|
1. Goals
2. Key Philosophies
3. Phone Characteristic Assumptions
4. Basics
5. Bookmarking
6. Subroutines, Cache Mgmt,
Cookies, Alerts, Graphics
7. Display Cards Basics
8. Choice Cards Basic Rules
9. Entry Cards Basics
10. Methodology for Designing
Usable Applications
11. Build Profiles of Your
Users
12. Classify Activities
13. UP.Browser User Interface
Design Principals
____________________________________________________________________________
Top
Goals
· Enable user friendly applications
for the Phone.com Platform
· Establish look and feel suggestions
for common operations
· Help developers design great applications
This Article is a collection of user interface
guidelines that will help in designing effective
applications
The implementations are targeted to
HDML developers. However, the UI guidelines
are also applicable to WML applications, since
HDML and WML share the same basic UI model.
Key Philosophies
When developing an application for a phone,
the following philosophies should be kept
in mind:
# Usability is more important due to device
constraints (display size, limited input)
Usability is important on any device, but
this is especially true for small devices
whose constraints make it even harder for
the user to establish their context and options.
# It’s a phone first
Most of the phones running browsers today
were designed first as a phone. The browser
was ported to it later. Also, most users purchase
phones for their phone characteristics first,
such as size and voice quality, and the browser
comes second. Users are unlikely in the early
days to replace their phone if they don’t
like how an application runs on their phone.
They will simply stop using that application.
# Phone browsers will be used for information
retrieval and vertical applications, not browsing:
Mobile users access their phone’s browser
for quick data access on the fly. When they
want to browse, they will go to their PC.
Vertical users will run vertical applications
on their phones, such as dispatch applications.
# Low-bandwidth: Many phones will have low-bandwidth
data characteristics. Even when carriers develop
high-bandwidth wireless solutions, phones
will still utilize less expensive low-bandwidth
solutions.
Assume data comes across in small chunks to
the user.
# Entering text is always hard:
There has yet to be invented a mass-market
consumer-class data input technology forc
phones. Most phones only have a phone keypad,
and your application should try to avoid data
entry, especially textual, whenever possible.
Too much data entry means that the user will
not return to your application.
#Airtime has a cost:
Most systems charge the user for each round
trip in some form. If it is a circuit-data
network, like most implementations in 1999-2000,
then the user will pay for the data like they
pay for a phone call, getting charged by the
minute. When packet technology becomes widely
deployed, and for packet networks currently
available, users will be charged either by
the packet, or a flat rate. Until flat-rate
packet fees becomes a standard competitive
position in the market, you should assume
your application should try
to work with as few round-trips to your web-site
server as possible.
# Every key-stroke costs usability:
Users will get lost in applications. If the
main value of your application doesn’t
expose itself quickly, they will not use your
application. Try to organize your application
to be as flat (hierarchically) as possible,
and ensure that the high-value areas of your
applications are exposed immediately or with
very few keystrokes.
#Displays are small:
Don’t develop your application for the
larger displays of specialty phones. These
phones will exist, but the mass-market phones
with browsers will have small displays (averaging
4 lines by 12-16 characters). Applications
developed for small displays tend to look
and work great on large displays. Applications
developed for large displays tend to look
and work very badly on small displays.
_____________________________________________________________________________
Top
Phone Characteristic
Assumptions
To help you profile the target phone, we recommend
you make the following assumptions:
· 4 lines for displaying content
· Softkey labels are visible at the
bottom of the screen
· Most phones don’t support more
than two softkeys
· First softkey is easy to select
· Second softkey may be harder to select,
but will be there
· “Back” is hard-mapped on
every phone
· “Up/Down” is hard-mapped
on every phone
· “Right/Left” may not be
supported on every phone
· “Home” will exist, but
may be hard to find
· “Marking a Site” will exist,
but may be hard to find
· “Browser Menu” will exist,
but may be hard to find
· “Alerts” will be supported
on all phones
· Browser-initiated phone calls may
not return to browser after the phone call
· UP.NetBrowser and UP.Browser will
both exist in the market
· Most phones support press-hold bookmarks
· Phones with fixed and proportional
fonts will both exist in equal numbers in
the market
· Some phones will support page scrolling
· Almost every phone will support <LINE>
mode, but may display differently
· Most phones will support #’s
on choice entries, but not all
· All phones will support links
· Most phones will support text formats
· Some phones have T9, others have
Smart mode, some will have only Alpha mode
· Triple-tap may work differently on
different phones
· Most phones are text based, some
support graphics
· Most phones support mapping the “Talk”
button
· Most phones don’t have separate
“Back” and “Clear” buttons
· Softkeys are 5 characters wide
· Not all phones support multiple beep
settings for alerts
General Basics Rules
· 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
____________________________________________________________________________
Top
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.
____________________________________________________________________________
Top
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 acknowledgement 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
____________________________________________________________________________
Top
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
____________________________________________________________________________
Top
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.
____________________________________________________________________________
Top
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
____________________________________________________________________________
Top
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.
____________________________________________________________________________
Top
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.
____________________________________________________________________________
Top
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.
|
WAP