Generating a LabVIEW UI 3: Control Scheme

LabVIEW, unlike other languages, draws non-traditional developers or rather people who aren’t developers at all, so when challenged to create a user interface, they may be starting from less than scratch: “I don’t even know how to begin to begin”. I think with this process, someone who is at least semi-proficient in LabVIEW can generate a functional and visibly pleasing user interface. I’ve used this exact process throughout my career in interacting with stakeholders and providing deliverables. This series seeks to provide a four step process to create a UI: (1) Wireframe, (2) Color scheme, (3) Control scheme, and (4) Functional prototype.

For context, the application being built is the lv-build (https://github.com/antonio-alexander/lv-build) which is a pocket CD (continuous delivery) which can be used to create one-click installers for certain LabVIEW applications.

Disclaimer(s)

• This isn’t the only way to generate interfaces, but it works really well for LabVIEW and interacting with other parties (especially to provide deliverables)
• This isn’t a super-complicated application, and in my case what it needs to do is well understood (it’s my application); so take it with a grain of salt
• A lot of the decision making in this article is driven by what is the most efficient method that uses the least amount of time; although the interface sells, the functionality should take all of the budget (including UI functionality)
• Some companies have whole teams for this kind of effort
• This is NOT geared toward applications that are heavy into process control. Often, those kinds of systems have more functional guidelines to dictate how controls should look, their colors and their shape.

The goal of the “control schemes”, is to determine what controls the interface should use and develop a scheme or style for all controls in the interface. This is also an opportunity to show what the interface could look like without having to do the work of developing the entire interface.

As this section is highly LabVIEW-specific, I’ll give a general overview of each control that I used and what I did to make the control look a specific way; my goal isn’t to give you a step-by-step, but to give you enough information where if you saw me do it, you’d have an idea of what I did and could figure it out for yourself. In addition, I favor flat interfaces similar to material (https://material.io/design) and flat design (https://en.wikipedia.org/wiki/Flat_design). I am definitely be behind the times, but I still prefer LabVIEW 2015.

LabVIEW already has a set of styles in the form of Modern, Classic, Silver System and Simple controls, all of these provide different “feels” for your application in very much the same way that we’ll modify string controls to fit the “style” we want. You don’t HAVE to do this level of customization for your controls, but it gives you an opportunity to make your application NOT look like LabVIEW and have more character which makes your stakeholders feel good.

• String: I start with a simple string control rather than a classic string to make it easier since it has far fewer layers, I can change the color without having to add or layer any decoration on it
• Boolean: I start with a flat square button for reasons similar to the string, far fewer layers and no drop shadows
• File path: historically I’ve used string controls and done conversions from file path to string and vice versa to keep it simple, but in this case I used the classic file control, made it transparent and placed decorations around it to maintain the colors I wanted without the drop shadows/3D effects with the classic control

• Navigation (radio button): I think the end effect looks really cool, but I used a classic radio button control and then since each of the “buttons” are just Boolean controls, I replaced the controls with the Boolean controls we made earlier
• Progress Bar: I used classic progress bar of the horizontal and vertical variants along with decorations. I went the extra step and during customization moved the increment/decrement buttons inside the progress bar to make lining it up with other controls easier since their use case is to never show the increment/decrement buttons
• Listbox (tree): I used the classic multi-column listbox, hid everything except the vertical scrollbar, made everything else monochromatic with the outline transparent and added a decoration around it to maintain the look
• Tab Control: I used a classic tab control, but I just made it 100% transparent and used a decoration around it. I don’t have plans to have the tabs visible (since I’m using the radio button for navigation) so I don’t need to do anything crazy intensive to get it to look right

I really like Icons or rather importing images into LabVIEW as bitmaps and using them as the different button states, it looks really professional and give you the ability to photoshop your own images. It’s intensive if you have to resize the control since in LV 2015 it’s not vectorized. If you do it, do it well after all the decisions have been made (I’d suggest POST prototype phase) so you can save time and do it once.

Although this matters most for the functional prototype, keep in mind that you can also make those controls strict type-defs and have SOME ability to propagate any changes to multiple interfaces without having to copy+paste them again. My suggestion is to not have to don’t lock in the interface until after stakeholders agree to it and push hard against any changes or at least make them admit that a change to the interface at this time is a scope change rather than a decision.

As a deliverable, this step should ONLY seek to show what the interface COULD look like with a given control scheme and should only show one of each type of control that would be used in the eventual interface.

I think my descriptions of how I modified the controls are sufficient, here is a video of me updating the controls: a picture is worth a thousand words:

Although (I think) this article had some hardcore LabVIEW-esque control customization, it should have given you the ideas behind using your imagination when creating interfaces: being able to create a custom control should give you the tools to create an interface and communicate your motivations behind it. In the final article, we’ll tackle how to generate a functional prototype using the wireframe, color scheme and control scheme.

All efforts/code for this entire series is available at: https://github.com/antonio-alexander/blog-lv-interfaces-and-experiences