Table-based Layout

From MobileDesign

Jump to: navigation, search

[edit] Applies to:

User Interface: Any
Hardware: Screen size > Extra-small - Small - Medium, Aspect ratio > Portrait

Example
Opera Mini home screen: forms and a series of heirarchical links, all in list format
Acceptable use of tables for a mobile screen. To make the conditions icon and temperatures appear next to each other, without using style sheet floats, a very small table is used.

Code Snippets


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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] Rationale

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

Risk of tables on small devices: Even small tables (this one is only three columns) can overlap the screen area and be difficult or impossible to see in its entirety. Consider lists instead.
Risk of tables on small devices: Even small tables (this one is only three columns) can overlap the screen area and be difficult or impossible to see in its entirety. Consider lists instead.

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.



Also see: add any cross-references that are relevant


Personal tools