Design Pattern of the Week: Table-based Layout

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This second set of patterns will address screen design for mobile applications.

Many devices and applications have a launch screen, with two or three columns of icons, from which major components can be started. Stylus devices in particular have these screens as application launchers; Palm has used such a screen for over a decade.

Design

A table-based layout screen is simple, with little need for softkeys or buttons. It should have a title, two or three columns of cleanly designed icons, and a label for each icon underneath it. This design is often repeated across devices and platforms; it is likely that the device currently in your possession has a launch screen with this design as one launch screen option.

On scroll and select devices, place the focus in the center of the layout, not the top. This reduces keypresses necessary to reach any given icon. Do not use this technique if the items do not fit on a single screen.

If at all possible, restrict the number of items to those that will fit on a single screen. If necessary and the application users can continue to see icon details, reduce icon size to make this possible. If this is not possible, consider a different design - especially for scroll and select devices.

Avoid using tables as layout on web sites; if a column layout is desired, use CSS.

Applicable Devices and Platforms

The table layout is particularly effective for stylus-driven devices but can be used in very limited amounts in local applications on scroll-and-select devices. Do not use a table to lay out a web page on a scroll and select device.

When Used

Use on launch screens, either for a device or for a frequently used application. Do not use it on a screen with frequently changing options. Consider other designs for a launch screen with more options than can be displayed simultaneously without scrolling, especially for scroll-and-select devices.

Rationale

Caution with using a table layout is based on all the rationale of using a list-based layout, combined with the need for graceful degradation on web pages in browsers that do not work well with tables.

Tables, with icons, are good for presenting more options on the screen and promoting location memory. Users know that the browser option is in the top right corner, so they can quickly tap there. Even scroll-and-select users get some benefit from position memory, but at the expense of complex scrolling control. If the list of options frequently changes, this position memory benefit disappears.

For a set of items that can not fit on a single screen, a table layout introduces extra complexity for a scroll and select device. The user has to manage decision making for each item, left and right cursor movement, up and down cursor movement, and page scrolling. This extra complexity can make the task of activating an item too complex.