Copyright © 2008 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This document specifies Best Practices for the development and
delivery of Web applications on mobile devices. The recommendations
expand and amplify upon general statements made in the Mobile Web Best Practices 1.0
(BP1), especially concerning statements 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-specific technologies.
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 a
First Second Public Working Draft and is not complete.
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:
iframe
on devices,
see Separate Rarely
Used Functionality 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 First 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 .
1 Introduction
1.1 Purpose of the
Document
1.2 How the Best
Practices are Organized 1.3 Audience
1.4 1.3 Scope
1.4.1
1.3.1
Best Practices
1.4.2
1.3.2
Web Application
1.4.3
1.3.3
Mobile Context
1.5 1.3.4
Delivery
Context
1.4 Relationship to other Best Practices and
recommendations
1.5 Terminology
2 Structure of Best Practice
Statements
3 Best Practice Statements
3.1 Personalization
3.1.1 Retain Personalization Information For Personalization
3.1.2 Use
Automated Means for Identifying Automatically Identify the User and Obtaining Personalization
Information
3.2 Security and
privacy
3.2.1 Protect Personal
Information Used in Transactions Use
HTTPS when Exchanging User Credentials
3.2.2
Secure JSON
Datafeeds
3.2.3
Use a Safe EVAL for JSON
Datafeeds
3.3 User
awareness and control
3.3.1 Inform the User About Automatic Network
Access and
3.3.2
Provide Sufficient Means
to Control Over its Use
Automatic Network Access
3.3.2
3.3.3
Inform Ensure the User
is Informed About Use of Personal
Information and Degrade Gracefully if Permission is Denied
Device Information
3.4 Conservative use
of resources
3.4.1 Use Transfer Compression for Content
3.4.2 Minimize Redirects
in Server-Server API's Application
Size
3.4.3 Avoid
Redirects
3.4.4
Minimize Automatically Issued
Network Requests
3.4.4
3.4.5
Use Push Methods to Reduce Pull
Traffic
3.4.5
Minimize Application Size
3.4.6 Minimize DOM
Manipulation External
Resources
3.4.7 Minimize External Consider Inlining Small Stylesheets and Script
Resources
3.4.8 Sprite Static Images into a Single
Resource
3.4.9
Inline Background Images in
CSS Stylesheet
3.4.10
Use Fingerprinting to Cache
Dynamic Resources
3.4.11
Make AJAX Datafeeds
Cachable
3.4.12
Use Power-Efficient Methods
3.5 One Web
3.4.13
Minimize DOM
Manipulation
3.5.1
Offer A Consistent View Across Multiple Devices 3.4.14
Reduce Cookie
Size
3.6 3.4.15
Don't Send Cookie
Information Unnecessarily
3.4.16
Use JSON in favour of XML
for Datafeeds
3.5 User Interface
Experience
3.6.1
Consider Different Device 3.5.1
Design for Multiple
Interaction Methods
3.6.2
3.5.2
Use Scripting for User Interface to
Improve Perceived Performance
3.6.3
3.5.3
Don't Move
the Preserve Focus on Dynamic Page Updates
3.6.4
3.5.4
Group Closely Coupled Views onto the Same Page
3.6.5
3.5.5
Use hash URLs to Preserve
Browser History and Enable Deep Links Fragment IDs for Application Views
3.6.6
3.5.6
Use URI
Schemes for Device Functions Make
Telephone Numbers Clickable
3.7 3.5.7
Ensure Paragraph Text
Flows
3.5.8
Separate Rarely Used
Functionality
3.5.9
Enable Progressive
Rendering
3.5.10
Ensure Consistency Between
Desktop and Mobile
3.6 Handling Device Capability Variation
3.7.1
3.6.1
Use Device Server-side
Capability Detection
3.7.2
3.6.2
Use Reliable
Methods Client-side Capability
Detection for Determining Script
Support Dynamic Device
State
3.7.3
3.6.3
Use Device Classification to Simplify
Content Selection/Adaptation
Adaptation
3.7.4
3.6.4
Provide Alternatives to Client-Side Scripting
Support a non-JavaScript Variant if
Possible
3.7.5
Provide for Both Graceful Degradation & Progressive
Enhancement 3.6.5
Offer Users a Choice
of CSS Interfaces
3.7 SVG
3.7.1
Use SVG Tiny 1.1
Compatible Content
3.7.2
Minimize Size and
Complexity of Content
3.7.3
Test on Target
Devices
3.7.4
Make Use of Language
Features to Write Compact Code
A Sources
(Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
D.1 MWI
References
D.2 Sources
D.3 Device
Independence
D.4 Web, Protocols and
Languages
D.5 Other
References
The following Best Practices are discussed in this document and listed here for convenience.
This section will be completed when the
list of Best Practices is more stable.
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, such as Web
servers, HTTP, and Web 2.0. Readers but are not expected to have a background in
mobile-specific technologies.
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, and tool developers, are encouraged to read it. Some Best Practices, however, clearly have a more technical focus. These are likely to be of interest only to developers interesting in building highly optimized / advanced mobile Web applications and can be safely ignored by other disciplines.
These recommendations expand and
amplify on the recommendations of the Mobile Web Best
Practices (BP1). Where BP1 focussed primarily on 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 modern device
capabilities to enable a better user-experience; 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 is 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 we
believe they will soon become
fully qualified Best Practices (e.g. in prevalent use within the
development community) in the very near
future. community).
For the purposes of this document, the term "Web application"
refers to a web Web page (XHTML or a variant thereof + CSS) or
collection of Web pages delivered over HTTP which use either
server-side or client-side processing (e.g. javascript) 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.
Whilst the focus of this document is on producing Best Practices that apply to applications running in a Web browser, in many cases these recommendations are equally applicable to other kinds of Web runtime, 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 focussing solely
on best-practices 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, poor
connectivity), and also the additional scope and features that must
be considered when developing for the mobile context (e.g. device
context / location, presence of personal data on the device,
etc).
Requirements on delivery context have not been made explicitly, but most best practices assume devices with basic 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).
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 BP1. Mobile
Web Best Practices 1.0 (BP1).
This document builds on some of the concepts described by the
Ubiquitous Web applications Applications (UWA) working group in and the Device
Independence Principles [DIP] . The
document discusses device and delivery channel characteristics,
which the DIWG has named "Delivery Context" [DCODI] . In addition, the document uses some
terminology from UWA's Glossary of Terms for Device Independence
[DIGLOSS] .
Note that the term "JavaScript" is used in place of the (arguably more correct) term "ECMAScript" in order to provide consistency with the companion Web application technologies (JSON and AJAX) which are in common use and both implicitly refer to JavaScript in their names.
Also, the term "AJAX" is used as it is in practice to refer to any asynchronous browser request. The implicit reference to XML suggested by the name is commonly accepted to be an historical anomaly.
Personalization This section elaborates on the recommendations of
BP1 Section 5.5 which details ways to minimize the amount of user input
required.
Given the limitations of a mobile device,
the interface should as far as possible minimize user input. To
this end, personalization can improve the user experience by
minimizing the amount of effort required to find relevant
information. This is especially important in
the mobile environment where extra effort is necessary to interact
with applications.
If a service relies on user entered personalization information (e.g. application
preferences, personal details) that
information should be retained in order to avoid the
need user should
not have to re-enter it
that information during the next time a user visits normal course of the site. application. This is
important both within a usage session and across usage
sessions.
Cookies are the most natural means to
store small amounts A number of
personalization technologies can be used to persist user entered
information. More extensive personalization
should Usually a combination of
technologies will be stored
required, the choice of which is application
and context specific:
Ensure that personalization information is available to the user
with minimal effort. effort by using their identity to automatically restore
application preferences.
The A Service
Provider (e.g. Mobile Network Operators or Web Portal Providers) or
an Identity Management Provider may provide means to access trusted
user identities automatically. This has the advantage of removing
the need for the user to enter their identity at all and will
provide an optimal experience.
Alternatively, the simplest way to
do this identify
the user is to associate
personalization information with a given user identity and obtain
their prompt for login
credentials directly on first
access. access
and store a Hashed identity token in a cookie for future
accesses. Recommended methods for doing this include:
Use trusted information, and protect all personally identifiable information.
Although HTTPS is the most common means to secure personally identifiable information, the overhead of using it can be significant over a mobile network. As such, HTTPS should not be used unnecessarily, and the level of security should be matched to the level of sensitivity of the information being exchanged.
Personally identifiable information (e.g. user identity or
information usable as a key to user identity) should only be
accepted or sent securely. Less sensitive information that cannot
be associated with an individual (e.g. a zip code by itself is not
personally identifiable) can be exchanged in
the clear does not need to use
HTTPS provided the correlating information is secure.
HTTPS is the most secure way to exchange sensitive information such as user-identity. To avoid the overhead of using HTTPS for all transactions, a related pseudo-identity or secure hash of the actual identity can be exchanged in non-secure transactions.
HTTPS should always be used to exchange the initial user credentials, but subsequent requests need not use HTTPS provided the user identity is exchanged in the form of a Hashed Identity Token.
The Working
Group working group is
interested in receiving looking for feedback on the
validity of this Best Practice. Whilst it is a true reflection
of techniques for securing personal
data on mobile devices, commonly in
use, it risks exposing the Hashed credentials in the network
proxies and might pose an unacceptable
security risk.
3.2.2.1 What it means
A common paradigm in Web applications is
to provide a datafeed to an JavaScript based Web client in
the relative impacts form of an executable JavaScript string (e.g. JSON).
This has many advantages in terms of speed of execution and
ease of development, but it represents
a significant security flaw which can expose user-data to malicious
Web sites.
If a JSON datafeed is executable, a
malicious Web site can reference it in a <script> element. This will execute the datafeed using
HTTPS the cookies
associated with the data providing site and other techniques. in most
cases generate a JavaScript object model in the client which can be
accessed by the malicious site.
3.2.2.2 How to do it
The JavaScript datafeed should be protected by a prefix that will prevent execution directly, but which can be stripped off prior to execution when accessed by an XHR request.
{ username: "My Name", contacts: [ {name: "Contact1", phonenumber: "xx-xxx-xxxx"}, {name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }
while(1); { username: "My Name", contacts: [ {name: "Contact1", phonenumber: "xx-xxx-xxxx"}, {name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }
3.2.3.1 What it means
If a JSON datafeed is being parsed using the eval(); method it is vulnerable to script attacks. For example, if the feed contains user entered data this data might replicate the JSON syntax in order to compromise the application.
3.2.3.2 How to do it
There are a number of steps which can be used to protect against this kind of attack, use the one most appropriate to the context:
The working group is looking for feedback on an example "Safe EVAL" algorithm that can be shared here, or a publicly available library that can be referenced.
Ensure that the user is aware of application behaviors that
might affect the overall service
experience, application
behaviour, and that the user is offered options to control
those behaviors.
Many browsers support the ability to make background server
requests without requiring a page
refresh. server roundtrip. This
makes it possible to make server requests that are not
automatically reflected in the user-interface and which might
surprise the user or lead to unexpected data charges.
Device APIs are being developed in a
variety A number of standards activities standard and vendor-specific
initiatives proprietary APIs
exist to give browsers access to both personal and device information, for
example:
The use Use of such personal information and device
functions can expose the user to privacy and security concerns.
The overall goal is that the user is informed of such
activities, given effective means to control them, and also the
opportunity to opt-out of application/function their use.
Whenever an application makes background data requests, whether
automatic or user initiated,
user-initiated, this should be
indicated to the user in an appropriate manner so the user is not surprised by unexpected
data-charges, etc. Means should be provided to disable any
automatic network activity. manner.
Applications should disclose, in a clear and useful way, the
basic nature of their use of the network. A simple icon indicating
background activity is usually sufficient and will not interrupt
the main application flow. If extensive background network activity
is required this the user should be called
out informed when the user they first
visits visit the site, when they first log-in, or in associated help pages.
The kinds of detailed information that could be disclosed in associated help pages or terms of service are:
3.3.2.1 What it means
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 should be provided provided.
3.3.2.2 How to easily disable / re-enable this do it
At a minimum, provide the ability to
switch off the automatic network activity. Endeavor to keep
the application as functional as possible even if automatic network activity is disabled. disabled by
prompting the user before making network requests.
If appropriate, it might be desirable to enable the user to adjust the level of network activity. For example, by adjusting the polling-schedule, or controlling which activities are allowed to initiate network requests.
Ensure that the user is informed when if the
application accesses 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. Applications should be
defensive and remain as functional as possible if the API request
for personal or device information is
denied.
In many cases APIs that provide access to personal or device information deliver a native confirmation dialogue to the user before providing access to the data. 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 might
will lead to the user being presented
with repeated confirmation dialogues by the underlying API.
Resources Resources, such as device memory, processor power,
and network bandwidth are significantly more limited on mobile
devices than on a desktop device. As a
result, Web the desktop. The most
effective way to ensure that applications should use device run
smoothly and network resources
conservatively. with low latency is to
take steps to ensure minimal use of resources.
Compress content for efficiency in
efficient delivery.
HTTP 1.1 compression, which typically uses gzip or deflate as
algorithms, is a widely (though not universally) supported method
of transfer encoding for delivery
optimization. To use HTTP compression, compression. In general, Web servers should be
configured to serve Web pages using HTTP 1.1 compression (gzip or deflate), compression, according to the coding supported by
the device as indicated by the HTTP Accept-Encoding header.
Note however, that the processing processor
cost of decompressing data should be balanced against the gains in
transport efficiency. As a rule of thumb the following should be
considered when configuring HTTP 1.1 compression:
The Working Group is researching the
conditions under which compression should 3.4.1.3 Maximizing Compression Efficiency
Gzipping of HTML and CSS files can
be recommended made more efficient by ensuring consistency in the code.
For example:
This section elaborates on
mobile devices the Best Practices of BP1 ( MINIMIZE ). Smaller
applications will download and execute more quickly and more
reliably on constrained devices.
The working
group is looking seeking recommendations for feedback on the best /
most-commonly used tools to reference in this topic. section.
Request redirection (e.g. through
(through HTTP response header or meta refresh methods) refresh) is a typical method
for a service typically used to
automatically obtain exchange information from a
different server between servers
(e.g. account authentication). Such redirect
based API's are common in Web applications, and play an useful role
in automated personalization. However, Whilst invaluable, the cost of redirects is much
higher over limited bandwidth networks and so the number of
redirects should be kept to a minimum to avoid degrading the user
experience.
A typical redirect sequence should require no more than two automated redirects, e.g. one to redirect to the information-providing server, and another to redirect back to the service-providing server.
If further redirects are required, it's
possible to use a landing page to break
up the sequence. However, it's important to balance the desire to
add landing pages in order communicate to improve the
perceived latency of the application, against the cost of
needlessly interrupting the user flow
. that the application is still
working.
Applications that automatically issue network requests should
provide value "value" for those requests.
The "value" in this case should be determined by the application
developer based upon the type of service the application
provides, requests so as not to
unnecessarily impact battery-life and the resulting direct value application performance. Take care to the user. ensure network
requests are as well optimized as possible.
Consider the following issues
possibilities when designing
an application:
Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods.
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:
3.4.6.1 What it means
This section elaborates on the best practices
of BP1 [section ref].
Ensure that the A Web application size is
optimized in order to minimize the impact typically requires a number of operating resources
(stylesheets, scripts, image, etc) each of which may incur an
additional HTTP Request. HTTP roundtrips are particularly
expensive on a limited bandwidth
network. mobile network and so fewer,
larger requests should be favoured over a larger number of smaller
requests.
3.4.6.2 How to do it Various techniques can be used to minimize application
size:
As far as makes sense after taking into
account 3.5.8
Separate Rarely Used Functionality combine all stylesheets into a single resource and
CSS files at build time to remove whitespace.
Several Open Source whitespace strippers are available [REF] ?
Process script files at build time to remove whitespace
all scripts into a single resource. If
multiple scripts and compile
stylesheets are required as part of the
script. Several Open Source javascript
compilers authoring process, then try
to arrange that they are available, for
example: http://developer.yahoo.com/yui/compressor/
merged before the page is served.
3.4.7.1 What it means
On small devices with limited processing
capability, In some circumstances
performance is improved if the cost of
excessive DOM manipulation can significantly impact application
performance. JavaScript and CSS
stylesheet resources are inlined in the HTML page, since it
eliminates the need for two additional HTTP requests required to
fetch the external files.
3.4.7.2 How to do it
Only use DOM manipulation
Investigate for dynamic parts a given
application the optimum configuration. Whether inlined resources
make sense or not depends on a number of factors. For example:
3.4.8.1 What it means
This section elaborates on the best practices
of BP1 [section ref].
Web applications typically require
multiple resource (e.g. stylesheets, scripts, images). On
often depend on a mobile network, however, the overhead number of making
static images to provide icons, buttons, etc.
If served as a separate image each one incurs an additional
HTTP requests roundtrip which is high and
can significantly impact service latency. Steps detrimental to performance. To avoid this, all static
images should be taken to minimize the
number of requests made by the application. sprited together into a single image.
3.4.8.2 How to do it
The following steps can be taken to reduce
network requests: Using manual or
automatic means, combine all icons into a single image. To optimize
the efficiency of this:
To render individual icons from a sprited resource using css positioning and clipping.
3.4.9.1 What it means
Background images are often used
as gradients to improve presentation the look and
feel of an application. These can be inlined in the
css file CSS as base64 encoded
strings in order to avoid an additional HTTP
roundtrip.
3.4.9.2 How to do it
Background images can be embedded
using the url("data:...") construct.
data URI scheme: url('data:image/png;base64, [data])
3.4.10.1. What it means
Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by identifying them with a URL that includes a fingerprint of the resource content. Using this technique means that the browser doesn't 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.10.2 How to do it
3.4.11.1 What it means
Datafeeds designed to be accessed by AJAX requests from the client should be cached in the same way as the primary content.
3.4.11.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 datafeeds as readily as primary content pages.
As mobile A Web applications become
increasingly ubiquitous they are more likely to be required
application is not guaranteed to
run for long periods of time or be
on suspended if
it is placed in the background (e.g. an
email application or an IM client). and
may continue running for a long period. In these circumstances, this
case, the application's impact
of prolonged JavaScript operations on
battery life battery-life should be considered.
The working group is currently investigating the relative impacts of Web application activities on battery life in order to make more concrete recommendations.
Multiple On
small devices may be used to access a
Web application with limited processing
capability, the same user credentials
(e.g. a user may own multiple mobile devices or may access the
same cost of excessive DOM manipulation
can impact application from both mobile
and desktop devices). Application consistency should be maintained
across different consuming devices. performance.
Only use DOM manipulation for dynamic
parts of the page. The most common
cause static framework of
failing to offer a consistent application
state across multiple consumers the
page is best created using HTML markup
which can then be connected to store
too much information on the device
(either script using the element ID
attribute.
3.4.14.1 What it means
Information stored in cookies
or a local device database). To avoid this,
use device based storage carefully is
exchanged between the server and avoid
storing personalization data on the device that would still client for every request, which can negatively impact
performance.
3.4.14.2 How to do it
Use cookies sparingly, and consider alternative methods (see 3.1 Personalization ) for anything other than trivial amounts of data.
3.4.15.1 What it means
Static resources don't need cookie
information and so performance can be relevant if improved by
serving these from a path or subdomain for which the
application were accessed from
cookies are out of scope.
3.4.15.2 How to do it
Use a different consumer. See 3.3.1 Inform domain, subdomain, or path name for static resources
to the User About Automatic Network
Access main application, and
Provide Control Over its restrict the valid path of cookies such that they will
not be exchanged when they are not needed.
3.4.16.1 What it means
Asynchronous data can be delivered to the client in response to an XHR request in any form (HTML markup, proprietary format, XML, or JSON object model). Use JSON in favour of XML if possible.
3.4.16.2 How to do it
A JSON datafeed can be built from an
object model by hand, or an Open Source JSON builder (
The Working Group
REF ). On
the client, JSON is investigating
readily parsed into a number of additional recommendations for this
section javascript object model using
the eval method. Note,
however, that care should be taken to observe: 3.2.2 Secure JSON
Datafeeds and is looking
3.2.3 Use a Safe EVAL
for suggestions in this area.
JSON Datafeeds .
Given the difficulties and
additional complexities of interacting
with an application on a mobile device, special consideration
should be given to the overall user
interface in order to maintain
experience. User experience is influenced
by a good level number of usability.
factors, including: perceived latency,
interaction method, and data consistency.
3.6.1.1 3.5.1.1 What it means
Interaction methods vary across different devices. Three main interaction methods should be considered:
Devices may implement one or
focus. more of
these approaches and it is important for an application to remain
usable in all cases.
3.6.1.2 3.5.1.2 How to do it
Particularly where content requires multiple links (ie back/forward in carousel) or where the user's interaction with links is designed to give them feedback, the following factors should be considered:
Focus Based:
Pointer Based:
Touch Based:
Using script for dynamic parts of the page means that the view
can be updated without a full page reload. Since re-rendering reloading
the entire page can be slow on a device, this can
greatly improves improve application usability.
Script on the client can update specified
parts of the page, identified either by the ID tag, the css
classname, or Use asynchronous (XHR)
requests to get additional information from the document structure. The content of these tags can then
be updated, and new nodes server
in response to user events and update
the page DOM can
be created and destroyed. to convey
this to the user.
The ECMAScript 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. It can also make an application unusable, if the focus
changes prevent the user from using other parts of the
application.
Use the ECMAScript JavaScript focus method only if it is essential to
the use of the application, and does not inhibit user
control/interaction.
3.6.4.1 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 full page reload. server roundtrip.
3.6.4.2 3.5.4.2 How to do it
Each view can be rendered in a DIV element which is hidden using
css. Script Client-side script can be used to show and hide the relevant views and their
reveal content updated with in response to
user events without the need for a background server request. roundtrip.
3.6.5.1 3.5.5.1 What it means
Web applications can show multiple views by showing and hiding content. However, this means it is not automatically possible to link directly to these views and the browser <back> button cannot be used to move between previous views. Usability is enhanced by enabling both of these features:
3.6.5.2 3.5.5.2 How to do it
Script can Each view within an application should be
identified with a fragmentID (e.g.
http://myapp.example.org/myapp#view
) and JavaScript used to update interrogate the
browser URL and append a "hash" part
location in order to the URL. A hashed section of the URL is a standard
mechanism for defining different views within an application. For
example, an email application may support and respect URLs of this
form: determine which view to
display.
Standardized URI schemes (link
formats) have been defined for some common device functions,
e.g. making phone calls and managing phone address books. These URI
schemes, if supported, can enable users to easily use these
functions from Web applications.
The Wireless Telephony Application
Interface Specification (WTAI) most
broadly supported scheme is tel: as described in RFC-3966 .Use this as
follows to make phone numbers easily diallable from the Web
application:
<a href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>
3.5.7.1 What it means
On small screens it's important that
paragraph text flows to fill all the "wtai:" URI scheme available
space. Fixed paragraph widths (even when optimized for
accessing a variety of telephone functions.
WTAI the device screen) are error
prone, make it harder to support may be
disclosed through multiple device
formats, and will not support multiple orientations (e.g. landscape
and portrait mode).
3.5.7.2 How to do it
Specify widths for elements containing
paragraph text as a User Agent
Profile percentage ( style="width:100%" )
in favour of using an absolute size ( style="width:660px" ).
3.5.8.1 What it means
Perceived performance can be improved by
separating out JavaScript and CSS styles that are not
required by the device vendor.
initial page. JavaScript and CSS styles
associated with rarely used features should be bundled separately
and downloaded only if those features are accessed.
RFC3966 defines 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 "tel:" URI scheme 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:
The working group is
seeking feedback on this Best Practice. Whilst it contains
value for making phone calls.
"tel:" very large / complex
applications, the implementation of this technique and its support
across even high-end devices is widely
supported, since 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 stylesheet ( <style> )
elements in the <head> stanza at the top of the document and
JavaScript ( <script> )
elements at the bottom of the document. Browsers will not
progressively render a supported attribute 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 UAProf ,
support 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 determined from
the stored on a server and cannot be
stored locally on a device vendor. (e.g. using cookies
or a local datastore). For any application data that is not
exclusively relevant to the current device, favour storing it on
the server so it can be shared by other devices.
NOTE: This section is too detailed and
requires significant editing. The Working Group is still evaluating
the appropriate recommendations for this section and is interested
in receiving feedback. Device capability variation is a basic
characteristic of the mobile Web environment. Web applications
should adapt their content such that they render in an optimum way
on as broad a range of target devices as possible.
For some of the best practices included
here, support is dependent upon application awareness of
related static device capabilities. At the current time, this awareness
capabilities that won't change (e.g. SVG
support, screen-dimensions) it is limited preferrable to
application server use of device
detect these capabilities information provided by on the user-agent directly,
or obtained from a Device Description Repository (DDR) based upon
device identification, e.g. based upon server and adapt content before it is sent to the
user-agent header. client in order to avoid transferring unnecessary
data.
Typically used methods of device capabilities detection:
It can be tricky to determine
For dynamic device state that might depend
on the supported script
capabilities configuration or context
of the device (e.g. Is scripting enabled? Is the SDCard available?
Has permission been granted for a
PIM access?) detection must be done on
the device. Use of reliable methods is
recommended.
When it is unknown whether a user-agent
supports a given functionality, use Javascript Use JavaScript reflection to check for available functionalities. This avoids
determine if a given API is active and
interrogate the error-prone approach of
trying device configuration using
appropriate APIs. Two methods can then be used to parse adapt on the
user-agent string client to determine
Javascript support. An example differing configurations:
Use Javascript Reflection
Option (1) is simpler to implement and
if statements + if(window.ActiveXObject) { //
Instantiate using new ActiveXObject } else
if(window.XMLHttpRequest) { // Instantiate using new XMHttpRequest
} 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.
It can be complex If a large number of devices are being targetted, or the
application is sensitive to select and
adapt content based upon dynamic assessment the permutations of device
capabilities. A commonly used alternate approach involves off-line
assessment a large number of
configuration properties, the number of
application variants required might quickly become
unmanageable.
To combat this, classify target
devices with resulting assignment into
"classes", e.g. "good", "better", "best". The
definitions of the classes, different
"buckets" and build a single
application variant for each device assignment to classes, is typically Content Provider
specific, i.e. based upon assessments specific to bucket.
This will keep the needs amount of
the Content Provider. device-specific code to a minimum without unduly
encouraging a "lowest common denominator" solution.
Adapting Web application content and
services to mobile devices may be simplified by assigning devices
and user-agents (e.g. browsers or other Web applications as
identified by Identify the
HTTP user-agent header, or other information)
to "classes". The "richness" of target
devices for the Web application
as provided can then be more easily
matched and assign these to
the broad range "buckets" of capabilities
represented by the varying capability.
Focus on application variants that work in each bucket rather than
building device-specific exceptions for every variation in
device class. configuration.
Device classification is partly subjective
and partly objective. The aspects buckets should be defined on an application-specific
basis, so that affect the
classification will vary depending upon the focus of the Web
application, and the device/user-agent
features it depends upon. Some example classes for web browsers may
include: "Good": Serve these devices very basic pages. These
devices are typically WAP1 or WML-only handsets with black and
white screens. Ringtones are supported, but MIDP applications,
wallpapers, and scripted applications are not. "Good" devices also
include such color-screen WML phones on which pictures
variants can be presented through tailored
accordingly. For example, the browser,
and javascript applications can be emulated by web servers. Some
devices in this category may claim xHTML following is a typical configuration of application
buckets:
Bucket 1:
Basic XHTML support, but have slow processors, no or the supported xHTML is
incomplete. "Better": These devices have solid xHTML support with
color screens, and support MIDP, graphics, and ringtones. However
they do not support scripted applications. "Best": The "best"
device category includes features from the "better" category plus
streaming video capabilities, UMTS/HSDPA, and special audio
clients. Scripted applications may be supported, but script support
likely requires verification before use. very basic scripting. No AJAX support.
Once the device/user-agent is identified,
the assigned class can be obtained from the DDR used by the Content
Provider, Bucket
2: Full AJAX and
content then provided consistent with the
assigned class. JavaScript
support.
Bucket 3: Advanced device APIs, for example: access to location API, device PIM data, or application cache.
Scripted applications, e.g. using
asynchronous I/O methods or ECMAScript/Javascript in general,
may and XHR based applications
are not be yet well supported by
some on many browsers.
Pages designed to use scripting will require
alternate approaches in browsers that do not support scripting, so
you should be prepared for that and If
possible, provide similar functionality
in case scripting is a variant of the
application that does not available. rely on script by
using synchronous FORM posts instead.
Detect browser capabilities or user
preferences, and react accordingly with graceful degradation or
progressive enhancement of Javascript/ECMAScript. Design targeting
purely desktop/laptop audiences (where media="screen") tends to be
structured to degrade gracefully if ECMAScript/Javascript is not
present or if advanced capabilities like asynchronous I/O (and
other "AJAX" techniques) are not supported. Design targeting a
mixed audience of mobile (where media="handheld") and
desktop/laptop users should be structured to both degrade
gracefully (if ECMAScript/Javascript Essentially this BP states that it is not present) and likewise to progressively enhance page-
and user-behavior capabilities (if ECMAScript/Javascript does turn
out to be present). Separate behavior from content and
presentation, for graceful degradation and progressive enhancement.
Good logical design separates XHTML content (the "data model"), CSS
presentation (the "view"), and ECMAScript/Javascript behavior (the
"controller"). Designers targeting purely desktop/laptop audiences
(where media="screen") tend favourable to duplicate support "Bucket 1"
devices as defined above if at all possible. Doing this
in will ensure
that the physical site structure,
placing each in its own file and having pages issue an HTTP request
for each separately through use application can be used across as broad a range of
the <link/> or <script/> tags.
Designers targeting purely mobile (where media="handheld")
audiences tend to interleave the three concerns into one physical
payload/file delivered to the client devices as possible. Furthermore, in order to reduce per-request charges. Designers
targeting some cases a
mixed audience of mobile and desktop/laptop
users non-JavaScript version can
build Web pages which load sufficient
ECMAScript/Javascript (in the <head/> element) to determine
device display and interaction capabilities when first loaded. This
allows for progressive enhancement, just as good structural design
of XHTML allows for graceful degradation. Techniques similar to
progressive enhancement of CSS (see 5.9.5) may also
sometimes be used
to inject event-handling Javascript/ECMAScript code into files at
request-time and to attach Javascript/ECMAScript behaviors at
run-time useful for progressive enhancement. simple operations in low-bandwidth situations.
In some cases, however, the
example below, page-scope variables and
functions are declared in type of
application simply has no non-JavaScript counterpart (e.g. a
<script/> element in the <head/>
while run-time test code for progressive enhancement is
declared Web based game, an IM
client) in which case it should
return a <script/> element in the
<body/> element (to allow the DOM to be loaded before
406
Not Acceptable response.
Do this by detecting the code runs): [NOTE to WG: see
http://chw.rit.edu/test/progressiveEnhancement.html for complete
code as running example] device
User-Agent and checking its JavaScript support against a DDR or
local index.
3.6.5.1 What it means
CSS may be incompletely supported by some
browsers. Pages using positioning and visibility control are not
supported by some browsers.
Site design to support both desktop/laptop
users and mobile Not only is
device users will require alternate
approaches for browsers that do not support positioning and
visibility control. You should provide characteristics detection imperfect, it cannot always
account for both graceful degradation
(in the case of no or minimal CSS
support) and progressive enhancement (in the case differing use-cases of full
positioning and visibility control support) an application. If multiple flavours of
CSS by the client
at run-time. application exist (e.g. to
support the various device buckets) it might make sense to offer
the user the choice of which flavour they wish to use.
3.6.5.2 How to do it
Detect browser capabilities or
Only if it makes sense in the specific
context of a given application, allow the user preferences and react accordingly. Design targeting
purely desktop/laptop audiences (where media="screen") tends
to be structured switch to degrade
gracefully: first a different flavour
(for example, upgrading their experience if ECMAScript/Javascript their
device is not present, and then
more capable than the server believes, or
degrading if CSS connectivity is not
supported. Design targeting a mixed audience of mobile (where
media="handheld") poor and
desktop/laptop users should be
structured they wish to
also progressively enhance CSS. Advanced CSS
capabilities should accomplish a very
simple task that can be separated from
basic CSS, and inserted into done more
easily with the DOM by
minimal UI).
Always attempt to default to the
client as most appropriate at
run-time. Separate behavior from content and presentation, for
graceful degradation and progressive enhancement. UI on first use.
Always remember the <head> element) CSS user's preference for mobile
audiences and (using the <script/> tag future visits in the
<head> element) sufficient ECMAScript/Javascript to determine
device display and interaction capabilities first.
a cookie or local datastore.
Note: This
allows section is
still under review. The working group is keen to receive further
suggestions for progressive
enhancement, just as good structural design best practices specifically related to the use of
XHTML allows for graceful degradation. The
following example code illustrates a possible request-time payload
aimed at a mixed SVG on mobile
and desktop/laptop audience. In this case, if
ECMAScript/ Javascript is present and if Web sites.
This section covers some specfic Best
Practices related to the screen-width use of SVG in
mobile Web applications. SVG is determined to exceed a minimum, then vector
graphics format designed for use in the display device Web. It is
useful when there is assumed to
be a desktop/laptop (where per-download
charges are unlikely need to
apply), an additional stylesheet is
requested, and ithe new stylesheet convey large amounts of information.
SVG Tiny 1.1 is inserted into the DOM:
most broadly supported.
In Take steps
to ensure that the above case,
SVG content is not overly complex since
constrained devices will have difficulty rendering it. Ensure
that the base-CSS for mobile
users browser is delivered along with ECMAScript/Javascript
configured to determine client capabilities enable GZip compression as a
result of the initial request. Subsequent requests for CSS (and
possibly other resources) allow for progressive enhancement where
determined appropriate by client-side code. per 3.4.1 Use Transfer Compression .
Good physical design can take advantage of
just-in-time technologies like "server-side includes" to assemble
the above payload Even if SVG Tiny 1.1
is supported on demand, resulting in
the <style/> and <script/> nodes being inserted at
request-time. The following code in an HTML file would cause the
server target devices, it is
necessary to insert (as above)
site-wide <style/> and <script/> nodes at request-time
in the payload actually being delivered at response-time:
test on-device since some implementations are
not entirely compliant.
Separating logical and physical design
like this helps reduce site-wide maintenance costs and
site-redesign difficulties as well as supporting graceful
degradation Certain features
(e.g. defs and
progressive enhancement use elements) enable
geometric shapes to be re-used. Appropriate use of
CSS. these
elements is encouraged in order to create compact code.
[To include the set of minimum device properties supporting specific best practices.]
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.7.3 3.6.3 Use Device
Classification to Simplify Content Selection/Adaptation 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