Today’s post is part of a monthly series exploring areas of focus and innovation for NI software.
The introduction of LabVIEW to the market was defined by a revolutionary graphical user interface that included a combination of built-in libraries for engineering applications and a drag-and-drop UX schema. I’ve heard stories from the “original” generation at NI regarding the jaw-dropping nature of LabVIEW in the early 80s and 90s due primarily to the simplicity of the development of the UI. Of course, 30 years ago the Internet didn’t exist, cellular networks were a novel idea for military applications, and touch-screen tablets were a distant dream.
For decades, the GUI set LabVIEW apart from traditional programming languages for two reasons. First, the UI components were built into the environment instead of being paid, add-on libraries. Second, the UI components were custom designed for engineering applications including gauges, tanks, and intensity charts. As a generality, the most critical aspect of UI development in an engineering application is the simplicity of data visualization. The LabVIEW UI was designed for the concept of visualizing time-based waveform measurements, the kind of measurements most commonly associated with real-world analog data such as temperature, vibration, and voltage.
Almost 30 years later, the LabVIEW UI is still well-suited for visualizing measurement data. Over the years, engineering tools have continued to evolve, closing this gap in UI functionality and ease of use. But it was the evolution of the consumer mobile market that seriously changed user expectations. Users now not only want, but expect advanced concepts in their UIs such as gestures, resolution scaling, and dynamic movement.
Most pragmatic users of LabVIEW are entirely content with the functional display capabilities of LabVIEW today. However, they voice their opinion on the Idea Exchange, and these typically fall into three categories:
1. General Look and Feel
The LabVIEW UI was designed to mimic the front panel of a physical instrument, graphing measurement data and providing a layout of knobs and sliders to control the measurement parameters. The design decisions made to this effect are often antiquated for the expectations of today’s modern UI principles. I often hear LabVIEW users say “this UI looks like it was built in the 80’s.”
Generally speaking, the Control Editor inside of LabVIEW helps developers apply a wide range of customizations to UI elements, breaking down each control to its elemental components where pictures, designs, and color schemes can be applied.
It’s not the functionality capability that most developers want to see improved, but the simplicity in applying sophisticated customizations and extensions. LabVIEW lacks a well-structured API to interface to these customizations, instead relying on an interaction editor to accomplish the task. That lack of automation from a tool centered on the concept of automation is limiting.
Lastly, the portability of LabVIEW UIs are minimal. The portability requirement is generally either to scale to a different size or resolution of monitor, or to a mobile-based device. By design, the LabVIEW UI is vector-based, which fundamentally limits the scalability or portability to different sizes or platforms.
These limitations leave LabVIEW behind where we want to be in terms of UI design, functionality, and portability. Redesigning the foundation of any UI is a difficult, multi-year effort. Fortunately, we’re significantly far into this investment-unfortunately, we’re not quite far enough. Over the next few years, you’ll begin to see our investment reach the point of deployment…deployment to you.
Follow along as we near that deployment; we’ll be sharing more information with you along the way.
Today’s Featured Author
Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at @TheLabVIEWLion.