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:

1. Introduction. Describes the audience, purpose and scope of the document.

2. Requirements. An illustration of the type of problems that the Best Practices are intended to address.

3. Delivery Context. Discusses the environment within which mobile access to Web applications is realized, with particular reference to adaptation.

4. Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.

5. Best Practices. The statements themselves.

6. Conformance. A brief conformance statement.

7. Appendices

   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.

Personalization increases the value of content and services to users, which is important in the mobile environment due to the extra effort necessary to find relevant content, interact with applications, and the limited output possible in mobile devices. In the PC environment, users have a variety of useful/easy input methods and controls making it easier to input personalizing information and surf to the content they want, and can more easily scan a large amount of content for the bits that are relevant to them. Each of these aspects are more limited, and thus more difficult to address in the mobile environment. The overall goal for personalization in the mobile context is to use user-friendly methods.

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 this also applies for PC based applications, for mobile applications additional options are typically available for access to trusted personalizing information, and the efficiency of methods for personal information security need to be more carefully considered. 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 sensitive functions, i.e. that may affect the service experience, and is offered some options for user control.

HTTP cookies and redirection 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.

As compared to their use for web browser applications, cookies and redirect may play less of a role in maintaining statefulness and personalization for for web applications in general. Application-specific methods may be used, and may include use of more advanced technologies that are not available to some browsers. 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.

In mobile networks, 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. The overall goal is that users are informed of the potential impact of application operation, and that regardless of the user's service plan, applications use network resources conservatively.

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.

As addressed in BP1, the basic aspects of delivery context in the mobile environment, and how awareness of delivery context relates to the goal of the "one web", also apply to web applications in general.

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 the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile Widgets

Audience of BP2 document will include CPs as well as Ajax and other toolkit developers.

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.

What to Test

The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. This section is not present for process related statements.

In this section it is noted whether the statement is Machine Testable (Automated testing is possible) or Human Testable (Testing requires human assessment). Some Best Practices are partially machine testable, i.e. based on the result of an automated test, some human interaction may be required. In such cases both a Machine Testable and a Human Testable statement are present.

Some Best Practice statements use words such as "minimize" and "avoid" which are intentionally non-prescriptive. This is in order to provide guidance while leaving room to accommodate a wide variety of applications whose requirements cannot be anticipated. It also allows creativity and diversity within the same Best Practice framework.

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 manual entry of information should retain that information to avoid the need to re-enter it upon each site access, over a 24-hour period at least. 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 or URL parameters), in server-side databases, etc.

5.1.3.1 What it means

If the user must be asked to enter account information, personalized services should simplify what they have to enter. Users are likely to quit using services that ask for too much manual information entry, especially if obviously simpler forms of entry are not provided.

5.1.3.2 How to do it

Various techniques can simplify user information input, e.g.:

• require only entry of variable information, e.g. if an email address domain can be assumed, require only the username, and don't require the user to enter "@domain".
• provide well-known options as radio buttons, rather than requiring the user to type them
• allow abbreviations, e.g. of locations

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

Public user identities should only be exchanged between user-agent and content server using secure methods, e.g. HTTPS, or as securely hashed information through a strong secure hash algorithm. To avoid the overhead of using HTTPS for all transactions, a related pseudo-identity or secure hash of the actual identity can be exchanged in non-secure transactions.

Since information is not personally identifiable unless it can be associated with an individual, e.g. a zip code which is by itself not personally identifiable, such information can be exchanged in the clear if the correlating information is itself secure, e.g. as a securely hashed identifier. As long as an application meets the basic objective that user identities are protected during exchange, other information can be exchanged in the clear.

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 internet for 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

Users should be informed of impacts to device memory (for application code and data) due to installation and use of applications. Because mobile devices typically are memory-constrained, the effect of application installation and use can be much more significant than in other devices.

5.3.2.2 How to do it

The following information should be disclosed:

• the installed size of the application
• the percentage of free device memory consumed by the installation, and the amount of free device memory left after installation
• the typical/maximum amount of device memory to be used for application data

5.3.3.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.3.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.4.1 What it means

Disclosures about application behavior are useful only if they are provided at a useful time and in useful ways. A non-useful disclosure is practically a non-disclosure.

5.3.4.2 How to do it

Disclosures should be provided during application selection, install, on first runtime, 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.5.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.5.2 How to do it

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

• Configure automatic operations, e.g. content update schedules
• Manage data memory use
• Select privacy/security options

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

User-agent redirect 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 supported method of transfer encoding for delivery optimization, and is most useful for text-based content e.g. markup languages and documents. Typical performance for HTTP compression use is 5:1 compression ratio for web pages, which also translates into a 5x latency improvement. 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 should not create network traffic unless there is a particular valuable reason for it. The "value" in this case should be determined by the application based upon the type of service it provides, and the resulting direct value to the user. 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.
• 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..

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

[Placeholder for guidance on building device classes and assigning devices to them]

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.

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

[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.]

[Address device classification as a common practice through examples of classes and related characteristics.]

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.

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