This document specifies Best Practices for delivering Web
content to mobile devices. The principal objective is to enable development and
delivery of great Web applications on mobile devices, through recommendations for exploitation
of mobile device capabilities and delivery context.
The recommendations refer to applications as experienced
on mobile devices. The recommendations necessarily reflect upon the processes by
which the applications are developed and delivered, and the nature of the
devices and user agents through which they are experienced. However the main
focus is upon the applications themselves, including content that is delivered and presented through the
applications.
The recommendation is primarily directed at creators, maintainers and operators of Web applications. Readers of
this document are expected to be familiar with the creation of Web sites,
and to have a general familiarity with the technologies involved, such as
Web servers, HTTP, and Web 2.0 technologies. Readers are not expected to have a
background in mobile-specific technologies.
(to be filled
in later)
(to be filled
in later)
This document sets out a series of recommendations designed to enable development and
delivery of great Web applications on mobile devices.
The recommendations are offered to creators, maintainers
and operators of Web applications.
The document is organized as follows:
Introduction. Describes the audience, purpose and scope of the
document.
Requirements. An illustration of the type of problems that the Best
Practices are intended to address.
Delivery Context. Discusses the environment within which mobile
access to Web applications is realized, with particular reference to
adaptation.
Overview of Best Practices. A discussion of the organization of the
Best Practices, and sources from which they were derived.
Best Practices. The statements themselves.
Conformance. A brief conformance statement.
Appendices
Sources
Related Reading
Acknowledgements
References
Readers of this document are expected to be familiar with the creation of Web applications,
and to have a general familiarity with the technologies involved, such as
Web servers, HTTP, and Web 2.0. Readers are not expected to have a background
in mobile-specific technologies.
Our intention is to make it clear to all involved what the Best Practices
are, and hence establish a common basis of understanding. As a result of
wishing to be clear to those not already involved in the development of
mobile friendly content, some of our statements may appear to be obvious or
trivial to those with experience in this area.
The document is not targeted solely at developers; others, such as interaction and
graphic designers, and tool developers, are encouraged to read it.
These recommendations (BP2) follow in the footsteps of
the Mobile Web Best Practices 1.0, (BP1), for which the scope was laid out in "Scope of Mobile Web Best
Practices" [Scope] .
In summary, BP1 refered primarily to the extension of Web browsing onto
mobile devices.
BP2 extends the focus to Web applications
generally, which means an application that is accessed and presented via Web technologies. Web applications represent a
spectrum of services and content, at the simple end
of which are typical Web browsing sites, presented in browsers, which were the focus
of BP1. The BP2 focus includes further recommendations for addressing delivery context
issues and for use of Web technologies more advanced than covered in BP1, which apply both to browsers and non-browser web
runtime environments.
Web applications considered in scope for BP2 typically have many of the
following characteristics:
-
uses the Internet and the Web to access data,
generally provided in XML form [or any
other format]
-
models the data on the client device in the form of a Document
Object Model
-
uses Cascading Style Sheets properties
for styling
-
offers autonomous interaction with the user and network, typically by use of a scripting language (often ECMAScript or
a derivative)
-
can operate successfully on client devices that are designed primarily
for use while moving or being carried and where the user can be expected to be in a range of
different contexts
-
can operate successfully in a intermittently-connected, resource-constrained networked environment with consequent impact on user experience, delay
and cost
-
can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces,
and camera
The recommendations refer to applications as experienced
on mobile devices. The recommendations necessarily reflect upon the processes by
which the applications are developed and delivered, and the nature of the
devices and user agents through which they are experienced. However the main
focus is upon the applications themselves, including content that is delivered and presented through
the applications.
As discussed in the Scope document [Scope]
there are many
aspects to Mobile Web Best Practices. BP2 represents the second phase of the Best
Practices development, i.e. beyond "Traditional Web Browsing".
1.4.1 Criteria for Best Practice recommendations
The BP2 is not intended as a landscape document, e.g. a general survey
of technologies and related issues in the mobile context. Recommendations are
included here if they meet specific criteria:
- will improve web applications in common delivery
contexts, by promoting adoption of good techniques and avoidance of
techniques considered harmful
- if they are relevant to the mobile context
- is implemented and recommended for broader use
- should remain relevant as technology
evolves
These recommendations follow in the footsteps of the BP1.
This document builds on some of the concepts described by
the Ubiquitous Web Applications (UWA) in the Device Independence Principles [DIP]. The document discusses
device and delivery channel characteristics, which the DIWG has named
"Delivery Context" [DCODI]. In addition, the
document uses some terminology from UWA's Glossary of Terms for Device
Independence [DIGLOSS].
The Best Practices have been written at a level of
generality that allows them to be applicable across a range of Web technologies. They
have been written with mobile user experience aspects in mind, which over
time will change, but should remain relevant as technology evolves.
This document may be reviewed from time to time. When necessary, an
updated version will be released with clear documentation as to the changes
that have been introduced.
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.
2.1 Personalization
Personalization is an important capability in the mobile
environment, given the extra effort necessary to interact with services, and the
limited output capabilities of mobile devices. Personalization increases the
value of content and services to users. However, conventional methods to
achieve/maintain personalization (e.g. user input, HTTP redirect, cookies) are
problematic given mobile context limitations. The overall goal for
personalization in the
mobile
context is to use user-friendly methods.
Security is important to address in the mobile
environment, due to more frequent dependence upon personalized information.
While this information is essential to increasing service value, its
use represents a security and/or privacy risk. The overall goal for
security is to protect any personally identifiable information, and especially
user
identifiers or keys to user identity.
2.3 User
awareness and control
Applications should ensure the user is aware of
sensitive functions, i.e. that may affect the service experience, and is offered
some options for user control.
HTTP cookies and redirection fulfill useful purposes in
the mobile context. Cookies support statefulness and personalization in
browsers, two considerations which can simplify the user experience and add
value to content and services. Redirect supports server-server interaction via
the browser, which is often essential for distributed services which rely upon partitioning of
service functions across different servers.
As compared to their use for web browser
applications, cookies and redirect may play less of a
role in maintaining statefulness and personalization for for web applications in
general. Application-specific methods may be used, and may include use
of more advanced technologies that are not available to some browsers. However,
support for statefulness and personalization will still need to consider similar
issues, e.g. state preservation/recovery and traffic overhead. As well, distributed services may still rely
upon redirect for web applications.
The overall goal is to set reasonable expectations on
the impact for use of cookies and redirect in service delivery to browsers and
web applications, and to address alternatives
for maintaining statefulness and personalization.
Web applications that autonomously interact with
network-based services can have a very significant impact on service cost.
These costs can be borne by the user and/or network service provider. Users with
"bucket" or per-KB service plans can find themselves responsible for huge
charges. Network service providers can bear these costs for users that subscribe
to unlimited service plans, and as a result may restrict the types of applications available
to users with such plans.
The overall goal is that users are informed of the
potential impact of application operation, and that regardless of the user's service plan,
applications use network resources conservatively.
- help spread the one web mentality
2.7.1 Presentation Issues
As addressed in BP1, presentation issues of
mobile devices can also be applicable to web applications in general,
e.g.
- variations in page rendering/layout in different
devices
- context/overview constraints due to limited screen
size and the limited amount of visible material
- dependency upon scrolling through material
- presentation space expense for images and navigation
links
- overall lack of site/content cohesiveness due to fragmentation of
display and site structure
However, advanced web browser features and
evolving web technologies are adding additional specific issues that need
to be addressed in the mobile context, including:
- support for popup windows and layers which can
overlap partially/fully
- support for popup menus
- dynamic changes in screen orientation
- need for content adaptation (e.g. image
resizing/cropping) due to variable presentation space
- overall usability issues resulting from more complex
presentation options
2.7.2 Interaction Issues
As addressed in BP1, issues of interaction with applications on mobile
devices can also be applicable to web applications in general, e.g.
- limited keypad, e.g. 16-key, leading to difficulty in
selecting \characters, and the need for application help in selecting the
input character type
- physical keying difficulty due to small key size
- form field navigation
- overall difficulty in entering text impacting
usability, e.g. for forms and long URLs
- no pointing device
- variations in softkeys for navigation and local application menus
However, evolution of mobile devices is adding additional specific issues
that need to be addressed in the mobile context, including:
As addressed in BP1, the basic aspects of delivery
context in the mobile environment, and how awareness of delivery context relates
to the goal of the "one web", also apply to web
applications in general.
BP2 extends/expands the discussion for specific delivery
context aspects, e.g.:
-
dynamic delivery context property awareness in
general, e.g. methods of determining current value of properties whether known by the device or by
the network only
-
issues for specific dynamic delivery context
properties, e.g. network bandwidth, roaming, location, network services
(e.g. content transformation
2.8 Applicability to Non-Browser Web Runtime
Environment
The focus of the BP2 document is on producing Best
Practices that apply to the browser sandbox, while recognising that they
may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM,
Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile
Widgets
2.9 Toolkit Developer Issues
Audience of BP2 document will include CPs as well as Ajax
and other toolkit developers.
3 The Mobile Context
Document will include a descriptive passage about mobile
context (including device, browser, network) we are talking about.
4 Structure of Best Practice Statements
- The Heading
-
The functional area that is addressed by the statements.
- The Statements
-
One or more Best Practice statements, identified in the following way:
[EXAMPLE] This is a Best Practice statement.
- What it means
-
An explanation of the significance of the statements under this heading.
- How to do it
-
A discussion of techniques and some suggestions as to how to implement.
- What to Test
-
The aspects of the delivered content that an external validator could
examine to assess conformance with the Best Practice statements. This section
is not present for process related statements.
In this section it is noted whether the statement is Machine
Testable (Automated testing is possible) or Human Testable
(Testing requires human assessment). Some Best Practices are partially machine
testable, i.e. based on the result of an automated test, some human
interaction may be required. In such cases both a Machine Testable and a Human
Testable statement are present.
Some Best Practice statements use words such as "minimize" and "avoid"
which are intentionally non-prescriptive. This is in order to provide guidance
while leaving room to accommodate a wide variety of applications whose
requirements cannot be anticipated. It also allows creativity and diversity
within the same Best Practice framework.
- References
-
Where appropriate, references to related WCAG points and other immediate
references from the preceding text.
- The Heading
-
The functional area that is addressed by the statements.
- The Statements
-
One or more Best Practice statements, identified in the following way:
[EXAMPLE] This is a Best Practice statement.
- What it means
-
An explanation of the significance of the statements under this heading.
- How to do it
-
A discussion of techniques and some suggestions as to how to implement.
- What to Test
-
The aspects of the delivered content that an external validator could
examine to assess conformance with the Best Practice statements. This section
is not present for process related statements.
In this section it is noted whether the statement is Machine
Testable (Automated testing is possible) or Human Testable
(Testing requires human assessment). Some Best Practices are partially machine
testable, i.e. based on the result of an automated test, some human
interaction may be required. In such cases both a Machine Testable and a Human
Testable statement are present.
Some Best Practice statements use words such as "minimize" and "avoid"
which are intentionally non-prescriptive. This is in order to provide guidance
while leaving room to accommodate a wide variety of applications whose
requirements cannot be anticipated. It also allows creativity and diversity
within the same Best Practice framework.
- References
-
Where appropriate, references to related WCAG points and other immediate
references from the preceding text.
Personalized services are enabled by content provider awareness of
personalizing information, e.g. user identity, preferences, characteristics.
Personalized services should be capable of using automated means of obtaining
such personalizing information, in order to reduce user effort in obtaining the
personalized service.
Content providers can often use personalizing information that is directly
forwarded by network proxies, e.g. as HTTP headers. Such
information may be made available by network operators through
developer and content provider programs.
Content providers can also use information, e.g. user credentials, which is
provided directly by the user on a first access, and then automatically provided
by the user-agent on subsequent accesses. An example method for this is to use
HTTP Basic or Digest Authentication.
Content providers may also be able to acquire personalizing information
directly through features of the user-agent, e.g. via Delivery Context Client
Interfaces (DCCI) methods.
Personalized services that rely upon manual entry of information
should retain that information to avoid the need to re-enter it upon each
site access, over a 24-hour period at least. Users are likely to quit using
services that ask for the same information often.
Information retention is possible by using cookies, as hidden information in
content (e.g. forms or URL parameters), in server-side databases, etc.
If the user must be asked to enter account information, personalized services
should simplify what they have to enter. Users are likely to quit using services
that ask for too much manual information entry, especially if obviously simpler
forms of entry are not provided.
Various techniques can simplify user information input, e.g.:
- require only entry of variable information, e.g. if
an email address domain can be assumed, require only the username, and don't
require the user to enter "@domain".
- provide well-known options as radio buttons, rather
than requiring the user to type them
- allow abbreviations, e.g. of locations
5.2 Security and privacy
Personally identifiable information (e.g. user identity or information usable
as a key to user identity) should only be accepted or sent securely. This will
ensure the confidentiality and integrity of the information. Information is
personally identifiable if it is by itself directly related to an
individual, e.g. a user's public identity such as name or phone number, or
can be correlated to an individual by being exchanged along with other
personally identifying information.
5.2.1.2 How to do
it
Public user identities should only be exchanged between user-agent and
content server using secure methods, e.g. HTTPS, or as securely hashed
information through a strong secure hash algorithm. To avoid the overhead of
using HTTPS for all transactions, a related pseudo-identity or secure hash
of the actual identity can be exchanged in non-secure transactions.
Since information is not personally identifiable unless it can be
associated with an individual, e.g. a zip code which is by itself not
personally identifiable, such information can be exchanged in the
clear if the correlating information is itself secure, e.g. as a securely
hashed identifier. As long as an application meets the basic objective that
user identities are protected during exchange, other information can be
exchanged in the clear.
5
.3 User
awareness and
control
Users should be informed if applications will
make automatic data requests that can impact service cost, and should be given
information that will help the user assess the significance of that impact.
While the significance ultimately may depend upon information that only the user
knows (e.g. their data service plan), having such notices up-front can avoid unexpected negative side-effects, e.g. significant usage charges
or effect upon battery life.
5.3.1.2 How to do it
Applications should disclose, in a clear and
useful way, the basic nature of their automatic use of the internet for data
exchange, e.g.:
-
how often the application will interact via the internet, e.g. every 5
minutes, hourly, daily
-
how long the automatic behavior will continue
-
roughly how much data traffic will occur, e.g. in kilobytes, in a given
period e.g. over each day, month, or per use of
the application
Users should be informed of impacts to device
memory (for application code and data) due to installation and use of
applications. Because mobile devices typically are memory-constrained, the effect of application installation and use
can be much more significant than in other devices.
5.3.2.2 How to do
it
The following information should be
disclosed:
- the installed size of the application
- the percentage of free device memory consumed by the
installation, and the amount of free device memory left after installation
- the typical/maximum amount of device memory to be used for
application data
While use of personal or contextual information can enhance service
effectiveness, applications should ensure that the user is aware of such
information use and exchange.
5.3.3.2 How to do
it
The following information should be
disclosed:
- the types of personal information (data or contextual
information, e.g. location) that will be used by the application
- what data will be exchanged via the internet
Disclosures about application behavior are useful only if they are provided
at a useful time and in useful ways. A non-useful disclosure is practically a
non-disclosure.
5.3.4.2 How to do
it
Disclosures should be provided during application selection, install, on
first runtime, or first use of sensitive functions.
Disclosures should be automatically provided e.g. as a user dialog, or easily
accessible to the user e.g. via an "about this application" menu option.
Unless a sensitive application behavior is essential to the application,
users should be given the option to control the behavior. If the behavior is
essential to the application, users should be given the option to opt-out of
application use.
5.3.5.2 How to do
it
Users should be given easy-to-use controls to personalize application
behavior, e.g.
- Configure automatic operations, e.g. content update
schedules
- Manage data memory use
- Select privacy/security options
If user control over sensitive application functions is not provided, users
should be given the chance to opt-out for the function, or to terminate the
application.
User control preferences should be saved by the application to avoid the need
to reenter them each time the application is used.
5.4 Use of cookies and redirection
Cookies may play an essential role in application design. However since they
may be lost, applications should be prepared to recover the cookie-based
information when necessary. If possible, the recovery should use automated
means, so the user does not have to re-enter information.
5.4.1.2 How to do
it
Server databases can be used to store user information with persistence
longer than typical session or cookie lifetime. Applications can be designed to
recognize loss of cookie information, and direct the user or user-agent to a
resource through which the information can be recovered from a database server.
After recovery, the user or user-agent may be directed to a server which then
provides service based upon the restored cookie information.
These methods can increase information persistence, while limiting
database server expense.
User-agent redirect is a typical method for a service to automatically obtain
necessary information from a different server. Such redirect based API's are
very common in web applications, and play an useful role in automated
personalization for mobile web applications, e.g. to avoid manual information
entry. However latency, efficiency, and interoperability considerations
benefit from minimizing the number of automated redirects in a sequence, for
this purpose.
5.4.2.2 How to do
it
A typical redirect sequence should require no more than two automated
redirects, e.g. one to redirect to the information-providing server, and another
to redirect back to the service-providing server. If further redirects are
required, e.g. to a second information-providing server based upon the
information obtained from the first information-providing server, a landing page
can be used to break up the overall sequence, into two automated redirect
sequences with a user "continue" click in the middle. This has the effect
of reducing the apparent latency for the user, but should be balanced against
the need for an extra user action, as four redirects in sequence (when
necessary) are rarely an interoperability issue.
Web applications that autonomously interact with
network-based services should be designed to minimize the overhead of
network traffic for such automatic functions. Such web applications are refered
to here as "autonomously interacting web applications".
HTTP compression is a widely supported method of content optimization, most
useful for text-based content e.g. markup languages and documents. Typical
performance for HTTP compression use is 5:1 compression ratio for web pages,
which also translates into a 5x latency improvement.
5.5.1.2 How to do
it
Web servers should be configured to serve web pages using HTTP 1.1
compression (gzip or deflate), for both upload and download
transactions.
Applications should not create network traffic unless
there is a particular valuable reason for it. The "value" in this case should be determined by the application based upon the type of service
it provides, and the resulting direct value to the user. For applications that automatically
issue network requests, e.g. dynamically updating applications built using AJAX
methods and XMLHttpRequest in particular, managing data usage should be a
key consideration.
5.5.2.2 How to do
it
Overall data usage effectiveness can be
improved by:
-
Applications can minimize the number
of interactions with the server, e.g. via XMLHttpRequest, by following some basic
guidelilnes, e.g.:
-
wait until there is sufficient value to the user
before sending requests, i.e. focus on how the request improves the
user exerience
-
if there is no direct value to the user from sending individual
requests, bundle transactions by combining multiple operations into one, e.g.
for prefetching data that is known to be useful at a
later time
- Applications can vary network request intensity based
upon the current value to the user, depending e.g. upon whether the user is
actively using the application, whether new information is ready to be
uploaded/downloaded, etc. Applications that are designed to "back off"
automatic behaviors during low-value periods can improve the overall cost
effectiveness of their use. Example criteria for determining the useful
transaction rate:
-
based upon intensity of user interaction with the application, e.g. if use
slows down considerably for an extended period, the application may assume a
lower user benefit from network traffic
-
based upon success ratio of network transactions, e.g. number of messages received
for mail/social-networking applications, news feed items published, etc
-
based upon typical usage patterns, e.g. reduced automated transactions at night
or periods of typical low usage/success
Network-initiated content delivery ("push") methods can significantly reduce
network traffic overhead, as compared to conventional polling (scheduled "pull")
methods. While scheduled pull is a useful method for content that is regularly
published, e.g. news/traffic/weather etc., some service types such as
messaging/social-networking and "breaking news" monitoring can greatly
benefit from use of push methods in terms of overall traffic effectiveness and
timely content delivery.
5.5.3.2 How to do
it
OMA
Push is a widely supported enabler providing methods for user-confirmed and
automatic content push, directed to mobile browsers and other user-agents.
Developers sometimes don't consider the impact of the
size of their application content, e.g. web pages, on mobile browsers.
Recognizing that you are developing for a mobile web
application, and using effective techniques for minimizing the overall application size,
will improve the user experience for mobile web applications.
5.5.4.2 How to do
it
Avoid overuse of nested css classes that can bloat
repeated blocks of content. Instead, make good use of selectors to minimize the
size of repeated blocks of HTML. Bear in mind that css is
easier to cache than generated HTML pages.
Use markup language to create the minimal page framework
and flesh out repetitive/dynamic aspects
of the page using javascript. For example:
-
For a page displaying 100 contacts, the data for
those contacts is much more compactly transmitted as a
JSON string [JSON] than as fully-rendered HTML.
-
The framework page ideally contains no dynamic data
so
it can be much more aggressively cached.
-
A "loading" spinner can be displayed while an asynchronous request is made to
get the guts of the data. Since a small and/or aggressively cached html page would
load quickly this creates a better user-experience overall.
When an application depends upon multiple external script files, it typically must
retrieve them separately from the main page itself. This
can increase data usage and
service latency. Overall reduction of the number and size of script files can
avoid these effects.
5.5.5.2 How to do
it
If your application depends upon external scripts:
-
Reduce the number of HTTP
GETs required to retrieve the script files, e.g. by
-
Keep the number of script files to
a minimum, e.g. by combining several script files into one
-
Send the
scripts and main page together as a multipart/related package
-
Reduce the size of your script files, e.g. by
-
Removing whitespace and comments
-
Making variable names in the code shorter
-
Use HTTP 1.1
compression [5.5.1 Support HTTP 1.1 Compression] when sending script files
See http://developer.yahoo.com/yui/compressor/ for an
example approach to script compression.
5.7 Presentation
Issues
Use script for the dynamic aspects of the user
interface
Use script for the dynamic aspects of the user
interface
5.8 Interaction Issues
If you want the user to be able to
easily make a phone call to a phone number included in a web page,
use the TEL: URI scheme.
5.8.1.2 How to do
it
The tel: URI scheme is defined in [RFC 3966]. The
following example allows the user to click a link to make a call, in devices that support the tel:
URI scheme:
Dial <a
href=
"tel:+1-212-555-0101">+1-212-555-0101</a> for assistance.
Including the phone number in the link text is recommended, so the user knows what number will
be dialed.
5.9
Delivery Context Variability
It can be tricky to determine the supported script
capabilities for a device. Use of reliable methods is recommended.
5.9.1.2 How to do
it
When available, a device description repository (DDR) may
be helpful in determining what script support is available for a device.
When a DDR is not available or the current device is not
supported in the DDR, use Javascript reflection to check for available
functionalities. This avoids the error-prone approach of trying to parse the
user-agent string to determine Javascript support. An example of how to use
Javascript reflection:
Use Javascript Reflection and if statements
+
if(window.ActiveXObject) {
// Instantiate using new
ActiveXObject } else if(window.XMLHttpRequest) {
// Instantiate using new XMHttpRequest }
AJAX is not supported by some browsers. Applications
designed to use AJAX methods will require alternate approaches in non-AJAX
browsers, so you should be prepared for that and provide the same functionality
in case AJAX it is not available.
5.8.1.2 How to do
it
Detect browser capabilities or user preferences and react accordingly.
[Some guidance on
alternate techniques would be helpful here']
5.11 Resource
Constraints
Various design
techniques can negatively impact battery life. These should be avoided and alternate techniques used where
possible, to minimize battery drain.
5.11.1.2 How to do
it
Use script only for the dynamic aspects of the user
interface. DOM manipulation and creation of new nodes can consume a lot of
battery at the device side, so as
much as possible create user interface elements using the markup language and modify (if needed) those elements using scripting.
For example:
-
When a page is first served from the server side, it
should contain all the markup that declares and populates user interface elements (forms,
selects, input, etc). If rich interactions are needed later then use scripting to mutate or modify the DOM of
the page.
5.12 Applicability to Non-Browser Web Runtime
Environment
5.13 Toolkit Developer Issues
Issues from the BPWG list
- A mobile property for providing seamless contents
connection among different types of terminals. Simply speaking, while user is
receiving the service with non-mobile device from web server, suddenly if user
want to change into different mobile device without restarting same service, Web
server and mobile device need to have some functionality to support this
capability.
