This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.

The Best Practices have been written at a level of generality that allows them to be applicable across a range of markup languages. They have been written with enduring properties of mobile access to the Web in mind. While the factors identified in 3.7 Default Delivery Context , such as screen dimensions, will change over time, it seems likely that the distinguishing features of mobile access such as cost and difficulty of input will remain issues.

The BPWG is developing a companion document describing techniques [Techniques] by which the Best Practice statements in this document can be implemented.

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

These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG] . As noted above, WCAG guidelines are supplementary to the Mobile Web Best Practices, whose scope is limited to matters that have a specific mobile relevance.

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.

The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability and device usability are important (for reading, navigating, and interacting with content), this document focuses primarily on Best Practices for improving site usability.

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

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

The Best Practice recommendations refer to delivered content. While they are clearly relevant to the processes of content creation and rendering on devices, they are not intended to be Best Practices for those activities.

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

The document is not targeted solely at developers; others, such as interaction and graphic designers are encouraged to read it.

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.

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

Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.

Delivery Context. Discusses the environment within which mobile access to the Web is realized, with particular reference to adaptation.

Requirements. An illustration of the type of problems that the Best Practices are intended to ameliorate.

The recommendations are offered to creators, maintainers and operators of Web sites and are intended as the basis for assessing conformance to the mobileOK trustmark, which is described in the Mobile Web Best Practices Working Group Charter and is not developed in this document. At the time of writing of this document, documents describing mobileOK and techniques for implementing the Best Practice recommendations are being worked on.

This document sets out a series of recommendations designed to improve the user experience of the Web on mobile devices.

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

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. providing medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time on their wristwatches.

By way of illustration of some of these factors: the Web can go where you go. You do not 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.

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.

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

Some activities associated with rendering Web pages are computationally intensive - for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid markup [T-MOB] . Mobile devices typically have quite limited processing power which means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses more power as does communication with the server.

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 choice of browser and upgrading it is not possible.

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

It is not the intention of the MWI to limit or to restrict advertising; rather it is the intention that the user experience of the site as a whole, including advertising, if any, is as effective as possible.

Developers of commercial Web sites should note that different commercial models are often at work when the Web is accessed from mobile devices as compared with desktop devices. For example, some mechanisms that are commonly used for presentation of advertising material (such as pop-ups, pop-unders and large banners) do not work well on small devices and are therefore contrary to Best Practice recommendations such as [CENTRAL_MEANING], [LARGE_GRAPHICS] and [POP_UPS].

Equally, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available.

Mobile users typically have different interests to users of fixed or desktop devices. They are likely to have more immediate and goal-directed intentions than desktop Web users. Their intentions are often to find out specific pieces of information that are relevant to their context. An example of such a goal-directed application might be the user requiring specific information about schedules for a journey they are currently undertaking.

Web pages can contain content that the user has not specifically requested - especially advertising and large images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.

Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory - for example, larger images may only be viewable in small pieces and require considerable scrolling.

Mobile data transfer often costs money. The fact that mobile devices frequently support only limited types of content means that a user may follow a link and retrieve information that is unusable on their device.

Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency. This can lead to long retrieval times, especially for lengthy content and for content that requires a lot of navigation between pages.

While many modern devices provide back buttons, some do not, and in some cases, where back functionality exists, users may not know how to invoke it. This means that it is often very hard to recover from errors, broken links and so on.

Because of the limitations of screen and input, forms are hard to fill in. This is because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields.

One of the difficulties of the mobile Web is that URIs are very difficult to type. Lengthy URIs and those that contain a lot of punctuation are particularly difficult to type correctly.

Mobile device input is often difficult when compared with use of a desktop device equipped with a keyboard. Mobile devices often have only a very limited keypad, with small keys, and there is frequently no pointing device.

It is particularly important in the mobile context to help the user create a mental image of the site. This can be assisted by adopting a consistent style and can be considerably diminished by an uneven style.

Because of the limited screen size, the subject matter of the page may require considerable scrolling to be visible, especially if the top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether their retrieval has resulted in the right content.

Accessing such a Web page on a mobile device often results in a poor or unusable experience. Contributing factors include pages not being laid out as intended. Because of the limited screen size and the limited amount of material that is visible to the user, context and overview are lost.

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.

3 Delivery Context

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

3.1 One Web The recommendations in this document are intended to improve the experience of the Web on mobile devices. While the recommendations 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 the Scope document [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 representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts (see 5.1.1 Thematic Consistency of Resource Identified by a URI). Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (for instance 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 that have a primarily desktop appeal (lengthy reference material, rich images, for example). 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 as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations. From the perspective of this document this means that services should be available as some variant of HTML over HTTP (see 3.7 Default Delivery Context).

3.2 Background to Adaptation 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 devices. For example different devices support different markup features and different screen sizes may demand different sized images. Consequently, it is very common when delivering content to mobile devices to vary the details of the markup, format of images, image sizes, color depths and so on to suit the characteristics of the device in question. The process of altering content to enhance the user experience on particular devices is referred to as Content Adaptation. We do not describe adaptation in detail in 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 Description Working Group, is currently defining requirements for a repository of mobile device characteristics that are relevant to content adaptation.

3.3 Adaptation Implementation Model There are a number of different implementation models for content adaptation. On the one hand, adaptation may be quite simple and consist of determining the device type and choosing the most appropriate set of previously prepared content to match the device characteristics. At the other extreme it may be carried out in a completely dynamic way, with content formatted at the time of retrieval, taking into account not only statically determined properties, such as screen dimension, but also dynamically determined properties, such as the temporary attachment of a fully featured keyboard. Adaptation can be carried out in a number of different points in the delivery of content to the device [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 device. Client Side adaptation consists of the device accepting content and displaying it in an appropriate way for its characteristics. Whatever the adaptation model at work, the process of adaptation should not diminish accessibility.

3.4 Assumptions about Adaptation In phase 1 (See 1.4.1 Phasing) it is assumed that content adaptation, if any, is carried out Server Side. Future phases may consider the implications of content adaptation elsewhere, especially the issues concerning the granting of authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address multiple adaptation - i.e. the possibility that adaptation can be applied at more than one point and that In-Network adaptation may occur more than once. It is also assumed 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.

3.5 Establishing Context Providing variations on the user experience that are appropriate in different cases requires the content provider to know a significant amount about the 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 contexts the need for such information is diminished when compared with a sophisticated site that has an optimized navigation structure, presents different size images or carries out other adaptations to suit the particular delivery context. There are several methods by which a content provider can discover information about the delivery context, such as CC/PP, UAPROF, CSS Media Queries and various outputs of the Device Independence Working Group. The companion Techniques [Techniques] document describes these methods.

3.6 Choice of User Experience In the interests of "One Web" (see 3.1 One Web) considerations, the content provider may choose to allow the user to select from broad categories such as mobile or desktop presentation, where these are distinguished in the application. If the presentation option has been determined automatically, the content provider may choose to allow the user to override the automatic determination. Where a choice of presentations is available, it is good practice to record the user's preferences and to allow them to be changed. Given an appropriate server environment, it is unlikely that the content provider will be unable to find out anything about the delivery context. However this can happen, either because details of the delivery context are not available in sufficient detail or because the server does not provide the ability to inspect and act on the information provided. In this case 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).