Copyright
© 2009 ©
2010 W3C ® ® ( MIT ,
ERCIM
, Keio ), All Rights Reserved.
W3C liability
, trademark
and document
use rules apply.
This document specifies Best Practices for
the development and delivery of Web applications on mobile
devices. The recommendations expand
upon statements made in the Mobile Web Best Practices (BP1) [MWBP]
, especially those that relate to the exploitation of device
capabilities and awareness goal
of the delivery context. Furthermore, since
BP1 was written, networks and devices have continued
this document is to evolve, with aid the
result that a number development of Best
Practices that were omitted from BP1 can now be included. The
recommendation is primarily directed at creators, maintainers
rich and operators of dynamic
mobile Web applications. Readers of
this document are expected to be familiar with It collects the creation of
Web sites, and to have most relevant
engineering practices, promoting those that enable a
general familiarity with the technologies
involved, such as Web servers, HTTP, better user experience and Web application technologies. Readers warning against those that are not expected to have a background in mobile technologies
or previous experience with BP1. considered harmful.
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/.
This is a Last Call Working Draft
W3C Candidate Recommendation of Mobile
Web Application Best Practices, expected to become a W3C
Recommendation. The W3C Membership and other interested parties are
invited to review the document and send comments to public-bpwg-comments@w3.org
(with public
archive ) through 6 November 2009 .
). Specific instructions to send
implementation feedback on the document is available in the
implementation feedback template .
This document was developed by the Mobile Web Best Practices
Working Group as part of the Mobile Web Initiative
. A complete list of changes since
publication as a Last Call Working
Draft on 7 May
6 October 2009 is available. Main
changes are:
W3C publishes a
Candidate Recommendation
to indicate that the respective benefits document
is believed to be stable and to encourage implementation by the
developer community. The Mobile Web
Best Practices Working Group expects to request that the Director advance this
document to Proposed Recommendation once:
No feature has been identified as at risk at this point. The Working Group does not plan to request to advance to Proposed Recommendation prior to 15 April 2010 .
The working group decided to consider and include statements that may be regarded as forward-looking when this document is published (11 February 2010). Examples provided in the How to do it sections sometimes reference on-going works on technologies that the group expects to become prevalent in the development community soon. The group encourages mobile developers to report on their use of these technologies in mobile Web applications.
Publication as a Working Draft
Candidate Recommendation 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 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 Audience
1.3 Scope
1.3.1 Best Practices
1.3.2 Web Application
1.3.3 Mobile Context
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 Application Data
3.1.1 Use Cookies Sparingly
3.1.2 Use Appropriate Client-Side Storage Technologies
for Local Data
3.1.3 Replicate Local Data
3.2 Security and
privacy
3.2.1 Do not Execute Unescaped or Untrusted JSON
data
3.3 User
Awareness and Control
3.3.1 Inform the User About Automatic Network
Access
3.3.2 Provide Sufficient Means to Control Automatic
Network Access
3.3.3 Ensure the User is Informed About Use of
Personal and Device Information
3.3.4 Enable Automatic Sign-in
3.4 Conservative use
of resources
3.4.1 Use Transfer Compression
3.4.2 Minimize Application and Data
Size
3.4.3 Avoid Redirects
3.4.4 Optimize Network Requests
3.4.5 Minimize External Resources
3.4.6 Aggregate Static Images into a Single
Composite Resource (Sprites)
3.4.7 Include Background Images Inline in CSS
Style Sheets
3.4.8 Cache Resources By Fingerprinting
Resource References
3.4.9 Cache AJAX Data
3.4.10 Don't Do not Send Cookie Information
Unnecessarily
3.4.11 Keep DOM Size Reasonable
3.5 User
Experience
3.5.1 Optimize For Application Start-up
Time
3.5.2 Minimize Perceived Latency
3.5.3 Design for Multiple Interaction
Methods
3.5.4 Preserve Focus on Dynamic Page
Updates
3.5.5 Use Fragment IDs to Drive Application
View
3.5.6 Make Telephone Numbers
"Click-to-Call"
3.5.7 Ensure Paragraph Text Flows
3.5.8 Ensure Consistency Of State Between
Devices
3.5.9 Consider Mobile Specific Technologies for
Initiating Web Applications
3.5.10 Consider Use Of Canvas Tag or SVG For Dynamic Graphics
3.5.11
Use viewport
Meta Tag Viewport
Element To Identify Desired Screen Size
3.6 Handling
Variations in the Delivery Context
3.6.1 Prefer Server-Side Detection Where
Possible
3.6.2 Use Client-Side Detection When
Necessary
3.6.3 Use Device Classification to Simplify Content
Adaptation
3.6.4 Support a non-JavaScript Variant if
Appropriate
3.6.5 Offer Users a Choice of
Interfaces
3.7 Further
Considerations
3.7.1
Consider Use Of Canvas
Element or SVG For Dynamic Graphics
Appendix: Appendix 1: Best
Practice Dependent Device Properties
A Related Reading (Non-Normative) B
Appendix 2: References (Non-Normative)
B.1 2.1 MWI
References
B.2 2.2 Device Independence
B.3 2.3 Web, Protocols and Languages
B.4 2.4 Other References
Appendix 3: Acknowledgments
The following Best Practices are discussed in this document and listed here for convenience.
Use Appropriate Client-Side Storage Technologies for Local Data
Provide Sufficient Means to Control Automatic Network Access
Ensure the User is Informed About Use of Personal and Device Information
Aggregate Static Images into a Single Composite Resource (Sprites)
Consider Mobile Specific Technologies for Initiating Web Applications
Consider Use Of Canvas Tag or
SVG For Dynamic Graphics Use
viewport Meta Tag Viewport Element
To Identify Desired Screen Size
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 (BP1) [MWBP] .
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 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 an
application.
The goal of this document is not to invent or endorse future technologies. However, there are a number of cases where explicitly omitting a Best Practice that referred to an emerging technology on the grounds that it was too recent to have received wide adoption would have unnecessarily excluded a valuable recommendation. As such, some Best Practices have been included on the grounds that the Working Group believes that they will soon become fully qualified Best Practices (e.g. in prevalent use within the development community).
In building a Web application, it's
it is not necessary to implement
all Best Practices in order to avoid
pathological behaviour. Practices. Instead, each Best Practice should be
considered as a possible measure that might be implemented towards
the goal of providing as rich and dynamic an experience as possible
on a mobile Web browser.
For the purposes of this document, the term "Web application" refers to a Web page (XHTML or a variant thereof + CSS) or collection of Web pages delivered over HTTP which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser. Web applications are distinct from simple Web content (the focus of BP1) in that they include locally executable elements of interactivity and persistent state.
While the focus of this document is to
document the 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 as
part of the W3C work on Web
Widgets Effort [ WIDGETS ] and also in a number of vendor-specific
initiatives.
In an increasingly mobilized
a world where 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 should be
considered when developing for the mobile context (e.g. device
context / location, presence of personal data on the device,
etc).
Requirements This document builds on some
of the concepts described by the Ubiquitous Web Applications
Working Group (UWA) and the Device Independence Principles
[DIP] .It also discusses device and delivery context have channel
characteristics, which the UWA has named "Delivery Context"
[DCODI] .
This document does not been made explicitly, make
any explicit assumptions about features of the Delivery
Context, but most Best Practices assume devices with support
for standard XHTML, JavaScript, and CSS capability. At the time of
writing, developers of relatively complex Web applications
targetting targeting mid- to high-end devices are most likely
to benefit from these Best Practices, but as the technology evolves
it is expected that the range of relevant devices will
increase.
Additionally, some Best Practices are relevant only if the device exposes certain capabilities (for example, access to device information such as location). In these cases the requirements are summarized as a separate sub-heading.
Implied by this discussion is
Saying that applications should be sensitive
to the Delivery Context implies that some level of device
knowledge and content adaptation is required. For Best Practices
specifically related to this area, see 3.6 Handling Variations in Delivery
Context .
These recommendations are complementary to the recommendations
of Mobile Web Best Practices 1.0 (BP1) though their focus is
somewhat orthogonal. Whereas BP1 focussed focused on
delivering a good experience on a broad range of devices, this
document's focus is on making use of advanced device capabilities
to deliver the best possible experience on those devices that can
support it. For this reason, whilst
while readers of this document are
likely to benefit from reading BP1, BP1
it is in no
way not a pre-requisite for this document. This document builds on
some of the concepts described by the Ubiquitous Web Applications
Working Group (UWA) and the Device Independence Principles [DIP] .
It also 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] . pre-requisite.
Note that the term "JavaScript" is used in place of the (arguably more correct) term "ECMAScript" in order to provide consistency with the companion Web application technologies (JSON and AJAX) which are in common use and both implicitly refer to JavaScript in their names.
Also, the terms "AJAX" and XMLHttpRequest (XHR) are used to
refer to any asynchronous browser request. The implicit reference to XML suggested by the names is
commonly accepted to be an historical anomaly.
Most applications have the need to store data of various forms, both intrinsic content (e.g. the emails of an email application, the calendar events of a calendar application) and supplementary personalization settings (e.g. preferred theme, default view, etc).
These Best Practices relate to the appropriate technologies and techniques to use for managing a Web application's data.
Cookies are a common and effective means to store small amounts of state on the client. They are appropriate for simple personalization data and are commonly used to store a token representing user identity in order to enable automatic sign-in.
Information stored in cookies, however, is sent to the server for every request and so using them for excessive amounts of data can negatively impact performance, particularly on a mobile network.
Also, in the mobile context, cookie support cannot be relied
upon since it may be disabled either in the device configuration or
by the mobile network. For this reason, applications should
endeavour endeavor to remain functional even if cookies are
unavailable. See BP1 [COOKIES] Do not rely
on cookies being available for more cookie related caveats.
If supported by the device, client-side storage APIs provide a
mechanism to store more extensive amounts of data than would be
appropriate with cookies. Some
At the time of writing, work is still
undergoing to unify these APIs, see the W3C WebApps working group
[ WEBAPPS
] and Device APIs working group [
DAP ] for more information. Additionally, some
examples of existing technologies that
support client-side storage APIs are BONDI [ BONDI ], HTML5 [ HTML5 ], and
Opera Widgets [ OPERA ].
Making use of client-side storage in Web applications is a powerful technique that brings Web applications into parity with native applications in terms of start-up time and responsiveness. Two key advantages are worth noting explicitly:
[ Client-Side Storage ] Requires: Local Storage API.
If a client-side storage API is being used the data in it is not
visible to the user's other devices.
Whilst this is appropriate for some forms of data (e.g. preferences
and state relevant only to a given device), it is often necessary
to replicate send this data back to a server in order to
provide a consistent view across devices (e.g. between mobile and desktop instances of an
application) and make it possible to recover data if the
device is lost or damaged. See 3.5.10 3.5.8 Ensure Consistency Of State Between
Devices for further discussion on this
topic. these topics.
As a rule of thumb, data that needs to be shared with other devices or recovered in the case of a lost or damaged device, should be replicated back to the server as soon as possible.
The technologies that provide client-side storage APIs provide facilities to detect the current network connectivity. For example, 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 ).
However, these APIs should be used with caution. Even if the
browser is reporting an online state, on an intermittant intermittent network this is no guarentee guarantee
that a subsequent connection will succeed. The most effective
approach is to fail gracefully in the event of a connection
failure, store unsaved data in a queue of uncommitted changes, and
set a timer to try again later.
[ Client-Side Storage ] Requires: Local Storage API.
Use trusted information, and protect all personally identifiable information.
3.2.1.1 What it means
A common pattern technique is to use JSON to transfer data to a
client and then use JavaScript's eval() function
to parse it. This is a powerful technique, since on constrained
devices eval() can
execute more quickly than the alternatives. However, direct
execution of a datafeed that contains unescaped user-generated data
represents a significant security risk and should be avoided.
Inadvertantly Inadvertently 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
Where possible, instead of parsing JSON data by executing it with the eval() function, use a JSON parser (for example: http://www.json.org/json_parse.js ).
If this is impractical (JSON parsers are
approximately x10 slower than eval() and may be impractical for
large datafeeds) ensure that the data contains no
user-generated content (e.g. the server is responsible for the
content of all fields in the datafeed) or that any user-generated
content is correctly escaped.
See [ RFC4627 ] for details on how to ensure a JSON datafeed is suitably escaped and can be safely passed into JavaScript's eval() function.
Ensure that Allow the user is aware of
otherwise invisible application actions, and offer options to
control those actions. Browsers may
have application behaviour that might
not otherwise be apparent, such as access to information such as: the
network and access to device data. For example:
Note that where possible it is preferable to rely on the browser's native functionality to notify the user of these activities, however the Best Practices below provide further advice on appropriate application behaviour in situations where the native functionality of the browser may not be sufficient.
Network traffic on a mobile device incurs
a cost (both in terms of data-charges and depletes the battery life) and may incur expense
-- so it is important to inform the user when this happens. accessing the
network. Whenever an application makes asynchronous XHR data
requests, whether automatic (on a timer
or in response to an external trigger)
or secondary to some a user
action, action or
automatically, this should be indicated to the user in an appropriate manner so that the
user.. user
remains informed and in control.
Applications should disclose how they use network resources. A simple icon indicating background activity is usually sufficient and does not interrupt the flow of the application. If extensive background network activity is required the user should be informed when they first visit the site, when they first sign-in, or in associated help pages.
The kinds of detailed information that could be disclosed in associated help pages or terms of service are:
If an application makes automatic network requests (e.g. to poll the server for updates or to automatically store an updated client state) a means to control this activity should be provided.
All applications that access the network automatically
must should
provide a means for the user to disable that activity. When
automatic network activity is disabled, periodically prompt the
user to make network requests.
Consider allowing the user to adjust the polling schedule and to control which activities are allowed to initiate network requests.
Ensure that the user is informed if the application needs to access personal or device information. The user should be informed of the types of information that will be used by the application and whether / how that data will be exchanged with the server.
These notices should be provided when the user first accesses
the Web application, or on first access
to user information, or in help pages.
information. It should provide the user
with enough information to reasonably
judge whether or not they want to allow the application access to
their data.
In many cases use of APIs that provide access to personal or device information causes a native confirmation dialog to be presented to the user. In this case the application should not force the user to confirm again at the application level, but should make clear in the UI that displayed data has been accessed from the device.
If the user declines a prompt to allow application access to
personal or device information, the application must recover
gracefully. For example, if a request to a device API fails, do not
automatically retry if this will lead to the user being presented
with repeated native confirmation dialogues. dialog
boxes.
[ DEVICE DATA ] Requires: Device Data APIs.
If an application requires user identity it is usual to prompt
for user credentials (username and password) and provide the option
to sign-in automatically on next usage session. This is especially
important on a mobile device where data input is more painful difficult than
on a desktop.
Note that if automatic sign-in is enabled, a sign-out link should also be provided.
User credentials can be stored in a cookie or in local storage.
However, it is important not to store unencrypted password
information since this is insecure. Most
commonly, Typically, a securely
hashed token which which, if necessary, can be revoked on the
server if necessary server, is stored locally in order to enable
automatic sign-in.
Battery lifetime and cost of network
traffic are significant considerations of The most users of mobile
devices. Since all activities that use either processor or wireless
connectivity will incur some cost effective way to battery
life or network data costs, ensure
that applications should consider this
factor run smoothly and
be conservative in their with low latency is to minimize use of resources. Additionally, resources, such as device
memory, processor power, and network bandwidth which 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 algorithms, is widely supported. Web servers
should be configured to serve appropriately compressed responses.
Where supported, alternative compression
formats (such as [ EXI ]) may also provide
benefit.
Note however, that the cost (in time and battery usage) of decompressing data should be balanced against the gains in transport efficiency. When configuring HTTP 1.1 compression note that:
This section elaborates on the Best Practices of BP1 ( MINIMIZE ). Smaller applications will download and execute more quickly and more reliably than larger ones on constrained devices.
Process HTML, JavaScript and CSS files to remove whitespace and
minify before delivery. A number of freely
available whitespace strippers and JavaScript / CSS optimizers are
available online.
Note that "minification" "Minification" / "optimization" can may take a number
of forms from simple removal of whitespace white space
and comments, to the global substitution of tokens (variables,
method names, selector names) with shorter alternatives. In
general, minification that parses the source
file and makes substitutions based on upon a lexical /
grammatical understanding of that source are is less fragile
and should be is preferred to simple regular-expression based
tools.
For See
http://compressorrater.thruhere.net
for a good
comparison of JavaScript minification tools
try: http://compressorrater.thruhere.net tools.
Request The redirection (through of requests
(using HTTP response header
3xx status or HTML 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.
minimum.
Try not to use redirects. If more than two redirects are required consider using an interstitial page to communicate to the user that the application is still working.
Network operations are costly
Establishing the necessary connections
in terms of battery usage, application
latency, and potential network traffic expenses, and should not be
made unnecessarily. The latency cost of setting up a
order to complete an HTTP request
is much higher can take significantly longer on a mobile network
than the on a
fixed network. Even though bandwidth limitations is typically
more restricted on a mobile network and
so it is still preferable to make
fewer, larger requests are preferred.
requests.
Consider the following possibilities when designing an application:
3.4.5.1 What it means
A Web application typically requires a number of resources
(style sheets, scripts, image, etc) each of which may incur requires an
additional HTTP Request. request. As
above, HTTP round trips
requests are particularly expensive on
a mobile network and so fewer, larger requests should be
favoured favored over a larger number of smaller
requests.
3.4.5.2 How to do it
As far as makes sense after taking into account 3.5.2 Minimize Perceived Latency combine all style sheets into a single resource and all scripts into a single resource. If multiple scripts and style sheets are required as part of the authoring process, then try to arrange that they are merged before the page is served.
3.4.6.1 What it means
Web applications often depend on a number of static images to
provide icons, buttons, etc. If served as a separate image each one
incurs an additional HTTP round-trip
request which is detrimental to
performance when compared with combining them
into a single image for transfer. performance.
3.4.6.2 How to do it
Combine images into a single image for
transfer (spriting). To optimize efficiency: For PNG and GIF files, efficiency combine images with of similar sizes
and color palettes; Endeavour to sprite JPEGs
on 8x8 boundaries in order to minimize the size of the combined
JPEG. palettes. Combine images
that do not change often. If one of the component images changes,
the entire combination image will need to be downloaded. refreshed.
To render individual components of a resource use CSS positioning
and clipping.
[ CSS ] Requires: CSS2 Clipping and Positioning Support
3.4.7.1 What it means
Background Visual effects (e.g. background images and gradients) 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.
request
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
fewer requests.
3.4.7.2 How to do it
Background images can be encoded using the data URI scheme:
url('data:image/png;base64, [data])
[ CSS ] Requires: RCF2397 data uri support.
3.4.8.1. What it means
Dynamic resources that change occasionally (e.g. a user's
avatar) can still be cached by identifying them with a URI that
includes a Hash hash 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.
For example,
<img src="http://www.example.com/userimages/joeblogs-67f90da089da">
Where the actual resource at joeblogs-[xxx] could be either generated in some offline process or served dynamically.
3.4.8.2 How to do it
Expires
header to a date in the far future.3.4.9.1 What it means
If possible, data designed to be accessed by AJAX requests from the client should be cached in the same way as primary content.
3.4.9.2 How to do it
The standard caching techniques ( Expires
header
and Cache-Control
header), as well as resource
fingerprinting (see 3.4.8
) can be used on AJAX data as readily
as primary content pages.
3.4.10.1 What it means
Static resources don't do not need cookie information and so performance
can be improved by serving these
them from a path or sub-domain for
which the application's cookies are out of scope.
3.4.10.2 How to do it
Use a different domain, sub-domain, or path name for static resources to the main application, and restrict the valid path of cookies such that they will not be exchanged when they are not needed.
For example:
Set-Cookie: somePreferenceInformation=purple; path=/myapp/
Application data served from /myapp will receive cookie information.
Static data served from /static will not receive unneeded cookie information.
The permitted in-memory size of the Document Object Model (DOM)
is more constrained may be limited on mobile devices and can be exceeded by large devices. Large / complex pages. Keep the DOM size below 10MB to avoid browser
crashes. pages may exceed this limit
and cause unpredictable errors.
Clip content and separate content onto
separate pages to keep Limit the amount
of information in the DOM size
manageable. at a single time using
pagination or other appropriate techniques.
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: latency, interaction method, and data consistency.
User experience is strongly influenced by the initial start-up time of an application.
Offline Web application technologies like HTML5 AppCache
[ HTML5-OFFLINE ]
bring Web applications into parity with native applications in
terms of their start-up time and their ability to be used
under intermittent even where network coverage. coverage is
intermittent. The following steps should be considered to
minmize minimize the start time of a Web application.
Consider the following techniques to help minimize application start time:
The Best Practices covered in section 3.4
Conservative use of resources will help to minimize the latency of
a Web application, but a number of measures can also be used to
further minimize the perceived latency. Lowering perceived
latency is an important factor in improving the overall usability
of a Web application, improving user's
perception of Web site credibility and decreasing bail out
rates. application.
A number of techniques can be used to improve lower
perceived latency:
Interaction methods vary across devices. Three main interaction methods should be considered when designing the UI:
The optimum configuration of UI elements varies depending on the
interaction method used by the device. Ideally, the UI should be
adapted based on a knowledge of the interaction methods supported
by the target device. If this is not possible, then the UI should
be carefully designed in order to provide a good experience in for each of these
different interaction methods.
Particularly where navigation of content requires multiple links
(ie (i.e.
back/forward in a carousel) the following factors should be
considered:
Focus Based:
Pointer Based:
Touch Based:
The JavaScript focus
method can be used to move the
focus to the part of a page that has changed. However, if
unexpected, this can confuse or irritate the user, especially if
returning to the previous focus is not easy.
Use the JavaScript focus
method only if it is
essential to the use of the application, and does not inhibit user
control/interaction.
3.5.5.1 What it means
Web applications can switch 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 possible to link directly to specific views within an application. Usability is enhanced by enabling both of these features:
3.5.5.2 How to do it
Each view within an application should
have Assign a URI with a
distinguishing fragment identifier (e.g.
http://myapp.example.org/myapp#view
) and ). Use
JavaScript used to interrogate the
browser location in order to determine which view to display.
For further discussion on this topic see: http://ajaxpatterns.org/Unique_URLs
Note that showing and hiding content in this way can have adverse affects on accessibility if not carefully handled. See [ ARIA ] for more information on writing accessible rich Web applications.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>
Note that [PHONE-NUMBER] should always be entered using the full international prefix (e.g. +1-201-555-0111) to ensure that it works outside of its home country.
3.5.7.1 What it means
On small screens it is important that paragraph text flows
both so that it doesn't require
horizontal scrolling and so that it will reflow re-flow if the
view orientation is changed. See BP1
[MEASURES] for more details.
3.5.7.2 How to do it
Do not use absolute or pixel
measures. Use percentage and RELATIVE measures for containers so that text can
reflow re-flow automatically.
3.5.8.1 What it means
This recommendation builds on the recommendation in BP1 ( 5.5.1 Thematic Consistency ) and expands it to consider the application preferences , personalization data , and state that form part of the overall experience on a mobile Web application.
User credentials valid on one device should be valid on other
devices. User preferences captured on one device should be
accessible on other devices. Data updated on one devices device should
be viewable consistently on other devices.
The most valuable An important example of this would be in is
offering a consistent experience where information data
entered during on a desktop session
is accessible in available on a mobile session and vice-versa. vice
versa.
3.5.8.2 How to do it
For any application data that is not exclusively relevant to the current device, favor storing it on the server so it can be shared by other devices. See 3.1 Application Data for more details.
Network-initiated content delivery ("push") methods allow
notifications and updates to be pushed
sent to the
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
a device classification repositories. repository.
If supported by the user agent, options for Push methods include:
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=device-width,minimum-scale=1.0,maximum-scale=1.0"/>
content="width=device-width,
initial-scale=1.0"/> ,
and should be is inserted into the <head>
element 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. The setting above is
appropriate for pages specifically designed for the target
screen-size.
Variations in the delivery context
Delivery Context (such as different
device capabilities) is a prominent feature of the mobile Web. Web
applications should adapt to known or discoverable properties of
the delivery context Delivery Context by adjusting the content,
navigation or page flow, with a view to offering a good user
experience on as broad a range of devices as possible.
Where possible, use the evidence available on the server to
determine the properties of the delivery
context, Delivery Context, and
adapt the responses to the client before transmission, transfer, thus improving the user experience and
avoiding transmission transfer of unnecessary or incompatible data.
In its most basic form, the minimum evidence from the
client requesting device is the HTTP request header. header fields.
Typically, the following header fields provide evidence of device
capabilities:
Where it is not possible to determine certain properties of the
delivery context Delivery Context from the server, this information
may be available at the client. Once obtained at the client, the
information can be used directly to adapt the presentation, or it
can used to request alternative, adapted content from the
server.
There are a few client-side solutions available to the developer:
JavaScript: this is the most common solution. A script determines the device / browser properties and manipulates the content and behaviour of the application accordingly. This can be done in two ways:
CSS Media Types: CSS Media Types allow different stylesheets to be associated with different media types (e.g. print, screen, mobile) and are traditionally used to repurpose content for these destinations. Since the list of recognized media types is limited, however, and devices are notoriously idiosyncratic in their interpretation of types, it is in general not a helpful technology in this context. See Media Types [ CSSMT ] for more details.
CSS Media Queries:
Media queries are an extension to the "media-types" paradigm that
allow developers to apply specific style rules based on the device
display characteristics (e.g. screen width, orientation, or
resolution). At the time of writing this specification is not fully
supported, but can provide a useful way to modify the page layout
(for example to reflow re-flow sections of text) in a more maintainable,
declarative way than is possible with script. See Media Queries [
CSSMQ ] for more details.
If a large number of devices are being targeted, or if the application is sensitive to the permutations of a large number of configuration properties, the number of application variants required might quickly become unmanageable.
To combat this, classify target devices into different device classes and build a single
application variant for each.
each class. This will keep the amount of device-specific code
allows you to exploit device capabilities with a minimum without unduly encouraging a "lowest common
denominator" solution. manageable code
base.
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 application by application basis, so that the
variants can be tailored accordingly. For
example, the following is a possible configuration
Example 1: Possible definition of
application classes: classes based on rendering and device API
capabilities:
Class 1: Basic XHTML support, no or very basic scripting. No XHR support. (Even if these kind of devices are not being explicitly supported, it is often advisable to support a non-XHR version in case JavaScript has been disabled on the device).
Class 2: Full AJAX and JavaScript support.
Class 3: Advanced device APIs, for example: access to location API, device PIM data, or application cache.
Example 2: Possible definition of application classes based on supported user-interaction modes:
Class 1: Pointer Based.
Class 2: Touch Based.
Scripted and XHR based applications are not supported on all
browsers. If broadest reach is a primary concern then consider
providing a variant of the application that uses synchronous FORM
posts in place of XHR requests. This Best Pratice Practice is
related (albeit with a differing focus) to BP 1 [
OBJECTS_OR_SCRIPT] .
Essentially this BP states that it is favourable favorable
to support "Class 1" devices as defined in
the first example above if appropriate. Doing this will
ensure that the application can be used across as broad a range of
devices as possible. Furthermore, in some cases a non-JavaScript
version can be useful for simple operations in low-bandwidth
situations.
In some cases, however, a particular application simply has no
non-JavaScript counterpart (e.g. a Web based game, an Instant
Messaging client) in which case it
the server should return a 406 Not Acceptable response. response with human readable content explaining the
situation in more detail.
Do this Ideally, content should be adapted before transfer
by detecting checking whether or not the device User-Agent and checking its supports JavaScript support
against using a DDR or local
index. However, in some cases (e.g. if the
device has disabled JavaScript) JavaScript may still be sent to a
device that can't process it. To cover this case, a
<noscript>
element should always be included and contain
a suitably informative message.
Not only is device characteristic detection imperfect, it cannot
always account for the differing use-cases 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
Therefore automatic detection is not
sufficient as the choice of
only mechanism for determining which
flavour they wish to use. version is appropriate.
Only if it makes sense in the specific
context Where multiple versions
of a given application, allow the user to
switch an application exist (e.g.
to a different flavour (for example,
upgrading their experience if their support the various device is more capable than classifications) always offer the server believes, or degrading if connectivity is poor
and they wish user the
opportunity to accomplish a very simple
task that can be done more easily with change the minimal
UI). selection.
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.
Canvas and SVG provide alternative options for incorporating graphics in a Web application. Support for these technologies varies across devices so in many cases the choice of which technology to use will depend on the target devices for a given application.
The canvas element specifies a display region where JavaScript can be used to draw simple graphics. In contrast, SVG is an XML language for defining vector graphic elements that are added to a DOM which can be modified using JavaScript.
SVG is well-suited for graphics that must be scalable and whose components need to be modified (e.g. panning and zooming a map) whereas canvas is better suited where a static bitmap is sufficient (e.g. drawing a scatter-chart or creating visual effects).
If speed is important, canvas may be more effective. However since Canvas generates a flat bitmap it is not inherently accessible and so should not be used as the sole means of conveying information.
See http://dev.w3.org/html5/spec/Overview.html#the-canvas-element for information on how to use the Canvas element.
See http://www.w3.org/Graphics/SVG/ for information on how to use SVG.
The following device properties included in the DDR Core
Vocabulary [REF] ( DDR-VOCAB ) 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:
Mobile Web Best Practices 1.0, Jo
Rabin, Editor, W3C Recommendation, 29th
29 July 2008 (see http://www.w3.org/TR/mobile-bp/
)
The editors would like to thank members of the BPWG for contributions of various kinds. The editors would also like to thank contributors to the public list, and contributors of Last Call comments whose comments have been taken into account in the creation of this document.
The editors acknowledge significant written contributions from:
* Daniel Appelquist, Vodafone
* Jo Rabin, mTLD Mobile Top Level
2 Revision 1 (CSS 2.1) Sp Domain (dotMobi)
* Phil Archer, W3C
* Jeff Sonst