W3C

Mobile Web Application Best Practices

Editors' Draft 01 January 2009

This version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090101
Latest version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest
Previous version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081215 (diff)
Editors:
Bryan Sullivan, AT&T
Adam Connors, Google

Abstract

This document specifies Best Practices for the development and delivery of Web applications on mobile devices. The recommendations expand upon statements made in the Mobile Web Best Practices 1.0 (BP1), especially concerning statements that relate to the exploitation of device capabilities and awareness of the delivery context. Furthermore, since BP1 was written, networks and devices have continued to evolve, with the result that a number of Best Practices that were omitted from BP1 can now be included.

The recommendation is primarily directed at creators, maintainers and operators of Web applications. Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers, HTTP, and Web application technologies. Readers are not expected to have a background in mobile technologies or previous experience with BP1.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Incomplete draft: This document is an editors' copy that has no official standing. It is subject to major changes and is therefore not intended for implementation. In particular, the list of Best Practices is not settled yet. The document is provided for review and feedback only. Please send feedback to public-bpwg-comments@w3.org (archive).

The Working Group is particularly seeking feedback on:

This document was developed by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Most of the best practices statements were changed since the publication of the First Public Working Draft on 29 July 2008. A complete list of changes is available.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is a Second Public Working Draft intended to progress along the Recommendation track and be eventually published as a Recommendation.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

@@requires revision

1 Introduction
1.1 Purpose of the Document
1.2 Audience
1.3 Scope
1.3.1 Best Practices
1.3.2 Web Application
1.3.3 Mobile Context
1.3.4 Delivery Context
1.4 Relationship to other Best Practices and recommendations
1.5 Terminology
2 Structure of Best Practice Statements
3 Best Practice Statements
3.1 Personalization
3.1.1 Retain Information For Personalization
3.1.2 Automatically Identify the User
3.2 Security and privacy
3.2.1 Use HTTPS when Exchanging User Credentials
3.2.2 Secure JSON Data feeds
3.2.3 Use a Safe EVAL for JSON Data feeds
3.3 User awareness and control
3.3.1 Inform the User About Automatic Network Access
3.3.2 Provide Sufficient Means to Control Automatic Network Access
3.3.3 Ensure the User is Informed About Use of Personal and Device Information
3.4 Conservative use of resources
3.4.1 Use Transfer Compression
3.4.2 Minimize Application Size
3.4.3 Avoid Redirects
3.4.4 Minimize Automatically Issued Network Requests
3.4.5 Use Push Methods to Reduce Pull Traffic
3.4.6 Minimize External Resources
3.4.7 Consider Inlining Small Stylesheets and Script Resources
3.4.8 Sprite Static Images into a Single Resource
3.4.9 Inline Background Images in CSS Stylesheet
3.4.10 Use Fingerprinting to Cache Dynamic Resources
3.4.11 Make AJAX Datafeeds Cachable
3.4.12 Use Power-Efficient Methods
3.4.13 Minimize DOM Manipulation
3.4.14 Reduce Cookie Size
3.4.15 Don't Send Cookie Information Unnecessarily
3.4.16 Use JSON in favour of XML for Datafeeds
3.5 User Experience
3.5.1 Design for Multiple Interaction Methods
3.5.2 Use Scripting to Improve Perceived Performance
3.5.3 Preserve Focus on Dynamic Page Updates
3.5.4 Group Closely Coupled Views
3.5.5 Use Fragment IDs for Application Views
3.5.6 Make Telephone Numbers Clickable
3.5.7 Ensure Paragraph Text Flows
3.5.8 Separate Rarely Used Functionality
3.5.9 Enable Progressive Rendering
3.5.10 Ensure Consistency Between Desktop and Mobile
3.6 Handling Device Capability Variation
3.6.1 Use Server-side Capability Detection
3.6.2 Use Client-side Capability Detection for Dynamic Device State
3.6.3 Use Device Classification to Simplify Content Adaptation
3.6.4 Support a non-JavaScript Variant if Possible
3.6.5 Offer Users a Choice of Interfaces
3.7 SVG
3.7.1 Use SVG Tiny 1.1 Compatible Content
3.7.2 Minimize Size and Complexity of Content
3.7.3 Test on Target Devices
3.7.4 Make Use of Language Features to Write Compact Code

Appendices

A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
D.1 MWI References
D.2 Sources
D.3 Device Independence
D.4 Web, Protocols and Languages
D.5 Other References


List of Best Practices

The following Best Practices are discussed in this document and listed here for convenience.

@@TODO

1 Introduction

1.1 Purpose of the Document

This document sets out a series of recommendations designed to facilitate development and delivery of Web applications on mobile devices. The recommendations are offered to creators, maintainers and operators of mobile Web sites.

1.2 Audience

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, but are not expected to have a background in mobile technologies or previous experience with Mobile Web Best Practices 1.0 (BP1).

The intention is to make 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 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. Some Best Practices, however, clearly have a more technical focus Well, since we are about to say that they can safely be ignored, perhaps we should be clear about which ones, precisely. . These are likely to be of interest only to developers interesting in building highly optimized / advanced mobile Web applications and can be safely ignored by other disciplines.

1.3 Scope

These recommendations expand on the recommendations of the Mobile Web Best Practices (BP1) [ref]. Where the focus of BP1 is primarily the extension of Web browsing to mobile devices, this document considers the development of Web applications on mobile devices.

1.3.1 Best Practices

The approach in writing this document has been to collate and present the most relevant engineering practices prevalent in the development community today and identify those that: a) facilitate the exploitation of device capabilities to enable a better user experience; or b) are considered harmful and can have non-obvious detrimental effects on the overall quality of the application.

The goal of this document is not to invent or endorse future technologies. However, there are a number of cases where explicitly omitting a Best Practice that referred to an emerging technology on the grounds that it was too recent to have received wide adoption would have unnecessarily excluded a valuable recommendation. As such, some Best Practices have been included on the grounds that the Working Group believes that they will soon become fully qualified Best Practices (e.g. in prevalent use within the development community).

1.3.2 Web Application

For the purposes of this document, the term "Web application" refers to a Web page (XHTML or a variant thereof + CSS) or collection of Web pages delivered over HTTP which use either server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser. Web applications are distinct from simple Web content (the focus of BP1) in that they include some elements of interactivity and persistent state.

While the focus of this document is to document Best Practices that apply to applications running in a Web browser, in many cases these recommendations are equally applicable to other kinds of Web run-time, such as the widget frameworks being considered as part of the Web Widgets [REF] [@@ref needed] effort and also in a number of vendor-specific initiatives.

1.3.3 Mobile Context

In an increasingly mobilized world the line between mobile and non-mobile is necessarily blurred and a document that restricts its focus solely to best practices that are uniquely mobile would most likely be very short. With this in mind, the focus of this document is to address those aspects of Web application development for which there are additional, non-trivial concerns associated with the mobile context. This applies equally both to the limitations of the mobile context (e.g. small screen, poor connectivity), and also the additional scope and features that must be considered when developing for the mobile context (e.g. device context / location, presence of personal data on the device, etc).

1.3.4 Delivery Context

Requirements on delivery context have not been made explicitly, but most best practices assume devices with basic XHTML, JavaScript, and CSS compliance. Additionally, some best practices are relevant only if the device exposes certain capabilities (for example, access to device information such as location).

Implied by this discussion is that some level of device knowledge and content adaptation is required. For best practices specifically related to this area, see 3.6.1 Use Server-side Capability Detection for Device Properties and 3.6.2 Use Client-side Capability Detection for Device State.

1.4 Relationship to other Best Practices and recommendations

These recommendations are complimentary to the recommendations of Mobile Web Best Practices 1.0 (BP1).

This document builds on some of the concepts described by the Ubiquitous Web Applications Working Group (UWA) and the Device Independence Principles [DIP]. The document discusses device and delivery channel characteristics, which the UWA has named "Delivery Context" [DCODI]. In addition, the document uses some terminology from UWA's Glossary of Terms for Device Independence [DIGLOSS].

1.5 Terminology

Note that the term "JavaScript" is used in place of the (arguably more correct) term "ECMAScript" in order to provide consistency with the companion Web application technologies (JSON and AJAX) which are in common use and both implicitly refer to JavaScript in their names.

Also, the terms "AJAX" and XMLHttpRequest (XHR) are used to refer to any asynchronous browser request. The implicit reference to XML suggested by the names is commonly accepted to be an historical anomaly.

2 Structure of Best Practice Statements

The Heading
A summary of the functional area to be addressed by these 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 intention of the Best Practice statement.
How to do it
A discussion of the techniques and device capabilities required to implement this Best Practice.

3 Best Practice Statements

3.1 Personalization

This section elaborates on the recommendations of BP1 Section 5.5 which details ways to minimize the amount of user input required.

Given the typical input limitations of a mobile device, input of data can require special effort by the user. Reuse of relevant information about the user can eliminate unnecessary user interaction and hence improve the user experience.

3.1.1 Retain Information For Personalization

3.1.1.1 What it means

If an application requires information entered by a user (e.g. application preferences, personal details) that information should not normally have to be reentered either in the course of using the application or between invocations of the application.

3.1.1.2 How to do it

A number of technologies can be used to persist user entered information. Consider using a combination of techniques:

Server Based Session Management:
Session management is a feature of many server frameworks (e.g. need examples PHP, .net etc.). Requests belonging to the same session are typically identified using cookies or URI decoration.
JavaScript Variables:
JavaScript object state can be used as a temporary data store provided the page is not reloaded. Note, however, that the JavaScript run-time is not guaranteed to remain in memory if the application is placed in the background, and so JavaScript state should be used only for short-lived and volatile data.I think this needs a deal more explanation if it is helpful. Are we saying "use javascript variables as variables, but don't use them for persistent data storage?"
Hidden Form Elements:
Within a session, state can be preserved between pages by storing information in hidden form elements, e.g: <input type="hidden" name="some_data" value="some_previously_entered_value"/>.
Cookies:
When supported and active, cookies are a common and effective means to store state on the client. Be aware, however, that cookie data is exchanged with the server on every request and can impact performance. See 3.4.14 Reduce Cookie Size for more details. Also see BP1 [COOKIES] Do not rely on cookies being available for more detail.
Unique URI:
Each user can be allocated a specific URI. On first use of the application, users should be prompted to bookmark this unique URI and to use it when subsequently invoking the application.
HTML5 Local Storage API:
If supported, the HTML5 Local Storage API can be used to store application data on the device. It can be used for more extensive and structured data than Cookies and URIs. See Offline Web Applications for more details.
Server Based Data Store:
Extensive personalization data and state that is required across sessions should be stored in a server-side data store. A server based data store is the only way to facilitate the sharing of state across multiple devices. (Surely this is over-stated?)See 3.5.10 Ensure Consistency Between Desktop and Mobile for more details.

3.1.2 Automatically Identify the User

Why isn't this part of the previous section? What we are trying to say here is a) reduce the effort for the user to identify themselves and b) once they have, retain the information they provided. Both within a session and across sessions where possible. Anyway, I think a re-write would make it clearer.

3.1.2.1 What it means

Ensure that personalization information is available to the user with minimal effort by using their identity to automatically restore application preferences.

3.1.2.2 How to do it

Service Providers (e.g. Mobile Network Operators or Web Portal Providers) or an Identity Management Provider like what? may provide means to access trusted what is the distinction we are making by saying "trusted" need to spell this out if the distinction is materialuser identities automatically. This has the advantage of removing the need for the user to enter their identity at all and will provide an optimal experience.

Alternatively, the simplest way to identify the user is to prompt for login credentials on first access and store a Hashed identity token in a cookie for future accesses. Recommended methods for doing this Needs clarification as to what is meant? identify user? simplify invocation of the application? collect credentials on application invocation? Also these sections are somewhat repetitious of each other. include:

3.2 Security and privacy

Use trusted information, and protect all personally identifiable information.

3.2.1 Use HTTPS when Exchanging User Credentials

3.2.1.1 What it means

Although HTTPS is the most common means to secure personally identifiable information, the overhead of using it can be significant over a mobile network. As such, HTTPS should not be used unnecessarily, and the level of security should be matched to the level of sensitivity of the information being exchanged.

Personally identifiable information (e.g. user identity or information usable as a key to user identity) should only be accepted or sent securely. Less sensitive information that cannot be associated with an individual (e.g. a ZIP code by itself is not personally identifiable) does not need to use HTTPS provided the correlating information is secure. I don't think I understand what this is telling me to do, one way or the other. What is correlating information?

3.2.1.2 How to do it

HTTPS is the most secure way to exchange sensitive information such as user-identity. 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.

HTTPS should always be used to exchange the initial user credentials, but subsequent requests need not use HTTPS provided the user identity is exchanged in the form of a Hashed Identity Token.

The working group is looking for feedback on the validity of this Best Practice. Whilst it is a true reflection of techniques commonly in use, it risks exposing the Hashed credentials in the network proxies and might pose an unacceptable security risk.

3.2.2 Secure JSON Data Feeds

3.2.2.1 What it means

A common paradigm in Web applications is to provide a data feed to an JavaScript based Web client in the form of an executable JavaScript string (e.g. JSON). Surely, strictly speaking, JSON (RFC 4627) - being a data representation format, is not executable? Should we not be clearer about this?This has many advantages in terms of speed of execution and ease of development, but it represents a significant security flaw which can expose user data to malicious Web sites.

If a JSON data feed is executable, a malicious Web site can reference it in a <script> element. This will execute the data feed using the cookies associated with the data providing site and in most cases generate a JavaScript object model in the client which can be accessed by the malicious site. Perhaps I am being feeble minded, but I think this could be spelled out a bit more to clarify what the vulnerability is?

3.2.2.2 How to do it

The JavaScript data feed should be protected by a prefix that will prevent execution directly, but which can be stripped off prior to execution when accessed by an XHR request.

Insecure JSON feed:
      { username: "My Name", 
	contacts: [ 
	{name: "Contact1", phonenumber: "xx-xxx-xxxx"}, 
	{name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }

Secure JSON feed:
      while(1); { username: "My Name", 
	contacts: [ 
	{name: "Contact1", phonenumber: "xx-xxx-xxxx"}, 
	{name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }

3.2.3 Use a Safe eval for JSON Data Feeds

The whole of this needs a bit more clarity in my view - should we not be distinguishing between incorrect data, incorrectly formatted data and malicious data? Should we not be a little clearer as to what the risk is that a user might enter a code fragment as data and what effect that would have on other users? Are we actually saying "use a JSON parser, don't use eval"?

3.2.3.1 What it means

If a JSON data feed is being parsed using the eval(); method it is vulnerable to script attacks. For example, if the feed contains user entered data this data might replicate the JSON syntax in order to compromise the application.

3.2.3.2 How to do it

There are a number of steps which can be used to protect against this kind of attack, use the one most appropriate to the context:

The working group is looking for feedback on an example "Safe eval" algorithm that can be shared here, or a publicly available library that can be referenced.

3.3 User Awareness and Control

Ensure that the user is aware of otherwise invisible application actions, and offer options to control those actions.

Browsers may have access to information such as:

Many browsers support the ability to make background server requests (i.e. requests that do not require action by the user). Unless specific action is taken to provide information about such activity, users may be exposed to revealing information that they did not intend to reveal and may be subject to unexpected data charges.

3.3.1 Inform the User About Automatic Network Access

3.3.1.1 What it means

Whenever an application makes background data requests, whether automatic or user-initiated if it is a background request it is not user initiated, surely?, this should be indicated to the user in an appropriate manner.

3.3.1.2 How to do it

Applications should disclose how they use network resources. A simple icon indicating background activity is usually sufficient and does not interrupt the flow of the application. If extensive background network activity is required the user should be informed when they first visit the site, when they first log-in, or in associated help pages.

The kinds of detailed information that could be disclosed in associated help pages or terms of service are:

3.3.2 Provide Sufficient Means to Control Automatic Network Access

3.3.2.1 What it means

If an application makes automatic network requests (e.g. to poll the server for updates or to automatically store an updated client state) a means to control this activity must be provided.

3.3.2.2 How to do it

All applications that access the network automatically must provide a means for the user to disable automatic network activity. When automatic network activity is disabled, periodically prompt the user to make network requests.

Consider allowing the user to adjust the polling schedule and to control which activities are allowed to initiate network requests.

3.3.3 Ensure the User is Informed About Use of Personal and Device Information

3.3.3.1 What it means

Ensure that the user is informed if the application needs to access personal or device information. The user should be informed of the types of information that will be used by the application and how that data will be exchanged with the server.

3.3.3.2 How to do it

In many cases use of APIs that provide access to personal or device information causes a confirmation dialog to be presented to the user. In this case the application should not force the user to confirm again at the application level, but should make clear in the UI that displayed data has been accessed from the device. Need example of how to do this? and how should it know that a confirmation dialog is or is not presented?

If the user declines a prompt to allow application access to personal or device information, the application must recover gracefully. For example, if a request to a device API fails, do not automatically retry if this will lead to the user being presented with repeated confirmation dialogues by the underlying API.

3.4 Conservative use of resources

Resources, such as device memory, processor power, and network bandwidth are significantly more limited on mobile devices than on the desktop. The most effective way to ensure that applications run smoothly and with low latency is to take steps to ensure minimal use of resources.

3.4.1 Use Transfer Compression

3.4.1.1 What it means

Compress content for efficient delivery.

3.4.1.2 How to do it

HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms is widely supported. Web servers should be configured to serve appropriately compressed responses.

Note however, that the cost (in time and battery usage) of decompressing data should be balanced against the gains in transport efficiency.When configuring HTTP 1.1 compression note that:

3.4.1.3 Maximizing Compression Efficiency

Compression of HTML and CSS files can be made more efficient by ensuring consistency in the code. I remain sceptical about this. It's all going to be in lower case anyway, if it is valid XHTML and ordering of attributes etc seems a bit whimsical to me. For example:

3.4.2 Minimize Application Size

3.4.2.1 What it means

This section elaborates on the Best Practices of BP1 (MINIMIZE). Smaller applications will download and execute more quickly and more reliably than larger ones on constrained devices.

3.4.2.2 How to do it

Process HTML, JavaScript and CSS files to remove whitespace and minify before delivery. A number of open source whitespace strippers and JavaScript compilers are available.

The working group is seeking recommendations for the best / most-commonly used tools to reference in this section.

3.4.3 Avoid Redirects

3.4.3.1 What it means

Request redirection (through HTTP response header or meta refresh) is typically used to exchange information between servers (e.g. account authentication). The delay incurred by redirects is much higher over mobile networks and so the number of redirects should be kept to a minimum to avoid degrading the user experience.

3.4.3.2 How to do it

Try not to use more than two redirects for any request. If further redirects are required, use an interstitial page to communicate to the user that the application is still working.

3.4.4 Minimize Automatically Issued Network Requests

3.4.4.1 What it means

Applications that automatically issue network requests should provide "value" for those requests so as not to unnecessarily impact battery life and application performance. Take care to ensure network requests are as well optimized as possible It's not clear what this means.

3.4.4.2 How to do it

Consider the following possibilities when designing an application:

Batching requests:
A single request for more data is considerably more efficient than several smaller requests. Wherever possible, batch up multiple requests at the application level.
Back off during periods of inactivity:
If the application polls for updates, it should monitor user activity and poll less frequently during inactive periods.
Device Context:
If supported by the device, use awareness of current connectivity (e.g. WiFi) to select an appropriate level of interaction.

3.4.5 Use Push Methods to Reduce Pull Traffic

3.4.5.1 What it means

Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods.

3.4.5.2 How to do it

Push method support may be disclosed through a User Agent Profile document if published by the device vendor, or through other device classification repositories.

If supported by the user agent, options for Push methods include:

3.4.6 Minimize External Resources

3.4.6.1 What it means

A Web application typically requires a number of resources (style sheets, scripts, image, etc) each of which may incur an additional HTTP Request. HTTP round trips are particularly expensive on a mobile network and so fewer, larger requests should be favoured over a larger number of smaller requests.

3.4.6.2 How to do it

As far as makes sense after taking into account 3.5.8 Separate Rarely Used Functionality combine all style sheets into a single resource and all scripts into a single resource. If multiple scripts and style sheets are required as part of the authoring process, then try to arrange that they are merged before the page is served.

3.4.7 Consider Including Small Style Sheets and Script Resources In-Line

3.4.7.1 What it means

In some circumstances performance is improved if JavaScript and CSS style sheet resources are included in the HTML page, eliminating the need for additional HTTP requests to fetch the external files.

3.4.7.2 How to do it

Whether in-line resources make sense or not depends on a number of factors. For example:

3.4.8 Aggregate Static Images ("Sprites") into a Single Composite Resource

3.4.8.1 What it means

Web applications often depend on a number of static images to provide icons, buttons, etc. If served as a separate image each one incurs an additional HTTP round-trip which is detrimental to performance when compared with combining them into a single image for transfer.

3.4.8.2 How to do it

To optimize efficiency:

To render individual components of a resource use CSS positioning and clipping.

3.4.9 Include Background Images In-Line in CSS Style Sheets

3.4.9.1 What it means

Background images are often used as gradients to improve the look and feel of an application. These can be included in the CSS as base64 encoded strings in order to avoid an additional HTTP round trip but at the expense of the loss of compression that base 64 implies, so what is the trade-off?.

3.4.9.2 How to do it

Background images can be encoded using the data URI scheme: url('data:image/png;base64, [data])

3.4.10 Use Fingerprinting to Cache Dynamic Resources

3.4.10.1. What it means

Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by identifying them with a URI that includes a fingerprint of the resource content. Using this technique means that the browser does not need to check the resource headers in order to validate its cache, instead, any change in the resource will lead naturally to a corresponding change in the resource reference.

3.4.10.2 How to do it

3.4.11 Cache AJAX Data

3.4.11.1 What it means

Data designed to be accessed by AJAX requests from the client should be cached in the same way as primary content.

3.4.11.2 How to do it

The standard caching techniques (Expires header and Cache-Control header), as well as resource fingerprinting can be used on AJAX data as readily as primary content pages.

3.4.12 Use Power-Efficient Methods

3.4.12.1 What it means

A Web application may not be suspended if it is placed in background. Consider the impact of on-going JavaScript operations on battery life.

3.4.12.2 How to do it

The working group is currently investigating the relative impacts of Web application activities on battery life in order to make more concrete recommendations.

3.4.13 Minimize DOM Manipulation

3.4.13.1 What it means

On small devices with limited processing capability, the cost of excessive DOM manipulation can impact application performance perhaps we can be either more specific (what does excessive DOM manipulation mean?) or considerably more terse here (e.g. DOM manipulation is costly).

3.4.13.2 How to do it

Only use DOM manipulation for dynamic parts of the page. The static framework of the page is best created using HTML markup which can then be connected to the script using the element ID attribute. I'm not sure I quite get the point. Static parts of the page don't get manipulated and hence are not costly. Dynamic parts do get manipulated and hence have a cost. So what are we encouraging people to do, and what are we encouraging them not to do.

3.4.14 Reduce Cookie Size

3.4.14.1 What it means

Information stored in cookies is exchanged I'm not sure it is actually "exchanged" ... sent, certainly (several uses of "exchanged" in document) between the server and the client for every request, which can negatively impact performance.

3.4.14.2 How to do it

Use cookies sparingly, and consider alternative methods (see 3.1 Personalization) for anything other than trivial amounts of data.

3.4.15 Don't Send Cookie Information Unnecessarily

3.4.15.1 What it means

Static resources don't need cookie information and so performance can be improved by serving these from a path or sub-domain for which the application's cookies are out of scope.

3.4.15.2 How to do it

Use a different domain, sub-domain, or path name for static resources to the main application, and restrict the valid path of cookies such that they will not be exchanged when they are not needed (e.g. ??).

3.4.16 Use JSON for Data Feeds

3.4.16.1 What it means

Asynchronous data can be delivered to the client in response to an XHR request in any form (HTML markup, proprietary format, XML, or JSON object model). Use JSON rather than XML if possible.

3.4.16.2 How to do it

JSON data can be built using an open source JSON builder (REF). On the client, JSON is readily parsed into a JavaScript object model using the eval method. Note, however, that care should be taken to observe: 3.2.2 Secure JSON Data Feeds and 3.2.3 Use a Safe eval for JSON Data Feeds.

3.5 User Experience

Given the additional complexities of interacting with an application on a mobile device, special consideration should be given to the overall user experience. User experience is influenced by a number of factors, including: perceived latency, interaction method, and data consistency.I think we should move the personalization stuff down here and merge it.

3.5.1 Design for Multiple Interaction Methods

3.5.1.1 What it means

Interaction methods vary across different devices. Three main interaction methods should be considered:

Devices may implement one or more of these approaches and it is important for an application to remain usable in all cases.

3.5.1.2 How to do it

Particularly where content requires multiple links (ie back/forward in carousel)what are we trying to say here? or where the user's interaction with links is designed to give them feedback and here?, the following factors should be considered:

Focus Based:

Pointer Based:

Touch Based:

3.5.2 Use Scripting to Improve Perceived Performance

3.5.2.1 What it means

Using script for dynamic parts of the page means that the view can be updated without a full page reload. Since reloading the entire page can be slow this can greatly improve application usability.

3.5.2.2 How to do it

Use asynchronous (XHR) requests to get additional information from the server in response to user events and update the page DOM to convey this to the user.

3.5.3 Preserve Focus on Dynamic Page Updates

3.5.3.1 What it means

The JavaScript focus method can be used to move the focus to the part of a page that has changed. However, if unexpected, this can confuse or irritate the user, especially if returning to the previous focus is not easy.

3.5.3.2 How to do it

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

3.5.4 Group Closely Coupled Views

3.5.4.1 What it means

Most applications consist of a number of views (e.g. an email application consists of an inbox and the message detail view). User experience is improved if switching between these views does not require a request to the server.

3.5.4.2 How to do it

Each view can be rendered in a div element which is hidden using CSS. JavaScript can be used to reveal content in response to user events.

3.5.5 Use Fragment IDs for Application Views

3.5.5.1 What it means

Web applications can show multiple views by showing and hiding content. However, this means it is not automatically possible to link directly to these views and the browser <back> button cannot be used to move between previous views. Usability is enhanced by enabling both of these features:

3.5.5.2 How to do it

Each view within an application should have a URI with a distinguishing fragment identifier (e.g. http://myapp.example.org/myapp#view) and JavaScript used to interrogate the browser location in order to determine which view to display.

3.5.6 Make Telephone Numbers "Click-to-Call"

3.5.6.1 What it means

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

3.5.6.2 How to do it

The most broadly supported scheme is tel: as described in [RFC3966]. Code such as the following can be used to enable "Click-to-Call":

<a href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>

3.5.7 Ensure Paragraph Text Flows

3.5.7.1 What it means

On small screens it is important that paragraph text flows to fill all the available space. Fixed paragraph widths (even when optimized for the device screen) are error prone, make it harder to support multiple device formats, and will not support multiple orientations (e.g. landscape and portrait mode).see BP1 Measures http://www.w3.org/TR/mobile-bp/#measures in fact, in what way is this different to that BP? And btw, ref the following, note that px is not an absolute measure :-)

3.5.7.2 How to do it

Specify widths for elements containing paragraph text as a percentage (style="width:100%") in favour of using an absolute size (style="width:660px") since use of the style attribute is "deprecated" perhaps these examples should be re-written.

3.5.8 Separate Rarely Used Functionality

3.5.8.1 What it means

Perceived performance can be improved by separating out JavaScript functions and CSS styles that are not required by the initial page. JavaScript functions and CSS styles associated with rarely used features should be bundled separately and downloaded only if those features are accessed.

3.5.8.2 How to do it

Consider what functionality is being downloaded in a given script resource and how likely that functionality is to be used in the majority of requests. If some functionality is rarely used, it may make sense to partition this into a separate script to be loaded on demand. On-demand loading can be accomplished by:

The working group is seeking feedback on this Best Practice. Whilst it contains value for very large / complex applications, the implementation of this technique and its support across even high-end devices is not clear. Specifically, IFRAMEs are known to have significant issues on many devices and so we are looking for validation that their use in this context is a good idea.

3.5.9 Enable Progressive Rendering

3.5.9.1 What it means

Progressive rendering means that the page will be displayed incrementally as it loads. In most cases this results in an improved perceived latency since content is available earlier.

3.5.9.2 How to do it

Place CSS style sheet (<style>) elements in the <head> head element at the top of the document according to HMTL style elements cannot occur anywhere else :-) and what do we want to say about link rel=stylesheet? and JavaScript (<script>) elements at the bottom of the document. Browsers will not progressively render a page until the stylesheet has been loaded and will block while JavaScript content is parsed.

3.5.10 Ensure Consistency Between Desktop and Mobile

3.5.10.1 What it means

This recommendation builds on the recommendation in BP1 (5.5.1 Thematic Consistency) and expands it to consider the application preferences and personalization data that form part of the overall experience on a mobile Web application.

User credentials valid on one device should be valid on other devices. User preferences captured on one device should be accessible on other devices. The most valuable example of this would be in offering a consistent experience where information entered during a desktop session is accessible in a mobile session and vice-versa.

3.5.10.2 How to do it

For application data to be shared between devices it must be stored on a server and cannot be stored locally on a device (e.g. using cookies or a local data store). For any application data that is not exclusively relevant to the current device, favor storing it on the server so it can be shared by other devices.

3.6 Handling Device Capability Variation

Device capability variation is a basic characteristic of the mobile Web environment. Web applications should adapt their content such that they render in an optimum way on as broad a range of target devices as possible. "As well as possible?" Optimum is an absolute. I think the headline message here is something like "take account of device variation"

3.6.1 Use Server-side Capability Detection for Static Device Capabilities

3.6.1.1 What it means

For static device capabilities that won't change (e.g. SVG support, screen-dimensions) it is preferable to detect these capabilities on the server and adapt content before it is sent to the client in order to avoid transferring unnecessary data.

3.6.1.2 How to do it

Typically used methods of device capabilities detection:

3.6.2 Use Client-side Capability Detection for Dynamic Device State

3.6.2.1 What it means

For dynamic device state that might depend on the configuration or context of the device (e.g. Is scripting enabled? Is the SDCard available? Has permission been granted for PIM access?) detection must be done on the device.

3.6.2.2 How to do it

Use JavaScript reflection to determine if a given API is active and interrogate the device configuration using appropriate APIs. Two methods can then be used to adapt on the client to differing configurations:

  1. Encapsulate the different behaviours in the control logic of the application. E.g. simply use: if (some_configuration_variable) decision-points in the code and behave accordingly;
  2. Use an initial "bootstrap" script to assess device capabilities and request the appropriate application bundle accordingly.

Option (1) is simpler to implement and is appropriate provided the amount of inactive code downloaded doesn't have a negative impact on performance. Option (2) is preferred when the application must change significantly in response to properties that can only be determined on the client.

3.6.3 Use Device Classification to Simplify Content Adaptation

3.6.3.1 What it means

If a large number of devices are being targeted, or the application is sensitive to the permutations of a large number of configuration properties, the number of application variants required might quickly become unmanageable.

To combat this, classify target devices into different "buckets" and build a single application variant for each device bucket. I wonder if we can use a differnt term to "bucket" and wonder how comprehensible it is to international audiences

This will keep the amount of device-specific code to a minimum without unduly encouraging a "lowest common denominator" solution.

3.6.3.2 How to do it

Identify the target devices for the application and assign these to "buckets" of varying capability. Focus on application variants that work in each bucket rather than building device-specific exceptions for every variation in device configuration.

Device buckets should be defined on an application-specific basis, so that the variants can be tailored accordingly. For example, the following is a typical configuration of application buckets:

Bucket 1: Basic XHTML support, no or very basic scripting. No AJAX support.

Bucket 2: Full AJAX and JavaScript support.

Bucket 3: Advanced device APIs, for example: access to location API, device PIM data, or application cache.

3.6.4 Support a non-JavaScript Variant if Possible

3.6.4.1 What it means

Scripted and XHR based applications are not yet well supported on many browsers. If possible, provide a variant of the application that does not rely on script by using synchronous FORM posts instead. might be worth having a note here on mobileOK Basic Tests and its relationship to this best practice

3.6.4.2 How to do it

Essentially this BP states that it is favourable to support "Bucket 1" devices as defined above if at all possible. Doing this will ensure that the application can be used across as broad a range of devices as possible. Furthermore, in some cases a non-JavaScript version can sometimes be useful for simple operations in low-bandwidth situations.

In some cases, however, the type of application simply has no non-JavaScript counterpart (e.g. a Web based game, an Instant Messaging client) in which case it should return a 406 Not Acceptable response.

Do this by detecting the device User-Agent and checking its JavaScript support against a DDR or local index.

3.6.5 Offer Users a Choice of Interfaces

3.6.5.1 What it means

surely it's usually the case that allowing the user to select among available interfaces is the right thing to do? The emphasis on the imperfactions of device detection is mis-stated I think compared with the importance of meeting the user's contextual needs Not only is device characteristics detection imperfect, it cannot always account for the differing use-cases of an application. If multiple flavours of the application exist (e.g. to support the various device buckets) it might make sense to offer the user the choice of which flavour they wish to use.

3.6.5.2 How to do it

Only if it makes sense in the specific context of a given application, allow the user to switch to a different flavour (for example, upgrading their experience if their device is more capable than the server believes, or degrading if connectivity is poor and they wish to accomplish a very simple task that can be done more easily with the minimal UI).

Always attempt to default to the most appropriate UI on first use.

Always remember the user's preference for future visits in a cookie or local data store.

3.7 SVG

Note: This section is still under review. The working group is keen to receive further suggestions for best practices specifically related to the use of SVG on mobile Web sites.

This section covers some specific Best Practices related to the use of SVG in mobile Web applications. SVG is a vector graphics format designed for use in the Web. It is useful when there is a need to convey large amounts of information.

3.7.1 Use SVG Tiny 1.1 Compatible Content

SVG Tiny 1.1 is the most broadly supported.

3.7.2 Minimize Size and Complexity of Content

Take steps to ensure that the SVG content is not overly complex since constrained devices will have difficulty rendering it. Ensure that the browser is configured to enable gzip compression as per 3.4.1 Use Transfer Compression.

3.7.3 Test on Target Devices

Even if SVG Tiny 1.1 is supported on target devices, it is necessary to test on-device since some implementations are not entirely compliant.

3.7.4 Make Use of Language Features to Write Compact Code

Certain features (e.g. defs and use elements) enable geometric shapes to be re-used. Appropriate use of these elements is encouraged in order to create compact code.

Appendix: Best Practice Dependent Device Properties

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

Appendix: Examples

TODO: Include more detailed examples on the following BPs... Use Fragment IDs

A Sources (Non-Normative)

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

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.

B Related Reading (Non-Normative)

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.

The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.

The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.

Section 3.6.3 Use Device Classification to Simplify Content Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity.

C Acknowledgements (Non-Normative)

D References (Non-Normative)

D.1 MWI References

to be added

D.2 Sources

to be added

D.3 Device Independence

DIP
Device Independence Principles, R. Gimson, Editor, W3C Working Group Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/)
DCODI
Delivery Context Overview for Device Independence, , R. Gimson, R. Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See http://www.w3.org/TR/di-dco/)
DIGLOSS
Glossary of Terms for Device Independence, R. Lewis, Editor, W3C Working Draft (work in progress), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/)

D.4 Web, Protocols and Languages

XML
Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C Recommendation, 26 November 2008 (See http://www.w3.org/TR/2008/REC-xml-20081126/)
XHTML-Basic
XHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/)
CSS
Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 January 1999, revised 11 April 2008 (See http://www.w3.org/TR/2008/REC-CSS1-20080411/)
CSS2
Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998, revised 11 April 2008 (See http://www.w3.org/TR/2008/REC-CSS2-20080411/)
HTTP1.0
Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945)
HTTP1.1
Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html)

D.5 Other References

UAPROF
Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0 06 Feb 2006 (See http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf)
WTAI
WAP Forum wap-268-wtai-20010908-a Wireless Telephony Application Interface Specification (See http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf)
RFC 3966
The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December 2004 (See http://www.ietf.org/rfc/rfc3966.txt)
RFC 2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997 (See http://ietf.org/rfc/rfc2119)