Introduction

Content designed for display on a desktop browser appears very differently on the space-constrained displays that are typical of mobile devices. Also, due to limited processing power of handheld devices, graphical content can significantly influence page loading times. As a result of these limitations, Web content that is destined for use on mobile devices is often customized (sometimes referred to as mobile-device optimized). The goal of optimization is to present Web page information with minimal scrolling (vertical & horizontal), improve download times, and reduce system-resource demands, while maintaining an intuitive and easy-to-use user interface.

Based on a cursory review of the technical literature and several "device-optimized" Web sites, there are several ways to "shrink" a conventional desktop HTML page to better fit on a device. For example, Steinberg & Pasquale (2002) describe the use of server-based "Web-stream customizers" that compress images and graphics, and reformat frames, and Buyukkokten, Kaljuvee, Garcia-Molina, Paepcke, & Winograd (2002) discuss Web page summarization, in which only a page's text or hyperlinks are displayed. However, the only way to truly optimize a page is to create a separate version that is designed from the start with the device's limitations in mind (Clement & Vickers, 2002).

We have assembled the following list of design guidelines to assist in the design of device-optimized Web content. This list is not comprehensive; however, it introduces some general rules that we hope various development teams can take advantage of in their interface design efforts.

Back to top

Design guidelines

Limit graphical content

A PDA screen has roughly one-sixth the area of an 800x600 display (Clement & Vickers, 2002). Page graphics, in the form of logos, icons, frames, and images, both increase page load times and unnecessarily occupy this limited space, thus forcing relevant information (text, hypertext, and essential data-entry fields) to the outskirts of the display area. The Yahoo!-news Web sites, intended for desktop browsers and mobile devices, provide a good example of the differences between device-optimized and non-optimized device content:

As can be readily seen in Figure 1 and Figure 2, the optimized version greatly reduces the amount of content (particularly frame graphics), thereby improving page loading time and reducing the amount of vertical scrolling necessary to view the entire page. Also, in most cases, no horizontal scrolling is necessary.

Limit text, use link navigation (numbered when appropriate)

Again, due to display size limitations, text use should be limited. As seen in Figure 2, a common theme among optimized Web sites is the use of vertical lists of hypertext. For devices that provide a physical keyboard, it is good practice to number the links. This allows users to select a link using the keyboard/numberpad instead of the stylus, thus providing means for one-handed interaction.

In most cases, lists of hyperlinks eliminate the need for horizontal scrolling; however, if the link items must be wordy, such as with news headlines or e-mail subject lines, consider allowing for horizontal scrolling so that more items can be stacked vertically atop one another. Horizontal scrolling can also be acceptable to avoid breaking the URL.

Limit text size

Avoid the use of large text and icons. The default sizing of text and icons should be consistent with individual devices' standard font sizes. The Windows™ Mobile standard font sizes and weights appear in Table 1:

Utilize empty space

Excessive vertical and horizontal spacing between various page elements (text, icons, fields, and so on) and page borders should be avoided.

Limit the use of forms/data entry fields

Device data entry is typically a challenging process for a user for several reasons. First, the input methods ("thumb keyboards," soft-keyboards, and "graffiti") are restrictive when compared with full-sized keyboards and mice. Input rates are significantly lower for these methods (Commarford, in press; Roeber, Bacus & Tomasi, 2003), and in the case of soft keyboards, the user must often take two extra actions to open, and then close, the keyboard feature. In addition, when presented with a data-entry field, novice users often expect to be able to handwrite (using the stylus) the requested information in the field provided, typically causing confusion and frustration (Clement & Vickers, 2002). Another problem with the use of forms containing multiple data-input fields is that display space is rapidly consumed by the empty input fields.

An alternative to displaying all input fields and associated textual prompts at the same time is to display the textual prompts alone. After the user knows which field they wish to fill, they can tap the corresponding textual prompt, at which point the input field is revealed (Kaljuvee, Buyukkokten, Garcia-Molina, & Paepcke, 2001).

Another alternative to the excessive use of data fields is to provide a user with a series of hyperlinks that begin with a broad scope and narrow with each successive set of links. An example of this would be searching for a hotel in a given geographical location. Instead of requiring the user to input the name of the hotel and its location, the user could be presented with a list of hotels, followed by a list of potential locations (for example, countries, then cities/regions, and so on). Note that, although the input and search method might be quicker than link navigation with a desktop system, this is often not the case for mobile devices. You should weigh the number of steps saved by the search feature against the time to input (assume 12 WPM with onscreen input methods and 25 WPM with a thumb keyboard).

Limit (or eliminate) the use of widgets

Whenever possible, use links in place of pull-downs, icon-style buttons, radio buttons, or forms. If widgets are used, minimize and match their sizing to surrounding screen elements such as text, to avoid excessive consumption of space, awkward alignment, and line spacing problems.

Enable appropriate word-wrapping

Allow text to wrap at the page border to prevent the need for horizontal scrolling. However, paired page elements, such as navigation links with associated buttons (for example, a cancel button and a cancel link), should not be wrapped onto separate lines (and should generally be avoided to conserve space; the link is sufficient).

Error messages

Error messages should be displayed in a manner that is obvious to the user (for example, through "pop-up" windows). If the error message must be embedded in the Web page, ensure that it is located in a position that will be in clear view upon refresh; otherwise, it might go unnoticed, especially if the user must scroll to bring it into view.

Place non-essential links at bottom of page

Hypertext links that are not relevant to the theme or purpose of the page being displayed should be placed at the bottom of the page. This preserves space and places the most critical information in the user's view upon entry to the page (no scrolling necessary to navigate down the most common paths). For example, the Palm2 screenshot shown in Figure 3 illustrates the preferred placement of navigation links to other related Web sites:

Resources

• "Efficient Web browsing on handheld devices using page and form summarization" presents a design and implementation for displaying and manipulating HTML pages on small handheld devices such as personal digital assistants (PDAs), or cellular phones. (ACM Transactions on Information Systems, 20(1), 82-115. Buyukkokten, O., Kaljuvee, O., Garcia-Molina, H., Paepcke, A. & Winograd, T. 2002)
  
  
• "From server to PDA: an HCI perspective on porting wireless roaming business applications" provides proceedings of the IEEE 5th International Workshop on Networked Appliances, Liverpool, England, 107-112. Clement, P. & Vickers, P. (2002).
  
  
• "Efficient Web form entry on PDAs" proposes a design for displaying and manipulating HTML forms on small PDA screens. The article is from the proceedings of WWW10, Hong Kong, 663-672. Kaljuvee, O., Buyukkokten, O., Garcia-Molina, H. & Paepcke, A. (2001).
  
  
• "Typing in thin air: The Canesta Project keyboard -- A new method of interaction with electronic devices" describes a different interface to electronic devices. The article is from the proceedings of Computer-Human Interaction, USA, 712-713. Roeber, H., Bacus, J. & Tomasi, C. (2003).
  
  
• "A Web middleware architecture for dynamic customization of content for wireless clients" gives a new Web middleware architecture that lets you customize your view of the Web for optimal interaction. The article is from the proceedings of WWW 2002, USA, 639-650. Steinberg, J. & Pasquale, J. (2002).
  
  
• This Redbook discusses designing Mobile applications with WebSphere Everyplace Access Design and Development.
  
  
• Another Redbook on Patterns, illustrates Pervasive and Rich Device access solutions.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the authors

James Cotton is presently working as a Human Factors Engineering intern with IBM's User-Centered Design team. In addition to working on future designs for the Websphere Everplace suite of products, James is pursuing his doctoral degree in Applied Experimental and Human Factors Psychology at the University of Central Florida.

Patrick is the Lead Human Factors Engineer for WebSphere® Everyplace Access Client. He is responsible for enhancing the Everyplace end user experience through implementation of User-Centered Design (UCD) methodologies and application of Human Factors principles. Patrick has been with IBM® for three years and, during this period, has worked to drive ease-of-use into products targeted at both enterprise and consumer markets. He can be reached at commarfo@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Design guidelines
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Web development on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers