Copyright
©
2008
2009
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document specifies Best Practices for the development and delivery of Web applications on mobile devices. The recommendations expand upon statements made in the Mobile Web Best Practices 1.0 (BP1), especially those that relate to the exploitation of device capabilities and awareness of the delivery context. Furthermore, since BP1 was written, networks and devices have continued to evolve, with the result that a number of Best Practices that were omitted from BP1 can now be included.
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 application technologies. Readers are not expected to have a background in mobile technologies or previous experience with BP1.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Incomplete draft : This document is an editors' copy that has no official standing. It is subject to major changes and is therefore not intended for implementation. In particular, the list of Best Practices is not settled yet. The document is provided for review and feedback only . Please send feedback to public-bpwg-comments@w3.org ( archive ).
The Working Group is particularly seeking feedback on:
This document was developed by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . Most of the best practices statements were changed since the publication of the First Public Working Draft on 29 July 2008 . A complete list of changes is available.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This
document
is
a
Second
Third
Public
Working
Draft
intended
to
progress
along
the
Recommendation
track
and
be
eventually
published
as
a
Recommendation.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
List
of
Best
Practices
1
Introduction
1.1
1.1
Purpose
of
the
Document
1.2
1.2
Audience
1.3
1.3
Scope
1.3.1
1.3.1
Best
Practices
1.3.2
1.3.2
Web
Application
1.3.3
1.3.3
Mobile
Context
1.3.4
1.3.4
Delivery
Context
1.4
1.4
Relationship
to
other
Best
Practices
and
recommendations
1.5
1.5
Terminology
2
Structure
of
Best
Practice
Statements
3
Best
Practice
Statements
3.1
3.1
Application
Data
3.1.1
3.1.1
Use
Cookies
for
Simple
Client-Side
State
Sparingly
3.1.2
3.1.2
Use
HTML5
Appropriate
Client-Side
Storage
Technologies
for
Local
Data
Model
3.1.3
3.1.3
Replicate
Local
State
Changes
to
a
Server
When
Possible
Data
3.2
3.2
Security
and
privacy
3.2.1
3.2.1
Do
not
Execute
Untrusted
JavaScript
3.3
3.3
User
Awareness
and
Control
3.3.1
3.3.1
Inform
the
User
About
Automatic
Network
Access
3.3.2
3.3.2
Provide
Sufficient
Means
to
Control
Automatic
Network
Access
3.3.3
3.3.3
Ensure
the
User
is
Informed
About
Use
of
Personal
and
Device
Information
3.4
3.4
Conservative
use
of
resources
3.4.1
3.4.1
Use
Transfer
Compression
3.4.2
3.4.2
Minimize
Application
and
Data
Size
3.4.3
3.4.3
Avoid
Redirects
3.4.4
3.4.4
Optimize
Network
Requests
3.4.5
3.4.5
Minimize
External
Resources
3.4.6
Consider
Including
Small
Style
Sheets
and
Script
Resources
In-Line
3.4.7
3.4.6
Aggregate
Static
Images
("Sprites")
into
a
Single
Composite
Resource
3.4.8
3.4.7
Include
Background
Images
Inline
in
CSS
Style
Sheets
3.4.9
3.4.8
Use
Fingerprinting
to
Cache
Dynamic
Resources
3.4.10
3.4.9
Cache
AJAX
Data
3.4.11
Use
Power-Efficient
Methods
3.4.12
Minimize
DOM
Manipulation
3.4.13
Reduce
Cookie
Size
3.4.14
3.4.10
Don't
Send
Cookie
Information
Unnecessarily
3.5
3.5
User
Experience
3.5.1
3.5.1
Design
for
Multiple
Interaction
Methods
3.5.2
Use
Scripting
to
Improve
3.5.2
Minimize
Perceived
Performance
Latency
3.5.3
3.5.3
Preserve
Focus
on
Dynamic
Page
Updates
3.5.4
Group
Closely
Coupled
Views
3.5.5
3.5.4
Use
Fragment
IDs
to
Maintain
Application
History
3.5.6
3.5.5
Make
Telephone
Numbers
"Click-to-Call"
3.5.7
3.5.6
Ensure
Paragraph
Text
Flows
3.5.8
Separate
Rarely
Used
Functionality
3.5.9
Enable
Progressive
Rendering
3.5.10
3.5.7
Ensure
Consistency
Of
State
Between
Desktop
and
Mobile
Devices
3.5.11
3.5.8
Consider
Using
Push
Mobile
Specific
Technologies
for
Initiating
Web
Applications
3.5.12
3.5.9
Use
Canvas
Tag
For
Dynamic
Graphics
3.5.13
3.5.10
Use
viewport
Meta
Tag
To
Identify
Desired
Screen
Size
3.6
3.6
Handling
Device
Capability
Variation
3.6.1
3.6.1
Use
Server-side
Capability
Detection
3.6.2
3.6.2
Use
Client-side
Capability
Detection
for
Dynamic
Device
State
3.6.3
3.6.3
Use
Device
Classification
to
Simplify
Content
Adaptation
3.6.4
3.6.4
Support
a
non-JavaScript
Variant
if
Possible
Appropriate
3.6.5
3.6.5
Offer
Users
a
Choice
of
Interfaces
Appendix:
Best
Practice
Dependent
Device
Properties
Appendix:
Examples
A
Sources
(Non-Normative)
B
Related
Reading
(Non-Normative)
C
Acknowledgements
(Non-Normative)
D
References
(Non-Normative)
D.1
D.1
MWI
References
D.2
D.2
Sources
D.3
D.3
Device
Independence
D.4
D.4
Web,
Protocols
and
Languages
The following Best Practices are discussed in this document and listed here for convenience.
This document sets out a series of recommendations designed to facilitate development and delivery of Web applications on mobile devices. The recommendations are offered to creators, maintainers and operators of mobile Web sites.
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, but are not expected to have a background in mobile technologies or previous experience with Mobile Web Best Practices 1.0 (BP1).
The intention is to make 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 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, site administrators, and tool developers are encouraged to read it.
These
recommendations
expand
on
the
recommendations
of
the
Mobile
Web
Best
Practices
(BP1)
[ref]
.
1.0
(BP1).
Where
the
focus
of
BP1
is
primarily
the
extension
of
Web
browsing
to
mobile
devices,
this
document
considers
the
development
of
Web
applications
on
mobile
devices.
The approach in writing this document has been to collate and present the most relevant engineering practices prevalent in the development community today and identify those that: a) facilitate the exploitation of device capabilities to enable a better user experience; or b) are considered harmful and can have non-obvious detrimental effects on the overall quality of the application.
The goal of this document is not to invent or endorse future technologies. However, there are a number of cases where explicitly omitting a Best Practice that referred to an emerging technology on the grounds that it was too recent to have received wide adoption would have unnecessarily excluded a valuable recommendation. As such, some Best Practices have been included on the grounds that the Working Group believes that they will soon become fully qualified Best Practices (e.g. in prevalent use within the development community).
In building a Web application, it's not necessary to implement all Best Practices in order to avoid pathological behaviour. Instead, each Best Practice should be considered as a possible measure that might be implemented towards the goal of providing as rich and dynamic an experience as possible on a mobile Web browser.
For the purposes of this document, the term "Web application" refers to a Web page (XHTML or a variant thereof + CSS) or collection of Web pages delivered over HTTP which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser. Web applications are distinct from simple Web content (the focus of BP1) in that they include some elements of interactivity and persistent state.
While
the
focus
of
this
document
is
to
document
Best
Practices
that
apply
to
applications
running
in
a
Web
browser,
in
many
cases
these
recommendations
are
equally
applicable
to
other
kinds
of
Web
run-time,
such
as
the
widget
frameworks
being
considered
as
part
of
the
Web
Widgets
[REF]
[@@ref
needed]
effort
and
also
in
a
number
of
vendor-specific
initiatives.
In an increasingly mobilized world the line between mobile and non-mobile is necessarily blurred and a document that restricts its focus solely to best practices that are uniquely mobile would most likely be very short. With this in mind, the focus of this document is to address those aspects of Web application development for which there are additional, non-trivial concerns associated with the mobile context. This applies equally both to the limitations of the mobile context (e.g. small screen, intermittent connectivity), and also the additional scope and features that must be considered when developing for the mobile context (e.g. device context / location, presence of personal data on the device, etc).
Requirements
on
delivery
context
have
not
been
made
explicitly,
but
most
best
practices
assume
devices
with
basic
standard
XHTML,
JavaScript,
and
CSS
compliance.
capability.
Additionally,
some
best
practices
Best
Practices
are
relevant
only
if
the
device
exposes
certain
capabilities
(for
example,
access
to
device
information
such
as
location).
[
TODO:
Make
compliance
assumptions
explicit:
XHTML
basic
/
CSS2
/
ECMAScript
/
etc
(Eduardo)
]
Implied
by
this
discussion
is
that
some
level
of
device
knowledge
and
content
adaptation
is
required.
For
best
practices
Best
Practices
specifically
related
to
this
area,
see
3.6.1
Use
Server-side
Capability
Detection
for
Device
Properties
and
3.6.2
Use
Client-side
Capability
Detection
for
Device
State
.
These recommendations are complimentary to the recommendations of Mobile Web Best Practices 1.0 (BP1).
This document builds on some of the concepts described by the Ubiquitous Web Applications Working Group (UWA) and the Device Independence Principles [DIP] . The document discusses device and delivery channel characteristics, which the UWA has named "Delivery Context" [DCODI] . In addition, the document uses some terminology from UWA's Glossary of Terms for Device Independence [DIGLOSS] .
Note that the term "JavaScript" is used in place of the (arguably more correct) term "ECMAScript" in order to provide consistency with the companion Web application technologies (JSON and AJAX) which are in common use and both implicitly refer to JavaScript in their names.
Also, the terms "AJAX" and XMLHttpRequest (XHR) are used to refer to any asynchronous browser request. The implicit reference to XML suggested by the names is commonly accepted to be an historical anomaly.
Most applications have the need to store data of various forms, both intrinsic content (e.g. the emails of an email application, the calendar events of a calendar application) and supplementary personalization settings (e.g. preferred theme, default view, etc).
These
Best
Practices
relate
to
the
appropriate
technologies
and
techniques
to
use
for
managing
a
Web
application's
data
model.
data.
Cookies
are
a
common
and
effective
means
to
store
small
amounts
of
state
on
the
client.
They
are
most
appropriate
for
simple
personalization
data
and
are
also
commonly
used
to
store
a
token
representing
user
identity
in
order
to
enable
automatic
sign-in.
Note
however
Note,
however,
that
information
stored
in
cookies
is
sent
to
the
server
for
every
request
and
so
using
them
for
excessive
amounts
of
data
can
negatively
impact
performance.
Also,
cookie
support
cannot
be
relied
upon
and
may
be
disabled
either
in
the
device
configuration
or
by
the
mobile
network.
For
this
reason
reason,
applications
should
endeavour
to
remain
as
functional
as
possible
even
if
cookies
are
unavailable.
Also
note
that
cookie
data
is
sent
to
the
server
with
each
request
and
so
an
excessive
volume
of
cookie
data
can
degrade
performance
over
mobile
networks.
See
3.4.14
Reduce
Cookie
Size
and
BP1
[COOKIES]
Do
not
rely
on
cookies
being
available
for
appropriate
cookie
related
caveats.
If
HTML5
is
supported,
supported
by
the
device,
client-side
storage
APIs
can
be
used
provide
a
mechanism
to
store
data
locally
on
the
device.
For
a
more
detailed
technical
summary
see
Offline
Web
Applications
extensive
amounts
of
data
than
would
be
appropriate
with
cookies.
Some
examples
of
technologies
that
support
client-side
storage
APIs
are
BONDI
,
HTML5
,
and
Opera
Widgets
.
Client-side
Making
use
of
client-side
storage
provides
in
Web
applications
is
a
powerful
mechanism
for
technique
that
brings
Web
applications
to
maintain
a
local
data
model.
This
provides
two
main
advantages:
into
parity
with
native
applications
in
terms
of
start-up
time
and
responsiveness.
Two
key
advantages
are
worth
noting
explicitly:
[
HTML5
icon
Client-Side
Storage
Icon
]
Requires:
HTML5
Local
Storage
API
and
HTML5
Database
Storage.
TODO:
Should
we
be
referring
to
HTML5
or
local
storage
in
general...
I
would
prefer
to
be
explicit
provided
HTML5
client-side
storage
is
sufficiently
supported
/
defined.
API.
Local
data
If
a
client-side
storage
API
is
a
powerful
provision
that
allows
Web
applications
being
used,
it's
important
to
maintain
a
local
remember
that
this
data
model.
However,
changes
is
not
visible
to
the
local
other
devices.
Whilst
this
is
adequate
for
some
forms
of
data
model
are
only
visible
on
the
device
that
made
them
(e.g.
preferences
and
should
be
replicated
state
relevant
only
to
the
a
given
device),
it
is
often
necessary
to
replicate
this
data
back
to
a
server
in
order
to
provide
a
consistent
view
across
devices.
devices
and
make
it
possible
to
recover
data
if
the
device
is
lost
or
damaged.
See
3.5.10
Ensure
Consistency
Of
State
Between
Desktop
and
Mobile
Devices
for
more
details.
further
discussion
on
this
topic.
As a rule of thumb, data that needs to be shared with other devices or recovered in the case of a lost or damaged device, should be replicated back to the server as soon as possible.
The technologies that provide client-side storage APIs should provide facilities to detect the current network connectivity. For example, HTML5 provides a provides a property on the navigator object ( navigator.onLine ) to indicate whether the client is currently online, and dispatches two events on the Window object to indicate a change of network state ( online and offline ).
Mobile
Web
applications
should
use
these
events
to
control
the
asynchronous
replication
flow
of
data
back
to
the
server.
server
and
to
build
up
a
local
queue
of
changes
if
the
application
is
offline.
[
HTML5
icon
Client-Side
Storage
Icon
]
Requires:
HTML5
Local
Storage
API
and
HTML5
Database
Storage.
TODO:
Discuss
this
--
can
we
really
call
it
a
best
practice?
Techniques
will
improve
application
performance
but
at
expense
of
considerable
additional
complexity.
It
only
really
applies
to
high-performance
Web
applications
and
performance
won't
be
pathologically
bad
without
it.
API.
Use trusted information, and protect all personally identifiable information.
3.2.1.1 What it means
JSON is a very commonly used method to transfer data to the client, usually as part of an asynchronous request. However, using eval(); to directly execute the incoming datafeed represents a security risk and should be avoided.
Inadvertantly executing malicious JavaScript is particularly dangerous on mobile devices where personal information (current location, contact data, etc) may be exposed.
3.2.1.2 How to do it
Instead of parsing JSON data by executing it with the browser's eval(); command, use a JSON parser instead (for example: http://www.json.org/json_parse.js ).
In cases where directly evaluating the JSON data is desirable for reasons of efficiency, ensure that the data either contains no user-generated content (e.g. the server is responsible for all fields in the datafeed) or that any user-generated content is correctly escaped.
Ensure that the user is aware of otherwise invisible application actions, and offer options to control those actions.
Browsers may have access to information such as:
Many browsers support the ability to make background server requests (i.e. requests that do not require action by the user). Unless specific action is taken to provide information about such activity, users may be exposed to revealing information that they did not intend to reveal and may be subject to unexpected data charges.
Whenever an application makes asynchronous XHR data requests, whether automatic (on a timer or in response to an external trigger) or secondary to some user action, this should be indicated to the user in an appropriate manner.
Applications should disclose how they use network resources. A simple icon indicating background activity is usually sufficient and does not interrupt the flow of the application. If extensive background network activity is required the user should be informed when they first visit the site, when they first sign-in, or in associated help pages.
The kinds of detailed information that could be disclosed in associated help pages or terms of service are:
If an application makes automatic network requests (e.g. to poll the server for updates or to automatically store an updated client state) a means to control this activity must be provided.
All applications that access the network automatically must provide a means for the user to disable that activity. When automatic network activity is disabled, periodically prompt the user to make network requests.
Consider allowing the user to adjust the polling schedule and to control which activities are allowed to initiate network requests.
Ensure that the user is informed if the application needs to access personal or device information. The user should be informed of the types of information that will be used by the application and whether / how that data will be exchanged with the server.
These notices should be provided when the user first accesses the Web application, on first access to user information, or in help pages. It should provide the user with enough information to reasonably judge whether or not they want to allow the application access to their data.
In
many
cases
use
of
APIs
that
provide
access
to
personal
or
device
information
causes
a
native
confirmation
dialog
to
be
presented
to
the
user.
In
this
case
the
application
should
not
force
the
user
to
confirm
again
at
the
application
level,
but
should
make
clear
in
the
UI
that
displayed
data
has
been
accessed
from
the
device.
Need
example
of
how
to
do
this?
and
how
should
it
know
that
a
confirmation
dialog
is
or
is
not
presented?
If the user declines a prompt to allow application access to personal or device information, the application must recover gracefully. For example, if a request to a device API fails, do not automatically retry if this will lead to the user being presented with repeated native confirmation dialogues.
[
PIM
DEVICE
DATA
icon
]
Requires:
PIM
Device
Data
APIs.
Resources,
Battery
lifetime
and
cost
of
network
traffic
are
significant
considerations
of
most
users
of
mobile
devices.
Since
all
activities
that
use
either
processor
or
wireless
connectivity
will
incur
some
cost
to
battery
life
and
/
or
network
data
costs,
applications
should
consider
this
factor
and
be
conservative
in
their
use
of
resources.
Additionally, resources, such as device memory, processor power, and network bandwidth are significantly more limited on mobile devices than on the desktop. The most effective way to ensure that applications run smoothly and with low latency is to take steps to ensure minimal use of resources.
Compress content for efficient delivery.
HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms is widely supported. Web servers should be configured to serve appropriately compressed responses.
Note however, that the cost (in time and battery usage) of decompressing data should be balanced against the gains in transport efficiency. When configuring HTTP 1.1 compression note that:
This section elaborates on the Best Practices of BP1 ( MINIMIZE ). Smaller applications will download and execute more quickly and more reliably than larger ones on constrained devices.
Process
HTML,
JavaScript
and
CSS
files
to
remove
whitespace
and
minify
before
delivery.
A
number
of
open
source
freely
available
whitespace
strippers
and
JavaScript
compilers
/
CSS
optimizers
are
available.
available
online.
The
working
group
is
seeking
recommendations
for
Note
that
"minification"
/
"optimization"
can
take
a
number
of
forms
from
simple
removal
of
whitespace
and
comments,
to
the
best
global
substitution
of
tokens
(variables,
method
names,
selector
names)
with
shorter
alternatives,
to
alternative
binary
and
compressed
representations
of
the
underling
data.
In
general,
minification
that
parses
the
source
file
and
makes
substitutions
based
on
a
lexical
/
most-commonly
used
tools
grammatical
understanding
of
that
source
are
less
fragile
and
should
be
preferred
to
reference
in
this
section.
simple
regular-expression
based
tools.
For a good comparison of JavaScript minification tools try: http://compressorrater.thruhere.net
Request redirection (through HTTP response header or meta refresh) is typically used to exchange information between servers (e.g. account authentication). The delay incurred by redirects is much higher over mobile networks and so the number of redirects should be kept to a minimum to avoid degrading the user experience.
Try not to use more than two redirects for any request. If further redirects are required, use an interstitial page to communicate to the user that the application is still working.
Network operations are costly in terms of battery usage, application latency, and potential network traffic expenses, and should not be made unnecessarily. The latency cost of setting up a HTTP request is much higher than the bandwidth limitations on a mobile network and so fewer, larger requests are preferred.
Consider the following possibilities when designing an application:
3.4.5.1 What it means
A Web application typically requires a number of resources (style sheets, scripts, image, etc) each of which may incur an additional HTTP Request. HTTP round trips are particularly expensive on a mobile network and so fewer, larger requests should be favoured over a larger number of smaller requests.
3.4.5.2 How to do it
As far as makes sense after taking into account 3.5.8 Separate Rarely Used Functionality combine all style sheets into a single resource and all scripts into a single resource. If multiple scripts and style sheets are required as part of the authoring process, then try to arrange that they are merged before the page is served.
3.4.7.1
3.4.6.1
What
it
means
Web applications often depend on a number of static images to provide icons, buttons, etc. If served as a separate image each one incurs an additional HTTP round-trip which is detrimental to performance when compared with combining them into a single image for transfer.
3.4.7.2
3.4.6.2
How
to
do
it
To optimize efficiency:
To render individual components of a resource use CSS positioning and clipping.
[ ICON: CSS ] Requires: CSS2 Clipping and Positioning Support
3.4.8.1
3.4.7.1
What
it
means
Background images are often used as gradients to improve the look and feel of an application. These can be included in the CSS as base64 encoded strings in order to avoid an additional HTTP round trip.
Note that base64 encoding adds around 10% to the image size after gzip compression and this additional cost should be weighed against the benefits of less requests.
3.4.8.2
3.4.7.2
How
to
do
it
Background
images
can
be
encoded
using
the
data
URI
scheme:
url('data:image/png;base64,
[data])
[ ICON: CSS ] Requires: RCF2397 data uri support.
3.4.9.1.
3.4.8.1.
What
it
means
Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by identifying them with a URI that includes a fingerprint of the resource content. Using this technique means that the browser does not need to check the resource headers in order to validate its cache, instead, any change in the resource will lead naturally to a corresponding change in the resource reference.
3.4.9.2
3.4.8.2
How
to
do
it
Expires
header
to
a
date
in
the
far
future.
3.4.10.1
3.4.9.1
What
it
means
Data designed to be accessed by AJAX requests from the client should be cached in the same way as primary content.
3.4.10.2
3.4.9.2
How
to
do
it
The
standard
caching
techniques
(
Expires
header
and
Cache-Control
header),
as
well
as
resource
fingerprinting
can
be
used
on
AJAX
data
as
readily
as
primary
content
pages.
3.4.14.1
3.4.10.1
What
it
means
Static resources don't need cookie information and so performance can be improved by serving these from a path or sub-domain for which the application's cookies are out of scope.
3.4.14.2
3.4.10.2
How
to
do
it
Use a different domain, sub-domain, or path name for static resources to the main application, and restrict the valid path of cookies such that they will not be exchanged when they are not needed.
For example:
Set-Cookie: somePreferenceInformation=purple; path=/myapp/
Application data served from /myapp will receive cookie information.
Static data served from /static will not receive unneeded cookie information.
Given the additional complexities of interacting with an application on a mobile device, special consideration should be given to the overall user experience. User experience is influenced by a number of factors, including: perceived latency, interaction method, and data consistency.
3.5.1.1 What it means
Interaction methods vary across devices. Three main interaction methods should be considered when designing the UI:
The optimum configuration of UI elements varies depending on the interaction method used by the device. Ideally, the UI should be adapted based on a knowledge of the interaction methods supported by the target device. If this is not possible, then the UI should be carefully designed in order to provide a good experience in each of these different interaction methods.
3.5.1.2 How to do it
Particularly where navigation of content requires multiple links (ie back/forward in a carousel) the following factors should be considered:
Focus Based:
Pointer Based:
Touch Based:
Using
script
for
dynamic
parts
The
Best
Practices
covered
in
section
3.4
Conservative
use
of
resources
will
help
to
minimize
the
page
means
that
the
view
can
be
updated
without
actual
latency
of
a
full
page
reload.
Since
reloading
the
entire
page
Web
application,
but
a
number
of
measures
can
also
be
slow
this
can
greatly
improve
application
usability.
used
to
further
minimize
the
perceived
latency.
Lowering
perceived
latency
is
an
important
factor
in
improving
the
overall
usability
of
a
Web
application,
improving
user's
perception
of
Web
site
credibility
and
decreasing
bail-out
rates
[REFS]
.
Use
asynchronous
(XHR)
requests
A
number
of
techniques
can
be
used
to
get
additional
information
from
improve
perceived
and
actual
latency:
The
JavaScript
focus
method
can
be
used
to
move
the
focus
to
the
part
of
a
page
that
has
changed.
However,
if
unexpected,
this
can
confuse
or
irritate
the
user,
especially
if
returning
to
the
previous
focus
is
not
easy.
Use
the
JavaScript
focus
method
only
if
it
is
essential
to
the
use
of
the
application,
and
does
not
inhibit
user
control/interaction.
3.5.5.1
3.5.4.1
What
it
means
Web applications can switch between views without a full page reload by showing and hiding sections of content. However, this means that the browser <back> button doesn't work by default, and it is not automatically possible to link directly to specific views within an application. Usability is enhanced by enabling both of these features:
3.5.5.2
3.5.4.2
How
to
do
it
Each
view
within
an
application
should
have
a
URI
with
a
distinguishing
fragment
identifier
(e.g.
http://myapp.example.org/myapp#view
)
and
JavaScript
used
to
interrogate
the
browser
location
in
order
to
determine
which
view
to
display.
For further discussion on this topic see: http://ajaxpatterns.org/Unique_URLs
Standardized URI schemes have been defined for some common device functions, e.g. making phone calls and managing address books. These URI schemes, if supported, can enable users to easily use these functions from Web applications.
The most broadly supported scheme is tel: as described in [ RFC3966 ]. Code such as the following can be used to enable "Click-to-Call":
<a
href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>
3.5.7.1
3.5.6.1
What
it
means
On small screens it is important that paragraph text flows so that it doesn't require horizontal scrolling and so that it will reflow if the view orientation is changed. See BP1 [MEASURES] for more details.
3.5.7.2
3.5.6.2
How
to
do
it
Use percentage and measures for containers so that text can reflow automatically.
3.5.10.1
3.5.7.1
What
it
means
This
recommendation
builds
on
the
recommendation
in
BP1
(
5.5.1
Thematic
Consistency
)
and
expands
it
to
consider
the
application
preferences
and
,
personalization
data
,
and
state
that
form
part
of
the
overall
experience
on
a
mobile
Web
application.
User credentials valid on one device should be valid on other devices. User preferences captured on one device should be accessible on other devices. Data updated on one devices should be viewable consistently on other devices.
The most valuable example of this would be in offering a consistent experience where information entered during a desktop session is accessible in a mobile session and vice-versa.
3.5.10.2
3.5.7.2
How
to
do
it
For
application
data
to
be
shared
between
devices
it
must
be
stored
on
a
server
and
cannot
be
stored
locally
on
a
device
(e.g.
using
cookies
or
a
local
data
store).
For
any
application
data
that
is
not
exclusively
relevant
to
the
current
device,
favor
storing
it
on
the
server
so
it
can
be
shared
by
other
devices.
See
3.1
Application
Data
for
more
details.
Network-initiated content delivery ("push") methods allow notifications and updates to be pushed to user even when they are outside of the application context.
Push method support may be disclosed through a User Agent Profile document if published by the device vendor, or through other device classification repositories.
If supported by the user agent, options for Push methods include:
TODO: Pending Jeff's research :)
Certain classes of browser attempt to display desktop pages on a small screen by automatically zooming the display. This can be problematic for applications that have already been optimized for a small screen. The viewport meta tag tells the device at what scale to render the page.
A typical viewport setting looks like this:
<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0" /> ,
and should be inserted into the <head> of the HTML document. This setting informs the browser to always render the page at 100% (e.g. no browser based scaling) and explicitly disallows scaling of the page. Explicitly disallowing scaling is required to prevent the page being scaled when an input box is clicked on.
The setting above is appropriate for pages specifically designed for the target screen-size.
Device capability variation is a basic characteristic of the mobile Web environment. Web applications should adapt their content such that they render as well as possible on as broad a range of target devices as possible.
For static device capabilities that won't change (e.g. SVG support, screen-dimensions) it is preferable to detect these capabilities on the server and adapt content before it is sent to the client in order to avoid transferring unnecessary data.
Typically used methods of device capabilities detection:
For dynamic device state that might depend on the configuration or context of the device (e.g. Is scripting enabled? Is the SDCard available? Has permission been granted for PIM access?) detection must be done on the device.
Use JavaScript reflection to determine if a given API is active and interrogate the device configuration using appropriate APIs. Two methods can then be used to adapt on the client to differing configurations:
if
(some_configuration_variable)
decision-points
in
the
code
and
behave
accordingly;
Option (1) is simpler to implement and is appropriate provided the amount of inactive code downloaded doesn't have a negative impact on performance. Option (2) is preferred when the application must change significantly in response to properties that can only be determined on the client.
If a large number of devices are being targeted, or if the application is sensitive to the permutations of a large number of configuration properties, the number of application variants required might quickly become unmanageable.
To combat this, classify target devices into different device classes and build a single application variant for each.
This will keep the amount of device-specific code to a minimum without unduly encouraging a "lowest common denominator" solution.
Identify the target devices for the application and assign these to device classes of varying capability. Focus on application variants that work in each class rather than building device-specific exceptions for every variation in device configuration.
Device
classes
should
be
defined
on
an
application-specific
basis,
so
that
the
variants
can
be
tailored
accordingly.
For
example,
the
following
is
a
typical
possible
configuration
of
application
classes:
Class
1:
Basic
XHTML
support,
no
or
very
basic
scripting.
No
AJAX
XHR
support.
(Even
if
these
kind
of
devices
are
not
being
explicitly
supported,
it
is
often
advisable
to
support
a
non-XHR
version
in
case
JavaScript
has
been
disabled
on
the
device).
Class 2: Full AJAX and JavaScript support.
Class 3: Advanced device APIs, for example: access to location API, device PIM data, or application cache.
Scripted
and
XHR
based
applications
are
not
yet
well
supported
on
many
all
browsers.
If
possible,
provide
broadest
reach
is
a
primary
concern
then
consider
providing
a
variant
of
the
application
that
does
not
rely
on
script
by
using
uses
synchronous
FORM
posts
instead.
in
place
of
XHR
requests.
This
Best
Pratice
is
related
(albeit
with
a
differing
focus)
to
BP
1
[
OBJECTS_OR_SCRIPT]
.
Essentially
this
BP
states
that
it
is
favourable
to
support
"Class
1"
devices
as
defined
above
if
at
all
possible.
appropriate.
Doing
this
will
ensure
that
the
application
can
be
used
across
as
broad
a
range
of
devices
as
possible.
Furthermore,
in
some
cases
a
non-JavaScript
version
can
sometimes
be
useful
for
simple
operations
in
low-bandwidth
situations.
In
some
cases,
however,
the
type
of
a
particular
application
simply
has
no
non-JavaScript
counterpart
(e.g.
a
Web
based
game,
an
Instant
Messaging
client)
in
which
case
it
should
return
a
406
Not
Acceptable
response.
Do this by detecting the device User-Agent and checking its JavaScript support against a DDR or local index.
Not only is device characteristic detection imperfect, it cannot always account for the differing use-cases of an application. If multiple flavours of the application exist (e.g. to support the various device classifications) it sometimes makes sense to offer the user the choice of which flavour they wish to use.
Only if it makes sense in the specific context of a given application, allow the user to switch to a different flavour (for example, upgrading their experience if their device is more capable than the server believes, or degrading if connectivity is poor and they wish to accomplish a very simple task that can be done more easily with the minimal UI).
Always attempt to default to the most appropriate UI on first use.
Always remember the user's preference for future visits in a cookie or local data store.
The following device properties included in the DDR Core Vocabulary [REF] are of particular value in supporting best practices recommended in this document. They should be available in any DDR supporting the W3C's DDR Core Vocabulary:
TODO: Include more detailed examples on the following BPs... Use Fragment IDs
The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:
While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.
Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.
The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.
The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.
Section 3.6.3 Use Device Classification to Simplify Content Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity .
to be added
to be added