Mobile Application Design

From MobileDesign

Contents 1 MOBILE APPLICATION DESIGN 1.1 Creativity vs. Consistency 1.2 (old) Page Size 1.3 Mobilizing a Desktop Application 1.4 Navigation 1.5 Application Structure 1.6 Navigational Controls 1.7 (old)Contexts and Subroutines 1.8 Backward Navigation 1.9 Security and State Management 1.9.1 (old)( Security, Cookies, and State Management 1.9.2 Passwords 1.9.3 Alerts 1.10 Performance Management 1.11 (old) Cache and Performance Management 1.12 Voice Calls 1.13 Location Services 1.14 Messaging and Push Services 1.15 PIM Data (from JSR 75) 1.16 Miscellany

[edit] MOBILE APPLICATION DESIGN

This chapter, in combination with the chapter on Design Patterns (page ), concerns the overall design of your application. All Screens (page ) concerns the design of individual screens.

The practice of application design involves planning feature sets, designing navigation techniques, organizing the menu structure, mapping navigational subroutines, planning data flow, creating distributed data models, managing cache, and selecting screens and other modules. This activity is best paired with the system architecture phase of software development. Most decisions regarding specific screen layout can be deferred.

With few exceptions, the display unit of an application is a page. This is what the user sees, how navigation is managed, and how history and cache are managed.

(old) WML 1.x, and its predecessor language HDML, use screens (in the languages' parlance, "cards") as display and navigation units, but manage downloading and cache using a small collection of cards called a "deck". Applications can largely be designed based on screens, but care should be taken to manage decks as well.(endold)

[edit] Creativity vs. Consistency

It's likely that one of the goals of your application has something to do with getting people to use it. Or maybe your goals are achievable only when many people use the application. What's not likely is that your goal is to get fewer people to use your application. Or to confuse your users. So why should you care about these guidelines? To meet your goals.

You must accept the fact that most users have used - and become comfortable with - numerous other applications before using yours. Those other applications may seem irrelevant or unimpressive to you, but you cannot ignore the fact that users are more likely to use your application if the techniques they've learned in other applications also work for yours. If most applications zig and your application zags, then it's likely you just zagged away from potential customers. Thus, consistency with a standard - this standard, preferably - helps improve usage, return usage, and customer satisfaction, and may attract new users.

To many developers, seeking consistency seems boring, uninspiring, and too simple. In some cases, developers resist stylistic guidelines because they are convinced that the guidelines are sub-optimal, irrelevant, or even wrong. These perspectives are understandable. Certainly, no set of standards is perfect or applies perfectly to everyone. Nonetheless, the value of consistency for the user cannot be overstated.

Consider, for example, the position of a turn signal stalk on a rental car. Traditionally mounted left of the steering wheel, the turn signal stalk is easy to use if for no other reason than its consistency of placement. If we ignore driver experience, we may find that a different position is superior. But the reality is that every driver's experience tells him to look for the turn signal on the left. If you were to rent or sell cars that violate this expectation, you would frustrate, annoy, and perhaps endanger many of your customers. Such is the case with ubiquitous user interface elements. And so these guidelines are very much like asking an automaker to keep his turn signals on the left.

Demanding consistency is not intended to stifle creativity. We too crave diversity and creativity. But too often creativity comes at the expense of usability, and this seems to benefit no one. Note that this discussion does not apply to games. When a developer is creating a game, learning the user interface is usually part of the experience, part of the skill involved in playing a game. As such, the need for consistency is usually much lower for games. − Use an ordinary user interface as a means to access extraordinary content.

[edit] (old) Page Size

Studies have shown that on desktop computers, large numbers of users abandon a page that takes more than 10 seconds to load. Thus web pages should contain less than 9 seconds worth of size (the extra time allocated for network traffic). As connection speeds have increased, 9 seconds can contain a lot more information, presuming that the site can afford to make slower-connection users wait longer.

As a general rule, the best consumer land-line connections are approximately an order of magnitude faster than the best consumer wireless connections. Further, many wireless users will have to pay for connection time or number of bytes transferred.

The following recommendation applies to all situations.

Minimize the number of bytes transferred. Users will abandon sites or applications that cost them a lot of time or money, especially on devices that can only do one process at a time. On devices with limited memory, large pages in the cache will force other information out of the cache. The following recommendation applies to XHTML Basic.

Keep page size below 10KB. Some devices will not cache anything larger. On a few devices, a page larger than 11KB will generate an error.

Decks contain one or more cards (screens), and are treated in cache as a single unit. The history, however, treats cards as separate entities. As such, recommendations regarding sizes apply to decks. The following recommendations apply to HDML and WML.

Deck size must not exceed 1492 bytes. Deck size must not exceed 1300 bytes on the Sanyo SCP 4000. This is an absolute limit. Exceeding this limit will yield an ungraceful error. Note that long URLs will significantly contribute to your deck size. Note that deck size may be affected by translation at the UP.Link server.

Deck size should not exceed 1200 bytes. This will yield a reasonable download time and create a buffer to help prevent packets that are too large. An ideal deck size is less than 800 bytes. Openwave recommends a 500-byte maximum.

Cards within a deck should be tightly coupled. Since all cards in a deck will be removed from the cache at the same time, the cards should be a "unit." For example, couple a card and its associated action menu. (endold)

[edit] Mobilizing a Desktop Application

The process of coding a mobile application is quite similar to the process of coding a desktop application. The language used is similar, and in some cases the same. The business processes are the same. The back end systems are the same. However, this does not mean that the mobile application should be designed as a smaller version of the desktop application.

− Do not make your mobile application a technology-limited version of your desktop application. Limit your application to the tasks most frequently attempted by your mobile users. Design your application around the constraints of mobile devices. Be conscious of your audience. − Optimize the design around the 20% of the functionality that will meet 80% of the users' needs (80/20 rule). If additional functionality can be added without compromising usability, add it cautiously. − Applications should be easy to learn and use. Users will not spend time reading user manuals or help pages. − Test your application on as many devices as possible. This remains the most reliable method for determining device compatibility. − Minimize the number of bytes transferred. Users will abandon applications that cost them a lot of time or money, especially on devices that can only do one process at a time.

[edit] Navigation

Generally, navigation design is the arrangement of information on the application (information architecture) combined with on-screen methods of getting from one part of the application to another.

On most devices, 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. 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).

− Make the site consistent. Your site should be consistent in terminology (especially softkey labels), organization (e.g., ordering of options in select lists), and user interface elements (e.g., use of wizards and forms). − Accommodate or, if possible, prevent user errors. Anticipate errors that your users might make. Then perform usability testing to discover errors that you haven't anticipated. Avoid text entry. When possible, design your site to prevent errors (for example, don't allow the user to enter alphabetic text when you need a numeric value). When you can't prevent errors, provide meaningful, intuitive error messages with clear, concise options. − Provide access to your main screen from key screens throughout the application. Good candidates for main screen links include end-of-task screens and subdirectory screens. − Provide customer support or contact information. If users have to guess who to contact, they will generally guess wrong.

(old) Generally, navigation design is the arrangement of information on the application (information architecture) combined with on-screen methods of getting from one part of the application to another.

Scrolling is better than fetching. Unfortunately, many developers mistakenly extend the aforementioned "simple and shallow" notion to conclude that each page should contain as little as possible. On the contrary, each page should contain as much relevant information as can fit within its capacity. For example, a menu with nine items (which is the comfortable limit for a list on a scroll-and-select device) is no more difficult to navigate than a select list with four or five items. And a long screen that requires scrolling can be as easy to navigate as the same amount of information split into two screens. Don't include more information than the user needs, but take advantage of both the vertical and horizontal range of each page to display your information in as few screens as possible. Users will quickly learn how to scroll and that scrolling is necessary, so don't avoid scrolling at the cost of adding fetches.

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. 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).

The following recommendations apply to all situations.

Make the site consistent. Your site should be consistent in terminology (especially softkey labels), organization (e.g., ordering of options in select lists), and user interface elements (e.g., use of wizards and forms).

Accommodate or, if possible, prevent user errors. Anticipate errors that your users might make. Then perform usability testing to discover errors that you haven't anticipated. Avoid text entry. When possible, design your site to prevent errors (for example, don't allow the user to enter alphabetic text when you need a numeric value). When you can't prevent errors, provide meaningful, intuitive error messages with clear, concise options.

Provide a link to your home page from key pages throughout the site. Good pages for home page links include end-of-task pages and subdirectory pages.

Provide a link to your customer support or contact information from the home or contact us page. If users have to guess who to contact, they will generally guess wrong. (endold)

[edit] Application Structure

An application map posted on the wall of your lab is helpful for you but useless to your users, who will never see your application as a whole. The limited display capability of mobile devices makes it very easy to be confused as to what page is being displayed and where that page fits within the application. In the mobile environment, a user's attention is frequently diverted elsewhere. Only the simplest application structure is likely to be comprehended and remembered once the user puts the device down or is interrupted.

_ Define a main screen for your application. This gives users an understandable starting point. − Target the main view at the user, not at the general public. Give the user personal information without having to navigate or sign in. Only use the generic view when the user is unknown. − Make the application structure simple and shallow. Do not build submenus of submenus of submenus, et cetera. − Don't make the application structure convoluted. A simple tree structure is better than a structure with lots of cross branches (cross branches are links to site components that are not on the same menu path).

Navigation models are the method that the user can use to get around the application, by way of commands, backward navigation, menus, and data input. - Keep the navigation model consistent throughout the application. Every screen does not have to have a link to every other screen, but the user has to be able to predict how to get to other screens. An effective way of accomplishing this is to have navigation to all parts of the application from the main screen, and links to the main page from every, or most, screens in the application.

[edit] Navigational Controls

Navigation controls are very difficult to design correctly. Use caution when transferring any desktop navigation scheme to the mobile environment. Be sensitive to placement of focus on the screen. Be sensitive to the small size of the screen and the limited control capabilities. Be judicious with the number of navigation controls you provide.

- Only put links to major nodes "higher" in the tree. Putting a link to every major section will cause the application to be unnecessarily large, and cause the user to have to scroll through and process too many possible choices of action. However, ensure that there is a link to your main screen and any major decision points the user met along the way. − Avoid ambiguous references to "Search". When encountering an ambiguously labeled "Search" control, users will often misinterpret its meaning. To avoid potential confusion, add a descriptor to clarify the nature of your search engine. For example, if you are linking to a general web search engine, "Web Search" could help users avoid a potential pitfall. If you are Acme.com and you have a search engine just for your application, "Acme Search" or "Search Acme" would be better than just "Search."

(old)Put navigation links at bottom of screen. This way, the user does not have to scroll through them to see the content.

The following recommendation applies to XHTML Basic, PDAs, and HTML.

Use within-page links to give access to unseen parts of a large page. Do not do this on the smallest screens because such links ensure the user has to scroll past them. This reduces the need for scrolling. (endold)

In the desktop environment, each screen has navigational controls on the screen and perhaps in the menu structure. The small size of mobile devices makes navigation bars across the top or side of the screen impractical, and the need for focus on content makes navigation bars confuse and lose users.

(old) The following recommendation applies to XHTML Basic.

Use caution when transferring desktop navigation schemes to your mobile application. Navigation schemes that work well on the desktop, with a large, wide screen, a mouse, a full keyboard, and a windowing system may not work well on a small, narrow screen with a scrolling device or stylus used when the user is easily distracted.

Drop-down lists are successfully used for navigation from the desktop-based web, but they have several problems for mobile XHTML devices:

XHTML does not support 'onpick' or 'onselect' events, so users have to operate a button as well as the select list.

These lists introduce three clicks as overhead to selecting any item in the list, while obscuring the contents of the list.

Users do not look in these lists for navigation unless they can't find the information anywhere else (including following links).

Javascript, necessary for best design of drop-down menus, is not available on XHTML Basic devices.

The list adds visual clutter as well as something the user must scroll (click) over before getting to real content.

The following recommendation applies to XHTML Basic.

Avoid using drop-down lists for navigation. They're clumsy and the users don't use them. Only use drop-down lists for forms.

Another trick from desktop web design is the use of "breadcrumbs", to assist users in understanding where they are within the site and provide quick navigation to earlier, more general pages already visited. While this is very useful in a highly visual environment, it adds visual clutter and extra clicks in the mobile environment. Further, to avoid using the entire screen on context, you have to use images rather than words to refer to other pages, causing the entire page to load more slowly. Thus, The following recommendations apply to XHTML Basic.

Avoid breadcrumb navigation.

If breadcrumb navigation is used, place it at the bottom of the page and use text descriptions. This allows the user to use the page without having to scroll past several links first.

Consider putting a single link to the page's breadcrumb (history) list. Users will have the ability to answer the questions "Where am I?" and "Where have I been?" without using valuable real estate or requiring the user to scroll through a list only tangentially related to the screen's task. This recommendation also applies to WML, WML2, and HTML.

Provide context using color, branding, and titles. For example, a small (19x19 pixel) graphic can show the site's logo, the page's name can be to the right of the logo providing specific page details, and the color behind the pair of these can show the region of the site. Sports at your site could have one background color; news another.

Avoid tabs. This popular desktop technique requires multiple graphics (slowing download time), tables (slowing rendering time), visual clutter, and several user clicks to bypass. Further, the narrow devices don't lend themselves to a navigation mechanism that capitalizes on width.

Avoid redundant lists. If two menus have roughly 70% of the items in common, it's likely that users will either not notice the difference or not understand the difference. Keep menus as unique as possible, with exceptions for hard-to-categorize items and links common to every menu (but keep the number of common links extremely small!).

Avoid redundant navigation mechanisms. You don't have the space for them, it takes more time to download, and it will confuse the users.

Use caution with multiple navigation mechanisms. If some content is accessible through one mechanism and other content is accessible through a different mechanism, users may become confused.

Use caution with navigation schemes giving access to "sibling" pages (horizontal navigation). Most such schemes quickly cause the user to lose any understanding of the site's structure while adding visual clutter and confusion to the page. The only horizontal navigation we have seen successfully used is next/previous navigation, like in the Series Reader (p 94) . Avoid providing links to unrelated parts of your site. Rely instead on the user revisiting the home page or navigating backward.

If included, place navigational search functions at the bottom of the page. On desktop web sites, many users will go first to a search field to find a particular part of the site, while others will navigate as a personal preference. Unfortunately, on devices with difficult text entry, using a search field results in a much longer task completion time due to triple-tap, server traffic, and browsing results. Thus, if you include a navigational search (as opposed to product search) function on your site, put it near the bottom of the page. Users will have to scroll past the navigation to get to it, and are therefore more likely to use the navigation rather than the search function. Note: if you wish to support expert use of your search function, you can put an accesskey accelerator on it, allowing experts to quickly get to the search function.

Okay, we've recommended against a large number of navigation mechanisms. What's left? We design our sites using list navigation, just like we did for HDML and WML. This isn't because we lack imagination, it's because we want to ensure fast simple easy sites for our users.

[edit] (old)Contexts and Subroutines

This section applies to Openwave devices only.

Contexts, also known as activities (in HDML jargon) or subroutines, are used to help navigation. Proper use of contexts can subtly yet effectively improve site usability, but poorly implemented contexts can be confusing and lead to errors. Contexts should be used liberally, but not recklessly. Good use of contexts separates exceptional sites from mediocre sites.

Contexts must eventually be exited. Failure to properly exit a context may cause navigation problems that could be difficult to detect. Use exit or return to ensure that the history stack is maintained in a logical manner.

Use contexts liberally to aid navigation. Do not require the user to hit BACK many times. Please read the section regarding Navigation:Backward Navigation . Use a Cancel Guard (a.k.a. "Delete Shield"). Add a confirmation to cancel out of contexts if exiting the context will result in loss of user-entered data. See Cancel Guard for more information.

Use contexts for processes that will not need to be revisited. For example, once an order has been processed, it is undesirable to revisit those pages, as it is possible for the user to accidentally place a second order. If the order creation process is a separate context, the user will never accidentally visit the process. Also, the "Back" function will work as the user might expect -- it will take the user to the card that called the order process.

Contexts should not share a deck with a card outside the context. Since the history is maintained based on cards and the cache is maintained based on decks, a context that is not in a separate deck is less likely to be removed from the cache. Since the cache will have to save the larger deck, it will have less capacity for other decks.

Consider exiting an activity when: A user has just logged out (security breach otherwise), A transaction (e.g., purchase or sale) has just been completed, A message has just been sent, A message has just been read, The user has just been through a long series of cards (otherwise they'd have to navigate back through that long series to go back to a card that preceded the series), There's no reason for a user to go back to the place they just came from, The previously-viewed information is now obsolete (might also handle with TTL=0), or The just-viewed information has been deleted or is no longer available. (endold)

[edit] Backward Navigation

Backward navigation is crucial in mobile design. In the desktop environment, the fast connection and rich controls make backing through the application fairly simple. However, users still get lost and the standard practice is to always provide a link to the site's home page, as well as other major pages throughout the site. In the mobile environment, the user is more likely to use backward navigation, as the rich controls and displays are not available. The designer should therefore make backwards navigation as easy as possible.

Backward navigation is not only about the Back button. Some other considerations: − Define a BACK abstract command for every screen. − Only use the “Back” label if your control goes back precisely one screen. "Back" is such a well-understood function that everyone has very specific expectations of what it performs. If you wish to go back more than one screen, use a different label for your control, such as "Retry", "Start Over", "Main" or some other location-specific label. _ Do not allow users to back into a screen and view a password. Unlike markup languages, J2ME does not have a linear history stored, so developers must explicitly code any Back functions. This is not very important on PDAs, but most phone operating systems implement back as a "one step backward in the tree" function. Specifically, if a user is looking at the 62nd consecutive name details and then presses CLR or Back, the device goes to the list of names and not the 61st name. _ Implement a logical Back function on each screen. This will help ensure your application is consistent with other applications on the phone - including the browser. In most cases, back will mean one step higher in the application hierarchy or to the previous screen in a process. Maintain a history stack for complex applications. If you application has complex navigation in which the user may switch from module to module without completing a task, have Back reflect the user behavior and not application hierarchy. _ Do not back into an alert screen. Because alert screens do not have abstract commands, the user will not be able to back past the alert screen. (old) Nokia devices use the right softkey as either the Back button or the Clear button (when the input widget is displayed) while the browser is running. The following recommendation applies to Nokia WML devices. Define a <prev> task for every card. Without a <prev> task, the device will not show the back button at all, and the user will be unable to navigate backwards at all. Most devices and browsers provide built-in back buttons. Phones running Openwave browsers, for example, have a physical button mapped to back (usually the CLR button). Palm browsers provide Back as a control, just as desktop browsers do.

The most frequently used button on an HTML Web browser is the Back button. HTML pages are often littered with back hyperlinks. Clearly, users are more comfortable exploring the depths of a site as long as they can get back to where they started. Nokia browsers do not have Back buttons, but instead place the back function on a second softkey. For this reason, many developers find it tempting to fill their HDML and WML applications with Back softkeys or links. We strongly urge you to resist this temptation. Here's why:

• Users wishing to go back several steps will press a Back softkey several times. But because the softkey usually changes from card to card, they eventually activate a different softkey. Users won't know what happened when they encounter what seems like an error to them.
• Browsers on phones support two softkeys. In most cases, the primary softkey will be OK or a similar "select and move forward" type of function. This leaves one softkey. If you consistently consume that softkey with a back function, you will find yourself without a valuable resource. Because users need constant access to the Back function, it's not fair to offer it only some of the time. Fortunately, there's a built-in solution to the problem...

All browsers have a dedicated key for the Back function--the CLR key (some phones use a different name, but the key is always there). We feel that learning to use the CLR key to go back is a fundamental part of learning to use the browser. Occasional use of a Back softkey undermines this arrangement because users who learn to go back with a Back softkey are not forced to learn of the CLR key and are more likely get stuck when a Back softkey is unavailable.

Some would argue that including a Back softkey would allow the use of one code set on both Nokia and Openwave browsers. This is not true. To code the Back function so that it displays properly on a Nokia browser, one must use the <prev> action type and not the <options> action type. Thus, the coded Back softkey will simply add an additional softkey within the options menu that appears on the Nokia browser.

A "Back" link would mean that there were two ways to do the same thing on a screen; this is generally confusing to users.

Perhaps the most compelling reason to not use Back as a softkey label is that some phones--such as Nokia--already have a built-in Back softkey. This built-in softkey will appear the same as softkeys you define, yielding two identical Back softkeys and the appearance of a mistake.

There are many times when it is appropriate to offer backward links via softkeys. For example, we often recommend using a Main softkey to provide access to the top level of your application. DONE is an excellent way to exit a context, taking the user to a higher level of the application. And there are times when it is appropriate for a softkey to return the user to the previous card. In such cases, the softkey should employ the <prev> command rather than following a link because the <prev> command will draw pages from the cache rather than make a new fetch. This technique will improve access times, reduce network load, and make it easier for users to navigate backward without revisiting cards they've already seen.

In summary...

The following recommendations apply to HDML, WML, Openwave and Palm.

"Back" should not be used as a softkey label. Note that this does not prohibit backward navigation from a softkey, it merely prohibits the use of the word "Back" as a label.

Do not use "Back" as a link. Users prefer to use built-in back controls, and your control just uses extra visual and data space. This recommendation also applies to XHTML Basic.

Backward navigation is not only about the Back button. Some other considerations: The following recommendations apply to all situations.

Appropriately handle backward navigation. On platforms and devices that do not provide a back control, provide one. On platforms that provide a built-in back control only if you code it (e.g., Nokia WML 1.x), code the back control. On platforms that automatically handle back (e.g., Openwave WML or XHTML, Nokia XHTML-MP), do not provide a back control, as it may give the user dual control over back. While most or all phones will have a Back key, PDAs may not. Further, these buttons may not work unless the screen has an abstract command of type "Back".

Only use the Back label if your control goes back precisely one screen. "Back" is such a well-understood function that everyone has very specific expectations of what it performs. If you wish to go back more than one screen, use a different label for your control, such as "Retry", "Start Over", "Main" or some other location-specific label.

Use backward navigation on-screen controls only when the device's backward navigation will interfere with the proper functioning of the application.

The following recommendations apply to HDML, WML and WML2.

Actions and commands that return to the just-viewed screen should invoke the platform's <prev> function rather than a forward-navigation function. This will avoid the appearance of an endless loop and take advantage of cached information. Exiting a context (via the exit or return elements) is a suitable alternative (when appropriate).

Use contexts (spawn and exit) or onenterbackward events to map backwards navigation to an intuitive location when direct backwards navigation is not suitable. Many times the just-viewed card is not an appropriate card to visit when using the BACK key. Examples include when entering a password, a wizard where clearing out data in the input elements are necessary to go backwards, or the user has just completed an order.

Use Cancel Guards (delete shields) to prevent loss of user entry. See the section Cancel Guard for details. . The following recommendations apply to Openwave HDML, WML and WML2.

Do not allow users to back into a screen and view a password. Define onenterbackward events or contexts to prevent this.

Clear the history stack when backward navigation is impossible and the user must not revisit cards. Ideally, you'll never have to worry about this because you've designed with good backward navigation techniques. But just in case, use the newcontext=true tag to implement this suggestion. The following recommendations apply to WML and WML2.

Don't define the <prev> task with the <noop> action. If the back button doesn't do anything, the user may feel forced to return the device's home page and then are less likely to retrace the steps that got them to your site in the first place.

Use throw and catch to preserve data entered in situations like contexts and wizards. When a context is exited, all variables assigned in it are deleted. In a wizard, users have to delete data to navigate backwards because the BACK key is also the CLR key. To preserve user-entered data, use a throw statement to send variables, typically in the <prev> task or exit task, but perhaps also in the onenterbackward event. Outside the context or wizard, on the first card displayed after the throw statement, use a catch statement to receive all the variables. This way, when navigating forward through the wizard, the user need not reenter data but can modify or remove it as necessary.

Use sophisticated back-end code techniques for backward navigation if extensions are not used. Although outside the scope of this guide, potential techniques include (but are not limited to) re-using the same URL to display a different card, managing variables in server-side code instead of the markup language, and redirecting based on application state. This recommendation also applies to XHTML Basic.

If you do not mask text input with "password" formatting, assign the password input field to its own page. A password alone is useless. A password combined with a user ID or other credentials is a different matter. If you choose to increase the usability of your application by not masking passwords, you can avoid any additional risks by not displaying a user's full set of credentials on one page. This recommendation also applies to HDML and XHTML Basic. (endold)

[edit] Security and State Management

The new security model allows for carriers and manufacturers to support their own customized headers in addition to the default domains. Carrier implementation, as always, varies. Such additional domains may provide a better fit with your application when they are implemented. This is worth looking for in the future.

− Specify the minimum security level that your midlet actually needs to perform its function. Develop with an eye towards “can I do this as an untrusted app”, and add just the access you need. J2ME allows multi-threaded applications. While managing a new thread has a high amount of overhead for a device, using threads judiciously can cause the application to seem faster and more responsive. _ Encapsulate lengthy operations (such as network activity) in their own new threads. A new thread will allow the device and application to continue providing user feedback. Using the existing thread will cause the application to appear to lock up. _ Provide user feedback during operations longer than 1 second. Let the user know the device is performing the requested task. A Gauge can let the user know the relative progress of the process. An animation can let the user know something is happening. The animation should be in a separate thread. _ Remove the command that started a lengthy operation. If the screen that you display while a lengthy operation is in progress looks the same as the screen that launched the operation, remove the command that started it. Otherwise, users may unnecessarily launch the operation again. _ Provide the user the opportunity to cancel a lengthy operation. _ Re-use existing threads in lieu of creating new ones. Using an existing (currently unused) thread is faster and uses less overhead than creating a new one. − Alert the user with sound or vibration at the end of a long process. The user is unlikely to stare at the screen for more than 10 seconds waiting for a long fetch to occur. A quiet beep or short vibrate will alert the user to the readiness of the application to proceed, freeing the user from having to check the device. PasswordsPassword security on a mobile device is a bit different than it is on computers. It is very difficult to look over somebody's shoulder to see what they are typing if they do not want you to see. MIDP provides two modifiers for TextField to handle your security needs: • PASSWORD – suggests to the device to “mask out” the entry, usually replacing with asterisks or some other characters • SENSITIVE – suggests to the device that the information not be cached, stored in predictive text dictionaries, or otherwise stored on the device. When using either modifier, you do have to rely on the device to implement correctly, which will be the case for most devices. _ Use the SENSITIVE modifier for sensitive information such as passwords and credit card numbers. The device will not store this information.

While only you can judge the security needs of your application, consider the difficulty associated with entering passwords. − Do not mask out text input with the PASSWORD modifier. The usability problems associated with triple-tapping masked passwords outweigh the costs of hiding those passwords. _ On the surface, password format appears usable because the user can see each character as it is entered. Actually, while typing letters, users look at the keypad or keyboard, not the display, as they determine the triple-tap sequence for each character. Touch typing on mobile devices is difficult! Once they look up at the display, the cursor will have advanced, obscuring the just-entered character with an asterisk or similar character. Even the most experienced users will have occasional trouble with password format. Consider that each mobile device is a personal device, and its user has considerable control over it. Unlike kiosk or fixed-computer situations, where somebody could look over a user's shoulder, in mobile situations the user can move the screen and keypad whenever desired. When combined with the difficulty in text entry on most devices and the likelihood of user distraction partway through text input, masking user input has an unacceptably high user cost for very low user or security benefit. In summary: masking passwords (during input) will reduce the amount of password theft primarily because there will be fewer users and thus, fewer passwords to steal. _ If targeting MIDP1 devices and not using the PASSWORD modifier, assign the password input field to its own page. A password alone is useless. A password combined with a user ID or other credentials is a different matter. If you choose to increase the usability of your application by not masking passwords, you can avoid any additional risks by not displaying a user's full set of credentials on one page. − Avoid unnecessarily complex password formats. The format of your password has a strong and direct effect on the difficulty of entry. In general, the difficulty of entering a masked string increases with the complexity of the string. As a rule: • Alphanumeric strings are more difficult to enter than alphabetic, • Alphabetic strings are more difficult to enter than numeric, • Case-sensitive strings are more difficult to enter than case-insensitive, • Strings with symbols are more difficult to enter than strings without symbols, etc. Because complex passwords are more secure passwords, you must find the appropriate balance for your particular application. All-numeric strings are the easiest to enter, but because it is not possible to force numeric format with some phones, we recommend that you not mask out numeric passwords. Other password-related recommendations: _ Require log-ins only when necessary. Once a user has logged in, that user should not be required to log in again unless 1 of 2 things has occurred: 1) the user logged out, or 2) the user has been inactive for a period of time that exceeds the security threshold for the site. A site's security threshold should be based on the nature of the site. For example, an e-commerce site might have a security threshold of 10-15 minutes, whereas a site that offers email might have a security threshold of 3 days. − Secure applications should require users to log in (or "sign in"). _ If you provide the ability to log in, then you must provide an option to log out (or "sign out"). _ A "log in" option must be provided only if the user is not currently logged in. The appearance of a "log in" option when already logged in will create the false impression that the user is not logged in. − A "log out" option must be provided only if the user is not currently logged out. The appearance of a "log out" option when already logged out will create the false impression that the user is not logged out. − Sites that require users to log in should also supply a freely accessible information page for non-registered users. Don't make the front page of your site an input card for logging in, as this will preclude your ability to greet new customers or offer support to existing customers.

If your application has a "sister" desktop application that uses user names and passwords, let users re-use their existing user name and password on the mobile device. Users will want to avoid having to remember yet another user name and/or password. If you share names and passwords between different versions of your site, make sure that the same rules (e.g., minimum number of characters, case-) apply to both versions. Although numeric passwords are easier to enter on a phone-type keypad, they are harder to remember and are not usually expected on an desktop site.

− Save the current state and user data often. Some MIDP implementations will lose the application state when the user switches applications - say, to answer a call. When the user returns to the MIDP area, your application might not even be running, and the user task will be interrupted or aborted. Save the application state so that upon return, the user can resume their task without loss of data. Include application-switching as part of your testing plan. Devices may not handle varying states and application states properly. Ensure your test plan includes receiving a phone call, switching to other non-J2ME applications on the device, and so forth.

[edit] (old)( Security, Cookies, and State Management

NOTE: This and the above newer section are really close but subtly different.

Security is a serious matter for mobile devices. But the common standards applied to desktop computer security do not necessarily apply to mobile devices. The primary difference is that unlike a desktop computer, most mobile devices are personal devices, treated like a wallet. It is kept with the user or in a secure place. Like a wallet, losing a device can result in significant financial loss, so users will take steps to disable a lost or stolen phone. Carriers can very quickly disable a phone at the request of the account holder. Thus, the potential thief will not be able to see the user's browser data, as the phone cannot make calls. With that in mind, please read the following guidelines pertaining to security and cookies:

The following recommendations apply to all situations.

Use cookies. Cookies are useful for avoiding text entry, particularly data that the user has already entered. Cookies can also be used to store user preferences for sites that allow user customization. Note that cookies are usually not stored on the device, but on the gateway. Alternately, you can store cookies on your server, as some gateways may not store cookies, and some devices may not use gateways.

Give your cookies an appropriate time-to-live (TTL). The optimal TTL for cookies will depend on your application and its inherent security risks. Consider how often your users will access your site. Note that security risk is often a matter of user perception (i.e., not all users care whether someone reads their email). For this reason, we prefer to employ a "log out" option to give users the choice of whether to keep their data secure. A short TTL, on the other hand, takes control away from the user (although this may be desirable in some situations).

Use the Subscriber ID to identify the device when available. The Subscriber ID is part of every fetch string sent to your site. We encourage sites to use Subscriber ID for tailoring low-security content (e.g., weather forecasts) to meet a user's preferences or usage patterns. Because users will sometimes borrow or lend phones, the Subscriber ID must not be used to verify a users identity unless there is a specific reason to limit a user to one particular phone. This guideline is less important with packet data networks in which a user can sign on to any device, but many consumers will ignore this feature. Further, users in corporate workgroups may not have a device specifically assigned to them.

[edit] Passwords

While only you can judge the security needs of your application, consider the difficulty associated with entering passwords.

The following recommendation applies to all situations.

Do not mask out text input with "password" formatting. The usability problems associated with triple-tapping masked passwords outweigh the costs of hiding those passwords.

On the surface, password format appears usable because the user can see each character as it is entered. Actually, while typing letters, users look at the keypad, not the display, as they determine the triple-tap sequence for each character. Once they look up at the display, the cursor will have advanced, obscuring the just-entered character with an asterisk or similar character. Even the most experienced users will have occasional trouble with password format.

Consider that each mobile device is a personal device, and its user has considerable control over it. Unlike kiosk or fixed-computer situations, where somebody could look over a user's shoulder, in mobile situations the user can move the screen and keypad whenever desired. When combined with the difficulty in text entry on most devices and the likelihood of user distraction partway through text input, masking user input has an unacceptably high user cost for very low user or security benefit. In summary: masking passwords (during input) will reduce the amount of password theft primarily because there will be fewer users and thus, fewer passwords to steal.

Note that the format of your password will affect the severity of this issue, as the difficulty of entering a masked string increases with the complexity of the string (e.g., alphanumeric is harder than alphabetic, which is harder than numeric, etc.). Numeric strings are easy to triple-tap, but only if the text entry format can be pre-set to numeric mode. Because this is not possible with many XHTML Basic devices, we recommend that you not mask out numeric passwords.

The following recommendations apply to all situations.

If you do not mask text input with "password" formatting, assign the password input field to its own page. A password alone is useless. A password combined with a user ID or other credentials is a different matter. If you choose to increase the usability of your application by not masking passwords, you can avoid any additional risks by not displaying a user's full set of credentials on one page.

Avoid unnecessarily complex password formats. The format of your password has a strong and direct effect on the difficulty of entry. In general, the difficulty of entering a masked string increases with the complexity of the string. As a rule: Alphanumeric strings are more difficult to enter than alphabetic, Alphabetic strings are more difficult to enter than numeric, Case-sensitive strings are more difficult to enter than case-insensitive, Strings with symbols are more difficult to enter than strings without symbols, etc.

Because complex passwords are more secure passwords, you must find the appropriate balance for your particular application. All-numeric strings are the easiest to enter, but because it is not possible to force numeric format with some phones, we recommend that you not mask out numeric passwords.

Other password-related recommendations:

The following recommendations apply to all situations.

Require log-ins only when necessary. Once a user has logged in, that user should not be required to log in again unless 1 of 2 things has occurred: 1) the user logged out, or 2) the user has been inactive for a period of time that exceeds the security threshold for the site. A site's security threshold should be based on the nature of the site. For example, an e-commerce site might have a security threshold of 10-15 minutes, whereas a site that offers email might have a security threshold of 3 days.

Secure sites should require users to log in (or "sign in").

If you provide the ability to log in, then you must provide an option to log out (or "sign out").

A "log in" option must be provided only if the user is not currently logged in. The appearance of a "log in" option when already logged in will create the false impression that the user is not logged in.

A "log out" option must be provided only if the user is not currently logged out. The appearance of a "log out" option when already logged out will create the false impression that the user is not logged out.

Sites that require users to log in should also supply a freely accessible information page for non-registered users. Don't make the front page of your site an input card for logging in, as this will preclude your ability to greet new customers or offer support to existing customers.

If your application has a "sister" desktop application that uses user names and passwords, let users re-use their existing user name and password on the mobile device. Users will want to avoid having to remember yet another user name and/or password. If you share names and passwords between different versions of your site, make sure that the same rules (e.g., minimum number of characters, case-) apply to both versions. Although numeric passwords are easier to enter on a phone-type keypad, they are harder to remember and are not usually expected on an desktop site.

[edit] Alerts

Many platforms support asynchronous messaging, in which an application can inform the user of some information when the application is not running or the user is not connected to the network. Alerts can be extremely useful. But be careful! Reckless or improper use of alerts can inhibit usability to the point of causing the user to not use alerts at all (and possibly also the browser). These rules apply to all alerts, whether they are built into a platform or attached to an application using a tool like SMS.

The following recommendations apply to all situations.

Automatic delivery of alerts must not be initiated unless requested by the user. Allow the user to decide whether to receive alerts from the application, instead of sending alerts after the user has visited the site once. Don't burden your customer support with the task of disabling alerts for disgruntled users who never asked for them in the first place. This practice will prevent your site from being perceived as sending spam.

The URL or other address to content in an alert must remain valid for a minimum of 24 hours after sending the alert (72 hours is recommended). If an application provides invalid alerts, those alerts will be ignored and probably discontinued.

Allow the user to control their alerts. The user may want alerts from one part of the site, but not another. Consider this situation when deciding to use alerts.

Be conservative with alerts. Don't assume that users want to be bombarded with information. Alerts are intrusive--they will interrupt the user at any time. If a user specifically asks for large quantities of alerts, then supply them. But don't send large numbers of alerts by default--most users will find this bothersome.

In the case of network-initiated messaging, do not confuse alerts with text messages (aka SMS) or multimedia messages (aka MMS). Although they may share similar delivery mechanisms, alerts behave differently than text messages and must be treated differently. Text messages are roughly 160-character text strings that are delivered to the device where they are stored in local memory. Multimedia messages are a newer technology based on text messages, with the possibility of image or sound attachments. Both message types are viewed off-line and do not involve use of the browser.

Aside from calling the sender's phone number (which may be transmitted along with the message, at the sender's discretion), the recipient of a text message cannot "reply" to it. Openwave has used network-based alerts in every browser they have made. With WAP version 1.2, alerts became part of standard WML.

The payload of an alert consists of a short title (usually the name of the originating service or sender) and a URL. When the alert is first received, the title is displayed on screen in the form of the question, "Message from '<alert title>'. View it now?" The precise message format varies from device to device. If the user chooses to view the alert, then the browser is activated and the enclosed URL is accessed. If the phone receives multiple alerts from the same application, only the most recent alert will be displayed.

Openwave alerts have three different priority levels: low, medium, and high. On most phones, the pop-up message described above will be presented only for high-priority alerts. If the pop-up message is not displayed then the user must go to the alert inbox to seek out the alert. The following recommendations apply to all situations.

Alert titles should not exceed 15 characters. This allows the title to fit on one line in the inbox. Use only one URL for all your application's alerts. Devices use the URL to determine whether the alert is a new one, or a replacement for a previous one. Each new alert takes one of a limited number of slots available, and the slot is occupied until the user manually deletes the alert. Openwave devices fill alert slots on a last in, first out basis, so users may not see an alert that arrives after the inbox is full.

If your application has multiple alerts, create an alerts menu within your application. If you want to have different types of alerts, use the alert's URL to point to a card that lists all the outstanding alerts for the user. This technique allows you to send a variety of alerts without consuming more than one alert inbox slot on the phone.

Alert titles should contain precise information only if that information is made obsolete by subsequent alerts. To avoid requiring the user to manage a large number of incoming alerts, alerts are combined, with new alerts overwriting old alerts. If one alert provides a specific piece of information (e.g., "email from Jim"), know that this information will be lost when a new alert overwrites the old alert. And note that alerts can be combined before they even get to a user's phone. For example, if the alert "email from Jim" is followed immediately by "email from Tom," the user will only see "email from Tom" and never know that they received an email from Jim. A better design would be to display how many emails were waiting. That is, the first alert would be "1 email," the second would be "2 emails," et cetera.

Send new title counts (e.g., "1 email") with low priority. This keeps the counts up to date without bothering the user with an unnecessary beep. If the user ignored the first alert, chances are that they're not paying attention to their phone or they don't want to be bothered.

Allow the user to turn off or change beep settings. Although this is not yet supported on phones, it will be useful when it is supported. Applications under development should support this. Please refer to the developer's literature from Openwave for more details about coding and delivering alerts to Openwave browsers. (endold)

[edit] Performance Management

J2ME returns us to the days of computers with slow processors and insufficient memory. The devices are slow and small and you'll want to extract every ounce of efficiency you can out of the language. A J2ME MIDP application runs within a KVM that runs within the device operating system. In short, there is even less memory and processing power available to a MIDP application than there is to native applications. Your application will be slow. Here are some tips to help alleviate the problem.

− Use local variables instead of fields. Accessing local variables is quicker than accessing class members. - Use function calls only when necessary. Assigning a function call to a local variable is faster than calling the function each time in a loop. − Reusing objects is preferred to creating new ones. Object creation and destruction uses a lot of overhead. Design your application so that objects will be reused and referenced, not created and destroyed. Avoid synchronization. Put long (> 1/2 second) processes in a separate thread. You'll use less overhead and less code, and your application will appear more responsive. Use StringBuffer instead of string concatenation. Concatenation requires object creation and garbage collection.

[edit] (old) Cache and Performance Management

The cache is very useful for many reasons. However because frequent backward navigation often re-displays cached data, developers must be careful to remove data from the cache so as to prevent the unwanted display of "old" data. Here are some tips on when to erase cached data:

The following recommendations apply to all situations.

Don't rely on cache management. Support for caching is highly variable across handsets, and your pages may not cache at all. The gateway may cache your content, but this does not reduce the amount the user has to transfer to the phone.

Specify a time-to-live value for data that will become obsolete or inaccurate. For example, email messages and stock quotes. Use the meta max-age control to specify this. For example: <meta http-equiv="cache-control" content="max-age=900" forua="true"> will set the TTL to 15 minutes (900 seconds). Note that this will only force a refresh of the screen when navigating forward.

Force TTL validation on data that will become obsolete or inaccurate. Use the "must-revalidate" meta control to cause the browser to respect the TTL even when the screen is entered via backward navigation.

Avoid setting short time-to-live values for infrequently-changing data. Setting a TTL to 0 will force the user to reload the screen--and experience the cost and delay--every time the screen is visited. The following recommendations apply to Openwave HDML and WML.

Remove from the cache any data that has outlived its usefulness. This (and the following techniques) will free the cache to store more data and prevent the user from accessing inappropriate data. Few users will be able to determine whether data is from the cache or has been recently fetched. Make it clear for them by not re-displaying old data.

Remove time-sensitive or obsolete data from the cache. For example, a stock quote loses its accuracy after about 15-20 minutes.

Remove from the cache any data that belonged to a completed action. For example, once a user makes a purchase, the data used to preface that purchase may now be obsolete and confusing if displayed after the purchase is complete.

Remove data from the cache in accordance with the user logging in or out of your site. Once a user logs in, they should not see the same data as before they logged in, and vice versa.

Remove "deleted" data from the cache. If the user takes an action that deletes data (such as an email), then that data should be removed from the cache, else the user may end up looking at data he just deleted!

Force reloading of the deck for dynamic data. This will reduce the chance of a user looking at old data and mistaking it for current data. To accomplish this, use <meta forua="true" http-equiv="Cache-Control" content="must-revalidate"/>

Use mobile-originated pre-fetch when the user's most likely next data is known. This will reduce the amount of time the user needs to wait when proceeding to the next step. Use pre-fetch for the next page of a news story if your site statistics show that most users are reading entire news stories. Use pre-fetch for the next screen in a wizard. (endold)

[edit] Voice Calls

Because the mobile user rarely has a free hand or the means to write, it is frustrating to find a phone number via the application and be required to write down or memorize the number and manually enter it after leaving the application. For this and other obvious reasons, we strongly encourage all developers to take advantage of this feature and let users launch voice calls on any phone number that they might encounter.

When a voice call is invoked from a MIDlet, the device will exit the application to make the call. Do not expect the device to return to the application after terminating the call. Enable voice calls by creating a TextBox with a PHONENUMBER modifier with the string set to the phone number to call. If the user presses the TALK button, the device will present the user with a call confirmation.

Provide a label for the text field indicating that the user should highlight it and press the TALK button. It may look like an editable field, so this extra labeling would be necessary. (old) Voice Calls

Most platforms offer the ability to launch voice calls directly from the application. The value of this feature is most evident when it's not available. Because the mobile user rarely has a free hand or the means to write, it is frustrating to find a phone number via the application and be required to write down or memorize the number and manually enter it after leaving the application. For this and other obvious reasons, we strongly encourage all developers to take advantage of this feature and let users launch voice calls on any phone number that they might encounter. Some devices have the ability to extract any number from any application screen. Other devices have built-in methods of making phone calls.

When a voice call is invoked from a browser or application environment, the device will exit the browser to make the call. Although we expect most devices will return to the browser or application environment following the call, you should not design around this assumption, as it cannot be guaranteed for all devices.

The following recommendation applies to all situations. When listing multiple phone numbers, list the primary number first. This is the most likely number for the user to call.

The following recommendation applies to Openwave XHTML Basic and WML. Use href="wtai://wp/mc;<phone number>" as the link's address to make a link to start a voice call directly from the screen. Avoid linking to another screen for further interaction.

The following recommendations apply to XHTML Basic and WML. When the link's "title" attribute is not displayed, ensure that the screen gives enough context to indicate a call will be made. Possible strategies include putting the text "Call:" in front of a linked phone number, and creating a phone graphic that is the link instead of the phone number. This provides extra context that a phone call will be made. Many users will not predict that following a link with a telephone number will make a voice call unless there are extra cues available.

When the softkey displays the "title" attribute, use a phone number as the link's text. This provides extra context that a phone call will be made. For example, a link that appears as "Call" is more mysterious than "242-555-1234". Ensure that the softkey label is "Call". This recommendation also applies to HDML .

The following recommendation applies to Access XHTML Basic. Realize that Access browser users (e.g., Sanyo devices) will not be able to call until their browser is in a dormant state. This is generally a few seconds after the page is done loading. (endold)

[edit] Location Services

Moving forward, phones and most other devices will have location support, in which the application can determine the location of the device. Most devices will not have pure GPS, and thus the location requires information from the network. Obviously, therefore, the carrier needs to have implemented location services.

Carrier's implementations vary based on their strategic goals when meeting government location requirements. For example, a carrier may not support standard GPS features such as orientation or velocity, requiring you to use a time series to estimate such values.

JSR179 has method getLocationMethod() which returns the location features (terminal or network-based, cell-ID, timed difference, etc.) implemented by the device. It is conceivable that a feature my be implemented by the device but is not supported by the carrier.

Note that MIDP 2 only requires CLDC 1.0, which does not have floating point arithmetic. Some devices have CLDC 1.1 support, which does have floating points. You'll need to be creative if the device does not have the capability.

_ Detect the device's location support and use the appropriate API. Devices may support Qualcomm's Java Application Environment, JSR 179, something else, or none. − Do not assume that the full API is supported, and capture exceptions gracefully. Velocity, address, or orientation portions of the API may not be supported. When designing location-based services, keep in mind that most applications can use even imprecise location effectively. A traffic application can effectively use accuracies ranging from 5 miles to 100 yards, but anything more precise does not help. Even a directions application, while best implemented with 10-meter accuracy, can be useful with 1000 meter accuracy. If it turns out that the directions are substantially different based on whether the user is at point a, b, or c, the application can simply ask the user which is closest. _ Design your application to support as imprecise a location accuracy as possible. Do not design a weather application to require 10 meter accuracy even if your database supports it. − Take advantage of the location precision returned. If you can make better use of 10 meter accuracy than 1000 meter accuracy, do so. _ Never disclose the user's location without express permission from the user. The exception, of course, is when you are legally obligated to do so.

[edit] Messaging and Push Services

SMS (Short Message Service) is a popular way to send text messages to both users and applications. Users like it because it has a predictable cost, is asynchronous, private, and non-invasive to the recipient. Reliability is guaranteed by a store-and-forward strategy to compensate for the possibility that the receiving device is off the network. Because the message is stored on the gateway until delivery, the gateway can be configured to acknowledge delivery of the message. SMS can also be used to push messages to applications on the device.

The format of the message is not tightly controlled by the SMS protocol, leaving the developer free to add their own message property fields. Message property fields may be used for message metadata, allowing intermediary applications and gateways to make decisions about the message. − Keep user data in the body of the message. Use message property fields for message metadata to be read by intermediary applications (e.g. message filtering).

Since SMS is asynchronous, messages may be delayed 15 seconds or 15 minutes normally; if the user is out of coverage the message could be delayed for hours. The user will get the message, but you do not have control over when. In certain rare situations, you need to closely manage message delivery times. In these cases, you can implement a timed event to poll the server on an appropriate schedule using UDP or TCP. − Use SMS for most messaging applications. It uses the least network resources and is most reliable. − Do not poll the network often. If appropriate, poll every 15 minutes rather than every minute. Otherwise your application will cause network congestion.

While most Internet traffic relies on the TCP (Transmission Control Protocol) to create reliable socket connections, the overhead for sockets can be prohibitive for a mobile device. UDP (User Datagram Protocol, or Unreliable Delivery Protocol), is a better strategy for dodgy networks despite the protocol's inherent "unreliability", UDP packets are data-rich and are more likely to get through. This does mean, however, that the application/gateway developer must write data control and validation routines.

For security reasons, many carriers do not allow unsolicited inbound UDP or TCP connections to mobile devices. They will allow SMS.

Only trusted applications may access UDP, TCP or SMS. The security model, included in the JAR/JAD files, is registered at install time.

The AMS listener listens for push messages and timed events, and activates applications in response. If the application is already active on the device, AMS does nothing; that application is responsible for listening for messages and timed events. Applications may be registered with AMS upon installation (preferred) or with a run-time method. Applications that register when installed are automatically unregistered when uninstalled.

_ Push application data updates through SMS. For larger data transfers, use the SMS message to tell the application to initiate a UDP or TCP connection from the device. − Provide an alert screen to inform the user what the application is doing. Having the device spontaneously burst into action confuses the user.

[edit] PIM Data (from JSR 75)

The purpose of the APIs that comprise the Personal Information Management (PIM) optional package for J2ME is to provide MIDP 2 applications access to native PIM data, either on the device or on a gateway which the device accesses. PIM data is defined as information included in address book, calendar application and to-do list applications, although each of the above is optional. The APIs provide for the ability to access PIM data not resident on the device, such as SIM cards attached to the device, as well as PIM databases created and managed by the Java VM itself. Note that only trusted applications will have access to PIM data.

− If the address book is present, do not store personal address book data. Use the device's data instead; it will be used across many applications and may even be synchronized with a computer database. Exception: the data you are storing, while using standard format, is not data that the user would be accessing regularly. − If the calendar is present, do not store personal calendar data. Use the device's data instead; it will be used across many applications and may even be synchronized with a computer database. − Allow access to PIM data for relevant data entry. It will save the user a lot of time. − Allow the user to save contact, task, or calendar data to their personal database. This is particularly relevant for yellow page applications, local events such as movies or concerts, and so forth. _ Ensure that you check for data availability before accessing it. Devices may have only some data types implemented. Use openPIMList() to ensure the data type is available and access does not violate the security model.

[edit] Miscellany

− Avoid lengthy operations. Users will become distracted, cancel operations, get impatient, and generally be unhappy with the application.

Use a timer element to ensure mission-critical data is up-to-date when the user looks at the screen. Avoid automatically updating most consumer applications due to airtime expenses. Use databases for long-term storage, global variables for short-term storage. Database operations have higher overhead, and will be slower than simply using a global variable. − Save user entry to long-term storage at every opportunity. When the user types something or changes a setting, save the information to a global variable. Clear the global variable when changes are committed. This allows you to re-populate fields when the user returns to a screen after some sort of interruption, like starting to exit, receiving a call, checking another application, or going to another screen.

Ensure your application or site name will display well in the browser or application manager. If your company has a long name, consider altering your branding requirements for the mobile environment. See Title and Header on page for further details. − Ensure that version and help information can be displayed from the main screen. Version information will help your support staff troubleshoot. If the application is in a free trial period, use a splash screen that indicates time remaining and how to order. Time remaining may be number of uses or number of days. Ordering information could be a URL or phone number. − Allow customization. However brilliant your design, it won't meet each individual's needs. Allow the user some method of having the application's main page match user tasks. This can be accomplished either via explicit customization, or saving user history and implicit customization. Note that MIDP 2 only requires CLDC 1.0, which does not have floating point arithmetic. Some devices have CLDC 1.1 support, which does have floating points. You'll need to be creative if the device does not have the capability.

(old) Miscellany

The following recommendations apply to all situations.

Avoid lengthy operations. Users will become distracted, cancel operations, get impatient, and generally be unhappy with the application.

Ensure your site name will display well in the browser. If your company has a long name, consider altering your branding requirements for the mobile environment. See Screen Design:Title and Header for further details.

Allow customization. However brilliant your design, it won't meet each individual's needs. Allow the user some method of having the application's main page match user tasks. This can be accomplished either via explicit customization, or saving user history and implicit customization. The following recommendations apply to XHTML Basic.

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.

If using Apache, be sure to define the PNG mime type.

Use the cache-control: no-transform HTTP header if your site is already optimized for mobile devices. This will prevent any gateway from converting your content, slowing down site responsiveness and perhaps rendering the site differently than you expect.

The following recommendation applies to HDML and WML. Use the Back (CLR) key only to execute the <prev> action. Do not assign other functions to this key. Use short URLs. The user will not see the URL, so it needn't be understandable. However, long URLs needlessly increase the size of the page, thereby increasing download time and adversely affecting your content (by limiting the number of menu items, for example).

The following recommendation applies to WML and WML2. Use a link element with rel="next" as a hint for the browser to pre-fetch the next page. The browser can pre-fetch the next page so that it is already on the device when the user is ready for it. This is a good technique on connections where the user is paying for airtime or applications where the user's time is more important than the small extra cost. (endold) Screen Design