Looking good--a lesson in layout

July 20, 2004

MurphysLaw-July 20, 2004

The engineers who implement user interfaces aren't always the best ones to design it. Good UI design is a specialty unto itself, with its own rules and guidelines. This month our resident UI specialist describes how to design user interfaces that are actually useable.

As the graphical display hardware for embedded systems becomes more impressive, we're often taking advantage of these new display capabilities when we design user interfaces. Ideally the look of an interface should be designed by a graphic designer and implemented by a programmer. In practice, however, many of the decisions about layout and appearance are made by the programmers or heavily influenced by the tools and libraries available to the programmers. This might not be such a good trend for the poor users of our user interfaces.

In this article, we'll look at some standard layout techniques that graphic designers employ. While we can't turn programmers into graphic designers, just knowing these techniques will improve our designs when we don't have the benefit of input from a graphic designer. If you do use a graphic designer, understanding their priorities will help you faithfully implement the proposed layout.

A programmer's priority when building a GUI is to get the functionality working first and to attend to the cosmetic details later. This is fine so long as "later" does arrive. In the meantime the placement of controls on the GUI can look unprofessional at best and haphazard and confusing at worst. Most of the worst layout problems can be remedied by adhering to a few simple rules we'll discuss here.

The rules for layout are sometimes applied to the entire display and sometimes to an internal area. On an embedded system, these areas are not always windows, as they would be on a PC. In this article I use the word "dialog" as a generic term for a set of graphical items that are displayed together and may or may not occupy the whole screen. Some of the dialogs presented here are from real products and others are fictional examples.

Often information you're displaying has a natural hierarchy. It makes sense to set the band on a tuner to AM or FM before picking a particular frequency. Major decisions, such as which printer you want to use, come before more detailed decisions like paper size and quantity.

Figure 1: Simplifying nesting boxes—1B shows less clutter

Figure 2: Left-to-right ordering

Figure 3: Gestalt phenomenon

Figure 4: Alignment

You can communicate such a hierarchy in the layout by nesting one box within another as in Figure 1a. In this figure, however, the bounding boxes tend to dominate the display, distracting the viewer from the real information. Also at edges where multiple boxes end, the set of identical lines make it hard to match each boundary to its contents. Indentation, combined with heavier fonts to distinguish section headers, can provide a more subtle clue to the hierarchy with less clutter, as shown in Figure 1b.

Hierarchy also influences the top-to-bottom ordering and the left-to-right ordering. In the Western world people expect to make the more major decisions on the left and move to more detailed decisions on the right. Figure 2 shows a hierarchy of choices represented by icons on the left, followed by the setting names in the middle column, and finally the values on the right. The icons for the main menu would also have worked well across the top.

If the icons had been arranged along the bottom, however, the user would have been forced to find the first level of hierarchical information in the last place they normally read, which would make the screen harder to scan. Sometimes you can't avoid putting the top-of-hierarchy choices at the bottom of the screen, for example when off-screen keys (also known as soft keys) to select the menu items are placed just below the display.

Invisible lines
In Figure 3, although there is no line-drawn triangle, you perceive one because your brain fills in the missing lines. These invisible lines are the key to grouping items by alignment. In Designing Visual Interfaces, Mullet and Sano refer to this as a gestalt phenomenon.1

In Figure 4b the link between the list of paper sizes is tighter than in Figure 4a. When vertically listed the circular radio buttons are aligned and also the start of the text describing each radio button is aligned, giving us two vertical lines. The horizontal arrangement isn't as effective because it switches between the radio button and the text after each item. It's also more difficult to space the horizontal line. If the round radio indicators are evenly spaced then the gaps between words are uneven. If the gaps are kept constant then the distance from one radio button depends on the length of the caption. Either case leads to the eye taking uneven jumps when scanning the row.

In the case of the radio buttons in Figure 4a, it was important to link the items tightly because they function as a group. More loosely linked items also benefit from alignment because it makes the set of labels or buttons easier to scan. The eye follows the line naturally without having to shift left and right as it moves down the list.

The baseline of text forms another important invisible line. Note how the baseline of the text in the "Copies" label is aligned with the baseline of the numeric value in the editable value box. Maintaining the text baseline is important for readability. Many GUI building tools get this wrong. If you select multiple items and pick the "Align items" option, it aligns the bottom of the text label with the bottom of the editable box, instead of the baseline of the text within the editable box.

Careful examination of Figures 1a and 1b also shows how important it is to spell check the text placed in your dialog boxes!

Balance and symmetry
Making a layout look balanced can be tricky when space is restricted. If one side of a dialog has more empty space than another, the effect is an unbalanced view. Obviously having all of the graphical widgets on the right and none on the left would look odd. Most designers would have enough sense to not do this, but sometimes it's hard to control; for instance, when certain graphical controls are optional and might not be visible under certain circumstances, it can leave a row of controls with an awkward gap, like a missing tooth.

Figure 5: Symmetry
Figure 6: Nonalignment

Figure 7: Proper order
Figure 8: Wasted space

Making the layout symmetrical helps maintain balance. Figure 5 shows a layout that is very symmetrical around a central vertical axis and is therefore well balanced. One blank box in the lower row maintains the symmetry of the lower row without adding awkward amounts of empty space to the other three data items. This blank space is analogous to the false doors that were used in Victorian architecture. A room with three exits would have a fourth door which led nowhere but simply hung on the wall to balance the appearance of the entire room. Figure 6 fails to be symmetrical due to careless layout—the box of numeric settings should have been centered in the display.

A symmetrical appearance will always be more appealing to the eye, even if the viewer is not consciously aware of it. A lack of symmetry in the human face or body is perceived as less beautiful by the viewer than a perfectly symmetrical shape. The same psychological effect influences our perception whether we are looking at a car, a building, or a GUI.

In Figure 7 placing the "Yes" and "No" buttons on the opposite sides of the display maintains symmetry and balance, which would have been lost if the designer had decided to place the buttons above one another on the same side.

Out loud
Your eye scans the display quite quickly, and you're not always conscious of inconsistencies in the display that contribute to confusion. To slowly scan the text in a dialog box, you can read it out loud. This can make it apparent if adjacent text items conflict. In Figure 7 a question is asked of the user. The "Yes" and "No" answers are available at the bottom of the screen but only after the user reads another piece of information—the customer's balance. It's preferable if the question is immediately followed by the set of possible answers instead of intermediate information.

When reading the display watch out for places where the same label is repeated often. This is a sign that creating a column for that piece of information might have worked better. Figure 8a wastes space by repeating labels. Figure 8b solves the problem by arranging the data in columns. This arrangement helps the viewer scan the list of names for the sensor of interest, without having to skip across the data related to each of the other sensors. The vertical list is also symmetrical around a horizontal axis making it more pleasing to the eye. The left and right edges are flush providing a stronger boundary to this block of data.

Figure 9: Which button reads next?
Figure 10: Word size

In many cases there is a natural order to a list. In Figure 9, there are three possible values of sharpness. The natural order of sharpness is "Soften," followed by "Normal" followed by "Sharpen." However they are not displayed in that order. The viewer's eye is not given a clue whether the next item to read after "Soften" is the one below it or the one to the right.

Overcrowding of the display can lead to confusion between parts of adjoining items. In Figure 4a consider the round radio buttons on either side of the word "Envelope." It's not obvious whether the left or right radio button is the one associated with that label, and the reader must remember the convention of having the radio button to the left or scan the whole list to work it out.

Creating an overcrowded dialog box is risky. It's hard to be sure that requirements are fixed when defining the layout, and if you have to add one new button, it may be too difficult to squeeze in. Also, in translating a dialog box to another language, you may need wider labels since many languages, such as German, have longer average word length than English. Translating to Chinese or Japanese requires more vertical space and sometimes requires a complete relayout of the GUI if it was not considered from the beginning of the design.

Limited resolution makes the overcrowding problem all the more acute—and providing scroll bars is not always an option. If one of your dialogs is too crowded, you should first go through each feature and decide if it's really needed. Almost every project I work on or review includes features that aren't going to be needed by a real customer. They were included either because they were easy to program, or based on flimsy evidence of a market need. If these pointless features are making it more difficult to provide the vital features, then strip them out.

The next step is to break the dialog into multiple dialogs. While this leads to the problem of navigating from one dialog to the other, two clear dialogs will always be preferable to one cluttered layout.

Conquer clutter
Fewer graphical controls and sparser data reduce clutter, but you should also consider the amount of visual data presented because of the graphical effects you're using. For example a 3D look for your buttons adds quite a few lines to the button edges. At low resolution the 3D effect could occupy 20% of the buttons' real estate while adding very little information. All of the extra lines and detailed shading to give a 3D impression add to visual noise that must be peeled away by the viewer in order to extract the core information. While the 3D effect serves a useful purpose in letting the user know which items can be selected, it has the disadvantage of making the screen look more cluttered.

Microsoft Windows uses 3D buttons, but on the toolbar of an application with a large number of buttons, they're all presented flat. They only take on the 3D effect when the mouse is placed over the button. Showing the 3D effect all of the time on all buttons would lead to a cluttered display. Unfortunately this technique of showing the 3D effect when the mouse is over the button doesn't work for touchscreens, which are common in embedded applications.

So the lesson is to be wary of a 3D effect in situations where the effect must be applied to a large number of objects that are displayed simultaneously.

Shading can make an object look curved or backlit. See my March 2003 Murphy's Law column for examples of this.2 While the effect can add impact to your buttons, it also adds to the visual noise. It's also important that such an effect doesn't cause contrast problems. In Figure 10 the "Low" and "High" buttons don't have contrast problems, but because "Medium" is a longer word the "M" starts to get lost in the lighter background. Shading the background of an entire window leads to similar problems.

Design by grid
Magazines and newspapers are generally designed with a grid template. Using the same template throughout gives the pages a consistent feel. Some elements of the design can take up the width of two or more columns, but to conform to the grid it's important that all items align their left and right edges to a column boundary. The grid also enforces consistent margins across all pages.

Figure 11: Using a grid

In GUI dialog-box layout the horizontal divisions are just as important as the vertical divisions. Figure 11 shows a grid layout of a photocopy machine's GUI. Notice how the graphical items in the bottom left and the bottom right use the same width and margins as the columns of buttons. The graphical elements are taller than the buttons in the grid and have been designed to occupy exactly two button heights.

This grid uses columns that aren't all equal in width. The location of some of the graphics and limits on space available may have forced the designer to do this. However the designer would have improved it slightly by making it more symmetrical around a vertical axis. In its current form the leftmost and rightmost columns are different widths, in a layout that would otherwise be perfectly balanced. The middle column is also a unique width. Because it is in the middle, this doesn't damage the symmetry, but it does leave the viewer wondering if there is a special reason for the difference in width.

Figure 12: Grids

Figure 12a shows another dialog based on a grid layout. Items such as the progress bar and the button containing the image of a truck are full-height items, and would touch the text above unless we have defined margins in the vertical axis. This dividing space is not always necessary if each line contains only text, in which case evenly spaced text baselines will suffice. Figure 12b shows the dialog with the grid overlaid.

You may use a grid to enforce symmetry and order on a single dialog, or you may be designing multiple dialogs and using a grid will help maintain consistency. This is especially useful if multiple programmers are working on the dialogs. The more complex the dialogs the more variability you need to allow within your grid, or you may require a small family of compatible grids.

Like many of the techniques discussed here, employing a grid does cost some screen real estate, so while you are considering what grid will work across all of your dialogs it's important to test it with the most cramped dialog in your design.

Final impressions
The layout of your display will have a major impact on a customer's first impressions. Often this is the impression that leads to the decision to buy or not. A little effort on making the appearance appealing can make a real difference here. In the longer term a frequent user will enjoy the benefit of taking less time to absorb the information on each dialog and will feel that he is interacting with a polished and well-finished product.

Niall Murphy has been designing user interfaces for twelve years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy teaches and consults on building better user interfaces. He welcomes feedback and can be reached at nmurphy@panelsoft.com. Reader feedback to this column can be found at www.panelsoft.com/murphyslaw.


  1. Mullet, Kevin and Darell Sano, Designing Visual Interfaces, Prentice Hall, NJ, 1995.
  2. Murphy, Niall, "Light and Magic," Murphy's Law column, Embedded Systems Programming, March 2003.

Loading comments...

Parts Search Datasheets.com

Sponsored Blogs