Mobile Style Guides - Screen Design, Part 1
From MobileDesign
This document is intended to help developers create useful and usable applications to run on mobile devices and browsers. It is not targeted at one specific environment, but instead is intended to support developers targeting:
- One platform, one device or browser
- One platform, multiple devices or browsers
- Multiple platforms, multiple devices or browsers
Some parts of this document apply to all mobile applications, others apply only to certain situations: specific platforms, specific devices, specific classes of devices, specific environments. We intend this document to be flexible enough to support a variety of development situations.
A quick word of caution: the information in this guide is accurate to the best of our abilities and current as of 2002. Where we make statements about devices’ rendering capabilities, we try to test our statement. However, there will undoubtedly be some aspect of device use that we haven’t tested – perhaps the particular code you are using, perhaps the particular version of the OS, perhaps a new device. Recognize that the information contained in this guide will change as the devices, platforms, industry, and our understanding change.
Contents |
[edit] Title and Header
This section and this guide refer 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. On some devices and platforms, this is the title element; on others, it is simply some text at the top of the screen.
- 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 platforms use the title as the default bookmark name.
Hence, "header" is a design term, and "title" is a programming term.
| The title or 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 contrained). | |
| 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 | PalmOS |
| Keep screen titles limited to approximately 12 characters. | PalmOS |
| Consider using a select list containing breadcrumb navigation as your screen header. As described earlier, "breadcrumb navigation" contains a list of screens (levels) visited from the home page to the current screen. On desktop systems, breadcrumb navigation is a set of links, something like "Home > MyInfo > Calendar > May". While this style of navigation will certainly work technically, it will take up a lot of space. Instead, make each item in breadcrumb navigation be an item in a select list, with the current (most recent) item at the bottom and as the default item. This serves as vertical navigation, consistent and easy access to your site’s home page, and context for the current screen. Put an unclickable logo image to the left of the control. | XHTML-MP Openwave |
| 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. | WML Nokia |
| Keep the title short (12-14 characters). The phone only allocates 1 line to the title. | XHTML-MP Nokia Openwave |
| Ensure that the screen is understandable without reading the title element. Some users do not look at the title, and some devices do not display the title on the screen at all. | |
| Avoid non-standard abbreviations. Users probably won’t understand them. | |
| Define your table to be no wider than the screen. Most devices will not be optimized for horizontal scrolling. Many devices will not support horizontal scrolling at all. | |
| 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. |
[edit] Contents of Screen
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.
| Use CSS to lay out screen elements when using XHTML-MP. | markup |
| 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. | XHTML-MP markup |
| 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. | XHTML-MP markup |
| 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. | XHTML-MP Openwave markup |
| If table content is clear from the first screen’s width of text, use CSS to set the table data cells to "nowrap". The default white-space display for tables is "overflow" (wrapped). You must explicitly set the table data cells to not wrap. Make content obvious within the first cell-width of characters, even on smaller devices. | XHTML-MP Openwave markup |
| 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. | XHTML-MP markup |
| Unless otherwise required, style the element text for tables with the same CSS font values as normal text within the table. A caption only serves as a short title for a table. Since there is rarely more than 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. XHTML-MP markup | |
| Highlight table header text. The most common way to do this is to make the text bold. Use the CSS value: "font-weight: bold;" | markup |
| If you specify fonts, always specify a generic font-family as the last in your list. Devices may have a limited number of fonts. The generic font-family will be a fallback if the device doesn’t support other fonts you specified. | XHTML-MP PPC |
| Use fonts, such as Geneva or Verdana, that are optimized for bit-mapped, small resolution screens. The text will display better at different sizes. | XHTML-MP PPC |
| Use the element instead of to emphasize text. The 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. | XHTML-MP PPC |
| Use the element instead of to make text more important. The 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. | XHTML-MP PPC |
| Avoid using pixel font sizes. All values greater than 9 pixels or less than 11 pixels will convert to 11 pixels. All values greater than 11 pixels will convert to 13 pixels. Use named font sizes (e.g., large) instead. | PPC XHTML-MP Nokia |
| Do not use the clear attribute of the element or the "clear" CSS property. These are not rendered by the browser. Instead, use a plain element to achieve the same effect. | XHTML-MP Openwave Nokia |
| Avoid using the "clear" CSS property on Openwave browsers. This CSS property is not rendered by the browser. Instead, use a line break element to achieve the same effect. | XHTML-MP Openwave |
| Avoid more than 2 consecutive blank lines. Users will believe they are at the bottom of the page. | |
| Consider using the CSS property "white-space: nowrap" instead of <pre> - If you use CSS to control the content layout, it's easier to change it later. For example, you only need to change the value from 'nowrap' to 'overflow' to allow the content to wrap. | XHTML-MP Openwave |
| Use the CSS "visibility" property cautiously. - Consider how changing an element's visibility may affect the overall screen layout. | XHTML-MP Nokia |
| 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. | XHTML-MP WML2 |
| 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. | XHTML-MP |
| Do not add brackets or underlining to designate a link. - The browser adds the formatting automatically. Note that links may appear differently on different phones. | |
| 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. | HDML WML |
| Do not include a blank line in a header. | HDML WML |
| 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. Remember that in a choice list, one character consumes ~10% of the available space on 12-14 character phones. | |
| 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. | |
| 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. | HDML WML Openwave |
| 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? | |
| 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." | |
| 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. | |
| When figuring the length of linked text, include two (potential) characters for the brackets. - Note that links may appear differently on different phones.
HDML WML Openwave | |
| Do not underline text. - Users may misinterpret underlined text as a link. | |
| 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 card 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. | |
| Use <left> justification for text in "nowrap" mode. Use <left> justification for text in "line" mode. - | |
| 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. | |
| Text displayed in "nowrap" mode 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. | HDML WML XHTML-MP |
| Put the most important content first. - Use the traditional journalistic style of writing: critical details first, least interesting details last. | |
| 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." |
[edit] Links (anchors)
Links may appear in several forms, depending on the device. Links may be surrounded by square brackets, angle brackets, or they may be underlined. Some platforms, such as WML and HDML, will never display more than one link per line.
| 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. | markup |
| 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. | WML Openwave markup |
| 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. | markup |
| Use a text or graphic prefix (e.g., "-") for all links without accesskeys. - This will allow the user to easily distinguish links. 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. | markup |
| 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. | markup |
| Use links sparingly. - Resist the temptation to link to everything from one card. | markup |
| 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. | markup |
| 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." | markup |
| 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. | HDML WML markup |
| Avoid underscores within links. - On devices that display hyperlinks with underlining, users will not be able to distinguish an underscore from a blank. | markup |
| 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. | WML Openwave markup |
| 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. | HTML XHTML-MP markup PDA |
[edit] Navigational Links
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".
| 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.
markup | |
| 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.
markup | |
| 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. | markup |
| 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. | markup |
| 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 <br /> or <p> tags. | Nokia markup |
| Do not replicate "Back" as a link. - Users will be confused when two items on the device are labeled the same thing. | markup |
[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-MP (excluding the WML namespace) 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 title as the softkey label, so recommendations in this section apply.
The designers of other platforms, such as HDML, WML, and J2ME, 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.
J2ME provides "abstract commands", actions you can define for your application without defining a specific user interface mechanism. Instead, each device has a scheme for rendering the various commands, allowing the developer to concentrate on designing the application. A screen in an application may have any number of commands. Commands in J2ME may be displayed as softkeys, button labels, or items in a menu (some won't appear at all on some devices and will only be mapped to a physical button). In cases where you know that the command will only appear in a menu or separate list, you can use labels as long as will fit on your smallest device, not half of your smallest device.
All commands have labels. Most platforms have command types. Some platforms (such as J2ME) have command priority. The command type and priority determine where in the UI the label is placed. Even within a platform, rendering differences may cause a command's label to be placed inconsistently on different devices.
So action labels may be displayed as softkeys, buttons, or menu items.
The code <do type="accept"> </b> will define the behavior for the primary softkey in the Openwave browser. The code <do type="options"> </b> will define the behavior for the secondary softkey in the Openwave browser. Note that display in Nokia browsers will be different.
| 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. | |
| 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. | |
| 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. | |
| 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 Navigation:Backward Navigation. | WML |
| Do not use the same label for multiple softkeys. - | |
| Use DONE to label the primary softkey on a dead-end card. - 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. 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. | |
| 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. | HDML WML Openwave |
| 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. | |
| 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. | |
| 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. | markup |
| 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!). | |
| 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? | WML HDML Openwave |
| 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 optionally display a control's title attribute in XHTML as a softkey label. Any J2ME command type other than SCREEN may be rewritten by the device. This will be more likely with the higher priority commands. | |
| 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. | |
| Use the same label for the same action throughout the application. - This does not mean use the same label for all Screen commands; rather, 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. | |
| 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. | WML |
| Do not define a <do type="delete"> or help as the sole definition for necessary functions. - Users may not find them. | WML |
| Always define the primary softkey (accept). - 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. | WML HDML Openwave |
[edit] Commands
Abstract commands in J2ME are not rendered by the application, but instead by the device. Different devices will display commands differently. Palm devices will put the first few commands as buttons along the bottom of the screen, and the rest of the commands in the menu structure. Phones will vary; some will put one command on the primary softkey, and all the remaining commands on the secondary softkey (labeled "Menu"). The application influences the location of commands by defining their type and priority (lower priority number means higher priority).
Note that the command type does not affect or limit in any way the functionality you assign to the command. Logically, you could put a "move forward" type action on a command of type Back ... and on some devices this would work well. On other devices, the user would have to use the device's back button to move forward. So consider the command type only as one of two hints you give to the device to aid rendering.
Command types, and their intended uses, are:
- Back - returns the user to a previous screen. May be allocated to a hardware button (Back, CLR), a permanent software button, or as other commands are allocated.
- Item - a command that pertains to the highlighted item in a Form or List. Scroll-and-select devices are likely to assign the highest priority Item command to the primary softkey or perhaps a select button.
- Screen - a command that pertains to the entire screen or application. Devices are likely to put Screen commands ahead of other commands (other than item commands). In the Sun MIDP, Screen and Item commands are in the same menu.
- Stop - stop a current process other than the application.
- OK - standard positive response to a query.
- Cancel - standard negative response to a query.
- Exit - exit the application. Palm devices are likely to not render this at all, and phones are likely to map the highest priority version of this to the End key.
- Help - access to how-to information about the application. May be allocated to a hardware key.
| Give your command the most relevant type (BACK, EXIT, ITEM, SCREEN, STOP, OK, CANCEL, HELP). - This is your best method to ensure that the device renders commands intuitively. | J2ME |
There are two command types that are consistently rendered in prominent locations: SCREEN and ITEM. Screen commands relate to the entire screen, and Item commands relate to the highlighted item in a list or form.
| Use commands of type BACK to return the user to a previous part of the application. - Previous locations can include the start of a process, the previous screen, or the application's home page. | J2ME |
| Use the highest priority BACK command to return the user to the previous screen. - Because some devices will put the highest priority command on a hardware button, your label may not be displayed. Thus the user will be misled if your application goes to a nonstandard location. Exception: if the previous screen is not one to which the user should return, then the highest priority Back command can go to another logical destination. | J2ME |
| Define a BACK command for each screen. - This gives the user an intuitive way to cancel a started process, and ensures that the device's native back-button (e.g., Back, CLR) works as the user expects. | J2ME |
| Define at least one forward-moving command (SCREEN, ITEM, or OK) for each screen. - This gives the user a logical next step. The forward-moving command may be a command to "dismiss" the screen and return to the previous one. This would likely be a SCREEN command, although it moves backward. | J2ME |
| Use a HELP command to give access to your application's About screen. - This gives applications a consistent method of getting to the About screen. | J2ME |
| Define an EXIT command for each screen. - This will ensure that the user can always leave, and that the device's native exit-button (e.g., END) works as expected. | J2ME |
| Make the EXIT command a low priority. - Users do not exit the application very often. Also, the highest priority EXIT command will be mapped to the END button, which is very intuitive for the user - and PDA users do not have the concept of exiting the application. By making the EXIT command be low priority, the device will only render it in a prominent location if no other commands exist. | J2ME |
| If usability testing shows that a particular pair of commands must be next to each other, make them have the same type and priority - but only for lower priority commands. - The idea is that if two commands have the same type and priority, the device will not know which one to display first. Consider "Reply" and "Reply All". This pair of commands would both be SCREEN commands when a message was displayed. If their priorities were 3 and 4, it is possible commands with priorities 3 and 4 could come between them - it would depend on the precise algorithm the device uses. However, if they had the same priority, it is possible that "Reply All" would come before or after "Reply", but they would be together, and would therefore make more sense. | J2ME |
