WAP Design

· Avoid large URLs: Users won’t see them, it increases download time, and it avoids potentially hitting a limit.

____________________________________________________________________________ Top

Bookmarking
· Try to make all cards bookmarkable: The user won’t understand why something isn’t
bookmarkable. In particular, try to bookmark:
· >Lists
· >Find screens
· >Display screens
· >If bookmark is in the middle of an entry wizard or form, remember to mark to the beginning of the form or wizard
· >Don’t bookmark silly things: If it doesn’t make sense, it probably will never be marked by the user.
· >Don’t bookmark edit screens: If the user is editing data, there is no sense bookmarking it. The only exception is useful screens like the final “enter stock quote” screen, where a user may want to go back and enter quotes.
· >Don’t bookmark transient data: It isn’t smart to bookmark an email.
· >Don’t bookmark action menus: For example, the email menu list.
· >Make titles context sensitive: If contextual data is associated with a bookmark, use it for
the bookmark name. Don’t make the user enter data. For example, don’t use “Stock” for
the name of a stock quote. If I bookmark “IBM” and “MSFT” then I will have to type a
name each time. The application has the name, call it “IBM Quote”.
· Make sure when you bookmark something, necessary navigation and data is available when returning to bookmark

____________________________________________________________________________

Subroutines
· >Use activities liberally to ease navigation: Don’t require the user to hit “Back” many
times
.
Cache Management
· >Don’t leave time-sensitive data in the cache (like stock quotes)

Cookies
· Use as needed

Alerts
· >Use them correctly:
· >Ensure that you use only 1 alert inbox slot: Make sure you use the same URL for all of your application’s alerts.
· >Ensure that the URL goes somewhere (for at least 24 hours): Make sure the user can go to the alert once it is in the box.
· >All alerts should have a short title, less than 10 characters:
· >Titles should not contain specific data (it will be lost): Don’t give specific data in the alert title, as they are combined. The paradigm is this is a title for a box, not data for the users. Thus if many alerts come in for the same box, only 1 alert is sent to the phone.
· >Titles can be no longer than 24 characters
· >Putting counts in the title is okay: This way, you can, for example, put the number of unread messages into the title.
· >Send new title counts without audio/visual flags: This keeps the counts up to date as the user goes through your alert items.
· >Alert URLs go onto lists: This is the list of alerts for this user. Thus, for example, if I got 4 emails, or 2 stock alerts, I should see the list of these displayed by the application when I go there.
· >Allow user to turn off or change beep settings: This isn’t supported on all phones, but is
nice when it is, so your application should take advantage of it.

Graphics
· >Don’t assume graphics are supported (use alt tags)
· >Make sure graphics line up
· >Use built-in icons were possible: They load faster.

____________________________________________________________________________

Display Cards Basics

Avoid <LINE> mode
Exceptions: Links or information that is only occasionally needed: Example, a header line for email stating whom the email is from. Most people won’t care as much about this. Another example is to show the name of a person in an address book, when also displaying all of their data.
·
Using Links in display cards
It’s okay to do it, but do it sparingly (For example, don’t use a display card for a choice card).
· When used for items within data being displayed
Link as few words as possible: If at all possible, don’t allow links to be so big that they wrap beyond 2 lines (For example, try to keep them shorter than 22 characters, allowing for the 2 brackets on a 12 character display).

Navigational Links
· Use navigational links at the beginning or end only, not within the data.
· Put them at the beginning if they’re typically used when starting to read the data.
(For example, the email header link going to a card that says who email is from and to whom cc’d).
· Put them at the end if they’re more often used after reading the data (For example, after reading part of an email you can link “[more]” to see more. Only needed at the end).
· They should be shorter than 12 characters
· If they’re longer than 12 characters, use <LINE> mode
· They should always act on the whole card, not some data within it (use links inline to the data for data links) (For example, don’t put the [call] link at the end for calling an embedded phone number. Instead, link the embedded phone number in the data).

500-800 characters total visible text
This includes links. Beyond this, use a “[More]” at the end to link to additional text. Use the first softkey for “More” if there are no other actions allowed on the data.

Where you control the data, avoid words longer than 10 characters
These words are hard to read on the display if they wrap.

Use titles where they add context to the data
For example, a stock display for IBM should say “IBM:” at the top. Don’t do it for email since there is no context to a message.

First softkey should navigate to the most likely place the user will go next and not
perform an action on the data
If the most common next place to go is to the next email, then make it “Next.” If the most common place to go after viewing a stock quote is back to get another stock quote, then make it “OK” and make it go back. Viewing a user’s basic address data may have a “Details” item to see more details. Don’t put actions like “Delete” on the first softkey, since it disrupts the user’s flow as they try to find a way to navigate without performing an action (such as pressing the “Back” key).

Second softkey should be an action item (such as “Delete”)
· “Menu” leading to a menu of actions and navigational options
· Secondary navigational option: “Done” to go back
· Display messages—Error/no answer required messages
· Softkey 1 should be “Ok”
· Softkey 2 should be blank
· Question messages
For example, “Do you like red or blue?” or “Are you sure you want to delete?”

· Softkey 1 should be the least risky option
· or a positive acknowledgment option if same risk
· or the most common option if no positive/negative distinction (for example, “do you want to delete email… ”, “No” on softkey 1, “Yes” on softkey 2.

· Softkey 2 other answer

____________________________________________________________________________

Choice Cards Basic Rules

· All choice cards should have a short title
· fewer than 12 characters (use <WRAP> not <LINE> if there are more)
· If the title is a long phrase, for example, Weather for Portland Oregon,” modify it to
be less specific, such as “Weather.”
· Titles cannot have more than 24 characters. Truncate at 22 characters and put “… ”
after it (for example, “Research Triangle Pa… ” ).
· Titles can have colons after them
· No more than 9 items, 10th can be “More”

Types of choice cards
· List of data (for example, email messages)
· Navigational only (for example, home card)
· Action and Action/Navigational
Used to act on an item (for example, deleting an email), or going back to email inbox
while within an email
· Pick Option
Used for picking an option (for example, the color of a house)
· Change Option
Used for changing an option (for example, a preference or predefined value)
· Don’t use “… ” to indicate you are going somewhere: All menus go somewhere, so don’t
say “more… ” or “Delete… ” or “View… ”.

List of data
· Sort contextually: May be by type, date, or whatever makes sense.
· First softkey should be “View” to see more
· Second softkey should be:
· Action item (like “Delete”)
· “Menu” leading to a menu of actions and navigational options
· Secondary navigational option
· “Done” to go back

Navigational
· Sort by most-used paths or alphabetically if it is a random list
· First softkey should be “Ok” to go to next menu
· Second softkey should be:
· “Menu” leading to a menu of other navigational options
· Secondary navigational option
· Blank: Don’t put back on navigational softkeys

Action/Navigational type of choice card
· Sort by most used actions
· Don’t put up Action items when they’re not valid
If you have a list of emails and you have a “more” at the bottom to see more email messages
listed, make sure that when “Menu” is chosen on “More” you don’t have “Delete” in
the menu.
· First softkey should be “Ok” to see more
· Second softkey should be:
· Action item (for example, “Delete”)
· “Menu” leading to a menu of actions and navigational options
· Secondary navigational option
· “Done” to go back

Pick Option
· Sort contextually: By type, date, or whatever makes sense.
· First softkey should be “Ok” or “Save” or “Next”
· Second softkey should be “Cancel”
· Try to put the common or default item first, or pre-select the common or default item
· If random input is allowed, put an item at the end called “Other”

Change Option
· Sort contextually: May be by type, date, whatever makes sense.
· First softkey should be “Save”
· Second softkey should be “Cancel”
· Should come up selecting the old value

____________________________________________________________________________

Entry Cards Basics

· Entry Card titles should be short
· fewer than 12 characters (use <WRAP> not <LINE> if there are more)
· If the title is a long phrase, for example, Weather for Portland Oregon,” modify it to
be less specific, such as “Weather.”
· Titles cannot have more than 24 characters. Truncate at 22 characters and put “… ”
after it (for example, “Research Triangle Pa… ” ).
· Titles can have colons after them

· Set proper capitalization

· Use “Mm*” format to obtain sentence-like formatting.

· Use formats where that enhance usability. For example, to get hours and minutes use format to get “5hrs30mins” so user sees words “hrs” and “mins”.

· Avoid text entry where possible
· Use choice lists
· Use fewer entry elements if possible
· Make entry elements optional

· Use links in titles to switch entry modes
For example, when finding names, use a link to change the mode from find by first name
to find by last name.

· Use a wizard layout for 2-5 entry items, otherwise use a form

· Make form entry walk down the fields
After the user enters one field, position the cursor to the next field after accepting it.

· Break up big forms to multiple decks
This makes the user experience seem less intense, and prevents lots of data from overflowing buffers.

· Use only one softkey
· “Ok” if no more data is needed on a single entry card
· “Next” if more data is needed or going to confirmation card
· “Save”, “Done”, or “Send” or similar title if at the end of a wizard
· “Ok” if at the end of a wizard for a single form entry: Such as end of putting in time
via a wizard, for a form for a airline reservation.

· Don’t hide password entry
It’s a phone! Turn away from others. Don’t make it harder for every user.

____________________________________________________________________________

Methodology for Designing Usable Applications

This section describes a methodology developers can follow to design great applications.

Application Goals
When designing a new application for a phone browser, the application should strive to meet the
following goals:

· Intuitive navigation
A good application design begins with a natural flow. Users think in terms of the problem that they are trying to solve, and not in terms of how to use the tool to solve the problem. The tool needs to be transparent to the user. Whenever the user has to stop to figure out how to use the tool, they get sidetracked and frustrated – introducing the risk that they won’t find their way, or will forget the problem they are trying to solve. Intuitive interfaces are easier to sell, easier for users to get up-and-running, and less likely to render the product useless, causing it to be returned or to become “shelfware.”

· Consistency
A good application leverages consistent metaphors to make it easier for users to intuitively discover how to perform activities. Whenever possible, these consistent metaphors should be used to keep the application simple.

· Key activities require the fewest operations
An application will have many features, all of which are important, but only 15-20% will be needed most of the time. For example, a user of email may read dozens of emails on a phone before responding to a single email. Understanding what features or activities are key to the user and reducing the steps to accomplish the activities will make the user experience much more pleasant.

· Solving new problems should be highly discoverable
Whenever the user is performing a new task that they haven’t done before, such as composing an email rather than reading one, they should be able to figure out how to do it without external help from other users or manuals. The placement of these less common features is not in the main path, but should be a short step away from the main path so that they can be found and used when needed.

· Unusual operations may not be as discoverable, but are easy to remember
Should the user branch out and use a rare or complex operation, the interface will not be as discoverable but will need to be easily remembered for future uses. For example, maybe a user has to read the manual to determine how to forward an email, a rare operation. Once they learn how, they shouldn’t have to refer to the manual two months later when they need to forward an email again. Instead, the first experience should flow or appear in such a way as to be easily remembered by the user.

Methodology Overview
The best methodology for developing a great application is to follow these steps:
1) Develop Profiles of Your Users
2) Break down your application into problems you solve for your users
3) Determine the tasks required to solve these problems
4) Prioritize tasks
5) Layout your user interface
6) Test your user interface

____________________________________________________________________________ 

Build Profiles of Your Users

If you are building a content application, you may think of your user as a consumer. If you are
building a business application, your user may be a mobile corporate user. If you are building a
vertical application like dispatch, your user may be a truck driver.However, this isn’t enough to get your application right. You need to try to build a model user with whom you can work while designing your application. Try to find characteristics that differentiate your users from a “class of users.” This will help you to better target your users.
With these kinds of real profiles you can start to better visualize what kinds of habits and behaviors
you will want your application to support and work around.

Steps to Break Down the Problem
Use the following steps to design a good user interface:
· Identify consistent metaphors
Consistent metaphors often don’t even come from your application, but are ingrained
into the user model of the platform the application is running on. There are two classes
of consistent metaphors:
· Usage metaphors
Standard usage metaphors, such as using softkeys to make selections.
· Accelerator metaphors
Secondary usage metaphors such as press-holding a number key to select and perform
the Accept action on a choice list.
It is often useful to decide if the metaphor is best used for more important or less important
activities. For example, the Accept key is for important activities, while softkey 2 is
used for less important activities.
· Identify user activities
The first step is to determine all of the activities your users will need to perform with your
application. Typically, these activities can be translated into features, each requiring
certain information or steps to be used. At this point in your application development, all
you need to do is to identify the activities, ignoring the features or steps.
· Define the problem being solved for each activity, and the expectations of the user
The problem to be solved for the user will help you understand better how to evaluate
the value of the final solution. The expectations of the user should be understood in
terms of how the user may expect the feature to work within other similar models, such
as their work life or how the PC performs the function.

____________________________________________________________________________ 

Classify activities

Next, you should classify activities into the following type:

· Required Activities (every user must perform)
Required activities are activities that 100% of your users will have to perform when
they use your application. These types of activities represent a barrier to use, and
should be removed or avoided if at all possible. There are two classes of required
activities:
· Setup activities
These are one-time activities such as installation. For example, you can’t use a
POP3 mail client without telling it your email address and server at least once.
· Single-purpose applications
If your application solves only one activity or problem, then 100% of your users
will perform this activity. UP.Homepage is an example of a required activity that
100% of users will have to go through to use the activity. The preference utility is
an example where no main path can be teased out of the system, but setting any
preference becomes the activity.

· Main Path Activities (high use activities)
The main paths of a user interface are those that most users traverse regularly for
common activities. An activity is only a main path activity if you can say that 80% or
more of the users will perform that activity when they use the application. These
paths must be very smooth and intuitive so that the user can quickly solve the common
problems without any clunky steps. Reading an email is an example of a main
path activity.

· Semi-Main-Path Activities (high use by large segment, but not all, users)
Occasionally, you will find an activity that is used 80% of the time by a large class of
users. These should also be considered main-path activities. For example, 50% of
email users will delete 80% of email after they read it (those who like to manage
their inbox). For this large class of users, deleting email is a main path. And since it
is also a large segment of users, the activity must be considered as a semi-main
path activity. These activities need to be easy for these users, but shouldn’t be an
impediment for the 50% of the users who never use them.

· Side-Path Activities (activities used occasionally by most users)
Side paths are used for activities that most users will use, but only occasionally. You
should be able to say that 80% of the customers will use this activity at least 10-20%
of the time that they use the application. Replying to an email is an example of a
side path activity.

· Rare-Path Activities (activities never used by most users)
Rare paths are those that most users will never use, but are provided for power users
or users with vertical market requirements.
· Sort Activities within each classification
Within each classification above, sort the activities in terms of how often a user may use
the metaphor.
· Define a hierarchical tree of activities
Lay out a hierarchical tree of all activities with the activity of the user entering the application
at the root, and each sub-activity below this.
· Sort the hierarchical tree of activities
Make sure each level of your tree is sorted based on the likely amount of usage for each
activity.
· Design user interface based on activity types
Starting with the most important activities, design the user interface to insure that the
higher priority activities are always available with the fewest (or no) keystrokes. The rest
of this section will describe how this is done.
· Perform user testing on design
The final step is to ask users to perform the activities, and then without helping them,
watch to see how intuitive your interface is. If you have designed the interface well, they
will have no problems. If not, you will need to smooth off the rough edges.

____________________________________________________________________________

UP.Browser User Interface Design Principals

Principals
Use the following principals when designing your user interface:
· Users value their time
· Top activities in all applications will not take more than 2 steps
With each extra step we lose 50% of the users. For example, replying to an embedded
reply currently takes 4 steps.
· Application design should be optimized for speed
It should take advantage of caching and attempt HDML compactness.
· Voice is king
Although phones have many limitations, they have one great advantage: they can call.
SEND should always do something smart anywhere in the application. Examples:
· SEND from the list of names in the PIM should call (1 step)
· SEND from any email (even just pointing at the header) could:
· Dial if number is provided by the application
· Check the local address book for the email user name and dial if found
· Check UP.PIM and dial if the email user name is found
· Check InfoSpace and dial if the email user name found
· Relevance
Screen real estate is limited. The most relevant information must always be shown first.
Example: the time stamp is not the most important information in an email header.
“EZReply” is not the most important part of an embedded reply.
· Discoverability
Users must be able to figure out what to do without ever reading the manual. Hidden options
can only be accelerators or expert user features. Example: keypress-and-hold is
not discoverable.
· Input – not
Mass market phones have limited input capabilities. Input will be minimized better with:
· Preset choice lists
· Search using first 1-2 letters of keyword
· Stickiness: remembering what users did last time
· Duality: using PC to do the input, setting up preferences
· Smart text input such as AIKI
· Consistency
Users build a model of the environment in their minds. To be easy to use the environment
must be consistent and predictable.
· Static Windows
Scrolling Times-Square mode is a necessary evil. It should only be used when an “at-aglance”
list makes the applications easier to use.
· Non-destructive exploration
As the name says, users must be able to explore without breaking anything. Irreversible
actions must be obvious or undoable.
· Printing
Most applications can be enhanced by the use of the print to fax capability. Computers
did not replace paper, they increased paper usage!
· Push, push, push
Phones are unique devices, always with the user, and always on (digital phones anyway).
Real time information is a key part of the value of an UP.Phone. Most applications
should leverage push capabilities by alerting users of important events in real time.
· PCs are good companions
Most users have Web access. Allowing settings and preferences to be edited from the
Web helps minimize input and reduces complexity. Access should be through UP.Web
and should not require any further authentication.
· Actions are verbs
Soft keys should be used for actions. Actions are verbs: Delete, Skip, Fax, etc.
· Back should go where the user thinks it should go
The Back key must take the user to a logical and consistent place in the application.
Don’t let the user go in circles, since most users can’t find their Home key.
· Accelerators are for advanced users
Accelerators are often non-intuitive mechanisms that make the interface even more productive
for advanced users. Once learned, such accelerators enable a user to solve
problems even more quickly than before. Accelerators should never be the only way to
perform an action—there should always be more intuitive ways (albeit with more steps)
to solve the same problem. One example of an accelerator is the push-hold of a number
key to select the “Accept” button for a choice item. If the user doesn’t know the accelerator,
they navigate to the choice and select the soft key – very intuitive. If they know
the accelerator they can reduce these two steps into one step.
· Utilize preferences as rarely as possible
Most users will never visit or set their preferences. Defaults for preferences must be designed
around the most common user models. Whenever possible, a default behavior
should be used instead of preferences. If a preference must be used, then it should be
easily discoverable by users.
· Share existing modules whenever possible to maintain consistency
If the same activity can be reached from separate mechanisms, share the user interface
for each. This promotes user interface consistency and reduces development effort.