Genie 7110 User Manual

Genie Application Style Guide

(For Openwave™, Nokia™ Model 7110™, Model 6210/6250™, and Mitsubishi™ Trium™ WAP™ browsers)

Openwave Systems Inc.

800 Chesapeake Drive Redwood City, CA 94063 http://www.openwave.com

Release 1.0, February 2001

LEGAL NOTICE

Copyright © 2000 –200 1 Openwave Systems Inc. and Genie. All right s r e ser ved. Use other than for internal purposes, reproduction, modification or distribution without prior written authorisation by Genie is

strictly prohibited. Openwave, the Openwave logo and the “UP.” family of terms are trademarks of Openwave Systems, Inc. Nokia, Model 7110, and

Models 6210/6250 are registered trademarks or trademarks of NOKIA Corporation and/or its affiliates. Mitsubishi and Mode l Trium are registered trademarks of Mitsubishi Electric and/or affiliates. “WAP Forum” and “W@P” and all trademarks, service marks, certification marks and logos based on these designations are marks

of Wireless Application Protocol Forum Ltd. All other trademarks and registered trademarks are the properties of their respective owners.

1: Style Guide Over view 1

Organisation of this Guide 1 Why Specialise? 2 Testing on SDKs 2

: Usability Design Philosophies 5

Creating Usable Applications 6 Testing the Design 7

: Navigation Guidelines 15

4: Menu Navigation 25 5: Making Phone Calls from the Browser 33 6: Using Multiple Se lection Lists 37 7: Backward Navigation 39 8: Displaying Text 45

9: Data Entry Queries 51 10: Formatted Entry Fields 55 11: Forms 59 12: Icons and Images 65 13: Cache 67 14: Cookies and Subscriber ID 69

February 2001 Genie Application Style Guide iii

Contents

15: Labels and Links 71

A: Identifying the Browser 73 B: Differences between Browser Types in Same Class 77

iv Genie Application Style Guide February 2001

Chapter 1 Style Guide Overview

This document gives developers comprehensive guidelines for developing highly usable applications that run on Genie supported WAP browsers: the Openwave Mitsubishi (Nokia 7110, 6210, and 6250) browser. This guide considers various situations and possibilities, offers the most usable solution, and provides sample code.

Usability tests have shown that it is not possible to write a single usable “generic” version of an application that will run well on different types of mobile browsers. For this reason, this document is written to help developers create optimised applications to run on the Openwave, Mitsubishi, or Nokia browsers.

 Trium browser, and the Nokia Models 7110, 6210, and 6250

 browser, the

Organisation of this Guide

This guide begins by outlining some usability philosophies and then gives detailed guidelines on navigation, selection lists, text display, forms, alerts, and many more topics. Each section that gives guidelines looks at the topic from four points of view:

• Shared feature set for creating WAP applications. These recommendations apply

to the Openwave, Nokia 7110/6210/6250 and Mitsubishi Trium browsers when developing usable applications. These guidelines address the shared feature set, that is, the features that are supported on all of the browsers. Because the browsers interpret the W AP standards diff erently when displaying data, this section outlines the approach that will work on all of the browsers.

• Openwave usability. These guidelines explain how to create the most usable

applications for the Openwave browser. Use the Openwave guidelines in conjunction with the shared feature set guidelines. Code samples may employ the Openwave extensions to WML to provide adv anced function ality. These extensions are available to applications running on Openwave handsets through the Genie gateway.

• Nokia usability. These guidelines explain how to create the most usable applications

for the Nokia 7110 and Nokia 6210/6250 bro wser. Again, use the Nokia guidelines in conjunction the shared feature set guidelines. Althoug h the Nokia e xamples are based on the Nokia 7110 browser, they apply as well to the Nokia 6210/6250 browser. The few exceptions are explicitly labelled as “Nokia 6210/6250 only”.

February 2001 Genie Application Style Guide 1

Style Guide Overview

Why Specialise?

• Mitsubishi Trium Usability. These guidelines explain how to create the most usable

application for the Mitsubishi Trium browser. Again, use the Mitsubishi guidelines in conjunction with the shared feature set guidelines.

• Appendix A provides informa tion on how to distinguish b etween various browsers.

The information in this document derives from usability tests, knowledge of the capability of the WML, and testing applications on a variety of phone models and SDKs.

Why Specialise?

The WAP language specification for the Wireless Mark-up Language (WML) can be variously interpreted, and devices with browsers from different manufacturers exhibit differences in display and behaviour. Although the WAP Forum is in the process of refining the language specification, developers have an immediate need for how to build the best applications for browser phones on the market today. Howev er, browsers interpret some of the same WML features differently. A main goal of this guide is to help application designers and developers understand and work around these differences.

A usable application is one that lets users achieve a goal with a minimum of keypresses and without incurring extensive charges. The most usable applications are written for a specific browser. “Generic” applications are developed to the “lowest common denominator”, a subset of WML that works on multiple browser phones. However, because this subset is quite small, “generic” applications are more difficult to use than applications customised for a specific browser.

This guide encourages developers to capitalise on the unique features of the Openwave, Nokia and Mitsubishi Trium browsers. The entire industry benefits from excellent usability on all devices.

Testing on SDKs

When developing to the features that work on the Openwave browser and the Nokia browsers, use the two SDKs:

• The Openwave WAP-compatible SDK. The UP.SDK 4.1 can be downloaded from

http://developer.openwave.comhttp://www.developer.phone.com/ at

no expense.

• The Nokia WAP Toolkit. The Nokia WAP Toolkit can be found at

http://forum.nokia.com. In addition to testing the applications on the SDKs,

test the application on the handsets to ensure that it looks right and works correctly.

2 Genie Application Style Guide February 2001

Style Guide Overvi ew

Testing on SDKs

• Mitsubishi Trium. There is little developer documentation on the Mitsubishi Trium

WAP browser, and no known full simulator or SDK product av ailable at this time. The device has not been through interoperability tests. The guidance for this browser is therefore based on observation of the behaviour of phones containing the M itsubish i browser (version 1.1.a) based on how the device renders the content of a sample set of applications. Indeed two dif ferent beha viours ha ve b een noticed with the two d iffer ent browsers both returning the same user agent string. The advice found herein will produce applications which are usable on both observed devices. The differences between those devices, and how they may be differentiated in software is provided in Appendix B for those developers who may wish to make their applications more specialised. There may be further versions of the browser reporting the same user agent with different behaviours, thus it is important to test all available versions of the handsets.

February 2001 Genie Application Style Guide 3

Style Guide Overview

Testing on SDKs

4 Genie Application Style Guide February 2001

Chapter 2 Usability Design

Philosophies

Keep in mind a few design philosophies when building an application for a WAP browser phone. The user’ s e xperience with an ap plication may determine wh ether or ho w o ften the user revisits the application.

■ Usability is critical.

Device constraints limit both navigation and the amount of content that a handheld device can display; further, data entry may be difficult. Take extra care to make the application usable in this constrained environment, or users will not use it.

■ Most devices are phones first.

Most devices on the market today have added the browser as an afterthought. Neither the hardware nor the user interface reflects reasoned planning for the browser from the inception. Some features may be more di fficult to use on one phone than another.

■ Mobile handsets will be used for information retrieval, not browsing.

Users of WAP browsers will not “browse the Web,” as they do with a PC, because the amount and nature of content is scaled down for the handheld device. Phone applications will most commonly be used for quick information retrieval, not for general browsing and research. Phone us ers tend to be les s technical and in more of a hurry to get to the data they seek.

■ A phone is not a PC.

The phone has features that a PC does not, such as the ability to integrate voice, data, and alert features. Design applications that address user interaction models, screen size, and screen context. When designing the UI, keep in mind that there is greater variability among phones than PCs.

■ Airtime costs money.

Most networks charge the user by the minute for brows ing on the pho ne. Assume that users will avoid expensive b rowsing sessions.

■ Minimise or avoid text entry.

Entering text on the phone keypad is tedious. Try to use alternative methods, such as remembering previously entered text or data, personalization, and selection lists.

■ Most users will avoid complex applications.

Applications must be well organised with a shallow menu structure so that the user can get to the value quickly.

February 2001 Genie Application Style Guide 5

Usability Design Philosophies

Creating Usable Applications

When developing applications, these are the most important factors to consider: who the user is, what problems the user is trying to solve, and how to solve them most efficiently. Here are some key principles for creating usable applications:

■ Specialise your application for the specific browsers.

To create a more usable application, determ ine the ty pe of browser in the code. With that information, develop customised versions that increase usability by taking advantage of unique browser features.

■ Know your customer.

Users turn to an application to solve a problem and, in some environments, to communicate or be entertained. For instance, the user’s goal might be to purchase an item or to upload and download information while in the field. Build the application to help the user accomplish that goal. If the user’s goal is to find a stock quote, display the quote right away. Use the quote display screen as the entry point to any other information the user might want.

■ Get to the value quickly.

Deeply embedded information can cause the user to forget the goal and become frustrated. This frustration will cause the user to avoid the application in the future. Provide commonly used options quickly rather than requiring users to navigate deep menus.

■ Limit the application to only necessary functionality.

Remember that the browser does not have the display and navigation capabilities of a PC. In addition, while browsing on the handheld device, the user is looking to find or submit information in the shortest possible time. Scale down the application to meet only the goals of the user, and do not include extras. Provide access to the most commonly used features through menu choices, links, or options.

■ Make the application easy to navigate.

Minimise the number of steps it takes to access information. Eliminate or combine cards if this can be done without losing important i nformation, choices, or content. Create multiple paths to access information, if possible. For example, if the application provides weather content, allow the user to search by postal code or city. In this way, the user has the choice of entering a short code rather than long strings, which are hard to type on the phone.

■ Make the application consistent.

Consistent applications are “intuitive” for the user. Make the texts descriptive and easy to follow. Labels should explain the actions they cause. Order lists logicall y, so that items and links are easy to find. Although images and icons provide added information to help make pertinent information stand out, be careful not to overuse them.

■ Av oid te xt entry.

A void queries that force the user to enter alphanumeric te xt. Use menu s or partial text searches to avoid or minimise text entry.

6 Genie Application Style Guide February 2001

■ Personalise the service according to the user.

Allow an application to retain user information to autofill personal fields. For example, store the login and/or password, billing address, or other information in a cookie or on a server where the application resides. The user can be determined by the subscriber ID.

■ Anticipate situations in which users are likely to make errors.

Make sure the application does not allow the user to continue a task unless certain requirements have been met. For example, if the user is entering the date, the application should check that the date is 8 digits: 2 digits for the day, 2 digits for the month, and 4 digits for the year.

Testing the Design

Once the application is designed, use display templates and navigation flow diagrams to show how the application will behave on each type of browser. Use templates to view the layouts until you are satisfied with the text, wrapping, and overall look and feel. For this guide, templates restricting the lengths of the text were used to demonstrate menus, multiple selection lists, non-wrapping text (Times Square text scrolling), the viewing of text and links, and entries. Examine ev ery layout and display for consistenc y. Unnecessary differences (for instance the use of scrolling text in one screen and wrapping text in another) can confuse the user.

Usability Design Philosophies

Testing the Design

The sample application diagrams in Appendix B are meant to demonstrate navigation only, not other behavior. In contrast, the templates used throughout the rest of the guide indicate other desired application behaviors (wrapping texts, softkey labels, and so on).

Browser Templates

Openwave Browser Template

1 Quotes 2 News 3 Top 10 most 4 My Done OK

5 Recent

The Openwave Brows e r typ ically has two programmable softkeys at the bottom; in this example, OK and Done. For these examples, the the right softkey and the scrolls horizontally across the screen (Times Square scrolling) appears to the right of the screen, in grey. Below the screen, the template shows additional menu items and text; the user must scroll down to these. Each phone has a fixed key for Back or Back/Clear navigation, not shown.

active stocks portfolios

activity

<do type="accept"> label appears on

<do type="options"> label on the left softkey. Text that

February 2001 Genie Application Style Guide 7

Usability Design Philosophies

Testing the Design

Nokia 7110 Browser Template

--------Stocks -------- Options items:

Quotes News Top 10 most active stocks

Options

Recent activit My portfolios

Back

O Done

do type labels

The Nokia 7110 browser has two softkeys with fixed labels: Options and Back. The application examples, the

<do> labels are listed under and accessed from the Options softkey. In these

<do type="accept"> and <do type="options"> labels appear to

the right of the screen under Options items and can be accessed from the Options softkey. The Nokia 7110 roller key has various functions depending on the selected item on the

display:

• If the selected item is an <input> element, activate the input query;

• If the selected item is a <select> element, activate the select list;

• If the selected item is an <a> or <anchor>, activate the link and access the

defined URL;

• otherwise, display the Options items (the same menu listed under the Optio ns

softkey).

Mitsubishi Trium Browser Tem plate

Stocks Quotes News Top ten most active stocks

Recent activity My portfolios

Done

8 Genie Application Style Guide February 2001

Usability Design Philosophies

Testing the Design

The Trium handset has two softkeys and a four-way scroll key (supporting the up and down functionality, as well as moving forward and backwards). The Back functionality is available from a press on the left scroll key. The left softkey is a programmable key and will display a more than one element is defined, the softkey displays the label menu of the defined behaves depending on the context, but typically displays the such as

<do> element if only one is defined for the card (which is no t a pre v). When

Card and will display a

<do> elements in the order of their definition. The right softkey

<prev> element. When links,

<a> or <anchor>, <input> and <select> elements are highlighted, these

will typically replace one of the two softkeys on a context sensitive basis. On one type of device, they will appear on the right hand key, on the other, they will appear on the left hand key ONLY when no conflicting

<do> element is defined (although they could be

accessed through the four-way scroll key). Genie’s experience has shown that users (particularly beg inners) do not un derstand the forw ard and bac kward behavio r of the scroll key, and therefore Genie recommends that its use is not relied upon.

Browser Proper ties for Phones

Although WAP-compatible phones on the market ha ve a var iety of screen sizes, nu mber of keys, and key functionality, design the application to display well on a small screen. Applications designed for small screens look good on larger screens, but not necessarily the other way around.

■ Up to four lines of text or selection items may be visible.

Some phones have as few as two lines ; some have as many as eight lines.

■ Approximately 15 characters can be displayed on one line.

This number may vary, since many phones support variable-width fonts.

■ All phones have menu up/down navigation.

■ Right/left navigation may be available.

■ The browser’s home deck may not be easy to access or find.

■ Some phones support smart-entry methods (for instance, T9 or smart mode).

■ Most phones can display graphics or images.

■ Not all phones have a Send/Talk key.

■ All phones support uppercase and lowercase fonts.

■ All phones support links, but phones may display them differently.

■ Most phones do not have separate Back and Clear buttons.

When queries for entries are presented, the user may need to delete all entered characters in order to return to a previous screen.

Table 2-1 summarises the properties of the Openwave, Nokia 7110 and Mitsubishi Trium WAP browser phones (in the t able, “phone” means a WAP browser phone).

February 2001 Genie Application Style Guide 9

Usability Design Philosophies

Testing the Design

NOTE

not affect the user experience.

Table 2-1. Summary of browser phone properties

Property Openwave Nokia 7110 Mitsubishi Trium

Number of characters per line

Lines of display 2 to 8 lines 4 lines 5 lines (depends

Image/graphic support Supports images

Link support Links display as:

Scroll keys Scroll keys for

There is some variability among Openwave browser phones; howev er , this should

15 characters (mostly variablewidth fonts)

and graphics

[link],

<link>,

or link

Up/Down, some support Left/Right scrolling, others do so automatically

18 characters (variable- width fonts)

Supports images and graphics

Links display as: link

Nokia 6210/6250 only: Can be selected by pressing Send k e y

Roller key for Up/Down

6210/6250 only: Scroll keys for Up/Down

Variable-width fonts. User can change font size.

on font size) Supports images

and graphics. User may disable these.

Links display as: link

Four-way scroll key for Up/Down (also supports forward and backward navigation)

<do> labels Label is

associated with softkeys on the phone

Menu navigati on Develop as a

element or statement

Labels appear under Options softkey

Develop as a list of links

Label displays on or under left softkey; see Mitsubishi Trium Browser Properties

Develop as a list of links

10 Genie Application Style Guide F e bruary 2001

Usability Design Philosophies

Testing the Design

Table 2-1. Summary of browser phone properties (continued)

Property Openwave Nokia 7110 Mitsubishi Trium

Back key for navigation Dedicated Back

key available except in entry queries

Programmable Back key is displayed on right softkey except in entry queries

Dedicated back key on left scroll key. Programmable Back key is displayed on right softkey

Clear/Back key in entry queries

Entry queries and multiple selection lists

Shared. User must delete data in a query to retain Back properties.

Displayed as a browser card wit h one programmable softkey

Shared. User does not necessarily need to delete data to return to previous card.

Displayed as a local application that users must select to access the local application

Shared. User does not necessarily need to delete data to return to previous card.

Displayed as a local application that users must select to access the local application

Openwave Browser Properties

The following properties are unique to the Openwave browser. Capitalise on these to enhance usability. Use the Openwave UP.SDK 4.1 or WAP browser phone to test applications using these features.

■ A label for the highest priority action is viewable and accessible from all cards.

The <do type="accept"> label is displayed on the screen and acces sed by pressing the primary softkey (the right softkey in the template).

■ A label for the secondary actions is accessible from a second softkey.

The <do type="options"> label is mapped to the second softkey (the left softkey in the template) and may require one or more keystrokes to select (depending on the number of

■ Each phone ha s a fixed key mapped to backward navigation.

<do type="options">).

Back functionality, <do type="prev">, is always available from a fixed key on the keypad. The default is the last card in the history if no other location is specified. This key may be shared with a Clear key in entry queries.

■ Phones support the ability to select an item from a numbered list.

Numbers corresponding to <option> items precede each menu item.

February 2001 Genie Application Style Guide 11

Usability Design Philosophies

Testing the Design

Nokia Browser Proper ties

■ Nokia 7110 only: The roller key can be pressed to activate the selected item.

The selected item (action, anchor, <option>, <select>, or <input> element) can be activated from the roller key and is also listed as the first item when the user presses the Options softkey, “Nokia 7110 Brow ser Template” on page 8. No label is displayed for the roller key action. If no item on the display is selected, pressing the roller key will display the menu listed under the Options softkey.

■ Nokia 6210/6250 only: The user can press Send key to activate the currently

selected anchor, <option> element, <input> element, or <select> element.

Do not rely on the user discovering this behavior since no label is displayed for the send key action. If no item on the display is selected, pressing the Send key will display the menu listed under the Options softkey.

■ Entry and multiple selection screens are self-contained functions.

The user cannot access <do> element, <option> element, or anchors from an input query or multiple selection screen. The phone controls the display of these functions, which are accessible on the card from which the item was selected.

■ The second softkey is reserved for Back.

The phone displays t he <prev/> task on the right softkey only if the action defined is

<prev/>. There is no need to provide a label; the browser will assign the label Back.

A defined label will not render on the softkey.

■ The screen displays approximately 18 characters on one line.

Because the phone supports variable-width fonts, the number of characters per line varies. Check the text on a phone or Nokia WAP Toolkit.

Mitsubishi Trium Browser Properties

■ The left softkey suppor ts the <do> elements.

The left softkey is a programmable key and displays the label for the

<do type="accept"> element when there are no more than one <do type="accept"> or <do type="options"> elements are defined. When

more than one element is defined, the softkey displays the label Card and will display a menu of the defined below when a

< prev> element is defined.

<do> elements in the order of their definition. See the rule

12 Genie Application Style Guide F e bruary 2001

Usability Design Philosophies

Testing the Design

■ The right softkey label supports the <prev> element and for some phones may

be context sensitive.

The right softkey supports the following function depending if an item is selected or what type of element is defined:

• If there is no item selected, the s oftkey returns the user to the previous card in the

history.

• For some phones, when a <prev> element is defined with a label, the phone will

display the defined label. When no label is defined, prev or Back will display. Backward navigation will replicate that of the left scroll key.

• For some phones, if the item selected is a <input> or <select> element, the

softkey displays the defined label and accesses a card with the

<select> element. For some phones, if there is a <do> element define with an

action other than element. The user can the access the

<prev>, there is no softkey prompt for the input or select

<input> or <select> element from the

right scroll key.

<input> or

• For some phones, if the item selected is a link, the softkey displays the defined

label and accesses the URL.

■ The phone has a fixed key mapped to backward navigation.

■ <input> and <select> elements.

Activating a <select> or <input> element takes the user to a separate card to either select an item or enter data.

■ Tables are supported.

■ Images and WML Scripts may be turned off by the user.

The browser has a setting that allows users to enable or disable image and WML Script support. For images, the browser displays the alt text defined. When WML Scripts are turned off, an error message displays causing user confusion; therefore, avoid using WML Scripts.

■ Timers are supported.

Timers on cards will be re-initialised and activated each tim e the card is displayed, even if that particular counter had already triggered.

February 2001 Genie Application Style Guide 13

Usability Design Philosophies

Testing the Design

14 Genie Application Style Guide F e bruary 2001

Chapter 3 Navigation Guidelines

T o na vigat e W irele ss Mark-up Lang uage (WML) content, the user must mo ve t hrough and between cards in one or more decks. The cards can contain many different types of elements, including selection lists (items in a list), displayed information (such as an email message), input fields, and multiple selection lists. To make applications run on multiple browsers, follow a number of general rules.

Shared Feature Set: Navigation Guidelines

■ Do not assign more than one action of <do type="accept"> in any card.

■ Map the most commonly chosen action or most intuitive task to

<do type="accept">.

■ If there is to be more than one <do> task, ensure that the most common one is

defined first in the card.

■ Create an intuitive label for every <do> task.

This label will appear on the softkeys for the Openwave and Mitsubishi Trium browsers and under the Options softkey for the Nokia browser . Note that when a label is assigned to the right. Always define a label of Back or Done for the Trium browser if the task is defined separately.

■ Capitalise only the fir st letter of labe ls of <do> elements e xcept in w or ds like OK .

Consistent style throughout all applications enhances usability.

■ Define a backward navigation action for each card.

Each card should have a <do type="prev">.

Example 3-1

<prev/>

</do>

prev task, the Nokia 7110 browser displays a Back label on the

prev task for the Mitsubishi

February 2001 Genie Application Style Guide 15

Navigation Guidelines

■ Never define a prev as having no action.

Do not bind an action of type <noop/> to a task of <do type="prev">. This forces the user to return to the home deck, which is not always intuitive and may make users follow a long path to return to the application. Instead, bind the intuitive place within the application, a starting point within the application or to the home deck when that makes sense.

■ Provide a confirmation card (delete shield) to prevent data loss.

Do not allow users to back o ut of an app lication inadve rtently when the y ha v e already entered data in an entry query. Create a card asking users to confirm that they wa nt to quit. This spares users the tedious task of re-entering data.

Example 3-2

Openwave Browser

Name (first & last): John Doe

Alpha Next

User presses the Back key

prev task to an

Are you sure you want to cancel your order? Yes No

Delete shield

Nokia 7110 Browser

----------Order---------

Name (first & last): [John Doe]

Options Back

Mitsubishi Trium Browser

Options items:

Edit Next

Order Name (first & last): John Doe

User presses the Back key

Are you sure you want to cancel your order? Yes No

[order Andrew]

Delete shield

[City &

----Confirm order---- Options items:

re you sure you want to cancel your order?

Options

Back

In Example 3-2, the code should be placed on the card that spawns the data entry form. If the user backs out after having entered the name, the confirmation card acts as a delete shield.

16 Genie Application Style Guide F e bruary 2001

Navigation Gui d elines

■ All cards should have a title attribute of 18 characters or fewer.

Longer titles may be truncated, obscuring meaning. Test the title to make sure it fits. Not all phones display the title.

Example 3-3

Nokia 7110 Browser

-Welcome to Wh... - Options items:

Last name: Smith

First name: Andrew

City & State: San Options

Diego, C

Back

Find Done

In Example 3-3, the last eight characters of the title are truncated. Test the text length on the Nokia SDK to ensure that the entire title appears on the screen.

■ Whenever a phone number is displayed, make it possible for the user to call it.

Assign the action href="wtai://wp/mc;<phone number>" to create calls, and assign the label Call. This will not work on Nokia handsets, but users can use the Use Number functionality instead.

Example 3-4

Openwave Browser

Andrew

[Home: 1-408-

[Work: 1-415[Mobile: 1-

Call Done

Smith

555-1212]

555-9146] 415-555-4251]

In Example 3-4, the user can call 1-408-555-1212 by pressing the Call softkey.

■ When possible, keep the order of menu items or forms the same.

Users become familiar with the order and select items without paying much attention.

■ Do not rely on font properties to convey added information.

Many phones do not support various font properties such as bold, underline, and italic.

February 2001 Genie Application Style Guide 17

Navigation Guidelines

Openwave Navigation Guidelines

■ Always define an action for <do type="accept">.

If no action is defined, a task of <do type="prev"> may be automatically bound to the the developer is intending. If Back is a more appropriate label than OK, use this:

Example 3-5

</do>

■ Limit the length of labels.

Define <do> element, <option> element, and anchors labels using f i v e characters or fewer: the screen si ze o n man y p hones is limited. Lo nge r labels m ay b e tru ncated and lose meaning.

Example 3-6

</do>

<do type="accept"> key with the label OK or Back, w hi ch may not be what

<prev/>

In Example 3-6, the label Find is under five characters.

■ Limit the number of softkey actions to two or fewer, when possible.

Since most phones do not have more than two softkeys, this limit allows the user to view both softkeys. This simplifies tasks because the softkey labels are accessible with one keypress. When more than two elements are defined, the first element is bound to the primary softkey, and all other options and elements are accessible from the secondary softkey.

18 Genie Application Style Guide F e bruary 2001

Example 3-7

Openwave Browser

1 U2: Best of

2 Actung Baby 3 Joshua Tree 4 War Menu View

</refresh> </do>

1980 – 1990

Options under Menu are: Buy

lert

Reset

Navigation Gui d elines

In Example 3-7, more than one option is bound to the <do type="options"> task. For this reason, the browser renders the label Menu on the secondary softkey. The options under the Menu softkey are Buy, Alert, and Reset. The phone will label the softkey Menu. Although the provided UI is generally understandable and efficient, a developer may wish to exercise more control and build a card for the menu themselves. This could provide more descriptive action items and enable better use of icons and key accelerators. In this case, when more than one option is required, build a card with the appropriate actions and bind this card to the secondary softkey key.

■ Include a descriptive header of 15 characters or fewer.

This header informs the user of the context if the title is not displayed. On some Openwave browsers, the title may be displayed as well.

Example 3-8

Openwave Browser

Stock service

1 Symbol

2 Company 3 Portfolio Menu Edit

In Example 3-8, the header “Stock service” orients the user to the context.

February 2001 Genie Application Style Guide 19

Navigation Guidelines

Name (First and Last): John Doe

ALPHA OK

■ Use activities or carefully designed navigation to direct the Back key to the most

intuitive page.

Activities best create a start point that allows the application to return to a specified card when user presses the Back key. The intermediate cards (those accessed before the return to the specified card) are removed from the history.

Example 3-9

Openwave Browser

Exp. Date (MM/YYYY): 01/2000

Confirm order U2: Best of John Doe 1212 Madison

Buy Edit Rd.

San Diego, CA 92109

Address: 1212 Madison Rd.

ALPHA OK

When the user presses Back from any card, the application returns to the first card, not the previous one. In this way, the user can navigate forward and need not delete already entered information.

</do>

</do>

<p>

</p> </card>

Zip code: 92109

Credit card: 1234567890123 456

</catch>

</spawn>

Name (First and Last): <input name="name" title="Full Name"/>

Street Address

20 Genie Application Style Guide F e bruary 2001

Navigation Gui d elines

</card>

</throw> </do> <p>

Zip Code

</card>

</throw> </do> <p>

Credit Card:

</card>

</throw> </do> <p>

Exp date (MM/YYYY):

<input name="exp" title="exp date mmyyyy"

format="NN\/\2\0NN"/>

</p>

</card>

February 2001 Genie Application Style Guide 21

Navigation Guidelines

In Example 3-9 the goal is to allow the user to navigate backward through the data input wizard without losing data that was difficult to enter (since many devices map the clear and back functions to the same ke y) and withou t corrupting the h istory stack. This is accomplished by starting out with the

<throw> for backward navigation. In the <throw> statement for each card, the data

that has already been entered is sent back (so it is not lost) and caught in the card where the user entered the name. This way, when navigating forward through the wizard, the user need not re-enter data but can modify or remove it as necessary.

A similar effect (although not quite so efficient) may be achieved w ith the use of the

onenterbackward construction, although if data is no longer in the cache this will

involve further server hits. A card containing:

</onevent>

Will immediately call the card that originally called it, without erasing any data.

spawn action, which enables the use of

<prev/>

Nokia Navigation Guidelines

■ Provide an action or link on every card.

Every card should define either a link or an action bound to a task of

<do type="accept">, <do type="options">, or <do type="prev">.

Generally, links should be used as a mechanism for forward navigation.

Example 3-10

Nokia 7110 Browser

------ Contacts------- Options items: Last name: Smith

First name: Andrew

City & State: San Options

Diego, CA Zip: Phone: Email:

Back

Edit Find

In Example 3-10, the <do type="accept"> task calls edit.wml, and the

<do type="options"> task calls find.wml. On the Nokia 7110 browser, Edit and

Find are accessible from the Options softkey.

22 Genie Application Style Guide F e bruary 2001

+ 58 hidden pages