- This version:
- http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081215
- Latest version:
- http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest
- Previous version:
- http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081210
- Editors:
- Bryan Sullivan, AT&T
- Adam Connors, Google
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 upon
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 or previous experience with BP1.
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current
W3C publications and the latest revision of this technical report can be
found in the W3C technical
reports index at http://www.w3.org/TR/.
Incomplete draft: This document is an
editor's copy that has no official standing and is incomplete. It is subject
to major changes and is therefore not intended for implementation. It is
provided for review and feedback only. Please send feedback
to public-bpwg-comments@w3.org (archive).
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). Advisory Committee Representatives should
consult their WBS questionnaires.
This document was developed by the Mobile Web Best
Practices Working Group as part of the Mobile Web Initiative.
This document was produced by a group operating under the 4
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.
Table of Contents
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
[EXAMPLE] This Is A Best Practice Statement
3 Best Practice Statements
3.1 Personalization
3.1.1 Retain Information For
Personalization
3.1.2 Automatically Identify the
User
3.2 Security and privacy
3.2.1 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
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.4 Conservative use of resources
3.4.1 Use Transfer Compression
3.4.2 Minimize Application Size
3.4.3 Avoid Redirects
3.4.4 Minimize Automatically Issued Network
Requests
3.4.5 Use Push Methods to Reduce Pull
Traffic
3.4.6 Minimize External Resources
3.4.7 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.4.13 Minimize DOM Manipulation
3.4.14 Reduce Cookie Size
3.4.15 Don't Send Cookie Information Unnecessarily
3.4.16 Use JSON in favour of XML for Datafeeds
3.5 User Experience
3.5.1 Design for Multiple Interaction Methods
3.5.2 Use Scripting to Improve
Perceived Performance
3.5.3 Preserve Focus on Dynamic Page
Updates
3.5.4 Group Closely Coupled Views
3.5.5 Use Fragment IDs for Application Views
3.5.6 Make Telephone Numbers
Clickable
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.6.1 Use Server-side Capability Detection
3.6.2 Use Client-side Capability Detection for
Dynamic Device State
3.6.3 Use Device Classification to Simplify
Content Adaptation
3.6.4 Support a non-JavaScript Variant
if Possible
3.6.5 Offer Users a Choice of 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
Appendices
A Sources (Non-Normative)
B Examples (Non-Normative)
C Related Reading (Non-Normative)
D Acknowledgements (Non-Normative)
E References (Non-Normative)
E.1 MWI References
E.2 Sources
E.3 Device Independence
E.4 Web, Protocols and Languages
E.5 Other References
The following Best Practices are discussed in this document and listed
here for convenience.
TODO
This document sets out a series of recommendations designed to facilitate
development and delivery of Web applications on mobile devices. The
recommendations are offered to creators, maintainers and operators of mobile
Web sites.
Readers of this document are expected to be familiar with the creation of
Web applications, and to have a general familiarity with the technologies
involved, but are not expected to have a background in mobile-specific
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 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 device
capabilities to enable a better user experience; or b) are considered harmful
and can have non-obvious detrimental effects on the overall quality of the
application.
The goal of this document is not to invent or endorse future technologies.
However, there are a number of cases where explicitly omitting a Best
Practice that referred to an emerging technology on the grounds that it was
too recent to have received wide adoption would have unnecessarily excluded a
valuable recommendation. As such, some Best Practices have been included on
the grounds that we believe they will soon become fully qualified
Best Practices (e.g. in prevalent use within the development community).
For the purposes of this document, the term "Web application" refers to a
Web page (XHTML or a variant thereof + CSS) or collection of Web pages
delivered over HTTP which use either server-side or client-side processing
(e.g. JavaScript) to provide an "application-like" experience within a Web
browser. Web applications are distinct from simple Web content (the focus of
BP1) in that they include some elements of interactivity and persistent
state.
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 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).
1.3.4 Delivery Context
Requirements on delivery context have not been made explicitly, but most
best practices assume devices with basic XHTML, JavaScript, and CSS
compliance. Additionally, some best practices are relevant only if the device
exposes certain capabilities (for example, access to device information such
as location).
Implied by this discussion is that some level of device knowledge and
content adaptation is required. For best practices specifically related to
this area, see 3.6.1 Use Server-side
Capability Detection for Device Properties and 3.6.2 Use Client-side Capability Detection for
Device State.
These recommendations are complimentary to the recommendations of Mobile
Web Best Practices 1.0 (BP1).
This document builds on some of the concepts described by the Ubiquitous
Web Applications (UWA) working group 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].
1.5 Terminology
Note that the term "JavaScript" is used in place of the (arguably more
correct) term "ECMAScript" in order to provide consistency with the companion
Web application technologies (JSON and AJAX) which are in common use and both
implicitly refer to JavaScript in their names.
Also, the 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.
- The Heading
- A summary of the functional area to be addressed by these
statements
- The Statements
- One or more Best Practice statements identified in the following
way:
[EXAMPLE] This Is A Best Practice Statement
- What it means
- An explanation of the intention of the Best Practice statement.
- How to do it
- A discussion of the techniques and device capabilities required to
implement this Best Practice.
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.
If a service relies on user entered information (e.g. application
preferences, personal details) the user should not have to re-enter that
information during the normal course of the application. This is important
both within a usage session and across usage sessions.
A number of technologies can be used to persist user entered information.
Usually a combination of technologies will be required, the choice of which
is application and context specific:
- Server Based Session Management:
- Most servers offer the facility to store client state in-memory on
the server. By default they will identify the request based on either a
cookie or by URI decoration.
- JavaScript Variables:
- JavaScript object state can be used as a temporary datastore provided
the page is not reloaded. Note, however, that the JavaScript runtime is
not guaranteed to remain in memory if the application is placed in the
background, and so JavaScript state should be used only for short-lived
and volatile data.
- Hidden Form Elements:
- Within a usage session, state can be preserved between pages by
storing extra personalization information in hidden form elements, e.g:
<input
type="hidden" name="somedata"
value="some_previously_entered_value"/>.
- Cookies:
- When supported and active, cookies are a common and effective means
to store state on the client. Be aware, however, that cookie data is
exchanged with the server on every request and can impact performance.
See 3.4.14 Reduce Cookie Size for
more details. Also see BP1 [COOKIES] Do not
rely on cookies being available for more detail.
- Persistent URL:
- Where no alternative exists (e.g. cookies are unsupported) some
degree of personalization is still possible by redirecting the user to
a persistent URL (PURL). On first-use, users should be prompted to
bookmark this unique URL and use it to identify them in future
requests.
- HTML5 Local Storage API:
- If supported, the HTML5 Local Storage API can be used to store
application data on the device. It is appropriate for more complex and
larger data than would be possible with other methods. See Offline
Webapps for more details.
- Server Based Datastore:
- Extensive personalization data and state that is required across
usage sessions should be stored in a server-side datastore whenever
possible. A server based datastore is the only way to facilitate the
sharing of state across multiple devices. See 3.5.10
Ensure Consistency Between Desktop and Mobile for more details.
Ensure that personalization information is available to the user with
minimal effort by using their identity to automatically restore application
preferences.
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 identify the user is to prompt for
login credentials on first 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) 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 is looking for feedback on the
validity of this Best Practice. Whilst it is a true reflection of techniques
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 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 the cookies associated with the
data providing site and 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:
- Ensure that the data comes from a trusted source (e.g. contains no
user-generated data).
- Use a "Safe EVAL" method which encodes any unsafe characters in the
datafeed before evaluating.
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 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 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.
A number of standard and proprietary APIs exist to give browsers access to
both personal and device information, for example:
- File system access to pictures, music, and video clips
- PIM data (contacts, calendar)
- Call handling
- System data (battery, coverage, roaming, location)
- Media recording (record audio/video clip, get new picture)
- Device context (e.g. location, connectivity, profile setting)
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 their
use.
Whenever an application makes background data requests, whether automatic
or user-initiated, this should be indicated to the user in an appropriate
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 the user should be informed
when they first 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:
- how often the application will interact with the internet. E.g. every 5
minutes, hourly, daily.
- how long the automatic behaviour will continue.
- how heavy the overall usage is expected to be or the type of service
plan recommended.
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.
3.3.2.2 How to do it
At a minimum, provide the ability to switch off the automatic network
activity. Endeavor to keep the application as functional as possible if
automatic network activity is 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 if the application needs to access
personal or device information. The user should be informed of the types of
information that will be used by the application and how that data will be
exchanged with the server. Applications should be defensive and remain as
functional as possible if the API request for 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 will lead
to the user being presented with repeated confirmation dialogues by the
underlying API.
Resources, such as device memory, processor power, and network bandwidth
are significantly more limited on mobile devices than on the desktop. The
most effective way to ensure that applications run smoothly and with low
latency is to take steps to ensure minimal use of resources.
Compress content for efficient delivery.
HTTP 1.1 compression, which typically uses gzip or deflate as algorithms,
is a widely (though not universally) supported method of compression. In
general, Web servers should be configured to serve Web pages using HTTP 1.1
compression, according to the coding supported by the device as indicated by
the HTTP Accept-Encoding header.
Note however, that the 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:
- Most binary data (especially JPEGs) will not benefit from gzip
compression.
- For very small files (e.g. <1k) the negative impact of processing
may outweigh any small transport gains.
3.4.1.3 Maximizing Compression Efficiency
Gzipping of HTML and CSS files can be made more efficient by ensuring
consistency in the code. For example:
- Ensure consistent ordering of attributes in elements (e.g. alphabetize
them).
- Use consistent casing (e.g. all lowercase)
- Use consistent quoting (e.g. always use single-quotes)
This section elaborates on the Best Practices of BP1 (MINIMIZE).
Smaller applications will download and execute more quickly and more reliably
on constrained devices.
- Process HTML and CSS files at build time to remove whitespace and
minify. A number of Open Source whitespace strippers are available.
- Process script files at build time to remove whitespace and minify the
script. Several Open Source javascript compilers are available.
The working group is seeking recommendations for the
best / most-commonly used tools to reference in this section.
Request redirection (through HTTP response header or meta refresh) is
typically used to exchange information between servers (e.g. account
authentication). 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, use a landing page to communicate to
the user that the application is still working.
Applications that automatically issue network requests should provide
"value" for those requests so as not to unnecessarily impact battery-life and
application performance. Take care to ensure network requests are as well
optimized as possible.
Consider the following possibilities when designing an application:
- Batching requests:
- A single request for more data is considerably more efficient than
several smaller requests. Wherever possible, batch up multiple requests
at the application level.
- Backoff during periods of inactivity:
- If the application polls for updates, it should monitor user-activity
and poll less frequently during inactive periods.
- Device Context:
- If supported by the device, use awareness of current connectivity
(e.g. WiFi) to select an appropriate level of interaction.
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:
- OMA Push: a widely supported enabler providing methods for
user-confirmed and automatic content push, directed to mobile browsers
and other user-agents. [ REF ]
- Alternative vendor-specific initiatives.
3.4.6.1 What it means
A Web application typically requires a number of resources (stylesheets,
scripts, image, etc) each of which may incur an additional HTTP Request. HTTP
roundtrips are particularly expensive on a 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
As far as makes sense after taking into account 3.5.8
Separate Rarely Used Functionality combine all stylesheets into a single
resource and all scripts into a single resource. If multiple scripts and
stylesheets are required as part of the authoring process, then try to
arrange that they are merged before the page is served.
3.4.7.1 What it means
In some circumstances performance is improved if the 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
Investigate for a given application the optimum configuration. Whether
inlined resources make sense or not depends on a number of factors. For
example:
- The cache hit rate (e.g. the number of times an average user will
successfully load script resources from the browser cache).
- The size of the JavaScript and CSS files.
- The frequency with which the JavaScript and CSS files change.
3.4.8.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 roundtrip which is detrimental to performance. To avoid this,
all static images should be sprited together into a single image.
3.4.8.2 How to do it
Using manual or automatic means, combine all icons into a single image. To
optimize the efficiency of this:
- For PNG and GIF files, sprite images with similar sizes and colour
palettes.
- In general, avoid spites for JPEGs, but if you do use them, sprite on
8x8 boundaries.
- Sprite images that don't change often -- e.g. if a single image in a
sprite changes the whole sprite will need to be downloaded.
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 the look and feel
of an application. These can be inlined in the 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 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
- Set the resource caching policy to never expire by setting the Expires header
to a date in the far future.
- Reference the resource using a URL that contains a Hash of the content.
If the content changes, this reference will change and the browser will
fetch the updated data.
3.4.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.
A Web application is not guaranteed to be suspended if it is placed in the
background and may continue running for a long period. In this case, the
impact of prolonged JavaScript operations on battery-life should be
considered.
- Network activity is the biggest drain on battery power. If the
application requires ongoing network activity (e.g. to poll a server for
updates) take steps to inform the user of this activity and minimize its
impact on battery-life. See 3.3.1 Inform the User About Automatic Network Access
- Excessive DOM manipulation over an extended period of time can also
impact device battery life.
The working group is currently investigating the
relative impacts of Web application activities on battery life in order to
make more concrete recommendations.
On small devices with limited processing capability, the cost of excessive
DOM manipulation can impact application performance.
Only use DOM manipulation for dynamic parts of the page. The static
framework of the page is best created using HTML markup which can then be
connected to the script using the element ID attribute.
3.4.14.1 What it means
Information stored in cookies is exchanged between the server and the
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
improved by serving these from a path or subdomain for which the application
cookies are out of scope.
3.4.15.2 How to do it
Use a different domain, subdomain, 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.
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.
- It is more compact.
- It is quicker to parse since it can be directly parsed using the eval
method.
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 (REF). On the client, JSON is
readily parsed into a javascript object model using the eval method. Note,
however, that care should be taken to observe: 3.2.2 Secure
JSON Datafeeds and 3.2.3 Use a Safe EVAL for JSON
Datafeeds.
Given the additional complexities of interacting with an application on a
mobile device, special consideration should be given to the overall user
experience. User experience is influenced by a number of factors, including:
perceived latency, interaction method, and data consistency.
3.5.1.1 What it means
Interaction methods vary across different devices. Three main interaction
methods should be considered:
- Focus Based: The browser focus "jumps" from link to link.
- Pointer Based: Key-based navigation controls a pointer that can cover
any part of the screen.
- Touch Based: Events are related directly to a touch position on the
screen with finger or stylus.
Devices may implement one or more of these approaches and it is important
for an application to remain usable in all cases.
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:
- Selectable elements can be widely spaced as the user can select them
easily by jumping from link to link.
- The current location of the user can be easily determined as link
elements will be in focus.
Pointer Based:
- Selectable elements that are associated need to be near each other as
scrolling the pointer can be slow.
- The current location of the user can be easily determined as link
elements will be in focus.
Touch Based:
- Selectable elements can be widely spaced as the user can select them
easily.
- No elements are in focus until they are selected so extra information
cannot be passed to the user (e.g. rollovers will not work).
Using script for dynamic parts of the page means that the view can be
updated without a full page reload. Since reloading the entire page can be
slow this can greatly improve application usability.
Use asynchronous (XHR) requests to get additional information from the
server in response to user events and update the page DOM to convey this to
the user.
The JavaScript focus method can be used to move the focus to the part of a
page that has changed. However, if unexpected, this can confuse or irritate
the user, especially if returning to the previous focus is not easy.
Use the JavaScript focus method only if it is essential to the use of the
application, and does not inhibit user control/interaction.
3.5.4.1 What it means
Most applications consist of a number of views (e.g. an email application
consists of an inbox and the message detail view). User experience is
improved if switching between these views does not require a server
roundtrip.
3.5.4.2 How to do it
Each view can be rendered in a DIV element which is hidden using css.
Client-side script can be used to reveal content in response to user events
without the need for a server roundtrip.
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:
- Enabling deep links (e.g. to the content of a specific email) means the
user can still bookmark this view and return to it quickly.
- Enabling the browser history provides a natural method to navigate
application views that is natively supported by the browser.
3.5.5.2 How to do it
Each view within an application should be identified with a fragmentID
(e.g. http://www.myapp.com/myapp#view) and JavaScript used to interrogate the
browser location in order to determine which view to display.
Standardized URI schemes have been defined for some common device
functions, e.g. making phone calls and managing phone 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 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
available space. Fixed paragraph widths (even when optimized for the device
screen) are error prone, make it harder to support 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 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 initial page. JavaScript and CSS styles
associated with rarely used features should be bundled separately and
downloaded only if those features are accessed.
3.5.8.2 How to do it
Consider what functionality is being downloaded in a given script resource
and how likely that functionality is to be used in the majority of requests.
If some functionality is rarely used, it may make sense to partition this
into a separate script to be loaded on demand. On demand loading can be
accomplished by:
- Moving that functionality onto an entirely separate page.
- Creating an embedded frame to load the required additional resources in
response to a page event.
- Using <link
rel="prefetch">
The working group is seeking feedback on this Best
Practice. Whilst it contains value for very large / complex applications, the
implementation of this technique and its support across even high-end devices
is not clear. Specifically, IFRAMEs are known to have significant issues on
many devices and so we are looking for validation that their use in this
context is a good idea.
3.5.9.1 What it means
Progressive rendering means that the page will be displayed incrementally
as it loads. In most cases this results in an improved perceived latency
since content is available earlier.
3.5.9.2 How to do it
Place CSS 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 page until the stylesheet has been loaded and will block while
JavaScript content is parsed.
3.5.10.1 What it means
This recommendation builds on the recommendation in BP1 (5.5.1 Thematic
Consistency) and expands it to consider the application
preferences and personalization data that form part of the
overall experience on a mobile Web application.
User credentials valid on one device should be valid on other devices.
User preferences captured on one device should be accessible on other
devices. The most valuable example of this would be in offering a consistent
experience where information entered during a desktop session is accessible
in a mobile session and vice-versa.
3.5.10.2 How to do it
For application data to be shared between devices it must be stored on a
server and cannot be stored locally on a device (e.g. using cookies or a
local 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.
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 static device capabilities that won't change (e.g. SVG support,
screen-dimensions) it is preferrable to detect these capabilities on the
server and adapt content before it is sent to the client in order to avoid
transferring unnecessary data.
Typically used methods of device capabilities detection:
- The "user-agent" header can be used to identify the device, and a
Device Description Repository (DDR) can be used to retrieve a detailed
description of capabilities.
- The "accept" header can be used to indicate specific MIME types
compatible-to/preferred-by the device.
- The "x-wap-profile" header (User Agent Profile or UAProf) can be used
both as device identification and as a source for detailed device
capabilities info.
For dynamic device state that might depend on the configuration or context
of the device (e.g. Is scripting enabled? Is the SDCard available? Has
permission been granted for PIM access?) detection must be done on the
device.
Use JavaScript reflection to determine if a given API is active and
interrogate the device configuration using appropriate APIs. Two methods can
then be used to adapt on the client to differing configurations:
- Encapsulate the different behaviours in the control logic of the
application. E.g. simply use: if
(some_configuration_variable) decision-points in the code and
behave accordingly.
- Use an initial "bootstrap" script to assess device capabilities and
request the appropriate application bundle accordingly.
Option (1) is simpler to implement and is appropriate provided the amount
of inactive code downloaded doesn't have a negative impact on performance.
Option (2) is preferred when the application must change significantly in
response to properties that can only be determined on the client.
If a large number of devices are being targetted, or the application is
sensitive to the permutations of a large number of configuration properties,
the number of application variants required might quickly become
unmanageable.
To combat this, classify target devices into different "buckets" and build
a single application variant for each device bucket.
This will keep the amount of device-specific code to a minimum without
unduly encouraging a "lowest common denominator" solution.
Identify the target devices for the application and assign these to
"buckets" of varying capability. Focus on application variants that work in
each bucket rather than building device-specific exceptions for every
variation in device configuration.
Device buckets should be defined on an application-specific basis, so that
the variants can be tailored accordingly. For example, the following is a
typical configuration of application buckets:
Bucket 1: Basic XHTML support, no or very basic
scripting. No AJAX support.
Bucket 2: Full AJAX and JavaScript support.
Bucket 3: Advanced device APIs, for example: access to
location API, device PIM data, or application cache.
Scripted and XHR based applications are not yet well supported on many
browsers. If possible, provide a variant of the application that does not
rely on script by using synchronous FORM posts instead.
Essentially this BP states that it is favourable to support "Bucket 1"
devices as defined above if at all possible. Doing this will ensure that the
application can be used across as broad a range of devices as possible.
Furthermore, in some cases a non-JavaScript version can sometimes be useful
for simple operations in low-bandwidth situations.
In some cases, however, the type of application simply has no
non-JavaScript counterpart (e.g. a Web based game, an IM client) in which
case it should return a 406 Not Acceptable
response.
Do this by detecting the device User-Agent and checking its JavaScript
support against a DDR or local index.
3.6.5.1 What it means
Not only is device characteristics detection imperfect, it cannot always
account for the differing use-cases of an application. If multiple flavours
of the application exist (e.g. to support the various device 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
Only if it makes sense in the specific context of a given application,
allow the user to switch to a different flavour (for example, upgrading their
experience if their device is more capable than the server believes, or
degrading if connectivity is poor and they wish to accomplish a very simple
task that can be done more easily with the minimal UI).
Always attempt to default to the most appropriate UI on first use.
Always remember the user's preference for future visits in a cookie or
local datastore.
3.7 SVG
Note: This section is still under review. The working
group is keen to receive further suggestions for best practices specifically
related to the use of SVG on mobile Web sites.
This section covers some specfic Best Practices related to the use of SVG
in mobile Web applications. SVG is a vector graphics format designed for use
in the Web. It is useful when there is a need to convey large amounts of
information.
3.7.1 Use SVG Tiny 1.1 Compatible Content
SVG Tiny 1.1 is the most broadly supported.
3.7.2 Minimize Size and Complexity of Content
Take steps to ensure that the SVG content is not overly complex since
constrained devices will have difficulty rendering it. Ensure that the
browser is configured to enable GZip compression as per 3.4.1 Use Transfer Compression.
3.7.3 Test on Target Devices
Even if SVG Tiny 1.1 is supported on target devices, it is necessary to
test on-device since some implementations are not entirely compliant.
3.7.4 Make Use of Language Features to Write Compact Code
Certain features (e.g. defs and use elements) enable
geometric shapes to be re-used. Appropriate use of 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.2 Background to 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
- XML
- Delivery Context: Client Interfaces (DCCI) 1.0, W3C Candidate
Recommendation 21 December 2007 (See http://www.w3.org/TR/DPF/)
- XML
- Extensible Markup Language (XML) 1.0 (Third Edition), Tim Bray, Jean
Paoli, C. M. Sperberg-McQueen, Eve Maler, Fran?ois Yergeau, Editors,
W3C Recommendation, 04 February 2004 (See http://www.w3.org/TR/2004/REC-xml-20040204/)
- XHTML-Basic
- XHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C
Working Draft, 5 July 2006 (See http://www.w3.org/TR/xhtml-basic/)
- CSS
- Cascading Style Sheets (CSS1) Level 1 Specification, H?kon Wium Lie,
Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 (See http://www.w3.org/TR/REC-CSS1)
- CSS2
- Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, H?kon
Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May
1998 (See http://www.w3.org/TR/REC-CSS2/)
- HTTP1.0
- Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945,
T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945)
- HTTP1.1
- Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616,
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html)
- UAPROF
- Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile
Approved Version 2.0 06 Feb 2006 (See http://www.openmobilealliance.org/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf)
- WTAI
- WAP Forum wap-268-wtai-20010908-a Wireless Telephony Application
Interface Specification (See http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf)
- RFC 3966
- The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December
2004 (See http://www.ietf.org/rfc/rfc3966.txt)
- RFC 2119
- Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
IETF, March 1997 (See http://ietf.org/rfc/rfc2119)