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 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) . 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).
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] 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 XHTML, JavaScript, and CSS
compliance. Additionally, some 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 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.
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 that 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 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, client-side storage APIs can be used to store data
locally on the device. For a more detailed technical summary see Offline Web
Applications.
Client-side storage provides a powerful mechanism for Web applications to
maintain a local data model. This provides two main advantages:
- A local cache of the application's data can be displayed immediately
when the application is started (without the need for a server roundtrip)
allowing start-up latency to be reduced.
- 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.
There are two APIs available in HTML5 that facilitate storage on the
device.
- Local Storage API
- This API provides simple 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
appropriate for storing relatively simple, unstructured data.
- SQL API
- The SQL Database API provides the ability to store and retrieve data
in a local database . This is appropriate for more extensive and
structured content.
[ HTML5 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.
Local data storage is a powerful provision that allows Web applications to
maintain a local data model. However, changes to the local data model are
only visible on the device that made them and should be replicated to the
server in order to provide a consistent view across devices.
See 3.5.10 Ensure Consistency
Between Desktop and Mobile for more details.
HTML5 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 of data back to the server.
[ HTML5 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.
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 how that data will be
exchanged with the server.
In many cases use of APIs that provide access to personal or device
information causes a 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.
[ PIM DATA icon ] Requires: PIM Data APIs.
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 whitespace strippers and JavaScript
compilers are available.
The working group is seeking recommendations for the
best / most-commonly used tools to reference in this section.
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.
3.4.7.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 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 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 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. 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 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 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 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.
A Web application may not be suspended if it is placed in background.
Consider the impact of on-going JavaScript operations on battery life.
- 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
.
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. ]
On small devices with limited processing capability, the cost of excessive
DOM manipulation can impact application performance .
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.
[ 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.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.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 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
elements will be highlighted.
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 of the page means that the view can be
updated without a full page reload. Since reloading the entire page can be
slow this can greatly improve application usability.
Use asynchronous (XHR) requests to get additional information from the
server in response to user events and update the page DOM to convey this to
the user.
AC: My feeling is that this BP is assumed by much of
the other BPs, is too obvious, and doesn't provide value. Cut of change to:
Avoid Page Reloads
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
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.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 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.
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 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 How to do it
Use percentage and measures for containers so that text can reflow
automatically.
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.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 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.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 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. 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 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:
- 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 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 configuration of application classes:
Class 1: Basic XHTML support, no or very basic scripting.
No AJAX support.
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
browsers. If possible, provide a variant of the application that does not
rely on script by using synchronous FORM posts instead. 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. 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 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 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