LabVIEW Development Best Practices Blog

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Professional User Interfaces in LabVIEW

Active Participant

The flexibility of front panel objects in LabVIEW is something many people, including myself, take for granted.  We quickly drop down charts, knobs, and sliders, leaving them unchanged, and as a result, most LabVIEW programs have an unmistakably similar look and feel.  Of course, this makes it much easier to spot in a lab or during cameo appearances on shows like MythBusters, but many people are looking for ways to make more impressive and even 'sexy' user interfaces.

The success of commercial products like the iPhone are clear examples of the growing desire for intuitive user interfaces, but the world of engineers and scientists is not exempt.  There are a lot of practical reasons why a clear and appealing UI is valuable for a large LabVIEW application, as it can reduce learning curves and improve the effeciency of the user.

What many LabVIEW developers don't realize, is the level of customization and flexibility that LabVIEW controls and indicators provide.  Realizing this, my friend and colleage, SimonH, set out to see just how easy it would be to make some impressive controls and indicators for LabVIEW that broke the mold.  He's posted his first few examples in his new UI Interest Group, but I happen to know he's got a lot more up his sleeve.  Join his group and look for more soon!

Here's another particularly slick user interface that was made in LabVIEW for OptiMedica

LV UI.png

Elijah Kerry
Chief Product Manager, Software Platform
Follow my Software Engineering for LabVIEW Blog
Active Participant

While custom UI controls and indicators are examples of how the interface that engineers are using to break the human/machine interface barrier, it's also very important to know the simple guidelines for creating intuative user experiences.  Christina Rogers' article in this quarter's "Measurement and Automation" newsletter covers some of the basiscs and is well worth a look.  Also, I wrote a couple of blog articles a while back about user interface design that you might find useful:



Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.

One of the biggest things that I think Labview developers tend to ignore is the need to adapt to different monitor resolutions.  It is hard!  I think this is one of Labview's biggest drawbacks from a development standpoint, simply because things don't always scale properly and panels can get pretty screwed up before you know it during the resizing process.  I have used panes extensively with some success, but it requires a lot of discipline to maintain that level of flexibility.  However, it is one of those things that's just expected from a commercial application.  Perhaps this is a discussion for the UI group, but I think it is a critical part of large commercial programs.  Anybody got any good resources for this topic?

Active Participant

Hey Eli - there's even more cool LabVIEW UIs over here:

Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

Hi Robert,

Most LabVIEW applications are for very specific purposes, and I would suggest for very well-defined systems in terms of hardware, so there hasn't been too much of a call for adapting UIs to changing resolutions (they're usually static, per the system requirements).  That said, there are a coupld of things you can do - one of them is to use the native grow capabilities in you VIs' front panels.  The other that I use when I need to is to create an application that has a lower-level engine to do all the work, that communicates to the UI VI through VI Server (direct writes and reads from the FP nodes).  The UI VI is very simple, and is really just there as a true UI - pass messages to/from the application.  Then, if the monitor resolution changes (you can detect this), the engine can send a message to close the UI, and then open up another more appropriately sized UI.  This is also a great moethod for implementing a pattern where the user can switch between simple and advanced modes.

Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Proven Zealot

The problem with autoscaling UI's is that there is really no single way that is right for all cases. This makes it already very hard to tackle this issue from within LabVIEW itself. Add to that the fact that LabVIEW works on at least three in some aspects quite fundamentally different UI platforms (Windows, X Windows and Mac OS) and the task really gets impossible to do.

All the other widget libraries out there do both require significant help by the application through callbacks and/or events and also have not as expensive set of various controls as LabVIEW has. You can actually do properly resizing LabVIEW front panels too. A first step to that as you have discovered is to use panes. Another option I did myself in the past is explicitedly adding resizing logic to my state machine and resize all the controls exactly the way I want.If done right (and this requires some geometric algebra logic) the code while of course being specific to the UI in question can be kept fairly generic in design so that modifications to the UI can easily be added. Yes it is a tedious job to do the scaling yourself, but it is the only way to do it right in the way you feel it is right.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Active Participant

JKI recently blogged about our professional user interface design services -- it's amazing what you can do with a professional designer and customizing LabVIEW controls.

JKI Blog