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 advanced Web technologies, which apply both to browsers and non-browser web
runtime environments.
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 the goal of the document is to specify Best Practices for delivery to
mobile devices, statements that do not have a specific mobile aspect are not
included. In particular, many Web Content Accessibility [WCAG] guidelines are general
to all forms of Web access and are not repeated here unless they have a
specific mobile interpretation. Examples of general good practice which have
a specific mobile interpretation include "Error Messages" and "Color".
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:
- are considered essential for successful deployment of
web applications in common delivery contexts
- are considered of fundamental importance to growth in
the mobile web application market
- can be readily verified through compliance testing, either automated (preferred) or
manual
These recommendations follow in the footsteps of the BP1,
and as such are in part derived from the Web Content
Accessibility Guidelines [WCAG] . The WCAG
guidelines are supplementary to the Mobile Web Best Practices, whose scope is
limited to matters that have a specific mobile relevance.
This document builds on some of the concepts described by the Device Independence Working Group
(DIWG) in the Device Independence Principles [DIP]. The document discusses
device and delivery channel characteristics, which the DIWG has named
"Delivery Context" [DCODI]. In addition, the
document uses some terminology from DIWG's Glossary of Terms for Device
Independence [DIGLOSS].
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.
The value of automated transactions may vary, 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.
5.5.2.2 How to do
it
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. Example methods include:
-
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.
5.7
.1 Presentation
Issues
5.7.2 Interaction Issues
5.8 Applicability to Non-Browser Web Runtime
Environment
5.9 Toolkit Developer Issues
Input from the BP list
Jo Rabin
- Use tel: scheme to take advantage of the telephony
capability of the device. Given that the device is often also a telephone, use
of such schemes help the user to use non Web capabilities in a range of
applications such as listings, contact and so on. Other schemes that may be
considered include sms:, wtai: …
José Manuel Cantera Fonseca
- Keep the number of external script files to a minimum:
Combine several script files into one at deployment time
+ Removing
whitespace and comments (it could be done at deployment time)
+
Making variable names in the code shorter (it could be done at deployment time,
although it could be tricky or dangerous)
+ Sending script files with
gzip content-coding (if the browser support it)
+ Aaron Kemp: but
watch out for max cacheable object size
+ Example: http://developer.yahoo.com/yui/compressor/
-
Use script for the dynamic aspects of the user interface
- Minimize the
number of interactions with the server via XMLHttpRequest
- Provide non-AJAX
alternatives to your applications
- Use Javascript reflection to check for
available functionalities
- Minimize the number of script files
- Use
Javascript reflection to check for available functionalities avoiding parsing
the user agent string. The user agent string cannot be trusted while trying to
figure out what are the script functionalities available.
+ How to do
it (example): Use Javascript Reflection and if statements
+
if(window.ActiveXObject) {
// Instantiate using new
ActiveXObject } else if(window.XMLHttpRequest) {
//
Instantiate using new XMHttpRequest }
- Provide non-AJAX alternatives to your
applications. There can be browsers that don't provide AJAX support so you
should be prepared for that and provide the same functionality in case AJAX it
is not available.
+ Could the user have also a preference on to-AJAX
or not AJAX? If he wants to save battery ... that could be something to
discuss
+ How to do it: Detect browser capabilities or user
preferences and react accordingly
- The number of interactions with the
server made via XMLHttpRequest should be kept to a minimum, prefetching data as
much as possible
+ How to do it: If you know that some data coming
from the server is going to be needed later, prefetch that data and keep
it in memory until it is finally needed
- 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
+ How to do it: 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
Adam Connors
- 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.
+ The logic of this is:
- lets say I
have a page displaying 100 contacts... the data for those contacts is much more
compactly transmitted as a json string 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.
+ This is
the approach we are using in our applications at the moment and it seems to be
giving us a better overall user-experience. It would be useful to understand the
tradeoffs though -- perhaps an experiment is required ? I don't know much about
impacts to battery life but since it's a short-term bit of processing at the
moment the page is displayed I can't imagine it has such a dramatic effect.
Sunghan Kim
- A mobile property for providing seamless content’s
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.
Barbara Ballard
- The user may also have a data plan that is not
unlimited; in those cases she should have control over how much data a page is
using.
