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.
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 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
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
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 standard XHTML, JavaScript, and CSS
capability. Additionally, some Best Practices are relevant only if the device
exposes certain capabilities (for example, access to device information such as
location).
Implied by this discussion is that some level of device knowledge and
content adaptation is required. For 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.
Cookies are a common and effective means to store small amounts of state on
the client. They are appropriate for simple personalization data and are
commonly used to store a token representing user identity in order to enable
automatic sign-in.
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, applications
should endeavour to remain functional even if cookies are unavailable. See BP1 [COOKIES] Do
not rely on cookies being available for appropriate cookie related
caveats.
If supported by the device, client-side storage APIs provide a mechanism to
store more 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.
Making use of client-side storage in Web applications is a powerful
technique that brings Web applications into parity with native applications in
terms of start-up time and responsiveness. Two key advantages are worth noting
explicitly:
- 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.
Each technology offers a variety of storage facilities that range from simple
"key = value" models appropriate for relatively simple, unstructured data, to
full SQL Database 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.
[ Client-Side Storage Icon ] Requires: Local Storage
API.
If a client-side storage API is being used, it's important to remember that
this data is not visible to other devices. Whilst this is adequate for some
forms of data (e.g. preferences and state relevant only to a given device), it
is often necessary to replicate this data back to a server in order to provide
a consistent view across devices and make it possible to recover data if the
device is lost or damaged. See 3.5.10
Ensure Consistency Of State Between Devices for 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 flow of data
back to the server and to build up a local queue of changes if the application
is offline.
[ Client-Side Storage Icon ] Requires: Local Storage
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.
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.
[ DEVICE DATA icon ] Requires: Device Data APIs.
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 freely available whitespace strippers and
JavaScript / CSS optimizers are available online.
Note that "minification" / "optimization" can take a number of forms from
simple removal of whitespace and comments, to the 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 / grammatical understanding of that source are less fragile
and should be preferred to 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.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.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.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.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.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.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.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.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.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.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;
- Selectable elements need to be 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).
The Best Practices covered in section 3.4
Conservative use of resources will help to minimize the actual latency of a
Web application, but a number of measures can also be 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 .
A number of techniques can be used to improve perceived and actual
latency:
-
Enable Incremental Rendering: Place JavaScript tags at
the bottom of the page (since many browsers halt whilst parsing JavaScript)
and configure the page such that any useful information that might be
available is viewable while the 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 they don't think the application is
"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 showing and hiding the
relevant parts of the DOM.
-
Partition Large Scripts: In complex Web applications,
JavaScript parsing can contribute a significant portion of start-up time.
If some functionality is rarely used it should be partitioned into separate
scripts that can be loaded on demand, lowering the amount of 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.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.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.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.6.2 How to do it
Use percentage and measures for containers so that text can reflow
automatically.
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, 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.7.2 How to do it
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
possible configuration of application classes:
Class 1: Basic XHTML support, no or very basic scripting.
No 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 supported on all browsers. If
broadest reach is a primary concern then consider providing a variant of the
application that uses synchronous FORM posts 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 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, 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:
- 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 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
-
DIP
- Device Independence Principles, R. Gimson, Editor, W3C Working Group
Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/)
-
DCODI
- Delivery Context Overview for Device Independence, , R. Gimson, R.
Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See http://www.w3.org/TR/di-dco/)
-
DIGLOSS
- Glossary of Terms for Device Independence, R. Lewis, Editor, W3C
Working Draft (work in progress), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/)
-
XML
- Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim Bray, Jean
Paoli, C. M. Sperberg-McQueen, Eve Maler, Fran