Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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
A Sources (Non-Normative)
B Acknowledgements (Non-Normative)
C References (Non-Normative)
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.
Participants in the mobile value chain include:
Developers of tools to assist with content production (authoring).
Developers of tools to assist with content serving and repurposing.
Those involved in the production and execution of testing processes.
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'.
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.
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.
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:
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.
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:
120 Pixels.
XHTML - Basic Profile.
UTF-8.
JPEG
GIF 89a (non-interlaced, non-transparent, non-animated).
20k Bytes.
Web safe.
External CSS Level 1, with internal definition of style and font properties.
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.
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.
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".
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.
Adaptation can be carried out in a number of different points in the delivery of content to the client [DCODI]
Server Side adaptation implies that the content is delivered by the originating content server or application.
In Network adaptation is where the content is altered as it passes through one or more network components. Some network operators, for example, compress images before they are passed over the air to the mobile client.
Client Side adaptation consists of the client accepting content and displaying it appropriately to the device's characteristics.
Hence, in the following section, listing Best Practices, they are organized under the headings of:
Best Practice Statements that refer primarily to the process by which content is created.
This section contains statements that relate to navigation and linking mechanisms.
The section contains statements that relate to the content of pages and how they lay out.
Statements that relate to the technical construction of pages.
One or more best practice statements, identified in the following way:
[EXAMPLE] This is a best practice statement. (Informative)
An explanation of the significance of the statements under this heading.
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.
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:
Automated testing is possible.
Testing requires human assessment.
Based on the result of an automated test some human interaction may be required.
Where appropriate, references to related WCAG points and other immediate references in the text.
There are some general principles that underlie delivery to mobile devices.
[DEFICIENCIES] Take reasonable steps to work around deficient implementations. (Informative)
[URIS] Keep the URIs of site entry points short. (informative)
[NAVBAR] Provide minimal navigation at the top of the page. (Informative)
[NAVIGATION] Use navigation mechanisms in a consistent manner. (Informative)
If a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.
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
[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)
[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions. (Normative)
Some studies [MF] have been carried out in this area to test for user preferences. Some of these indicate that users prefer scrolling to click-throughs and some indicate the contrary. More research is likely to be needed in this area.
[GRAPHICS_FOR_SPACING] Do not use graphics for spacing. (Normative)
[PAGE_TITLE] Provide a short but descriptive page title. (Normative)
[NO_FRAMES] Do not use frames. (Normative)
See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.
[TABLES_LAYOUT] Do not use tables for layout. (Normative)
[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation. (Informative)
[NON-TEXT_ALTERNATIVES] Provide textual alternatives for non-text elements. (Normative)
Design pages as though they were to be displayed on a text-only browser.
Use only features from the markup that are known to be supported by the device in question.
Avoid things like CSS image replacement and actual pictures of words.
[IMAGES_SPECIFY_SIZE] Always specify the size of images in markup. (Normative)
[VALID_MARKUP] Create documents that validate to published formal grammars. (Normative)
[STYLE_SHEETS_SUPPORT] Organize documents so that they may be read without style sheets. (Normative)
[STYLE_SHEETS_SIZE] Keep style sheets as small as possible. (Normative)
[CONTENT_FORMAT_PREFERRED] Where possible send content in a client's preferred format. (Normative)
[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used. (Normative)
As in the previous section, content should not be sent to a device if it can not use it.
The character encoding being used in a response may be indicated using the HTTP Content-Type header.
Additionally for XML documents the character encoding may be indicated in the encoding declaration [XMLENC] although this will generally be ignored if an HTTP Content-Type header is present.
Example: <?xml version="1.0" encoding="UTF-8"?>
Encoding of the content to a desired character encoding is dependent on the authoring tools being used, web server configuration and the server side scripting technology being used (if any). For a discussion of this see [HTTP_CHARSET]
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:
A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);
A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");
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.
[COOKIES] Do not use cookies unless you know the device supports them. (Normative)
[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)
Specification of the natural language required for assists with predictive text input.
There are a number of techniques available for this including:
Where possible use previous entries as defaults.
Make it possible to select items using navigation keys and/or numeric input.
[TAB_ORDER] Create a logical tab order through links, form controls and objects. (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.
iMode Guidelines [iMode]
Opera's "Making Small Device Look Great" [Opera]
Openwave Guidelines [OpenWave]
Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP]
Browsing on Mobile Phones, Nokia[Nokia-VR]
Little Spring Design [LSD]
Sprint PCS Web Style Guide [Sprint]
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.
The editors acknowledge significant written contributions to this draft from: