|
(2) Use simple and familiar phrases for labeling
Telling people what will happen before they click through to a new
screen is a basic, long-established principle of Internet design[4]. It should also be
applied to the design for mobile phones, where the screen real estate is particularly
restricted. Simple descriptions should always be used instead of more enigmatic phrases. Thus users can simply find the information that they are
looking for.
(3) Use the <prev> or <exit> tasks whenever navigating in the backward
direction.
According to [5], The back button has become a fundamental part of the Internet. Users
accept that they might find themselves on the wrong track and have to go back a few steps
to choose a different path. If you link to a page the user has already visited (e.g., the
application's main menu), be sure to navigate to the page by popping pages from the
history stack instead of adding a redundant page to the history stack. This minimizes the
risk of history stack overflow on memory-constrained devices, which can result in the user
being unexpectedly returned to the subscriber homepage. Use the <prev> or
<exit> tasks whenever navigating in the backward direction. Don't use the <go>
task to navigate to a page that is already on the history stack.
[3][5] also provide the following design principles for Telephone based
access to Internet.
3. Design to reduce the operation/waiting time
(1) Assign the most commonly chosen action or most intuitive task to the accept
soft key.
Make it easy for users to select the most common action by pressing
a single key -- the accept (OK) key. Don't force users to move the cursor before
pressing the accept key (e.g., by making them navigate to some text anchor first).
(2) Ensure all decks are smaller than 500 bytes.
The download latency for very large decks (1500-2000 bytes) can be over
10 seconds. Wireless phone users perceive network latencies to be longer than they
actually are, because consumer-grade devices are typically single-tasking devices
(prohibiting users from performing other tasks on the device while waiting for content to
load). To minimize network latencies, keep each deck as small as possible. The recommended
guideline is 500 bytes or less per deck (encoded WML).
(3) Don't set a deck's expiration to a low value unless the content is highly
volatile.
Setting a short expiration time for non-volatile deck (e.g., static
application menus) may force users to reload the deck from the server even though the
deck is already in the browser cache. Applications that optimize deck caching are
perceived by users to be more efficient and less costly, since they minimize connection
times over the wireless network. Short deck expiration values should only be set for
highly volatile content (e.g., stock quotes).
4. Design to avoid Storage Limitation
(1) Avoid using Scripts, Event Handlers
Usual mobile devices have limitation of memory storage, CPU power
and so on, thus in many cases scripting are not supported. It should not be assumed that
scripts will always be executed. Contents should be readable even if scripts are not
executed.
(2) Avoid using Forms
Usual mobile devices support basic forms, but they don't have
keyboards like desktop PCs. Content authors should keep in mind that it will be hard for
users of mobile devices to input many characters. Since mobile phones don't have local
file systems, some features, which depend on local file system, such as file upload,
should not be used.
5. Others for convenient usage and error prevention
(1) Keep soft key labels to 5 characters or less.
Many devices cannot display soft key labels that exceed 5
characters, and will truncate or abbreviate any labels that are longer.
(2) Use Wizards instead of forms.
By using a single card for each input of information, the user can
follow a natural process of entering information. User studies show that wizards make for
a better user experience than forms. Finally, avoid having a separate 'submit' card. The
last 'ok' of the wizard should in fact be the 'submit' option. This avoids an unnecessary
additional click.
(3) Use the format attribute to constrain text input fields to only allow valid
character types
In some applications, text entry fields can employ character format
constraints. These guide users to enter the required information. For example, if
users must enter a credit card number of 16 digits, the entry field can be formatted to
accept 16 characters exactly. Other formatting is also possible; for example, the browser
can be limited to accept only numeric entries. Use format="NNNNN" for US zip
code fields.
(4) Assigning access keys via "accesskey" attribute
In general, it cannot be assumed that input methods which
consist
of a (full) keyboard and a pointing device such as mouse are available in mobile phones.
It is desirable that description for efficient use of input methods on mobile devices are
provided in contents. From this viewpoint, assigning access keys via "accesskey"
attribute (for A, AREA, BUTTON, INPUT, LABEL, LEGEND and TEXTAREA elements) will be
effective when it is available. This may improve accessibility of links or form related
operations.
But the use of "accesskey" attribute needs careful
consideration.
- In many mobile devices, available keys are limited. It cannot be assumed that all keys
in "full" keyboards are available.
- Available keys differ among mobile devices. For example, cell phones will usually have
"0"-"9", "*" and "#" keys, but the same assumption
cannot be applied for most pagers or mobile game machines.
- There may be some mobile devices that cannot use "accesskey" attribute at all.
For example, devices only for voice browsing will not use access "keys". Content
authors should not rely on access keys for navigation.
|
