Generating a LabVIEW UI 1: Wireframes

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

Wireframes are used to organize one or more interfaces without getting too deep into the details. Both from the perspective of a developer and who you’re developing the application for, it’s best to backload anything that takes a lot of effort as you may not have enough information to make the right decisions at this early stage in development. Form follows function and you may find it easier to have a clear idea of what the application should do by putting together it’s interface.

When creating wireframes, I focus on navigational structures such as tab controls, subpanels, window size/look, resizing and splitter bars. I don’t focus on things like colors or controls (outside of those mentioned), I even attempt to keep LabVIEW grey and the default color for controls to reduce the distraction. For controls/indicators and expected items, I use a comment (with LabVIEW yellow) to make them easy to move around/re-size. In situations where I want to group a set of items, I use decorations to show logical grouping if they’re not already in a tab control or pane.

Wireframes are great for live interactions, you can safely perform changes with stakeholders as well as re-size and re-organize at their whim; this gives them the illusion of you being able to make any changes very quickly. As with any application, the further you get in the project, the more difficult it is to make changes and you’ll find that the moment you add custom controls or colors, it becomes significantly harder to make certain changes. Being able to make changes will instill confidence and give you room to push back as you complete more of the application.

In terms of deliverables, you could always build an application using your wireframes to provide a “functional” application so stakeholders could see the wireframes in action, especially with any interface-like functionality (mentioned above). This is a great time to get them familiar with the process to install and/or run a LabVIEW application on the machines they plan to deploy them onto. In the event you are not the end-all, be-all for giving demos (e.g. they have people they demo to), this can help them give live demos. Alternatively screenshots can be made of the wireframe interface(s).

I thought there was value in being able to observe me doing a wireframe, so I made a time-lapsed video:

Although I do a really good job of glossing over some of the details; I think there’s enough here to get anyone who can program a little LabVIEW, in a place to generate a wireframe. Similar to the “Blank VI” syndrome, it doesn’t JUST happen on the block diagram. In the next article we tackle color schemes, both in terms of choices to give stakeholders AND in what’s practical to look good but not take a lot of effort.

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