Mobile Web Best Practices 1.0

1 Introduction

1.1 Purpose of the Document

The document contains a list of best practices and discussion around the assertions made for content on the Web so that it is delivered effectively to mobile devices. It also contains information about how to implement sites that conform to those best practices.

The document is intended to provide guidance to players 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 intended as the basis for assessing conformance to the requirements of the MobileOK trustmark. The idea for the MobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter

We do not develop the idea of mobileOK in this revision of this document. Future revisions may contain a discussion of mobileOK.

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

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.2.1 Players in the Mobile Value Chain

Players in the mobile value chain include:

Web Site Developers: Original content developers together with portal operators and other aggregators of content who deliver non-original content to mobile and other users.
Mobile Network Operators: Who may transform content when it passes from the Internet to their networks, and who may in addition operate portals.
Browser and Delivery Platform Developers: Who realize content for users to perceive.
Authoring Tool Developers: Developers of tools to assist with content production (authoring).
Content Manipulation Tools Developers: Developers of tools to assist with content serving and repurposing.
Conformance Testers: Those involved in the production and execution of testing processes.

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 browsing experience to be more usable on mobile devices.

The charter of the group is to specify best practices for delivery to mobile devices. Hence best practice statements that do not specifically have a 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.

1.3.1 Phasing

As discussed in [Scope] the are many aspects to Mobile Web Best Practices.

One of those aspects is that, at present, the design and construction of many Web sites and pages make for a poor user experience when those sites and pages 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.

1.3.2 Usability

There are three aspects of mobile usability - namely site, device, and browser usability. All three together contribute to the user experience.

We define these three aspects as follows:

Site usability relates to the structure, content and layout rules of a site and is a measure of the effectiveness of the mobile web site.

Device usability pertains to the capability of the equipment being used easily and effectively. "Easily" refers to a specified level of acceptability and comfort of use; "Efficiency" relates to the resources expended in relation to the accuracy and completeness with which users achieve their goals. In particular, device usability focuses on keypad design, display, fast browser access and UI styles.

Browser usability defines the ease of using a browser effectively namely performing the three functions reading, navigating or interacting. The ease of interaction, page rendering, caching etc. are issues that are frequently used to judge browser usability.

While recognizing the contribution of device and browser usability to the overall user experience, this document focuses on site usability.

1.3.3 Boundaries of the Best Practice Guidelines

This section describes what the Best Practices are trying to achieve, and what they are not.

1.3.3.1 A Reasonable User Experience

The MWI in this phase [See Phasing] is concerned with establishing a set of guidelines that help content providers achieve the best possible experience of their Web content - given the client and network limitations that are encountered in the mobile delivery of Web content [see Requirements for a discussion of these]. A reasonable experience of the Web cannot be achieved on clients that exhibit too many of the limitations discussed or where one or other of the limitations is very severe.

In saying this it is recognized that any judgment of what is a reasonable experience is made at a particular point in time and from particular cultural perspective. It is also recognized that it is possible to achieve a reasonable experience of non-Web services in the presence of such limitations and that that there are at present many such services, often implemented using WAP 1.x technologies. The intention, however, of the Mobile Web Initiative, is to extend the reach of the Web to mobile devices. Hence such non Web services are out of scope of this discussion.

1.3.3.5 Which Formats are in Scope?

Similarly to the [WCAG] the best practice recommendations are couched at a level of generality that allows them to 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 as [CDFWG].

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

Baseline conformant devices have been available for some years, and are in common use in many markets. The recommendations encourage the use of features that go beyond the baseline, that have been and will continue to be introduced in new devices. However, since the MWI Phase 1 refers only to 'traditional' browsing it does not establish best practices for those features.

1.3.3.7 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 is anticipated that the best practice recommendations will change at a slower pace than the definition of the baseline device.

As mentioned above, the definition of a baseline device is with 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 in different regions of the world, with more developed economies having access to a wider range of more fully featured clients.

1.3.3.8 Implementation Issues

The notion of a baseline client is an abstract notion. No specific real device is targeted. Rather, it is an abstraction of 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 the features described. It is considered good practice to work around implementation defects of real devices. However, it is not in scope of best practices to itemize known defects and limitations nor to detail techniques or examples of how to do this. See [] for references as to known device and client limitations.

1.3.3.9 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 is hoped that by providing a baseline definition creators of devices and clients will be encouraged to produce devices that meet or exceed the baseline definition. It is also hoped that those commissioning or setting standards for such devices will require implementation of baseline features to a reasonable standard of completeness and quality.

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 is supplemented by a 'local' default device, which may have either greater or lesser functionality when compared with the baseline.

The group would value feedback both on which parameters are to be specified and what the values for those parameters should be.

The following are for illustration only.

Format

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.

Usable Screen Size

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.

Colors

Varying opinions again on this.

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

Other

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

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 of the words must, should and may should not be interpreted as having the meanings defined in RFC2119.

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 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 of the Device Independence Working Group [DIWG] has a direct and fundamental relevance to this document.

3 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.1 User Experience

Many Web pages today are laid out with presentation on desktop size displays in mind, and make use of the facilities provided by desktop browsing software.

Accessing such a Web page on a mobile device often results in a poor, or unusable experience. Contributing to this poor experience is that the content does not lay out as intended, and because of the limited screen size and the limited amount of material on the page that is visible to the user, things that are intended to be viewed together are not presented together - context and overview are lost.

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.

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 contrariwise can be considerably diminished by an uneven style.

3.2 Input

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

It's perhaps a paradox of the mobile web that URLs are very hard to type, and lengthy URLs and those that contain a lot of punctuation are particularly hard to type correctly. Bookmarking, while often supported, sometimes does not achieve the expected result.

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

There is frequently no back button, which means that it is often very hard to recover from errors, broken links and so on.

3.3 Bandwidth and Cost

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

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.

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.

Requests for web pages can result in the delivery of content that the user has not specifically requested - especially advertising and large site images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.

3.4 Content Type

Mobile users typically have different interests to users of fixed or desktop devices. Mobile users 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. Examples frequently include travel related applications, where the user requires specific information about train times.

Other examples often include time filling applications, where people are filling otherwise dead time while traveling, and entertainment related applications are often noted as being appropriate.

On the other hand, 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.

3.5 Advertising

Developers of commercial web sites should note that different commercial models are often at work when the Web is access from Mobile devices as compared with fixed line access, see [some reference TBD], for information. For example, some mechanisms that are commonly used for presentation of advertising material do not work well on small devices and are therefore contrary to the Best Practice Recommendations.

It's 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.

3.6 Device Limitations

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

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

Some activities associated with rendering web pages are computationally intensive. 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 Advantages

[The group notes that as well as having limitations mobile devices also have advantages when compared with desktop or laptop devices. This section to be developed to elucidate this point.]

4 Delivery Model Architecture

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

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

The remainder of this section outlines content adaptation in order to provide a background to this document. It is not intended as a comprehensive guide or to be definitive. The Device Independence Working Group [DIWG] has published a great deal of material relevant to this subject. Readers are expecially referred to "Delivery Context Overview for Device Independence" [DCODI].

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.1 Adaptation Implementation Model

There is quite a wide spectrum of implementation models for content adaptation. On the one hand it 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 client [see DIWG work and Device Description Landscape paper for more detailed discussion].

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 that was originally purposed for another device and displaying it with appropriate reformatting.

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

Various BPWG group meetings and discussions.
WCAG Guidelines 1.0 [WCAG]
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

5.1.2 How this section is organized

The best practice statements are organized under the headings of:

Overall Behavior: General Best Practice Statements
Navigation and Links: This section contains statements that relate to navigation and linking mechanisms
Page Layout and Content: The section contains statements that relate to the content of pages and how they lay out
Page Definition: Statements that relate to the technical construction of pages
Input: Statements that relate to Input

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

This is a best practice statement

What it means

Explanation of the significance of the statements under this heading

How to do it

Discussion of techniques, usually a reference to the relevant section of this document [not much filled in in this revision]

References and Sources

Discussion of similar and related points and supporting references especially those from the list above.[usually missing in this version, a shorthand reference being provided directly against the statement(s) itself/themselves]

Testability

Outline discussion of how amenable this is to automated testing. [almost totally missing in this revision]

Many of the best practice statements rely on the implementation 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 the implementation. For simple sites which 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 is not recognized or its capabilities cannot be determined a reasonable default experience should be provided. In this case a warning should be provided and the implementation should provide the ability for the user to select the device type in use. Where possible the user's selection of a device type should persist across visits to the implementation, but should be changeable.

The warning provided while making it clear that the experience may not be optimal for the user, should be minimally intrusive to the experience of the information and as far as possible should be consistent with other recommendations.

It is not the intention that encouraging implementations to be sensitive to the needs of baseline devices should result in a diminished experience on more capable devices. Specifically it is not the intention the encourage the development of sites that have a uniform baseline targeted presentation when a better user experience could be attained on more capable devices.

Just as in the desktop browser world, there are differences in interpretation between browsers and there are also deficiencies in implementation. Because the software in mobile devices is frequently embedded in the device there is no easy way to correct or enhance software once it is in the field. It's a particular challenge to provide work-arounds for these deficiencies and differences in interpretation.

Just as it is not the intention to recommend a least common denominator approach, it's not the intention to recommend non-use of features which exhibit problems on some class of devices.

It's also not the intention to suggest that implementations should restrict their support to certain client types. Implementations should aim to support as wide a range of client types as is practical.

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.

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

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.6 Testing

Carry out testing on actual devices as well as emulators.

5.2.6.1 What it means

Any web site should be tested in a range of browsers. Mobile browsers often show markedly different characteristics to desktop browsers. As well as assessing a site's suitability for display in reduced format, authors are encouraged to test that the features they rely on work in actual devices.

5.2.6.2 How to do it

Many manufacturers provide emulators for their device that can provide a convenient preliminary means of testing. However, in practice, many of the emulators behave in a different way to the devices they emulate. Consequently testing should be carried out in as wide a range of real devices as is practical.

The user should not need to type the default page filename. See [Techniques] for a more detailed discussion on the structure of sites, and especially the choice of whether to use subdomains or folders (i.e. timetables.foo.com vs. www.foo.com/timetables)

The design should aim to balance between providing an excessive number of navigation links on a page and the need to navigate multiple links to reach content. Each retrieval of a navigation page takes time, and adds cost, so the number of links on a page should not be minimized at the expense of adding page retrievals.

5.3.4 Thematic Consistency of Resource Identified by a URI

Links must provide a thematically coherent experience when accessed from a device other than the one on which they were captured.

5.3.4.1 What it means

The representation of a URI (the page that is delivered when a device accesses a URI) may not look the same or contain identical content when accessed from different devices, because in the interests of usable site navigation the pagination may be different for different devices and in the in order to use capabilities of different devices appropriately it may look different.

However, an important principle of One Web [link] is that a URI should be usable on any device. So if a user of one device sends a bookmark, or link, to another user that does not have the same device, their intention in sending that URI must be respected and the second user should be presented with information that the first user had intended to communicate.

Intelligent grouping, perhaps optimized through adaptation according to usage patterns can assist usability.

5.3.5.2 How to do it

A "drill-down" method, based on major headings, can often provide an effective means of navigation. And because of the linearized arrangement of content, small screen size and lack of pointing device, it is often useful to provide a means to jump entire sections of content.

At each target of the drill down navigation an "up" link should be provided to allow the user to jump up an entire section.

See [Techniques] for further discussion of site navigation mechansims.

Users of mobile devices may suffer undue delay and cost as a result of following links. It's important to identify where a link leads so users can make an assessment of whether following it will be of interest to them. While implementations are unlikely to be able to specify the cost in monetary terms of a particular user following a particular link, it should be possible to give an idea of the size of the resource [in bytes or in an abstract way e.g. large file].

Links to content that is in a different format to the format of the page the link is on (i.e. content that can only be interpreted by other applications, downloads) should be human signposted, so that users are not lead to download content that their device may not be able to use.

Do not use image maps unless you know the target client supports them and has sufficient screen real estate 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

Do not use a server side image map unless you know that the client provides a means of selection within the image map

5.3.8.1 What it means

Image maps allow fast navigation providing the requesting device can support the image involved and providing there is a means of navigating the map satisfactorily. Up, down, left, right, enter are available on most mobile devices, even if no pointing device is present, and this is usually sufficient to allow navigation of the active regions of client side image maps.

Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of http 3xx codes

5.3.9.1 What it means

Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction. Many mobile devices cannot support more than one window and consequently attempting to open one will have unpredictable results. In general, the users consent should be sought before initiating the download of content.

While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser which adds to delay on slow links. Hence redirection should not be used as a matter of course.

Content should be limited to what the user has requested

5.4.1.1 What it means

Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information, and while providing the option to access all information, should offer appropriate information first.

The general prescription to use clear language is of particular importance in the mobile context where brevity and directness are generally more desirable than a discursive style.

Writing content in the traditional journalistic 'front loaded' style can assist users determining whether information is of interest to them and allow them to skip it more easily if it is not. [It also assists with some summarization and truncation techniques]. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area.

In many cases the user pays for bandwidth in the mobile context, and offering the user content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience.

On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. Since, in the mobile environment, each request typically takes a measurable time to complete, this can lead to an unnecessary delay.

The balance between pagination and scrolling is partly a matter of taste and partly a matter of necessity. Devices with severe memory restrictions can only have small pages delivered to them. Equally some devices offer a poor scrolling experience, and a better page retrieval experience.

If some element on the page requires two way scrolling it must not cause the remainder of the page to require this. For example, if an object causes subsequent text to lay out with a significant margin to its left, then this text may not be visible once a user has scrolled past the object.

Equally, if the presence of such an object causes text to lay out beyond the right boundary of the page then the user will be required to scroll to read each line of text.

Many Web pages are designed with significant navigational and other elements at the top of, or to the side of the page (e.g. Menu Bars, Breadcrumb Trails, Search Functions). This provides a convenient and well-understood navigational metaphor on large displays. However, on small displays this can result in the navigation appearing instead of the actual content of the page when the page is first retrieved.

Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page.The user should not have to scroll significantly to find the primary content of the the page.

5.4.5.2 How to do it

Menu selections can be placed further down the page with a simple link at the top of the page that allows the user to select navigation from the top of the page, Or use meta navigation on top of the page with simple text links to major sections of the web site.

Keep the number of colors to a minimum

5.4.7.1 What it means

Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence relying on color highlighting of information may not be visible to users. If color is used to indicate a feature it is a good idea to indicate that feature in a non color dependent way. In particular, don't use blue or purple text, as this may be confused with hyper-links, especially on device that do not underline links.

The client may use the page title as the default label for bookmarks. Again space may be limited so use it to help identify the content and not for other purposes.

Mark up quotations

5.5.3.1 What it means

It is good practice for all but the simplest documents to indicate their structure through headings and sub-headings. Using structural markup, rather than formatting effects, allows easier adaptation of content where it needs to be divided into several pages as well as potentially facilitating access only to the sections of the document that a user is interested in.

Where headers are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.

Structural markup must not be used solely to create a font effect.

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

5.5.5.1 What it means

Downloading images to a mobile client requires the browser to fetch images and to download them, which adds to the time to display an image and the cost of displaying the page. Making the page readable in text only mode can help the user assess its usefulness before images arrive.

Many mobile clients do not support embedded objects or script and in many cases it is not possible for users to down load plug-ins to add support. Content must be designed with this in mind.

Resizing images at the server and specifying their size in mark up assists the browser to flow the text, reduces amount of data transferred and the amount of processing the client has to carry out to scale the image.

5.5.5.2 How to do it

Design pages as though they were to be displayed on a text-only browser.

Always use features of the markup designed to support alternate rendering such as the longdesc and alt attributes in XHTML

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.

Reduce the number of different font sizes

5.5.7.1 What it means

Avoiding absolute measures allows the browser to adapt content to fit the display. An exception to this being where an image has been specifically sized for a display, references to the image in markup may specify the exact dimensions of the image in order to help the browser to flow the page, and avoid re-flowing it after the page has been retrieved.

Keep style sheets as small as possible.

5.5.9.1 What it means

Clients provide several levels of support for style sheets. Some provide full implementations including caching of external style sheets. Some do not cache external style sheets, and for these devices embedding the style information in the delivered page is more efficient than the browser making repeated retrievals for the style sheet across a site. Some implementations do not support style sheets at all.

Transferring content that a client cannot display wastes users time and money. Preference may be expressed by a client for one format rather than another. In this case it is good practice to respect the client's preference - as it may have a fuller implementation of its preferred markup.

5.5.11.2 How to do it

Web sites should use a combination of HTTP User-Agent and Accept headers, UAProf and other device profile information to determine what formats a device supports.

There are problems with using any one approach to the exclusion of the others. Some issues that have been noted by the BPWG in this context are:

Not all devices supply accept headers
Some devices state that they accept all formats */* when they do not support some common formats, and also mis-state their capabilities
Some operator gateways supplement the accept headers as they adapt content presented in formats that the device does not accept
User Agent headers do not always uniquely identify the device
UAProf information may not be available or may be incomplete

Further detailed discussion of heuristics for determining which formats a device supports is contained in [Techniques].

Example:
<?xml version="1.0" encoding="UTF-8"?>

The character encoding being used in a response may be indicated using the HTTP Content-Type header.

Example:
Content-Type: text/html; charset=utf-8

These mean use the label element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the control so re-flowing or or adapting the content intelligently will always recognize label controls and keep them together.