Generating a LabVIEW UI 4: Functional Prototype

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

A functional prototype is meant to combine the wireframe, color scheme and control scheme. I suggest that you literally copy + paste the controls from your control scheme and then copy + paste your wireframe and re-arrange as needed. The prototype should be quick and the only additional time you should spend is changing background, skinning, decorations or final re-arrangement because the wireframe doesn’t look appealing when combined with the controls or colors (it happens).

Implement as much UI based functionality as you can: if a button is meant to navigate toward another interface implement this, if a subpanel should show another interface implement this, if the UI should re-size with splitter bars, implement this; make the exit button work. The functional prototype shouldn’t implement the interface architecture, although you should definitely be thinking about it at this point. Also implement some dummy code if indicators should be displaying values or changing at run time; this gives you the air of a “demo” and makes your deliverable feel alive, even though zero functionality should be implemented at this point.

During the prototype creation phase, your first draft prototype should take into account placement of controls and indicators and when they should be visible. For example if a handful of controls are only accessible under specific circumstances, then they should only be visible or enabled when those circumstances are present. Also visual indicators to what’s a control and what’s an indicator also help: for example in the image below, notice how all the string indicators on the prototype have a white outline while the navigation controls have an orange outline. Also notice how the exit button uses the complementary color to draw attention, is by itself and is always accessible.

In my opinion, as long as you communicate that no functionality has been enabled and you get to this phase VERY early in the project, you can manage expectations. The only reason a stakeholder will see a “finished” UI and think the project is complete is because you didn’t communicate to them the project is not complete. I’ll restate that designing a complete user interface should take less than 2–5% of your total budget; there are only a couple of cases where implementing functionality could break your prototypes and you should know what these are.

Like any demo, it’s an opportunity to communicate and connect with your stakeholders, sometimes they are really fixated on something that’s really inconsequential (e.g. a kind of graph) or tied into their business case for the application. In these cases, try to check that box for them and show them that it’s as trivial as you think it is: If your stakeholder REALLY wants some vertical strip charts, ensure that you implement enough functionality to SHOW a vertical strip chart, maybe even go the extra mile to implement that functionality. Again, keep in mind the budget and defer to budget constraints when not implementing it if it’ll take too much effort, but if you can spend a little time to go the extra mile, do it. It’ll make your job easier when you get further into the budget and have to start hitting the brakes on things that you can’t “afford” to do.

I put together a video showing me copy+pasting all of the deliverables from the previous steps into one:

I hope that (1) you read the entire series and (2) you have learned how to create a functional prototype as a way to ensure that you or your stakeholders have a user interface and experience that meets the goals of the project. This series should allow you to get through the interface planning aspect of a project as quickly as possible while developing a good user experience and giving stakeholders the ability to understand what’s going on and make decisions that ultimately affect them.