- This version:
- http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080717
- 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-20080707
- 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 and amplify
upon general statements made in the Mobile Web Best Practices 1.0 (BP1),
especially concerning statements that relate to the exploitation of device
capabilities and awareness of the delivery context. Furthermore, since BP1
was written, networks and devices have continued to evolve, with the result
that a number of Best Practices that were omitted from BP1 can now be
included.
The recommendation is primarily directed at creators, maintainers and
operators of Web applications. Readers of this document are expected to be
familiar with the creation of Web sites, and to have a general familiarity
with the technologies involved, such as Web servers, HTTP, and Web
application technologies. Readers are not expected to have a background in
mobile-specific technologies.
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
1.6 Longevity and Versioning
2 Structure of Best Practice Statements
3 Best Practice Statements
3.1 Personalization
3.1.1 Retain Personalizing Information
3.1.2 Use Automated Means for Identifying the User and Obtaining Personalizing Information
3.2 Security and privacy
3.2.1 Protect Personal Information Used in Transactions
3.3 User awareness and control
3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use
3.3.2 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 for Content
3.4.2 Minimize Redirects in Server-Server API's
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 DOM Manipulation
3.4.7 Minimize External Resources
3.4.8 Use Power-Efficient Methods
3.5 One Web
3.5.1 Offer A Consistent View Across Multiple Devices
3.6 User Interface
3.6.1 Consider Different Device Interaction Methods
3.6.2 Use Scripting for User Interface
3.6.3 Don't Move the Focus on Updates
3.6.4 Group Closely Coupled Views onto the Same Page
3.6.5 Use hash URLs to Preserve Browser History and Enable Deep Links
3.6.6 Use URI Schemes for Device Functions
3.7 Handling Device Capability Variation
3.7.1 Use Device Capability Detection
3.7.2 Use Reliable Methods for Determining Script Support
3.7.3 Use Device Classification to Simplify Content Selection/Adaptation
3.7.4 Provide Alternatives to Client-Side Scripting
3.7.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS
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
List of Best Practices
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
- 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, such as Web servers, HTTP, and Web 2.0. Readers 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 and amplify on the recommendations of the
Mobile Web Best Practices (BP1). Where BP1 focussed primarily on the
extension of Web browsing to mobile devices, this document considers the
development of Web applications on mobile devices.
The approach in writing this document has been to collate and present the
most relevant engineering practices prevalent in the development community
today and identify those that: a) facilitate the exploitation of modern
device capabilities to enable a better user-experience; or b) are considered
harmful and can have non-obvious detrimental effects on the overall quality
of the application.
The goal of this document is not to invent or endorse future technologies.
However, there are a number of cases where explicitly omitting a Best
Practice that referred to an emerging technology on the grounds that it is
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 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).
These recommendations are complimentary to the recommendations of BP1.
This document builds on some of the concepts described by the Ubiquitous
Web applications (UWA) working group in 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.
Personalization can improve the user experience by minimizing the amount
of effort required to find relevant information. This is especially important
in the mobile environment where extra effort is necessary to interact with
applications.
3.1.1.1 What it means
If a service relies on user entered personalization information (e.g.
application preferences, personal details) that information should be
retained in order to avoid the need to re-enter it the next time a user
visits the site.
3.1.1.2 How to do it
Cookies are the most natural means to store small amounts of
personalization information. More extensive personalization should be stored
on the server in order to facilitate recovery if the cookies are lost,
sharing of state across multiple devices, and limiting the amount of data
traffic.
The following limitations should be considered when storing
personalization information inside a browser cookie:
- Cookies are not always available, they may not be supported by some
devices or they may be disabled. This situation can be detected both on
the server and in the client using javascript. In this case, the
personalization information can be stored on the server and a unique,
personalized URL (PURL) generated to identify the user. The application
UI should encourage the user to bookmark this URL so they can return to a
personalized experience the next time they visit the site.
- Information stored in cookies is typically sent to the server with each
request, potentially increasing the amount of data traffic. Limit the
amount of data stored in cookies, and limit the scope of cookies to an
appropriate subdomain so that they are not sent unnecessarily (e.g. when
requesting static resources).
- Cookies are only accessible to the client that created them and cannot
be used to share state across multiple devices. Any personalizing
information that has relevance beyond the device that created it should
be stored on the server so it can be readily shared by other clients.
- Cookies are readily deleted. An application must not rely on their
presence in order to function correctly. Limit the amount of data stored
in cookies by storing more significant personalization information on the
server in order to limit the cost to the user of this information being
inadvertently lost.
3.1.2.1 What it means
Ensure that personalization information is available to the user with
minimal effort.
3.1.2.2 How to do it
The simplest way to do this is to associate personalization information
with a given user identity and obtain their login credentials directly on
first access. Recommended methods for doing this include:
User login credentials should not be stored directly on the device because
this is insecure, but a securely hashed token can be used to enable automatic
login the next time a user visits your 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,
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.
3.2.1.1 What it means
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.
3.2.1.2 How to do it
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.
The Working Group is interested in receiving feedback
on techniques for securing personal data on mobile devices, and the relative
impacts of using HTTPS and other techniques.
Ensure that the user is aware of application behaviors that might affect
the overall service experience, and that the user is offered options to
control those behaviors.
Many browsers support the ability to make background server requests
without requiring a page refresh. 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)
The use of such personal information and device functions can expose the
user to privacy and security concerns.
The overall goal is that the user is informed of such activities, given
effective means to control them, and also the opportunity to opt-out of
application/function use.
3.3.1.1 What it means
Whenever an application makes background data requests, whether automatic
or user initiated, this should be indicated to the user in an appropriate
manner so the user is not surprised by unexpected data-charges, etc.
Means should be provided to disable any automatic network activity.
3.3.1.2 How to do it
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 log-in, or in associated help
pages.
If an application makes automatic network requests (e.g. to poll the
server for updates or to automatically store an updated client state) a
control should be provided to easily disable / re-enable this activity.
Endeavor to keep the application as functional as possible even if automatic
network activity is disabled.
3.3.2.1 What it means
Ensure that the user is informed when the application accesses personal or
device information. Applications should be defensive and remain as functional
as possible if the API request for personal or device information is
denied.
3.3.2.2 How to do it
In many cases APIs that provide access to personal or device information
deliver a native confirmation dialogue to the user before providing access to
the data. In this case the application should not force the user to confirm
again at the application level, but should make clear in the UI that
displayed data has been accessed from the device.
If the user declines a prompt to allow application access to personal or
device information, the application must recover gracefully. For example, if
a request to a device API fails, do not automatically retry if this might
lead to the user being presented with repeated confirmation dialogues by the
underlying API.
Resources and network bandwidth are significantly more limited on mobile
devices than on a desktop device. As a result, Web applications should use
device and network resources conservatively.
3.4.1.1 What it means
Compress content for efficiency in delivery.
3.4.1.2 How to do it
HTTP 1.1 compression, which typically uses gzip or deflate as algorithms,
is a widely (though not universally) supported method of transfer encoding
for delivery optimization. To use HTTP compression, Web servers should be
configured to serve Web pages using HTTP 1.1 compression (gzip or deflate),
according to the coding supported by the device as indicated by the HTTP
Accept-Encoding header.
Note that the processing 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.2.1 What it means
Request redirection (e.g. through HTTP or meta refresh methods) is a
typical method for a service to automatically obtain information from a
different server (e.g. account authentication). Such redirect based API's are
common in Web applications, and play an useful role in automated
personalization. However, 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.
3.4.2.2 How to do it
A typical redirect sequence should require no more than two automated
redirects, e.g. one to redirect to the information-providing server, and
another to redirect back to the service-providing server.
If further redirects are required, it's possible to use a landing page to
break up the sequence. However, it's important to balance the desire to add
landing pages in order to improve the perceived latency of the application,
against the cost of needlessly interrupting the user
flow.
3.4.3.1 What it means
Applications that automatically issue network requests should provide
value for those requests. The "value" in this case should be determined by
the application developer based upon the type of service the application
provides, and the resulting direct value to the user.
3.4.3.2 How to do it
Consider the following issues when designing application:
- Batching requests: A single request for more data is much more
efficient than several smaller requests. Wherever possible batch up
multiple server requests.
- Backoff during periods of inactivity: If the application polls for
updates, it should monitor user-activity and poll less frequently if the
user is inactive.
- Consider contextual factors: If possible, use awareness of the current
connectivity (e.g. WiFi) and roaming status, to select an appropriate
level of interaction. As a fallback, ensure that server requests are
visible to the user and controllable. (See 3.3.1 Inform the User About Automatic
Network Access and Provide Control Over its Use)
3.4.4.1 What it means
Network-initiated content delivery ("push") methods can significantly
reduce network traffic overhead, as compared to conventional polling
(scheduled "pull") methods.
3.4.4.2 How to do it
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
- Alternative vendor-specific initiatives.
3.4.5.1 What it means
This section elaborates on the best practices of BP1 [section ref].
Ensure that the Web application size is optimized in order to minimize the
impact of operating on a limited bandwidth network.
3.4.5.2 How to do it
Various techniques can be used to minimize application size:
- Process HTML and CSS files at build time to remove whitespace. Several
Open Source whitespace strippers are available [REF] ?
- Process script files at build time to remove whitespace and compile the
script. Several Open Source javascript compilers are available, for
example: http://developer.yahoo.com/yui/compressor/
3.4.6.1 What it means
On small devices with limited processing capability, the cost of excessive
DOM manipulation can significantly impact application performance.
3.4.6.2 How to do it
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.7.1 What it means
This section elaborates on the best practices of BP1 [section ref].
Web applications typically require multiple resource (e.g. stylesheets,
scripts, images). On a mobile network, however, the overhead of making
additional HTTP requests is high and can significantly impact service
latency. Steps should be taken to minimize the number of requests made by the
application.
3.4.7.2 How to do it
The following steps can be taken to reduce network requests:
- For small stylesheets or script files it may be more efficient to
inline them rather than making a separate request for each one. The
downside in this case is that inlined resources can't be cached, but for
small files (<XX K) the overhead of the additional
request outweighs the potential benefit of caching the resource.
- Multiple stylesheets and script should be combined together.
- Background images often used to improve presentation can be inlined in
the css file as base64 strings using the url("data:...") construct.
- If the application contains multiple icons these should be combined
into a single image and then rendered as separate icons in the
application using css clipping.
3.4.8.1 What it means
As mobile Web applications become increasingly ubiquitous they are more
likely to be required to run for long periods of time or be on in the
background (e.g. an email application or an IM client). In these
circumstances, the application's impact on battery life should be considered.
3.4.8.2 How to do it
The working group is currently investigating the
relative impacts of Web application activities on battery life in order to
make more concrete recommendations.
The term "One Web" encapsulates two aspects of mobile Web application
development:
- Thematic consistency between desktop and mobile devices. See BP1 [ REF
]
- Application consistency across multiple devices.
3.5.1.1 What it means
Multiple devices may be used to access a Web application with the same
user credentials (e.g. a user may own multiple mobile devices or may access
the same application from both mobile and desktop devices). Application
consistency should be maintained across different consuming devices.
3.5.1.2 How to do it
The most common cause of failing to offer a consistent application state
across multiple consumers is to store too much information on the device
(either in cookies or a local device database). To avoid this, use device
based storage carefully and avoid storing personalization data on the device
that would still be relevant if the application were accessed from a
different consumer. See 3.3.1 Inform the User
About Automatic Network Access and Provide Control Over its Use
The Working Group is investigating a number of
additional recommendations for this section and is looking for suggestions in
this area.
Given the difficulties and complexities of interacting with an application
on a mobile device, special consideration should be given to the user
interface in order to maintain a good level of usability.
3.6.1 Consider Different Device Interaction Methods
3.6.1.1 What it means
Interaction methods vary across different devices. Three main interaction
methods should be considered:
Focus Based
This is the traditional mobile browser interface and is analogous to
navigating with tabs on a desktop browser. As the user navigates through the
page using the keypad the browser focus jumps from link to link, in more
advanced devices there is 4-way navigation so a user can control the flow
more easily.
Pointer based
Many of the more recent browsers have implemented a navigation influenced
by desktop browsers. Using the navigation controls a pointer across the
screen. Unlike the focus based devices the pointer can cover all aspects of
the screen, not just links.
Touch based
Touch based devices allow the user to select links or other page elements
directly with a finger or stylus. There is no concept of a pointer or
focus.
3.6.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
- Selectable elements can be widely spaced as the user can select them
easily by jumping from link to link
- The location of the user can be easily determined using as link
elements will be in focus
- Normally only link elements will be in focus
Pointer
- Selectable elements that are associated need to be near each other as
scrolling the pointer can be slow
- The location of the user can be easily determined using as link
elements will be in focus
- All page elements can be scrolled over and so maybe in focus
Touch
- Selectable elements can be widely space as the user can select them
easily
- No elements are in focus until they are selected so information cannot
be passed to the user (e.g. rollovers will not work).
3.6.2.1 What it means
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
on a device, this greatly improves application usability.
3.6.2.2 How to do it
Script on the client can update specified parts of the page, identified
either by the ID tag, the css classname, or from the document structure. The
content of these tags can then be updated, and new nodes in the DOM can be
created and destroyed.
3.6.3.1 What it means
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. It can
also make an application unusable, if the focus changes prevent the user from
using other parts of the application.
3.6.3.2 How to do it
Use the ECMAScript focus method only if it is essential to the use of the
application, and does not inhibit user control/interaction.
3.6.4 Group Closely Coupled Views onto the Same Page
3.6.4.1 What it means
Most applications consist of a number of views (e.g. an email application
consists of an inbox and the message detail view). User experience is
improved if switching between these views does not require a full page
reload.
3.6.4.2 How to do it
Each view can be rendered in a DIV element which is hidden using css.
Script can be used to show and hide the relevant views and their content
updated with a background server request.
3.6.5 Use hash URLs to Preserve Browser History and Enable Deep Links
3.6.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.6.5.2 How to do it
Script can be used to update the browser URL and append a "hash" part to
the URL. A hashed section of the URL is a standard mechanism for defining
different views within an application. For example, an email application may
support and respect URLs of this form:
- http://www.myapp.com/myapp#inbox
- http://www.myapp.com/myapp#compose
- http://www.myapp.com/myapp#read;id=XXXXX
3.6.6.1 What it means
Standardized URI schemes (link formats) have been defined for some common
device functions, e.g. making phone calls and managing phone address books.
These URI schemes, if supported, can enable users to easily use these
functions from Web applications.
3.6.6.2 How to do it
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.
RFC3966 defines the "tel:" URI scheme for making
phone calls. "tel:" is widely supported, since it is not a supported
attribute in UAProf, support must be determined from
the device vendor.
NOTE: This section is too detailed and requires
significant editing. The Working Group is still evaluating the appropriate
recommendations for this section and is interested in receiving
feedback.
Device capability variation is a basic characteristic of the mobile Web
environment. Web applications should adapt their content such that they
render in an optimum way on as broad a range of target devices as
possible.
3.7.1.1 What it means
For some of the best practices included here, support is dependent upon
application awareness of related device capabilities. At the current time,
this awareness is limited to application server use of device capabilities
information provided by the user-agent directly, or obtained from a Device
Description Repository (DDR) based upon device identification, e.g. based
upon the user-agent header.
3.7.1.2 How to do it
Typically used methods of device capabilities detection:
- The "user-agent" header can be used to identify the device and/or
user-agent, with detailed device capabilities then retrieved from a
DDR.
- The "accept" header can be used to indicate specific MIME types
compatible-to/preferred-by the user-agent.
- 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.
- Retained information about the current/last used device for the
specific user, can be used when preparing content for delivery to the
user-agent at a later time.
The type of information used will depend upon the way in which the request
was received, and the support for the methods, e.g. headers, by specific
user-agents. For example:
- for requests received directly from the user-agent, based upon
information from the user-agent directly or forwarded by
intermediaries
- for requests received from other intermediaries, information as
available from the intermediary, e.g.
- for SMS-interworking gateways, the user's phone number
3.7.2.1 What it means
It can be tricky to determine the supported script capabilities for a
device. Use of reliable methods is recommended.
3.7.2.2 How to do it
When it is unknown whether a user-agent supports a given functionality,
use Javascript reflection to check for available functionalities. This avoids
the error-prone approach of trying to parse the user-agent string to
determine Javascript support. An example of how to use Javascript
reflection:
Use Javascript Reflection and if statements
+ if(window.ActiveXObject) {
// Instantiate using new ActiveXObject } else if(window.XMLHttpRequest)
{
// Instantiate using new XMHttpRequest }
3.7.3.1 What it means
It can be complex to select and adapt content based upon dynamic
assessment of device capabilities. A commonly used alternate approach
involves off-line assessment of devices with resulting assignment into
"classes", e.g. "good", "better", "best". The definitions of the classes, and
device assignment to classes, is typically Content Provider specific, i.e.
based upon assessments specific to the needs of the Content Provider.
3.7.3.2 How to do it
Adapting Web application content and services to mobile devices may be
simplified by assigning devices and user-agents (e.g. browsers or other Web
applications as identified by the HTTP user-agent header, or other
information) to "classes". The "richness" of the Web application as provided
can then be more easily matched to the broad range of capabilities
represented by the device class.
Device classification is partly subjective and partly objective. The
aspects that affect the classification will vary depending upon the focus of
the Web application, and the device/user-agent features it depends upon. Some
example classes for web browsers may include:
- "Good": Serve these devices very basic pages. These devices are
typically WAP1 or WML-only handsets with black and white screens.
Ringtones are supported, but MIDP applications, wallpapers, and scripted
applications are not. "Good" devices also include such color-screen WML
phones on which pictures can be presented through the browser, and
javascript applications can be emulated by web servers. Some devices in
this category may claim xHTML support, but have slow processors, or the
supported xHTML is incomplete.
- "Better": These devices have solid xHTML support with color screens,
and support MIDP, graphics, and ringtones. However they do not support
scripted applications.
- "Best": The "best" device category includes features from the "better"
category plus streaming video capabilities, UMTS/HSDPA, and special audio
clients. Scripted applications may be supported, but script support
likely requires verification before use.
Once the device/user-agent is identified, the assigned class can be
obtained from the DDR used by the Content Provider, and content then provided
consistent with the assigned class.
3.7.4.1 What it means
Scripted applications, e.g. using asynchronous I/O methods or
ECMAScript/Javascript in general, may not be supported by some browsers.
Pages designed to use scripting will require alternate approaches in browsers
that do not support scripting, so you should be prepared for that and provide
similar functionality in case scripting is not available.
3.7.4.2 How to do it
Detect browser capabilities or user preferences, and react accordingly
with graceful degradation or progressive enhancement of
Javascript/ECMAScript.
- Design targeting purely desktop/laptop audiences (where
media="screen") tends to be structured to degrade gracefully if
ECMAScript/Javascript is not present or if advanced capabilities like
asynchronous I/O (and other "AJAX" techniques) are not supported.
Design targeting a mixed audience of mobile (where media="handheld")
and desktop/laptop users should be structured to both degrade
gracefully (if ECMAScript/Javascript is not present) and likewise to
progressively enhance page- and user-behavior capabilities (if
ECMAScript/Javascript does turn out to be present).
Separate behavior from content and presentation, for graceful degradation
and progressive enhancement.
- Good logical design separates XHTML content (the "data model"), CSS
presentation (the "view"), and ECMAScript/Javascript behavior (the
"controller"). Designers targeting purely desktop/laptop audiences
(where media="screen") tend to duplicate this in the physical site
structure, placing each in its own file and having pages issue an HTTP
request for each separately through use of the <link/> or
<script/> tags. Designers targeting purely mobile (where
media="handheld") audiences tend to interleave the three concerns into
one physical payload/file delivered to the client in order to reduce
per-request charges.
- Designers targeting a mixed audience of mobile and desktop/laptop
users can build Web pages which load sufficient ECMAScript/Javascript
(in the <head/> element) to determine device display and
interaction capabilities when first loaded. This allows for progressive
enhancement, just as good structural design of XHTML allows for
graceful degradation.
- Techniques similar to progressive enhancement of CSS (see 5.9.5) may
also be used to inject event-handling Javascript/ECMAScript code into
files at request-time and to attach Javascript/ECMAScript behaviors at
run-time for progressive enhancement. In the example below, page-scope
variables and functions are declared in a <script/> element in
the <head/> while run-time test code for progressive enhancement
is declared in a <script/> element in the <body/> element
(to allow the DOM to be loaded before the code runs):
[NOTE to WG: see
http://chw.rit.edu/test/progressiveEnhancement.html for complete code as
running example]
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
"http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
<meta http-equiv="content-type"
content="application/vnd.wap.xhtml+xml; charset=utf-8" />
<meta http-equiv="cache-control" content="no-cache" />
<title>Javascript Insertion Test</title>
<style type="text/css" media="all">
/* <![CDATA[ */
#testMe {
border: thin solid red;
}
/* ]]> */
</style>
<script type="text/javascript" charset="utf-8">
// <![CDATA[
var someVariable;
var triggerTest = 480;
function actualValue() {
[...]
return someRuntimeValue;
}
function setSomeVariable( newValue ) {
[...]
}
// ]]>
</script>
</head>
<body>
<p id="testMe">
Please click on this area to test this scripting example.
</p>
<script type="text/javascript" charset="utf-8">
// <![CDATA[
function thisFunction() {
[do something, possibly using someVariable] } if( actualValue() >= triggerTest ) {
setSomeVariable( 'some new value' );
document.getElementById( targetID ).onclick = thisFunction;
}
// ]]>
</script>
</body>
</html>
3.7.5.1 What it means
CSS may be incompletely supported by some browsers. Pages using
positioning and visibility control are not supported by some browsers.
Site design to support both desktop/laptop users and mobile device users
will require alternate approaches for browsers that do not support
positioning and visibility control. You should provide for both graceful
degradation (in the case of no or minimal CSS support) and progressive
enhancement (in the case of full positioning and visibility control support)
of CSS by the client at run-time.
3.7.5.2 How to do it
Detect browser capabilities or user preferences and react accordingly.
- Design targeting purely desktop/laptop audiences (where
media="screen") tends to be structured to degrade gracefully: first if
ECMAScript/Javascript is not present, and then if CSS is not supported.
Design targeting a mixed audience of mobile (where media="handheld")
and desktop/laptop users should be structured to also progressively
enhance CSS. Advanced CSS capabilities should be separated from basic
CSS, and inserted into the DOM by the client as appropriate at
run-time.
Separate behavior from content and presentation, for graceful degradation
and progressive enhancement.
- Designers targeting a mixed audience of mobile and desktop/laptop
users can build Web pages which load (using the <style/> tag in
the <head> element) CSS for mobile audiences and (using the
<script/> tag in the <head> element) sufficient
ECMAScript/Javascript to determine device display and interaction
capabilities first. This allows for progressive enhancement, just as
good structural design of XHTML allows for graceful degradation.
The following example code illustrates a possible request-time payload
aimed at a mixed mobile and desktop/laptop audience. In this case, if
ECMAScript/ Javascript is present and if the screen-width is determined to
exceed a minimum, then the display device is assumed to be a desktop/laptop
(where per-download charges are unlikely to apply), an additional stylesheet
is requested, and ithe new stylesheet is inserted into the DOM:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
"http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
<meta http-equiv="content-type"
content="application/vnd.wap.xhtml+xml; charset=utf-8" />
<meta http-equiv="cache-control" content="no-cache" />
<title>Example Payload for Progressive Enhancement</title>
<style type="text/css" media="all">
/*
<![CDATA[ */
[put initial CSS here]
/* ]]>
*/
</style>
<script type="text/javascript" charset="utf-8">
// <![CDATA[
var triggerWidth = 480;
function appendStylesheet( uriString, mediaTypeTarget ) {
[inject stylesheet into DOM here]
}
function getViewportWidth() {
[determine viewportWidth here] }
function adaptToScreen( uriString ) {
if ( getViewportWidth() >= triggerWidth ) {
appendStylesheet( uriString, 'screen' );
}
}
// ]]>
</script>
</head>
<body onload="adaptToScreen( './stylesheets/bigScreen.css' );">
[...]
In the above case, the base-CSS for mobile users is delivered along with
ECMAScript/Javascript to determine client capabilities as a result of the
initial request. Subsequent requests for CSS (and possibly other resources)
allow for progressive enhancement where determined appropriate by client-side
code.
Good physical design can take advantage of just-in-time technologies like
"server-side includes" to assemble the above payload on demand, resulting in
the <style/> and <script/> nodes being inserted at request-time.
The following code in an HTML file would cause the server to insert (as
above) site-wide <style/> and <script/> nodes at request-time in
the payload actually being delivered at response-time:
[... replace style and script elements with:]
<style type="text/css" media="all">
/*
<![CDATA[ */
<!--#include virtual="./stylesheets/content.css" -->
<!--#include virtual="./stylesheets/tabNav.css" -->
/* ]]>
*/
</style>
<script type="text/javascript" charset="utf-8">
// <![CDATA[
<!--#include virtual="./javascripts/appendStylesheet.js" -->
// ]]>
</script>
[...]
Separating logical and physical design like this helps reduce site-wide
maintenance costs and site-redesign difficulties as well as supporting
graceful degradation and progressive enhancement of CSS.
[To include the set of minimum device properties supporting
specific best practices.]
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.
D.1 MWI References
to be added
D.2 Sources
to be added
D.3 Device Independence
- XML
- Delivery Context: Client Interfaces (DCCI) 1.0, W3C Candidate
Recommendation 21 December 2007 (See http://www.w3.org/TR/DPF/)
D.4 Web, Protocols and Languages
- 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)
D.5 Other References
- 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)