- This version:
-
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081125
- 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-20081008
- 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.
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.
1 Introduction
1.1 Purpose of the Document
1.2 How the Best Practices are Organized
1.3 Audience
1.4 Scope
1.4.1 Best Practices
1.4.2 Web Application
1.4.3 Mobile Context
1.5 Relationship to other Best Practices and recommendations
2 Structure of Best Practice Statements
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 Protect Personal Information Used in Transactions
3.2.2 Ensure that JSON datafeeds are not Executable
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 Inform the User About Use of Personal Information and Degrade Gracefully if Permission is Denied
3.4 Conservative use of resources
3.4.1 Use Transfer Compression
3.4.2 Avoid Redirects
3.4.3 Minimize Automatically Issued Network Requests
3.4.4 Use Push Methods to Reduce Pull Traffic
3.4.5 Minimize Application Size
3.4.6 Minimize External Resources
3.4.7 Inline 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 Use a Cookieless Domain for Static Content
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 Prefer Serverside Capability Detection
3.6.2 Use Clientside capability Detection When Necessary
3.6.3 Use Device Classification to Simplify Content Adaptation
3.6.4 Support a non-ECMAScript Variant if Possble
3.6.5 Offer Users a Choice of Interfaces
Appendix: Best Practice Dependent Device Properties
Appendix: Examples
A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
D.1 MWI References
D.2 Sources
D.3 Device Independence
D.4 Web, Protocols and Languages
D.5 Other References
The following Best Practices are discussed in this document and
listed here for convenience.
This section will be completed when the
list of Best Practices is more stable.
This document sets out a series of recommendations designed to
facilitate development and delivery of Web applications on mobile
devices. The recommendations are offered to creators, maintainers
and operators of mobile Web sites.
The document is organized as follows:
- Introduction. Describes the audience, purpose and scope of the
document.
- Structure of Best Practices. An overview of how the Best
Practice statements are organized.
- Best Practices. The statements themselves.
- Appendices
- Best Practice Dependent Device
Properties
- Further Examples
- Sources
- Related Reading
- Acknowledgements
- References
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.
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.
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 modern 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 become fully qualified Best Practices
(e.g. in prevalent use within the development community) in the
very near future.
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
serverside or clientside processing (e.g. ECMAScript) 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).
These recommendations are complimentary to the recommendations
of BP1.
This document builds on some of the concepts described by the
Ubiquitous Web Aapplications (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].
-
This section will be completed when the
Best Practice statement structure is more stable.
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.
-
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 re-writing the query to include an
identifying parameter.
- ECMAScript Variables:
- Within the lifetime of a given pageload, clientside state can
be preserved across views by storing it locally as ECMAScript
objects, thus avoiding the need for a server roundtrip. Note,
however, that the ECMAScript runtime is not guarenteed to remain in
memory if the application is backgrounded, and so ECMAScript state
should be used only for short-lived and volatile data.
- Hidden Form Elements:
- Within a usage session, state can be preserved across server
roundtrips by storing extra personalization information in hidden
form elements, e.g: <input
type="hidden" name="somedata"
value="some_previously_entered_value"/>.
-
Cookies:
- 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.
- Personalized URL:
- Where no alternative exists (e.g. cookies are unsupported) some
degree of personalization is still possible by redirecting the user
to a personalized URL (PURL). After first redirect the user should
be prompted to bookmark this unique URL which can then be used 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.
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:
User login credentials should not be stored
directly on the device as this is a security risk. Instead, a
securely hashed token (that can be revoked at the server if
required) should be used to enable automatic login the next time a
user visits the site.
If you have a relationship with a Service Provider (e.g. Mobile
Network Operators or Web Portal Providers) or an Identity
Management Provider they 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, leading to a
better overall experience.
Use trusted information, and protect all personally identifiable
information.
Although HTTPS is the most common means to secure personally
identifiable information, the overhead of using it can be
significant over a mobile network. As such, HTTPS should not be
used unnecessarily, and the level of security should be matched to
the level of sensitivity of the information being exchanged.
Personally identifiable information (e.g. user identity or
information usable as a key to user identity) should only be
accepted or sent securely. Less sensitive information that cannot
be associated with an individual (e.g. a zip code by itself is not
personally identifiable) can be exchanged in the clear 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.
In general, HTTPS should always be used to exchange the intial
user credentials, but it is okay to exchange the hashed identity
token in the clear in subsequent requests.
3.2.2.1 What it means
A common paradigm in Web applications is to provide a datafeed
to an ECMAScript based Web client in the form of an executable
ECMAScript string (e.g. JSON). This has many advantages in terms of
speed of execution and ease of development, but it represents a
signifcant 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>
tag. This will execute the datafeed and in most cases generate an
ECMAScript object model in the client which can be accessed by the
malicious site.
3.2.2.2 How to do it
The ECMAScript datafeed can be rendered "unexecutable" by
prefixing it with, for example: while true;
This means that it will not execute when called from a <script>
tag, but can be preprocessed before evaluation to remove the prefix
when accessed via an XHR request (for which the same-origin
security model ensures security).
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.
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.
Device APIs are being developed in a variety of standards
activities and vendor-specific initiatives to give browsers access
to 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 this should be called out when the user first visits
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 will 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)
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 issues 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.
This section elaborates on the Best Practices of BP1 (MINIMIZE). Smaller
applications will download and execute more quickly so care should
be taken to avoid application "bloat".
- Process HTML and CSS files at build time to remove whitespace
and minify. A number of Open Source whitespace strippers are
available [REF] ?
- Process script files at build time to remove whitespace and
minify the script. Several Open Source javascript compilers are
available, for example: http://developer.yahoo.com/yui/compressor/
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, large 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 at build
time.
3.4.7.1 What it means
In some circumstances performance is improved if the ECMAScript
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 ECMAScript and CSS files.
- The frequency with which the ECMAScript 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 the browser doesn't need a roundtrip to the server
to check the validity of its cache.
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.
- Serve the image from a URL that contains a hash of the image
content. If the image content changes, the URL will change and the
browser will know to 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 guarenteed to be suspended if it is
backgrounded and may continue running for a long period. In this
case, the impact of prolonged ECMAScript 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
tag.
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 different
domain to the main application domain in order to avoid unnecessary
cookie exchange.
3.4.15.2 How to do it
Use a different domain name for static resources and restrict
the valid domain 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 Ensure
JSON datafeeds are not Executable and 3.2.3 Use a Safe EVAL for
JSON Datafeeds. (TODO: Link)
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 re-rendering the
page can be slow this greatly improves 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 without re-rendering the whole page.
The ECMAScript 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 ECMAScript 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. Clientside 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 ECMAScript
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 Wireless Telephony Application Interface
Specification (WTAI) defines the "wtai:" URI scheme for
accessing a variety of telephone functions. WTAI support may be
disclosed through a User Agent Profile
document if published by the device vendor.
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 paragrah 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
ECMAScript and CSS styles that are not required by the initial
page. ECMAScript 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 demain 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">
TODO, Check if rel="prefetch" widely
supported by mobile browsers?
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>)
tags in the <head> stanza at the top of the document and
ECMAScript (<script>)
tags at the bottom of the document. Browsers will not progressively
render a page until the stylesheet has been loaded and will block
while ECMAScript 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 are intrinsic to the device
and won't change (e.g. SVG support) 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 capabilties.
- 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 transient device capabilities 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 ECMAScript reflection to determine if a given API is active
and interrogate the device configuration using appropriate APIs.
Two methods can 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 intial "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 properites, 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 demoninator"
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 ECMAScript 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-ECMAScript version can sometimes be useful for simple
operations in low-bandwidth situations.
In some cases, however, the type of application simply has no
non-ECMAScript 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
ECMAScript 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.
[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)