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.
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:
- new pointing methods, e.g. touch screens
- dynamic changes in keyboard layout, e.g. between
16-key, querty, and soft keyboards
-
solve the top left navigation problem [need a definintion of what this is, and
consideration of whether it is actually
testable]
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.
Personalized services should be capable of basing personalization upon
information obtained directly from the user-agent or network entities, e.g.
through HTTP headers or message body.
Personalized services that rely upon manual entry of information should
preserve that information to avoid the need to re-enter it upon each site
access, over a 24-hour period at least.
If the user must be asked to enter account information, personalized services
should simplify what they have to enter, e.g. for email addresses, assume the
domain (if possible) or offer well-known options as radio buttons.
5.2 Security and privacy
Personally identifiable information (e.g. user identity or information usable
as a key to user identity) should be accepted or sent securely, i.e. over secure
transport (HTTPS), or securely hashed if sent over non-secure transport.
5
.3 User
awareness and control
Users should be informed if applications will make automatic data requests
that can impact service cost.
Users should be informed of impacts to device memory (for application code
and data) due to installation and use of applications.
Users should be informed about the types of personal information (data or
contextual information, e.g. location) that will be used by the application, and
exchanged over network connections.
Informational notices should be provided during application selection,
install, on first runtime, or first use of sensitive functions.
Informational notices should provide an estimate of the impact so the user
can determine its significance.
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
If personalized services use cookies, they should be capable of recovering
the cookie-based information without requiring user information reentry, e.g. if
the user-agent cookie cache is cleared.
If achieving personalization via redirect-based APIs, personalized services
should use redirect in an efficient manner to reduce latency and data overhead,
and require no more than two redirects to obtain the necessary
information.
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".
Autonomously interacting web applications should support content compression,
e.g. HTTP 1.1 gzip/deflate compression, for both upload and download
operations.
Autonomously interacting web applications should support user control over
the intensity of the network interaction.
Autonomously interacting web applications should be intelligent enough to
"back off" autonomous operation during periods in which little or no service
value results from the network interaction.
Autonomously interacting web applications that provide network
event-triggered content delivery should support push methods, e.g. OMA Push, to
avoid the need for rapid polling for new events.
5.7
.1 Presentation
Issues
5.7.2 Interaction Issues
5.8 Applicability to Non-Browser Web Runtime
Environment
5.9 Toolkit Developer Issues
