• Too many elements on one panel
• Improper use of color
• Inappropriate use of font faces and styles
• Counterintuitive operation
• Interface "scalability" issues as new features are added
  
  

In an attempt to provide a "complete picture", an inexperienced designer may overload an interface with a multitude of indicators and controls, just to ensure that "all the bases are covered". This often backfires and creates a confusing panel. Rather than showing "everything" as intended, the designer actually causes the operator or end-user to experience "data overload" which makes it difficult to differentiate critically important information from less important display components.

Solution:

Remember, as each additional control or indicator is added to a panel, the relative importance any and all other interface components is reduced. Start by evaluating your interface panel. Is every single item critically important, or could some of the components be deleted completely or moved to a pop-up subVI panel? Move less critical panel objects out of the "visible area" until only the most critical items remain. Rearrange these items until you obtain a visually pleasing balance. Now, look for creative ways to add the other (recently "hidden") displays back into the visible design area. Where possible, offload the least critical items to pop-up subVI panels, and look for places where "low data per area" displays, such as a bank of numeric indicators can be replaced by the creative use of "high data per area" graph displays, charts, custom controls, and indicators. And don't forget the most elegant way to minimize interface clutter - use attribute nodes to hide and reveal panel items on command or as the program requires.

Back to top

This particular pitfall can take a variety of forms: 1) too many colors, 2) too FEW colors, 3) color "clashes", 4) colors and/ or combinations inappropriate to the nature of the project.

Volumes have been devoted to the psychological, cultural and cognitive aspects of color and how to use it properly to enhance communication. It is beyond the scope of this document to go into any great detail about color usage beyond a few very simple guidelines. The best place to start with this whole color business is to examine how you are currently using color in your panel designs. What role does color play? Are the colors helping to communicate information, or are they used primarily for cosmetic reasons? Are you using colors "thematically"? Are you using color at all?

Color usage suggestions:

At the most practical level, color can be used to immediately draw attention to a specific indicator or control - to inform the end user of a critical operation or a change of status. Just as a red "trouble" indicator is hard to miss, other colors can be used to effectively indicate various operational states "at a glance".

Color can also be used to aid navigation in a large application, or to help organize many interconnected systems into subsystems. For example, an operator could quickly determine that he is looking at a component of the heating system because an indicator, icon or status bar is colored orange.

Too many colors!

One problem to watch out for when adding colors to a design is an overwhelming urge to use too many colors. Just because a computer monitor is capable of displaying thousands or even millions of colors, it doesn't mean we should boldly continue to add countless new shades to our design! What starts as a few nice flourishes of color can quickly degenerate into a gaudy "carnival show". To avoid this problem, the best course of action is to define a limited color palette at the outset. Two or three fairly muted basic colors for background and major interface components and a few (no more than 3) complimentary, bright, highlight colors chosen to draw attention to critical indicators, controls, icons, or perhaps a logo. Generally the "highlight" colors should be used sparingly for maximum impact.

Choosing Color Combinations That Work:

Choosing a combination of colors that will not only work together, but also help convey an appropriate message for your application can be a challenge. If you have a good eye for color and good taste, you will definitely have an edge. If you take your color choices seriously, you might want to check with a local graphic design or art supply shop for a graphic designer's color wheel - a cardboard device which helps you to choose colors which "match". A much more direct alternative however would be to download the "LabVIEW™ Color Palette Generator VI" available from our Free Samples page.

Other sources for color "inspiration":

- magazine covers
- professionally prepared internet sites
- look critically at book covers, television, advertisements etc.
Count the number of colors used by the designer. Notice how color is used to create an "attitude" in the viewer. Look for an appropriate attitude, then adapt it to your own color choices and interface design - in other words, borrow from the pros!

Effective use of color can be extremely challenging, but avoid the urge to simplify your interface design by using the tired, old, two-tone gray "minimalist" approach. Your applications deserve more than that. The addition of color will give your application a unique look, and rest assured, as you become more experienced, your color choices and usage will improve.

Back to top

You may already be aware of the effects of this one if you recall the early years of desktop publishing, or perhaps you have seen evidence more recently with the appearance of the "personal" internet home page. The problem appears when a designer decides to use several, even dozens of different font styles and sizes on a single page. The result of this practice is not only confusing, but generally it looks rather unprofessional. As with colors choices, "less" definitely is "more".

Solution:

Select a small number of font sizes and styles, assign those styles to specific functions (i.e. headings, controller labels, indicators etc.) and then stick to those fonts and only those fonts. Most certainly, a different title size and controller font on every subVI panel does not give the impression of a high quality, professional application. Limit your choices, then stay consistent.

Back to top

This problem seems to appear most often when a VI is developed primarily from the diagram with little consideration given to the panel components, or when building the most logically demanding parts of the code. For example, logic structures are added to the diagram which require several controls for the front panel. The controls are added on the diagram, but when it comes time to organize the user interface operations on the panel, the result is an awkward, counterintuitive interface.

Solution:

In most cases, a little forethought and a clear vision of the user interface functionality actually helps to streamline the logic flow of the diagram. As the most complex parts of the diagram evolve and features are added, it remains very important to continually check changes in design with the user interface to be sure the functionality is not "drifting off-track". Remember, the best features of your application are of little use if the operator can't figure out (or remember) how to access them.

Back to top

This problem can occur as an application grows or is modified. Perhaps this problem is more prevalent in LabVIEW™ applications simply because modification, editing and updating is relatively easy in comparison to more traditional "text-based" languages.

"Scalability issues" occur when new interface elements are added to the panel to accommodate modifications to the underlying code. Even an initially well thought out interface design can be turned into a clunky, unintuitive monster when new interface elements are added without sensitivity to the balance of the original design. This is not to say that the code must be in it's final form before the interface is finalized, but as items are added, great care must be taken to prevent a "tacked-on" look.

Solution:

Perhaps the best way to minimize this problem is to develop an initial design which "leaves room" for modifications. A bit more thought and time must be invested up front, but if there is an expectation that the code will be modified later, an unsightly interface or complete redesign might be avoided.

Back to top