W3C

Mobile Web Best Practices 2.0

Basic Guidelines

W3C Editor's Draft 03 March 2008

This version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080303
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-20080213  
Editors:
Bryan Sullivan, AT&T

Abstract

This document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to enable development and delivery of great Web applications on mobile devices, through recommendations for exploitation of mobile device capabilities and delivery context.

The recommendations refer to applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.

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 2.0 technologies. Readers are not expected to have a background in mobile-specific technologies.

Status of this Document

(to be filled in later)

Table of Contents

(to be filled in later)

Appendices

(to be filled in later)


List of Best Practices

(to be filled in later)


1 Introduction

1.1 Purpose of the Document

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.

1.2 How the Best Practices are Organized

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

1.3 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, 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.

1.4 Scope

These recommendations (BP2) follow in the footsteps of the Mobile Web Best Practices 1.0, (BP1), for which the scope was laid out in "Scope of Mobile Web Best Practices" [Scope] . In summary, BP1 refered primarily to the extension of Web browsing onto mobile devices.

BP2 extends the focus to Web applications generally, which means an application that is accessed and presented via Web technologies. Web applications represent a spectrum of services and content, at the simple end of which are typical Web browsing sites, presented in browsers, which were the focus of BP1. The BP2 focus includes further recommendations for addressing delivery context issues and for use of advanced Web technologies, which apply both to browsers and non-browser web runtime environments.

The recommendations refer to applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.

As the goal of the document is to specify Best Practices for delivery to mobile devices, statements that do not have a specific mobile aspect are not included. In particular, many Web Content Accessibility [WCAG] guidelines are general to all forms of Web access and are not repeated here unless they have a specific mobile interpretation. Examples of general good practice which have a specific mobile interpretation include "Error Messages" and "Color".

1.4.1 Phasing

As discussed in the Scope document [Scope] there are many aspects to Mobile Web Best Practices. BP2 represents the second phase of the Best Practices development, i.e. beyond "Traditional Web Browsing".

1.4.1 Criteria for Best Practice recommendations

The BP2 is not intended as a landscape document, e.g. a general survey of technologies and related issues in the mobile context. Recommendations are included here if they meet specific criteria:

  • are considered essential for successful deployment of web applications in common delivery contexts
  • are considered of fundamental importance to growth in the mobile web application market
  • can be readily verified through compliance testing, either automated (preferred) or manual

1.5 Relationship to other Best Practices and recommendations

These recommendations follow in the footsteps of the BP1, and as such are in part derived from the Web Content Accessibility Guidelines [WCAG] . The WCAG guidelines are supplementary to the Mobile Web Best Practices, whose scope is limited to matters that have a specific mobile relevance.

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

1.6 Longevity and Versioning

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.

2 Requirements

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.

2.1 Personalization

Personalization is an important capability in the mobile environment, given the extra effort necessary to interact with services, and the limited output capabilities of mobile devices. Personalization increases the value of content and services to users. However, conventional methods to achieve/maintain personalization (e.g. user input, HTTP redirect, cookies) are problematic given mobile context limitations. The overall goal for personalization in the mobile context is to use user-friendly methods.

2.2 Security  and privacy

Security is important to address in the mobile environment, due to more frequent dependence upon personalized information. While this information is essential to increasing service value, its use represents a security and/or privacy risk. The overall goal for security is to protect any personally identifiable information, and especially user identifiers or keys to user identity.

2.3 User  awareness and control 

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.

2.4 Use of cookies and redirection

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.

2.5 Conservative use of network traffic

Web applications that autonomously interact with network-based services can have a very significant impact on service cost. These costs can be borne by the user and/or network service provider. Users with "bucket" or per-KB service plans can find themselves responsible for huge charges. Network service providers can bear these costs for users that subscribe to unlimited service plans, and as a result may restrict the types of applications available to users 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.

2.6 "One Web"

- help spread the one web mentality

2.7 Constraints and Capabilities of the Mobile Context

2.7.1 Presentation Issues

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

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

 

2.7.2 Interaction Issues

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

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]   

 

2.7.3 Delivery Context Variability

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.

BP2 extends/expands the discussion for specific delivery context aspects, e.g.:

 

2.8 Applicability to Non-Browser Web Runtime Environment

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

2.9 Toolkit Developer Issues

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

3  The Mobile Context

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

4 Structure of Best Practice Statements

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 Best Practice Statements

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 Personalization

5.1.1 Use Automated Means for Obtaining Personalizing Information

5.1.1.1 What it means

Personalized services are enabled by content provider awareness of personalizing information, e.g. user identity, preferences, characteristics. Personalized services should be capable of using automated means of obtaining such personalizing information, in order to reduce user effort in obtaining the personalized service.

5.1.1.2 How to do it

Content providers can often use personalizing information that is directly forwarded by network proxies, e.g. as HTTP headers. Such information may be made available by network operators through developer and content provider programs.

Content providers can also use information, e.g. user credentials, which is provided directly by the user on a first access, and then automatically provided by the user-agent on subsequent accesses. An example method for this is to use HTTP Basic or Digest Authentication.

Content providers may also be able to acquire personalizing information directly through features of the user-agent, e.g. via Delivery Context Client Interfaces (DCCI) methods.

5.1.2 Retain Manually Entered Personalizing Information

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 Simplify Manual Entry of Personalizing Information

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

5.2 Security and privacy

5.2.1 Use Secure Means to Exchange Personal Information

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 User  awareness and control 

5.3.1 Inform the User About Automatic Use of Networks

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

5.3.2 Inform the User About Device Memory Impact for Application Installation and Use

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:

5.3.3 Inform the User About Use of Personal Information

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:

5.3.4 Provide Disclosures that are Timely and Accessible

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 Provide Useful Control over Application Behavior 

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.

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 Use of cookies and redirection

5.4.1 Automatically Recover Cookie-Based Information 

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 Minimize Redirects in Server-Server API's

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.

5 .5 Conservative use of network traffic

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 Support HTTP 1.1 Compression 

5.5.1.1 What it means

HTTP compression is a widely supported method of content optimization, 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.

5.5.1.2 How to do it

Web servers should be configured to serve web pages using HTTP 1.1 compression (gzip or deflate), for both upload and download transactions.

5.5.2 Back off Automatic Operation During Low-Value Periods 

5.5.2.1 What it means

The value of automated transactions may vary, 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.

5.5.2.2 How to do it

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. Example methods include:

5.5.3 Use Push Methods to Reduce Pull Traffic 

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

OMA Push is a widely supported enabler providing methods for user-confirmed and automatic content push, directed to mobile browsers and other user-agents.

5.6 "One Web"

5.7 Constraints and Capabilities of the Mobile Context

5.7 .1 Presentation Issues

5.7.2 Interaction Issues

5.7 .3 Delivery Context Variability

5.8 Applicability to Non-Browser Web Runtime Environment

5.9 Toolkit Developer Issues

Input from the BP list

Jo Rabin

- Use tel: scheme to take advantage of the telephony capability of the device. Given that the device is often also a telephone, use of such schemes help the user to use non Web capabilities in a range of applications such as listings, contact and so on. Other schemes that may be considered include sms:, wtai: Ö

Josť Manuel Cantera Fonseca

- Keep the number of external script files to a minimum: Combine several script files into one at deployment time
  + Removing whitespace and comments (it could be done at deployment time)
  + Making variable names in the code shorter (it could be done at deployment time, although it could be tricky or dangerous)
  + Sending script files with gzip content-coding (if the browser support it)
  + Aaron Kemp: but watch out for max cacheable object size
  + Example: http://developer.yahoo.com/yui/compressor/
- Use script for the dynamic aspects of the user interface
- Minimize the number of interactions with the server via XMLHttpRequest
- Provide non-AJAX alternatives to your applications
- Use Javascript reflection to check for available functionalities
- Minimize the number of script files
- Use Javascript reflection to check for available functionalities avoiding parsing the user agent string. The user agent string cannot be trusted while trying to figure out what are the script functionalities available.
  + How to do it (example): Use Javascript Reflection and if statements
  + if(window.ActiveXObject) {
    // Instantiate using new ActiveXObject } else if(window.XMLHttpRequest) {
    // Instantiate using new XMHttpRequest }
- Provide non-AJAX alternatives to your applications. There can be browsers that don't provide AJAX support so you should be prepared for that and provide the same functionality in case AJAX it is not available.
  + Could the user have also a preference on to-AJAX or not AJAX? If he wants to save battery ... that could be something to discuss
  + How to do it: Detect browser capabilities or user preferences and react accordingly
- The number of interactions with the server made via XMLHttpRequest should be kept to a minimum, prefetching data as much as possible
  + How to do it: If you know that some data coming from the server is going to be needed later, prefetch that data  and keep it in memory until it is finally needed 
- 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
  + How to do it: 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

Adam Connors

- 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.
- Use markup language to create the minimal page framework and flesh out repetitive/dynamic aspects of the page using javascript.
  + The logic of this is:
    - lets say I have a page displaying 100 contacts... the data for those contacts is much more compactly transmitted as a json string 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.
  + This is the approach we are using in our applications at the moment and it seems to be giving us a better overall user-experience. It would be useful to understand the tradeoffs though -- perhaps an experiment is required ? I don't know much about impacts to battery life but since it's a short-term bit of processing at the moment the page is displayed I can't imagine it has such a dramatic effect.

Sunghan Kim

- A mobile property for providing seamless contentís connection among different types of terminals. Simply speaking, while user is receiving the service with non-mobile device from web server, suddenly if user want to change into different mobile device without restarting same service, Web server and mobile device need to have some functionality to support this capability.

Barbara Ballard

- The user may also have a data plan that is not unlimited; in those cases she should have control over how much data a page is using.