Luca Passani
by Luca Passani

Practitioners Alternative to MWI BP (Best Practices) from W3C.
Motivation behind the GAP document and background information.

Table of Content

1 Introduction
  1.1 Prerequisites
  1.2 What is XHTML MP 1.0?
  1.3 Challenges of Mobile Development
  1.4 Device Market Fragmentation
  1.5 The Importance of Content Adaptation (AKA Multiserving).
  1.6 the Role of WML as a Universal Mark-up for Mobile
  1.7 the Role of HTML as a Universal Mark-up for Mobile
  1.8 Other Mobile Technologies
  1.9 Definition of Least Common Denominator (LCD)
  1.10 Motivation for this Authoring Guide
  1.11 Assumption on devices: the Baseline
2 Practices for XHTML MP
  2.1 Best Practices = Adaptation
  2.2 Groupings of Practices
  2.3 Structure of Practice Statement
3 Practices
  3.1 Development
  3.2 Usability
  3.3 Elevating the baseline
4 How to contribute to this document
5 Templates
6 References

Practice Quick Index
[VALID_XHTMLMP] Make sure that mobile pages are valid XHTML Mobile Profile 1.0
[MULTITEST] Test an application on at least 5 different microbrowsers
[MIME_TYPE] Use the application/vnd.wap.xhtml+xml MIME Type
[SIMPLE_CSS] Only use simple in-line CSS or none
[FEW_IMAGES] Keep the number of images in a page down
[ENCODING] Use UTF-8 encoding or better for non-english content
[BEWARE_OF_COLORED_LINKS] Do not try to color links
[AVOID_BACKGROUNDS] Avoid background pictures
[NO_VERTICAL_SPACE] Avoid Vertical Whitespace
[SPECIFIC] Place the most specific menu items in the top positions of menus
[ACCESS_KEYS] Use the 'accesskey' attribute to implementkeyboard accelerators on menus
[NAVIGATION] Provide consistently used links to navigate inside the application
[NO_TOP_BAR] Avoid navigation bars at the top of the page
[NO_REDUNDANCY] Avoid repeating links such as 'Help','About','FAQ' in every page
[NO_SPLASH_SCREEN] Avoid first pages made to be skipped
[ADD_TITLE] Provide a short but descriptive page title
[CONCISE] Use clear, short and concise terms and sentences
[DIFFERENT_MEDIA] Do not serve a website to a mobile device and do not serve a mobile site to a web browser
[USE_SHORT_URL] Adopt a short URL for site entry point(s)
[EXPLOIT_CACHE] Do not disable caching (unless low page lifetime is part of actual business model)
[INPUT_MASK] Use input masks to minimize user input
[BEWARE_OF_FORMS] Beware of HTML-style forms
[AVOID_LOGINS] Do not require that users login each time
[NO_PASSWORD_MASK] Do not mask user input when entering a password
[BEWARE_OF_COOKIES] Carefully evaluate how cookies are used in the application. Cookies may or may not work on some networks and/or some devices
[NO_BIG_PAGE] Delivered mark-up and images should not exceed 10 Kilobyte totally
[SMALL_PICTURES] Do not deliver pictures that are wider than the screen
[STATE_IMAGE_SIZE] Specify the real image width and image height in the mark-up
[MINIMIZE] Minimize the number of clicks required to carry out activities
[STILL_A_PHONE] Enable one-click calls for phone numers
[MAX_10_LINKS] Only exceed 10 links per page if the application demands it
[NO_WEB] Do not try to port all functions of a website to mobile
[NO_MWI_BP] Beware of W3C MWI Best Practices
[TESTING] Find real, non-techie users and make them perform functions. Observe what problems they have
[FIND_BASELINE] Try to identify own project's device baseline
[UPGRADE_EXPERIENCE] Review practices and fine-tune content accordingly

Global Authoring Practices
for the Mobile Web

Public Draft:
Version 1.0.4
Official URL:
Author & Editor:
Luca Passani, luca dot passani at gmail dot com
Last Update:
April 2010
Reviews and Contributions:
James Pearce, Argogroup
Marten van Wezel
Martin Kindler,
Cédric Bénazech, Atos Origin


This document gives general guidelines for web developers and content authors who are searching for directions to help create sites for the mobile web.

While this document clearly appreciates that mobile web development poses extra challenges to authors (as compared to the traditional WWW) and encourages developers to explore techniques to deliver content in context-sensitive manners (adaptation), the objective of the document is to explain how to get the best user-experience out of a (potentially static) XHTML-MP 1.0 page.
This one-size-fits-all approach is sometimes referred to as Least Common Denominator (LCD). While content adaptation is more likely to provide a better user-experience than LCD, it is recognized that some developers/authors may not be using adaptation for a variety of reasons.
This document is a guide about how to get the most out of single non-dinamically generated XHTML MP pages and, at the same time, it educates developers about common pitfalls in the design of mobile services.

It is assumed that the reader is familiar with HTML and the creation of web sites. Understanding of XHTML 1.0, XHTML Mobile Profile 1.0 and HTTP is a plus.

The terms mobile application, mobile document, mobile page and mobile service will be used interchangeably througout the document, since the practices provided by this document apply to both content authors and application developers.

Note to the Reader: Pressing the 't' key will make you snap back to the top from wherever you are in the document. Also 'b'= snap to bottom and 'p' = snap to Practices section.

1 Introduction

This document presents a set of practices to support the creation of acceptably usable mobile services based on XHTML-Mobile Profile 1.0.

The audience of the Global Authoring Practices are developers and content authors who are creating mobile sites for the first time

1.1 Prerequisites

The document assumes that the reader is, as a minimum, familiar with HTML and the basics of web site creation.
Preferably, the reader should also be familiar with XHTML 1.0, which is the normalization of HTML into an XML-based format by W3C.

1.2 What is XHTML MP 1.0?

XHTML Mobile Profile is the mark-up most widely supported by browsers on mobile devices (microbrowsers).
Technically, XHTML MP is built on top of XHTML-basic, a subset of XHTML 1.0 defined by W3C and originally also intended for mobile devices, even though adoption of XHTML Basic by device manufacturers has been limited.

XHTML Mobile Profile 1.0 (XHTML MP, defined by the OMA, the Open Mobile Alliance) adds extra usability and graphical features through the introduction of WAP CSS (WCSS) and the 'style' tag and attribute.
Since XHTML basic is a subset of XHTML MP, the majority of devices can also manage XHTML-basic content.
Evolution can be summarized as follows:

HTML 4 -> XHTML 1.0 -> XHTML Basic -> XHTML MP.

The reference section at the end of the document provides links to XHTML MP tutorials ([XHTMLTUT]) and reference material [XHTMLREF].

A note about the Japanese Market: Japan represents a world of its own when it comes to the mobile internet. Not only has NTT DoCoMo endorsed cHTML (Compact HTML, a subset of HTML 4) as the mark-up for mobile in the i-Mode platform, but the level of consistency in cHTML support by Japanese devices is solid and consistent enough that Japanese developers are better served by referring to their own styleguides and reference materials when addressing the Japanese market. While those developers may find interest in reading this document, they will need to come up with their own understanding of how the practices can be applied to the their market.

1.3 Challenges of Mobile Development

Mobile devices have several limitations when compared to desktop PCs and laptops.

  • Small screens
  • Limited input capabilities
  • Limited processor power and memory
  • Limited bandwidth

In addition, there are also relevant differences in the value users assign to services depending on how critical that information is. Time and cost are factors that discourage users of a given web site from accessing its mobile counterpart:

  • Web and mobile offer each a different value propositions to users.

These limitations have serious implications on the way one should design his/her mobile site.

1.3.1 Small screens

Navigating with a web browser is a more pleasant experience than doing the same with a mobile device. Mobile devices have small screens. Even today, the average mobile device allows for 20/25 character per line and 5/7 lines of visible text. In these conditions, simply scaling down a web site to fit a mobile device is bound to be catastrophic in terms of user experience.

1.3.2 Limited Input Capabilities

The majority of mobile devices are phones with a numeric keypad. While this is sufficient for dialing phone numbers, entering text with it is a time consuming, at times even annoying, activity, when compared to a QWERTY PC keyboards.
This is a key aspect to remember when designing interaction for applications.

1.3.3 Limited Processor Power

Aligning mobile devices with the capabilities of a PC is a never-ending catch up activity for device manufacturers. Microbrowsers are designed to scale down well on devices that are primarily built to allow voice communication, while keeping the form factor acceptable to consumers that will constantly carry the device around with them.
This is an aspect to remember when trying to port web functionalities that rely on CSS, Document Object Model manipulation or scripting to a mobile device.

1.3.4 Limited and Expensive Bandwidth

Mobile devices have little bandwidth available when compared with PCs on the Internet. With the advent of 3G (EDGE, UMTS, HSDPA) the situation has improved for some users, but a lot of other users (or 3G users themselves when roaming out of 3G coverage) can count on a speed down to just a few kilobytes per second (GSM, GPRS). Latency introduced by the time needed to establish a connection should also be accounted for.
While some operators offer flat-fees also for mobile navigation, others still charge by connection time or volume. This aspect should be considered and large graphics should be avoided.

1.3.5 Different Value Propositions for Users

Creating the mobile version of an existing website does not make sense in all cases. For example:

  • Reading news, accessing email and looking at the price of stocks are typical examples of the kind of activities that users may want ot perform while they are mobile.
  • Doing research related to their work is something even the most advanced users will prefer to delay until they sit by their PCs in the comfort of their homes or offices (and a broadband connection to the Internet).
  • Booking a holiday is something that most people do not want to do through a mobile application: too complicated and the risk of something going wrong is either too high or perceived as such.
    In spite of this, it may make sense for an internet-based travel agency to have a mobile site with last-minute offers in order to catch impulse buyers. In this case, the transaction should be finalized through a phone call to an operator. Not only is talking to an operator faster and less error prone, but connecting to the operator is typically just one click away, since mobile devices are primarily built to make voice calls.

Development of great user experience for mobile is to an extent a "holistic philosophy", or even, an 'art', as much as it is a science that can be codified in a set of rules.
While mobile devices are not as good as fixed browsers when it comes to browsing, it is also possible to look at things the other way around. Telephony, messaging and location-based applications are examples of features that are unique to mobile.
Developers are encouraged to look at these extra possibilities that are typically not part of the web paradigm

1.4 Device Market Fragmentation

Mobile development is difficult because different devices have different features. This aspect is often referred to as 'Device Market Fragmentation' or 'Device Diversity'.

Differences among devices happens along multiple dimensions:

Hardware characteristics
Screen size, Keyboard (numeric vs QUERTY), Stylus,...
Network characteristics
Connection Speed, Bandwidth,...
Multimedia Formats
Browser behavior
Openwave Browser ≠ Nokia Browser ≠ Opera Browser≠ .....
Formatting, speed, image layout,...

XHTML-MP and WCSS support varies greatly from browser to browser.

Device fragmentation is the consequence of several factors:

  • Device manufacturers' drive to differentiate from competitors.
  • Network operators' request to have devices that are unique or customized to their networks.
  • Rapid innovation and advancement in underlying technologies and standards.
  • Devices require an average 18 months from design to first device on the market.
  • Device software is typically not upgraded. Poorly performing software stays around longer.

Because of this, issues related to device fragmentation cannot be expected to disappear any time soon.

1.5 The Importance of Content Adaptation (AKA Multiserving).

The widely varying characteristics of mobile devices effectively disrupt the development model used on the web, where:

  • a relatively rich subset of HTML and CSS can be delivered to web browsers with acceptable results in terms of both design and usability.
  • the dimension of the user's browser window either does not represent an issue or that issue can be addressed by dynamically re-flowing the content.

To achieve an acceptable user experience for mobile sites, authors need to deal with the facts that:

  • There are relevant differences in terms of CSS and XHTML support in microbrowsers.
  • Devices have screen dimensiones in the 90 to 320 pixel range for both width and height.
  • All kind of minor disruptions can occur among devices.

Certain mobile applications can figure out (or, at least, hypothesise) device capabilities on the server-side. This allows the application to send customized content to the requesting device. These applications are 'adapting' the content and the process by which the content is transformed is called 'content adaptation' or 'Multiserving'.

There are many ways to do adaptation. Sending pictures that are the right size for the requesting device is the typical example, but there are other situation where adaptation is desirable. A few examples of adaptation follow:

  • Redirecting devices to either the XHTML or the WML version of a mobile site, depending on which one is best for the requesting device.
  • Adding/hiding links to downloadable content which is known to be supported/not supported by the requesting device.
  • Sending the right MIME-type and character encoding to the requesting device.

Adaptation generally implies looking at HTTP headers used by a device for requests to the application to predict which features are supported by the device. In particular, no adaptation can be achieved with static XHTML-MP documents exclusively.

While some forms of adaptation are indeed simple, as a general rule, adaptation adds extra cost and extra complexity to software projects. While it is recommended that some form of adaptation is adopted by mobile developers, extra costs are bound to be measured against potential benefits.
Actual techniques for adaptation vary widely. Looking at the 'accept' HTTP header is probably the simplest example, there is. Using a fully-fledged framework, such as WURFL [WURFL] requires a deeper understanding of the problems and the tools. Drutt [Drutt], MobileAware [MobileAware], Volantis [Volantis] and others also offer solutions in this space. W3C is also addressing adaptation indirectly with an initiative called [DDWG]. DDWG aims at creating a standard API to access "Device Description Repositories" from different sources.
An open source approach to adaptation that is both simple and powerful is WALL [WALL], the Wireless Abstraction Library, which lets developers code their pages with a mark-up similar to HTML, while delivering WML, XHTML-MP and CHTML mark-up to the requesting devices depending on device capabilities. WALL is a JSP Tag-Library. A port to PHP also exists [WALL4PHP].

Note 1: Some use the term 'adaptation' when referring to the process in which an 'adapting proxy' on the network can re-arrange web content into smaller bits that a mobile device can access (albeit with different degrees of success usability-wise). Typically, adapting proxies are commercial products and network adaptation happens outside of the control of content authors. This kind of adaptation is out of the scope of this document.

Note 2: Some use the term 'adaptation' when referring to the ability of some browsers (notably Opera and Openwave) to columnify web pages when accessed through a mobile device. The process is essentially about:

  • removing table layout
  • placing elements with absolute positioning in the document flow
  • resizing pictures.

The results of this "client-side" adaptation can give interesting results in some cases. Nevertheless, the amount of content that a device needs to download (average web page = ~130 Kb) and the amount of scrolling required of the end user typically compromises usability unacceptably. Client-side adaptation is aimed at web sites and covering it is out of the scope of this document [SmartRendering].

Note 3: Some mobile devices with high resolution (320 pixel width or larger) feature fully-fledged web browsers (such as Safari WebKit). These browsers can visualize all pages and zoom in on parts of the page that require more definition for correct visualization.
Deciding if these browser should be considered web or mobile browsers is up to both the developer and the consumer (who may have conflicting views on the issue in some cases).
Assuming developers want to treat those browsers as microbrowsers, they should be considered as baseline browsers in case LCD is used, or they should be served a better version of the content if adaptation is adopted.
Considering them web browser will place them out of the scope of this document.

1.6 The Role of WML as a Universal Mark-up for Mobile

WML 1.1 [WML] is the mark-up language of the WAP 1.1 [WAP] standard introduced in the late 90s to enable internet on mobile devices. While WML has similiraties with HTML-based markups, there are also relevant differences.

  • WML has the concept of hyperlinks
  • WML has the concept of forms, which can be posted through HTTP


  • WML is XML based.
  • WML has its own MIME type (text/vnd.wap.wml).
  • WML can represent multiple 'cards' (pages) within a single 'deck' (document).
  • WML can program device softkeys (the buttons used to activate items in the native UI).

While WML has been the target of criticism for 'diverging' from established web standards (notably HTML), it has the merit of having made 'physically' clear that web and mobile are different media serving different requirements and different fields of application. Yet another advantage is WML widespread support on mobile devices around the globe: virtually every device produced anywhere over the past 6 years carries a WML microbrowser. While these practices apply to XHTML-MP devices (the mark-up language of WAP 2), it must be recognized that WML is currently the most widely supported mark-up. While this document chooses to identify XHTML-MP as the universal mark-up for mobile, it is recognized that WML may be a better alternative for services that require maximum global accessibility without adaptation and no particular requirement about color-rich graphics.

1.7 The Role of HTML as a Universal Mark-up for Mobile

While multiple versions of HTML [HTML] have been made available to developers over the years, today's predominant coding style on the web is still the one often referred to as "tag soup", i.e. HTML tags are used according to the visual effect they produce on one or more browsers, and not according to strict syntax rules and clear standard-based semantics.

Note: Tag-soup HTML is typically served with text/html conten type. In spite of the fact that usage of tag-soup HTML is frowned upon by those who advocate XML-based XHTML 1.0, it has been argued that much of the success of i-Mode in Japan is due to the choice of "Compact-HTML" (a subset of HTML) as the mobile mark-up: by being lenient with mark-up errors, CHTML has effectively enabled thousands of Japanese users to publish mobile content. Some argue that resilience to HTML errors in web browsers (often referred to as 'quirks mode' HTML parsing) has fueled the exponential growth of web content.

Because of its widespread adoption on the web, most mobile microbrowsers can render 'tag soup' HTML with varying degrees of success. Such generalized support for HTML-based mark-ups has effectively turned HTML into a candidate language for mobile.
Resorting to HTML for mobile development has positive and negative implications for developers.
On the negative side, by adopting HTML, the number of supported devices would be reduced. In addition, some microbrowsers apply heuristics to adapt web content to mobile when the HTML content type (text/html) is encounterd. This can affect the rendering of a page in unexpected ways. Typically, CSS may be ignored and table layout may be disrupted and 'columnified'.
Apple's iPhone will assume that a page served as HTML is a page meant for the full web, and will use tiny fonts also for mobile content, thus forcing users to zoom in and scroll in order to make text readable and be able to select links. This will severely diminish the usability of the site for iPhone users.
Finally, HTML would make errors in mark-up go by undetected, yet those errors would negatively impact the page rendering speed, thus reducing the perceived responsiveness of the system and degrading usability.
On the positive side, by adopting HTML, 'newbies' would not have to deal with the intricacies of XML-based mark-ups, such as: the need to validate content, adding relatively obscure XML prolog/doctypes to each page, manage the configuration of unfamiliar MIME types and so on.
A significant extra advantage with HTML would be the ability to preview mobile content with all web browsers, including MS Internet Explorer, which notoriously cannot handle the XHTML Mime type properly [XHTMLMIME].
While this document elects XHTML-MP as the mark-up of choice for mobile, it is acknowledged that HTML may represent a viable alternative for hobbists and semi-professional mobile authors.
Nevertheless, this document discourages developers from adopting HTML as a mobile mark-up, since the extra effort required by using XHTML MP is limited when compared to the advantages in terms of rendering speed and number of devices supported.
It should be noted that the majority of practices in this document will also apply when HTML is adopted and HTML authors will benefit from reading this document as well.

1.8 Other Mobile Technologies

For completeness, the role of other mobile technologies in the context of this document is briefly discussed.
There are at least three or four major mobile technologies on the market today which allow the creation of usable and graphically pleasant mobile applications. Among these technologies the following are mentioned: Sun's J2ME [J2ME], Macromedia/Adobe's Flash lite [FLASH LITE] and Qualcomm's BREW/uiOne [BREW].
While it is acknowledged that these technologies can be leveraged for the creation of usable and graphically appealing mobile apps, none of them has been adopted as universally as XHTML-MP and WML. For this reason, they fall outside of the scope of this document.
In spite of the different focus, developers and authors who adopts those technologies may find useful information in this document as far as usability goes.

1.9 Definition of Least Common Denominator (LCD)

Least Common Denominator (LCD) is the coding style that authors need to resort to when adaptation is not a possibility for any reason. In those cases, any HTTP client which requests the document will receive the same HTTP headers, the same mark-up and the same pictures in terms of size and format.

While LCD is the most widely adopted approach for the creation of internet web sites, device fragmentation prevents LCD from being equally effective on the mobile web. Choosing a default experience that does not take device features into consideration is bound to deliver a poor user experience on most devices.

1.10 Motivation for this Authoring Guide

This document clearly makes a point that authors/developers should turn to adaptation for the creation of usable mobile sites. Nevertheless, it is acknowledged that many developers/authors will attempt to create LCD sites anyway. The objectives of this document are:

  • To help developers maximize the user-experience delivered through LCD on the widest possible variety of devices
  • To educate developers about pitfalls of mobile development and how adaptation can make their mobile sites more succesful.

Among the reasons why authors/developers may choose not to apply adaptation in some form are:

  • Extra cost and complexity introduced by adaptation.
  • Lack of free hosting services that allow adaptation (free hosting service typically only allow static pages).
  • Lack of understanding of HTTP.
  • Lack of previous experience with mobile development.
  • Failure to understand the importance of usability.

This document is addressed to those who choose LCD in spite of having been warned that adaptation is key to delivering a usable service on a wide array of devices.
Putting things in different terms:

LCD is bad and authors/developers of mobile sites are encouraged to apply content adaptation techniques instead.
The goal of this document therefore is to both show and explain the LCD, as well as point to resources that describe the preferred, but more advanced course of action.

1.11 Assumption on devices: the Baseline

The definition of the practices must necessarily rely on a set of assumptions about the capabilities of the target devices. The range of mobile devices available worldwide is so varied, that hardly any recommendation can be provided before the range is clearly identified.

Having excluded WML-only (WAP 1.X) devices from the set of target devices, a considerable simplification of the problem has been achieved.
Unfortunately, there are some XHTML-MP mobile devices that feature particularly poor implementations of the standard, this applies particularly to the first WAP 2 devices which reached the market in 2001-2002.
Because of this, a choice is made to restrict the applicability of the practices to devices that meet a certain standard which will be referred to as 'the baseline'.

Devices which meet baseline requirements or above will support the following features:

Support for XHTML Mobile Profile 1.0.
Support for GIF and JPEG image formats.
256 colors
Color device with support for a minimum of 256 colors.
120x120 screen
120x120 pixel screen or larger.
At least 10 Kilobyte of content
Device can manage at least 10Kb of combined mark-up, graphics and CSS content.
Basic support for Tables
two columns tables are supported. no 'rowspan' and 'colspan' support required.
Picture and Link on the same Line
Device can display a picture and a link on the same line.
9.6 Kbps Minimal Bandwidth
Device and network support at least 9.6 Kbps bandwith.

It would be possible to require extra properties on the baseline device, but this would restrict the amount of devices LCD can be applied to. In other words, in order to build an LCD style-guide, some choice has to be taken regard which devices to address. Strict requirements will make LCD more powerful, while diminishing the range of devices LCD can be applied to. Loose requirements will allow LCD to address a larger set of devices, at the expense of authoring expressiveness.

The choice made by this document is an arbitrary compromise between these two opposite requeriments, which should keep 90% (or more) of devices currently accessing the mobile web in range for LCD.

Note 1: The baseline choice is arbitrary, yet it is based on the experience of professional in the mobile business. It is not excluded that upgrading the baseline to represent better devices, while remaining in the 90% range, could happen in the future. In that case, the practices would need to be re-visited accordingly.

Note 2: It is not excluded that, in some situations, the device set is limited by the nature of a given project (operator limited device portfolio, vertical application). In those cases, the LCD approach may make more sense than in the general case, but developers/authors should also identify a different, more powerful baseline. While many practices in this document will still apply also in those cases, others should be filtered by the awareness that the baseline is different.
The practices that could be revisited in case of a better baseline will be marked with a note. This document also dedicates a paragraph to elevating the baseline.

Note 3:The baseline configuration for devices is similar in concept (but not identical) to what W3C' Best Practices refer to as "Default Delivery Context".[DDC]

1.11.1 Devices that score below the baseline

This document does not issue any particular recommendation about how to handle HTTP requests from devices that fall outside of the set identified by the baseline.
Under the assumption that adaptation is not an option, the default trajectory for such devices is either to result in an error (WML devices) or an unsatisfactory user-experience (poor XHTML-MP support in microbrowsers).
As mentioned, this is expected to happen only for less than 10% of the devices which try to access the service.

2 Practices for XHTML MP

What follows is the list of practices for mobile authoring.

2.1 Best Practices = Adaptation

It should be noted that a decision was taken not to use the term "Best Practices" in this document for two reasons: to avoid confusion with W3C' Best Practices [BP] and because it is believed that content adaptation is the best way to achieve acceptable user experience. For this reason, the term Best Practices is considered a reserved word for the time when a set of practices for multiserving will be created.

2.2 Groupings of Practices

The practices will be split into two groups: development and usability:

  • Development relates to practices of technical nature mostly related to the XHTML-MP mark-up.
  • Usability relates to user-perception of the application and are mostly agnostic of the mark-up adopted.

2.3 Structure of Practice Statement

Each practice statement will be composed of three parts.

The Statement:

Hi, I am a GAP practice.

The Rationale behind the statement:

Etymology: Latin, neuter of rationalis
  1. an explanation of controlling principles of opinion, belief, practice, or phenomena
  2. an underlying reason :

Suggestions to implement the practice (Optional):

Suggestions will be displayed in plain text.

3 Practices

Mobile developers who cannot or do not intend to adopt adaptation techniques, are encouraged to apply these practices in their mobile applications.

Practices are split in two groups: those related to development and those related to usability aspects of the application.

3.1 Development

Validation of XHTML MP

[VALID_XHTMLMP] Make sure that mobile pages are valid XHTML Mobile Profile 1.0
Rationale: Most microbrowser today are reasonably tolerant of validity and well-formdness errors in mark-up when it comes to HTML-based pages.
In spite of this, there are still devices out there that will break on not strictly well-formed XHTML MP or not valid XHTML-MP.
For this reason, it is recommended that applications' pages are tested with a validator.

Practice: The W3C's Validator is a good starting point [VALIDATOR] for validating the mark-up generated by an application.
XMLLint [XMLLINT] is a useful utility to check a page XML validity through a command-line tool.
Most microbrowsers are tolerant to minor validation and well-formedness errors, but this will not guarantee that an application would not appear broken when accessed with a different microbrowser.

Note: This practice may be revisited in case authors need to comply to strict requirements for the visual appearence of their pages or in case the baseline is elevated.
HTML tags and attributes (for example, cellpadding and cellspacing for XHTML tables) can deliver graphically accurate renderings in ways that are not achievable through CSS (through the padding and spacing properties, for example), mainly because of poor CSS support in minibrowsers. This behavior can be observed also in minibrowsers running on high-end devices.
While the usage of extra XHTML attributes will make an XHTML-MP page non-valid, opting for non-valid, but effective, mark-up may be preferrable in some cases.
Making sure that a page is well-formed is still recommended, since well-formed XHTML-MP mark-up is less likely to cause troubles than invalid XHTML-MP.

Testing Applications

[MULTITEST] Test an application on at least 5 different microbrowsers
Rationale: There are many microbrowser families on the market. While every manufacturer also releases emulators and SDKs to let develop test applications on their system, reality has shown that there can be major differences between these SDKs and the actual devices. While using SDKs and emulators in the development phase is encouraged, it is recommended that applications are also tested on a wide enough array of devices, in order to gain confidence about the actual solidity of the mobile UI.

Practice: Acquire at least 5 devices for development and testing, where each device has one of the following browsers: Nokia WAP Browser series 40, Openwave Mobile Browser version 6 or greater, SonyEricsson (Teleca), Netfront, Opera for Symbian.
The list above is minimalist in nature. More robust testing could include one or more of the following microbrowsers: Motorola Mobile Browser 2 or grater, Microsoft Mobile Explorer, Nokia Series 60, Safari for Nokia. In addition, there are devices such as the BlackBerrys or Palm OS-based devices which have browsers of their own.
It should be noted that browsers from the same manufacturers may have different features from version to version. Those browsers/devices are covered by this document as long as they satisfy the requirements of the baseline device.
This document does not recommend any particular device for testing, since devices vary from place to place (i.e. GSM vs CDMA vs iDen...) and from month to month (new devices shipping at all times). If in doubt about which devices run the browsers mentioned above, turning to popular mobile developer forums (such as WMLProgramming at Yahoo Groups [WMLProgramming]) for advice is a viable option to find expert recommendations for specific cases.

Note: This practice may be revisited in case the baseline is elevated.
In addition, this practice does not necessarily apply to the Japanese market, in spite of the fact that testing is a good practice for Japanse applications too.

MIME type

[MIME_TYPE] Use the application/vnd.wap.xhtml+xml MIME Type
Rationale: In addition to be the MIME type created by OMA for XHTML-MP 1.0 content, this is the most widely understood MIME type of all. Assuming adaptation is not an option, application/vnd.wap.xhtml+xml is the best choice.
One of the disadvantages of this MIME type is that it prevents developers from previewing the applications in some regular web browsers (notably Microsoft Internet Explorer up to version 7). On the other hand, the text/html MIME type fools some devices into believing that it is a regular page they need to render. This may get them to apply heuristics that conflict with the intentions of the author.
Yet another possible MIME type is the XHTML-basic one (application/xhtml+xml), which does not completely solve the web preview issue, while not behaving like its OMA counterpart in all cases.
Some basic hosting solutions may disallow authors from adding the OMA WAP Mime type. In that case, the default association between the .xhtml file extension and the application/xhtml+xml content type is a better choice than text/html for reasons explained previously.

Practice: If adaptation is not possible, the web server should be configured to serve mobile content with the application/vnd.wap.xhtml+xml content type.
For static files, this is typically achieved by associating the .xhtml file extension with the application/vnd.wap.xhtml+xml in the web server 'content mapping' table.
If the application is responsible for sending the right MIME type, then application/vnd.wap.xhtml+xml should be used.
It should be observed that being in the position to generate dinamic content with technologies such as PHP, ASP, Perl and Java, typically implies the possibility to look at HTTP headers and do some conditional programming.
In this case, there is a very simple trick to multi-serve the MIME type to microbrowsers. The trick implies looking at the accept header string to understand what MIME types are supported ([MIMETRICK]).
This trick also enables Internet Explorer to preview a mobile application, by serving the mark-up to that browser with the text/html MIME type.

The above trick may not be optimal for recent BlackBerry devices. Those devices will claim to support all the HTML-related MIME-types in the accept: header, thus inducing a application/vnd.wap.xhtml+xml type. Unfortunately, this MIME type (as well as application/xhtml+xml) will cause the BlackBerry to ignore tables and CSS, which would otherwise be rendered normally with text/html. It should also be observed that RIM devices often depend on extra proprietary proxies deployed at operators. This means that the same devices may have different capabilities with different operators. For example, BlackBerrys from legacy Nextel (USA) are WML-only.

Little or No CSS

[SIMPLE_CSS] Only use simple in-line CSS or none.
Rationale: While CSS is a handy feature for styling a document without interfering with tags, XHTML MP mobile devices have different levels of support for the WCSS standard.
Many devices will not honor the color CSS assigns to links, for example. Another problem is that devices will take more time to render a page if rendering the page requires that an external CSS is loaded and parsed.
To add to that, it is not unusual that buggy (but nevertheless popular) devices simply do not cache CSS retrieved in previous requests, which ends up slowing the rendering for every page.

Practice: Keep styling information to a minimum and do not change the color of links. Using WCSS for input masks [INPUT_MASK] is a good idea because it will degrade gracefully on all known browsers.
Advanced CSS constructs such as media queries [MEDIAQUERIES] should be avoided: Only a few browsers support Media Queries acceptably (notably, recent versions of the Opera browser). In addition, pages based on Media Query hardly degrade gracefully on non-supporting devices. Microbrowsers typically end up downloading large graphics, which, in the author's intentions, was not meant to be delivered to a mobile device.
Good WCSS tutorials are available on the internet [WCSSTUT]. It should be observed that, while those tutorials typically advise to place CSS sheets in an external document, this document recommends to keep CSS in-line for LCD pages out of usability concerns.

Note: This practice may not apply in case the baseline is restricted to higher-end devices with more solid CSS support.

Minimizing the number of pictures

[FEW_IMAGES] Keep the number of images in a page down.
Rationale: The number of external images greatly affects the loading and rendering times for a page. For this reason, a balance needs to be found between the number of pictures used for visual purposes and the page rendering time.
Many devices will not enable softkeys nor return control to the user until the page is fully loaded and rendered. This will make it impossible for users to invoke browser functions (notably, backward navigation) for a frustratingly long time.

Practice: Testing a page on SDKs (i.e. over a PC with high bandwidth) may hide the real user experience. It is advisable that tests on real devices are performed as early as possible in the development cycle in order to obtain an accurate perception of actual user experience.

Providing the right encoding for content.

[ENCODING] Use UTF-8 encoding or better for non-english content.
Rationale: Non-english characters may display incorrectly on certain browsers/devices if the character encoding is not provided.
In case adaptation is not an option, adding the UTF-8 encoding string to the XML prolog has the best chance of fixing the problem for western languages.
If adaptation is an option, serving different encoding to different devices will help addressing issues with devices that only support iso-8859-1, utf-16 or other encoding.

Practice: The encoding can be specified this way:

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

If adaptation is an option, looking at the "accept-charset" may work in identifying supported charsets on some devices. For example (SonyEricsson W810i):

accept-charset = utf-8, utf-16, iso-8859-1, iso-10646-ucs-2, 
                 Shift_JIS, Big5,*

Beware of Colors

[BEWARE_OF_COLORED_LINKS] Do not try to color links.
[AVOID_BACKGROUNDS] Avoid background pictures.
Rationale: Many microbrowsers rely on the widgets provided by the host device UI to render hyperlinks. The implication of this is that, on some devices, CSS cannot influence the color of links, while this happens as expected on other devices. This can also be true of the same microbrowser running on devices by different manufacturers.
In addition to this, the same color may vary greatly from device to device. The same RGB color can appear like a light green on a device, and turn into a dark background that makes everything unreadable on another device. This can also apply to two instances of the same microbrowser on different devices.

Practice: Setting the background to blue and using CSS to color links white will result in unreadable black labels against a blue background on a wide range of devices.
If adaptation is not an option, avoiding background images and colored links is the safest choice to make sure that content is usable across a wide array of devices.
If no color info and no background are specified, devices will resort to default colors, which are typically very readable.
Background colors may be OK only as long as authors stick to light hints of color.
Developers who adopt LCD should also avoid styling 'visited' and 'active' hyperlinks as follows:

a {color:#0000FF;}
a:hover {color:#0000FF;}
a:link {color:#0000FF;}
a:visited {color:#0000FF;}
a:active {color:#0000FF;}

Some devices may highlight selected links by inverting link color and background color, effectively hiding the label of the currently selected link in case the above CSS is applied.

Note: This practice may be revisited in case the baseline is elevated and in case of adaptation.

Avoid too much vertical white space

[NO_VERTICAL_SPACE] Avoid Vertical Whitespace
Rationale: if too much vertical whitespace is introduced, some users on some device will think the page is over and will not scroll to reach the remaining content.

Practice: Avoid adding vertical white space in a page.
Code like the following is not unusual on poorly designed mobile sites:


While this code may have a nice visual appeal on some devices, it will cause the problem described above. Using the XHTML-MP <hr/> is a better option.

Note:One word of caution about <hr/>: it may break the validity of an XHTML-MP page in subtle ways and make the application break almost inexplicably on some specific devices (Notably some versions of the Teleca browser running on SonyEricsson devices).

3.2 Usability

Order of Menus (most important choices first)

[SPECIFIC] Place the most specific menu items in the top positions of menus.
Rationale: People scan a menu item by item from the top down. Usability studies have shown that people will click on the first item that might match what they are looking for. For this reason, it is preferable that the most specific items are presented first, and the most generic are displayed further down.

Practice: This is a question of how items are placed in a manu relatively to one another. If one of the menu items is labelled 'Information' and another one is labelled 'Weather', the latter should be presented before the former, or users looking for weather information will descend into the information section without realizing that 'Weather' was one of the available choices.

Note: One open question is who defines the importance of each item in the first place. This choice may be about letting users choose through usability tests ([TESTING]).

Access Keys

[ACCESS_KEYS] Use the 'accesskey' attribute to implement keyboard accelerators on menus.
Rationale: The use of the accesskey attribute allows users to activate a link by pressing (or press-holding) a number key on the numeric keypad, thus avoiding the need to click several times to select the link.
In menus, access keys allow experienced users of the service to reach the information they need faster by memorizing the numeric combination that will take them where they wish.
For example, 3-2-6 might be the path to today's horoscope.

Practice: The following XHTML-MP construct will deliver a numbered menu on all baseline devices or superior. Numbers are guaranteed to be displayed only once and items will be selectable by 'pressing' the accompanying number.
'Pressing' may mean simply pressing or 'pressing and holding' (Nokia devices).

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="" xml:lang="en">
    <title>Contacts - R</title>
Pick contact:
  <li><a href="contact.jsp?id=32" accesskey="1">Ramona</a></li>
  <li><a href="contact.jsp?id=45" accesskey="2">Robert</a></li>
  <li><a href="contact.jsp?id=21" accesskey="3">Romeo</a></li>
  <li><a href="contact.jsp?id=17" accesskey="4">Ronan</a></li>  

Caveat for the Japanese market: This code may not be the most suitable for the Japanese market and I-Mode devices.

Navigation Mechanism: Home/back link at the end

[NAVIGATION] Provide consistently used links to navigate inside the application
Rationale: While most devices support a back-button to access the previous page, not all devices included in the baseline do. For this reason, it is important to provide ways to return to some logical place in the application at the end of most page.
Such navigation links should be placed at the end of the page to avoid cluttering the interface and forcing users to scroll past the same links at every page.

Practice: Add navigation links at the end of each page. At a minimum, a link labelled 'Home' (or the equivalent in the user's language) should be present.
There can be exceptions to this rule in case of confirmation requests ("Really Delete? yes|no") or other situation in which the user shouldn't be distracted from the task he or she is performing.

No Navigation bars at the top

[NO_TOP_BAR] Avoid navigation bars at the top of the page
Rationale: For devices with small screens, navigation bars at the top of the page force users to scroll past the navigation bar for each page they encounter. This is irritating and greatly detracts from the system's overall usability.
As suggested by the [Navigation] practice above, make sure navigation links are are available at the end of the page.

Practice: Do not add a navigation bar at the top of application pages.

Note 1: This practice may not apply in case the baseline is elevated to higher-end devices. In those cases, large screens, the possibility to have smaller fonts for navigation links and the availability of a four-ways rocker (clicking past the navigation bar just requires one extra click) can make the presence of a navigation bar acceptable.
If adaptation is available, navigation bars may optionally be inserted at the top for high-end devices.
In these cases, it may also make sense to place 'bread-crumb' navigation (for ex: Home >Hardware >Chainsaws) or page numbers ( page 3 of 10 ) to navigate through large amounts of text, similarly to what is seen on web pages.

Note 2: This practice should not be confused with the case where a navigation bar supports a page function. A user may be looping through large amounts of text or a list of previews of downloadable content. In those case, backward/forward navigation as well as knowing how many extra pages are there before the end, would not be cluttering the UI, rather they would represent the UI itself.

Avoid unnecessary links

[NO_REDUNDANCY] Avoid repeating links such as 'Help','About','FAQ' in every page.
Rationale: Those links clutter the interface. They should only be added in one place and just if they are part of the business model of the application.

Practice: Most users do not access on-line help even when available on desktop applications. Virtually all mobile users will stay away from a link that labelled 'Help' or 'About'. Success can be achieved by making the application intuitive to use. Not cluttering the page with unnecessary links is a step in the right direction.

Avoid splash screens

[NO_SPLASH_SCREEN] Avoid first pages made to be skipped.
Rationale: While this may go against the wishes of the 'branding' department, forcing users to wait for the download of company logo, just to discover that they need to click to the next page is bad for usability and should be avoided.

Practice: Avoid so-called 'splash-screens'. Make sure that the first page the user receives has links to activate the main functionalities of the site.

Add a meaningful page title

[ADD_TITLE] Provide a short but descriptive page title.
Rationale: While not all devices display the content of the 'title' tag on the screen, no microbrowser will give an error. For this reason it makes sense to add a title. Not only will some devices display it at the top of the page, but the title will also be used as a default for bookmarking purposes. Some devices will use titles to build a usable history list on devices with advanced backward navigation (Symbian Series 60, for example).

Practice: Some devices will truncate title strings longer than 8-10 characters. For this reason, it is probably a good idea to keep the title short.

Concise and Clear Language

[CONCISE] Use clear, short and concise terms and sentences.
Rationale: Mobile users are typically not accessing the information in a comfortable environment. More often than not, they are in the street, in a crowded bus or other environment unfavourable for concentration.
This factor and the tiny size of the screen of a mobile device imply that carefully worded sentences and labels have a greater chance to be understood by the intended audience and make the overall application more pleasant to use.

Practice: The number of words should be reduced in every possible way. Using the label "Age:" is a better choice than "Please enter your age here:". Another example could be to avoid words like "Entertainment" when one can simply say "Fun".

Different media means different user experience

[DIFFERENT_MEDIA] Do not serve a website to a mobile device and do not serve a mobile site to a web browser.
Rationale: Web and Mobile are different medias. Accessing a fully fledged web site on a mobile device is likely to be catastrophic for user-experience. On the other hand, accessing a mobile site with a web browser will hardly provide the kind of sophisticated look and feel that today's internet users have grown accustomed to. Web and mobile sites should be designed separately with separate objectives in mind.

Practice: if adaptation is not possible, two different URLs should be provided: one for the website and one for the mobile site. While "" is the typical choice for websites, "", "", "" and "" are popular choices for mobile.
Lately, a new Top-Level domain called '.mobi' (pron.,dot-mobi) ([DOTMOBI]) has been created specifically for mobile. In case a .mobi domain is acquired, the mobile site URL would be "".
If adaptation is possible, a popular approach is to advertise one URL ("") and look for hints in each HTTP request to understand the nature of the client: requests coming from mobile devices are redirected to the mobile site, while request from web clients are redirected to the web site [SWITCHER]
The advantage of this approach is that a unique entry point to both applications is maintained. Techniques and heuristics to recognize and redirect browsers are available on the internet either as standalone [DIFFER] or as part of a framework such as WURFL [WURFL].

Adopting short URLs

[USE_SHORT_URL] Adopt a short URL for site entry point(s)
Rationale: While part of the users may click their way to an application starting from another portal (possibly their operator's portal), others will type the URL. Developers should make sure that the application is short to help users.

Practice:Sites such as allow everyone to define short URL as a free service. Commercial organization may pay for an equally short, but more memorable, URL.

Cache Management

[EXPLOIT_CACHE] Do not disable caching (unless low page lifetime is part of actual business model).
Rationale: Limited bandwidth and high latency greatly impact the usability of a mobile service. For this reason, services should let devices cache content by default and avoid forcing a device to clear the page after the first access, unless this is part of the business model.
Caching strategy vary for different devices. Trying to fine tune caching strategies quickly leads into adaptation, which may not be an option for the audience of this document. In spite of this, avoiding to specify any caching directive for the page will typically lead to pages that are not reloaded when users press the back button of the browser. This is a great starting point.

Practice: Disabling the cache can mean many different things. In most cases, users expect to find new content when they access a certain page again, yet, they expect to find the same content when they press the back button to return to a previous state where they feel comfortable.
The exact caching model is part of the business model of the application. Browsing an email inbox may require nothing short than total disabling of any caching. Weather forecast may live with a couple of hours caching. Yet again, advertisement and banners may pose additional requirements on caching. These requirements may clash with the service usability.
Things are complicated by the fact that some microbrowsers allow fine grained control of the cache by respecting Time-To-Live (TTL) directives, while others only respond to a somewhat brutal use of META tags.
Assuming that adaptation is not an option, two techniques are provided: completing disabling the cache and a somewhat softer reset that will preserve the usability of backward navigation (back button).

Disabling caching completely
Different microbrowsers (and microbrowser/gateway combinations) react in different ways to different META-tags and HTTP headers.
The following set of headers has been proven to work on a wide range of devices to disable caching for the page:

Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: DD. month YYYY HH:MM:SS GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache

The Wireless FAQ [WIRELESSFAQ] illustrates how headers can be set in different programming paradigms.
In case access to headers is not possible, the same functions can be achieved with the usage of the following META tags:

<meta http-equiv="expires" content="Wed, 26 Feb 1997 08:21:57 GMT">
<meta forua="true" http-equiv="Cache-Control" content="must-revalidate"/>
<meta http-equiv="Pragma" content="no-cache, must-revalidate">

Soft cache disable
This is the illustration of how page cache can be disabled without interfering with the back-button functionality, which should always bring the user back to the previously visited page.
No HTTP header or META tag should be used to disable caching. All the links to an application page should be different. This can be achieved by adding dynamically a bogus HTTP GET parameter to each internal link. The time in seconds is a good candidate for this. The following JSP/JSTL example shows how a link to a newly modified bookmark page could be created to make the microbrowser perceive it as a different URL. This fools the browser into reloading the page from the service and not from the cache:

<jsp:useBean id="now" class="java.util.Date" scope="request"/>
<a href="bookmarks?id=${bookmark_folder_id}&amp;
         cache_buster=${now.time}">Go to Bookmarks</a>

It goes without saying that this trick cannot be performed with static XHTML-MP pages.

Manage User Input (use input masks/minimize clicks)

[INPUT_MASK] Use input masks to minimize user input.
[BEWARE_OF_FORMS] Beware of HTML-style forms.
[AVOID_LOGINS] Do not require that users login each time.
[NO_PASSWORD_MASK] Do not mask user input when entering a password.
Rationale: Entering data and text is a very time consuming and error-prone task for users of mobile devices. Everything possible should be done to minimize the amount of clicks required to users. This may imply having to do extra effort on the application back-end to collect user-preferences and use the information to provide reasonable defaults and pre-filled forms.

Input Masks
Most mobile devices let users specify input-masks, i.e. the format with which user-input is supposed to be entered. If a telephone number is required of the user, setting the input form in numeric mode greatly simplifies the task of entering the data for the user. Also, this prevents user errors.

Beware of Forms
XHTML-MP forms are very similar to the ones in HTML, which, in turn, mimic widgets such as push button, radio buttons, check buttons, combo boxes (also called 'drop-down' boxes) and others commonly found in desktop applications.
While those widgets are usable in web pages and desktop applications, they are often implemented in ways that force users to do far too many clicks on a mobile device. Selecting, activating and deselecting each single widget is time consuming and not pleasant, particularly on devices without a stylus or other pointing device (the great majority of devices).
Developers should get creative about ways to minimize recourse to such widgets. While complex forms with text fields, radio buttons and drop-down boxes are the norm on the web, they should be avoided on a mobile devices by splitting a form in several atomic steps (such forms are sometimes referred to as 'wizards'). Wizards make users focus on a task at the time and are less error-prone than monolithic (elective) forms.

Avoid Logins
Logins are a big killer for usability. Requiring users to type a username and a password before they can use the application will reduce the number of users by two-thirds or more.
If the application business model does not allow for the removal of a login task altogether, developers should at least make whatever they can to recognize users the second time they access the service and refrain from requiring login.

Do not use password masks
Reading what is on the screen of a mobile device is often hard enough for the user of the device. Peeking over the shoulder of the user is less likely to disclose a password than observing the user's keypress sequence.
For this reason, hiding user input to users themselves by replacing each character with a '*' (star) symbol (or similar) will do very little to protect privacy, while making it generally harder to use the service. For this reason, users should be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login and find alternative ways to identify users.
Caveat: In case of highly sensitive application (such as 'Net Banking'), security requirements may force you to overlook this practice. For example, some users may perceive the lack of password obfuscation as a sign of slack security practices.


Input Masks: XHTML-MP lets developers add input masks with the following syntax:

<input type="text" name="pin" value="" style="-wap-input-format:NNNN" /> 

Some early versions of XHTML-MP microbrowsers did not understand the above syntax and were better served with the following syntax:

<input type="text" name="pin" value="" format="NNNN" /> 

If adaptation is possible, multiserving the input-mask would be a good idea. If not, choosing the syntax in the first example is preferable. Not only is it more elegant, but the CSS syntax will not make the application break on browsers that do not support it.
The XHTML references in the reference section [XHTMLREF] contains the specification of formats.
It should be noted that this is an area in which different microbrowsers behave differently and adopting adaptation is strongly encouraged.
For example, input masks such as "NNN-NNN-NNNN" to identify a US phone number may be supported usably on some devices and not in others. If adaptation is not an option, relying on a simpler numeric input mask would be a better choice for this case.
Forms: Radio buttons, checkboxes and combo boxes tend to be confusing and require too many clicks. It is usually possible to re-define complex forms in terms of set of menus.
For example, the following code shows a combo box implemented though a syntactically correct XHTML-MP code snippet. The combo box is rendered as shown on the left. This is not very usable, since users are required to perform the following activities:

  • Scroll to the combo box and select it (which brings them to a virtual page that implements the choices. This makes the user loose context)
  • Select the right value
  • Choose to abandon the combo box (which brings them back to the original context)
  • Focus on what the next thing to do is (de-select the combo and select the next widget in the form).

Forcing the user to perform a large number of clicks and to concentrate continuously on what he or she is doing is likely to make the application feel unfriendly and hard to use.

  <option value="17">Less than 18</option> 
  <option value="25">[19-25]</option> 
  <option value="45">[26-44]</option> 
  <option value="100">over 44...</option> 
Less than 18
Over 44

To optimize the number of clicks, a better option is to break down the form in more atomic parts which require users to focus on a single task at the time. The case described above could be implemented in terms of single steps. In particular, the age could be collected by providing a set of links. When to user selects a link, the age is chosen and the user is automatically brought to the next step of the form.

<a href="next/form?age=17">Less than 18</a><br>
<a href="next/form?age=25">[19-25]</a><br>
<a href="next/form?age=44">[26-44]</a><br>
<a href="next/form?age=100">Over 44</a><br>


For example, text input fields often require clicks to activate and deactivate. Combo boxes bring users to a new virtual page and back after the selection, which may be confusing to some users.
Creating usable forms is generally difficult. Developers are encouraged to do usability tests with real users ([TESTING]) as early as possible in the lifecycle of the application, possibly with the help of prototypes.
It cannot be ruled out that different forms are required to optimize usability on different classes of devices. This is consistent with the general idea that adaptation drammatically improves the success of mobile applications.

Avoid Logins: Assuming that removing login tasks completely is not an option because of a mobile site business model, there are a few techniques to prevent users from having to login again the second time around.
Most operators gateway attach extra HTTP headers to each mobile-generated request which uniquely identify the user. This bit of information can be used to recognize the user and log him or her in automatically.
Yet another option is to use cookies. While cookies may not be supported on some ntwork or on older devices, they should be used to avoid the login task when available.
Some WAP gateways can manage cookies on behalf of a device which does not support them.

Do not use password masks: this practice can be easily applied in XHTML-MP (and other HTML-derived mark-ups) by using:

<input type="text" ..../>

in place of:

<input type="password" ..../>

to implement a password entry field.

Note: These practices should be candidates to revision in case the baseline is elevated. This is particularly true of the case when a stylus or other pointing device is part of the new baseline.

Cookies may not be reliable

[BEWARE_OF_COOKIES] Carefully evaluate how cookies are used in the application. Cookies may or may not work on some networks and/or some devices.
Rationale: Availability of cookies on the mobile web depends on both devices and networks. Newer devices tend to support cookies.
Access to the mobile Internet is often achieved through WAP gateways (HTTP proxies managed by mobile operators). Most gateways manage cookies on behalf of devices that have no cookie support. This further increases the number of devices for which basic cookie support can be assumed.
Finally, caution should be taken when "cookie support" is assumed. Many devices/gateways may not be supporting the full RFC 2109 specification, i.e. limitations on the size and/or lifetime of cookies as compared to what is available for vanilla web programming must be accounted for.
Generally speaking, cookies are available in some form in excess of 80% of the cases. It is advisable to rely on cookies to provide improved user experience (for ex., to avoid logins). On the other hand, relying on cookies for fundamental parts of the service (such as session management) may cause the application to fail for some users.

Practice: If an application only relies on cookies for improved service, but is not essential to the well-functioning of the service itself, then cookie support can be safely assumed.
If cookies availability is essential to the correct functioning of the application (typically for supporting user sessions), then alternative mechanisms should be assumed. URL-Rewriting is the common way to by-pass the lack of cookie support ([URLREWRITING]).
One word of caution should be spent about usage of URL re-writing for mobile applications. Many commonly available URL-rewriting packages assume that the HTTP client is a web browser. For this reason the rewritten URLs include session IDs that can be very long and contain special characters. This can cause problem on some mobile devices.
Some URL rewriting libraries let themselves be configured to address this problem by avoiding special chars and keeping session IDs under 50 chars. Creating one's own URL rewriting function is also a possibility.
Finally, in many cases, operator gateways and independent portals attach unique headers and values to each HTTP request, such as phone number headers (x-wap-msisdn, x-nokia-msisdn, x-up-calling-line-id) and subscribeer id headers (x-up-subno). The headers can be exploited as unique keys to track users and the foundation for session management.
Some detailed techniques to track users are presented here [TRACKUSERS]

Note: This practice should be amended in case the baseline is elevated.
For example, the application could be developed for an operator that supports cookies fully for all of its devices. Another possibility is that the baseline is restricted to devices with full cookie support.

Large content

[NO_BIG_PAGE] Delivered mark-up and images should not exceed 10 Kilobyte totally.
Rationale: This is an area where adaptation would greatly help. While some devices would be better served with 3 or 4 Kilobytes of content, others can manage over 30 Kb without compromising usability.
If multiserving is not an option, 10kb represents a good compromise.

Practice: Each mobile page should not contain more than 10 Kilobytes of content totally (i.e. XHTML+Pictures+CSS).
In case adaptation is used, it is OK to serve larger pages to the devices which can handle them.
It is observed that device memory, screen size and download speed should not be the only limiting factors when deciding how much content to deliver to a device. The form factor of a mobile device will make it hard for the user to scroll precisely through large amounts of text and images, even when a large screen and a stylus are available.
For this reason, it is recommended that mobile pages do not exceed 40kb totally even for high-end devices.

Note: These practices should be candidates to revision in case the baseline is elevated.
This is particularly true in case of devices with large screens, fast rendering of pages and high-bandwidth connections.

Keep images small

[SMALL_PICTURES] Do not deliver pictures that are wider than the screen.
Rationale: Serving pictures that are wider than the screen size will either make the browser resize the picture or get the picture cropped (possibly with the addition of horizontal scrollbars). In the first case, the quality of the picture is typically decreased. In the second case, the usability of the service suffers.

Practice: Adaptation is strongly encouraged in cases like this. Developers should find frameworks to serve pictures in different sizes to different classes of devices in order to avoid scrollbars and low-quality resizing.
If adaptation is not feasible, pictures should be constrained by the screen size of the baseline device (120x120 pixels).

Note 1: Some image editors (even popular ones) are adding extra information in JPEG pictures through 'tagging' and/or a standard called EXIF. This may increas the size of pictures (and, correspondingly, download times). On some devices, pictures may not be displayed at all (Nec devices are known to have problems with 'tagged' pictures). Developers should make sure that their software can produce JPEG pictures without extra information and small in size.
The Wireless FAQ describes how picturef for mobile can be optimized extensively [OPTIMIZEPIX].

Note 2: This practice may be revisited in case the baseline is elevated and a larger screen can be assumed.

Specify image dimensions

[STATE_IMAGE_SIZE] Specify the real image width and image height in the mark-up.
Rationale: Adding image dimensions in the mark-up will typically allow the browser to allocate screen space for the picture before the picture is actually downloaded. This speeds up the rendering phase and gives users the feeling of a more responsive and usable service.
Width and height of the pictures should be the real ones for the picture, to avoid that the browser has to do CPU-intensive image rescaling which would impact the rendering negatively. For example, the page might be re-rendered by the browser and snap back to the top, which is not friendly to users who have already started to scroll down.
In the case of dynamic pictures, for which the size is not known from before, omitting to specify width and height is usually the best choice.

Practice: Specify image size using the following syntax.

<img src="images/logo.gif" alt="ComPany" width="100" height="20" />

One possible exception to this practice might be a free wallpaper site, where users can be sent a whole picture while specifying the dimensiones of a smaller thumbnail. In that case, saving the page will work without having to fetch the full-size version

Minimize the amount of clicks to get to content

[MINIMIZE] Minimize the number of clicks required to carry out activities
Rationale: Accessing mobile services or content should be quick and easy for users. A confusing, repetitive, and time-consuming process will lead to frustration and ultimately result in disattisfied users.
It should be noted that many users ascribe their reluctance to use a system to their own ignorance or laziness, rather than the lack of usability of the system. This does not change the fact that those users will not access the system or will do so less frequently.

Practice: Application menus should be organized to offer access to the most commonly used functions with the least possible numbers of clicks.
Most commonly used functions should be made available as top links, while less used functions should be pushed down. The idea that less commonly accessed functions are removed completely from the mobile UI should be considered, particularly when the primary reason for adding them in the first place was their existence on a companion web site.

Turn telephone numbers into links that start a phone call

[STILL_A_PHONE] Enable one-click calls for phone numers
Rationale: Almost all mobile device are also mobile phones. When a phone number is displayed, turning that number into a link that will start a phone call when activated is a simple way to increase application usability.

Practice: There are two ways to implement one-click phone calls:

 <a href="wtai://wp/mc;+39393939777778">+39 393939777778</a>


 <a href="tel:+39393939777778">+39 393939777778</a>

While modern devices support both syntaxes, neither is guaranteed to work on all phones. In addition, some older device do not support one-click calls at all.
Authors who rely on LCD can choose one or the other. Adaptation may be used to cover all devices and just present the telephone number to devices that do not support one-click calls.

Fewer than 10 links

[MAX_10_LINKS] Only exceed 10 links per page if the application demands it.
Rationale: There are 10 numeric keys on mobile devices. This allows authors to associate a numeric shortcut to each item [ACCESS_KEYS], which will help users to quickly find their ways when accessing submenus.
There are extra usability-related reasons to keep the number of items in a menu limited. Users need to understand the label of each link before they decide which one to click on. Too many labels means requiring to much concentration of users.
According to developer reports, log analysis has revealed that the four top link in a page collect about 80% of the clicks regardless of the number of items that follow. In other words, many users simply don't scroll.

Practice: Minimize the number of items in menus. Keep the total number under 10.

No Thinking Web

[NO_WEB] Do not try to port all functions of a website to mobile.
Rationale: When confronted with the task of porting an application to mobile, it is not straightforward to decide which functions should be ported and which should be discarded.
The fact that a given function is already implemented for the web might lead developers and software architects to replicate those functions for mobile.
Trying to port all functions is bound to have negative implications for usability, though, because menus and submenus would quickly get too crowded and too complicated to be pleasant to use and navigate.
For example, many are interested in reading email while they are away from their PC. At the same time only a fraction of "readers" would bother to answer using their mobile device: they prefer to wait until they get on-line again, send a very short message ("yes", "no", "ok", or something the size of an SMS message) or just make a call when it is really urgent. Finally, very few users would try to configure a spam filter through a mobile device.

Practice: When designing the port of a web site to mobile, one possible approach is identifying two kind of information:

  • Information that users want to access when they are mobile.
  • Information that people want all the time

This may turn up to include only 5% or less of a web site current functions, but that is still acceptable. In fact, that is the key to creating a mobile site which has high value for mobile user and which, ultimately, makes it acceptable for users to carry the cost (time, money and concentration) of accessing the service.

Note: Some developers may be tempted to add text to a mobile page to explain the extra features available with the related website or another device. Generally speaking, this is not a good idea, because that extra text provides no value to the user, clutters the interface and forces the users to do more clicks to scroll past the message. Some users will not click at all and stop using the application.

Not everything is good with W3C Best Practices

[NO_MWI_BP] Beware of W3C MWI Best Practices.
Rationale: W3C has produced a document called "Mobile Web Best Practices" [BP] which should provide practical advice about how to create usable pages for the mobile web.
Unfortunately, those 'practices' are not derived from real practice in all cases, but rather they represent a compromise among the partecipants to the BP working group (BPWG). Members of BPWG and W3C have interests in enforcing requirements not strictly related to the creation of usable mobile sites.
For this reason, adhering to BP (or, even, passing the MobileOK tests, which are based on BP) is no guarantee that the page will be usable. In some case, applying BP practices may actually diminish usability.
Of particular interest is the fact that the BP document advocates the use of XHTML Basic 1.1, a mark-up language which offers the same features of XHTML Mobile Profile, but which, as of November 2006, does not exist either in terms of actual support by microbrowsers or, simply, as an actual W3C recommendation.
A more detailed discussion about the issues with Best Practices and MobileOK is available [MWI BP Criticism].

Practice: W3C MWI Best Practices should be ignored by developers who are new to mobile.
In case this is not possible for any reasons, it is recommended that the validity of every BP 'practice' is questioned. This can be achieved by matching BP practices against the ones in this document or by asking specific questions on mobile development forums such as WMLProgramming at Yahoo Groups [WMLProgramming].

Test with real users

[TESTING] Find real, non-techie users and make them perform functions. Observe what problems they have.
Rationale: Most of the times, real users will find obstacles in using a mobile service that are completely unexpected for the owners and the creators of the service itself.
Observing real users will provide useful clues about how those obstacles can be removed.

Practice: Applying this practice properly is expensive. Fully-fledged usability testing requires the availability of people to manage the tests and the sample users who volunteered to use the service.
There should be a room with a two-way mirror and a camera that records what the user did (or tried to do) when asked by someone who observes (without helping!) the user. Users for focus groups are typically recruited by specialized companies, who should find people that represent the target audience for the service to be tested.
It is recognized that this kind of testing is expensive and outside of the possibilities of small and medium-sized projects.
For this reason, one should apply the usability practices described in this document and observe friends and relatives when given a chance t use the service.
It is also advised that usability testing starts as early as possible, by using prototypes (or, even, just mockups) of the pages. It is not uncommon that achieving good usability has an impact on the back-end. For this reason, such changes should be managed earlier rather than later.

3.3 Elevating the baseline

The default baseline chosen for the purposes of this document ensures that a high percentage of Internet-enabled mobile devices can access LCD content written according to the practices.
It is possible that the default baseline is not the best choice in the context of a given project. There can be multiple reasons for this. For example:

  • By the time an author adopts this document, the baseline could be out-dated, and a stricter set of requirement still identify a high enough percentage of devices.
  • The project might concern a 'vertical application', i.e. an application that only matters to a specialized set of users (for example, a mobile intranet). In that case, developers might be able to make assumptions on the capabilities of the target devices, thus implicitly identifying a better baseline.
  • An application is directed to users in a specific market or a specific operator in a specific country.
  • Adaptation has happened elsewhere and only a well-defined class of devices is redirected to the application.
For these and similar cases, two extra practices are introduced.

Identifying a new baseline

[FIND_BASELINE] Try to identify own project's device baseline.
Rationale: In all the cases, when the set of target devices is more limited, authors and developers are encouraged to analyze the capabilities of the devices and derive a better baseline.

Practice: Deriving a better baseline means being able to assume better support for CSS, larger screen size, better management of forms and so on.
This information can be obtained from operator developer site or independent sources available on the internet in the form of blogging and developer forums.

Fine-tune content to new baseline

[UPGRADE_EXPERIENCE] Review practices and fine-tune content accordingly.
Rationale: Once a new baseline is identified, some of the practices in this document may have to be reviewed accordingly. Developers who have acquired experience with mobile developments should be able to deal with this task autonomously, in spite of the fact that the task is not automatic.

Practice: Assumptions about maximum picture size and use of CSS should be revisited. In certain cases, XHTML MP may be abandoned totally in favor of richer mobile paradigms.

4 How to contribute to this document

While the initial draft of this document is the work of an individual, the ultimate goal of this effort is to serve the mobile industry in general and the community of mobile developers in particular.
Contributions to the draft by mobile industry stakeholders are always welcome.
Suggestions, corrections, criticisms and support to this document can be expressed either by posting a message on the WMLProgramming developer forum at Yahoo Groups [WMLProgramming] or by taking contact with the editor of the document.
The editor reserves the right to submit private communications relating to this document to the attention of the WMLProgramming forum, possibly after anonymizing the source of the message in the event this is explicitly required.
It is expected that the collective knowledge of the mobile practitioners attending WMLProgramming will keep the document at a high standard for everyone for the years to come.
In the event a dispute arises about any aspects of the document, the editor reserves the right to the final decision.

5 Templates

In order to enable authors to create usable LCD mobile content, a list of fully-validated XHTML-MP templates is hereby provided. The templates are available at or, as a single download at
Each template is briefly illustrated in the list that follows:

Screenshots were captured with Nokia and Openwave V7 microbrowsers
Menu 1: This is the most straightforward way to implement navigation menus.
Not only does this menu support softkeys on the greatest number of devices, but the lack of icons and the in-line usage of CSS will let microbrowsers render the menu in the fastest possible way.
On the negative side, menus built this way tend to have a low 'cool factor'.
Menu 2: This menu is slightly cooler thanks to the addition of graphical elements. Icons this large are only advisable when there are few associated links, or the combined download/rendering times may cause the system to feel too slow for users.
Menu 3: MSN Style menu. This menu has more icons than menu 2, but the icons are to avoid delaying rendering. The fewer the icons, the better for system responsiveness.
Rich List: Rich lists shows how content can be presented in appealing ways also when doing LCD XHTML-MP.
The template uses a simple table for layout, which, in spite of what W3C's BP recommends, is a good practice.
Grid: VodafoneLive-inspired grid menu. This kind of interface is usually only recommended for devices with a 4-way rocker to skip from one row to the next without forcing users to click their way through each and every link.
The two-column layout may not be adequate for devices with large screens. In the case of commercial portals, the number of columns is often adjusted dynamically according to screen width. This function can be easily implemented with the help of an adaptation framework.
Forms: the template above examplifies how forms should be broken down into simpler steps (i.e.a "wizard") to let users concentrate on a series of simpler tasks. This increases the chance that users will complete the process and reduce the number of errors.
The example refers to the process of collecting credit-card information.
While breaking complex forms down into simpler tasks is recommended, it is advisable to provide some indication about how far a user has come in the process whenever the wizard requires more than 2 or 3 steps to complete: Log-analysis has shown that the number of users drops dramatically when users get as far as the third step and there is no end in sight. Progress can be easily communicated by labelling each page of the wizard with "step X of Y", where Y is the total number of steps and X is the step the user is requested to perform.

6 References

XHTMLTUT - XHTML Mobile Profile 1.0 Tutorials

XHTML MP tutorial at Developers Home:
XHTML MP tutorial at Openwave: documentation/guides_and_references/xhtml_tutorial/index.htm

XHTMLREF - XHTML Mobile Profile 1.0 References

XHTML MP Reference at Openwave:

XHTML MP 1.0 Specification from OMA: wap/wap-277-xhtmlmp-20011029-a.pdf


The Wireless Universal Resource FiLe:








MWI Device Description Working Group (DDWG):


Wireless Abstraction Library by Luca Passani:


Implementation of WALL for PHP:


Opera Small-Screen Rendering:

WML - Wireless Mark-up Language 1.1 Reference

WML 1.1:

WAP - Wireless Application Protocol

Wireless Application Protocol:


HTML - The Hypertext Markup Language:


Issues with XHTML Mime Types in Web Browsers:

J2ME - Java Platform, Micro Edition (Java ME)

Set of Java APIs for the development of mobile applications:


Flash Lite. Macromedia's Flash retrofitted for mobile phones:

BREW - Binary Runtime Environment for Wireless

Application development platform created by Qualcomm for mobile phones:

DDC - Default Delivery Context

Default Delivery Context as defined in W3C Best Practices for the Mobile Web:

BP - Mobile Web Best Practices 1.0

W3C Best Practices for the Mobile Web:


W3C Markup Validation Service:


Command-line XML parser:


Extract best MIME type from Accept Header: page=mimeTypesFileExtension


WAP CSS Tutorial:


CSS-based expressions to limit the scope of stylesheet:


.mobi Top Level Domain:


.mobi Switcher: direct mobile browsers to .mobi site and web browsers to web sites

DIFFER - Differentiate Mobile Devices and Web Browsers

To Differentiate Mobile Devices or User Agents Made by Different Companies with the User-Agent Header: page=userAgentHeader


The Wireless FAQ. How do I prevent a WML deck from being read from the cache: how_do_i_prevent_a_wml_deck_from_being_read_from_the_cache


WikiPedia on URL Re-Writing:


Techniques to track users from the Wireless FAQ: how_do_i_remember_users


Techniques to optimize pictures from the Wireless FAQ: how_can_i_optimize_image_size


WMLProgramming Mailing List at Yahoo Groups:

MWI BP Criticism

Issues with Mobile Web Best Practices 1.0:

Copyright © 2002-2011, Luca Passani