Mobile Internet sites are not as easy to use as their computer-targeted Web-site cousins, due to smaller screens, more difficult text input, and a wide variety of user situations. Despite these factors, industry experts agree that mobile access to Web sites needs to be more usable than computer access. Although there are many resources from browser manufacturers, carriers, and industry organizations available to achieve this (see design reources at the end of the article), severe design mistakes continue to be made.

An unusable site can prevent users from being able to perform their tasks. A salesperson might simply call the main office to have somebody else do order entry if it's not simple to carry out on the mobile device. A consumer might decide that there is no useful information on a site. I recently reviewed a site where all I saw was the company logo; there was nothing else I could see to do. It took me 90 seconds to figure out what to do to enter the site. That's about 85 seconds more than your users will be willing to spend, and they'll be gone. When the site is usable and useful, users return ­ which means more revenue for everybody involved.

Web Navigation
One of the major aspects of the user experience of a Web site is information architecture: the distribution of information and functions across the pages within a site. A well-designed information architecture will allow users to understand how to find information, both in the first visit and in future visits. In short, information architecture is a key driver to usability.

Computer-targeted Web sites generally aid user navigation through the information architecture with some sort of navigation bar, which generally provides links to major site components as well as the home page.

Backwards navigation, the tools that allow users to move appropriately to previous screens, is often overlooked. Users frequently want to return to a page they've already visited, especially when they've pushed the wrong button. When designing for the computer, the general rule of thumb is to always provide a link to your site's home page, and perhaps, to the subsite's home page. This is generally accomplished with a navigation bar.

Some sites provide a "Back" link on the page; HTML doesn't provide much more backwards navigation help than this. Fortunately, the rich visual context, large screen size, and operating system information help users return to where they've visited. However, when site designers need to display "Do not use the 'Back' button," a language limitation (or implementation flaw) is revealed.

Mobile Web Design
Devices and languages enabling mobile access to the Web have a lot in common ­ most notably, smaller displays, the capability of displaying only one screen or piece of information at a time, slower speeds than their wired equivalents, and the well-known limited input capabilities. These aspects make Web sites on any currently available mobile device (even the Pocket PC) appear not like a set of windows, but instead, like a series of screens. The best analog in the computer desktop world is a wizard ­ a series of screens with buttons labeled "Back" and "Next" that help you complete a task. Software installation on the computer is usually designed with a wizard user interface.

The wizard look and feel of mobile Web sites, combined with menu and link selection, has led users to perceive a mobile Web site's information architecture as a tree. Following a link or selecting a menu item selects a branch of the tree; going back goes up one level in the tree. This understanding is not explicit ­ I've never heard a user in a usability test describe a site as a tree. However, users' behavior and comments make clear how (at least behaviorally) they understand the site. If a site has poorly implemented navigation, users will get lost. The tree will become a freeway interchange. If a site has well-designed navigation ­ particularly backwards navigation ­ users gain the mental model of a tree and can find their way around.

Developers of mobile platforms realized that a nonwindowed, small-memory environment required more sophisticated navigation control. AvantGo, for example, supplements standard links with the PODS URL, pods://avantgo/back. This will take the user one page back in the history stack. Similarly, WML has the attribute, task=prev. These tools allow developers to create links labeled "Back" and have them be the same as if the user had hit the actual "Back" button.

Perhaps the most important aspect of designing backwards navigation is this: if you provide a "Back" control on a page, use the language's built-in back function.

Do not link to the previous page's URL. First, doing so guarantees a server hit, at the cost of your site's perceived speed and the user's money. Second, it adds complexity; if the user uses your hard-coded back link, then switches to the browser's "Back" button, the first instance will take the user forward one step (to where the hard-coded back link was). Third, it will generate false hits, clouding your server's Web tracking. Finally, your link will likely be less accessible than the browser's "Back" button. After all, the browser manufacturers know that the browser control used 80% of the time is the "Back" button.

In a windowed environment, "OK" is generally used to mean "close this screen." Whether this is the best label is debatable, but it's certainly the standard interface. On the Pocket PC interface, there's an "OK" button available in the top right of the screen ­ the same place we find a "Close" button on a Windows window. However, don't use "OK" to mean "I'm done with this screen, please take me back." Use "Save", "Close", or "Done".

PDA Navigation
When designing Web-site information architecture and navigation for a PDA or small handheld computer like Pocket PC or Palm OS, the device's built-in browser has a "Back" button, just like the desktop browser. Based on form factor, browser tools, and language capabilities, the differences in navigation design between computer-targeted and PDA-targeted Web sites are:

1. Avoid navigation bars. They take up too much space. Instead use "bread crumb" information, identifying the part of the tree the user is at. For example:

   Home -> Weather -> Tampa, FL

2. Avoid "Back" links or controls. The user will have to search for them, they take up valuable screen space, and you'll have to monitor the platform (e.g., AvantGo) to determine which language-specific "Back" function or URL to use.

Phone Navigation
Phones are usually more restrictive than PDAs, and they have more implementation differences between languages and devices. A browser on a PDA will provide its own buttons, but a browser on a phone will use the phone's hardware buttons where available and appropriate. For example, Openwave uses the phone's "Clear" (usually labeled CLR) button both for text editing and backwards navigation. The advantage of this approach is it does not use valuable screen space. Nokia instead uses the right softkey as "Clear" or "Back", depending on the context. This has the advantage of consistency across phones and with the phone's native user interface.

Different phones currently support WAP, J2ME, and a variety of HTMLs, including DoCoMo's i-mode. A variety of companies, including Microsoft and Pixo, are using "full" HTML. Currently, the most common in the U.S. and Europe is WAP (and also Openwave's HDML, which is largely the same).

WAP's language, WML, provides the "Back" function discussed above (task=prev), as well as an event that catches when the user enters a screen backwards ("onenterbackward"). Openwave provides some extensions that give the designer even more tools to help the user.

Unfortunately, the rendering differences between Nokia (the largest phone manufacturer) and Openwave (the largest browser manufacturer) are large enough that a site needs to detect the user's browser (and phone type) and render the appropriate content for it. For example, if you do not explicitly code a prev event, Nokia's right softkey will be blank, and the user cannot navigate backwards at all. Don't bother coding the event if you detect an Openwave browser, as CLR will always work ­ so you can reduce the download time by not including it.

If there's a page that the user should not revisit ­ for example, a deleted e-mail, a password, or out-of-date information, use the "onenterbackward" event to redirect the user to a more appropriate place. In some cases, this is simply a matter of refreshing the information.

Openwave has created "activities", which are essentially subroutines. The user follows a link, which spawns an activity. After performing some task, the user might complete a transaction, which in code exits the activity. Everything that the user did in the activity is removed from the history and the cache. This also frees up the device's limited memory to cache things that the user may actually want to back into. Activities are a powerful tool, but there are a variety of tricks that can be played on the site's server to mimic the end result. Investigate using the same URL for a series of screens or manually removing screens from the cache.

The "bread crumb" trick used on PDA and PC Web pages doesn't work on the phone; it takes up too much space. However, a link or command that allows the user direct access to the site's main (home) page does. Don't call it a home page, as many browsers have a home command that takes the user to a different page. If at all possible, returning to the site's main page should exit an activity or perform the functional equivalent.

Consider the case of ordering airplane tickets: you select the date and cities of travel, select the ticket, verify your credit card information, and hit "Submit". What happens when you hit back? If the site was implemented for an Openwave system, the ticket purchase process was within an activity, and "Back" would take you back to the first screen. If the site was more generally targeted, the "submit" card would have an "onenterbackward" event, and the screens within the process would all have the same URL. "Back" from anywhere within the ticket purchase process, or just afterwards, would take the user to the beginning of the process. And as strange as it sounds, jumping to the beginning of the ticket process is perfectly natural when you're using it.

Design Resources

WAP Forum General Content Authoring Guide: www.wapforum.org/what/informal.htm

Openwave Usability Guidelines and Application Style Guides: http://developer.openwave.com/resources/uiguide.html

Sprint PCS WML Style Guide: http://developer.sprintpcs.com/index.cfm

AvantGo Style Guide http://avantgo.com/support/developer/styleguide/styleguide.html