Design Recommendations

From MobileDesign

1 THE MOBILE ENVIRONMENT

[edit] THE MOBILE ENVIRONMENT

Before you start designing a wireless application, the first thing to understand is the mobile environment. Obviously, this environment is not the same as the desktop computer environment. But what design implications stem from this difference? We'll address the most important issues, starting with the user.

[edit] Users

Mobile users are mostly average consumers, typically in the early majority but not innovators. Unless you are creating an application for a selective audience, it is best to assume that users won't want to try things out and won't have patience for an unusable site simply because it is high-technology or because it provides a rare or unique service.

When users are using a mobile application, they have different needs than when they are using the desktop application. Examples include:

Usage context may change several times, as the user changes from driving to walking to sitting in a meeting.
Interruptions in the stream of usage may be frequent. Usage in general may be sporadic, particularly with the advantage of packet data.
The presence or absence of other people influence what the user is willing to do at any given time. Many people feel uncomfortable talking to their device in a public space.
The input characteristics of a mobile device are more limited than those of a desktop computer. Thus users will be less willing to enter character data.
The user may switch from device to device, but use the same application.
Compared to desktop computers, display characteristics of mobile devices are generally more limited than those of desktop computers. Further, the user may not be able to look at the display in some situations (like driving).
The user is more likely to have real-world distractions, like walking, dealing with clerks, or driving.
Mobile devices are frequently single-task devices, so application interruptions may not be readily resumed, if the user gets distracted.
For most types of applications, the user will use the device for only a few seconds or minutes at a time. Exceptions include interactive games.

Another consideration of your users is whether they may or may not be familiar with your desktop application. Some may have experience with your desktop application; some won't. Mobile sites that allow new users to sign up shouldn't presume familiarity with the site, its features, its menu structure, or its jargon. Even if users must be pre-registered to use your application, considering adding an unrestricted section to support curious non-registered users. It might get you a few new users.

[edit] Devices

Mobile devices have smaller displays, more restricted input capabilities, and more limited memory than desktop devices. They also have a wider variety of forms, including phones, PDAs, and game devices. Each device has different characteristics.

[edit] Phones

For the purposes of this guide, we define a "phone" as a member of a class of devices with the following features:

Small device. Phones are intended for carrying all the time: on the belt, in the pocket, or in the purse. Ease of portability is one of the key driving factors.
Constant companion' Most users will carry their mobile phone with them at all times. It is a personal device that is part of their identity.
Small screen. This naturally arises from "small device", at least until technology allows us to effectively put a large display in a small form. The screen will hold 14-25 characters wide (in a normal sized font) and 4-10 lines of text.
Scroll-and-select input with DTMF keypad. The line between phone and PDA is pretty blurry, but scroll-and-select (as opposed to stylus/touch) input is pretty clear.
Optimized for voice. Most PDAs are optimized for viewing data. Phones are optimized for making and receiving voice calls.
Low memory and processor speed. They get faster and more powerful every year, but just like with desktop computers, it's never enough!
Single-device operating system. Although operating systems like Symbian can run on a phone, most phones running such high-end operating systems are a lot closer to the definition of PDA than of phone. Most device manufacturers have their own unique phone software.
Non-upgradeable. Once in the field, phones are very rarely upgraded. Although this rule has many downsides, at least developers can make assumptions about a phone's software based on the model.

Since users do not upgrade to the latest browser, you can make assumptions about a phone's capabilities based on the platform you are developing for.

[edit] Personal Data Assistants

The line between a phone and a PDA is constantly blurring. Phones with application-display characteristics have at least some phone number storage, and many PDAs now come with telephone capability. However, we can usefully consider a PDA as having the following characteristics:

• Larger screen (160 x 160 up to 1/4 VGA). Screen may be square, tall, or wide. • Stylus or full keyboard input. While not having the input capabilities of a computer, a PDA has significantly more input capabilities than a phone. • Existence of other applications on the device. Users will want to interact with them and sometimes share data between them. • Data connectivity other than wireless networking. Most PDAs can synchronize to a computer using a cable. Many can use external modems and dial up directly or via 802.11. • Cross-device operating system. PDA applications need to follow the rules of the operating system they run on, as the OS is a large part of the reason why the user selected the device in the first place. PocketPC owners will be unhappy with an application that looks and acts like a Palm; Palm owners will likewise be unhappy with an application that is targeted to PocketPC. • Device specifications directed or constrained by the operating system. PDAs have some predictable characteristics because they have to qualify to be a "PocketPC" or "Palm" device, and developers can use the OS characteristics as base assumptions for device characteristics.

[edit] J2ME MIDP Devices

Sun has specified a minimum set of characteristics that all MIDP devices must have:

• Display - 96 x 54 pixels, 1-bit color, approximately 1:1 pixel height:width ratio • Input - phone keypad, 2-handed (usually QWERTY) keyboard, or touch screen • Memory - 128kb for MIDP, 8kb for application data, 32kb volatile memory for runtime • Connectivity - two-way, wireless, intermittent, limited bandwidth

[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. Implementation issues include:

• 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; please see the Layout section on page 79 for details. 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.

[edit] Writing for Multiple Devices

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.

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 was intended to run on a wide variety of devices. Sun does not dictate how the device is designed, but instead works with the device manufacturer to make the best compromises.

One example compromise is the Back button. A small number of devices have separate buttons for Back and CLR. However, 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, MIDP is 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] (old) Platforms

A platform, for the purposes of this guide, is a development environment. Some platforms are device operating systems, some are markup languages, and some are cross-platform application environments. This section gives an overview of the platforms covered in this guide.

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.

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, XHTML, WML, and HDML were all intended to run on a wide variety of devices. Companies like Openwave 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.

[edit] HDML and WML 1.x

Wireless Markup Language (WML) is the application language specified by the WAP Forum. HDML is, in many ways, the predecessor to WML. Although the appearance and coding of these two languages is similar, WML has some features that HDML does not; HDML has other features that WML does not. To ensure that WML would not be a step back from HDML, Openwave added several WML extensions that match or expand on HDML features.

In this document, we refer to “Openwave” and “Nokia” when discussing WML rendering. Obviously there are other browsers, but most of them render similarly to Nokia. The difference between Openwave and Nokia is large. Note that Openwave provides browsers to a wide variety of device manufacturers.

WML comes in a variety of forms, and you must understand which ones are right for you and your potential audience. Among the things that preclude a single WML standard are:

• Gateways and Browsers. Different combinations of gateways and browsers from different manufacturers can significantly affect a WML application.

• Extensions. Designed to bridge the gap between HDML 3.0 and WML 1.1. Openwave Extensions offer additional functionality for applications running on Openwave gateways and Openwave browsers.

• Future Versions of WML. Because there is yet no practical means to upgrade phones in the field, changes to the WML standard over time will only widen the variety of applications in the field.

• WML Script. WML Script can improve an application. But it can't be translated to work with older HDML browsers. • HDML Browsers. Developers seeking a large audience must not ignore the existence of the millions of HDML browsers in the field.

• Browser User Interfaces. Openwave browsers and the Nokia browser have inherently different user interfaces (e.g., Openwave uses two softkeys, Nokia uses one). Regardless of the language used, it is nearly impossible to design a single application that is compatible with both the Nokia and the Openwave user interfaces without sacrificing usability. As shown in the table below, the only path toward good usability on both browsers is to offer two applications: one targeted to the Openwave browser, the other targeted to the Nokia 7110.

(review table creation)WML 1.1 designed generically WML 1.1 targeted to the user interface of the Openwave 4.x (WML) browser WML 1.1 targeted to the user interface of the Nokia 7110 browser Potential Usability on Openwave WML Browsers Poor Best Very Poor Potential Usability on Nokia 7110 WML Browsers Poor Very Poor Best

Targeting WML to different browser user interfaces

The following recommendation applies to WML.

- WML applications intended for use with Openwave 4.X WML browsers should be optimized for the user interface of the Openwave 4.X WML browsers. In other words, don't present a Nokia-optimized application to the user of a Openwave browser. This is perhaps the most important thing you can do to ensure a positive user experience for your customers!

As of the time of creation of this document, no mobile device fully supports WML 1.1 as defined by the WAP Forum. Every phone (to date) recognizes a subset of WML 1.1 and ignores tags outside that subset. Different devices support different subsets. Some devices support non-standard tags; these "extra" tags are called extensions. To further the problem, the rendering of even the commonly supported tags varies from device to device. Because the devices to which WML is applied do not consistently and completely support WML 1.1 (as defined by the WAP Forum), we say that in practice there is no such thing as "standard WML."

A "functionally generic" WML application ensures compatibility with a target set of WAP devices by avoiding use of WML tags not supported by one or more of those devices. The figure below illustrates the problem with this technique. If one avoids tags not shared by all targeted browsers, then the set of available commands shrinks. The more devices targeted, the smaller the command set becomes. Not only does omitting commands limit your ability to create an application, it also prevents you from offering advanced functionality supported by certain browsers. In short, using functionally generic WML can prevent you from delivering the best possible application for your users. We do not claim that it is impossible to build a good application with functionally generic WML. In fact, you may find that "functionally generic" WML is the perfect solution for your application. Rather, we present these issues as support for our belief that rendering browser-specific applications is the best means to achieve a positive user experience.

(an Illustration of the concept of "functionally Generic" ... goes here)

For details on how Openwave and Nokia render WML differently, please see the WML Rendering Appendix.

The following recommendations apply to HDML and WML.

• WML applications intended for delivery to web browsers on other platforms (including HDML browsers) must not cause errors in the Openwave HDML browser versions 3.0, 3.1, or 3.2. There are several WML tags that do not translate to the HDML 3.0 language. It is assumed that WML applications that do not cause errors in the 3.0 browsers will also not cause errors in the 3.1 or 3.2 browsers. - Take advantage of the usability enhancements afforded by Openwave extensions (WML+). To be clear, this is a request to enhance usability and not necessarily a recommendation to use the Openwave extensions. After all, Openwave extensions have no value for browsers and gateways other than Openwave. Openwave's extensions are one way to reproduce in WML some of the features of HDML that can enhance usability. We expect that advanced developers will be able to reproduce the functionality of the Openwave extensions using "work-arounds" built with standard WML. Note that Openwave extensions should be used only for applications that will be delivered to Openwave WML browsers via an Openwave gateway. This recommendation also applies to Openwave.

Applications intended for delivery to Openwave 3.0, 3.1, or 3.2 browsers should be authored in HDML 3.0. Use of HDML 2.0 is not recommended under any conditions.

WML applications should be authored in WML 1.1.

[edit] XHTML Basic, XHTML MP, and WML2

If you're anything like us, trying to understand the relationship between XTHML Basic, XHTML Mobile Profile, and WML2 was a little difficult. XHTML is an XML recasting of HTML. The W3C then modularized XHTML. The group of simple modules (basic text, basic forms, basic tables, hypertext, images, and meta information) was defined as being XHTML Basic.

The WAP Forum wanted to merge the capabilities of DoCoMo's iMode, XHTML Basic, and WML 1.x. They therefore added a few XHTML elements to XHTML Basic and called the resulting language XHTML Mobile Profile. In addition to a few attributes, the elements added are:

• acronym • address • br • b • big • hr • i • small • dl • fieldset • optgroup

Thus XHTML Basic is a subset of XHTML Mobile Profile, with the exception of the pre and noscript elements and the align attribute of caption and table.

The WAP Forum also wanted to allow for backward compatibility with WML 1.x, and many of the WML 1.x tags could not be found anywhere in XHTML. They therefore created a WML namespace that allowed these elements and attributes to continue working. To give browser manufacturers ultimate flexibility, they decreed that a device might be WAP 2 compliant in one of two ways: either allow the WML namespace, or have a second browser on the device that reads WML 1.x, without allowing a page to have both types of elements. Many browser manufacturers chose the second option, so the WML namespace is not likely to be widely used.

WML 1.x contained several tags that aided in navigation. These tags are not in any version of HTML, and indeed had more in common with some programming languages. One available action, <prev>, is in several "mobilized" versions of HTML, including that of AvantGo and Handspring Blazer. Others are used to manipulate the cache or ensure that a screen with dynamic data has all the necessary tags. In WML2, these tags and attributes are the "wml namespace". If you are unfamiliar with XML, that essentially means that you have to put "wml:" in front of each of them.

This history is represented in the figure below.

(diagram that ends in XTHTML. mobile goes here)

There are some new features in XHTML Basic that were not in iMode or WML1.x, the most notable of which is style sheets (CSS). Previous phones and devices had little control over graphics, color, and layout, so previous platforms did not attempt to manipulate these things. As hardware has advanced, certain things like font control and layout became possible and desirable. Thus WAP Cascading Style Sheets (WCSS) was created.

The following recommendations apply to XHTML Basic, XHTML MP and WML.

• Use the WAP DTD <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML MOBILE 1.0//EN" "xhtmlmobile10.dtd">. This allows you to take advantage of WAP extensions and additional XHTML MP elements. • Use the W3C DTD <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">. This DTD gives access to all the XHTML Basic tags, but no WML elements and no styling elements such as b, hr, i, small, or acronym. • Ensure your code is valid. The XHTML Basic validator is found at http://validator.w3.org/. • Use the Openwave DTD <!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/DTD/xhtml-mobile10.dtd"> when targeting Openwave browsers. This allows you to take advantages of Openwave modules, including the WAP extensions, text entry formatting, and icons. It also allows you to use some deprecated attributes to style your code, but you should use stylesheets instead. This recommendation also applies to Openwave and other platforms.

[edit] Rendering Issues

[edit] XHTML Basic, XHTML-MP, and 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. Almost every browser is implemented without the WML namespace. (graphic goes here)

The relationship between XHTML Basic, XHTML-MP, and WML2 is not clear, since XHTML-MP is built on top of XHTML Basic. The approximate relationship between the languages is shown in the illustration. (graphic goes here)

(look up tables)Issue Nokia Openwave Anchor title Not rendered Softkey label Taborder Not implemented Controls highlight order 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

Rendered but does not validate against the DTD Horizontal rule

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

[edit] Softkeys

Softkeys in XHTML browsers don't work the same as in Openwave HDML and WML browsers. In an HDML or WML 1.x browser, the softkeys are (more or less) independently programmable, such that each can perform a different action. Those actions can vary depending on the cursor position. The user selects his actions by selecting the desired softkey. Navigate, act, navigate, act, et cetera. When browsing an XHTML site, there's really only one softkey, and it acts just like a mouse click on the highlighted element. The user selects his action by navigating to the representative element, then selects it by pressing the one softkey. Navigate, select, navigate, select, et cetera. While the device may display a second softkey, it is used to access a browser menu.

Here's another way to think about the softkeys. In a HDML or WML browser, card elements are typically the subjects to the softkey's action (e.g., to erase an email; the element = the email, the softkey = erase). In an XHTML browser, selectable elements are typically the actions themselves; pressing the softkey merely initiates them (e.g., to erase an email; the element = a command to erase the email, softkey = select the element).

Softkey Labels. In a HDML or WML browser, softkeys can be programmed not only in functionality but also in appearance. By assigning a custom label, a developer could convey the action of a softkey. For example, to reply to an email, the user would press the softkey labeled "Reply." Simple enough. But in XHTML, not all browsers support dynamic softkey labels -- yet.

Eventually, we expect that all wireless devices will support dynamic softkey labels, the first N (usually 6) characters of the title attribute of a selectable element when that element is in (navigational) focus. If an element's title attribute is missing or otherwise inappropriate for use as a softkey label, then use "OK" as the label.

While not all browsers will behave as described above, developers are encouraged to encode title attributes with the expectation that they will appear as softkey labels on some browsers. The effect will be similar to "Tool Tips" as seen in Windows. The softkey text should be helpful, and the page should be designed with the assumption that the text may never be seen. And, as always, the softkey text should be short enough to fit.

Softkey Support for WML 1.X. In a WML 1.x application, the developer may define some number of options (do type = option). To support these options, browsers supported at least one secondary softkey (some had more). Singular options would appear as the sole secondary softkey. Multiple options usually appeared in a sub-menu, accessible via the secondary softkey which was automatically labeled "Menu."

Because only one softkey (select) is used with XHTML and because XHTML is the primary language for our new browsers, not all browsers will dedicate a softkey to the display of WML options. Thus, even when a WML application contains only one option, it may be nested in a pop-up or sub-menu on certain browsers.

New and Improved? This new softkey paradigm may seem like an oversimplification, but it's necessary to achieve device independence. The softkey paradigm in older browsers assumes a disassociation between navigation and selection; a point-then-select interface. But the older assumption is invalid on some devices because they use a different interface. When using a touch screen with a stylus, for example, navigation and selection are performed together -- it is a select-by-pointing interface. One cannot read a softkey label while selecting an item with a stylus. (end old)

[edit] Carriers

Carriers have historically played an important role in mobile application design. They play a crucial role in determining which devices have access to their network, which applications are immediately visible to the user, and which connection technologies are used. In addition, different carriers have different roles in determining the characteristics of devices. Japanese carriers have historically provided the device manufacturers with specifications for phones; U.S. carriers may provide requirements to device manufacturers, resulting in a more consistent product line.

Carriers may also provide gateways, application servers, and branded content for its subscribers. Gateways have a variety of features, most notably:

• May control billing for your application • Controls application distribution • May specify MIDP extensions • May restrict network access

(old) • May store bookmarks • May store cookies • May convert between languages (such as HDML to WML, or WML to XHTML MP) • Convert wireless requests (such as HDTP or WAP) to HTTP for transmission to the internet • May convert image types (such as GIF to PNG) • May convert image size • May control billing for your application • May specify language extensions • Controls application distribution • May restrict network access (end old)

[edit] A Note about Emulators

Emulators are crucial tools in application development. They do a very good job of giving the developer an idea of how the application will feel to the user, and allow the developer to do unit testing. Unfortunately, these tools must not be used as the exclusive means for testing the application for either functionality or usability.

There are a variety of known differences between most simulators and the devices that they simulate. Device manufacturers make a large number of implementation decisions to put J2ME onto a specific device with specific input/output characteristics and specific user expectations. For any given device, there may be hundreds of these decisions. There are even likely to be slight differences in the emulator for a device and the actual implementation.

Usability testing using emulators, while less expensive than testing using real devices, is also fraught with problems:

1. For the reasons discussed above, the presentation of your application will not match the real presentation. 2. Normal device usage involves holding the device at a comfortable angle, and even gesturing with it. The unnatural use of a computer will cause your test to miss nuances in user interaction. 3. The speed of transmission and rendering on the computer is faster than on the mobile device. 4. Dropped calls and dropped packets do not happen on the computer. 5. User input is different on the computer. Typing will be easier, unless you restrict the user to using the mouse (in which case it will be harder). 6. User context is different. Sitting at a desktop computer is a fairly formal experience. Sitting on a sofa using a device is an informal experience. Users will behave differently.

Usability testing with an actual mobile device using standard video capture technologies is difficult, because the camera can not have a fixed focus on the device. Fortunately, manufacturers of usability testing equipment have developed a cradle to hold the device with a very lightweight camera mounted to the cradle. This ensures that the user's actions are recorded. Use emulators for experimentation, not design validation.

[edit] (old) A Note about Simulators and Emulators

Simulators (which duplicate the experience of the device on the desktop) and emulators (which use the same code as what runs on the device recompiled for the desktop) are crucial tools in application development. They do a very good job of giving the developer an idea of how the application will feel to the user, and allow the developer to do unit testing. Unfortunately, these tools must not be used as the exclusive means for testing the application for either functionality or usability.

There are a variety of known differences between most simulators and the devices that they simulate. For example, an Openwave HDML simulator will work just fine without a "public=true" attribute, but the device will not find the application at all. Further, device manufacturers make a large number of implementation decisions to put a standard platform (XHTML Basic, HDML, WML, etc.) onto a specific device with specific input/output characteristics and specific user expectations. For any given device, there may be hundreds of these decisions. There will therefore be slight differences in the "standard" simulator for a platform and the actual implementation.

Usability testing using simulators, while less expensive than testing using real devices, is also fraught with problems: 1. For the reasons discussed above, the presentation of your application will not match the real presentation. 2. Normal device usage involves holding the device at a comfortable angle, and even gesturing with it. The unnatural use of a computer will cause your test to miss nuances in user interaction. 3. The speed of transmission and rendering on the computer is faster than on the mobile device. 4. Dropped calls and dropped packets do not happen on the computer. 5. User input is different on the computer. Typing will be easier, unless you restrict the user to using the mouse (in which case it will be harder). 6. User context is different. Sitting at a desktop computer is a fairly formal experience. Sitting on a sofa using a device is an informal experience. Users will behave differently.

The following recommendation applies to all situations.

• Use emulators for experimentation, not verification. We recommend using the Openwave emulator as a tool for experimenting with different application designs and as a platform for usability testing. All known emulators are incapable of identifying all flaws that could compromise your application. (end old)

Mobile Application Design

Retrieved from "http://patterns.design4mobile.mobi/index.php/Design_Recommendations"