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:
- best/most-commonly used tools to minimize the size of a Web
application, see Minimize application size .
- the relative impacts of Web application activities on battery
life, see Use
Power-Efficient Methods .
- the use of techniques aimed at separating out JavaScript and
CSS that are rarely
used, and in particular
the use of iframe on devices, see Separate Rarely Used
Functionality used.
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 .
The following Best Practices are discussed in this document and
listed here for convenience.
@@TODO
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).
1.3.4 Delivery Context
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] .
1.5 Terminology
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.
- The Heading
- A summary of the functional area to be addressed by these
statements
- What it means
- An explanation of the intention of the Best Practice
statement.
- How to do it
- A discussion of the techniques and device capabilities required
to implement this Best Practice.
- Requires
- A summary of device capabilities required in order for this
Best Practice to apply.
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:
A local cache of the application's
Application data stored locally can be displayed immediately when
the application is started (without the need for a server
roundtrip) allowing start-up latency to be reduced.- By making updates locally at first and
replicating changes back to the server in the background when
connectivity is available Web applications can continue to
operate responsively even when the network signal is
unreliable, since changes to the data model do not need
to be immediately communicated to the server. unreliable.
There are two APIs available in HTML5 that
facilitate Each technology offers a
variety of storage
on the device. Local
Storage API This API provides facilities that range from simple
key "key =
value persistent storage that fulfills many of the same
needs as cookies but without the overhead of this information being
transferred to the server on each request. It is value" models appropriate for
storing relatively simple, unstructured
data. SQL API The data, to full SQL Database
API provides the ability to store and retrieve data in a
local database . This is APIs
appropriate for more extensive and structured content.
For a good technical discussion of these facilities in
the context of HTML5 see Offline Web Applications .
[ 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:
- Pictures, music, and video clips;
- Contacts, calendar (PIM data);
- Call history;
- System data (battery, coverage, roaming, location);
- Media recording (record audio/video clip, get new
picture);
- Device context (e.g. location, connectivity, profile
setting).
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:
- how often the application will interact with the Internet -
e.g. every 5 minutes, hourly, daily;
- how long the automatic behavior will continue;
- how heavy the overall usage is expected to be or the type of
service plan recommended.
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:
- Most images (especially JPEGs) does not benefit from
compression;
- For very small files (e.g. <1k) the negative impact of
processing will outweigh any small transport gains.
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:
- Batching requests:
- A single request for more data is considerably more efficient
than several smaller requests. Wherever possible, batch up multiple
requests at the application level.
- Back off during periods of inactivity:
- If the application polls for updates, it should monitor user
activity and poll less frequently during inactive periods.
- Device Context:
- If supported by the device, use awareness of current
connectivity (e.g. WiFi) to select an appropriate level of
interaction.
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.6 Consider Including Small Style Sheets
and Script Resources In-Line 3.4.6.1 What it means In some
circumstances performance is improved if JavaScript and CSS style
sheet resources are included in the HTML page, eliminating the need
for additional HTTP requests to fetch the external files. 3.4.6.2
How to do it Whether in-line resources make sense or not depends on
a number of factors. For example: The cache hit rate (e.g. the
number of times users will successfully load resources from the
browser cache). The size of the JavaScript and CSS files. The
frequency with which the JavaScript and CSS files change. TODO: For
F2F discussion: Do we want to recommend this? It's certainly a
powerful technique, but must be used judiciously and is not
required... For things that are advantageous in some circumstances
but not required to avoid pathological behaviour, are they really
best practices ?
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:
- For PNG and GIF files, combine images with similar sizes and
color palettes;
- Endeavour to sprite JPEGs on 8x8 boundaries in order to
minimize the size of the combined JPEG.
- Combine images that do not change often. If one of the
component images changes, the entire combination image will need to
be downloaded.
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
- Set the resource caching policy to "never expire" by setting
the
Expires header to a date in the far future.
- Reference the resource using a URI that contains a Hash of the
content. If the content changes, this reference will change and the
browser will fetch the updated data.
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.11 Use Power-Efficient Methods
3.4.11.1 What it means A Web application may not be suspended if it
is placed in background. Consider the impact of on-going JavaScript
operations on battery life. 3.4.11.2 How to do it Network activity
is the biggest drain on power. If the application requires ongoing
network activity (e.g. to poll a server for updates) take steps to
inform the user of this activity and minimize its impact on
battery-life. See 3.3.1 Inform the User About Automatic Network
Access ; DOM manipulation over an extended period impacts device
battery life What are we saying here? Don't manipulate the DOM in
background? Don't update DOM if the application is in background? .
The working group is currently investigating the relative impacts
of Web application activities on battery life in order to make more
concrete recommendations. [ AC: I propose we cut this BP unless we
can say something more concrete or empirically supported. I don't
believe this BP is useful in its current form. ] 3.4.12 Minimize
DOM Manipulation 3.4.12.1 What it means On small devices with
limited processing capability, the cost of excessive DOM
manipulation can impact application performance perhaps we can be
either more specific (what does excessive DOM manipulation mean?)
or considerably more terse here (e.g. DOM manipulation is costly) .
3.4.12.2 How to do it Only use DOM manipulation for dynamic parts
of the page. The static framework of the page is best created using
HTML markup which can then be connected to the script using the
element ID attribute. I'm not sure I quite get the point. Static
parts of the page don't get manipulated and hence are not costly.
Dynamic parts do get manipulated and hence have a cost. So what are
we encouraging people to do, and what are we encouraging them not
to do. [ AC: I agree this BP is currently too vague to be useful
and would prefer to cut it or come up with something more concrete
to say ] 3.4.13 Reduce Cookie Size 3.4.13.1 What it means
Information stored in cookies is sent to the server for every
request and can negatively impact performance. 3.4.13.2 How to do
it Use cookies sparingly, and consider alternative methods (see 3.1
Application Data ). 3.4.14 3.4.10 Don't Send Cookie Information
Unnecessarily
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:
- Focus Based: The browser focus "jumps" from link to link;
- Pointer Based: Key-based navigation controls a pointer that can
cover any part of the screen;
- Touch Based: Events are related directly to a touch position on
the screen with finger or stylus.
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:
- Selectable elements (e.g. links) can be widely spaced since the
focus area will jump automatically from link to link;
- The current focus of the page is easily determined because that
element will be highlighted.
Pointer Based:
- Selectable elements that are associated need to be near each
other as scrolling the pointer can be slow;
The current focus of the page is easily
determined because that Selectable elements will need to be
highlighted. large enough to be easily selected -- since the pointer
often moves in steps of approximately 5 - 10 pixels;- Selectable elements should have rollovers
to make it clear when the pointer has entered their active
area.
Touch Based:
- Selectable elements can be widely spaced as the user can select
them directly;
- Selectable elements must be large enough to be easily selected
(e.g. list items should have a height of at least 30px).
- No elements are in focus until they are selected so extra
information cannot be passed to the user (e.g. rollovers will not
work).
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 .
Use asynchronous (XHR) requests
A number of techniques can be used to
get additional information from
improve perceived and actual
latency:
- Enable Incremental
Rendering :Place JavaScript
tags at the
server in response to user
events bottom of the page (since many
browsers halt whilst parsing JavaScript) and update configure the
page DOM to convey this to such that any useful information that might be available
is viewable while the user. AC: My
feeling main content of the
application is still
loading.
- Keep the User Informed of
Activity: Spinners and
progress bars should be used to keep the user informed during
network and device API accesses so that
this BP they don't think the
application is assumed
"stuck".
- Avoid Page
Reloads: In dynamic Web
applications page reloads should be avoided and the page
dynamically updated to reflects changes in state. Different views
can be switched by
much
showing and hiding the relevant parts
of the other BPs, DOM.
- Partition Large
Scripts: In complex Web
applications, JavaScript parsing can contribute a significant
portion of start-up time. If some functionality is
too obvious, and doesn't provide value.
Cut rarely used it should be
partitioned into separate scripts that can be loaded on demand,
lowering the amount of change to: Avoid
Page Reloads core code that needs to be
parsed at start-up.
- Use Client-Side
Storage: Where appropriate,
aggressively cache a snapshot of application state so it can be
displayed immediately on start-up. In many cases possibly stale
data is still more useful no data.
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.4 Group Closely Coupled Views 3.5.4.1
What it means Most applications consist of a number of views (e.g.
an email application consists of an inbox and the message detail
view). User experience is improved if switching between these views
does not require a request to the server. 3.5.4.2 How to do it Each
view can be rendered in a div element which is hidden using CSS.
JavaScript can be used to reveal content in response to user
events. AC: This feels like the wrong level of detail. Propose
merging with 3.5.2 into Avoid Page Reloads 3.5.5
3.5.4 Use Fragment IDs to Maintain
Application History
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:
- Enabling deep links (e.g. to the content of a specific email)
means the user can still bookmark this view and return to it
quickly;
- Enabling the browser history provides a natural method to
navigate application views that is natively supported by the
browser.
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.8 Separate Rarely Used Functionality
3.5.8.1 What it means Perceived performance can be improved by
separating out JavaScript functions and CSS styles that are not
required by the initial page. JavaScript functions and CSS styles
associated with rarely used features should be bundled separately
and downloaded only if those features are accessed. 3.5.8.2 How to
do it Consider what functionality is being downloaded in a given
script resource and how likely that functionality is to be used in
the majority of requests. If some functionality is rarely used, it
may make sense to partition this into a separate script to be
loaded on demand. On-demand loading can be accomplished by: Moving
that functionality onto an entirely separate page; Creating an
embedded frame to load the required additional resources in
response to a page event; Using <link rel="prefetch"> . The
working group is seeking feedback on this Best Practice. Whilst it
contains value for very large / complex applications, the
implementation of this technique and its support across even
high-end devices is not clear. Specifically, IFRAMEs are known to
have significant issues on many devices and so we are looking for
validation that their use in this context is a good idea. 3.5.9
Enable Progressive Rendering 3.5.9.1 What it means Progressive
rendering means that the page will be displayed incrementally as it
loads. In most cases this results in an improved perceived latency
since content is available earlier. 3.5.9.2 How to do it Place CSS
style sheet ( <style> ) elements in the <head> head
element at the top of the document according to HMTL style elements
cannot occur anywhere else :-) and what do we want to say about
link rel=stylesheet? and JavaScript ( <script> ) elements at
the bottom of the document. Browsers will not progressively render
a page until the stylesheet has been loaded and will block while
JavaScript content is parsed. 3.5.10
3.5.7 Ensure Consistency Of State Between Desktop and
Mobile Devices
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:
- OMA Push: a widely supported enabler providing methods for
user-confirmed and automatic content push, directed to mobile
browsers and other user-agents. See http://www.openmobilealliance.org/Technical/wapindex.aspx
for more details.
- SMS
- QR Codes
- Alternative vendor-specific initiatives.
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:
- The "User-Agent" header can be used to identify the device, and
a Device Description Repository (DDR) can be used to retrieve a
detailed description of capabilities;
- The "Accept" header can be used to indicate specific MIME types
compatible-to/preferred-by the device;
- The "X-Wap-Profile" header (User Agent Profile or UAProf) can
be used both as device identification and as a source of detailed
device capabilities.
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:
- Encapsulate the different behaviours in the control logic of
the application. E.g. simply use:
if
(some_configuration_variable) decision-points in the code
and behave accordingly;
- Use an initial "bootstrap" script to assess device capabilities
and request the appropriate application bundle 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.
TODO: Class 1 is not relevant to most of the
BPs in this document... The recommandation to support class 1
devices is ideologically sound, but not compatible with what we do
on a practical level. Discussion point @ F2F.
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.
TODO: Ideologically sound, but not compatible
with where the market is going / what we do in practice... Also,
somewhat incompatible with all the other recommendations in the
doc... Personally, I would ditch this BP, but I suspect that will
meet some opposition.
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:
- Display Width, Display Height, Display Color Depth
- Input Devices
- Markup Support
- Stylesheet Support
- Image Format Support
- Input Mode Support
- Cookie Support
- Script Support
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 S