Mobile Style Guides - Multiple-Device Platforms

From MobileDesign

With the rapid increase of number and variety of devices, the old model of creating one operating system for each device (or family of devices) has broken down. It is not financially feasible to create new operating systems all the time, nor is it good for users or carriers. Developers are the most affected, however, as creating an application that runs on multiple operating systems is very expensive. Thus there have been several movements to create platforms that run on multiple devices.

Some platforms are operating systems themselves, such as PalmOS, Windows CE, or Symbian. The first two occurred because one company created an OS that device manufacturers implement; the other was created by a consortium of device manufacturers. In theory, developing an application to run directly on one of these operating systems will result in a highly usable, "native" application. In practice, there are sometimes minor differences between devices that may affect how an application renders. Because these differences are minor, this section focuses on other platform types.

Some platforms are markup languages that display in browsers running in the native device operating system. In theory, the device renders the markup code in a way that appears native to the device, allowing developers to write a generic web page. In practice, the decisions made by the device (browser) manufacturers assume different developer intent for the same tags. Thus if a developer uses a tag matching the intention of browser A, it may not match the intention of browser B and the user won't figure out how to use the application running on browser B. For example, Nokia assumes a "title" tag for a WML 1.x card should be displayed at the top of the screen (but only one line); Openwave assumes there will be content on the card describing the card and thus relegates the title for use as the default bookmark title.

Some platforms, such as J2ME and BREW, allow developers to write applications that are stored on the device. Although invisible to the user, there is an application environment on the device that has been designed to make the platform's applications look as native as possible. These platforms suffer many of the same troubles as markup language platforms. The rendering differences between device types are significant enough to affect how applications are designed.

There have been several attempts to create a common operating system or platform that will run on several devices. In the PDA market, vendors such as Microsoft and Palm have achieved this by providing detailed requirements regarding the behavior of the devices. However, J2ME, BREW, WML, and HDML were all intended to run on a wide variety of devices. Companies like Openwave and Sun do not dictate how the device is designed, but instead work with the device manufacturer to make the best compromises.

One example compromise is the Back button. Openwave simulators have separate buttons for Back and CLR. It is a rare phone that devotes two buttons to these similar controls, due to styling, branding, cost, size, and layout issues. The compromise is to map the Back button onto the CLR button, and then determine what to do when the cursor is in an input field.

As a result of these compromises, the multiple-device platforms are rendered with a wide array of different implementations. Some rendering differences between devices are significant enough that an application that works well on one device will work poorly on another device.

There are at least four common approaches to developing for the myriad rendering methods on a particular platform:

• Target a single device - By picking one, or a small number of devices, developers can readily write an application that delivers an outstanding user experience. The drawback is, of course, that the application will not run well, or at all, on other devices. The drawbacks are important enough that this approach is relegated to situations where the developer can constrain the device choice of the users, such as some corporate applications and games.
• Develop an application that is "good enough" for all devices - By assessing all devices' implementation of the platform, and selecting the subset that works effectively the same all devices, developers can write only one application. Here the obvious drawback is that finding a common ground between all devices may be impossible, and will certainly result in a severely limited application that does not meet all the user's needs.
• Use a "run anywhere" server to automatically render code targeted to each device - This approach is a promising one, and can be quite expensive. Essentially, the developer writes in a proprietary XML language, and the server translates into the appropriate language and appropriate format. Unfortunately, most implementations use a subset of possible language elements, with the result that although the device display is targeted, the navigational features are generic and suboptimal. Further, writing one navigational scheme to target scroll-and-select, stylus, and voice devices will result in awkward navigation on at least two classes of device. One promising approach is class-based development (write once per class, and then let the server target it to a device within the class).
• Develop in-house automatic transformations for common user interface objects - This approach is substantially the same as the one above, except that the developers have more control over rendering and device optimization, but likely fewer resources to keep up with device explosion. Many developers have created a "menu" object and translators that determine whether to use select lists or links to render it.

As the number of device and device classes continues to increase, we believe the majority of developers will select some form of run-anywhere solution during development. We have targeted this guide to support simultaneous development.

[edit] XHTML-MP/WML2 Rendering Issues

When this document was written, there was little information available about how different browsers would render different tags. The following information was based on documentation provided by Nokia and Openwave before devices were developed; this information can be used as a prediction for ways other browsers may render information.

The biggest issue with WML2 is the WML namespace. The WAP Forum has decided that as long as a device can handle a WML1.x file, it is not necessary to use the WML namespace, including all of its navigation support, in XHTML files. Expect Nokia and DoCoMo devices to not allow the WML namespace, which means other devices will follow.

Expect this information to change as devices become available.

Issue	Nokia	Openwave
Anchor title	Not rendered	Softkey label
Accesskey	Not displayed	Displayed to left of link or control
Taborder	Not implemented	Controls highlight order
Various Presentation elements (big, b, hr, small)	Not displayed	Displayed appropriately
Elements like th, abbr, acronym, div	Distinguished from normal text	Same as normal text
Element	Not rendered	Line break
Fieldsets	Not rendered	Displays horizontal line before and after
Optgroups	Not implemented	Implemented
Table header	Bold and centered	Bold and centered
Element hr	Rendered but does not validate against the DTD	Horizontal rule

[edit] CSS

When this document was written, there was little information available about how different browsers would render style sheet properties. Some CSS properties are optional and may not be initially supported by devices. Expect this information to change as devices become available.

The following properties may or may not be implemented on a device in CSS-MP:

Property Name	Value or Data Type
'border-width'	Length (e.g., "em", "ex", or "px")
'border-style'	Keyword values: "hidden", "dotted", "dashed", "double", "groove", "ridge", "inset", and "outset"
Background image position	Percentage or length (e.g., "em", "ex", or "px") values
'font-size'	Percentage or length (e.g., "em", "ex", or "px") values
'font-family'	Specific font name value
'text-align'	Keyword value: "justify"
'text-decoration'	Keyword values: "underline" and "blink"
'visibility'	Keyword value: "collapse"
'font-family'	Specific font name value

XHTML-MP supports these WAP extensions:

• -wap-marquee-style
• -wap-marquee-loop
• -wap-marquee-dir
• -wap-marquee-speed

The following pseudoclasses are optional in WAP CSS, but must be supported to comply with CSS Mobile profile guidelines.

• Dynamic pseudoclass :active
• Dynamic pseudoclass :focus
• Link pseudoclass :visited

Avoid using optional CSS properties.Properties identified as optional in the WAP CSS guidelines may not be supported by user agents or may be supported inconsistently. Support of optional CSS properties is not mandatory for many device manufacturers.	XHTML-MP WML2
Avoid using shorthand for the CSS properties: "margin", "padding", "border-width", "border-style", and "list-style".They are optional CSS properties. Some may be used, but only when declared in a certain manner.	XHTML-MP WML2
Use shorthand notation for the CSS properties "font" and "background" with caution. While both properties are supported by WAP CSS compliant user agents, the shorthand notion must adhere to very specific requirements. See the WAP CSS Specification for more details.	XHTML-MP WML2
Ensure page content is readable without CSS. Devices that don't support CSS need to render content reasonably for users.	XHTML-MP WML2

[edit] J2ME MIDP Rendering Issues

Sun created the Mobile Information Device Profile with the understanding that mobile information devices have a wide array of user interfaces, and they could not rely on a specific set of controls being available. At the time this document was written, there were few J2ME devices on the market, so it is not yet possible to provide detailed comparisons between devices. However, we are already aware of some implementation differences among devices.

• Display of abstract commands - This is likely the most important type of rendering difference, as abstract commands are a major method users have to interact with the application. Known issues include:
  1. Display of "highest" priority commands - Sun's MIDP implementation for Palm OS renders the first few commands as buttons. Most phone implementations will render one or two commands as a softkey, generally selecting a command type Item as the "primary" softkey, even if that is not the highest priority command.
  2. Location of other commands - Sun's MIDP Palm implementation puts these commands in the menu structure. Unfortunately, many users never find the menu structure (which is accessed by tapping the soft button just under Home). Phones generally will label one softkey as "Menu" and display an implicit list containing all remaining commands.
  3. Sequence of commands - Some devices sort by type (e.g., all Item commands together), others will sort by priority (i.e., all commands of priority 1 first). Thus in some cases "Reply" will be right next to "Reply All" (both commands of the same type and one step different in priority), and in other cases they won't (perhaps an Exit or Screen command will intervene).
  4. "Hidden" commands- Some devices have hardware buttons for functions like back, exit, and help. These devices will take the highest priority commands of those three types and map them to the hardware buttons and may or may not show the equivalent on the screen.
  5. Grouping of commands - Some devices will render commands as a single list, but Sun's Palm implementation will group Screen and Item commands under the Actions menu, Help commands under the Options menu, and the remainder under the Go menu.
• Layout of forms - Each implementation has different methods for creating forms. Issues include:
  1. Display of labels - In some implementations, labels are displayed right-aligned, in bold. In others, they are left-aligned and their items may or may not be next to them.
  2. Line breaks - Some devices will insert line breaks between the label and its item.
  3. White space - Devices may or may not respect white space added by the application developer.