W3C

Mobile Web Best Practices 1.0

W3C Working Draft 20 December 2005

This version:
http://www.w3.org/TR/2005/WD-mobile-bp-20051220/
Latest version:
http://www.w3.org/TR/mobile-bp/
Previous version:
http://www.w3.org/TR/2005/WD-mobile-bp-20051017/
Editors:
Jo Rabin, mTLD Mobile Top Level Domain (.mobi)
Charles McCathieNevile, Opera Software [Early Drafts]

Abstract

This document specifies best practices for Web content when accessed from mobile devices.

The primary goal is to improve the user experience of the Web when accessed from such devices.

It is directed at all participants in the mobile value chain.

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

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

This document describes the best practices for content to work well on mobile devices. A companion scope document [Scope] describes the scope of this work.

This is the second public Working Draft of the Mobile Web Best Practices for review by interested parties. It incorporates a great number of changes and updates since the previous publication.

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 draft incorporates the changes resulting of the resolution of issues since the previous draft. The group expects to publish a Last Call Working Draft based on this document in the first weeks of January.

This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. The plan being to release this document as Last Call in a few weeks, the Working Group is not actively seeking feedback on this document. Comments send on this version of the document are likely to be considered as part of the Last Call comments. If you do send comments, please send them to the mailing list public-bpwg-comments@w3.org, a publicly archived mailing list.

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures made in connection with this document; 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) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
    1.1 Purpose of the Document
    1.2 Audience
        1.2.1 Participants in the Mobile Value Chain
    1.3 Scope
        1.3.1 Phasing
        1.3.2 Usability
        1.3.3 One Web
    1.4 Default Delivery Context
    1.5 Relationship to other best practices and recommendations
    1.6 How the Best Practices are Organized
2 Requirements
    2.1 Presentation Issues
    2.2 Input
    2.3 Bandwidth and Cost
    2.4 User Goals
    2.5 Advertising
    2.6 Device Limitations
    2.7 Advantages
3 Delivery Model Architecture
    3.1 Adaptation Implementation Model
    3.2 Assumptions about Adaptation
4 Overview of Best Practices
    4.1 How the Best Practice Statements are Organized
    4.2 Structure of Best Practice Statements
5 Best Practice Statements
    5.1 Overall Behavior
        5.1.1 Establish the Context of the Device
        5.1.2 Exploit Client Capabilities
        5.1.3 Work around deficient implementations
        5.1.4 Testing
    5.2 Navigation and Links
        5.2.1 URIs of Site Entry Points
        5.2.2 Navigation Bar
        5.2.3 Balanced Structure
        5.2.4 Thematic Consistency of Resource Identified by a URI
        5.2.5 Navigation Mechanisms
        5.2.6 Access Keys
        5.2.7 Link Target Identification
        5.2.8 Image Maps
        5.2.9 Refreshing, Redirection and Spawned Windows
    5.3 Page Content and Layout
        5.3.1 Page Content
        5.3.2 Page Size
        5.3.3 Scrolling
        5.3.4 Navigation Bars etc. (Extraneous material)
        5.3.5 Graphics
        5.3.6 Color
        5.3.7 Background Images
    5.4 Page Definition
        5.4.1 Title
        5.4.2 Frames
        5.4.3 Structural Elements
        5.4.4 Tables
        5.4.5 Non Text Items
        5.4.6 Image Size
        5.4.7 Valid Markup
        5.4.8 Measures
        5.4.9 Style Sheets
        5.4.10 Minimize
        5.4.11 Content Types
        5.4.12 Character Encoding
        5.4.13 Error Messages
        5.4.14 Cookies
        5.4.15 Cache Headers
    5.5 User Input
        5.5.1 Input
        5.5.2 Tab Order
        5.5.3 Labels
6 Conformance and mobileOK (Normative)
    6.1 Classes of Products
    6.2 Normative Parts
    6.3 Extensibility

Appendices

A Sources (Non-Normative)
B Acknowledgements (Non-Normative)
C References (Non-Normative)


1 Introduction

1.1 Purpose of the Document

This document sets out a series of recommendations designed to promote more effective delivery of Web content to mobile devices.

Each recommendation is discussed in context and brief explanatory notes are provided. The recommendations are offered to all participants in the mobile value chain and are intended as the basis for assessing conformance to the mobileOK trustmark.

The mobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter and is not developed in this document. mobileOK and techniques for implementing the Best Practice recommendations will be discussed in companion documents.

1.2 Audience

Readers of this document are expected to be familiar with creation of Web sites, and have a general familiarity with the technologies involved, such as web servers and HTTP. 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 and others such as interaction and graphic designers are encouraged to read it.

1.3 Scope

The scope of these Best Practices is laid out in [Scope]. In summary this document refers primarily to extension of web browsing onto mobile devices.

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.3.1 Phasing

As discussed in [Scope] there are many aspects to Mobile Web Best Practices. For example, at present, the design and construction of many Web sites and pages make for a poor user experience when they are viewed on a mobile device.

While improving those Web sites is only one aspect of improving the user experience, significant improvements can be achieved in this way, hence the first phase of work is concerned with providing guidelines for Web-site and content developers.

In future phases other aspects may be considered - e.g. best practices as applied to adaptation and devices. Also in future phases the scope of the recommendations may be extended beyond 'Traditional Web Browsing' into fields such as multimodal interaction.

1.3.3 One Web

The recommendations in this document are intended to improve mobile experience of the Web on mobile devices. While the recommendations in this document are not specifically addressed at the desktop browsing experience it must be understood that they are made in the context of wishing to work towards 'One Web'.

As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same way across all devices. Some services and information are more suitable for and targeted at particular user contexts.

Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (perhaps for complex configuration tasks). Still others have a primarily desktop appeal but a complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications which have a primarily desktop appeal (lengthy reference material, rich images, perhaps).

It is likely that application designers and service providers will wish to provide the best possible experience in the context in which their service has the most appeal. However, while services may be most appropriately experienced in one context or another, it is considered best practice to provide a reasonable experience irrespective of the device, and as far as is possible, not to exclude access from any particular class of devices.

From the perspective of this document this means that services should be available as some variant of HTML over HTTP.

1.4 Default Delivery Context

The recommendations refer to delivered content. Given the range of different mobile device types which have different properties and different features the Best Practices Working Group has defined a Default Delivery Context.

Delivery Context is used with the specific meaning defined in the Device Independence Glossary [DIGLOSS].

The document makes reference to the Default Delivery Context in two ways:

  1. If the delivered content does not result from an adaptation process - e.g. the content is statically defined as HTML stored in files - then the delivered content should be suitable for the Default Delivery Context and should comply with the Best Practice Statements.

  2. If an adaptation process is used, then information that it known about the Delivery Context can be used to vary the delivered content to make it more suitable for that Delivery Context or to provide an enhanced user experience.

The default delivery context is defined as follows:

Usable Screen Width

120 Pixels.

Mark Up Language Support

XHTML - Basic Profile.

Character Encoding

UTF-8.

Image Format Support

JPEG

GIF 89a (non-interlaced, non-transparent, non-animated).

Maximum Total Page Weight

20k Bytes.

Colors

Web safe.

Style Sheet Support

External CSS Level 1, with internal definition of style and font properties.

1.5 Relationship to other best practices and recommendations

These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG]. As noted above, WCAG guidelines are supplementary to the Mobile 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 also discusses the notion of device characteristics, which DIWG has described in terms of a "Delivery Context" [DCODI]. In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS].

The BPWG will develop a companion document describing techniques [Techniques] by which the best practice statements in this document can be implemented.

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.6 Device Limitations

As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than that used for desktop devices. As detailed in [Scope], various other limitations may apply to mobile devices, and these have an impact on the usability of the Web from a mobile device.

Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no option as to which browser they should use, and in many cases upgrade of the browser is not possible. This creates the situation that in order to support users of a popular device, the limitations or implementation defects associated with particular releases need to be taken into account in some situations.

Some activities associated with rendering web pages are computationally intensive. Examples are re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid mark up [T-MOB]. There is typically quite limited processing power available to carry out such computations, which may mean they take a noticeable time to complete. Such computations also use more power and diminish battery life. In any case, data communication reduces battery life and reducing communication can conserve battery.

Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.

2.7 Advantages

In discussing the limitations of mobile devices for delivery of Web content it is easy to lose sight of the fact that they are extremely popular and very common.

This popularity largely stems at present from their being:

  • personal,

  • personalizable

  • portable

and increasingly multi-function beyond their original purpose of voice communications.

Beyond these factors, we see the advantages of mobile devices increasingly including:

  • location awareness

  • implicit user identification

  • one handed operation

  • always on

  • universal alerting device

As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place.

Moreover, with mobile devices appearing in all shapes and forms, and with a growing variety of features like location technology, cameras, voice recognition, touch screens etc, the Web can reach a much wider audience, and at all times in all situations. It has the opportunity to reach into places where wires cannot go, to places previously unthinkable (e.g. medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time in their wristwatches.

Finally, today, many more people have access to mobile devices than access to a desktop computer. This is likely to very significant in developing countries, where web-capable mobile devices may play a similar role for deploying wide-spread Web access as the mobile phone has played for providing "plain old telephone service".

3 Delivery Model Architecture

The widely varying characteristics of mobile devices can make it difficult for a Web site to provide an acceptable user experience across a significant range of clients. For example different clients support different markup features, and the different screen sizes may demand different sized images.

Consequently, it is very common when delivering content to mobile clients to vary the details of the markup, format of images, image sizes, color depths and so on to suit the characteristics of the client in question. The process of altering content in this way to enhance the user experience on particular devices is referred to as content adaptation.

The remainder of this section briefly describes content adaptation in order to provide a background for this document. For a more detailed description, readers are referred to the Device Independence Principles [DIP]

In addition, the sister group of the Best Practices Working group - the Device Descriptions Working Group, is currently defining requirements for a repository of mobile client characteristics that are relevant to content adaptation.

4 Overview of Best Practices

4.2 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. (Informative)

Each statement identifies whether it is normative or not.

These statements can be identified by using URI reference composed of the URI of this document together with the statement identifier used as a fragment identifier (e.g. #EXAMPLE).

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. The BPWG intends to create a separate document describing techniques [Techniques] in more detail.

What to Test

The aspects of the delivered content that an external validator would examine to assess conformance with the Best Practice Statements. This section is not present for process and other non-normative statements.

In this section it is noted whether the statement is:

Machine testable

Automated testing is possible.

Human testable

Testing requires human assessment.

Partially machine testable

Based on the result of an automated test some human interaction may be required.

References

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

5 Best Practice Statements

5.1 Overall Behavior

There are some general principles that underlie delivery to mobile devices.

5.1.1 Establish the Context of the Device

[CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource. (Informative)

5.1.1.1 What it means

Many of the best practice statements refer to the content provider knowing a significant amount about the physical characteristics of the device, the properties of the browser in use and the transparency of the network connection to the device. For simple sites that present an interface which is similar across a broad range of clients the need for such information is diminished when compared with a sophisticated site which has an optimized navigation structure, presents different size images or carries out other adaptations to suit the client.

It is unlikely that the content provider, "having taken all reasonable steps", will know nothing at all about the context of the device. However if absolutely nothing is known "a reasonable default experience" should be provided. The details of the default experience depend upon a number of factors including, but not limited to, the geographic region in which the service is offered and the primary intention of the service (e.g. considering whether the service is primarily desktop focused vs. primarily mobile focused).

Where the determination of the default experience has resulted in selection of a mobile experience, the default delivery context should be assumed in creating that presentation.

The content provider may choose, in the interests of "One Web" considerations, to allow the user to select the experience from broad categories such as mobile or desktop, where these presentations are distinguished in the application.

5.2 Navigation and Links

Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile clients, care should be exercised in defining the structure of a site and the navigation model for the site.

5.2.8 Image Maps

[IMAGE_MAPS] Do not use image maps unless you know the target client supports them and has sufficient screen area and an appropriate means of selection, such as a stylus or navigation keys. When using image maps under these circumstances, use client side image maps unless the regions required cannot be described with an available geometric shape. (Normative)

[SERVER_SIDE_IMAGE_MAPS] Do not use a server side image map unless you know that the client provides a means of selection within the image map. (Normative)

5.2.9 Refreshing, Redirection and Spawned Windows

[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. (Normative)

[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it. (Normative)

[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes. (Normative)

5.3 Page Content and Layout

This section refers to the user's perception of the delivered content. It concentrates on design, the language used in its text and the spatial relationship between constituent components. It does not address the technical aspects of how the delivered content is constructed, which is discussed in 5.4 Page Definition

5.3.1 Page Content

[SUITABLE] Ensure that content is suitable for use in a mobile context. (Informative)

[CLARITY] Use the clearest and simplest language appropriate for a site's content. (Informative)

[LIMITED] Limit content to what the user has requested. (Informative)

5.3.2 Page Size

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions. (Normative)

[PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to bandwidth, the memory limitations of the device and other device and delivery channel characteristics if they can be determined. (Normative)

5.3.3 Scrolling

[SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided. (Normative)

[SCROLLING_LIMIT] Limit secondary scrolling to objects that require it, where it cannot be avoided. (Normative)

5.4 Page Definition

5.4.5 Non Text Items

[NON-TEXT_ALTERNATIVES] Provide textual alternatives for non-text elements. (Normative)

[OBJECTS_OR_SCRIPT] Do not embed objects or script in pages unless you know the device supports them. (Normative)

5.4.10 Minimize

[MINIMIZE] Use terse efficient markup. (Normative)

5.4.11 Content Types

[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device. (Normative)

[CONTENT_FORMAT_PREFERRED] Where possible send content in a client's preferred format. (Normative)

5.4.12 Character Encoding

[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the target device. (Normative)

[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used. (Normative)

5.4.13 Error Messages

[ERROR_MESSAGES] Provide informative error messages, and a means of navigating away from an error message back to useful information. (Normative)

5.4.13.2 How to do it

It is noted that many web servers provide a default error page especially in the event of a request for a non-existent page (404) or an internal error (500). Where possible (see [TOMCAT], [APACHE] and [IIS] ), applications should trap all error conditions by overriding the default pages if necessary, and handle them in a user-friendly, and graceful, way.

Error messages should be provided in the same language as the application that was being used. They should be clear and concise, adhering to the same best practices as the rest of the application. They should be provided in a format that the device can handle.

The error message should detail whether the issue is likely to be temporary or permanent, whether the user may be able to solve the issue themselves (for example, by changing input data, or a handset setting), or whether it is an issue that can be escalated to the content provider or network operator. In the latter case, contact details, such as an SMS address or a support line number, might be appropriate.

Navigationally, the error message should provide one or more of:

  1. A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);

  2. A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");

  3. A "home" link to allow the user to proceed back to the main part of the application.

The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.

5.5 User Input

This section contains statements relating to user input. User input is typically more or a lot more restrictive on Mobile devices, which may lack pointing devices and usually do not have a standard keyboard with which to enter text.

5.5.1 Input

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum. (Informative)

[AVOID_FREE_TEXT] Avoid free text entry where possible. (Normative)

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible. (Normative)

[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the target device is known to support it. (Normative)

6 Conformance and mobileOK (Normative)

Conformance to this document requires conformance to each and every one of the Statements, except where required to satisfy the needs of deficient implementations as noted under [DEFICIENCIES].

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.

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.

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 primarily 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 Acknowledgements (Non-Normative)

The editors would like to thank members of the BPWG for contributions of various kinds. The editors would also like to thank contributors to the public list, whose comments have been taken into account in the creation of this document.

The editors acknowledge significant written contributions to this draft from:

C References (Non-Normative)

Scope
"Scope of Mobile Web Best Practices ", Phil Archer, Ed Mitukiewicz, W3C Working Draft 1 September 2005 (See http://www.w3.org/TR/mobile-bp-scope/.)
Techniques
Mobile Web Techniques for Best Practices [to be published]
mobileOK
mobileOK Trustmark [to be published]
WCAG
"Web Content Accessibility Guidelines 1.0", W Chisholm, I. Jacobs, G Vanderheiden eds. W3C Recommendation 5 May 1999. (See http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505.)
DIP
Device Independence Principles, W3C Note, R. Gimson 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/.)
DCODI
Delivery Context Overview for Device Independence, W3C Note, R. Gimson and R. Lewis 18 January 2005 (See http://www.w3.org/TR/di-dco/.)
DIGLOSS
Glossary of Terms for Device Independence, W3C Working Draft, R Lewis 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/.)
HTTP_CHARSET
The HTTP charset parameter, Martin J. Dürst 22 September 1999 (See http://www.w3.org/International/O-HTTP-charset.)
XMLENC
Extensible Markup Language (XML) 1.0 (Third Edition) W3C Recommendation Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Sun Microsystems, François Yergeau 04 February 2004 (See http://www.w3.org/TR/2004/REC-xml-20040204/#charencoding.)
TOMCAT
Tomcat FAQ How do I get a customized error page? (See http://tomcat.apache.org/faq/misc.html#error.)
APACHE
Apache Core Features ErrorDocument directive (See http://httpd.apache.org/docs/1.3/mod/core.html#errordocument.)
IIS
IIS Custom HTTP Error Messages (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/ee7a8c53-f9bc-4cd4-b954-e32066105cf1.asp.)
CDFWG
CDF WG References (See http://www.w3.org/2004/CDF/Group/.)
T-MOB
T-Mobile International - Position Statement for W3C Mobile Web Initiative Version: 1.0 18 Dec 2004 (See http://www.w3.org/2004/10/MWIWS-papers/W3C_Mobile_Web_Initiative_-_T-Mobile_Position_Statement-final.pdf.)
iMode
iMode (See http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf.)
Opera
Opera's Making Small Devices Look Great (See http://my.opera.com/community/dev/device/.)
OpenWave
Openwave (See http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm.)
Nokia-MP
Nokia Guidelines for XHTML-MP on Series 60 (See http://sw.nokia.com/id/4f7b6805-47d7-4914-885c-6ef2b487adf6/Series_60_Platform_Designing_XHTML_MP_Content_v1_4_en.pdf.)
Nokia-VR
Browsing on Mobile Phones, paper by Virpi Roto, Nokia (See http://www.research.att.com/~rjana/WF12_Paper1.pdf.)
LSD
Little Spring Design (See http://www.littlespringsdesign.com/design/styleguides.html.)
Sprint
PCS Web Style Guide, Vision Edition, XHTML Mobile Profile, Version 1, August, 2002
MF
Study by Segala M Test on Scrolling vs. Pagination (See http://www.mobilefriendly.org.)