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.