Design Patterns phm

From MobileDesign

Contents 1 DESIGN PATTERNS (phm) 1.1 Alphabetical List 1.2 Sports Scores 1.3 Complex Entry: Wizards and Forms 1.3.1 Complex Data Entry: Wizards 1.3.2 Complex Data Entry: Forms 1.4 Visual Segmenting 1.5 Quick City Lookup 1.6 Series Reader 1.7 Cancel Guard 1.8 Navigational Menus 1.9 Action Menus 1.10 List of DataBold text

[edit] DESIGN PATTERNS (phm)

NOTE: I could not figure out how to reconcile Screen Patterns from the 2004-5 materials and the following which is from the 2003 materials.-phm

This chapter contains commonly occurring design situations, and recommended solutions for each. These solutions have been applied frequently by applications supported by leading carriers. All of the solutions that have been explicitly tested in usability studies have fared better than alternate designs. Because they are so common, they improve usability by the virtue of their familiarity.

The previous chapter contained issues affecting the design of your entire application; this chapter focuses on a collection of screens within the application. Continue to the next chapter for generic screen design, and the subsequent chapter for specific types of screens.

[edit] Alphabetical List

An alphabetical list occurs in many situations, such as a list of countries, cities, or states. It can also occur as a list of user contacts. The list of data is typically navigational - for example, pick a city to get its weather or pick a car manufacturer to get a car's value.

Designing an alphabetical list in the best possible way depends a lot on the number of items, how the device renders links and lists, and how the user can select items in the list. As you read the recommendations below, be sure you select the design based on your situation.

− For small sets of data (3 screens or less) simply display the list of data without supplemental navigation. On average, the user will visit 2 screens of a 3-screen list. The best possible navigation described below results in 2 screens. Keep it simple. Each screen would be a List of Data, as described on page Error! Bookmark not defined..

− Give users access to alphabetical data using a TextBox, instructing the user to type the first 2-3 letters. This practice makes a very targeted list - if not the precise data item - one screen and 3-4 key presses away. With a full keyboard, this will be faster than navigating 2 or more screens.

Scroll and select devices, such as phones, require the user to scroll through all the links, just like users of screen readers. For this reason, the standard PC solution of one link for each letter of the alphabet is inappropriate. Instead, the data needs to be grouped. The specific method of grouping depends on how the device renders a list.

On devices without keyboard shortcuts for lists, or scroll-and-select devices without a keypad, the design goal is to minimize the number of screens while keeping an appropriate amount of scrolling, balancing breadth and depth. Try to keep scrolling to 3-5 screens of information; if you are not targeting a specific device assume the device supports 4 lines of content per screen. Don't forget to account for items wrapping and taking two lines of space.

Various sources give you specific numbers regarding the number of items to place in a list, but it depends on the application. You need to balance breadth and depth. In the current example, an alphabetical list on a scroll-and-select platform without keyboard shortcuts, you will want to have larger letter groups when you have a small database, so that users do not have to view a lot of screens to scan all the data. However, a larger database will likely be best accessed with small letter groupings so the results are not prohibitively long.

− If you are not using accesskeys, group data into approximately 9 roughly-equal groups, with easy-to-represent groupings. For example, there are 50 states in the U.S. 9 equal groups would mean 5-6 items per group, but there are 8 states starting with M (Minnesota, Michigan, Missouri, Montana, Maine, Massachusetts, Maryland, Mississippi). Although it would theoretically be faster to break these into two groups, the more complex labels in the list require more processing from the user. Keep these states under the simple label "M".

In many cases, the total number of items is greater than approximately 90. In these cases, each group will have more than 10 items. In these cases, you have to make a decision between further categorization and extending the list to a second (or third) page.

The underlying goal is to get the user to the data in as few keystrokes and as few screens as possible. If there are two navigational menus leading to a third screen that has the list of data, the user must go through 4 screens (select PQRS, select Q, select data item, and then view the data). On the other hand, if there is one navigational screen leading to a list of data that is 3 screens long, the user must also go through 4 screens (select PQRS, 1/3 time item is on first screen, 1/3 on second, and 1/3 on third, for an average of two screens of data list, and then view the data).

− Restrict the number of screens of item data to three per letter grouping. Anything more than three screens results in more screens (on average) for the user to visit. Therefore add an additional layer of navigation, grouping the items into approximately 9 roughly equal groups.

− Use at most two levels of navigation for an alphabetical list. Anything more is generally too complex for the mobile environment, and users will likely get lost. Note that this limits you to roughly 2000 (10 at first level, 10 at second level, 10-30 at the detail level) items.

Although 2000 items may be reasonable for an alphabetical list with a known ordering of data, they are too many for a categorized list. In this latter case, the user may have to explore many branches before determining the correct path to data. See Navigational Menus.

[edit] Sports Scores

Sports scores are often reported in the form of Visitor's Name, Score, Home Team Name, Score, Game Status (e.g., Yankees 4, Cubs 6, 8th inning). If you casually apply this format to a list of data, menu, or other screen type, your information is guaranteed to look awkward most of the time on most phones.

− Display visiting teams first, home teams second. You may be tempted to list winning teams first. There are better ways to show who won a game, but listing the visitors first is a reliable convention. In cases where there is no visiting competitor (e.g., tennis matches), we recommend listing the higher-seeded or higher-ranked competitor first.

− For simple scores (where a single number represents each team's score), display scores before the competitor name, not after. In print, it is more common to see the score displayed after the team's name (e.g., Lakers 96). But on a phone's small display, placing the score before the name will provide the best consistency despite the variability in team names and screen sizes.

For compound scores (where multiple numbers or sets of numbers represent each team's score, as in tennis), display the scores following all team/individual names. Use a new line for these compound scores (see example).

If a team/individual's name carries a notation such as a ranking or seeding, display that notation in parentheses following the team's/individual's name. For example, if Florida State were the first-ranked team and had scored 21 points as a visitor, then the first line of their score would be "21 Florida State (1) vs."

Use a separate line of text for each team and their score. Follow the first (visiting) team's name with "vs" or other appropriate text. Note that different sports have different conventions in displaying match-ups (e.g., in tennis, a "d." is used between players' names to indicate "defeated.").

Use abbreviated team/league references when appropriate. Three-letter abbreviations (e.g., CHI for Chicago teams; NBA for National Basketball Association) are widely understood for professional, big-league sports. Avoid abbreviations for college teams, as these abbreviations are not well known.

Place visual separators between score pairings. Failure to do so will cause misleading visual pairings on small screens. See Visual Segmenting for more on this technique.

When reporting scores, include the date and proper notation for the league, conference, tournament, division, et cetera. If you tell the user that they are reading NBA scores, then a score for "CHI" clearly indicates the Chicago Bulls. Otherwise, "CHI" could refer to dozens of teams. Don't assume that readers will know which teams are paired together on a given day.

[edit] Complex Entry: Wizards and Forms

Wizards and Forms represent two standard methods to lead users through the completion of a data entry or other task involving user input. Wizards and Forms are very similar tools, but each has an optimal purpose. This section should help you decide which tool best fits your needs.

A Wizard is a series of single-task screens that walk the user through a data entry task. Each screen has one menu or one text box (a few situations allow for two text fields). The user proceeds through the task screen by screen.

A Form (not the MIDP widget Form) is a single screen containing all the parts of the data entry task, visible at once. On some devices, text entry can be done on that screen; on most devices the user must go to a different screen or widget to perform text entry or select a setting from some type of menu.

Whether to use a wizard or a form for a particular application has been a source of much disagreement and research. The best available research leans towards using forms. One study says "always use a wizard". However, this study was performed using a single application scenario on a single device - and that device had a navigational Back button separate from the delete character button, giving users easy navigation. A more rigorous study used 4 times as many users with 3 different scenarios comparing wizard and form, and used a highly typical Openwave-style WML browser. This study found that users took slightly more time with a form and made slightly fewer errors, but that users have a marked preference for forms. As this will certainly also be true for most MIDP devices, we can conclude that, in general, forms are better. Because every application has a different situation, testing your own application design should determine the better design choice.

− For most situations, use a form. Although they take more time to use, users tend to make fewer errors with a form. Further, users tend to have a strong preference for forms. As more and more devices and platforms allow for in-line editing (as opposed to separate screens), this time penalty will disappear.

− Consider a wizard when the user must enter data in a particular order or fields are inter-dependent. A wizard will reduce the probability of error.

Consider a wizard when some or all of the data entry process requires an introduction. A wizard allows you to insert explanatory text as the user needs it.

For very complex interactions, combine wizards and forms. A handful of required fields can be a wizard leading into a form containing all fields.

Consider combining related form items into one "nested form". Instead of separate items for "last name" and "first name", instead have an item "name". If you can't parse user entry from a single field, then you can launch either a mini-wizard (2 screens) or a form for first and last name.

[edit] Complex Data Entry: Wizards

Wizards are simple and easy to understand, but can have one major shortcoming if you are not careful: they make it very difficult to correct mistakes.

− Back (prev) on each field in the wizard should take the user to the first screen in the wizard. This prevents the user from having to clear out data on each input field and saves key presses. If you do this, it's also important to put the data into the input field when the user revisits each screen.

_ Display previous user entry when the user revisits a screen. This is applicable after the user navigates backwards and you've mapped the prev function to the first screen in the wizard (as suggested above). Remove this data once the user selects "Save" or otherwise ends the wizard.

Avoid wizards. Users prefer forms.

− Avoid long (5+ items) wizards. Wizards are simple and easy to understand, but can have one major shortcoming if you are not careful: they make it very difficult to correct mistakes. A user who wishes to back up and correct an error may be forced to delete all data entered between their current position and the error.

− For long wizards (> 6 steps), provide a means to abort or save data from the process. A screen asking the user whether the wish to continue the wizard can be a welcome relief. Otherwise, users may be forced to exit your application completely because they are unwilling to press the Back key a few dozen times.

Precede long wizards (> 6 steps) with a message stating the number of steps in the wizard. This will alleviate the "how long does this go on?" question.

− Do not put optional information in the same wizard as required information. By their nature, wizards imply that each field must be completed. Also, it may be unclear how to advance while leaving a screen blank.

− Add a method to review and edit data following a wizard. One method is to provide a form immediately following the wizard. This allows the user to look at all the data at once, correct mistakes, or change their mind. This is especially important for wizards with intensive data entry like purchasing or email writing.

Consider introducing the wizard with a separate screen containing an overview of what will be entered. This is especially useful when the user is expected to enter non-standard data or use special formats.

− The primary command should advance to the next screen in the wizard. Use "Next" for the label.

Restrict input of later fields using earlier fields. For example, if you need to ensure that a valid street address is entered, order information by state, then city (allow only cities in that state; ideally there would be a list of cities to select from), then address. If your users are likely to know the ZIP, allow that as an option in lieu of state/city.

[edit] Complex Data Entry: Forms

Forms offer more editing control than a wizard, but their complex appearance may be daunting to some users. Users may believe that an entry is required for all items.

Please see Interactive Forms for more information on designing forms.

The primary command should be ".

The second command should initiate the proper action on the data. "Save" and "Find" are example labels. On Nokia devices, the command will instead be a link at the bottom of the screen. Do not put this action as a select list item; it is rarely good to mix objects and actions in the same list.

[edit] Visual Segmenting

Screens with large amounts of information may become visually crowded and overwhelming, especially on platforms without layout control. You can alleviate this problem by dividing the information into meaningful segments and then separating those segments either by placing the segments on different screens or by interspersing the segments with visual separators.

− Use a row of 6-12 dashes between logical segments on devices with text-based layout. Note how the dashes help break up the data into meaningful groups of values rather than a dizzying series of text.

Because many phones display 3 lines of text (4 if you include the softkeys), information that is displayed in repeated pairs is particularly troublesome. For example, in the examples, consider the leftmost screen in which football scores are displayed in pairs. It's clear which teams are paired. But look what happens when this same card appears on a 3-line display (center screen). Once the user scrolls down one line, the pairings are now lost. Now it looks like Minnesota beat Indianapolis, 17 to 14.

[edit] Quick City Lookup

Many applications call for the user to input or select a city. In our never-ending search for ways to avoid text entry, we've developed a useful user interface that allows users to select the 144 largest cities with as few as 3 or 4 clicks. Especially for applications where it's necessary only to specify a metropolitan area (e.g., weather forecasts, sports scores), this method may represent the fastest means to input a location.

Basically, the idea is to take the top cities in your region, group them based on the needs of the platform and device, and not require the user to select country or state.

Rank the top 150 cities and sort alphabetically into 9 roughly-equal groups. There is no keypad shortcut to quickly access items. See Alphabetical List for details.

Use two Navigational Menus to display the top cities in a group. Use "More" to connect the first menu to the second.

[edit] Series Reader

Applications that provide information (news, email, quotes, etc.) often display lists of titles in a menu, each leading to a more complete version of the particular piece of information. For example, a user may select from a list of headlines to view a complete story. The series of titles may or may not represent a meaningful sequence; either way it allows the user to quickly scan for the information they seek. There are many applications of this scenario: email messages, calendar items, news stories, stock quote details, search result details, driving directions, et cetera.

Different users will approach these kinds of lists with different goals. Some seek one particular piece of information. Some want to read the whole list in detail. Others may wish to access two or three items not in sequence. To accommodate these different goals, we have developed a navigation paradigm that we like to call a "Series Reader," because it's useful for reading information presented in a series or list.

There are two alternatives for the design of a Series Reader, depending on whether the series is to be read in a loop (i.e., it makes sense for the user to go from the last item to the first item) or the series is meant to end with the last item. Each of these alternatives is described below.

In a "non-loop" Series Reader, the user is not expected to go from the last item to the first item. There are two basic components: a parent menu screen containing the header of each item, and child screens containing each piece of information in its complete, detailed form.

In a "looped" Series Reader, the user is permitted to go from the last item to the first item. The basic components of this Series Reader are the same as the non-looped variety: A parent select list containing the header of each item, and child screens containing the items in entirety. Users often will go through a list of items until they reach the end.

− Use a series reader to navigate through lists of data.

− If the Series Reader is meant to be read in a loop, add an end-of-list screen. Because there is no end to a looped series, an end-of-list screen provides users with a landmark to help them see where the list begins and where it ends. This special screen lets the (now informed) user choose to loop back to the beginning of the list or to end the list and exit the Series Reader.

Use NEXT as the primary command in child screens (articles) of a Series Reader. It has been shown in usability tests of news sites that novices are likely to misinterpret NEXT as referring to the "next page" of the article they are reading. It seems SKIP does not exhibit this problem when used in the same application. Nonetheless, we suggest using NEXT as the primary command label because SKIP has connotations that may be false or confusing in some applications. For example, SKIP is inappropriate beyond the first card of a multi-page article since it is illogical to skip a story that one has just read. NEXT is more generic and thus a more suitable recommendation for Series Readers in general.

Another variation of the Series Reader is the abbreviated Series Reader. In this variation, the parent screen containing the article headers is not used. The user starts with the first article screen and may either read it or go to the next screen. This form of the Series Reader is useful assuming: 1) users are expected to read articles in sequence, and 2) users are not expected to be searching for a particular article, and 3) the number of articles is small. If any of these assumptions is not true (as is usually the case), then you should not use an abbreviated Series Reader.

_ Split long items across multiple screens. When building your Series Reader, you may have to deal with a piece of information so lengthy that it requires multiple screens. You'll need to link those screens using a MORE command. For modern 3G devices, a large screen would contain approximately 5 screen-lengths of data.

− Use notations such as "1 of 3" at the top of a screen to indicate the length of a story. Users will use the information to navigate within a story and to determine whether they want to read the story.

[edit] Cancel Guard

Cancel Guards (a.k.a. Delete Shields) are intended to avoid inadvertent cancellations out of processes that are difficult to re-perform--especially processes that include data entry. Because the CLR (Back) key is used both as a back key and a backspace key in input fields on many devices, accidental cancellation is a real threat.

A Cancel Guard is a screen activated when the user backs out of an input process. The screen asks the user to confirm whether they actually want to cancel the process that they are canceling. An example is a plain screen with a question such as "Do you want to cancel this entry?" with the responses NO and YES. If the user selects NO or presses Back (CLR) again, then return to the input screen. The exact text of the question should fit the situation. When possible, improve clarity by labeling each softkey to represent its result. For example, if your question is "Do you really want to erase this file?" then your commands should be CANCEL and ERASE. To avoid yet another inadvertent cancellation, YES (or whatever label matches the destructive action) should be the secondary command

− Consider using a Cancel Guard when the user may destroy data. Situations include when the user presses CLR in the first card of a subroutine or input series, when the user presses CLR to delete text but presses it one too many times, or during a complex process (e.g., composing an email) in which the user may inadvertently cancel before the process is completed (e.g., before the email is sent).

[edit] Navigational Menus

Use a Navigational Menu when you need a screen whose primary purpose is to allow the user to find content on another screen. Contents of the All Screens chapter apply to Navigational Menus.

Your main screen is likely to be a Navigational Menu. They are easy and efficient to use. Implement a Navigational Menu with an Implicit List, following all the design rules, as well as the following:

− Items should be ordered based on frequency of use or - less commonly - importance. This is true unless there is a natural ordering, such as numeric or alphabetic.

− Avoid wrapping navigational menu items. The best way to accomplish this is to have menu labels short enough to display on one screen width.

_ Navigational menus must have at least two items. If there is only one item, skip the menu entirely and perform what would have been the implicit action.

Various sources give you specific numbers regarding the number of items to place in a list, but it depends on the application. You need to balance breadth and depth. Consider the example of a navigation menu. Users look at each item in the list and decide whether they want to follow that item, or definitely not, or whether they don't know. On a small screen, they will not be able to see all the items in the list to quickly compare them without scrolling, so they will have to remember many of the items. For this reason,

_ Keep navigational menus to 10 items or fewer. The "magic number 7 plus or minus 2" applies to the number of items the user has to remember, which will not be the complete set of items.

In most cases, the ITEM command label should be “OK”. This will take the user to the location selected with the cursor.

In most cases, secondary actions should be navigational. Adding actions to a navigation screen is confusing. Don't use "Back" as a softkey. If you have no appropriate action for the softkey, consider placing a navigational path to your application's main menu.

[edit] Action Menus

Action Menus are created with the same code as a Navigational Menu is, but are used in a different context. Action Menus are typically accessed by a MENU command or link in a parent screen. They contain a list of actions and (optionally) navigational items. The effects of actions are context-sensitive, based on the parent screen or the item that was highlighted when the screen was accessed. For example, a screen showing an email message contains a MENU command. The resulting select list contains a DELETE action, allowing the user to delete the just-viewed email. This menu may also contain a navigational path to a set of email folders.

Unlike most other platforms, J2ME automatically creates action menus from the list of abstract commands defined for the screen. Unfortunately, the automatic rendering does not give the user all the control, feedback, and flexibility as you might want.

Ideally, the Action Menu is not simply a list of commands, but a separate screen with its own title. The title and context gives the user information about what item is being acted upon. Note further that on a Palm device, the extra commands will not be hidden in the menu hierarchy.

Implement an Action Menu with an Implicit List, following all the design rules, as well as the following:

− If the actions in an Action Menu do not all apply to the same object, then items should indicate their object. If you have an Action Menu containing email actions, like "Reply", "Reply All", "Forward", "Erase", and "Erase All", the first four items apply to the selected email and the fifth item applies to the folder. Adding the email's subject line (truncated to approximately 15 characters) to each action that applies only to the message reduces ambiguity. Although a more generic "Reply to msg" label will help distinguish menu items, the user will have to remember which message was selected. Recall that a slip of the finger can cause an unintended message to be selected.

_ If the actions in an Action Menu all apply to the same object, then the screen header should be the name of that object. If all the actions on the screen apply to the email message "Hello, Bob (tsel2@somewhere.com).", then the header of the Action Menu could profitably be this message label. Because the message was selected from the previous screen, its identity is sufficiently rendered when truncated to fit on the screen.

_ Ensure that all items are valid based on what was highlighted when the menu was accessed. Items in an Action Menu should be context-sensitive. Don't display items when their selection would have no effect or make no sense. For example, a list of email items might contain "More" as the tenth item. If the user activates the "Menu" command while "More" is highlighted, then "Delete" should not appear in the Action Menu because "More" is not an email and cannot be deleted.

− Do not rely on the device to automatically create your Action Menus using abstract commands. The device will not display the selected item. You may not have control over the exact order of items. You will not have control over the header, which may say "Menu". You will not be able to add or subtract actions based on which item was selected.

The primary command label should be “OK”. This will execute the action or take the user to the location selected with the cursor.

The secondary command should be one of:

• CANCEL. Cancels the action and returns to the appropriate parent screen.

• Secondary navigational option (e.g., MAIN).

• DONE. Returns to the appropriate parent screen. Useful when the menu is part of a more complex process or set of submenus.

While MIDP2 allows you to use long command names, these long names will only display in menus, not in softkey labels. Providing a menu on an Action Menu creates unnecessary levels of information and engenders user confusion. Thus long command names are unnecessary.

− Use at most two commands. Creating a menu of actions to work on your Action Menu is at best confusing.

[edit] List of DataBold text

Use a List of Data for data items such as email messages or news headers. Contents of the All Screens chapter apply to Lists of Data.

Implement a List of Data with an Implicit List.

− Most times, a List of Data will be the main screen of a Series Reader,

− Sort data contextually. Items may be sorted by type, date, or whatever makes sense.

− List elements may include images. Recognize this when creating element labels.

− The primary command should be labeled “VIEW”, “OK”, “READ”, or “OPEN”. It's action should be to access the highlighted item. This will almost certainly be the most frequent item. This should be a ITEM command type.

The secondary command (softkey) depends on context. Actions include:

1. 1. A context-dependent action (e.g., ERASE)
2. 2. Secondary navigational option (e.g., MAIN).
3. 3. MENU. Opens a submenu of actions and navigational options. Actions in that submenu will operate on the whole screen or the currently highlighted item, as appropriate.
4. 4. DONE. Returns to the appropriate parent screen. Useful when the list is part of a more complex process or set of submenus.

ALL SCREENS 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. Title and Header This section and this guide refer to both "titles" and "headers", because some widgets explicitly use a title element to create a screen title. However, not all widgets 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. _ 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). − 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. Contents of Screen 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. Content Authoring: Less is More 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. 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." Text In addition to adopting the motto, “minimize, minimize, minimize”, there are other practices that will enhance the user experience. These are derived from a mix of standard usability knowledge, technical implementation details, and an understanding of issues arising from display on small screens. − 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." − 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. − 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. − 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 (e.g., ticker) Exception: applications written for languages written right-to-left, like Hebrew. Do not use soft hyphens. They don't work on many devices. Commands and Softkeys J2ME MIDP 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 MIDP 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. Commands have labels, types, and priority. The command type and priority determine where in the UI the label is placed. Rendering differences may cause a command's label to be placed inconsistently on different devices. 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). MIDP2 allows developers to specify two different command labels, regular and long. Devices will typically display the regular labels as softkey labels, and the long label when the command is rendered in a menu. Thus if you have a command that is better understood with a long label, you can provide it while still providing a reasonable abbreviation or truncation for display as a softkey. 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. _ Restrict regular command labels to 6 characters. Command labels may be displayed in a menu, in which case they can be much longer. However, most devices will render high-priority commands' labels as softkey labels. 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, or if you are using MIDP2's long label, the label can be as wide as the device display - you can assume 20 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. − The following labels should be avoided: “Exit”, “Clear”, “CLR”, “End”, “Power”, and “PWR”. These are reserved for device use, or conflict with labels of hard keys. − Do not use “Back” as a command 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 Error! Bookmark not defined.. If you didn't read it, you should now. _ Do not use the same label for multiple commands. Dead-end screens are those which do not lead deeper into a menu hierarchy, but instead return the user to the card of origin. Such screens 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. − Provide a SCREEN command labeled “Done” on a dead-end screen. 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 screen and thus offers a "reverse alternative" to “OK”. Depending on the language of the screen, there will be times when “D” 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 screens 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. − 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!). _ 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. 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. 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. − Prioritize 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. − 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. 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. − 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. − 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. _ 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. 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. − 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. 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. − 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. Tickers J2ME provides a ticker control that is a common element displayed across multiple screens in an application. It is one line and contains a text string that "marches" across the screen like marquees do on Times Square. − Include dividing characters or spaces at the end of the Ticker string. The Ticker simply displays the beginning of the string immediately after the end. If the message is a sentence or other logical unit, provide a separator like ||| or >>>. If the message is looped information (like a stock ticker) simply put an extra space or two at the end of the string. − Test the Ticker speed for readability on a variety of devices. Differences in ticker speed, screen width, processor speed, and pixel size will cause legibility to differ. Moving text is hard to read. _ Move Ticker text right-to-left. This most closely approximates left-to-right reading styles. Exception: languages written for right-to-left languages like Hebrew. _ Keep information critical for the user to understand extremely short (less than 30 characters). When users read moving text in a small area, they frequently forget the beginning of the sentence long before the end of it is visible. Further, they are likely to get distracted (and are certain to get frustrated) during the long duration of text moving by. − Keep a "list of facts" to fewer than 10 items. Users are unlikely to watch several facts (like stock prices) go by. Give the information to them in a list. Use Tickers to provide application-wide contextual information. A personal information manager might put the time of the next appointment and the arrival of a new email message in the Ticker. Keep this very short (ideally one screen.) Avoid Tickers. Moving text is hard to read. Anything moving on the screen is distracting. 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. 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: 1. Color - keep the same small family of colors (color palette) on images throughout the site. 2. 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. 3. Contrast - on mobile devices, keep contrast high. 4. Size - keep images consistently sized; for mobile devices, the size is small. 5. 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. 6. 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. Content − 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. − Don't use animated graphics that can be mistaken for a Gauge. Your user may simply look at the screen waiting for the process to end. Provide a visual control indicating how to continue. − Use only images appropriate for audience. An application 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. MIDP supports only PNG (portable network graphics) format. Some devices additionally support JPG and GIF. − Trim palettes to the minimum appropriate size. Your application will run faster. − Design your audio, video, and graphics explicitly for mobile use. You will not achieve good results by simply mapping your desktop media. For example, a wide shot of a baseball game (video or image) can result in enough image compression that the players become dots; the ball will be invisible. Use closeup shots. Understand sampling and compression that devices and gateways use. Size and Layout _ 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. _ Keep supplementary graphics small. This requirement applies to graphics that are not the main purpose of the screen, 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 graphics use valuable memory on the device. _ 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. − 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. Design the screen based on both fixed-width fonts and variable-width fonts. 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. Sound and Vibration Sound management is a bit tricky for MIDP applications. Most, but not all, devices have volume control buttons, but not all of them will affect volume within an application. Perhaps worse, the volume control might affect all settings for the device – turning volume down or off in an application could turn the phone's ringer off! For this reason, some devices have a separate volume setting for all MIDP applications which will not affect other parts of the device. In addition to implementation complexities, there are also a variety of usage complexities. A user may be surreptitiously using an application on her phone, and may not want the other people in a meeting to be aware of it. This can even hold true for vibration on some devices. − Restrict the amount of time the device is vibrating. The vibrator reduces battery life. _ Do not play background sounds unless the user has requested it. "Background" sounds may distract the user, will reduce battery life, and may cause the user embarrassment in quiet environments. − Use MIDI rather than WAV or AAC for sound when possible. While WAV files may sound more realistic, MIDI will use less storage and may be more discernible. Use higher-quality sound to make lower-quality video more acceptable. Users find the combined experience more acceptable.