Mobile Style Guides - Screen Design, Part 2
From MobileDesign
Contents |
[edit] 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. Don’t confuse this element with "marquee" formatting in XHTML or "line" formatting in WML. Although it is displayed similarly, it is a separate element and not a method of formatting strings or paragraph.
| 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. | J2ME |
| 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. | J2ME | |
| Move ticker text right-to-left - This most closely approximates left-to-right reading styles | J2ME European | |
| Move ticker text left-to-right - This most closely approximates right-to-left reading styles | J2ME Arabic Chinese Japanese | |
| 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. | J2ME | |
| 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. | J2ME | |
| 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.) | J2ME | |
| Avoid tickers - Moving text is hard to read. Anything moving on the screen is distracting. | J2ME |
[edit] Styles
| Do not rely on the CSS "font-variant" property - The simulator does not render this CSS property. | XHTML-MP Nokia Openwave |
| Do not rely on the CSS "font" shorthand property - The simulator does not render this CSS property. | XHTML-MP Nokia |
| Do not rely on the CSS "background-attachment" and "background-position" properties - The simulator does not render these properties. The only CSS property currently supported that controls backgrounds is "background-color". | XHTML-MP Nokia Openwave |
| Use the CSS "background" shorthand property cautiously - You may declare any CSS-MP background property except for "background-attachment" and "background-position". Not all CSS-MP property values will render correctly. Use values that are normally supported by the simulator, such as anchor named color. | XHTML-MP Openwave |
| Do not use negative values for any "margin" CSS properties - The simulator does not render negative values for this CSS property. According to documentation, Openwave should support negative values, but they are not rendered in the simulator. | XHTML-MP Nokia Openwave |
| Do not use the CSS "border-style" shorthand property - The simulator does not render this CSS property. Instead, specify the styles for all necessary sides, such as "border-top-style" and "border-left-style". | XHTML-MP Openwave |
| Do not rely on the CSS "float" property - The simulator does not render this CSS property. | XHTML-MP Openwave |
| Do not rely on the CSS "visibility" property - The simulator does not render this CSS property. | XHTML-MP Openwave |
| Do not rely on the CSS "border-top", "border-right", "border-bottom", "border-left", and "border" shorthand properties - The simulator does not render these CSS properties. | XHTML-MP Nokia |
| If you declare border properties, consider using the CSS shorthand properties "border-color", "border-style" and "border-width" - The simulator renders these CSS properties. Using them may simplify your style sheet. | XHTML-MP Nokia |
| Do not rely on negative values for any CSS "padding" properties - The simulator does not render negative values. According to documentation, Openwave should support negative values, but they are not rendered in the simulator. | XHTML-MP Nokia Openwave |
| If you declare padding properties, consider using the CSS shorthand property "padding" - The simulator renders this CSS property. Using the shorthand version may simplify your style sheet. | XHTML-MP Nokia Openwave |
| Do not rely on the CSS "text-transform" property - The simulator does not render this CSS property. | XHTML-MP Openwave |
| Do not use numeric values for the CSS "font-weight" property - The simulator does not render numeric values for this CSS property. Use named values, instead. | XHTML-MP Openwave |
| Use numeric values with the CSS "font-weight" property - Numeric values give you more precise control than named values over font appearance on devices with more font sizes. | XHTML-MP Nokia |
| Do not rely on the CSS property "display" - The simulator does not render this CSS property. | XHTML-MP Nokia Openwave |
| Avoid using the CSS named font values "x-large" or "xx-large" - Both values render the font as 13 pixels. One line of text this size may fill a quarter (or more) vertical space on small screens. This increases scrolling, which should be avoided. | XHTML-MP Nokia |
| Use the CSS value "text-decoration:blink" sparingly - Although 'blink' highlights an element, if overused it may detract from the overall usability. No more than one element per screen should use it. Few elements should ever need it. | XHTML-MP |
| You may use multiple values for the CSS "text-decoration" property, but NOT in the same CSS declaration - You may apply more than one "text-decoration" value to an element through inheritance. Do NOT declare more than one value within a single class or related set of property-value pairs. If you apply both values in one style declaration, only one value will apply. Although you may combine values, avoid underlining plain text as it might be confused with a link. | XHTML-MP Openwave |
| Do not apply more than one style value to an element with the CSS "text-decoration" property - You may not apply more than one "text-decoration" value to an element, even through CSS inheritance. | XHTML-MP Nokia |
| Avoid use of the "align" attribute of header, br, div, and p - It's better practice to use style sheets to specify the alignment of these elements. | XHTML-MP Openwave |
| Avoid use of bgcolor, link, and text attributes for the body element - It's better practice to use style sheets to control these aspects. | XHTML-MP Openwave |
| Avoid specifying the list type for ordered lists - It's better practice to use style sheets to control this value. | XHTML-MP Openwave |
| Avoid use of hspace and vspace attributes for the image element - It's better practice to use style sheets to control these values. | XHTML-MP Openwave |
| Do not rely on CSS to affect images - CSS applied to the image directly or to container elements may not be applied. | XHTML-MP Nokia |
| Use "solid" as the value for CSS property "border-style" - "solid" is the only value currently supported by the Openwave Mobile Browser for this property. | XHTML-MP Openwave |
| Do not rely on adding a border to a table or styling the border using CSS - The simulator does not render any values for CSS border properties applied to tables. | XHTML-MP Openwave |
[edit] Multimedia and Graphics
In general, graphics on mobile devices should be smaller, simpler, and fewer than on desktop applications. Some devices don't support graphics at all, some support graphics but have pixels that aren't square, many devices do not have color, most devices have small screens, and all devices have limited bandwidth or processor capability.
Alternate text (alt text) is displayed when the device has not successfully downloaded the graphic. This may happen because the user has turned off graphics, because the page has not yet finished downloading the graphic, because the graphic was not found, or because the device is incapable of displaying graphics. Standard web design practice says to always use alt text, but even the simplest analysis says this is not true.
| Use alt text to describe graphics that carry meaning - Site logos and content images are integral parts of the experience of a screen or site, and the user needs to get as much information as possible even if the images are not displayed. The alt text should describe the image (if the image itself is content) or the meaning of the image if the image is metaphoric. For example, don't describe your corporate logo as a bouncing ball, describe it as "ACME, Inc." | markup |
| Use single-character alt text to describe "marker" icons - Marker icons are used to give the user a little information about the nature of a select list item, link or other bit of text on a screen. A graphic of a paper clip that indicates that a message has an attachment might have alt text of "+". A graphic of a closed envelope indicating an unread message might have alt text of "*". | markup |
| Avoid alt text for graphics used simply for layout or emphasis - Of course, if you use CSS, you shouldn't have many of these. | markup |
| 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. | |
| Ensure graphics resize gracefully and use the CSS "width" and "height" properties to size them appropriately for each device - Customized sizes will optimize screen layout and ensure images do not get cut off if scrolling is disabled or not supported by the device. | |
| Avoid image maps - Most platforms don't support them. For those that do, image maps are large and require sophisticated input/output characteristics. | |
| Keep graphics very small (under 4KB) - Users have to pay for download time, and they use valuable memory on the device. | |
| 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. |
Perhaps the most important thing to remember about graphics, is that devices may have 256, 64, 16, 4, or 2 colors for graphics - and some devices don't have graphics at all. On some devices that support graphics, users may not choose to download them.
Openwave browsers can display graphics in links, plain text, or select items. They are displayed on the same line as neighboring text, barring wrapping or extra <p> marks. The placement of the image will match the formatting of the <p> element.
| Provide graphics in the appropriate format - MIDP supports only PNG (portable network graphics) format. Nokia supports WBMP and GIF. WML supports only WBMP (wireless bitmap) format. | |
| Do not define borders around normal images - In the Nokia Mobile Browser 3.0 image links are distinguished with a border. | XHTML-MP Nokia |
| If an image takes up less than half of the display, float text around it using the CSS 'float' property with 'vertical-align: top' - Floating text around images conserves space and reduces the amount of scrolling. Openwave does not support the CSS 'float' property, so ensure your screen works without it. | XHTML-MP |
| Add a few pixels of padding around images using the CSS 'margin' property - If there is no padding, adjacent content may bump up against the image. | XHTML-MP Nokia |
| 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. | |
| Do not implement image maps - The user has no way to click on a portion of the image. | scroll & select |
| Images must 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. | |
| Ensure your application displays well without graphics - Not all devices have graphics capability. | |
| Use graphics only when they serve a purpose - For example, don't precede your main menu with a splash screen just because you're proud of your company logo. Your users are paying for the airtime. Don't waste it. And don't forget that images take longer to load than the textual equivalent. We've observed users abandon sites they believe are malfunctioning when there's actually just a delay due to downloading images. | markup |
| Use built-in icons (localsrc images) where possible - This will result in faster loading and a less expensive experience for the user. It will also give the screen more capacity for text content. However, always define the URL for the image on the server, in case an error occurs. See Openwave's SDK documentation for more information on localsrc images. | Openwave |
| Make sure graphics line up - On text-based platforms, design the site based on both fixed-width fonts and variable-width fonts. On graphics platforms, place your graphics carefully. Test your graphics on a wide variety of devices. Ensure that the presentation is appealing to the eye. | |
| Unless vertical scrolling is appropriate for an image, the image should not exceed the screen height, minus softkeys or buttons | |
| Images serving as headers of menus or input screens should ensure that at least one line of the control is visible - Generally, take the screen height, subtract 15 pixels for softkeys and 15 pixels for the first line of the control. Otherwise, the top portion of the image may scroll off the screen or the user may not realize that more content is on the screen. | |
| Use caution when putting an image on a screen with a timer element - The screen may time out before the image is displayed. | WML XHTML-MP |
| Image alignment should be "bottom" - Some devices may truncate the image otherwise. | WML Nokia |
| Put no other elements on the same line as an image - The device may not render appropriately otherwise. | WML Nokia |
| Ensure at least one dimension of the image fits on the device - The Nokia simulator can not scroll if the image is both wider and taller than the screen. | XHTML-MP Nokia |
Some devices and platforms give you access to the device's ringer, vibrator, MIDI player, or general Media player. Many devices allow graphics on some or all screens.
[edit] Bookmarks
Although beginners will not know how to create them, bookmarks allow users to customize the browser to match their personal needs and are a very good tool. Users who do understand bookmarks and can find them will expect behavior similar to HTML. Openwave browsers assume storage on the gateway (so bookmarks are unlimited, but only if an Openwave gateway is available); Nokia browsers store bookmarks on the device.
| Assume the screen title will be the default bookmark label - | markup |
| Almost everything should be markable - The user won't understand why a card isn't markable. In particular, ensure that select lists, find cards, and content cards are markable. | HDML WML markup |
| Mark the appropriate card - If the user marks a card in the middle of a process (or wizard), the bookmark should point to the beginning of the process. For example, all the cards in an order-entry series should point to the first card in the series. | HDML WML markup |
| Ensure necessary navigation and data are available - If a card relies on the "Back" function to work properly, a different card in the application should be marked. If the card displays data from a user selection, the site should either set a cookie containing that data or point the bookmark to a different card. | HDML WML markup |
| Bookmark labels should be context-sensitive - The default label (the title attribute of the card) should provide as much data as possible, especially if it relies on user data. For example, if the user marks a Microsoft stock quote, the bookmark label should be "MSFT Quote", not "Stock Quote." The user should never be required to edit the bookmark label to make it usable. | markup |
| Allow the user to bookmark cards with input fields leading to information - For example, allow the user to bookmark the flight number entry in an application to check flight schedules. | HDML WML markup |
Certain cards should not be markable. The following items should either be not markable, or should point to some other card.
| HDML WML markup |
