Creating a Usable WAP Application

In a HTML browser, the user traditionally has access to a number of navigation tools, including a back button, a forward button, a drop-down list of recently visited URLs, a Go field to enter any URL at will, and possibly a separate history or favorites pane. On a WAP device, only a few of these are readily accessible, and in a different way on each device. As a result, thinking about the navigation patterns for your application becomes more critical.

Backward Navigation

Navigating backward is important to an application because users tend to favor the Back operation for navigating out of an application. Users come to rely on and feel less apprehensive using an application that has good backward-navigation functions available. Allowing users to navigate backward permits leaving an application without having to return to the home deck. For example, if a set of applications is three menus deep from the home card, backward navigation will allow the user to easily get to the start of the set without having to renavigate through the first two to three menus. In some cases, backward navigation must be carefully considered and designed, such as prohibiting navigation behind password-protected cards. Also, remember that there is no inherent forward navigation with a WAP browser. Once a user navigates backward, she cannot then retrace her steps with a Forward button the way she can on a PC-based browser.

The following are some guidelines for how to handle backward navigation in your application:

• Always provide some kind of backward navigation.

• Map backward navigation to the next highest or most intuitive menu when direct backward navigation is unsuitable. Backward navigation might not always be practical. For example, if the user confirms an action, such as making a purchase or deleting an item, backward navigation should not redisplay the card asking the user to confirm the purchase or the list with the deleted item. Instead, the application should either return to the application's home card, a login card, or a card intuitive to continuing through or leading to an easy exit from the application.

  <do type="prev">
   <go href="loginstart.wml"/>
  </do>
  

  This example shows how backward navigation will not allow the user to retrace through a card that is beyond a password-protected area. In this case, the user must renavigate to the login menu.

• Never provide a label for a <do type="prev">. Providing a label will remove the Back label from the right soft key on the Nokia 7110. If no label is defined, a Back label will automatically be assigned to the right soft key. Define an appropriate URL when going directly back in the history is not suitable.

  <do type="prev" label="back">
   <go href="loginstart.wml"/>
  </do>
  

  This code will cause a number of problems on different devices. On the Nokia 7110, the BACK key will not be activated; instead a back option will be displayed under the Options menu. On the Phone.com UP.Browser, the back label will either render above the second soft key, or if there is already a <do type="options"> task defined, a label of "menu" will render above the second soft key and the options action as well as the prev action will be accessible from this menu.

• Provide backward navigation via <do type="options"> if backward navigation returns the user to a higher menu or the top menu of the application. Use the label Done to indicate that backward navigation will go back more than one step. This will render a soft key of Done on the secondary soft key on the Phone.com browser and will also add Done to the Options list for the Nokia 7110 browser.

• Empty the application history, when direct backward navigation is not possible. When it is impossible for an application to go backward, such as in the case of a confirmed action, the application should erase the history for that application.

  <do type="options" label="Done">
   <go href="#clear"/>
  </do>
  
  ...
  <card id="clear" newcontext="true">
   <onevent type="onenterforward">
      <go href="home.wml"/>
     </onevent>
    <p>
    </p>
   </card>
  

• If the user exits an entry field, it might be helpful to temporarily save the values of all or some of the variables. This can reduce the amount of information the user must enter in the future. For example, if the user entered personal information in an order form, it might be helpful to retain insecure information such as the name and address, so the user will not have to reenter this during the same browsing session.

Menu Items

When you are presenting a list of menu choices to a user such as email headers, news stories, or contacts, you should present a list of anchors, with each anchor on a line of its own with no more than nine items on each card. If you have a need to present more than nine choices, include a tenth choice, "more…", that links to another card of nine choices. This will prepare your code for WML 1.2 which includes an accesskey attribute that allows you to bind a number key on a phone to a link in the deck.

Building your menus this way also allows you to easily branch your code for the USER_AGENT and deliver the menu choices in a <select> statement to the UP.Browser from Phone.com.

Limiting Required Input

One of the most striking differences between a device with a WAP browser and a traditional Web browser is the facility for inputting data. Although on your desktop machine you seldom think about entering data, long URLs, or descriptions, on a phone even minimal data entry can be an arduous task and be a deterrent from your site. If users need to enter data every time they visit your site, they will simply not visit. There are a few approaches that can be taken to limit the amount of data a user needs to input on the phone for your site:

• Provide persistent storage for long or difficult-to-enter data strings such as names and addresses. Depending on the device and WAP Gateway, you might be able to store such information in a cookie. Or you might keep it locally in your own database and identify a user and associate her with her persistent data when she revisits your site.

• Never ask a user to enter his city and state. You can identify user's city and state by his ZIP code. By forcing an input field to the numeric mode with the following code, you make entry much less painful for the user.

  <input name="zip" format="5N" title="zipcode"/>
  

  Have your application then use this ZIP code information on the back end and look up the appropriate city and state.

$ret = &AppUtils::HTTPConnect(*HTTP,
"http://www.usps.gov/cgi-bin/zip4/ctystzip2","POST" $zip);

• If your application performs a search function, be sure to search on data that is not case sensitive and perform a pattern match or a partial match. This ensures that users do not have to be exact, nor do they have to enter their complete information to get a match.

This fact bears repeating: If users must enter a significant amount of data, or if they have to log in every time they visit your site, they will not return.

Building Data Entry Wizards

Now that I have established that entering data in and of itself is a painful process, if you must do it be sure to walk the user through the process of visiting each field that is required. On some browsers, if there is more than one input element on a card, each input element will render inline, and a user will be able to select each individual one to visit and enter data. Usability studies show that users are often unable to figure out whether fields are optional or required. The best solution when you require a user to fill in more than one <input> element is to split each element onto a card of its own and bind the accept action of each card to navigate along the chain of input cards. This will ensure that the user will visit all the input fields that are required:

 <card id="buy" title="order cd">
  <do type="accept" label="next">
   <go href="#add1"/>
  </do>
  <do type="prev">
    <go href="cnclcrd"/>
  </do>
  <p>
  Name<br/> First &amp; Last
  <input name="name" title="Full Name"/>
  </p>
 </card>

 <card id="add1" title="order cd">
  <do type="accept" label="next">
   <go href="#add2"/>
  </do>
  <do type="prev">
    <go href="#buy"/>
  </do>
  <p>
  Street Address
  <input name="street" title="Street Address"/>
  </p>
 </card>
<card id="add2" title="order cd">
  <do type="accept" label="next">
   <go href="#cc"/>
  </do>
  <do type="prev">
    <go href="#buy"/>
  </do>
  <p>
  Zip Code
  <input name="zip" title="Enter Zip" format="5N"/>
  </p>
 </card>