Genie 7110 User Manual

Download

Page 1

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

Page 2

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.

Page 3

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

Page 4

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

Page 5

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

Page 6

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

Page 7

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

Page 8

Style Guide Overview

Testing on SDKs

4 Genie Application Style Guide February 2001

Page 9

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

Page 10

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

Page 11

■ 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

Page 12

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

Page 13

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

Page 14

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

Page 15

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

Page 16

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

Page 17

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

Page 18

Usability Design Philosophies

Testing the Design

14 Genie Application Style Guide F e bruary 2001

Page 19

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

Page 20

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

Page 21

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

Page 22

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

Page 23

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

Page 24

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

Page 25

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

Page 26

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

Page 27

Navigation Gui d elines

■ Use up to 18 characters on option labels.

Since <do> labels are items under the Options softkey, labels can be approximately 18 characters long. Limit labels to one or two words.

Example 3-11

Nokia 7110 Browser

--------Contacts-------

------

Last name:

[Smith]

First name: [Andrew]

Options

City & State: [San Diego, CA]

Back

Options items: New Contact Done

In Example 3-11 the menu item “New Contact” can replace New in applications searching a database of information because the label is displayed under the Options softkey.

■ Never define an action of go or noop to the prev task.

• The Nokia browser will not acti v ate the right softkey. The action will be accessible

only under the Options softkey. To control how the application behaves when the

<prev> action is invoked, use a “shadow” card that contains an <onevent type="onenterbackward"> element.

Example 3-12

<wml> <template> <do type="prev" label="Back"> <prev/> </do> </template> <card id="start" onenterforward="#start2" onenterbackward="backtome.wml"> </card> <card id="start2" title="The Start"> …

Example 3-12 works by defining a dummy card (id="start") that immediately transfers control to the real card ( Entering the card from a backward direction triggers the loading

backtome.wml.

id="start2") and puts itself on the history stack.

onenterbackward, thus

■ It is not necessary to define a label for a <do type="prev">.

The Nokia 7110 browser assigns the label Back to the right softkey and ignores the defined label.

February 2001 Genie Application Style Guide 23

Page 28

Navigation Guidelines

Mitsubishi Trium Navigation Guidelines

■ Provide backward navigation for each card.

Provide an intuitive label, for example Done or Back, to allow the user to use the right softkey for backward navigation. The browser will automatically provide a label of Back assigned to an action of overridden such

Example 3-13

Example 3-13 provides an alternative labelling for the right hand key.

■ Do not rely on being able to override the default backward navigation

Trium browsers vary in ter ms of th eir handling of the <do type="prev"> construction. One type will only change the right hand key behaviour if the action is still also. For safety, handle alternate back navigation using a mechanism similar to Example 3-12 above.

<prev/> - if the term “Back” is not suitable, it may be

<prev/>; the other type allows <noop/> and <go/> constructions to be used

■ Do not define a <do type="accept"> or <do type="options"> task when a

<select> element, <input> element, <a> or <anchor> is use d.

A <do type="accept"> or <do type="options"> task on some versions of the browser, this will cause the softkey to display the Card label preventing easy navigation to t he next card or to the input a nd select items. Instead, provide a li nk allowing the user to navigate to the next card.

■ Limit the number of softkey actions to one.

The browser displays the defined label on the left softkey. This simplifies tasks because the softkey label is accessible with one k eyp ress. When more than on e task is defined, the le ft softkey labe l may become Card and displays the defined labels. In this case, build a card with the desired tasks and label the softkey Menu. This pro vides room to display more descriptive labels for each action and enables the use of key accelerators, on some handsets.

■ Do not underline text (<u> mark-up tag), because the user may think that the

item is a link.

Not all Trium browsers will do underlining if the tag is used, but if it does, there is clear possibility for confusion.

■ Avoid using WML Scripts.

Since the user can disable WML Scripts, do not rely on them b eing activated. You can check to see if the user has disabled scripts by checking the

HTTP_ACCEPT header –

however th e user could st ill turn off scripts while a script is in the cache of the phone.

24 Genie Application Style Guide F e bruary 2001

Page 29

Chapter 4 Menu Navigation

Navigating though menus primarily consists of selecting items or links that, when selected, display a new card or deck or perform some action. Menus can be used for:

• Presenting a list of data (for instance, a list of email messages)

• Navigation (for instance, choices within a financial application)

• Performing an action (for instance, deleting an email message)

• Selecting an option (for instance, picking the day of the week for a scheduled event)

• Changing an option (for instance, allowing the user to change a preference or setting)

Shared Feature Set: Menu Guidelines

■ Sort items contextually.

Items or links should be sorted logically as content dictates; this might be by type, by date, alphabetically, and so on. If there is no logical order, sort by priority, that is, put the item most likely to be chosen first.

■ Do not put more than 9 items on a single card.

Limit the amount of scrolling needed on a given card and allow for key shortcuts.

■ Create a More link or <select> element as the 9th item if there are more than

9 items in a menu.

Clicking More should display the next ca rd of menu items.

■ Consider using numbers to help the user remember the application.

Even if the handset does not provide for key accelerators numbers help a user find their way around an application and remember where to find the information that is important to them. Openwave browsers (when using numbering) and some Mit subishi Trium br owse rs (when using provide key accelerators, but numbering is potentially useful even if this is not the case.

<select> - and automatic

<a> or <anchor>)

February 2001 Genie Application Style Guide 25

Page 30

Menu Navigation

Openwave Menu Guidelines

■ Use the <select> element to get numbers, icons, and items for a menu.

These provide quick access to an item by including numbers in a list. Instead of us ing anchors, use a becomes an

Example 4-1

Openwave Browser

1 New message

2 Reply 3 Forward

<select> element for each card. In this case, each item in the list

<opti on onpick=URL> element rather than an anchor.

Done

<option title="New" onpick="compose.cgi">New Message</option>

<option title="Reply" onpick="reply.cgi">Reply</option>

<option title="Fwd" onpick="forward.cgi">Forward</option> </select>

In Example 4-1, menu items can be selected by pressing a number key.

■ Wrap text that takes up multiple lines or multiple display windows.

For a series of items that occupy multiple lines, allow the lines to wrap and use a link to display the next item. For example, in a list of news headlines, display each headline on a card of its own. Use an anchor with the label Skip at the end so that the user can navigate to the n ext headline. Map the

<do type="accept"> task to a

View label so that the user can view the news item. While the user is viewing the headline, map the <do type="accept"> task to a Skip label, so that the user can skip to the next headline.

Example 4-2

Openwave Browser

Top stories 1/3 Astronomers find evidence Skip View

Top stories 2/3 Sunspot activity at Skip View

Top stories 3/3 Stock markets worldwide Done View

of planet in constellation Leo.

an all time high.

gaining.

26 Genie Application Style Guide F e bruary 2001

Page 31

Menu Navigation

Nokia Menu Guidelines

■ Each menu should be a list of anchors.

30 Genie Application Style Guide F e bruary 2001

Page 35

Mitsubishi Trium Menu Guidelines

■ Each menu should be a list of anchors.

■ Define labels of six characters or fewer for each anchor.

Longer labels may be truncated.

Menu Navigation

February 2001 Genie Application Style Guide 31

Page 36

Menu Navigation

32 Genie Application Style Guide F e bruary 2001

Page 37

Chapter 5 Making Phone Calls from

the Browser

Some applications require the user to make a call or create opportunities for the user to do so, for instance, from a list of contacts, a phone number q uery, or an order form. This is an extension of general navigation; however, not all phones allow the user to make a call directly from the browser. If the phone does support calls from the browser, develop the application so that the user can retrieve the phone numbers.

Shared Feature Set: Calling Guidelines

■ When displaying more than one phone number on a card, display the primary

number first.

Some browsers pick out phone numbers from the deck automatically and list them in the order listed on the card.

■ Use a line or page br eak (<br/> or <p>) between displayed phone numbers.

Unless a break is added, the numbers may run together when the user selects the “Use number” menu function or presses the Send key.

Example 5-1

Nokia 7110 Browser

---- Robert Brown--Phone number:

555-1212

Options

■ When terminating a call, do not assume that the phone may reinvoke the

browser.

■ Do not assume that the same deck will be redisplayed after the browser is

reinvoked.

The user may need to navigate back to the same deck.

Back

February 2001 Genie Application Style Guide 33

Page 38

Making Phone Calls from the Browser

Openwave Calling Guidelines

■ Embed code to make the phone call.

Example 5-2

Openwave Browser

Hi Bob, Please call

e when you have a Menu Call

chance. Tom

[1 408 555

1543]

In Example 5-2 the user can call 1-408-555-1543 by pressing the Call softkey.

■ Provide a Call anchor label.

This allows users to make a call directly from the browser.

■ Use href="wtai://wp/mc;<phone number>" instea d of a link, unl ess m ultiple

actions are desired.

This allows the user to make the call directly from the card rather than accessing another card to retrieve the number and make the call.

■ Some brows ers wil l retu rn to the p re vious car d when it is rei nvoked after the call

is terminated.

To display a card other than the previous card in the history after the call terminates,

<onevent type="onenterbackward"> in the card that generated the call.

use

■ Map the Send key action to the action of calling.

In addition to using the softkey Call use <do type="vnd.up.send"> so that users can also press the Send key to make the call. However, do not rely solely on this because not all phones have a Send key or map the Send key function.

34 Genie Application Style Guide F e bruary 2001

Page 39

Making Phone Ca lls from the Browser

Nokia Calling Guidelines

■ Include both the name and number on the screen.

■ Provide a link to a card with the number if only the name is displayed.

If the application displays only a name and not a number, such as in a search of a contact list, allow the user to place the call from the name lis t. However, it is also important to give the user the option of accessing an additional card with the name and number.

■ List the numbers for only one contact on one card.

Do not list numbers for different people on one card. When more than on e contact and phone number are listed, the contextual information is lost when the user selects the “Use number” item under the Options softkey or presses the Send key.

Mitsubishi Trium Calling Guidelines

■ Embed code to make the phone call.

Use links or softkeys to make phone calls as in Example 5-3.

Example 5-3

■ Provide a Call anchor label.

This allows users to make a call directly from the browser.

■ Use href="wtai://wp/mc;<phone number>" instead of a link, unless

multiple actions are desired.

This allows the user to make the call directly from the card rather than accessing another card to retrieve the number and make the call.

■ Expect the browser to return to the previous card when it is reinvoked after the

call is terminated.

February 2001 Genie Application Style Guide 35

Page 40

Making Phone Calls from the Browser

36 Genie Application Style Guide F e bruary 2001

Page 41

Chapter 6 Using Multiple

Selection Lists

Use multiple selection lists when the user can select more than one item on a list.

Openwave Multiple Selection List Guideline

■ Create on ly one <do> element or <do type="accept"> label, using five

characters or fewer for the multiple selection list.

Only one label is displayed; the second label is reserved for the device.

Example 6-1

Openwave Browser

Bob Brown X Angelica Dirk Gary Kinser Done Pick

Swansen Bigelow

X Jeff Lingle

<option value="bbrown">Bob Brown</option> <option value="aclemson">Angelica Clemson</option> <option value="dbigelow">Dirk Bigelow</option> <option value="gkinser">Gary Kinser</option> <option value="jlingle">Jeff Lingle</option>

</select>

Example 6-1 demonstrates how to create a multiple selection list. Notice that the code does not use displaying the defined and

■ Do not use <option onpick = href> for items on the selection list.

Using <option onpick> does allow the user to select the item but may automatically display the next URL.

February 2001 Genie Application Style Guide 37

<do type="options"> because it would render a Menu softkey

prev actions.

Page 42

Using Multipl e Sele ction Lists

Nokia Multiple Selection List Guideline

■ Provide navigation links to the next URL.

In addition to the <do> element or <do type="options"> label, create a link leading to the next card. This lets the user navigate via the link rather than from the Options softkey.

Example 6-2

Nokia 7110 Browser

----Send options---Names: [Abby Clemson] Next

Options

Example: <select name="recip" multiple="true">

<option value="bbrown">Bob Brown</option> <option value="aclemson">Angelica Clemson</option> <option value="dbigelow">Dirk Bigelow</option> <option vlaue="gkinser">Gary Kinser</option>

<option value="jlingle">Jeff Lingle</option> </select> <a href="send.cgi">Next</a>

Back

 Bob Brown

■

Abby Clemson

 Dirk Bigelow  Gary Kinse

■

Jeff Lingle

Mark

Done

Example 6-2 illustrates how to let the user easily navigate from a URL. The multiple selection list is displayed by the local Nokia 7110 user interface and is not a browser card. Providing a link allows the user to navigate to the next card without pressing the Options softkey.

■ Long text does not wrap.

Ensure that the text fits on one line; longer text is truncated.

Mitsubishi Trium Multiple Selection List Guideline

■ Av oid using <do> options.

Provide a link to the next URL instead

■ Long text does not wrap.

Ensure that the text fits on one line; longer text is truncated.

38 Genie Application Style Guide F e bruary 2001

Page 43

Chapter 7 Backward Navigation

Pay special attention to backward navigation because users tend to use the Back key or softkey to back out of an application. Users are more likely to trust applications with good backward navigation functions. In addition, backward navigation lets users leave the application without returning to the home deck. This may be particularly helpful for applications that are deeply embedded in the browser. For example, if a set of applications is three menus deep from the home card, backward navigation allows the user to return easily to the start of the set without re-navigating through the first two or three menus. In some cases, the design must prohibit navigation behind password-protected cards.

The default behaviour for all three browsers vary amongst each other and depending on the how the code is defined:

Table 7-1. Summary of backward navigation behaviour

Openwave Browser Nokia 7110 Mitsubishi Trium

No defined <do> or

<prev> elements

Primary softkey (labelled OK or Back returns users to the previous card in the history.

Dedicated Back key returns the user to the previous card in the history.

Backward navigation is not possible.

User must select Home from the Options menu to exit the application.

Right softkey, labelled Back, returns user to the previous card in the history. On some phones, if user navigates over a link,

<input> or <select> element,

the back functionality is removed.

Left scroll key returns user to the previous card in the history.

February 2001 Genie Application Style Guide 39

Page 44

Backward Navigation

Table 7-1. Summary of backward navigation behaviour (continued)

Openwave Browser Nokia 7110 Mitsubishi Trium

<prev> element defined

with no label

<prev> element

defined with a label

Where url takes the user to a defined URL

Dedicated Back key returns the user to the previous card in the history.

Dedicated Back key sends the user to the defined URL

Back displays on the right softkey and return s the user to the previous card in the history.

Back displays on the right softkey and return s the user to the previous card in the history. Defined label is ignored.

Defined label displays under the Options key and sends the user to the defined URL.

Note that if a Template has been defined, then the Back key may act a

<prev> action.

Right softkey, labelled prev or Back, returns the user to the previous card in the history.

Left scroll key returns user to the previous card in the history.

Right softkey labelled with the assigned label and returns the user to the previous card in the history.

Left scroll key returns user to the previous card in the history.

On some phones, if there is no

<do> element defined, the

other Done label will appear on the left softkey and send the user to the defined URL. The right soft key displays Back and returns the user back in the history.

On other phones, the right hand key will be labelled Done and will send the user to the defined URL.

Shared Feature Set: Backward Navigation

■ Always provide some kind of backward navigation.

■ Map backwar d na vigation t o the ne xt high est or most intuiti ve men u when dire ct

backward navigation is not suitable.

Backward navigation is not al w a ys practical. F or example, suppose the user confirms an action, such as making a purchase or deleting an item. Pressing the Back key should not take the user to the card confirming the purchase or the list with the deleted item. Instead, the application should either return to the application’s home card, a login card, or a card that intuitively lets the user continue through the application or exit easily. Use backward navigation or to take the user past screens they should not revisit.

an <onevent type="onenterbackward"> task either to prevent

40 Genie Application Style Guide F e bruary 2001

Page 45

Backward Navigation

Example 7-1

<template> <do type="prev" label="Back"> <prev/> </do> </template> <card id="start" onenterforward="#start2" onenterbackward="backtome.wml"> </card> <card id="start2" title="The Start"> …

Example 7-1 shows how to prevent the user from navigating back through a card by catching the reverse entry into the card. In this case, the user is taken back an additional card.

■ Always prov ide a label f or a <do type="prev">.

The Nokia browser assigns the label Back instead of the defined label to the right softkey. If no label is defined, the label Back is automatically assigned to the right softkey. On some Mitsu bishi Trium browsers, if a label is not defined, the right key will be labelled prev – which is not intuitive.

■ Create a second way to navigate backward when moving back in the history

stack is not desirable.

Provide backward navigation via <do type="options"> if backward navigation should return the user to a higher menu or the top menu of the application. Use the label Done to indicate that backward navigation will take the user back more than one step. The label Done appears on the secondary softk ey on the Openwave browser and also under the Options softkey on the Nokia 7110 browser.

February 2001 Genie Application Style Guide 41

Page 46

Backward Navigation

Example 7-2

Openwave Browser

Nokia 7110 Browser

Mitsubishi Trium Browser

Results 1/322

[Brown, A]

[Brown, Alex] [Brown, Done View

----Search results ---

Results 1/322

Brown,

Brown, Alex Brown, Andrew

Options Back

Search results Results 1/322

Brown, A

Brown, Alex Brown, Andrew

Done

View

Andrew]

Options items:

iew

Done

Example 7-2 shows how a URL helps the user navigate more easily. The Done and Back keys take the user to the application’s home card.

■ Empty the application histor y when direct backward navigation is not possible.

When it is not possible to go backward (for instance, after the user confirms an action), consider erasing the application’s history list.

Example 7-3

... <card id="clear" newcontext="true">

</card>

Example 7-3 shows how to empty the history for applications requiring passwords or secured data. This will delete variables in the handset. If this is not desirable, use an

onenterbackward to catch the backward navigation.

42 Genie Application Style Guide F e bruary 2001

Page 47

Backward Navigation

■ Save the values of variables when needed.

If the user exits an entry field, it may be helpful to temporarily save the values of all or some of the variables. This can reduce the amount of information the user must enter in the future. For example, it may be helpful to retain non-secure information entered in an order form, such as the name and address, so that the user does not have to reenter it in the same browsing session. See “Cookies and Subscriber ID” later in this guide for information on using cookies for this purpose.

■ Provide delete shiel ds.

If backing out of an app lication may cau se data loss , p rovide a card asking the user to confirm the action.

Example 7-4

Openwave Browser

Name (first & last): John Doe

Alpha Next

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

Nokia 7110 Browser

Mitsubishi Trium Browser

Order Name (first &

last): John Doe

Order Are you sure you want to cancel

your order?

Yes No

Example 7-4 shows how the conf irm ation card acts as a delete shield if the user backs out of the card with the Name prompt preventing loss of data.

■ Retain data in wizard forms.

Many devices have shared Clear and Back keys for text input. Therefore, if the user wants to edit or change the data in one of the forms, return to the first entry card so that the user will not have to delete already entered data. When the user navigates through each card, display the data already entered for that card. It is much easier for users to navigate forward through each card than to delete what they already entered in order to navigate back t hrough previou s cards.

February 2001 Genie Application Style Guide 43

Page 48

Backward Navigation

Name (First and Last): John Doe

ALPHA OK

Openwave Backward Navigation

■ Use activities when needed.

This way, the user does not have to repeatedly press the Back or Clear key, clearing already entered data.

Example 7-5

Openwave Browser

Address: 1212 Madison Rd.

ALPHA OK

When the user press es 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.

Example 7-5 shows the navigation of activities. See Example 3-9 for a complete descripti on of the code .

Zip code: 92109

Credit card: 1234567890123 456

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

Confirm order U2: Best of 1980 1990 John Doe

Buy Edit

1212 Madison Rd. San Diego, CA 92109

Mitsubishi Trium Backward Navigation

■ Define an appropriate label describing backward navigation when Back is not

intuitive.

Define a label for the <prev/> event when Back is not intuitive. For example, if the previous card has an

onenterbackward event.

44 Genie Application Style Guide F e bruary 2001

Page 49

Chapter 8 Displaying Text

Some cards contain mostly text. For instance, applications that display email messages, news items, stock quotes, and conf irmation or informati ve notices are te xt intensi ve. These cards often contain limited number of selection choices and are not used for text entry.

Shared Feature Set: Text-Display Guidelines

■ Display about 500 to 800 characters per card.

■ Define a More link if more information is available.

Example 8-1

Openwave Browser

The China Ocean Shipping Corporation Done Skip

(COSCO) recently developed a

ulti functional software for maritime [More]

■ Wrap the text.

Do not use <p mode="nowrap">. The exception is a short header or text of little relevance to the user. For example, when displaying news for a specific company, use

<p mode="nowrap"> mode to display the company na me.

the

■ Define the primary label for navigation.

Use the primary softkey or a li nk for forward navigation (accessing the next set of data); use t he secondary labels fo r alternative navigation or other functions related to the application.

February 2001 Genie Application Style Guide 45

Page 50

Displaying Text

■ Define a Skip link to go to next related item.

When displaying a series of related data, such as news stories or email messages, use a Skip link to allow the user to skip the current item and retrieve the next one. Do not use Next. Usability tests show that users tend to think it means “go to the next page” and not “go to the next item.”

■ Define labels for links.

Create an appropriate label that reflects the action of the link. When the user selects the link, the label should change accordingly, for example, from View to Skip. Limit labels to five characters.

■ Use links sparingly.

It is popular to put links at the end of display cards for alternative navigation, but do not define more than two or three links per card. User tests show that links at the end of the card often make it difficult for users to navigate out of the card. The reason is that labels corresponding to the link replace the labels for the primary action. This forces the user to scroll back up to access the primary action. The last link should match the default action for the card so that the user does not have to scroll up again.

■ Keep the text of links short.

This avoids links that wrap beyond one li ne.

■ Place navigation links only at the top and bottom of the card.

Do not embed navigation links in displayed text (unless it is context sensitive), because users will not understand that the links are not related to the data. Limit the length of navigation links to one line each, 13 characters if possible (the brackets will use 2 of the 15 characters).

Example 8-2

Openwave Browser

INTC Last: 81 1/4 Chg: -1 Vol: Done OK

1,361,800 [News]

46 Genie Application Style Guide F e bruary 2001

Page 51

Displaying Text

Openwave Text-Display Guidelines

■ Use mobile originated prefetch to access the next card.

This shortens the time needed to retrieve the next set of information. While the user is reading one card, the next card can be retrieved and put into the cache.

Example 8-3

<head>

Page 1 of 2<br/>

... </p>

</card>

Example 8-3 shows how to use prefetch to access the next card in a deck.

■ Do not use links on cards used to display results.

On cards that ask the user to confirm an action (for instance, deleting a contact from an address book), that provide error e xplanations , or that display other results, use the

<do type="accept"> and <do type="options"> labels instead of links. Map

the safest or most common response to the

■ Incorporate Done softkeys when possible.

<do type="accept"> label.

If no secondary functions on the displayed text are needed, add a Done softkey that returns the user to the next highest level within the application. This is often used in conjunction with activities so that the user can pop out of the current activity and return to the activity that spawned it.

February 2001 Genie Application Style Guide 47

Page 52

Displaying Text

Nokia Text-Display Guidelines

■ Include extra navigation links, and allow users to use the Options softkey for

additional navigation, when needed.

For example, when confirmation card s are used, add links after the question and place confirmation labels (such as Yes and No) under the Options softkey.

Example 8-4

Are you sure you want to cancel your order?

Options

</go> </do> <p> Are you sure you want to cancel your order?<br/> <anchor>

<prev/>

No </anchor> <anchor>

</go>

Yes </anchor> </p>

</card>

Back

Options items:

In Example 8-4, the links on the card allow the user to easily see and select the available choices in response to the query.

48 Genie Application Style Guide F e bruary 2001

Page 53

Displaying Text

Mitsubishi Trium Text-Display Guidelines

■ Create links to navigate off the card.

■ Define appropriate softkey labels for confirmation cards.

Provide intuitive labels, such as Yes an d No, for cards that require the user to confirm an action. For example, to confirm a purchase transaction or acknowledge data loss, define a a this type of card as they may be difficult to select.

Example 8-5

</card> <card id="makechoice2" title="Your choice"> <do type="accept" label="Yes"> <go href="http://www.myservice.com/somethingnew.wml"/> </do> <do type="prev" label="No"> <prev/> </do> <p> Are you sure you want to exit? </p> </card>

<do type="accept"> task with a Yes label to render on the left softkey and

prev task with the label No to render on the right softkey. Do not provide links on

Example 8-5 shows how to define a prev task with a softkey labelled No. When the user presses the No softkey the

onenterbackward event rejects the confirmation

and returns the user to the previous card.

February 2001 Genie Application Style Guide 49

Page 54

Displaying Text

50 Genie Application Style Guide F e bruary 2001

Page 55

Chapter 9 Data Entry Queries

If the user must enter numeric or alphanumeric information, the application can use data entry queries to elicit it.

Shared Feature Set: Data Entries Guidelines

■ Minimise the number of input fields requiring alphanumeric entry.

It is difficult and time consuming to enter text on mobile phones. Use selection lists, when possible, to avoid data entry. Other strategies are to store the user’s entries and reuse them when appropriate.

■ Include a descriptive label for the <do type="accept"> task.

For example, use the label Find in applications that allow the user access information from a database.

■ Include both a descriptive title of 18 characters or fewer and an <input>

element of 15 characters or fewer.

On some phones, the title lets the user know what to enter. On others, the <input> element is used.

February 2001 Genie Application Style Guide 51

Page 56

Data Entry Queries

Example 9-1

Openwave Browser

First and last name: John Doe

ALPHA Send

Nokia 7110 Browser

----- Order Info -----

irst and last ame:

]

First & last name:

John Doe

ptions

First and last name:

</card>

Back

Clea

Example 9-1 shows how to create a card requesting data. Note that only one action label can be defined.

■ Limit input elements to 254 characters.

■ Make password fields numeric only, when possible.

It is easier to enter numbers than letters or symbols.

■ Do not mask alphanumeric passwords.

Do not mask the entry. It is eas ier for the user to hide the display from others than to type with masked characters.

■ User names can be no longer than 32 characters; pass w ords, no longer than 20.

Discourage long passwords by limiting the length.

Openwave: Data Entries Guidelines

■ Define only one action label for entry cards.

Use only one <do type="accept"> action. Additional options will hide primary navigation from the user.

■ Do not have text or links following a <select> or <input> element.

This will render on what feels like a separate card, and is inefficient for the user.

52 Genie Application Style Guide F e bruary 2001

Page 57

Data Entr y Q uer ie s

■ Limit text before a <select> or <input> element.

The browser will automatically ensure that the initial selected item or the input field is visible. If there is significant information above this then the user may need to scroll UP in order to see it. T e xt prior to these elements should be considered as a prompt for the element itself.

Nokia and Mitsubishi Trium: Data Entries Guidelines

■ Define a link to allow the user to navigate to the next card following a card with

an <input> element.

Provide a link following all the <input> and/or <select> elements on a card to allow the user to easily navigate to the next card.

February 2001 Genie Application Style Guide 53

Page 58

Data Entry Queries

54 Genie Application Style Guide F e bruary 2001

Page 59

Chapter 10 Formatted Entry Fields

In some applications, the data entry queries can provide specialised format fields. These guide the user in entering the req uired information. F or ex ample, if user mus t 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.

Shared Feature Set: Formatted Input

■ Create informative titles.

For example, if the field requires a date in a specific format, the field title should indicate what is required (mmyyyy) or “5 digit zip code”.

Example 10-1

Openwave Browser

Date (mmyyyy):

</card>

Example 10-1 shows how to create a card requesting formatted data. T he field accep ts only numeric input of six digits. The label also informs the user what input is expected.

February 2001 Genie Application Style Guide 55

Page 60

Formatted Ent ry Fi elds

■ Force the entry type to numeric or alpha, if appropriate.

For example, in some environments, postal codes are numeric only. For those countries, force the entry type to numeric so that the user cannot enter alphabetic characters.

■ Restrict the length of the string, if required.

This is helpful for phone numbers or credit card entries. For example, use

maxlength="N"; where “N” is the maximum number of characters to limit the

length of the entry. Use NNN if exactly 3 numb ers are required along with the

maxlength attribute.

Example 10-2

Zip code:<br/>

Example 10-2 shows how to define a maximum length for an input string.

■ Prefill known data.

With the Openwave browser, Mitsubishi Trium and Nokia 6210/6250 (but NOT the 7110 with browser version prior to 5.0) including forced characters in the format can help the user as they will need to enter less information. For e xample in an expiry date for a credit card field the format of NN\/\2\0NN could be used – this would only require the user to enter four digits for any month from January 2000 to December 2099.

In addition, with ALL browsers specifying a default value where one is sensible (or can be derived from personalisation information) avoids large quantities of data input. For example where a login and a password is absolutely required in some mcommerce sites consider pre-filling the username (which the user can always change) but not the password.

Openwave Formatted Input

■ Set the default input mode to numeric when the entry typically is numeric or

starts with a number, but also allow the user to enter letters or symbols.

For example, phone numbers generally consist of number s only, but in some cases the user may also need to enter a special character, such as + or #. This applies to postal codes for some countries, purchase orders, ticket confirmations, and part numbers.

Example 10-3

Example 10-3 shows how to use type="phonenum" so that the input mode is initially numeric but so that users can change to alphanumeric or symbol mode.

56 Genie Application Style Guide F e bruary 2001

Page 61

Formatted Entry Fields

■ Include symbols in the forma t to simplify te x t entry.

Use symbols (such as / : ; - or even spaces ) in the formatting string to indicate the expected input.

Example 10-4

NI no:

Example 10-4 shows how to embed s pecial characters in the input f ield. This provides better visual information to the user . For example, all UK National In surance numbers are of the format two letters, six digits and a letter, but the six digits are normally written in three groups of two. This helps the user to recognise information as they enter it, and helps them avoid mistakes.

■ When using the format nN or nM, keep in mind that the user can enter from 0 to

n digits or characters.

■ Set the proper case (lowercase or uppercase).

Example 10-5

State (2 Letter Code)

Example 10-5 shows how to set the appropriate case when the user first accesses the input field. Here the letter A is for a letter whose case cannot be changed.

■ Use M*m formatting to obtain sentence-like formatting.

Example 10-6

Last Name:

Example 10-6 shows how to set the case.

Nokia Formatted Input

■ Do not include symbols in the formats.

Some phones will not accept symbols and may even f ail if symbols (such as / : ; -) are supplied in the format.

■ In phone number entries, use appropriate formatting.

If the field requires the user to enter a special character (such as + or #), do not define a format. Also, remember that phone numbers can vary in length (7, 10, 11 digits), so do not format for length.

■ When using the format nN or nM, keep in mind that the user must enter exactly

n number of digits or characters.

February 2001 Genie Application Style Guide 57

Page 62

Formatted Ent ry Fi elds

■ Use the maxlength attribute to prevent users from losing entered data.

When the user exits a data query format ted with 3N (NNN) or 3M (MMM), the data is lost when the user does not enter exactly 3 numbers or characters. Set the attribute and state the number of required number of characters in the title to inform the user and avoid lost data.

■ The emptyok="false" attribute has no effect.

This attribute does not prevent the user from leaving an input field empty.

Mitsubishi Trium Formatted Input

Formatted text entry is similar to the Openwave browser with the following exception:

■ Always provide a short descriptive title as part of the element

This will be displayed when the user is editing the data

■ Handsets vary with their treatment of format strings

One handset type requires a format of M*m to con tain at least two characters, another type will accept a single character input with a format of Aa*a but will add a line feed character to the data that is entered to make it two characters long.

maxlength

■ The emptyok="false" attribute has no effect.

This attribute does not prevent the user from leaving an input field empty.

58 Genie Application Style Guide F e bruary 2001

Page 63

Chapter 11 Forms

Forms can encompass one or more display or action types on a card or set of cards. There are two primary types of forms: forms that allow the user to enter information sequentially (wizard forms) and forms that show all of the fields in one list and allow users to choose what data to enter (elective data forms).

Shared Feature Set: Wizard Forms

■ Use a wizard form whenever possible.

User tests show that wizards are always easier to use. Elective data forms require the user to focus on navigation instead of entering data, and mistakes are often made. This is particularly the case for Openwave browsers – the navigation features wit hin the browsers make wizard forms very quick for users to navigate. The different presentation model of the Nokia and Mitsubishi browsers means that presenting all information in one card is sometimes more efficient for the user.

■ Link cards in a logical order.

Provide a logical order that suggests what needs to be entered or selected and why.

■ Include descriptive text and titles for all <input> or <select> elements.

■ Place each <input> or <select> element on a card of its own.

■ The primary action should access the next card in the sequence.

Bind the action of <do type="accept"> to the next card with a required field.

■ The primary label for all cards in the sequence, except the final card, should

be Next.

The label for the last card in the wizard should explain the final action, such as Save, Send, Order, or Buy. Limit the label to five characters.

■ Create a final verification card displaying all entered or selected values.

Allow the user to change the values if necessary.

■ Return to the first card in the wizard form for backward navigation.

Many devices ha ve shared Clear and Back ke ys for te xt input. For this reas on, the user must delete the information in the card before returning to the previous card. To prevent this, map the Back key to the first card in the form. In this way, users can revisit the cards without deleting the information they already entered. See “Backward Navigation” on page 39 for more information.

February 2001 Genie Application Style Guide 59

Page 64

Forms

Openwave Wizard Forms

■ Separate cards are not needed for each of the <input> elements.

It is not necessary to place separate <input> elements on individual cards; however, doing so ensures breaks between the elements and allows for control of backward navigation. See the section “Backward Navigation” on page 39 for details. If all

<input> elements are placed on the same card, the label OK is automatically bound

<do type="accept"> key, and pressing OK takes the user to the next def ined

to the

<input> element. When the last <input> element is reached, the label defined for

<do type="accept"> action is used.

the

■ The primary label for all cards in the sequence, except the final card, should

be OK.

The label for the last card in the wizard should explain the final action, such as Save, Send, Order, or Buy. Limit the label to five characters.

■ Text and links and links following a <select> or <input> element renders on a

separate card.

Cards that have a <select> or <input> element followed by a link or text will automatically render on another card when the user accepts the input or makes the selection. This may cause unnecessary extra keystrokes.

■ Limit the number of c haracter s preceding a <select> or <input> element to 30.

Long text preceding the option or input field will scroll off the screen.

Nokia Wizard Forms

■ Provide a link following the <input> or <select> element to the next card in the

sequence.

In addition to binding the <do type="accept"> action, include a link after the required input.

Example 11-1

Nokia 7110 Browser

------ Order Info -----

Name (first & last):

[ ] Next

Options

Back

In Example 11-1, the Next link allows the user to easily navigate to the next card in the sequence without having to select Next from the Options menu.

■ The label for the last link in the wizard should be no longer than 18 characters.

Name (first & last):

John Doe

Clea

60 Genie Application Style Guide F e bruary 2001

Page 65

Forms

Mitsubishi Trium Wizard Forms

The guidelines for the Mitsubishi Trium are similar to the Nokia, with the following exception:

■ Provide a link following the <input> or <select> element to the next card in the

sequence.

Do not provide a <do> action as well.

Example 11-2

<card id="empdata" title="Database"> <p> Name (First Last) <input name="employee" title="First Last"/> <a href="#empdata1" label="Next">Next</a> </p> </card>

<card id="empdata1" title="Database"> <p> Date of birth (DDMMYYYY) <input name="dob" title="DDMMYYY" format="NNNNNNNN"/> <a href="#empdata2" label="Next">Next</a> </p> </card>

<card id="empdata2" title="Database"> <p> Phone extension (4 digits) <input name="ext" title="Extn. (NNNN)" format="NNNN"/> <anchor label="Send">Send <go href="commit.cgi" method="post"> <postfield name="empname" value="$(employee)"/> <postfield name="dateofbirth" value="$(dob)"/> <postfield name="phoneext" value="$(ext)"/> </go> </anchor> </p> </card>

Example 11-2 shows how to create a link labelled Next that will allow users navigate from one card to the next. Provide an intuitive label for the final li nk in the sequ ence to confirm the action (for example "Buy", "Save", "Send").

February 2001 Genie Application Style Guide 61

Page 66

Forms

Shared Feature Set: Elective Data Forms

■ Always try to find alternatives to using elective data forms.

Use a wizard to link sequences of input queries and selections within an application. For example, if the user must supply a city, state, or zip code in a phone number search, use a menu from which the user selects one of the three. Then use a wizard to elicit the input.

■ Provide an appropriate label for the primary action.

Label the <do type="accept"> element with the desired result. For example, in a search query, define the

■ Display a final card showing the selected or entered results for all fields.

<do type="accept"> label as Find.

When the application saves us ers data fo r futu re access, p rovide a card displaying the data entered and the elements on the form. For example, in an address book application, it shows the user all the data entered for that contact.

Openwave Elective Data Forms

■ Display the user’s entered data on the form.

Provide a card with the elements and v ariable stri ngs to display the entered o r selected values. Build a form. Within the card containing either a name of the

Example 11-3

Openwave Browser

1 First name: John 2 Last name: 3 Zip: 92109

Find Edit

</spawn> </onevent> First name: $f

</option>

<select> statement with an <option> element for each item on the

<option> element, use the <onpick> action to access a second

<input> or <select> element (as desired). Include the

<input> or <select> element in the text associated with the option.

Doe

Example 11-3 shows how to ad d a v ariable strin g to the end of a menu item to dis play the entered data to the user.

62 Genie Application Style Guide F e bruary 2001

Page 67

Forms

Nokia and Mitsubishi Trium Elective Data Forms

■ After the final field, add a link performing the final function.

For example, if the card is a contact search form, add a Search link that allows the user to search on the entered and/or selected fields.

Example 11-4

Nokia 7110 Browser

----White Pages ----- Options items:

Last name:

[Smith] First name: [Andrew]

Options

Zip: [92109 ] Search

Back

The Search link in Example 11-4 allows the user t o search on the entered fields without having to select the Options softkey and then the Search item.

Edit Search Done

February 2001 Genie Application Style Guide 63

Page 68

Forms

64 Genie Application Style Guide F e bruary 2001

Page 69

Chapter 12 Icons and Images

Images can enhance or support the displayed information so that the user can quickly review a list of items or see a trend. For example, a weather report can display a date along with an icon of the predicted weather. Likewise, an up/down arrow can precede a stock quote.

Shared Feature Set: Image Support

■ Images need to be in wbmp format.

■ Always include descriptive alt text for devices that do not support images.

■ If the phone talks to an UP.Link Server Suite , the server will compile 1-bit bmp

images to wbmp form.

■ The WAP Forum does not currently define an animated image format.

■ Do not define associate functions for areas within an image.

There is no way to associate an area within an image to an action (that is, there is no image map function).

■ Be careful using images on cards with a timer element, because the timer may

expire before the image is loaded.

Openwave Image Support

■ Images larger than the display size are scrollable ver tically, but not horizontally.

Thus, make images no wider than 40 pixels.

■ Use preloaded images.

Openwave offers localsrc images that are preloaded into the devices that support images. The use of these images shortens network access time and creates a consistent user experience. A list of the the WML reference that ships with the UP.SDK from Openwave, which can also be accessed at UP.SDK Developer’s Guide for localsrc images.

■ Images will be aligned according to the attribute of the <p> element.

■ Images can be displayed inline (along with text or a link).

http://developer.openwave.com. See the “Image” section in the

localsrc images is available in the “Images” section of

February 2001 Genie Application Style Guide 65

Page 70

Icons and Images

■ Images can be included in an <option> element, if the extension DTD is

being used.

This will allow an icon to be displayed on the same line as a menu item.

Example 12-1

<option onpick="my_url"><img localsrc="envelope" src="" alt=""/>Email</option>

Example 12-1 shows how to embed an image inline with a men u item. In this case, an envel ope is displayed before the text (

■ When delivering a deck that calls images, consider the use of a digest so that

the image is displayed when the card has finished loading.

This will load the deck and image simultaneously. The maximum digest size must be less than the MAX PDU, which is device specific but is approximately 2000 bytes.

This technique is also useful for pre-loading images that will be needed later in an application as the images are put into the cache of the handset.

Nokia Image Support

 Email).

■ The maximum display size for an image is 96 x 44 pixels.

■ Images are centred and displayed wit h nothing else on the line.

Images wider than 96 pixels are left aligned and cropped on the right. Images longer than 44 pixels are sometimes scr ollable, depending on the other con tent of the card. A link immediately below a tall picture can mean that it is not possible to see all of the picture.

6210/6250 handsets (and the 7110 with a browser model 5.00 or later) left align the image rather than centring it.

Mitsubishi Trium Image Support

■ Images can be displayed inline (along with text or a link).

Example 12-2

<img src="envelope.wbmp" alt=""/>Email</option>

Example 12-2 shows how to embed an image inline with a menu item. In this case, the envelope.wbmp is displayed before the text (

■ Ensure that the alt tag deck has meaning when image support is disabled by

the user.

The alt text will show in angle brackets – for example <test>

 Email).

■ The gif image format is supported.

66 Genie Application Style Guide F e bruary 2001

Page 71

Chapter 13 Cache

Cache management is important for allowing quick access to previously viewed cards and controlling the display of time-sensitive content.

Shared Feature Set: Caching

■ Do not leave time-sensit ive data, such as stock quot es, in the cache.

■ Use a cache-control directive to specify how long a deck should persist in the

cache of a device.

A cache-controlled directiv e can prev ent users from accessi ng outdated time-sensiti ve information, such as weather, traffic, or a stock quote. Cache-control directives are at a deck level rather than a card level.

Example 13-1

In Example 13-1, the value 600 represents the number of seconds the data should be marked as valid the cache.

■ Do not build an application that relies on information residing in the cache.

Openwave Caching

■ The default TTL (time to live) for a deck is 30 days or until memory is exhausted.

■ Allow the browser to prefetch the next deck when the user is likely to access the

next card.

For applications providing textual information that users are likely to access in sequence, such as news or email.

February 2001 Genie Application Style Guide 67

Page 72

Cache

Example 13-2

<head>

</head> <card id="page1">

Page 1 of 2<br/>

... </p>

</card>

Example 13-2 shows how to prefetch the content of the next card. When the user loads the deck, current deck is completed loading. This ensures that cache when the user presses the

■ Force the reloading of the deck for dynamic data.

page2.wml is automatically loaded in the background as soo n as the

page2.wml is already in the

<do type="accept"> key .

Example 13-3

Example 13-3 shows how to force a reloading of the deck each time the card is accessed in the forward or backward direction.

Nokia Caching

■ Force the reloading of a deck for dynamic data.

Example 13-4

Example 13-4 shows how to force a reloading of the deck each time the card is accessed in the forward or backward direction.

■ The maximum cache size is 40KB, and the maximum size for a single compiled

deck is 1397 bytes.

■ The default TTL for a deck, if one is not defined, is one day.

Mitsubishi Trium Caching

The cache behaviour is unknown; however, the default cache time is approximately one hour.

68 Genie Application Style Guide F e bruary 2001

Page 73

Chapter 14 Cookies and Subscriber ID

Use cookies to store data, thereby reducing the amount of information the user must enter. The subscriber ID may also be used to personalise a service.

Shared Feature Set: Cookies

■ Cookies are not stored in the phone.

However, the phone can access cookies if it is connected to an Openwave UP.Link Server. If it is unknown whether the device will be accessing an UP.Link Server, the information should be stored on the server where the application resides.

■ Use cookies as needed.

Cookies may save the user from continuously needing to enter data from the keypad. If specific information needs to be stored, provide a login so the application can validate the user and access that user’s personal information. Dynamically configure the login menu item so that it is displayed only if the application cannot identify the user. Although the Genie gateway supports cookies, note that there is no guarantee that all network gateway/browser combinations will universally support them.

■ If session information needs to be retained, cons ide r the use of URL rewriting.

Shared Feature Set: Subscriber ID

■ Use the Subscriber ID to allow the user to personalise the application.

The Genie Gateway delivers the subscriber ID in every HTTP request with the following HTTP header:

HTTP_X_UP_SUBNO

A database can be used to identify subscriber an d personalise the application based o n what the user is doing.

February 2001 Genie Application Style Guide 69

Page 74

Cookies and Subscri ber ID

70 Genie Application Style Guide F e bruary 2001

Page 75

Chapter 15 Labels and Links

Depending on the type of application and type of information displayed, consistent labels should be used within the application and across other applications. Only the first letter of the label or link should be capitalised unless the word is always capitalised, such as OK.

The following labels apply to the Openwave and Mitsubishi Trium browsers since both browsers can display the title or label attribute as the softkey labels. However, these labels can also be used for the Nokia 7110 browser.

Accepted Labels and Links

■ OK: Used to select a menu ch oice in a choice card.

Can also signify agreement to an operation, such as sending an email message.

■ Done: Used to allow the user to cancel the operation.

Used to return the user to the Home deck, main menu, or intuitive card within the application.

■ Skip: Used to lead to similar data, such as the next news article or email

message.

Skip should always be the first softkey when used. May be repeated as a link at the end of a page as well.

■ View: Used to select an item in a menu of similar data, such as a list of stock

quotes or email messages.

Must provide additional detail. If Times Square scrolling was used to display the list data, pressing View should redisplay the data.

■ Details: Used as a link to get details of an item, such as a news article that is

summarised by a headline.

If information continues on another page, then use More instead of Details.

■ More: Used as a link at the end of a page of data to see the next page of related

and similar data.

February 2001 Genie Application Style Guide 71

Page 76

Labels and Links

Conflicting Labels and Links

The following labels may conflict with items on a browser menu and may mislead the user.

■ Back: Not used for entry query cards.

Back returns the user to the previous card in the histor y list. All three bro wse rs hav e a dedicated Back key. Avoid defining a Back softkey on for the Openwave and Mitsubishi Trium browsers since users tend to rely on that rather than the dedicated Back key. Back on the primary softkey should be assigned to the

<do type="accept"> task only if no label for the <do type="options"> is

defined. If required, Back should be assigned to the only if no other

■ Exit: May imply exiting the browser.

■ Next: Often misinterpreted by users when used as a link.

<do type="options"> labels are required.

<do type="options"> label

However, Next may be used as a softkey label in some wizard forms for the Nokia 7110.

■ Home: May imply the browser’s home card.

■ Bookmark: May conflict with the browser menu.

72 Genie Application Style Guide F e bruary 2001

Page 77

Appendix A Identifying the Browser

Several classes of web clients could potentially access your site, but for the sake of simplicity, this appendix addresses four possible situations:

1 A client that expects HTML 2 A Nokia 7110 browser 3 A device with the UP.Browser v3.1 or 4.x that supports WML 1.1 4 A Mitsubishi Trium browser

To identify which client is accessing your site, investigate two different HTTP headers,

HTTP_ACCEPT and HTTP_USER_AGENT. While neither of these is part of the WAP

specifications, they are both standard HTTP headers defined in RFC1945 (see

http://www.rfc-editor.org/rfcsearch.html).

The fir st st e p is to look the

text/vnd.wap.wml:

■ Perl

#!/usr/local/bin/perl

$acc = $ENV{"HTTP_ACCEPT"}; $ua = $ENV{"HTTP_USER_AGENT"}; if ($acc =~ "wml"){

deliver wml

} else{

print' Location: http://mysite.com/index.html'."\n\n";

}

HTTP_ACCEPT header and parse it for the inclusion of

February 2001 Genie Application Style Guide 73

Page 78

Identifying the Browser

■ Java

public void doGet (HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException{

String acc = req.getHeader("Accept"); String ua = req.getHeader("User-Agent"); ServletOutputStream out = res.getOutputStream();

if (acc.indexOf("wml") != -1){

deliver wml } else {

res.setHeader(res.SC_MOVED_TEMPORARILY);

res.setHeader("Location", "http://mysite.com/index.html"); }

■ ASP

<%response.buffer="true"

Dim accstring Dim uastring uastring = request.ServerVariables("HTTP_USER_AGENT") accstring = request.ServerVariables("HTTP_ACCEPT")

If (InStr(accstring,"wml")) Then

Deliver wml

Else

Response.Redirect("/index.html")

In all of these cases, it has been established that the client sends WML in the

HTTP_ACCEPT header and can thus assume that WML should be deli v ered. If WML is not

found in the

HTTP_ACCEPT list, HTML is delivered. This ensures that HTML is delivered

to web browsers and to spiders (crawlers, site indexers). Once a WML device is found, it is possible to discriminate further to see exactly which

device is accessing the site. Three possibilities are accounted for in this code: (1) the UP.Browser from Openwa ve, (2) the Mitsubishi Trium (3) an y other device (including the Nokia browser).

■ Perl

if ($ua =~"UP.B" || $ua =~"UP/"){

Print "Location: /opwv/index.wml \n\n"; } elseif($ua =~"Mitsu"){

print "Location: /mitsu/index.wml \n\n"; } else{

print "Location: /nokia/index.wml \n\n"; };

74 Genie Application Style Guide F e bruary 2001

Page 79

Identifying th e Browser

■ Java

if ((ua.indexOf("UP.B") != -1)) || (ua.indexOf("UP/") != -1)){

res.setHeader(res.SC_MOVED_TEMPORARILY); res.setHeader("Location", "/opwv/index.wml");

} elseif(ua.indexOf("Mitsu") != -1){

res.setHeader(res.SC_MOVED_TEMPORARILY); res.setHeader("Location", "/mitsu/index.wml");

} else{

res.setHeader(res.SC_MOVED_TEMPORARILY); res.setHeader("Location", "/nokia/index.wml");

};

■ ASP

If((InStr(uastring, "UP.B")) || (InStr(uastring, "UP/")))

Response.Redirect("/opwv/index.wml")

ElseIf(InStr(uastring, "Mitsu"))

Response.Redirect("/mitsu/index.wml")

Else

Response.Redirect("/nokia/index.wml")

February 2001 Genie Application Style Guide 75

Page 80

Identifying the Browser

76 Genie Application Style Guide F e bruary 2001

Page 81

Appendix B Differences between

Browser Types in Same Class

Genie strongly recommends that developers provide content that is tailored for the Openwave, Nokia and Mitsubishi browsers as detailed in the information above. The recommendation may become mandatory in time for content to be considered for the Genie Portal.

Genie under stands that some developers may wish to take further advantage of the particular features offered by certain browsers. This is acceptable provided that all phones in that class are supported to at least the level defined above. It is not acceptable, for example to deliver content that is tailored for the features of a Nokia 6210 but which is very difficult to use on a Nokia 7110.

The following tables show observed differences between two Nokia variants and two Mitsubishi variants. These have been identified by observation only – if y ou use them you should check on real handsets that the behaviour is what you expect.

Table B-1. Nokia browser types

Nokia 6210, 6250 and 7110 with version

Behaviour Nokia 7110 (browser version 4.xx)

Differentiation HTTP_USER_AGENT string contains

Nokia7110/1.0 (04

Layout tags All text is left aligned and wraps Text may also be centre and right aligned.

T ables Every cell on a table is laid out on a line of

its own. It is recommended that tables NOT be used

5.00 or greater

<p mode="nowrap"> can have an effect, b ut

it is recommended that this is NOT used as reading the text can be difficult

Tables are formatted acceptably by the browser

February 2001 Genie Application Style Guide 77

Page 82

Differences betwe en Browser Types in Same Class

Table B-1. Nokia browser types (continued)

Behaviour Nokia 7110 (browser version 4.xx)

Nokia 6210, 6250 and 7110 with version

5.00 or greater

Images Non-breaking space

character

Behaviour Earlier browser type Later browser type

Where found Believed to be only in Trium Geo@

The browser does not enter fixed characters (those preceeded by a backslash) automatically, and may not handle the change between character type A and character type N sensibly.

It is recommended that forced characters NOT be used

A format such as 3N will only accept three digits (so NNN3N requires six digits

Forced characters are inserted by th e br owser at appropriate points during the data input. The browser also handles changes between character types in input statements acceptably.

Forced characters may be used. A format such as 3N will accept between 1 to

3 digits (so NNN3N will accept between 4 and 6 digits)

Images are centre aligned Images are left aligned Typically ignored, and not wr itten as a

Correctly represented on screen

space

Table B-2. Mitsubishi Trium browser types

Believed to be only in Trium Mars@ handset

handset

Differentiation Both contain identical

HTTP_USER_AGENT string. HTTP_ACCEPT header does not contain

text/x-vCard

HTTP_ACCEPT text/x-vCard

header contains

Softkey behaviour Left hand so ftkey is fixed as a labelled

<do> action if exactly one non- <prev/>

one exists, nothing if none exist, or Card (providing a menu) if more than one exists.

Right hand s oftkey provides Back functionality (executing

<prev/>) which

may be relabelled. The right hand key changes context depending on what is highlighted on screen – a link will cause the title (or link) to be displayed, and

<select> and <input> items can be

highlighte d and entere d.

Right hand softkey provides fixed Back function which can be relabelled (and repurposed – see below)

If no

<do> actions of type not bei ng "prev"

are defined, left hand key is context sensitive, allowing links,

items to be entered. If exactly one

"prev" is defined the left hand key is bound

<do> action of type not being

to this action and labelled and is not context sensitive (links,

must be accessed by other means). This is NOT recommended.

If more than one being

"prev" is defined the le ft hand key

<do> action of type not

says Card, and links to a menu of the actions in the order of their definition. As above, links,

<select> and <input> must be

accessed by other means.

78 Genie Application Style Guide F e bruary 2001

Page 83

Differences betw een Browser Types in Same Class

Table B-2. Mitsubishi Trium browser types (continued)

Default action labelling

Unlabelled <do> is labelled with the type (truncated to fit, if necessary)

Unlabelled

is labelled OK – all others are labelled with the type (truncated to fit if necessary)

Back key handling Example of

Layout tags

The back key can only have the action

<prev/> – any attempt to make it have a

different action will leav e the ke y in place. The example code will show up as an

action labelled "Main" on the left hand key (or down a Card menu) – "Back" will still show on the right hand key.

<p mode="nowrap"> has no effect. <small> text is smaller than normal text. <u> does not underline text

The back key may be redefine d with any action.

The example code will label the right hand key Main, and will go to home.wml

<p mode="nowrap"> truncates text to the

screen width. There is no obvious mechanism to read the rest of the text. Use of this is not recommended.

<small> text is the same size as normal te xt. <u> underlines text – not recommended as

looks like a link.

Key accelerators There are none If a user presses a number key on a card

which is a list of links, the phone navigates to the corresponding link. For example, if the user presses key “4” the 4

link is followed.

The browser does not provide numbers.

example

sendreferer in

<go>

statements

The "*" prequalifier requires at least one character to be accepted.

The example would accept only three or more characters of input.

The full absolute URL is sent, irrespective of whether a relative one could be used.

The “*” prequalifier will match zero or more characters. Where Alphabetic characters are required, the browser may pack incomplete entries with an underscore character.

The example would accept two or more characters of input. If the user enters only ONE character, an underscore character will be insert ed by the browser to make up th e required characters.

Part of the referring URL is sent. This behaviour has not been completely characterised and may be incomplete. Where a relative URL could be provided, only the leafname was returned (even if this did not provide the proper path). For a URL which would need to have been provided as a full absolute URL the referrer has been presented as

//www… (i.e. missing the http).

Developers relying on this for security should check what gets sent with real handsets and verify that it meets their security objectives.

February 2001 Genie Application Style Guide 79

Page 84

Differences betwe en Browser Types in Same Class

80 Genie Application Style Guide F e bruary 2001