Mobile Web Best Practices 2.0

This document sets out a series of recommendations designed to enable development and delivery of great Web applications on mobile devices.

The recommendations are offered to creators, maintainers and operators of Web applications.

The document is organized as follows:

• Introduction. Describes the audience, purpose and scope of the document.
• Requirements. An illustration of the type of problems that the Best Practices are intended to address.
• Delivery Context. Discusses the environment within which mobile access to Web applications is realized, with particular reference to adaptation.
• Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.
• Best Practices. The statements themselves.
• Conformance. A brief conformance statement.
• Acronyms
• Aliliendices
• Sources
• Related Reading
• Acknowledgements
• References

Readers of this document are expected to be familiar with the creation of Web applications, and to have a general familiarity with the technologies involved, such as Web servers, HTTP, and Web 2.0. Readers are not expected to have a background in mobile-specific technologies.

Our intention is to make it clear to all involved what the Best Practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some of our statements may appear to be obvious or trivial to those with experience in this area.

The document is not targeted solely at developers; others, such as interaction and graphic designers, and tool developers, are encouraged to read it.

These recommendations follow in the footsteps of the BP1.

The Best Practices have been written at a level of generality that allows them to be applicable across a range of Web technologies. They have been written with mobile user experience aspects in mind, which over time will change, but should remain relevant as technology evolves.

This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.

This section discusses the requirements of the Mobile Web Best Practice statements in section 5. The statement of requirements is intended to be illustrative rather than exhaustive or complete.

Related to the more frequent dependence upon personal information is the need to secure that information from eavesdropping or tampering when exchanged over the Internet. In order to ensure privacy and information accuracy you should only used trusted information, and protect any personally identifiable information, especially user identifiers or keys to user identity. While the need to protect personal information is not unique to the mobile environment, due to the typical resource limitations of mobile devices and mobile networks, developers should carefully weigh the impact of typical information security methods (e.g. use of secure HTTP), and may need to consider more efficient design alternatives in the mobile context. The overall goal for security is to use efficient methods to protect any personally identifiable information, and especially user identifiers or keys to user identity.

Applications should ensure the user is aware of application behaviors that may affect the overall service experience, and that the user is offered options for control over the behaviors. For example, while it can significantly simplify the user experience, frequent data exchange with servers can significantly impact service cost and battery life.

Device API's that are available to Web applications are being developed in a variety of standards activities and vendor-specific initiatives, e.g. for:

• File system access to pictures, music, and video clips
• PIM data (contacts, calendar)
• Call handling
• System data (battery, coverage, roaming, location)
• Media recording (record audio/video clip, get new picture)

Such API's are likely to be available in devices in the near term. The use of such personal information and device functions can expose the user to privacy and security concerns.

The overall goal is that the user is informed of such potentially experience-affecting functions, and given effective means to control them, or the opportunity to opt-out of application/function use.

In BP1, HTTP cookies and redirection were recommended to "not be relied upon" due to constraints of limited-capability mobile browsers and slower mobile networks. BP2 however recognizes that cookies are widely supported by current mobile browsers, and mobile network speeds have considerably increased since BP1. Thus while the BP1 recommendations are still useful to consider when the delivery context can't be determined, BP2 focuses on use of HTTP cookies and redirection for capable browsers and mobile networks.

BP2 clarifies how HTTP cookies and redirection can fulfill useful purposes in the mobile context. Cookies support statefulness and personalization in browsers, two considerations which can simplify the user experience and add value to content and services. Redirect supports server-server interaction via the browser, which is often essential for distributed services which rely upon partitioning of service functions across different servers, or for automated Identity Management / SSO. The restrictions recommended in BP1 prevented these application design approaches from being leveraged for mobile Web applications. However BP2 recognizes that since BP1, both web clients (e.g. browsers) and networks have evolved considerably in capability.

As compared to their use for web browser applications, cookies and redirect may play less of a role in maintaining statefulness and personalization for non-browser Web applications. Application-specific methods may be used, and may include use of more advanced technologies that are not available to some browsers, e.g. persistent storage. However, support for statefulness and personalization will still need to consider similar issues, e.g. state preservation/recovery and traffic overhead. As well, distributed services may still rely upon redirect for Web applications.

The overall goal is to set reasonable expectations on the impact for use of cookies and redirect in service delivery to browsers and Web applications, and to address alternatives for maintaining statefulness and personalization.

Web applications can have a significant impact upon the limited resources of mobile devices, and the cost of service in mobile networks. As a result, Web applications should use device and network resources conservatively.

The amount of network traffic that Web applications generate can have a very significant impact on service cost, especially for applications that autonomously interact with network-based services. These costs can be borne by the user and/or network service provider. Users with usage-based service plans can find themselves responsible for huge charges. Network service providers can bear these costs for users that subscribe to "bucket" or unlimited service plans, and as a result may only recommend or support efficient applications for use with such plans.

Web applications can also significantly affect the typically-limited battery life of mobile devices, e.g. through network traffic, screen updates, and processor/memory-intensive operations.

Web applications should be designed with consideration that users often want to use multiple/different devices to access services. Keeping such goals in mind will enhance the usefulness of Web applications, especially those that do offer multi-device access options, e.g. mobile and desktop.

As addressed in BP1, presentation issues of mobile devices can also be applicable to Web applications in general, e.g.

• variations in page rendering/layout in different devices
• context/overview constraints due to limited screen size and the limited amount of visible material
• dependency upon scrolling through material
• presentation space expense for images and navigation links
• overall lack of site/content cohesiveness due to fragmentation of display and site structure

However, advanced web browser features and evolving web technologies are adding additional specific issues that need to be addressed in the mobile context, including:

• support for popup windows and layers which can overlap partially/fully
• support for popup menus
• dynamic changes in screen orientation
• need for content adaptation (e.g. image resizing/cropping) due to variable presentation space
• overall usability issues resulting from more complex presentation options

As addressed in BP1, issues of interaction with applications on mobile devices can also be applicable to Web applications in general, e.g.

• limited keypad, e.g. 16-key, leading to difficulty in selecting \characters, and the need for application help in selecting the input character type
• physical keying difficulty due to small key size
• form field navigation
• overall difficulty in entering text impacting usability, e.g. for forms and long URLs
• no pointing device
• variations in softkeys for navigation and local application menus

However, evolution of mobile devices is adding additional specific issues that need to be addressed in the mobile context, including:

• new pointing methods, e.g. touch screens
• dynamic changes in keyboard layout, e.g. between 16-key, querty, and soft keyboards
• solve the top left navigation problem [need a definintion of what this is, and consideration of whether it is actually testable]

Device capability variation is a basic characteristic of the mobile web environment. The need to consider it when selecting, adapting, and delivering content and services is essential effectiveness of mobile Web applications.

Addressing this challenge also depends upon knowing which device and/or user-agent is in use (or intended to be served by the application), and its specific capabilities.

Delivery context variation is another basic characteristic of the mobile web environment. Variation occurs in several aspects, e.g.

The focus of the BP2 document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to a Web Runtime. The "Web Runtime" means in this case a Web application execution environment that provides support for application use of web technologies (e.g. CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), in particular as envisioned for use by Mobile Widgets. To ensure the applicability is clear, the recommendations address the functions of a Web application, rather than the specific client/framework in which they execute. The reasoning is that what is a good guideline for user experience improvement in one type of Web application running in a browser, is likely a useful guideline for Web applications being provided in other clients.

Document will include a descriptive passage about mobile context (including device, browser, network) we are talking about.

The Heading

The functional area that is addressed by the statements.

The Statements

One or more Best Practice statements, identified in the following way:

[EXAMPLE] This is a Best Practice statement.

What it means

An explanation of the significance of the statements under this heading.

How to do it

A discussion of techniques and some suggestions as to how to implement.

References

Where appropriate, references to related WCAG points and other immediate references from the preceding text.

5.1.1.1 What it means

5.1.2.1 What it means

Personalized services that rely upon user entry of information should retain that information to avoid the need to re-enter it upon each site access or use session, especially given the difficulty of doing so through mobile devices. Users are likely to quit using services that ask for the same information often.

5.1.2.2 How to do it

Information retention is possible by using cookies, as hidden information in content (e.g. forms, URL parameters, Javascript variables), in server-side databases, etc. The duration of retention should be matched to the type of application and typical user session profile, e.g. how often users typically access the application and how long they interact with it during each use.

5.2.1.1 What it means

Personally identifiable information (e.g. user identity or information usable as a key to user identity) should only be accepted or sent securely. This will ensure the confidentiality and integrity of the information. Information is personally identifiable if it is by itself directly related to an individual, e.g. a user's public identity such as name or phone number, or can be correlated to an individual by being exchanged along with other personally identifying information.

5.2.1.2 How to do it

5.3.1.1 What it means

Users should be informed if applications will make automatic data requests that can impact service cost, and should be given information that will help the user assess the significance of that impact. While the significance ultimately may depend upon information that only the user knows (e.g. their data service plan), having such notices up-front can avoid unexpected negative side-effects, e.g. significant usage charges or effect upon battery life.

5.3.1.2 How to do it

Applications should disclose, in a clear and useful way, the basic nature of their automatic use of the Internetfor data exchange, e.g.:

• how often the application will interact via the Internet, e.g. every 5 minutes, hourly, daily
• how long the automatic behavior will continue
• roughly how much data traffic will occur, e.g. in kilobytes, in a given period e.g. over each day, month, or per use of the application

5.3.2.1 What it means

While use of personal or contextual information can enhance service effectiveness, applications should ensure that the user is aware of such information use and exchange.

5.3.2.2 How to do it

The following information should be disclosed:

• the types of personal information (data or contextual information, e.g. location) that will be used by the application
• what data will be exchanged via the Internet

5.3.3.1 What it means

Disclosures about application behavior are useful (i.e. result in user awareness of the implications of using an application) only if they are provided at a useful time and in useful ways. A non-useful disclosure is practically a non-disclosure.

5.3.3.2 How to do it

Disclosures should be provided during application selection/loading or first use of sensitive functions.

Disclosures should be automatically provided e.g. as a user dialog, or easily accessible to the user e.g. via an "about this application" menu option.

5.3.4.1 What it means

Unless a sensitive application behavior is essential to the application, users should be given the option to control the behavior. If the behavior is essential to the application, users should be given the option to opt-out of application use.

5.3.4.2 How to do it

Users should be given easy-to-use controls to personalize application behavior, e.g.

• If an application uses AJAX requests to poll for updates from a server, the user should be able to turn off the polling, or adjust the schedule.
• Users should be able limit application use of personal data, or delivery of it over networks.
• Users should be able limit application use of sensitive device API's, e.g. location, filesystem, PIM data, media recording, etc.
• Users should be able to select the security level for requests and data sent over networks.

If user control over sensitive application functions is not provided, users should be given the chance to opt-out for the function, or to terminate the application.

User control preferences should be saved by the application to avoid the need to reenter them each time the application is used.

5.4.1.1 What it means

Cookies may play an essential role in application design. However since they may be lost, applications should be prepared to recover the cookie-based information when necessary. If possible, the recovery should use automated means, so the user does not have to re-enter information.

5.4.1.2 How to do it

Server databases can be used to store user information with persistence longer than typical session or cookie lifetime. Applications can be designed to recognize loss of cookie information, and direct the user or user-agent to a resource through which the information can be recovered from a database server. After recovery, the user or user-agent may be directed to a server which then provides service based upon the restored cookie information. These methods can increase information persistence, while limiting database server expense.

5.4.2.1 What it means

Request redirection (e.g. through HTTP or meta refresh methods) is a typical method for a service to automatically obtain necessary information from a different server. Such redirect based API's are very common in Web applications, and play an useful role in automated personalization for mobile Web applications, e.g. to avoid manual information entry. However latency, efficiency, and interoperability considerations benefit from minimizing the number of automated redirects in a sequence, for this purpose.

5.4.2.2 How to do it

A typical redirect sequence should require no more than two automated redirects, e.g. one to redirect to the information-providing server, and another to redirect back to the service-providing server. If further redirects are required, e.g. to a second information-providing server based upon the information obtained from the first information-providing server, a landing page can be used to break up the overall sequence, into two automated redirect sequences with a user "continue" click in the middle. This has the effect of reducing the apparent latency for the user, but should be balanced against the need for an extra user action, as four redirects in sequence (when necessary) are rarely an interoperability issue.

Web applications that autonomously interact with network-based services should be designed to minimize the overhead of network traffic for such automatic functions. Such Web applications are refered to here as "autonomously interacting Web applications".

5.5.1.1 What it means

Compress content for efficiency in delivery. Balance use of compression with the potential cost, e.g. to battery life for compress/uncompress operation. Use techniques if possible that are more efficient, e.g. tokenization.

5.5.1.2 How to do it

HTTP 1.1 compression, which typically uses gzip or deflate as algorithms, is a widely (though not universally) supported method of transfer encoding for delivery optimization, and is most useful for text-based content e.g. markup languages and documents. HTTP compression can significantly reduce the size and transfer time for web page. To use HTTP compression, web servers should be configured to serve web pages using HTTP 1.1 compression (gzip or deflate), for both upload and download transactions.

For tokenization, examples that may be supported include:

• Efficient XML Interchange, EXI
• WAP Binary XML encoding (WBXML)

Explain and expand upon the difference between use of encoding as a transport compression technique vs. an application compression technique. Note that transfer compression may not be supported for all network request techniques.

5.5.2.1 What it means

Applications that automatically issue network requests should provide value for those requests. The "value" in this case should be determined by the application developer based upon the type of service the application provides, and the resulting direct value to the user. Be mindful that background polling of servers on a mobile device can cause costly data usage and drain the battery. For applications that automatically issue network requests, e.g. dynamically updating applications built using AJAX methods and XMLHttpRequest in particular, managing data usage should be a key consideration.

5.5.2.2 How to do it

Overall data usage effectiveness can be improved by:

• Applications can minimize the number of interactions with the server, e.g. via XMLHttpRequest, by following some basic guidelilnes, e.g.:
  • wait until there is sufficient value to the user before sending requests, i.e. focus on how the request improves the user exerience
  • if there is no direct value to the user from sending individual requests, bundle transactions by combining multiple operations into one, e.g. for prefetching data that is known to be useful at a later time
• Applications can vary network request intensity based upon the current value to the user, depending e.g. upon whether the user is actively using the application, whether new information is ready to be uploaded/downloaded, etc. Applications that are designed to "back off" automatic behaviors during low-value periods can improve the overall cost effectiveness of their use. Example criteria for determining the useful transaction rate:
  • based upon intensity of user interaction with the application, e.g. if use slows down considerably for an extended period, the application may assume a lower user benefit from network traffic
  • based upon success ratio of network transactions, e.g. number of messages received for mail/social-networking applications, news feed items published, etc
  • based upon typical usage patterns, e.g. reduced automated transactions at night or periods of typical low usage/success
• If possible, use awareness of the current serving bearer network type, and roaming status, to select an appropriate intensity of network requests

5.5.3.1 What it means

Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods. While scheduled pull is a useful method for content that is regularly published, e.g. news/traffic/weather etc., some service types such as messaging/social-networking and "breaking news" monitoring can greatly benefit from use of push methods in terms of overall traffic effectiveness and timely content delivery.

5.5.3.2 How to do it

5.5.4.1 What it means

This section elaborates on the best practices of BP1 [section ref].

Developers sometimes don't consider the impact of the size of their application content, e.g. web pages, on mobile browsers. Recognizing that you are developing for a mobile Web application, and using effective techniques for minimizing the overall application size, will improve the user experience for mobile Web applications.

5.5.4.2 How to do it

Optimize use of CSS, e.g. avoid overuse of nested css classes that can bloat repeated blocks of content. Instead, make good use of selectors to minimize the size of repeated blocks of HTML. Bear in mind that css is easier to cache than generated HTML pages. For example, this...

style.css
.contact > div { float:left; }
.contact > div > img { border:1px solid #ccc; padding: 3px; }
.contact > ul { padding-top:3px; }
.contact > ul > li { font-weight:bold; }
.contact > ul > li:first-child + li { color:#777; font-weight:normal; }

content.html
<li class="contact">
  <div><img src="#" alt=""></div>
  <ul><li>name</li><li>status</li><li>address</li></ul>
</li>

Is much more compact than this... (if the element of HTML content is some repeated block, e.g. contact, stock entry, orders, etc)

style.css
.thumbnail { float:left }
.mountedimage { border:1px solid #ccc; padding:3px; }
.details { padding-top:3px; }
.name { font-weight:bold; }
.status { color:#777; }
.address { font-weight:bold; }

content.html 
<li>
  <div class="thumbnail"><img class="mountedimage" src="#'" alt=""/></div>
  <ul class="details"><li class="name">name</li><li class="status">status</li><li class="address">address</li></ul>
</li>

Note that the cost of CSS optimization needs to be balanced against impacts to maintainability. A way to retain maintainability is to optimize the CSS at point of delivery, instead of designing optimizations into the application.

5.5.5.1 What it means

Developers sometimes use scripting to create basic framework parts of their document. This has a higher cost in terms of content size and battery, rather than creating the framework in HTML.

5.5.5.2 How to do it

Use markup language to create the minimal page framework and flesh out repetitive/dynamic aspects of the page using javascript. For example:

• For a page displaying 100 contacts, the data for those contacts is much more compactly transmitted as a JSON string [JSON] than as fully-rendered HTML.
• The framework page ideally contains no dynamic data so it can be much more aggressively cached.
• A "loading" spinner can be displayed while an asynchronous request is made to get the guts of the data. Since a small and/or aggressively cached html page would load quickly this creates a better user-experience overall.

5.5.6.1 What it means

This section elaborates on the best practices of BP1 [section ref].

When an application depends upon multiple external script files, it typically must retrieve them separately from the main resource (e.g. web page) itself. This can increase data usage and service latency. Overall reduction of the number and size of script files can avoid these effects.

5.5.6.2 How to do it

If your application depends upon external scripts:

• Reduce the number of HTTP GETs required to retrieve the script files, e.g. by
  • Keep the number of script files to a minimum, e.g. by combining several script files into one
  • Send the scripts and main page together as a multipart/related package
• Reduce the size of your script files, e.g. by
  • Removing whitespace and comments
  • Making variable names in the code shorter
  • Use HTTP 1.1 compression [5.5.1 Support HTTP 1.1 Compression] when sending script files

Note that caching can also diminish the overhead for transfer of external script files, however as script files are collected into single packages, the efficiency of caching may diminish. So you should seek an optimum balance between script aggregation and cache efficiency..

5.5.7.1 What it means

Various design techniques can negatively impact battery life. These should be avoided and alternate techniques used where possible, to Use Power-Efficient Methods.

5.5.7.2 How to do it

Use script only for the dynamic aspects of the user interface. DOM manipulation and creation of new nodes can consume a lot of battery at the device side, so as much as possible create user interface elements using the markup language and modify (if needed) those elements using scripting. For example:

• When a page is first served from the server side, it should contain all the markup that declares and populates user interface elements (forms, selects, input, etc). If rich interactions are needed later then use scripting to mutate or modify the DOM of the page.
• Update existing elements for new content, instead of creating new high-level elements. Elements that must be added should be appended after the focus point as a parent of an existing element, instead of the document. For example, use an existing <div> element as the parent for new content, without removing/recreating the parent <div> itself. (from http://www.unc.edu/webaccess/training/ajax/ajax_best_practices.pdf)

Editor's note: This is a placeholder for input re the ETRI "seamless content mobility" input paper.

5.6.1.1 What it means

Users may have access to applications from both a deskop user-agent and mobile user-agents, e.g. as described in [ref to BP1 3.1 One Web].

5.6.1.2 How to do it

If available as a server feature, provide a synchronized (i.e. current) view of user data when a multi-device enabled application is accessed from a mobile device.

5.7.1.1 What it means

Use script for the dynamic aspects of the user interface

5.7.1.2 How to do it

Use script for the dynamic aspects of the user interface

5.7.2.1 What it means

The ECMAScript focus method can be used to move the focus to the part of a page that has changed, e.g. for automatically updating pages. If unexpected, this can confuse or irritate the user, especially if returning to the previous focus is not easy. It can also make an application unusable, if the focus changes prevent the user from using other parts of the application.

5.7.2.2 How to do it

Use the ECMAScript focus method only if it is essential to use of the application, and does not inhibit user control/interaction.

5.8.1.1 What it means

Standardized URI schemes (link formats) have been defined for some common device functions, e.g. making phone calls and managing phone address books. These URI schemes, if supported, can enable users to easily use these functions from Web applications.

5.8.1.2 How to do it

If you want the user to be able to easily take a device-specific action such as making a phone call to a number included in a web page, use URI schemes supported by the device. This will allow the user to take the action using a normal means, i.e. clicking a link.

5.9.1.1 What it means

For some of the best practices included here, support is dependent upon application awareness of related device capabilities. At the current time, this awareness is limited to application server use of device capabilities information provided by the user-agent directly, or obtained from a Device Description Repository (DDR) based upon device identification, e.g. based upon the user-agent header.

5.9.1.2 How to do it

Typically used methods of device capabilities detection:

• The "user-agent" header can be used to identify the device and/or user-agent, with detailed device capabilities then retrieved from a DDR.
• The "accept" header can be used to indicate specific MIME types compatible-to/preferred-by the user-agent.
• The "x-wap-profile" header (User Agent Profile or UAProf) can be used both as device identification and as a source for detailed device capabilities info.
• Retained information about the current/last used device for the specific user, can be used when preparing content for delivery to the user-agent at a later time.

The type of information used will depend upon the way in which the request was received, and the support for the methods, e.g. headers, by specific user-agents. For example:

• for requests received directly from the user-agent, based upon information from the user-agent directly or forwarded by intermediaries
• for requests received from other intermediaries, information as available from the intermediary, e.g.
  • for SMS-interworking gateways, the user's phone number

5.9.2.1 What it means

It can be tricky to determine the supported script capabilities for a device. Use of reliable methods is recommended.

5.9.2.2 How to do it

When it is unknown whether a user-agent supports Javascript, use Javascript reflection to check for available functionalities. This avoids the error-prone approach of trying to parse the user-agent string to determine Javascript support. An example of how to use Javascript reflection:

Use Javascript Reflection and if statements
+ if(window.ActiveXObject) {
// Instantiate using new ActiveXObject } else if(window.XMLHttpRequest) {
// Instantiate using new XMHttpRequest }

5.9.3.1 What it means

It can be complex to select and adapt content based upon dynamic assessmement of device capabilities. A commonly used alternate approach involves off-line assessment of devices with resulting assignment into "classes", e.g. "good", "better", "best". The definitions of the classes, and device assignment to classes, is typically Content Provider specific, i.e. based upon assessments specific to the needs of the Content Provider.

5.9.3.2 How to do it

Adapting Web application content and services to mobile devices may be simplified by assigning devices and user-agents (e.g. browsers or other Web applications as identified by the HTTP user-agent header, or other information) to "classes". The "richness" of the Web application as provided can then be more easily matched to the broad range of capabilities represented by the device class.

Device classification is partly subjective and partly objective. The aspects that affect the classification will vary depending upon the focus of the Web application, and the device/user-agent features it depends upon. Some example classes for web browsers may include:

• "Good": Serve these devices very basic pages. These devices are typically WAP1 or WML-only handsets with black and white screens. Ringtones are supported, but MIDP applications, wallpapers, and scripted applications are not. "Good" devices also include such color-screen WML phones on which pictures can be presented through the browser, and javascript applications can be emulated by web servers. Some devices in this category may claim xHTML support, but have slow processors, or the supported xHTML is incomplete.
• "Better": These devices have solid xHTML support with color screens, and support MIDP, graphics, and ringtones. However they do not support scripted applications.
• "Best": The "best" device category includes features from the "better" category plus streaming video capabilities, UMTS/HSDPA, and special audio clients. Scripted applications may be supported, but script support likely requires verification before use.

Once the device/user-agent is identified, the assigned class can be obtained from the DDR used by the Content Provider, and content then provided consistent with the assigned class.

5.9.4.1 What it means

Scripted applications, e.g. using asynchronous I/O methods or ECMAScript/Javascript in general, may not be supported by some browsers. Pages designed to use scripting will require alternate approaches in browsers that do not support scripting, so you should be prepared for that and provide similar functionality in case scripting is not available.

5.9.4.2 How to do it

Detect browser capabilities or user preferences, and react accordingly with graceful degradation or progressive enhancement of Javascript/ECMAScript.

Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured to degrade gracefully if ECMAScript/Javascript is not present or if advanced capabilities like asynchronous I/O (and other "AJAX" techniques) are not supported. Design targeting a mixed audience of mobile (where media="handheld") and desktop/laptop users should be structured to both degrade gracefully (if ECMAScript/Javascript is not present) and likewise to progressively enhance page- and user-behavior capabilities (if ECMAScript/Javascript does turn out to be present).

Separate behavior from content and presentation, for graceful degradation and progressive enhancement.

Good logical design separates XHTML content (the "data model"), CSS presentation (the "view"), and ECMAScript/Javascript behavior (the "controller"). Designers targeting purely desktop/laptop audiences (where media="screen") tend to duplicate this in the physical site structure, placing each in its own file and having pages issue an HTTP request for each separately through use of the <link/> or <script/> tags. Designers targeting purely mobile (where media="handheld") audiences tend to interleave the three concerns into one physical payload/file delivered to the client in order to reduce per-request charges.

Designers targeting a mixed audience of mobile and desktop/laptop users can build Web pages which load sufficient ECMAScript/Javascript (in the <head/> element) to determine device display and interaction capabilities when first loaded. This allows for progressive enhancement, just as good structural design of XHTML allows for graceful degradation.

Techniques similar to progressive enhancement of CSS (see 5.9.5) may also be used to inject event-handling Javascript/ECMAScript code into files at request-time and to attach Javascript/ECMAScript behaviors at run-time for progressive enhancement. In the example below, page-scope variables and functions are declared in a <script/> element in the <head/> while run-time test code for progressive enhancement is declared in a <script/> element in the <body/> element (to allow the DOM to be loaded before the code runs):

[NOTE to WG: see http://chw.rit.edu/test/progressiveEnhancement.html for complete code as running example]

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
  <meta http-equiv="content-type" 
          content="application/vnd.wap.xhtml+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
  <title>Javascript Insertion Test</title>
  <style type="text/css" media="all">
/* <![CDATA[ */
#testMe {
  border: thin solid red;
}
/* ]]> */
</style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
var someVariable; 
var triggerTest = 480; 
function actualValue() {
  [...]
  return someRuntimeValue;
}
function setSomeVariable( newValue ) {
  [...]
}
// ]]>
  </script>
</head>
<body>
  <p id="testMe">
    Please click on this area to test this scripting example.
  </p>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
function thisFunction() {
  [do something, possibly using someVariable] } if( actualValue() >= triggerTest ) {
  setSomeVariable( 'some new value' );
  document.getElementById( targetID ).onclick = thisFunction; 
} 
// ]]>
  </script>
</body>
</html>

5.9.5.1 What it means

CSS may be incompletely supported by some browsers. Pages using positioning and visibility control are not supported by some browsers.

Site design to support both desktop/laptop users and mobile device users will require alternate approaches for browsers that do not support positioning and visibility control. You should provide for both graceful degradation (in the case of no or minimal CSS support) and progressive enhancement (in the case of full positioning and visibility control support) of CSS by the client at run-time.

5.9.5.2 How to do it

Detect browser capabilities or user preferences and react accordingly.

Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured to degrade gracefully: first if ECMAScript/Javascript is not present, and then if CSS is not supported. Design targeting a mixed audience of mobile (where media="handheld") and desktop/laptop users should be structured to also progressively enhance CSS. Advanced CSS capabilities should be separated from basic CSS, and inserted into the DOM by the client as appropriate at run-time.

Separate behavior from content and presentation, for graceful degradation and progressive enhancement.

Designers targeting a mixed audience of mobile and desktop/laptop users can build Web pages which load (using the <style/> tag in the <head> element) CSS for mobile audiences and (using the <script/> tag in the <head> element) sufficient ECMAScript/Javascript to determine device display and interaction capabilities first. This allows for progressive enhancement, just as good structural design of XHTML allows for graceful degradation.

The following example code illustrates a possible request-time payload aimed at a mixed mobile and desktop/laptop audience. In this case, if ECMAScript/ Javascript is present and if the screen-width is determined to exceed a minimum, then the display device is assumed to be a desktop/laptop (where per-download charges are unlikely to apply), an additional stylesheet is requested, and ithe new stylesheet is inserted into the DOM:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
  <meta http-equiv="content-type" 
      content="application/vnd.wap.xhtml+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
  <title>Example Payload for Progressive Enhancement</title>
  <style type="text/css" media="all">
/*
<![CDATA[ */
                         [put initial CSS here]
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
var triggerWidth = 480; 
function appendStylesheet( uriString, mediaTypeTarget ) {
                         [inject stylesheet into DOM here] 
} 
function getViewportWidth() {
                         [determine viewportWidth here] } 
function adaptToScreen( uriString ) {
  if ( getViewportWidth() >= triggerWidth ) {
    appendStylesheet( uriString, 'screen' );
  }
}
// ]]>
  </script>
</head>
<body onload="adaptToScreen( './stylesheets/bigScreen.css' );">
  [...]

In the above case, the base-CSS for mobile users is delivered along with ECMAScript/Javascript to determine client capabilities as a result of the initial request. Subsequent requests for CSS (and possibly other resources) allow for progressive enhancement where determined appropriate by client-side code.

Good physical design can take advantage of just-in-time technologies like "server-side includes" to assemble the above payload on demand, resulting in the <style/> and <script/> nodes being inserted at request-time. The following code in an HTML file would cause the server to insert (as above) site-wide <style/> and <script/> nodes at request-time in the payload actually being delivered at response-time:

[... replace style and script elements with:]
  <style type="text/css" media="all">
/*
<![CDATA[ */
<!--#include virtual="./stylesheets/content.css" --> 
<!--#include virtual="./stylesheets/tabNav.css" -->
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
<!--#include virtual="./javascripts/appendStylesheet.js" --> 
// ]]>
  </script>
[...]

Separating logical and physical design like this helps reduce site-wide maintenance costs and site-redesign difficulties as well as supporting graceful degradation and progressive enhancement of CSS.

[It may not be necessary to address this specifically, as our current approach is that if a best practice is useful, it is useful regardless of the runtime environment the application is executing under.]

The Best Practice statements are intended to be capable of having conformance statements constructed around them in support of the mobileOK trustmark and for other purposes. Work on the mobileOK trustmark will develop specific recommended requirements for a trustmark, which will be based on some profile, or subset, of the statements in this document.

As such, the mobileOK trustmark will serve as the main conformance claim for the Best Practices document.

All of the Best Practice statements have a fragment identifier to allow formal reference to them and allow the construction of compliance claims that refer to them.

This specification applies to one class of product: content delivered to a mobile device, including the metadata transferred as part of the delivery protocol.

This specification may be compatible with other specifications that describe a different set of requirements for content, insofar as such requirements do not conflict with the current specification.

[To include the set of minimum device properties supporting specific best practices.]

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

• to be added

While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.

Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.

• to be added

D.1 MWI References

D.2 Sources

D.3 Device Independence