In life, one question frequently leads to another. So, if we ask users of mobile devices what they consider are effective, successful user interfaces in their hands, then, as developers it follows we must also ask what parameters are involved to make the device user interfaces successful. Development guidelines can help, especially if they result from practical experience. Mobile applications, in fact, may provide the best example of the role and benefit of developer’s guidelines that optimize user interaction. Several factors contribute to this situation:
- Uncontrollable user environment
- Small screen size
- Limited input mechanism
- Low-bandwidth connection
Before getting to the actual guidelines, it is always beneficial to consider some of the basic realities of the mobile application environment and objectives of device interaction with the user. For one, mobile devices use a variety of protocols. These protocols include WML, XHTML, cHTML, and so forth. The developer’s objective with this environment constraint is to maximize protocol coverage and support while minimizing development effort. Ideally, select tools are able to target multiple protocols with a single UI model, and support rapid visual application development.
Next, developers must deal with a small display and limited user input. Mobile devices can be personal digital assistants (PDAs) featuring medium-size displays, but can also include mobile phones with much smaller displays and only number keys for input. Here, our objective is to minimize scrolling. We also want to target keyed user input.
A last consideration, which effects virtually every mobile application being written, is server access. Mobile devices are wireless and bandwidth is not relatively abundant, so we must be very efficient in accessing the server.
Field Guide to Development
Experience suggests that guidelines are best grouped into four areas: application, deck, card, and navigation. The notion of a “card” is used to describe a specific screen presented to mobile devices accessing our application. It includes a visible display, input areas, and links to other cards in the application. These cards are grouped into decks. A deck is a sequence of cards that are intended to be viewed sequentially.
Our first set of guidelines deals with the application level. Our first guideline is to organize decks as wizards that guide a user through specific functions, such as capturing related information. Probably the most predominant use of wizards is graphical install applications for personal computers. Designing a good mobile UI wizard requires extreme care. The aim is to present only the information a user really requires; this is accomplished by prudent elimination of any and all unnecessary information and user input. For instance, if I wanted to capture a user’s city, state, and zip, I might first capture zip code and look up the city and state on the server, thereby eliminating two alphabetic fields. In this same manner, we would look to minimize all user interactions.
The presentation layout, or “look and feel,” should be consistent across the application. Use the same types of UI elements (such as checkboxes, radio buttons, lists, menus, and so forth) for the same types of information. It also pays to keep the application simple. Avoid throwing in extra “splash” content such as images and sounds. Look for every opportunity to conserve bandwidth and accesses to the server.
Decks are groups of cards in a mobile Web application. Applications can have multiple decks. Developers should utilize decks to effectively display and guide users through multiple “cards” or screens. Split large content bodies into multiple cards within the deck. Also, label cards using a “1 of 3” or “1/3” to show the total number of cards in the deck, and the current card location. When allowing the user to delete information, provide a confirmation card or “delete screen” so the user doesn’t inadvertently delete input data. This is especially true with mobile UIs because users get used to moving through cards and all the effort minimizing user input can be undone if a user ends up reentering input data.
Cards are basically screens on the mobile device. If a card is larger than the device display, the user will be able to scroll through all card content. Scrolling should be minimized, however. It is easier for users to move from card to card than it is to manage lots of scrolling. Also, don’t leave a row empty; this is because some devices do not have scrollbars. Instead, put a horizontal rule or something to fill a blank line so users will know there is content following, even if it’s just not yet visible. You don’t want them to miss content that follows a blank line because they don’t know it’s there.
Put titles on your cards. Some devices (such as Nokia) display WML card titles. But, try to keep these labels at five characters or less, as the room for titles — like everything else — is very limited in these displays. Limit cards to nine items per card, using a “More” link as the 10th item. Too many elements causes unnecessary scrolling and it is easy for the user to get lost. Also, avoid wrapping the text of lists or menu items. This clutters the screen and is less understandable to most users. This also allows the user to see more list items at a time. Also, avoid wrapping links, as this also becomes difficult to read.
Do not define more than two softkeys because many mobile devices do not support more than two. On cards that display information or confirm a user action, use softkeys to accept or present options. Users are most familiar with the softkeys, and proper setup of your wizards will effectively guide users with these softkeys.
Provide multiple paths to the same information. For instance, to find a specific phone number, allow the entry of a zip code or city/state information. Do not let the user proceed after entering improper information. If you ask for a date, for example, validate the date before accepting more information. This is the opposite approach from many Web sites that have plenty of display room to indicate erroneous fields all at once.
Another good practice is to construct and use informative titles (for example, dd/mm/yyyy) that communicate field type as well as format. Restrict length on input fields when possible, and distinguish between alpha and numeric fields. Users may be entering characters via a phone pad, so convey to the user what input you are expecting. Avoid relying on font type and color, and only use images or icons when they are necessary. They take up precious screen space and bandwidth and can make the card too busy and unclear.
As in most Web applications, an easy return path is useful in your mobile application as well. Backward navigation is almost a necessity in a well-designed mobile UI. When navigating backwards, avoid cards with input fields. Otherwise, as users press back/clear, they will erase the inputted values, which is probably not the desired result. Use intuitive links or softkeys, such as “previous” and “next” to guide the user linearly in the deck. Use “more” to indicate jumping to additional pages of the same data. Next implies jumping to the next card. Also, put navigation links at the beginning or end of a card. Avoid embedding links in text unless they are very context sensitive.
Map the safest or most common action to the “accept” or “OK” softkey. List link choices in the interface, not in the softkey options. Also incorporate a done softkey when possible to pop the user up to the next highest level.
Many tools are available for developing graphical user interfaces for computer applications. HP has developed such a tool, called HP mBuilder, for creating mobile Web user interfaces. This application allows users to manage UIs per protocol deployment, and is extremely useful when targeting multiple devices. It also includes a built-in simulator for visualizing the mobile UI on several devices. Developers build with UI elements rather than actual protocol tags, effectively supporting multiple protocols. The HP mBuilder application is currently available for Linux and Windows platforms. For more information, visit the mBuilder Web site.
Different Strategies Called For
User Interfaces for mobile Web applications are quite different from their browser siblings. However, many of the early experiences and skills developed at HP were subsequently folded into the HP mBuilder application and, by using it in conjunction with useful tips for producing better mobile user interfaces, developers can promote acceptance for new devices that the Internet continues to touch and connect.
Developers can also get deeper into the often subtle differences and access additional resources from Web sites or developer portals that some vendors support. For example, dspp the developer edge at the developers site is a portal to a wide variety of other reports and presentations for HP developers that provide specialized information to guide designing applications and interfaces especially for mobile devices.
Grace Hays is a Software Architect at Hewlett-Packard. She has ten years of experience in the computer industry, primarily in the Virtual Memory area of operating system design. Her current area of focus is in development tools for the mobile space.