Happy Halloween!

It's a tradition, on Halloween, for the LabVIEW team to demo features under development to the rest of NI. Some of us dress up for the event. You probably can't see in the picture, but I have buttons on my belt that say <Back, Next>, Finish, Cancel, and Help. My hair is blue and I have a white X on a red square on one side of my head and a LabVIEW logo on the other side. That's right... I dressed up as a LabVIEW wizard (dialog)!

Demystifying the LabVIEW Color Picker

Ah, color. So integral to a good user interface, and yet also the easiest way to make a VI as hideous as an evil clown.

The LabVIEW color picker tries to help you, but unfortunately it doesn't explain itself very well. So I'm going to explain how the folks who designed it meant for it to be used.



The bar along the top lets you pick pure black, pure white, or any shade of gray in between. These are good choices for large areas, like the panel.

The box at the top right is a T if transparent is available as a selection, and an X otherwise.

The second bar from the top contains muted colors. These are good for medium sized areas, like controls.

The third bar contains saturated colors. These are for small areas: LEDs, graph plots, etc. Please don't overuse these bright colors, or everything on your panel will scream for visual attention so much that users won't know where to look first.

The User row of boxes contains colors that you can define in Tools>>Options. These are handy if you want to use the same RGB colors frequently.

The History row of boxes helps you re-use colors that you selected recently.

The box at the bottom left shows you the selected color (and is split into two sections for foreground/background color when applicable).

To the right of that is an icon that tells if you the selected color is an RGB value (color circle icon) or a symbolic color (stacked rectangles icon).

To the right of that is either the RGB value or the name (for User colors and System colors).

At the bottom right is a button that brings up your system's color selection dialog.

Now, you may noticed I saved one section for last: the System section. I talked a little about these in my previous post. When you use these colors, the color that you see is only the current value of the color. The user can change appearance properties in the system (outside of LabVIEW) and remap these colors to whatever he or she wants.

The boxes are really three pairs. In each pair, you have a color and then the color for text that goes on top of that color. The three groups are: panel and object, window, and highlight.

Confusingly enough, window is not the color of the window. That's panel and object. "Window" color is used in places like listboxes. Why is it named the way it is? I have no idea. [11/15/2006 Correction: I found out that the "window" color refers to the "client area of a window," such as the document area in a text editor. Listboxes actually have separate symbolic colors but they are often set to be the same as the window colors].

So, there it is. The LabVIEW color picker's mysteries revealed. I hope some people find this useful.

Looking Like LabVIEW

Ideally, you should first design your user interface without worrying about the visual design. Make sure the right controls and indicators are there, that they have the right names, and that they're in the right place.

But at some point, you have to decide on a style. With LabVIEW, there are basically three options:

• You can use the controls and indicators on the top-level palette (which became the Modern sub-palette in 8.x).
• You can make something that uses the colors and styles of your platform.
• Or, you can make something completely customized with your own graphics.

Each has pros and cons.

The first option is super easy. The "Modern" controls and indicators were designed by professional visual designers, and they look good together. But, anyone who's familiar with LabVIEW will be able to recognize the tool that you used. Some people complain that they don't want their applications to "look like LabVIEW."

Making a "system" UI is difficult to get completely right. When you use the system controls and the system colors, you have to think about everything more abstractly. You're not placing that listbox. You're placing a listbox. The frame, the scrollbar, the font, the colors... everything can change out from under you, and you have no control over it whatsoever. You also don't have a complete set of controls and indicators. Microsoft hasn't defined a system graph indicator, so LabVIEW can't offer it. The best you can do is create controls with similar fonts and colors, that blend well with the system controls. [Here's a tip: if you need a control for a system style UI that isn't on the palette, see if you can find a custom probe that has it. We've made system-like graphs and arrays for the custom probes that ship with LabVIEW].

A word of warning: do not mix system style with modern style! If you're doing a system style UI, you have to do it 100%. System colors change based on user preferences at the OS level. So, if you put black text on top of a system panel color background, even though the background may look gray to you, it could easily be black on someone else's machine. And black text on a black background is notoriously difficult to read. :-)

The third option is to create (or acquire from a visual design company) graphics and customize your controls in the control editor. Many people I talk to are surprised at how much customization is possible in the control editor. I'm not saying this is easy... just possible.

My advice is to weigh the requirements, benefits, and cost on a case-by-case basis. I have seen some impressively beautiful UIs from LabVIEW customers. It is possible, but it takes more effort. It's up to you to decide how much you want to invest in your visual style.

User Interfaces in LabVIEW

I'm going to change gears a bit and talk about user interfaces (UIs), particularly LabVIEW panels. Some of you may have seen me co-present "the Good, the Bad, and the Ugly" with Greg McKaskle at NI Week. We've given tips and tricks for UI design, some of which are general design principles and some of which are specific to LabVIEW. I've gotten a request for a new LabVIEW UI Design presentation, so I'm going to review some of the material here, and hopefully get feedback on what parts people find valuable.

UIs can be the most challenging part of a project, because by definition they deal with that most variable of variables: people.

I find that UI design is full of guidelines and heuristics, with few unbreakable rules. And there are good reasons for that. There are a lot of factors to consider when designing an interface.

I can't look at a snapshot of a panel and tell you if the UI is good or not. No one can. A user interface is much more than whether or not the panel "looks good."

You have to know who is using the panel and what she's trying to accomplish with it. Because, in the end, a good user interface is one where the user gets her task done and is satisifed with the experience.

You also need to know where the interface is being used (e.g. desktop or manufacturing floor?) and how the user operates it (e.g. keyboard, mouse, or touchscreen?).

Making a panel "pretty" should actually be the last step in UI development. You can invest time and money making a panel very attractive, but not everyone who uses LabVIEW is going to find that investment worthwhile.

This is only the first post in a series. Feel free to request any guidelines or features you want me to discuss by e-mailing me at eyesonvis@gmail.com.