Device Hierarchy

From MobileDesign

Desktop UI design patterns are reasonably stable regardless of platform. Tab navigation may look different in a Windows dialog box than it does on the Apple web site, but the basic concepts are the same. Only when multiple rows of tabs are needed does the underlying platform have much influence over design.

In contrast, mobile patterns rely on both device user interface style and platform. Whereas tabs are a useful mechanism on a stylus-driven device (web or local application), they are less useful on a scroll-and-select device application, and should be implemented as horizontal navigation instead. The same navigation in a web browser on a scroll and select device should either avoid the problem altogether, or use a drop-down list.

Since good design depends so frequently on device characteristics, a device hierarchy is helpful when working with mobile UI design. The hierarchy organizes devices into relevant device classes, with varying degrees of specificity based on the level in the tree.

There is no one correct hierarchy. Any hierarchy design will have its challenges. The sample hierarchy below shows one possible organization, assumed by the designs in this chapter.

The highest node in the hierarchy above is a mobile device. The distinction with the most impact on UI design is scroll-and-select versus stylus devices, so that may be the second level. Within stylus-driven devices, the operating system likely has the next most impact on design decisions. Within scroll-and-select devices, softkey management paradigms may have the next most relevant impact.

Feeding into the hierarchy at the lowest level is devices themselves, as reported in a device description repository. Several of these exist, as they are included in both WURFL and J2ME Polish. The W3C envisions myriad device repositories available.

Building and maintaining this hierarchy can not yet be done without human editing, as available device description repositories do not have information about user interface paradigms. The devices themselves do not report this information. Further, the hierarchy will be different for different platforms. Softkey management is largely irrelevant to a web site, very important to a Java ME or Flash application, and absolutely critical to a native application.

Each UI design pattern applies to one or more nodes in the hierarchy. Some patterns apply to all devices. Others apply only to lower nodes in the hierarchy. Most apply to the entire hierarchy, with different versions for different nodes. In this chapter are patterns in all three categories. The picture below illustrates how patterns may apply to different nodes in the hierarchy.

When designing an application, use information about target users, their devices, their training, and their diversity to help determine development strategy. Combine user and device information with project needs, application complexity, and organizational capabilities to decide what set of nodes to target.

A corporate intranet application might not have a large enough user population to justify multiple designs, and a generic design might be possible. In some companies, a generic scroll-and-select design might be optimal if few or no employees have PDA devices. A very simple web site is likely to work well with a generic mobile design. On the other hand, a highly interactive application or a frequently used application like a browser or email client will be well-served with a stylus version and different versions for various scroll-and-select user interface paradigms.

Designs within the hierarchy are inheritable. If targeting the Nokia-style softkey node, a design situation with no Nokia-specific design simply inherits the scroll-and-select pattern. Similarly if no scroll-and-select softkey design is present, the generic mobile pattern is inherited. In this way, targeting three nodes does not mean three times the design and coding work of targeting a single node.