Mobile Web Best Practices 1.0

W3C Working Draft 17 October 20 December 2005

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


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 .

The primary goal is

Readers of this document are expected to improve the user experience be familiar with creation of the Web when accessed from mobile devices. 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 first Public second public Working Draft of the Mobile Web Best Practices for review by interested parties. 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 does not represent incorporates the consensus changes resulting of the MWBP Working Group. It is known to be missing requirements, and is likely resolution of issues since the previous draft. The group expects to contain errors. 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 . There are several specific issues on which the group solicits public feedback and comment. They are called out in the text like The plan being to release this note. We encourage feedback on all aspects of the document but particularly request as Last Call in a few weeks, the Working Group is not actively seeking feedback on these points. Please this document. Comments send comments on this version of the document are likely to be considered as part of the working group's public email Last Call comments. If you do send comments, please send them to the mailing list public-bpwg@w3.org public-bpwg-comments@w3.org , a publicly archived mailing list. 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 Players Participants in the Mobile Value Chain
    1.3 Scope
        1.3.1 Phasing
        1.3.2 Usability
        1.3.3 Boundaries of the Best Practice Guidelines One Web
    1.4 Baseline Client Default Delivery Context
    1.5 Compliance     1.6 Relationship to other best practices and recommendations
2     1.6 How the Best Practices are Organized
3 2 Requirements
    3.1 User Experience     2.1 Presentation Issues
    3.2     2.2 Input
    3.3     2.3 Bandwidth and Cost
    3.4 Content Type     2.4 User Goals
    3.5     2.5 Advertising
    3.6     2.6 Device Limitations
    3.7     2.7 Advantages
4 3 Delivery Model Architecture
    4.1     3.1 Adaptation Implementation Model
    4.2     3.2 Assumptions about Adaptation
5 4 Overview of Best Practices
    5.1 Overview         5.1.1 Sources         5.1.2     4.1 How this section is organized the Best Practice Statements are Organized
        5.1.3     4.2 Structure of Best Practice Statements
    5.2 5 Best Practice Statements
    5.1 Overall Behavior
        5.2.1         5.1.1 Establish the Context of the Device
        5.2.2         5.1.2 Exploit Client Capabilities
        5.2.3         5.1.3 Work around deficient implementations
        5.2.4 Error Messages         5.2.5 User Preferences         5.2.6         5.1.4 Testing
        5.2.7 [Other general things]     5.3     5.2 Navigation and Links
        5.3.1 URLs         5.2.1 URIs of Site Entry Points
        5.3.2 Provide a Site Map         5.2.2 Navigation Bar
        5.3.3         5.2.3 Balanced Structure
        5.3.4         5.2.4 Thematic Consistency of Resource Identified by a URI
        5.3.5         5.2.5 Navigation Mechanisms
        5.3.6         5.2.6 Access Keys
        5.3.7         5.2.7 Link Target Identification
        5.3.8         5.2.8 Image Maps
        5.3.9         5.2.9 Refreshing, Redirection and Spawned Windows
    5.4     5.3 Page Layout and Content and Layout
        5.4.1         5.3.1 Page Content
        5.4.2 Consistency         5.4.3         5.3.2 Page Size
        5.4.4         5.3.3 Scrolling
        5.4.5         5.3.4 Navigation Bars etc. [Extraneous material] (Extraneous material)
        5.4.6         5.3.5 Graphics
        5.4.7         5.3.6 Color
        5.4.8         5.3.7 Background Images
    5.5     5.4 Page Definition
        5.5.1         5.4.1 Title
        5.5.2         5.4.2 Frames
        5.5.3         5.4.3 Structural Elements
        5.5.4         5.4.4 Tables
        5.5.5         5.4.5 Non Text Items
        5.5.6 Valid Markup         5.4.6 Image Size
        5.5.7 Measures         5.4.7 Valid Markup
        5.5.8 Semantic Markup         5.4.8 Measures
        5.5.9         5.4.9 Style Sheets
        5.5.10         5.4.10 Minimize
        5.5.11         5.4.11 Content Types
        5.5.12         5.4.12 Character Set Encoding
    5.6         5.4.13 Error Messages
        5.4.14 Cookies
        5.4.15 Cache Headers
    5.5 User Input
        5.6.1         5.5.1 Input
        5.6.2         5.5.2 Tab Order
        5.6.3         5.5.3 Labels
        5.6.4 Language Identification 6 Conformance and mobileOK (Normative)
        5.6.5 Context Menus     6.1 Classes of Products
6 Techniques     6.2 Normative Parts
7 Conformance and mobileOK     6.3 Extensibility


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

1 Introduction

1.1 Purpose of the Document


This document contains sets out a list series of recommendations designed to promote more effective delivery of best practices and discussion around the assertions made for content on the Web so that it is delivered effectively content to mobile devices. It also contains information about how to implement sites that conform to those best practices.

The document

Each recommendation is intended to provide guidance discussed in context and brief explanatory notes are provided. The recommendations are offered to players all participants in the mobile value chain as to best practices for production of web sites and of Web content intended for delivery to mobile devices. It is also are intended as the basis for assessing conformance to the requirements of the MobileOK mobileOK trustmark.

The idea for the MobileOK mobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter We do and is not develop the idea of mobileOK developed in this revision of this document. Future revisions may contain a discussion of mobileOK. mobileOK and techniques for implementing the Best Practice recommendations will be discussed in companion documents.

1.2 Audience

As mentioned above the document is targeted at players in the mobile value chain, as described below. 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. 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.

The group solicits public feedback as to the usability of the document by Web professionals that are not technology specialists.

1.3 Scope

The scope of these Best Practices is laid out in [Scope] . In summary this document refers primarily to browsing and extension of the Web web browsing experience to be more usable on onto mobile devices.

The charter As the goal of the group document is to specify best practices Best Practices for delivery to mobile devices. Hence best practice devices, statements that do not specifically 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] the there are many aspects to Mobile Web Best Practices. One of those aspects is that, For example, at present, the design and construction of many Web sites and pages make for a poor user experience when those sites and pages 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 voice browsing. multimodal interaction.

1.3.3 Boundaries of the Best Practice Guidelines One Web

This section describes what the Best Practices are trying to achieve, and what they are not. A Reasonable User Experience The MWI recommendations in this phase [See Phasing ] is concerned with establishing a set of guidelines that help content providers achieve the best possible document are intended to improve mobile experience of their the Web content - given on mobile devices. While the client and network limitations that are encountered recommendations in this document are not specifically addressed at the mobile delivery of Web content [see Requirements for a discussion of these]. A reasonable desktop browsing experience of the Web cannot it must be achieved on clients understood that exhibit too many of they are made in the limitations discussed or where one or other context of the limitations is very severe. wishing to work towards 'One Web'.

In saying this it is recognized that any judgment of what is a reasonable experience is made at a particular point As discussed in time and from particular cultural perspective. It is also recognized that it [Scope] One Web means making, as far as is possible reasonable, the same information and services available to achieve a reasonable experience users irrespective of non-Web services in the presence of such limitations and that that there device they are at present many such services, often implemented using WAP 1.x technologies. The intention, however, of using. However it does not mean that exactly the Mobile Web Initiative, same information is to extend the reach of available in exactly the Web to mobile same way across all devices. Hence such non Web Some services and information are out of scope of this discussion. more suitable for and targeted at particular user contexts. The Idea of a Baseline Client

To be clear about the level of functionality (or absence of limitation) that is targeted for Some services have a reasonable primarily mobile experience of the Web we define the notion of appeal (location based services, for example). Some have a baseline client. By establishing primarily mobile appeal but have a baseline definition, is it possible to provide guidance as to what an implementation should do if it cannot determine whether complementary desktop aspect (perhaps for complex configuration tasks). Still others have a client accessing the service supports features that meet or exceed the baseline definition. In short, it should assume the client provides baseline support. As such the notion of primarily desktop appeal but a baseline client should be seen as guidance on the limitations of pages that are delivered by an implementation, rather than the specification of complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications which have a device. primarily desktop appeal (lengthy reference material, rich images, perhaps). Least Common Denominator

It is not the intention likely that application designers and service providers will wish to encourage Least Common Denominator Implementations. The best practice recommendations actively encourage provide the best possible support of the baseline client as well as exploitation of features that go beyond the baseline so far as those features refer to experience in the Phase 1 scope (Web Browsing). What is a Mobile Client? While it is out of scope of context in which their service has the best practices to consider non-mobile delivery, it must most appeal. However, while services may be understood that there is no clear dividing line most appropriately experienced in one context or categorization that makes mobile and non mobile clients distinct. Rather, as mentioned above, that non-mobile clients tend to suffer fewer of the limitations that are characteristic of mobile ones. Any particular client can be another, it is considered best practice to be in provide a scale between suffering all reasonable experience irrespective of the limitations discussed device, and suffering none of them. In addition, for as far as is possible, not to exclude access from any particular client, the limitations may not apply equally at different times. class of devices. Which Formats are in Scope?

Similarly to the [WCAG] From the best practice recommendations are couched at a level perspective of generality this document this means that allows them to services should be applied to a wide range of markup languages. The intention being that as well as being applicable to current Web standards (especially XHTML), they are also applicable to existing and legacy non-Web recommendations, such as cHTML and WML, as well as future standards, such available as [CDFWG] . some variant of HTML over HTTP. Real-World Coverage of Best Practices

It is recognized that many devices in daily use do not qualify as baseline clients. While the best practices do not target such clients, they do not discourage implementations from supporting them. 1.4 Default Delivery Context

Baseline conformant devices have been available for some years, and are in common use in many markets. The recommendations encourage refer to delivered content. Given the use range of features that go beyond the baseline, that different mobile device types which have been different properties and will continue to be introduced in new devices. However, since different features the MWI Phase 1 refers only to 'traditional' browsing it does not establish best practices for those features. Best Practices Working Group has defined a Default Delivery Context . Evolution of Baseline Definition

As time moves on it is likely that both the definition of a baseline device and the best practice recommendations will change. It Delivery Context is anticipated that the best practice recommendations will change at a slower pace than used with the definition of specific meaning defined in the baseline device. Device Independence Glossary [DIGLOSS] .

As mentioned above, the definition of a baseline device is with The document makes reference to a notion of a reasonable Web experience. Any future change in the baseline device specification will need to take into account both the ongoing development of the non-Mobile Web experience and the availability of devices that exceed the current baseline. It is understood that the capabilities of devices differs markedly Default Delivery Context in different regions of the world, with more developed economies having access to a wider range of more fully featured clients. two ways:

  1. Implementation Issues

    The notion of a baseline client is an abstract notion. No specific real device is targeted. Rather, it is an abstraction of If the characteristics of a range of currently popular devices that have been available for some years. The abstraction assumes complete and defect free implementation of delivered content does not result from an adaptation process - e.g. the features described. It is considered good practice to work around implementation defects of real devices. However, it content is not statically defined as HTML stored in scope of best practices to itemize known defects and limitations nor to detail techniques or examples of how to do this. See [] files - then the delivered content should be suitable for references as to known device the Default Delivery Context and client limitations. should comply with the Best Practice Statements.

  2. Best Practices refer to Server Implementations not Clients

    The recommendations refer to the behavior of implementations in providing a service, and in this phase do not refer to the behavior of clients. It If an adaptation process is hoped used, then information that by providing a baseline definition creators of devices and clients will it known about the Delivery Context can be encouraged used to produce devices that meet or exceed vary the baseline definition. It is also hoped delivered content to make it more suitable for that those commissioning Delivery Context or setting standards for such devices will require implementation of baseline features to a reasonable standard of completeness and quality. provide an enhanced user experience.

    1.4 Baseline Client

The group requests public comment on the specification of the baseline device given the comments in the previous section, that the purpose of the baseline specification is to inform what implementations can assume to be the minimum level of support that they must take account of, and what assumptions they may make in the absence of any other information . In addition to discussing the baseline client the group has also discussed the idea of a default client. The idea being that for any particular application or geographic region, it may be known that the majority of devices are of a particular type or support particular features. In this case the notion of the 'global' baseline device delivery context is supplemented by a 'local' default device, which may have either greater or lesser functionality when compared with the baseline. defined as follows:

The group would value feedback both on which parameters are to be specified and what the values for those parameters should be.
Usable Screen Width The following are for illustration only.

120 Pixels.

Format Mark Up Language Support

For the purposes of delivering The Web, this is assumed to be a version of XHTML - probably aligned with XHTML-MP. Some opinion states that WML should be assumed. http delivery is assumed. There is a further variation in views as to what image format a web site should assume a client supports. It may be that it should be assumed that there is no compatible image support. Basic Profile.

Usable Screen Size Character Encoding

People have strong, but divergent opinions on this. The absolute minimum being 96 x 96 pixels. Strong support is expressed for 128 x 128, however a vocal group supports bigger still. Some opinions support the notion that a minimum row and column availability for text presentation needs to be specified. UTF-8.

Colors Image Format Support

Varying opinions again on this. JPEG

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

Maximum Total Page Weight

It is important to understand the limitations of memory so that Web sites do not try to deliver pages that are too big. However it is not clear how this should take into account the combined weight of markup and images. Suggestions vary from 10k bytes upwards. 20k Bytes.

Other Colors

Many other candidate parameters have been suggested, including cpu power, Back / Forward navigation in history, text entry (which character sets?), form controls, SSL 1/2, Javascript ... Web safe.

Style Sheet Support 1.5 Compliance

The document does not have a compliance model. The Best Practice Recommendations represent suggestions as to the behavior of Web sites. Any use External CSS Level 1, with internal definition of the words must , should style and may should not be interpreted as having the meanings defined in RFC2119. font properties.

The Best Practice statements are intended to be capable of later having conformance statements constructed around them, in support of the mobileOK trustmark and for other purposes.

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

The work This document builds on some of the concepts described by the Device Independence Working Group [DIWG] (DIWG) in the Device Independence Principles [DIP] . The document also discusses the notion of device characteristics, which DIWG has described in terms of a direct and fundamental relevance to this document. "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.

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

We discuss the requirements under two broad headings, User Experience and Device Limitations; both contribute to a poor experience of the Web on mobile devices.

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

3.7 2.7 Advantages

[The group notes that as well as having

In discussing the limitations of mobile devices also have 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 compared 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 or laptop devices. computer. This section to be developed is likely to elucidate this point.] 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".

4 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, 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 outlines briefly describes content adaptation in order to provide a background to for this document. It is not intended as a comprehensive guide or to be definitive. The Device Independence Working Group [DIWG] has published For a great deal of material relevant to this subject. Readers more detailed description, readers are expecially referred to "Delivery Context Overview for the Device Independence" [DCODI] . 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.2 3.2 Assumptions about Adaptation

In phase 1 we assume that content adaptation, if any, is carried out Server Side. Future phases may consider the implication of other content adaptation, especially the issues around granting authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address the issues around the possibility of multiple adaptations - i.e. the possibility that adaptation can be applied in more than one place, and that in network adaptation may occur more than once.

We also assume that it is possible to create a site that is consistent with the best practice recommendations, without carrying out adaptation at all. However, it is likely that a more sophisticated and enhanced user experience will be achieved if adaptation is used.

Clearly in order to determine the appropriate adaptation for any particular access, it is necessary to determine the device that is accessing the service. Sometimes it is not possible to determine the device type, either because the device does not present this information to the server at all, or in sufficient detail, or because the server does not provide the ability to inspect and act on the information provided.

In these cases the content author provider is expected to assume baseline or default device characteristics, as discussed in the Introduction to this document.

The group seeks public feedback on the desirability of stating that, in practice, adaptation is required for delivery to mobile devices; and that consequently, in view of the desirability of making content widely accessible across a broad range of devices, all Web development requires adaptation.

5 4 Overview of Best Practices

5.1.3 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

Explanation An explanation of the significance of the statements under this heading heading.

How to do it

Discussion A discussion of techniques, usually a reference techniques and some suggestions as to the relevant section of this how to implement. The BPWG intends to create a separate document [not much filled in describing techniques [Techniques] in this revision] more detail.

References and Sources What to Test

Discussion The aspects of similar and related points and supporting references especially those from the list above. [usually missing in 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 version, a shorthand reference being provided directly against section it is noted whether the statement(s) itself/themselves] statement is:

Machine testable

Automated testing is possible.

Testability Human testable

Outline discussion Testing requires human assessment.

Partially machine testable

Based on the result of how amenable this is to an automated testing. [almost totally missing in this revision] test some human interaction may be required.


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

5 Best Practice Statements

5.2 5.1 Overall Behavior

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

In this section we refer to 'Implementations' by which we mean Web Servers, Adaptation Devices and other components in the delivery chain (as discussed above under 'Delivery Model Architecture').

5.2.1 5.1.1 Establish the Context of the Device

Implementations should take

[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) What it means

Many of the best practice statements rely on refer to the implementation content provider knowing a significant amount about the physical characteristics of the device, the properties of the browser in use and the transparency or otherwise of the communication path between the device and network connection to the implementation. device. For simple sites which 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.

If a particular client It is not recognized or its capabilities cannot be determined a 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 experience" should be provided. In this case The details of the default experience depend upon a warning should be provided and number of factors including, but not limited to, the implementation should provide geographic region in which the ability for service is offered and the user to select primary intention of the device type in use. service (e.g. considering whether the service is primarily desktop focused vs. primarily mobile focused).

Where possible the user's determination of the default experience has resulted in selection of a device type should persist across visits to mobile experience, the implementation, but default delivery context should be changeable. assumed in creating that presentation.

The warning provided while making it clear that the experience content provider may not be optimal for choose, in the user, should be minimally intrusive interests of "One Web" considerations, to allow the experience of user to select the information and as far experience from broad categories such as possible should be consistent with other recommendations. mobile or desktop, where these presentations are distinguished in the application.

5.2.3 5.1.3 Work around deficient implementations

Implementations should recognize that there are a significant number of clients that do not support standards completely or correctly and should take

[DEFICIENCIES] Take reasonable steps to work around such deficiencies. deficient implementations. (Informative) How to do it See the section on Adaptation under [Techniques], which describes several techniques for varying the presentation of the site depending on the device capabilities and variations in implementation. 5.2.4 Error Messages Provide informative error messages, and a means of navigating away from an error message back to useful information. What it means It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought. So far as determination of the error is within control of the implementation, the user should be provided with clear information regarding the fault they have experienced. This should help them to understand whether the fault was temporary or permanent, whether they should re-attempt to access the content, and how they may be able to escalate the problem. It should also be possible for the user to escape from the error condition. They should either be able to return back to the page they were on previous to the error, or to be able to move onwards to a convenient part of the service from where they can retry or alter the transaction they were attempting. How to do it Where possible, applications should trap all error conditions that could occur 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. 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 and concise. Navigationally, the error message should provide one or more of: A 'back' link to return to the previous page (particularly for handsets that do not provide a native 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. Whilst some users may understand '404' to mean 'page cannot be found', this must not be assumed to be true for all users. 5.2.5 User Preferences Where possible capture and apply user preferences. What it means In view of the difficulties relating to user input and the limitations of the screen that are usually associated with mobile devices, capturing user preferences and applying them can significantly aid usability. How to do it User preferences related to user experience choices, may be managed by the user agent responsible for rendering some Web content. User preferences related to application personalization could also be transmitted as part of the delivery context. The W3C DIWG has been active formulating a draft recommendation for delivery context. See [Techniques] for a detailed discussion of use of CC/PP and UAProf to support user preferences.
5.2.7 [Other general things] [should we have some general exhortations as to simplicity, keeping retrievals small, reducing round trips, and not sending things the device can't do anything with?] [Session management and cookies ... do we need some thing on this?]

5.3 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.3.4 5.2.4 Thematic Consistency of Resource Identified by a URI

Links must

[THEMATIC_CONSISTENCY] Ensure that links provide a thematically coherent experience when accessed from a device other than the one on which they were captured. (Informative)

5.3.7 5.2.7 Link Target Identification

Clearly identify links to content that

5.3.8 5.2.8 Image Maps

[IMAGE_MAPS] Do not use image maps unless you know the target client supports them and has sufficient screen real estate 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 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 map. (Normative)

5.3.9 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 user. (Normative)

[AUTO_REFRESH] Do not create periodically auto-refreshing pages 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 HTTP 3xx codes codes. (Normative)

5.4 5.3 Page Layout and 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.4.1 5.3.1 Page Content

Content should be

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

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

Content should be limited

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

5.4.3 5.3.2 Page Size

Pages should be divided

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


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

5.4.4 5.3.3 Scrolling

Where possible,

[SCROLLING] Limit scrolling should be in to one direction Where an object direction, unless secondary scrolling cannot be presented without avoided. (Normative)

[SCROLLING_LIMIT] Limit secondary scrolling it must not cause the rest of the page to objects that require scrolling it, where it cannot be avoided. (Normative)

5.4.5 5.3.4 Navigation Bars etc. [Extraneous material] (Extraneous material)


[CENTRAL_MEANING] Ensure that material that is not central to the meaning of the page should not precede precedes material that is. is not. (Normative)

5.5 5.4 Page Definition

5.5.5 5.4.5 Non Text Items

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

[OBJECTS_OR_SCRIPT] Do not embed objects or script in pages unless you know the device supports them When an appropriate markup language exists use markup rather than images to convey information if the device supports it. Always specify the size of images in markup When resizing images do so at the server them. (Normative)

5.5.7 5.4.8 Measures

In general,

[MEASURES] Do not use pixel measures and do not use relative rather than absolute units in markup language attribute values and style sheet property values Do not specify an absolute page width Reduce the number of different font sizes values. (Normative)

5.5.8 Semantic Markup Semantic Markup (tbd) should be included to indicate the purpose of content Provide information about document collections (i.e. documents comprising multiple pages)

5.5.9 5.4.9 Style Sheets

If the client supports

[STYLE_SHEETS_USE] Use style sheets, use this mechanism sheets to control layout and presentation presentation, unless the device is known not to support them. (Normative)

[STYLE_SHEETS_SUPPORT] Organize documents so that they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets it must still be possible to read the document (Normative)

[STYLE_SHEETS_SIZE] Keep style sheets as small as possible. (Normative)

5.5.10 5.4.10 Minimize

[MINIMIZE] Use terse efficient markup markup. (Normative)

5.5.11 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.5.12 5.4.12 Character Set Encoding

[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character set 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) 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.6 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.6.1 5.5.1 Input

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

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

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

Use selection lists where possible

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

5.6.4 Language Identification
Clearly identify changes in the natural language of a document's text and any text equivalents. What it means 6 Conformance and mobileOK (Normative)

This provision is particularly relevant Conformance to predictive text input. How this document requires conformance to do it each and every one of the Statements, except where required to satisfy the needs of deficient implementations as noted under [ DEFICIENCIES ].

Use xml:lang attributes if appropriate All of the Best Practice Statements have a fragment identifier to allow formal reference to them and allow the mark up language in question, or equivalent mechanisms in other markup languages. construction of compliance claims that refer to them.

The default language 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 document may also trustmark, which will be specified using based on some profile, or subset, of the Content-Language http header. Statements in this document.

As such, the mobileOK trustmark will serve as the main conformance claim for the best practices document. What it means

6 Techniques A Sources (Non-Normative)

[to be done after The best practices agreed] 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 the members of the Best Practices Working Group BPWG for their 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:

  • Greg Aaron *, Aaron, Afilias Limited
  • Manuel Alvarez *, elmundo.es Daniel Appelquist *, Appelquist, Vodafone
  • Phil Archer *, Internet Content Rating Association Stéphane Boyera , W3C/ERCIM Emiliano Ceraldi *, TIM Italia SpA Yih-Farn (Robin) Chen *, AT&T Jyri Hagman *, Nokia Rotan Hanrahan *, Hanrahan, MobileAware
  • Martin Harris *, America Online, Inc. (AOL) Dominique Hazaël-Massieux *, Hazaël-Massieux, W3C/ERCIM
  • Philipp Hoschka *, Hoschka, W3C/ERCIM
  • Scott Hughes *, Vodafone Dean Jackson *, W3C/Keio Rittwik Jana *, AT&T Jonathan Jeon *, Electronics and Telecommunications Research Institute (ETRI) Richard Kennedy *, T. Kennedy, The Boeing Company
  • Kazuhiro Kitagawa, NTT DoCoMo Kevin Lawver *, America Online, Inc. (AOL) Rhys Lewis *, Lewis, Volantis Systems Ltd
  • Roger Lindsjö, Drutt Magnus Lönnroth, Drutt Ron Mandel *, Openwave Systems Inc. Ignacio Marín *, Fundación CTIC (Centro Tecnológico para el Desarrollo en Asturias de las Tecnologías de la Información y la Comunicación) Timur Mehrvarz *, Vodafone Roland Merrick, IBM Edward Mitukiewicz *, France Telecom Ram Mohan *, Afilias Limited Tim Moss, Bango Giorgio Natili *, International Webmasters Association / HTML Writers Guild (IWA-HWG) Sean Owen *, Google, Inc. Luca Passani *, Passani, Openwave Systems Inc.
  • Giles Payne *, Payne, NTT DoCoMo
  • James Pearce *, Pearce, Argo Interactive Ltd
  • Mark Peden, Rulespace Kimmo Raatikainen *, University of Helsinki Arun Ranganathan *, America Online, Inc. (AOL) Ove Ranheim *, Opera Software Stefano Sabatini *, TIM Italia SpA Kai-Dietrich Scheppe *, Scheppe, T-Online International AG
  • Donatella Sergi *, TIM Italia SpA Paul Sponagl *, Sevenval AG Peter Stark *, Ericsson Carl Taylor, Hutchison 3G David Torres *, Fundación ONCE Andrea Trasatti *, Trasatti, W3C Invited Expert
  • Paul Walsh *, Walsh, Segala M Test
  • Keith Waters, France Telecom Andy Wilson, Intel Matt Womer, France Telecom Chris Yanda, BBC
The editors apologize if anyone's name has accidentally been left off the list and invite people to remind us by mail so this can be corrected in future drafts.

C References (Non-Normative)

"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/.) http://www.w3.org/TR/mobile-bp-scope/ .)
Mobile Web Techniques for Best Practices [to be published]
mobileOK Trustmark [to be published]
"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.) http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 .)
DI WG References Device Independence Principles, W3C Note, R. Gimson 1 September 2003 (See http://www.w3.org/2001/di/Group/.) http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ .)
Delivery Context Overview for Device Independence Independence, W3C Note, R. Gimson and R. Lewis 18 January 2005 (See http://www.w3.org/TR/di-dco/.) http://www.w3.org/TR/di-dco/ .)
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/ .)
The HTTP charset parameter, Martin J. Dürst 22 September 1999 (See http://www.w3.org/International/O-HTTP-charset .)
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 FAQ How do I get a customized error page? (See http://tomcat.apache.org/faq/misc.html#error .)
Apache Core Features ErrorDocument directive (See http://httpd.apache.org/docs/1.3/mod/core.html#errordocument .)
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 .)
CDF WG References (See http://www.w3.org/2004/CDF/Group/.) http://www.w3.org/2004/CDF/Group/ .)
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 (See http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf.) http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf .)
Opera's Making Small Devices Look Great (See http://my.opera.com/community/dev/device/.) http://my.opera.com/community/dev/device/ .)
Openwave (See http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm.) http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm .)
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.) http://sw.nokia.com/id/4f7b6805-47d7-4914-885c-6ef2b487adf6/Series_60_Platform_Designing_XHTML_MP_Content_v1_4_en.pdf .)
Bowsing Browsing on Mobile Phones, paper by Virpi Roto, Nokia (See http://www.research.att.com/~rjana/WF12_Paper1.pdf.) http://www.research.att.com/~rjana/WF12_Paper1.pdf .)
Little Spring Design (See http://www.littlespringsdesign.com/design/styleguides.html.) http://www.littlespringsdesign.com/design/styleguides.html .)
PCS Web Style Guide, Vision Edition, XHTML Mobile Profile, Version 1, August, 2002
Study by Segala M Test on Scrolling vs. Pagination (See http://www.mobilefriendly.org .)