Good usability requires that you customize your application for
each specific browser. I will talk about usability issues on the
UP.Browser, and the browser of the Nokia 7110. This should help you
to evaluate usability issues for other devices as well.
Guidelines for Nokia 7110
What follows is an overview of the interface for the Nokia 7110
WAP browser:
Entering Data on the 7110
If you have an <input> or a <select> element in your
code, you need to make it clear to the user how they can submit the
data in order to move on to the next logical step.
The only sensible thing to do in these cases is to provide a
link that will keep users going with one click:
<p>
Name please:
<input type="text" name="searchkey" value=""
/>
<a href="search.asp">Submit
data</a>
</p>
If you use <do> elements, the 7110 browser will interpret
it by adding an extra element in the menu triggered by the left
softkey. This is not good. Users will not immediately see this, and
so would be at a loss for what to do after they've entered the
data.
Forms
There are two types of form: wizard forms and elective
forms.
Wizard forms let users insert data one bit at a time.
Each card contains an input element. It's a good idea to use
Wizards when you can, since they let users focus on entering data
rather than navigation.
Forms implemented through a single card containing multiple
input fields are called elective forms.
It goes without saying that on the 7110, you should provide a
link to let users move from one card to the next, rather than using
<do> elements.
Menu Navigation on the 7110
Menu navigation is a straightforward way to let your users
access all the different parts of your application, laid out in a
tree structure.
The best way to implement this for a Nokia 7110 is by building a
menu as a list of anchors. For example:
<a href="#band" title="find">Artist/Band</a>
<a href="#song" title="songs">Title/Song</a>
<a href="#top" title="top">Top 20</a>
<a href="#new" title="new">New Releases</a>
<a href="#conc" title="live">Concerts</a>
Forcing users to do a lot of scrolling is not a good idea. If
you need to display more than nine or ten items, you should split
your links over several cards or decks.
Backward Navigation
The right softkey of the 7110 can only be used as a back button,
and is labeled as such. By default, it has no action at all. Some
sub-versions of the 7110 allow reprogramming of the back key with
<do type="prev">. Unfortunately, this is not the case
with all phones. The way to get the phone to do what you want
is:
<card id="mycard" onenterforward="#nextcard"
onenterbackward="http://logical_back">
Unfortunately, this has the side effect of spoiling the history
stack.
Never provide a label for the <do type="prev">
element. The 7110 will remove the Back label from the right
softkey, and instead create a new entry in the menu accessed
through the left softkey. This confuses users who expect to find
the back key in a well-known position.
Guidelines for UP.Browser
The Phone.com browser has a different interface from the Nokia
7110. The general idea behind the UP.Browser is that a <do>
element is mapped directly to a softkey whenever possible.
Users will only ever be one click away from performing a
main-path activity. Other activities will also be reachable in a
simple way. This is in sharp contrast with the Nokia 7110.
<do type="accept"> elements are normally used to support
main-path activities. They are also called ACCEPT buttons. Other
activities are supported through <do type="options">
elements (OPTION elements).
If you have a single main-path activity, for example, the best
you can do is to associate it with an ACCEPT button, which is
always bound to a softkey (usually mapped to Softkey1). This way,
your users are only one click away from the activity they are most
likely to perform.
If you have a single <do type="option"> element (or
OPTION button), this will be mapped to Softkey2. In the case of
multiple OPTION buttons, Softkey2 will display the label menu,
which leads to a pseudo-card that allows you to select the option
from a simple list (similarly to Softkey1 on the 7110).
Some UP.Browser phones support three softkeys. In that case, you
can afford an ACCEPT task and two OPTION tasks without the need to
go through an extra menu.
In the diagram, you can see softkey1 on the left and softkey2 on
the right, but this is not always the case. Softkeys occupy
different positions in different implementations of the
UP.Browser.
Entering Data on the UP.Browser
Unlike the Nokia 7110, the UP.browser does not require the
presence of a link after an input element in order to be usable. A
<do> element will work wonders there:
<do type="accept" label="Send">
<go href="receive.asp" />
</do>
<p>
name please:
<input type="text" name="username" value=""
/>
</p>
The data can be posted with just one click (on Softkey1). If you
insert a navigation link after the input element, as you should do
with the 7110, the mechanism will still work, but usability will
degrade. The construct that follows will require no fewer than
three clicks to post the data from the UP.Browser.
<p>
name please:
<input type="text" name="username" value=""
/>
<a href="receive.asp" title="Send">Submit
data</a>
</p>
Forms
Use <do> elements to navigate from one card to the next;
otherwise, the same guidelines for forms apply as did for the Nokia
7110.
Menu Navigation on the UP.Browser
If you implement menu navigation the same way as you would on
the 7110 (with a bunch of links), the UP.Browser will work
satisfactorily. Unfortunately, by doing so you'll lose a feature
that the UP.Browser supports to facilitate navigation for slightly
advanced users.
To demonstrate, the code below implements menu navigation in the
optimal way for the UP.Browser:
<select>
<option onpick="#band"
title="find">Artist/Band</option>
<option onpick="#song"
title="songs">Title/Song</option>
<option onpick="#top" title="top">Top
20</option>
<option onpick="#new" title="new">New
Releases</option>
<option onpick="#conc"
title="live">Concerts</option>
</select>
Here is how the UP.Browser renders the code:
The numbers on the left of the screen are shortcuts. If you
implement navigation menus this way, UP.Browser users will not be
required to scroll to the menu item of choice, since they can press
the number on their keypads and trigger the onpick event for the
corresponding menu choice.
Email TopXML