Screen Design

From MobileDesign

Design patterns:

---

The screen design patterns apply to the design of individual screens in myriad situations. Many have implications for application architecture or the design of other screens.

[edit] Screen Design

Information in this chapter pertains to the design of all screens. Later sections will apply to specific types of screens.

(old)An application is made up of one or more screens, which may be high-level (List, Form, Alert) or low-level (Canvas). The user, however, doesn't care about what type of screen it is, and there are several design points that should be consistent throughout the application. This chapter, therefore, covers aspects of screen design that apply to all screens.

[edit] Title and Header

This guide refers to both "titles" and "headers", because many platforms explicitly use a title element to create a screen title. However, not all devices display such titles, and many users do not notice the title anyhow -- on the PC, users are accustomed to ignoring the information in the title bar of a window, and on some devices, they do the same.

Header -- the text at the top of the screen giving the user context for the screen. Because many people ignore areas of the screen devoted to titles (e.g., the title bar), and because many devices do not display the title element, this is specifically not the title.

Title -- the title element within the platform language. Some devices have a fixed area on the screen that displays the title, whether you specify one or not. Some devices ignore the title completely, and some devices use the title as the default bookmark name.

Hence, "header" is a design term, and "title" is a programming term.

[edit] The following recommendations apply to all situations.

Each screen must be understandable and unambiguous in the absence of the title element. Some users do not look at the title. More importantly, some devices do not display the title. Do not rely on the title to convey critical meaning.

Avoid non-standard abbreviations. Users probably won't understand them.

The header of a screen should tell users what they need to do on the screen. This is true unless the goal of the screen is obvious or if there is no action required of the user. There is no need to tell the user to pick an item in a menu or list, nor to type in an entry screen. Hence titles can skip verbs. Example titles include "Pick State" ("State" if space constrained), "Select Pizza Toppings" ("Pizza Toppings" if space constrained), and "Enter Home Address" ("Home Address" if space constrained).

(old)

− Use mixed-case format for titles and headers. Mixed-case format (or title-case format) is easier to read than all upper-case, and the device can use other methods to distinguish different parts of the page.

− Use caution when switching between full screen (unstructured) mode and structured mode without user intervention. If the title and ticker disappear and reappear without visible cause, the user will be distracted and possibly confused.

− Provide an option for the user to switch to unstructured mode.

(endold)

[edit] The following recommendations apply to Palm.

Keep screen titles understandable within the first 12 characters. Palm devices display the title as a tab that does not take up the full screen width. Some browsers or environments use the area to the right of the tab for controls, and thus truncate the title at approximately 12 characters

Keep screen titles limited to approximately 12 characters.

[edit] The following recommendation applies to Nokia WML.

A title should be set for each card. This gives the user context for the whole screen, and ensures a predictability across screens. Note that the Openwave WML browser does not display the title.

[edit] The following recommendations apply to XHTML Basic.

A title should be set for each page. While some devices do not display the title, most use the title as the default bookmark label. Without the title, the default bookmark label is the URL -- not very useful!

Keep the title short (12-14 characters). Some devices only allocate 1 line to the title. This recommendation also applies to phones.

Use mixed-case format for titles and headers. Mixed-case format (or title-case format) is easier to read than all upper-case, and the device can use other methods to distinguish different parts of the page.

[edit] Screen Layout

[edit] The following recommendations apply to all situations.

Make sure content is visible upon entering page. Bold textIf the content is an image, make sure something is visible upon entering the page, even before image loads (this may be relevant if you define dimensions for your image). Note that the alt text will appear upon entering the page.

Your screen layout should work with and without graphics. Early XHTML browsers download pages in a characteristic way: first they download and render the text page, including alt text for the images. Then they download images, replacing alt text where appropriate. This behavior means that the user will see the alt text for every image on every screen. Further, some users will have graphics turned off.

Avoid more than 2 consecutive blank lines. Users will believe they are at the bottom of the page.

[edit] The following recommendations apply to XHTML Basic.

Avoid span tags. Many devices have problems rendering these. Use div instead.

When the first focusable element on the screen is an input field, do not use access keys. When the user tries to use the access keys, the device may go into text entry mode.

Be consistent with content alignment. Consistent alignment can make content more readable. Using many varied alignments on the same page makes it harder for the user to scan.

Avoid multiple-choice select lists (selects lists with 'multiple="multiple"'). We have little information about how these might be rendered on different devices. They may be pull-down menus, they may be separate screens. They may take over the softkey, they may not. Use checkboxes instead.

[edit] Tables

In the desktop web environment, site designers have used tables to enable precise control over how a page is arranged. In the mobile environment, device capabilities and display size make this practice inadvisable. Most platforms do not allow nested tables.

[edit] The following recommendations apply to XHTML Basic.

Use tables to organize data, not as screen layout. Devices render tables somewhat arbitrarily, so you won't be able to control the screen layout as much as you would like. Thoroughly test your screen on all available devices. The small screen does not lend itself to a visual layout other than a simple layout. Samsung browsers, for example, fit every table to the width of the screen and makes the columns equal width. Use definition lists (dl) in XHTML.

Ensure your tables are not wider than the screen. Scroll-and-select devices usually have no convenient method of scrolling left-to-right. Even devices with a 4-way navigation button usually do not allow left-to-right scrolling in the browser. A wide table will, at best, cause the screen to jump around as the user scrolls. At worst, there will be content in your table that the user is unable to see. This recommendation also applies to scroll-and-select devices.

Use percentage rather than fixed width tables. This will help avoid tables wider than the screen.

Use extreme caution when using tables for layout with Samsung devices. Early Samsung XHTML Basic browsers make every column in the table equal width, with the width determined by the widest calculated column. Your layout will almost certainly be destroyed. This recommendation applies to Samsung.

Ensure that the table width is less than the screen width. A table width of 100% or greater causes the Openwave browser to render the table as plain text. This recommendation applies to Openwave.

Avoid a table width greater than the screen width. Users will have to scroll too much. Further, since Samsung browsers fit the table to screen width, your wide table will likely be unreadable on these browsers.

Align table headers to the left and use default font styles using CSS. The default display for table headers is bold and centered. Typically, this text does not need the extra emphasis of being bold. Align it to the left so the content will line up with the heading.

Keep the number of rows and columns in a table to a minimum. Tables, and rows and columns, increase rendering time due to floating-point calculations, which is noticeable on the slow processors embedded in the phones. Try it out on a couple phones before deciding on a design.

Avoid tables with focusable items in the cells. Although some browsers, like Openwave, allow both horizontal and vertical scrolling through the table, others, like Access, do not. On these devices, the user will have to scroll "downwards" through every cell in the first row before accessing any cell in the second row. Exception: month calendars are an acceptable use of focusable items within tables.

Never use form elements in the same row in a table. On Access browsers, users will have to scroll up, not down, to get to the next cell. They will assume they can't get to the next cell at all. This recommendation applies to Access.

Align table captions to the left and use default font styles using CSS. The default display for table captions is bold and centered. Typically, this text does not need the extra emphasis of being bold. Align it to the left so the content will line up with the caption. This recommendation applies to Openwave.

Vertically align table content to "top". If you must wrap table data cell content, then align the content consistently to the top. The default vertical alignment is middle. When content wraps, some text will display in the middle of the row and some will display at the top. Use CSS to declare all content vertically aligned to "top" to remove inconsistency and improve content formatting.

Consider using CSS to alternate the background color of rows in a table. For devices that support the color, subtle background color difference between consecutive table rows may improve scanability. Ensure the colors contrast with each other and with any possible background or background color!!! If you're worried about it, specify a known contrasting color for the background color of the table.

Table captions should normally have the same font values as normal text within the table. A caption only serves as a short title for a table. When there is only one table per screen, there is little need to make the text stand out to distinguish it from surrounding information. The data within the table should be the user's focus.

Highlight table header text. The most common way to do this is to make the text bold. Use the CSS value: "font-weight: bold;".

Avoid defining content-table cells taller than the screen. The user will lose the context of the cell. Note that this is not a problem for tables used for the purpose of layout.

Use only one border type or thickness per table. Multiple border types will decrease table readability and increase user confusion.

Note: Devices do not support nested tables, so keep it simple.

[edit] Lists

Tables can be avoided in most situations, although some sites will require them. Some designers never use tables for their mobile sites, relying exclusively on lists.

Using lists for page layout also gives the designer a bit more control over text scrolling and wrapping behavior. On some browsers, the only way to accomplish <nowrap> is to have a focusable item such as a link as a list item, coupled with the the CSS "white-space: nowrap;" property. In all other cases, the browser will wrap the text, regardless of whether you specify the CSS property.

[edit] The following recommendations apply to XHTML Basic.

Design visually attractive pages using lists, not tables. Your page will render faster, be compatible across browsers, and not require sophisticated CSS.

Use unordered lists (ul) when you wish to have a bulleted list. Note that support for different types of bullets is variable across devices.

Use ordered lists (ol) when you wish to have a numbered list, and you do not need control over the number artifacts. If you need an item with a "0" accesskey, you will need to use a definition list (dl) instead.

[edit] Definition Lists

Definition lists are seldom used in designing desktop-focused web sites, but are exceptionally useful in designing for mobile devices. They are universally supported and give the designer some layout control without invoking the problems associated with CSS or tables. The defined term tag (dt) is displayed left-aligned and the definition tag (dd) is displayed on a new line, indented. This makes the definition list a superb tool for creating a list or menu where one or more items has "sub-items".

[edit] The following recommendations apply to XHTML Basic.

Use definition lists (dl) when you wish to have a list of items with no artifacts.

Use definition lists (dl) when you wish to have subsections of some items in your list.

Use definition lists (dl) when you wish to have a numbered list, but you need control over the number artifacts. If your numbers need to be bold, red, out of order, or have a 0 item, definition lists are useful. Don't forget to code the numbers for display as well as for accesskeys.

Ensure that any item with an accesskey defined displays the matching number. Otherwise, users will not know the accesskey exists.

Avoid div tags within list items. Samsung browsers introduce an extra line break with each div tag as well as an extra line break for each list item. The result is a list with too much extra space. This recommendation applies to Samsung.

[edit] Grouping Techniques

You, or your graphic design team, are probably accustomed to designing pages with a variety of "grouping techniques": background shading of headers, borders around regions, and different font colors. Some of these techniques require tables, which are covered above and should not be used. However, most of the others do not have relevance for small devices:

Content probably won't be on the screen at the same time, anyhow. When it is, you get "banding" effect, where coloring (and not your content) is the dominant feature of the screen. A primary use of the background shading is to easily see that two items are in the same row or horizontally aligned. The screen's too small for horizontal alignment to be an issue.

Thus,

[edit] The following recommendations apply to XHTML Basic.

Restrict the use of background shading for single lines (e.g., section headings). The top of the page plus perhaps one other location should be considered a maximum for using this grouping technique.

If you use background shading for text, use a very light color and retain a dark font. Note that some devices will not color text, so a dark background will create an unreadable page on some devices.

Restrict the use of colored header text to one color per page. Users will not gain information from multicolored headers and the resulting screen will look cluttered.

[edit] Styles (CSS)

To add to the rendering issues associated with XHTML, CSS support varies wildly across browsers. In fact, if you want to ensure that every browser renders everything in your CSS, you are restricted to the background-color and font-size properties. Please see CSS for Mobile Devices in Appendix 2 for information on profile, browser, and device CSS rendering.

[edit] The following recommendations apply to XHTML Basic.

Keep CSS elements to a minimum. More elements means more time for the page to render.

Avoid using shorthand for the CSS properties: "margin", "padding", "border-width", "border-style", and "list-style". They are optional CSS properties. Some may be used, but only when declared in a certain manner. Support is variable across browsers.

Ensure page content is readable without CSS. Devices that don't support CSS need to render content reasonably for users.

Do not embed images into external style sheets. The browser will make an http request to get the page, then an http request to get the CSS, then an http request to get the image, causing an unnecessary long delay for rendering.

Use in-line CSS (style type="text/css" element). This saves an http request, decreasing page load time by 1.5-2.5 seconds. Further, Openwave browsers load the external CSS after the main XHTML content, causing the content to jump around as the user looks at the page. Devices generally do not cache the external CSS, so there is no time savings across multiple pages.

Avoid using the CSS named font values "x-large" or "xx-large". Both values render the font as 13 pixels. One line of text this size may fill a quarter (or more) vertical space on small screens. This increases scrolling, which should be avoided. This recommendation applies to Nokia.

Don't include styles in the CSS that aren't used on your page. Every style you include increases both file size and rendering time.

Use the CSS value "text-decoration:blink" sparingly. Although 'blink' highlights an element, if overused it may detract from the overall usability. No more than one element per screen should use it. Few elements should ever need it.

You may use multiple values for the CSS "text-decoration" property, but NOT in the same CSS declaration. You may apply more than one "text-decoration" value to an element through inheritance. Do NOT declare more than one value within a single class or related set of property-value pairs. If you apply both values in one style declaration, only one value will apply. Although you may combine values, avoid underlining plain text as it might be confused with a link. This recommendation applies to Openwave.

Do not apply more than one style value to an element with the CSS "text-decoration" property. You may not apply more than one "text-decoration" value to an element, even through CSS inheritance. This recommendation applies to Nokia.

When possible, use cascading rules rather than class or id attributes. That is, use p {align:right} rather than .right {align:right}. This enables you to avoid defining class="right" each time you use the

element. Avoid use of bgcolor, link, and text attributes for the body element. It's better practice to use style sheets to control these aspects. Avoid specifying the list type for ordered lists. It's better practice to use style sheets to control this value. Avoid use of hspace and vspace attributes for the image element. It's better practice to use style sheets to control these values. Do not rely on CSS to affect images. CSS applied to the image directly or to container elements may not be applied. This recommendation applies to Nokia.

[edit] Contents of Screen

(old) The contents of a screen are what is most visible to the user, and they communicate the point of the screen to the user. They include everything excluding the screen title and commands.

− Use hyperlink styling only for actions that access web content. The hyperlink styling has major connotations of web access.

− Provide confirmation screens for any action that will cost the user money. (endold)

[edit] Fonts

Font use is more restricted on mobile devices than it is on desktop devices. While you can count on a desktop browser having access to several fonts, usually over 100, you can only count on a mobile phone having two. Thus any font differentiation based on style and size may not appear on the user's device.

[edit] The following recommendations apply to XHTML Basic.

Keep color contrast high for fonts. Since some devices will not display background colors or images, this means keeping font colors dark (e.g., black, blue, purple, brown, dark red, etc.).

Avoid subtle font color distinctions. If the user needs to understand it, different colors need to be very different. If the user doesn't need to understand it, don't overload bandwidth and processing with unneeded distinctions.

If you specify fonts, always specify a generic font-family (serif or sans serif) as the last in your list. Devices may have a limited number of fonts; many devices will only have one font. The generic font-family will be a fallback if the device doesn't support other fonts you specified.

Use fonts, such as Geneva or Verdana, that are optimized for bit-mapped, small resolution screens. The text will display better at different sizes. A word of caution: most devices, as of 2004, will not support these fonts. Always specify a generic font-family.

Use font size "x-small" as your standard font size. On most devices, anything larger looks "too big" and anything smaller is too small. x-small represents a good compromise for most text.

Use the em element instead of i to emphasize text. The em element logically marks-up the content to show where to put emphasis. This information may be rendered as necessary by the device, whether it's visually by making the text bold or audibly by placing more emphasis on the word as the device speaks it. Use the CSS property 'font-style' to style text you want bolded only for appearances.

Use the strong element instead of b to make text more important. The strong element logically marks-up the content to show where to add importance to the content. This information may be rendered as necessary by the device, whether it's visually by italicizing the text or audibly by placing more emphasis on the word as the device speaks it. Use the CSS property 'font-weight' to style text you want in boldface only for appearances.

Avoid using pixel font sizes. Most devices do not have many fonts, and naming a pixel size will cause the browser to select the best fit, not necessarily what you chose. Further, pixel sizes may differ across devices, and on one device a 10 pixel font could be quite large, whereas it may be quite small on another device. Use named sizes, like x-small, instead.

[edit] Text

[edit] Content Authoring: Less is More

(old) J2ME MIDP devices are small, and have small screens. They can not display a lot of text without the user having to scroll. Further, more text means either a larger application using more memory, or more for the user to download and thus pay for. To make the most of the small screen available, don't use the same content as you have in your equivalent desktop application.

[edit] Content authoring tips:

Adopt a concise writing style. Professional publications, whether written or electronic, usually employ a particular writing style: friendly, chatty, formal, humorous, et cetera. But there is only one writing style that works well in the mobile phone environment - concise. Consider relaxing your organization's writing style requirements to cope with this new medium. Make sentences direct and focused. Use active verbs instead of the passive tense. Logically break content into small chunks.

_ Omit needless words. The advice of Strunk & White (Strunk, W. & White, E. B. (1979). The Elements of Style, 3rd Edition. MacMillan Publishing.) applies to mobile design as well as it applies to everyday writing: "A sentence should contain no unnecessary words, a paragraph no unnecessary sentences... This requires not that the writer make all his sentences short, or that he avoid detail and treat his subjects only in outline, but that every word tell."

• Avoid redundancies. For example, use "PIN" rather than "PIN number."

- Shorten times and dates. If the content has a time stamp, omit the seconds unless they are necessary (they rarely are). If the content has a date, omit the year unless it is necessary (it rarely is).

• Abbreviate dates with the three-letter abbreviation for the month, followed immediately by a two-digit notation for the day. For example, display November 12th as "Nov12." Writing 11/12 is just as brief, but users may misinterpret it as December 11th, as "the eleventh item of twelve," or even the fractional value eleven-twelfths. Names of months or days of the week should be spelled out in full only when necessary.

• Omit unnecessary dates and times. Very often, a piece of information dated today need only be labeled with the time; a piece of information from a previous day need only be labeled with the date.

− Replace text input with selection lists. When possible, allow the user to select from a list instead of entering text. For example, it's easier for users to pick from a list of states and then a list of cities than it is to enter most city names. If you cannot provide a list that covers all possible options, provide a select list for the most popular items then add an "Other" option to allow text input.

• Do not include content merely because it is included in your desktop application. Limit your content to that which is appropriate for the mobile environment and your mobile users.

• Use standard abbreviations over non-standard abbreviations. Sometimes, your second choice for a word is the best choice if that word has a standard abbreviation.

Abbreviate creatively but without omitting useful detail. For example, "Go North to East 38th St" may be reduced without loss to "N to E 38th St." Shortening the phrase to "Go North" removes the value.

− Avoid displaying more numeric accuracy than is necessary. Just because your database supports numeric accuracy to the third decimal point doesn't mean your mobile users need or want to see that much information. It's usually more efficient to give users a highly rounded value at first and allow them to get more detail on a lower-level page. If you're hesitant to round or truncate numbers, consider that the device's small screen may do it for you whether you like it or not!

− Avoid unnecessary punctuation. Colons, dashes, parentheses, and quotation marks are common culprits. For example, "Low 52" is just as clear as "Low: 52." (end old)

[edit] The following recommendations apply to all situations.

Avoid unnecessary punctuation. Colons, dashes, parentheses, and quotation marks are common culprits. For example, "Low 52" is just as clear as "Low: 52." Remember that in a select list, one character consumes ~8% of the available space on a small display.

Do not break long character strings with dashes, commas, or other traditional separators. For example, the word "autobiographical" is too long for many screens (16 characters) and must be broken. It is tempting to re-write the word as "auto-biographical." But the browser sees this new text as a continuous string of 17 characters, making it worse than the original word! The browser will insert line breaks only at a space, which means that text must appear as "auto- biographical." A better choice would be to substitute a different, shorter word.

Words (strings of characters) not separated by (standard) spaces should not exceed the minimum display width. Character strings exceeding the minimum width will be broken in different places by different devices, creating unpredictable fractions of text. Avoid this problem by searching for and replacing strings exceeding your target width. Do not apply this rule to email addresses or other items for which precise spelling is critical. Note that non-breaking spaces do not behave the same as "standard" spaces and should be counted as standard characters. For older, HDML phones, assume a standard minimum width of 12 characters. For older, WML 1.x phones, assume a standard minimum width of 14 characters. If only targeting Nokia devices, use 18 characters.

Be careful with words that are ambiguous with regard to their part of speech. Ambiguity is a problem in small displays because of the absence of natural language and the use of words outside their normal context. Words intended as verbs are often misinterpreted as nouns or adjectives, and vice versa. For example, an email menu containing the item READ MAIL could be interpreted in at least two ways. It could be understood as a verb, indicating link to an inbox for the reading of email. Or it could be understood as an adjective, implying a link to a list of email that has already been read. Even when the part of speech is clear, some words still cause trouble. Does NEW EMAIL refer to the act of composing a new email or to a list of email that has not yet been read?

In most cases, decimal format (e.g., 0.25) is preferred over fractional format (e.g., 1/4). Unlike fractional representations, decimal format may be rounded to a certain number of digits, thus conserving space.

Use non-breaking spaces to maintain the integrity of fractional numbers. A whole number followed by a fraction (e.g., 34 7/16) should be separated by a non-breaking space. This will prevent undesirable breaks across lines or even screens (on phones that appropriately display non-breaking spaces).

Avoid displaying more numeric accuracy than is necessary. Just because your database supports numeric accuracy to the third decimal point doesn't mean your mobile users need or want to see that much information. It's usually more efficient to give users a highly rounded value at first and allow them to get more detail on a lower-level page. If you're hesitant to round or truncate numbers, consider that the device's small screen may do it for you whether you like it or not!

Two functions on a screen should share the same label only if they perform the same action.

Use caution when using non-breaking spaces. Some phones will treat them as breaking spaces.

Left-justify any text that will move (nowrap, marquee, etc.)

Do not use soft hyphens. They don't work on many devices.

Consider saving (perhaps in a cookie) and displaying user entry when the user revisits a screen. In many situations, the user will enter the same data again. Examples include starting point location for directions and stock ticker symbols.

Organize questions, greetings, error messages, et cetera so that the user can respond without having to read all the text. For example, instead of "Confirm deletion of user 'myfriend'", use "Delete 'myfriend'?" with commands "Erase" and "Cancel". Instead of "Error 1234: Could not recognize address," use "Address not recognized."

Put the most important content first. Use the traditional journalistic style of writing: critical details first, least interesting details last.

Do not add brackets or underlining to designate a link. The browser adds the formatting automatically. Note that the Samsung N400/A500 phones do not underline links, although the links are blue.

Avoid removing underlining from links. Users may not be able to tell your link is a link, even with link coloring.

Do not underline text. Users may misinterpret underlined text as a link.

Use the format xxx-xxx-xxxx for North American phone numbers. This format is 12 characters and will fit (without breaking) more often than the larger "(xxx) xxx-xxxx" format. If you are unsure what the phone number is, do not necessarily provide formatting because it may prohibit or distort numbers such as "1-800-FLOWERS."

[edit] The following recommendation applies to XHTML Basic.

Avoid all-uppercase text. It's difficult to read and there are better ways to visually distinguish parts of the page in XHTML.

[edit] The following recommendations apply to HDML and WML.

Use font formatting (e.g., boldface) only as a redundant highlighting method. In other words, do not use font formatting as a primary or single means of encoding information. Because some phones cannot display formatted characters, you must not rely on font formatting. This does not mean that you shouldn't use font formatting (it looks great on some phones), but rather that the application still be usable even if the formatting is invisible. Use a more basic form of emphasis (e.g., ALL CAPS) if all users must see it.

Do not include a blank line in a header.

Display screen titles and softkeys in ALL CAPITAL LETTERS. This convention visually separates content from headers and softkeys. Brand names, proper nouns, and user-generated text (like subject lines of email messages) are exceptions to this rule. This recommendation applies to Openwave.

Do not break up text with blank lines. Blank lines imply the end of a card and users will often fail to scroll beyond a blank line. Use a row of 6-12 dashes (------) instead of a blank line. See Visual Segmenting for more on this topic.

When figuring the length of linked text, include two (potential) characters for the brackets. Note that links may appear differently on different phones. This recommendation applies to Openwave.

[edit] About nowrap

For small screens, displaying all information on the screen results in excessive scrolling and the inability to scan a list. Displaying the beginning of a line and allowing the remaining text to fall beyond the right side of the screen (<nowrap> mode) allows users to quickly scan a list of long strings of text.

In XHTML, <nowrap> mode is implemented with the CSS property white-space: nowrap;. Openwave HDML/WML browsers use "Times Square" scrolling to show the user the content of a highlighted item. Nokia WML only has wrapping.

Currently, XHTML browsers behave as follows: Samsung devices will display a focusable list item with <nowrap> formatting with a scrolling behavior, but no other content. Openwave devices will display any content with <nowrap> formatting with scrolling behavior. Access devices use a horizontal scroll bar to display excess text in a list item with <nowrap> formatting. Nokia Mobile Browser will, if the user has turned the "Text Wrap" feature of their browser off, use a horizontal scroll bar to display excess text in a list item with <nowrap> formatting.

We therefore come to the following recommendations:

[edit] The following recommendations apply to all situations.

Use <nowrap> formatting for scannable list of items.

Keep text in <nowrap> format relatively short (approximately 2 screens of characters). Truncate if necessary. Devices display long strings of text very slowly (or require the user to manually scroll).

[edit] The following recommendations apply to XHTML Basic.

To get <nowrap> (scrolling) behavior, use some type of list (ordered, unordered, definition) as well as the CSS line white-space: nowrap;.

Text displayed in <nowrap> mode (marquee, nowrap, etc.) must have enough information in the first screen width to give users a clue what that line is about. Otherwise, users will have to go to the first line, wait for the other text to be displayed, then go to the second line, and wait for the other text to be displayed, etc. Remember that on some devices that the cursor consumes one space of the first screen width. This recommendation also applies to HDML and WML.

[edit] Links (anchors)

Links may appear in several forms, depending on the device. Although most browsers made in 2002 or later underline links, links also may be surrounded by square or angle brackets. Some platforms, such as WML and HDML, will never display more than one link per line.

[edit] The following recommendations apply to all situations.

Do not duplicate the action of a softkey in a link and vice versa. Because the primary softkey will be used to select links, links and the secondary softkey must never be assigned to the same action.

Link text must not exceed 116 characters. The Samsung N400 will crash with longer links. This recommendation applies to Samsung XHTML Basic.

Do not use links to replicate the function of a select list. In other words, don't use links to build a menu. This is one of the key differences between designing for Openwave browsers and designing for Nokia browsers. This recommendation applies to Openwave WML.

Use caution when applying focus (linking to a named place or element in the document). Most browsers will scroll to that location, causing the user to not see the top of the screen. The user therefore loses the context of the screen. This recommendation applies to XHTML Basic.

Use accesskeys for all predictable links. If the user can predict that the link is there, perhaps because the user has visited the screen before, enable quick access to it. This has the further benefit of distinguishing the beginning of a new line from a wrapped line. Some devices (e.g., Nokia) may not render the accesskey; in these cases, display the accesskey before the link.

Ensure that any item with an accesskey defined displays the matching number. Otherwise, users will not know the accesskey exists.

Use a text or graphic prefix (e.g., "-") for all links without accesskeys. This will allow the user to easily tell links apart by preventing links from visually running together. Ensure that a text prefix is used as alt text for a graphic prefix. Ensure that a graphic prefix is very small and only 2 colors. Exception: if the device, platform, and browser all have reliable layout control, use layout to help users discriminate links. This recommendation applies to Nokia WML.

Consider using different prefixes (e.g., "+" and "-") for different classes of links without accesskeys. Although the user will not consciously recognize it, using one prefix for navigation links and another prefix for action links will speed the user in understanding your application. This recommendation applies to Nokia WML.

Use links sparingly. Resist the temptation to link to everything from one card.

Link only one or two words per link. Surrounding text can add context to the link but be plain text. This practice makes the screen easier to read and more understandable.

Linked text should fit on one line. This will prevent multi-line links, which are discouraged. 15 characters is a good standard guess for length of a line. Keep links to 9 characters for HDML devices, 11 characters for Openwave WML devices. The first available character will be kept blank for the cursor, the second character is the left bracket, and this leaves 12 characters for the word and the right bracket. If your link text is longer than 11 characters, consider reducing the amount of text that appears between the brackets. For example, change "[Click here to see a list of options]" to "Click [here] to see a list of options."

Do not place links in a table. The table layout will be destroyed, since every link is put on a new line. If the links form the whole row or the first cell in a row, then they should work okay. This recommendation applies to HDML and Nokia WML.

Avoid underscores within links. On devices that display hyperlinks with underlining, users will not be able to distinguish an underscore from a blank. Links displayed in <nowrap> mode must have enough information in the first 13 characters to give users a clue what that line is about. Otherwise, users will have to go to the first line, wait for the other text to be displayed, then go to the second line, and wait for the other text to be displayed, etc. This recommendation applies to Openwave WML.

Use within-page links to give access to unseen parts of a large page. Do not do this on the smallest screens because such links ensure the user has to scroll past them. This reduces the need for scrolling. This recommendation applies to XHTML Basic and PDAs.

A navigational link is like the navigation bar at the top of a web page on a computer. It relates to the entire screen, like "Next Item", "Previous Message", "Headers", and "More".

[edit] The following recommendations apply to all situations.

Use navigational links only at the beginning or end of a screen. Since the link operates on the entire card, it would be in a position to reflect that.

Place navigational links at the beginning of the screen if the function is used at the beginning of reading the data. For example, a link to email headers would typically go at the top of a screen, as would a "skip" link (which might leave an item marked as unread). Note that these links may be after the header information so the user can make decisions based on visible screen content.

Place navigational links at the end of a screen if the function is used at the end of reading the data. The most common example is "More" if the data cannot fit on a single screen. It's likely that the user won't want to read the next page if he hasn't already read the current page, so it makes sense to place a "More" link at the end of a page.

In a group of links with no natural order, order the links with the most frequently used links first. This will minimize the average number of actions the user has to perform and will aid discoverability of the most common actions.

Do not replicate "Back" as a link. Users will be confused when two items on the device are labeled the same thing.

[edit] The following recommendation applies to Nokia.

Only put one anchored item (text or graphics) on a line. The second item will not be rendered as a link--- or may cause an error. Separate the items with
or <p> tags.

[edit] Commands and Softkeys

The wide variety of controls available on mobile devices means that any commands outside of simple links or menus have different activation methods on each device. Some platforms, such as HTML and XHTML Basic avoid the problem by not allowing any commands. Thus navigation on these platforms is provided exclusively by links and built-in navigation controls, particularly the Back button.

Nevertheless, some devices display a link or button title as the softkey label, so recommendations in this section apply.

The designers of platforms such as HDML and WML wanted more sophisticated controls, such as those that applied to the entire page. These controls were perhaps were not visible. Because devices vary widely in what physical controls are available, the platform controls have to be implemented differently on different devices.

WML provides "do" events. Phones with Openwave browsers display the labels for these events on the softkeys (stacking remaining do events under a "Menu" softkey). Nokia phones with WML browsers put all the do events under the "Options" softkey, along with several other controls. Palm WML browsers display do events as on-screen buttons.

The code <do type="accept"> will define the behavior for the primary softkey in the Openwave browser. The code <do type="options"> will define the behavior for the secondary softkey in the Openwave browser. Note that display in Nokia browsers will be different.

[edit] The following recommendations apply to all situations.

Restrict command labels to 6 characters when the command may be displayed on a button or softkey. Command labels may be displayed in a menu, in which case they can be much longer. However, many devices will render a command label as a softkey label. If you do not know how the device will render your action, assume it will be on a button or softkey. If the command will only appear in a menu on all devices, the label can be as wide as the device display -- you can assume 14 characters.

The following labels should be avoided: Home (unless executing the Home function), Help, Exit, Bookmark, Back, Clear, CLR, End, Power, and PWR. These are reserved for browser or device use, or conflict with labels of hard keys.

[edit] The following recommendations apply to XHTML Basic.

Define title attribute of hyperlinks and buttons -- many browsers will display them as the softkey label.

Avoid the title "Done" for any selectable element. Browsers are required to display "Done" when focus is within a text field. Users will become accustomed to "Done" applying to text entry or some other on-screen task, and not to the entire screen.

[edit] The following recommendations apply to HDML, WML and WML2.

Ensure that the command label causes users to accurately predict what it does. You can do user testing to check this. A good label is short, descriptive, unambiguous, and consistent within an application.

Provide a label for every action. Otherwise the users won't see the action. There is no need to provide a label for the <prev> action on an Openwave device because <prev> is mapped to the back (CLR) key. Do not provide a label for the <prev> action on Nokia devices, as it will cause the phone to not display the action on the "Back" softkey.

Do not use BACK as a softkey label. Also do not use functional equivalents such as <prev> or UP. The reasons for this are described in detail in Backward Navigation on page 43. If you didn't read it, you should now.

Do not use the same label for multiple softkeys.

Dead-end cards are those which do not lead deeper into a menu hierarchy, but instead return the user to the card of origin. Such cards are functionally equivalent to a simple dialog box in Windows or Mac OS, in which the de facto acknowledgment button is labeled "OK." Thus, many developers are inclined to use "OK" in the analogous mobile situation. We disagree. Dialog boxes in Windows or Mac OS come with many graphical attributes that imply their nature, especially the manner in which they "float" over other windows. In mobile applications, there are few such graphical cues.

[edit] The following recommendations apply to all situations.

Change the primary softkey label when the cursor moves to a link. Especially in screens with only one link, it is often difficult to determine whether a link is highlighted. Changing the softkey label when the cursor moves to a link help the user perceive the change in functionality. If possible, use a label that represents the function of the link. For example, if the link text is "Erase," the softkey label should be "Erase" when the cursor is on that link. In XHTML, do this by providing a title attribute for the link.

Avoid command labels that are ambiguous with regard to their part of speech. Ambiguity is a problem for commands because commands often have no context. Words that are intended as verbs can be misinterpreted as nouns or adjectives, or vice versa. Close, Read, and Clear are examples.

Whole words are better than abbreviations, and standard abbreviations are better than non-standard. For example, Erase is preferred over Del or Delet (short for Delete). Give the user the best chance of understanding the label (just make sure it fits!).

Use the same label for the same action throughout the application. If a command means and does the same thing (reply to a message, create a new contact, view a stock price, exit the application), it should be labeled the same throughout the application.

Use MAIN to refer to the main page of your site. Do not use Home, as this refers to the browser home page. If your site has a short name or an acceptable abbreviation (of five characters or fewer), consider using the site name instead of Main. Main is preferred over Top.

[edit] The following recommendations apply to HDML and WML

Use DONE to label the primary softkey on a dead-end card. Because OK is the label of choice for selecting and going forward, we hesitate to recommend its use for backward navigation. DONE better implies a dead-end card and thus offers a "reverse alternative" to OK. Depending on the language of the card, there will be times when DONE sounds awkward and OK seems better. In such cases, use OK. But do not recklessly use OK for softkeys that navigate backwards or dead-end cards in general.

When the purpose of the primary softkey is to select an item or move forward in a series, use OK for the label. Avoid deviations like VIEW, DETAIL, GO, READ, SELECT, or PICK. If the softkey navigates forward in a series, then NEXT is an acceptable alternative.

Ensure that your screen and command can be understood even if the command label is changed or hidden. Many devices display a standard label for commands such as "Back". Some devices have hardware buttons. Devices may or may not display a control's title attribute in XHTML as a softkey label.

[edit] The following recommendations apply to Openwave HDML and WML.

Headers and softkeys on text-based devices should be in ALL CAPS. This convention visually separates headers and softkeys from content. Brand names and proper nouns are common exceptions to this rule.

Do not use spaces in the softkey label. Some browsers allocate their softkey space between the two labels dynamically. For example, one browser gives as much space as possible to the secondary softkey, and the remaining space to the primary softkey. Other allocation methods may differ. Thus, if your softkey labels are Goto and Main Page. the user will see Goto Main Page How would the user know which softkey to use to go to the main page?

[edit] The following recommendations apply to HDML, WML and WML2.

Provide a 1-to-1 mapping between labels and their commands. Commands with different labels will suggest different actions, and users will make up explanations for how the two actions are different -- even when the actions are the same. Provide a unique label for each command, and if the command is replicated on the screen, use the same label for each instance.

List actions according to frequency of use. But please note that... Actions that are always present should precede items that are not always present. This will prevent actions from changing order and surprising the user.

Do not define more than one <do type="accept"> for a card. In other words, define only one primary softkey.

Do not define a <do type="delete"> or help as the sole definition for necessary functions. Users may not find them.

Always define the primary softkey. Users will feel "stuck" if there are no softkeys.

Define a navigation action for every screen. Users will be "stuck" without an action.

Do not place committal or destructive actions on the primary softkey or select button if such actions are irrevocable. Actions like BUY, PLACE (order), or ERASE should be placed on the secondary softkey so the user is less likely to activate them inadvertently. Use the primary softkey primarily for navigation. An exception is made when the user is allowed to revoke (undo) such actions.

Define both softkeys. Use MAIN as the second softkey. If MAIN is not applicable, consider using "-----" and having it execute a no-op. DONE may also be a good second softkey. Phones with scrolling softkeys will move "Home" to the left, making the user believe that the link may go to your site's main page. This recommendation also applies to Openwave.

[edit] Multimedia and Graphics

In general, graphics on mobile devices should be smaller, simpler, and fewer than on desktop applications. Some devices don't support graphics at all, some support graphics but have pixels that aren't square, many devices do not have color, most devices have small screens, and all devices have limited bandwidth or processor capability.

Perhaps the most important thing to remember about graphics, is that devices may have 65,000, 4,096, 256, 64, 16, 4, or 2 colors for graphics -- and some devices don't have graphics at all. On some devices that support graphics, users may not choose to download them.

Openwave browsers can display graphics in links, plain text, or select items. They are displayed on the same line as neighboring text, barring wrapping or extra <p> marks. The placement of the image will match the formatting of the <p> element.

Despite the general bias against graphics, it is possible to create a branded, attractive, good user interface with minimal graphics. Essentially, the graphics on your site need to speak the same visual language throughout your site. Without trying to replicate a design education, realize that a consistent visual language has similar values for all graphics across the following dimensions:

Color -- keep the same small family of colors (color palette) on images throughout the site. Line weight -- keep the same small set of line weights on graphics throughout the site. Of course, the images on mobile sites should be very small, so you do not have a lot of opportunity to create variations here. Contrast -- on mobile devices, keep contrast high. Size -- keep images consistently sized; for mobile devices, the size is small. Placement & Proximity -- this is controlled mostly by the rendering engine, with little control by the developer. Do not control placement using spacer graphics. If you need text aligned precisely with an image, include the text in the graphic. Don't do this more than once per page. Style -- keep the general style (e.g., cartoonish) consistent from image to image. For details on how to do this, consult your local graphic designer.

[edit] Content=

[edit] The following recommendations apply to all situations.

Keep images high-contrast. Recall that your users will be using a wide variety of screen types in a wide variety of conditions, including backlit, full sunlight, and indoor lighting. Subtlety will frequently result in obscurity. This is especially important if the graphics are in color. High contrast among colors makes it easier for users with color deficits to distinguish everything in the image.

Avoid images with text in them. They don't scale. They take longer to download. They are difficult to translate. They are impossible to translate on the fly.

Do not anti-alias text in images. The text will look blurry on small devices. Avoid animations unless they are the point of the screen. Moving images take user attention as well as processor overhead. They also use extra memory. They are distracting and users will eventually turn off images, if possible. The exception is when the animation is the actual content of the screen and directly related to the user task, like feedback screens or games.

Use only images appropriate for audience. A site targeted at a youth market might have cartoons and animations whereas a business application would have few (or no) graphics.

Provide graphics in the appropriate format. While the gateway may transform the graphics to an appropriate format, it will take time and the resulting quality may not be what you envision. Use PNG, JPG, or BMP instead. Nokia supports WBMP and GIF. WML supports only WBMP (wireless bitmap) format.

[edit] The following recommendations apply to markup languages.

Restrict the number of graphics per page to 2. Each image generates its own http request and causes the page to display more slowly. The LG 5350 (Openwave browser) is particularly slow.

Use graphics only when they serve a purpose. For example, don't precede your main menu with a splash screen just because you're proud of your company logo. Your users are paying for the airtime. Don't waste it. And don't forget that images take longer to load than the textual equivalent. We've observed users abandon sites they believe are malfunctioning when there's actually just a delay due to downloading images.

Do not implement image maps. The user has no way to click on a portion of the image. This recommendation applies to scroll-and-select devices.

[edit] The following recommendation applies to HDML and WML.

Use 1-bit (black & white) graphics. The browser cannot display other graphics formats.

[edit] The following recommendation applies to WML.

Images must be encoded in WBMP format. Note that some gateways, including the Openwave gateway, will convert 1-bit BMP files to the WBMP format.

[edit] The following recommendations apply to Openwave HDML and WML.

Use built-in icons (localsrc images) where possible. This will result in faster loading and a less expensive experience for the user. It will also give the screen more capacity for text content. However, always define the URL for the image on the server, in case an error occurs. See Openwave's SDK documentation for more information on localsrc images.

Put decks that call images in digests. This will load the deck and the image simultaneously.

[edit] The following recommendations apply to Samsung and Access XHTML Basic.

Avoid graphics on pages delivered via SSL. The Samsung and Sanyo phones of 2002 will not download at least some images.

[edit] Size and Layout

[edit] The following recommendations apply to all situations.

Ensure graphics will fit horizontally on the device without scaling or scrolling. Some devices will scale large images in unpredictable ways. Others will truncate the image. After allowing for the scroll bar, Palm devices allow 153 pixels for image width. 2002 and later devices will have a minimum of 64 pixels wide; most are 120 pixels wide. The width of scroll bars is unknown.

Keep supplementary graphics small (under 4KB). This requirement applies to graphics that are not the main purpose of the page, such as icons or logos. If the graphic is the user's destination, however (e.g., viewing a celebrity photo), then this requirement does not necessarily apply. Users have to pay for download time, and they use valuable memory on the device. Ideally, graphics will be less than 500 bytes, as anything larger, when combined with protocol overhead, will result in two packets rather than one.

Images should not exceed screen width. Because many devices don't support horizontal scrolling, users will be unable to access the portion of an image beyond the screen width.

Make sure graphics line up. On text-based platforms, design the site based on both fixed-width fonts and variable-width fonts. On graphics platforms, place your graphics carefully. Test your graphics on a wide variety of devices. Ensure that the presentation is appealing to the eye.

Unless vertical scrolling is appropriate for an image, the image should not exceed the screen height, minus softkeys or buttons.

Images serving as headers of menus or input screens should ensure that at least one line of the control is visible. Generally, take the screen height, subtract 15 pixels for softkeys and 15 pixels for the first line of the control. Otherwise, the top portion of the image may scroll off the screen or the user may not realize that more content is on the screen.

Don't use CSS to create a few pixels of whitespace around certain images to ensure they don't bleed into other content. Put the whitespace in the graphic instead. This way, the browser has fewer calculations to perform and your content will render faster.

Always define image sizes. This will prevent content on the page from jumping around as each image loads. Note that some phones will ignore image sizing.

Ensure your application displays well without graphics. Not all devices have graphics capability, or users may have graphics turned off to save money.

[edit] The following recommendations apply to XHTML Basic.

Do not embed images in style sheets as containers. This increases page load time and cost due to multiple http requests.

Do not create side-by-side images using tables. Instead, try using a div container with both images inside it, without anything between them that will create a line break. You can not rely on tables for any sort of layout, as devices render them unpredictably.

If an image takes up less than half of the display, float text around it using the CSS 'float' property with 'vertical-align: top'. Floating text around images conserves space and reduces the amount of scrolling. This recommendation applies to Nokia.

Ensure at least one dimension of the image fits on the device. The Nokia simulator can not scroll if the image is both wider and taller than the screen. This recommendation applies to Nokia.

Do not define borders around normal images. An image that is a link is generally rendered with a border around it. Defining a border for an image may lead the user to believe your image is a link.

[edit] The following recommendation applies to WML and WML2.

Use caution when putting an image on a screen with a timer element. The screen may time out before the image is displayed.

[edit] The following recommendations apply to Nokia WML.

Image alignment should be "bottom". Some Nokia WML devices may truncate the image otherwise.

Put no other elements on the same line as an image. The device may not render appropriately otherwise.

[edit] Alt Text

Alternate text (alt text) is displayed when the device has not successfully downloaded the graphic. This may happen because the user has turned off graphics, because the page has not yet finished downloading the graphic, because the graphic was not found, or because the device is incapable of displaying graphics. Standard web design practice says to always use alt text, but even the simplest analysis says this is not true.

[edit] The following recommendations apply to XHTML Basic.

Use alt text on all graphics. Otherwise, your code will not validate.

[edit] The following recommendations apply to all situations.

Your screen layout should work with and without graphics. Early XHTML browsers download pages in a characteristic way: first they download and render the text page, including alt text for the images. Then they download images, replacing alt text where appropriate. This behavior means that the user will see the alt text for every image on every screen. Users may also have graphics turned off to conserve time and money.

Keep alt text short. Users first impression of your page will be the one with no graphics and all alt text. Because the length of alt text will affect screen layout before the images are loaded, long alt text may meant that users see no actual content on the screen without scrolling. Further, the browser will re-arrange the page when the graphics are loaded, so long alt text means that information on the screen will dance around as the graphics are loaded one by one.

Use alt text to describe graphics that carry meaning. Site logos and content images are integral parts of the experience of a screen or site, and the user needs to get as much information as possible even if the images are not displayed. The alt text should describe the image (if the image itself is content) or the meaning of the image if the image is metaphoric. For example, don't describe your corporate logo as a bouncing ball, describe it as "ACME, Inc."

Use single-character alt text to describe "marker" icons. Marker icons are used to give the user a little information about the nature of a menu item, link or other bit of text on a screen. A graphic of a paper clip that indicates that a message has an attachment might have alt text of "+". A graphic of a closed envelope indicating an unread message might have alt text of "*".

[edit] Use blank alt text for graphics used simply for layout or emphasis.

[edit] Color

The introduction of XHTML and color-capable devices into the mobile browsing arena is exciting, and many current developers want to use as much of this capability as possible. The mere existence of thousands of colors may make one think that using thousands of colors, the way a desktop application does, is appropriate. Unfortunately, issues such as quality of display, glare, pixel size, and lighting conditions get in the way.

[edit] The following recommendations apply to XHTML Basic.

Keep color contrast high if the user needs to understand the color distinction. Devices don't render well, colors aren't consistent, and glare and sun will be problems.

If using a background image or color, ensure black and blue fonts are readable on it. Some devices will not change the background.

Avoid using background shading as a grouping method. If the regions to be grouped are small, the resulting display looks garish. If the regions to be grouped are large, the user will not get the benefits of grouping as the majority of the page will be off the screen.

[edit] Select Lists in WML 1.x

Select Lists (a.k.a. "menus") on Openwave WML 1.x devices are simply a numbered list of selectable options. The user may scroll down and select the desired option, or simply press the number key associated with the desired item. Select Lists are most commonly used for building hierarchical menu systems.

On Nokia devices, Select Lists are pop-up screens used for option settings, and links are used for hierarchical menus.

[edit] The following recommendations apply to HDML and WML.

Include a header with each select list. On Openwave devices, the header will look like the screen title. On Nokia devices, a description immediately before the select list (a header) will give context to the list. In either case, the header explains the purpose of the select list.

Use <wrap> for headers longer than 14 characters. It enhances readability. Exception: use <nowrap> mode if the header is obvious, known, or infrequently used.

Select List items displayed in <wrap> mode must not exceed three rows of text. Using the smallest phones as a rule, the first line allows 12 characters; the remaining lines allow 14 characters each. If a choice item exceeds three rows of text, the cursor and the softkeys tend to disappear while scrolling! This is especially problematic for phones that fill the now-empty softkey positions with other softkeys.

Either all items must have onpick events, or no items should have onpick events defined. The user has no visual indication of the difference.

Use 11 items or fewer on a select list. A group of 12 or more items is best displayed across sequential lists. Exceptions can be made for well-known groups of 12, like months.

Divide long Select Lists (>11 items) into several cards of 9 items each. To provide access to additional items in subsequent cards, display "More..." as the 10th item. If an entire select list contains only 10 or 11 items, it's usually best to put the 10th or 11th items at the end of a card rather than creating a second card. Create a second select list for 12 or more items. Note that the 10th item in a select list may be selected with the 0 key.

Items that are always present (visible) should precede items that are not always present. Many users prefer to make selections by pressing the number associated with an item and will memorize the numbers for their favorite sites. If the order fluctuates, users will sometimes select the wrong item. Note that users don't have to scroll down to make choice via number, so they may not notice a re-arrangement if it's not at the top of the list (they may not notice it at the top, either!).

Don't use an ellipsis (...) to indicate that an item goes somewhere. All items go somewhere. Use an ellipsis only to indicate continuation of a series (e.g., "More...") or that further interaction is required to accomplish the task (e.g., "Save As..."). For example, if the task is to make a call, then the label should be "Call." If the task is to select a number to call, the label should be "Call..." If the length of the preceding word does not allow a full three-dot ellipsis, use a two-dot ellipsis (..) instead.

Use 12 characters or fewer for Select List items. This will make for a better user experience regardless of whether the text is in <nowrap> or <wrap> mode.

When using <nowrap> mode, modify items so that each is understandable and distinguishable within the first 12 characters. Note that text beyond 12 characters will be hidden on smaller phones.

<nowrap> mode is usually preferred over <wrap> mode. In <wrap> mode, scrolling behaves oddly. Instead of scrolling line by line, the card scrolls line by line but the cursor jumps from item to item.

Select List headers should not exceed two rows of 14 characters per row. This recommendation is especially important if the first portion of the header (that which would "disappear" on smaller phones--see example) is critical to the understanding of the card. Note that this guideline is not based on a simple 28-character limit. Due to word wrap, three 7-letter words will consume three lines even though the total character count is 23 characters (including spaces). Because a small-screen browser will automatically scroll down to the first select list item, a header that exceeds the two-row limit will not appear in full -- the portion preceding the last two rows will be hidden. If your header is too long, truncate the second line to 12 characters and put two dots (..) at the end.

[edit] The following recommendations apply to Openwave WML.

Unless it is a multiple select list, all items must have onpick events defined. This gives the user a consistent expectation that selecting something will cause something to happen. On Nokia phones, it is reasonable to have a select list that defines a setting (like a pop-up list) and other controls to move forward. Openwave phones have select lists displayed as menus and having nothing happen when an item is selected is extremely confusing.

If a Select List contains one especially long item label, then place it last and display it in <wrap> mode. The wrap-around text in the last position will not interfere with the visual structure of the list.

Avoid optgroups. Openwave 4.x browsers do not support them.

[edit] The following recommendations apply to Nokia WML.

Items should not have onpick events defined. This gives the user a consistent expectation that selecting something is simply selecting something. On Nokia phones, it is reasonable to have a select list that defines a setting (like a pop-up list) and other controls to move forward. Openwave phones have select lists displayed as menus and having nothing happen when an item is selected is extremely confusing.

For a select list with onpick events, set the default index value to 0. Some browsers will not trigger the onpick event when the user selects the default item.

Use optgroups to display items in a select list in logical groupings.

[edit] Bookmarks

Although beginners may not know how to create them, bookmarks allow users to customize the browser to match their personal needs and are a very good tool. Users who do understand bookmarks and can find them will expect behavior similar to HTML.

Assume the page title will be the default bookmark label.

Openwave browsers assume storage on the gateway (so bookmarks are unlimited, but only if an Openwave gateway is available); Nokia browsers store bookmarks on the device.

Different browsers will handle offline bookmarks in different ways. For example, the browser may bookmark the specific page, or only the site. Your page-specific bookmark of Harry Potter at Amazon may only point the user to the Amazon home page.

[edit] The following recommendations apply to all situations.

Do not rely on deep linking to make your site work well. The device may not support it.

Provide a default bookmark label by defining the title element for the page. Otherwise, users will have the page's URL as the bookmark title.

[edit] The following recommendations apply to HDML and WML.

Almost everything should be markable. The user won't understand why a card isn't markable. In particular, ensure that select lists, find cards, and content cards are markable.

Mark the appropriate card. If the user marks a card in the middle of a process (or wizard), the bookmark should point to the beginning of the process. For example, all the cards in an order-entry series should point to the first card in the series.

Ensure necessary navigation and data are available. If a card relies on the "Back" function to work properly, a different card in the application should be marked. If the card displays data from a user selection, the site should either set a cookie containing that data or point the bookmark to a different card.

Bookmark labels should be context-sensitive. The default label (the title attribute of the card) should provide as much data as possible, especially if it relies on user data. For example, if the user marks a Acme Co. stock quote, the bookmark label should be "Acme Quote", not "Stock Quote." The user should never be required to edit the bookmark label to make it usable.

Allow the user to bookmark cards with input fields leading to information. For example, allow the user to bookmark the flight number entry in an application to check flight schedules.

Certain cards should not be markable. The following items should either be not markable, or should point to some other card:

Transient data. Data that will disappear, like a specific email, should not be markable unless the target is another card.

Action menus. The card accessible by the "Menu" softkey on certain sites will not have the appropriate context associated with it. For example, a menu associated with a specific email might have a "Delete" item. If the menu is markable, the result of this item is unclear. Action menus should therefore not be markable.

Edit screens. Most edit screens should not be markable. An exception might be a card that asks for a value that the user is likely to want to change frequently.

One example might be the user's current ZIP code for a weather application. A stock quote entry is an example of a card you may want to make markable.

Design Patterns phm