Copyright 2008 W3C ( MIT, ERCIM, Keio ), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to enable development and delivery of great Web applications on mobile devices. "Great Web applications" means that users find true value in use of the applications, and simply enjoy using them even given the constrained mobile context. The recommendations expand and amplify upon general statements made in the Mobile Web Best Practices 1.0 (BP1), especially statements that relate to exploitation of device capabilities and awareness of the delivery context. Further, since BP1, networks and devices have continued to evolve and improve, with the result that some things can now be recommended as Best Practices, which did not qualify as Best Practices in BP1.
The recommendations refer to Web applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.
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 2.0 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) through . 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.
The following Best Practices are discussed in this document and listed here for convenience.
[AUTOMATE_PERSONALIZATION] Use Automated Means for Obtaining Personalizing Information
[RETAIN_PERSONALIZATION] Retain Personalizing Information
[PROTECT_PERSONAL_INFO] Protect Personal Information Used in Transactions
[DISCLOSE_AUTOMATION] Inform the User About Automatic Use of Networks
[DISCLOSE_PERSONAL_INFO_USE] Inform the User About Use of Personal Information
[PROVIDE_EFFECTIVE_DISCLOSES] Provide Disclosures that are Timely and Accessible
[PROVIDE_USER_CONTROL] Provide Control over Application Behavior
[RECOVER_COOKIES] Automatically Recover Cookie-Based Information
[MINIMIZE_REDIRECT] Minimize Redirects in Server-Server API's
[USE_CONTENT_COMPRESSION] Use Transfer Compression for Content
[MINIMIZE_AUTOMATIC_REQUESTS] Minimize Automatically Issued Network Requests
[USE_PUSH_METHODS] Use Push Methods to Reduce Pull Traffic
[MINIMIZE_APPLICATION_SIZE] Minimize Application Size
[MINIMIZE_DOM_MANIPULATION] Minimize DOM Manipulation
[MINIMIZE_EXTERNAL_SCRIPTS] Minimize External Script Files
[USE_POWER_EFFICIENT_METHODS] Use Power-Efficient Methods
[SYNC_VIEW_ACROSS_DEVICES] Offer Synchronized View for Multi-Device Capable Applications
[USE_SCRIPTING_FOR_UI] Use Scripting for User Interface
[RETAIN_FOCUS_ON_UPDATES] Don't Move the Focus on Updates
[USE_DEVICE_URI_SCHEMES] Use URI Schemes for Device Functions
[DETECT_DEVICE_CAPABILITIES] Use Device Capability Detection
[DETECT_SCRIPT_SUPPORT] Use Reliable Methods for Determining Script Support
[CLASSIFY_DEVICES] Use Device Classification to Simplify Content Selection/Adaptation
[MATCH_SCRIPTING_SUPPORT] Provide Alternatives to Client-Side Scripting
[MATCH_CSS_SUPPORT] Provide for Both Graceful Degradation & Progressive Enhancement of CSS
This document sets out a series of recommendations designed to enable development and delivery of great Web applications on mobile devices.
The recommendations are offered to creators, maintainers and operators of Web applications.
The document is organized as follows:
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.
Our intention is to make it 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 of our 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 (MWABP) follow in the footsteps of the Mobile Web Best Practices (BP1), for which the scope was laid out in "Scope of Mobile Web Best Practices" [Scope]. Where BP1 referred primarily to the extension of web browsing onto mobile devices, this document further extends that scope to consider the use of web-applications on mobile devices.
This document sets out a series of best practices that are intended to help content creators develop and deliver great web applications in the mobile context.
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 an optimal user-experience for mobile web-applications; or b) are considered harmful and can have non-obvious detrimental effects on the overall quality of your mobile web-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 and considered to have a positive impact on the overall quality of your web-application) 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.
It should be noted that there are a number of emerging mobile technologies that allow web-applications to be delivered in a more componentized or gadget-like way, outside of a traditional browser [REFERENCES TO WEBLETS, ETC]. Whilst many of the recommendations in this document remain relevant in these contexts, no explicit effort has been made to adapt them for this scenario on the grounds that there are as yet no convergent technologies or practices for non-browser based web-applications. As such, the reader should remain mindful of potential divergences from these recommendations when dealing with web-applications delivered outside of a browser.
In an increasingly mobilised 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).
Note that additional weight has been placed on those aspects of the mobile context that are believed to be intrinsic and likely not to change in the near future (e.g. limited input capabilities) as opposed to those that are likely to disappear quickly as the technology evolves (e.g. limited device processing capability).
As discussed in the Scope document [Scope] there are many aspects to Mobile Web Best Practices. MWABP represents the second phase of the Best Practices development, i.e. beyond "Traditional Web Browsing".
The MWABP is not intended as a landscape document, e.g. a general survey of technologies and related issues in the mobile context. Recommendations are included here if they meet specific criteria:
These recommendations follow in the footsteps of the 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].
The Best Practices have been written at a level of generality that allows them to be applicable across a range of Web technologies. They have been written with mobile user experience aspects in mind, which over time will change, but should remain relevant as technology evolves.
This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.
This section discusses the requirements of the Mobile Web Best Practice statements in section 4. The statement of requirements is intended to be illustrative rather than exhaustive or complete.
The functional area that is addressed by the statements.
One or more Best Practice statements, identified in the following way:
[EXAMPLE] This is a Best Practice statement.
An explanation of the significance of the statements under this heading.
A discussion of techniques and some suggestions as to how to implement.
Where appropriate, references to related WCAG points and other immediate references from the preceding text.
Personalization increases the value of content and services to users, which is important in the mobile environment due to the extra effort necessary to find relevant content, interact with applications, and the limited output possible in mobile devices. In the PC environment, users have a variety of useful/easy input methods and controls making it easier to input personalizing information and surf to the content they want, and can more easily scan a large amount of content for the bits that are relevant to them. In the mobile environment, each of these aspects are more limited, and thus more difficult to address. This increases the value of seeking ways to provide easier personalization, and to retain personalizing information once it is acquired.
Personalized services are enabled by Content Provider awareness of personalizing information, e.g. user identity, preferences, and delivery context characteristics. Personalized services should be capable of using automated means of obtaining such personalizing information, when available, in order to reduce user effort in obtaining the personalized service.
Service Providers (e.g. Mobile Network Operators or Web Portal Providers) or Identity Management Providers may provide means for Content Providers to access trusted user identities. This both avoids the need for users to manually enter their identity, or significantly reduce the frequency of manual entry. The result is an automated personalization experience, which results in much easier-to-use Web applications. If offered, Service Providers usually provide details on use of Identity Management and Single Sign-On (SSO) services through their Developer or Content Provider programs, or through participation in industry initiatives (e.g. OpenID). Of importance here is the trust in the identity as provided, e.g. as described in 4.2.1 Protect Personal Information Used in Transactions, but when available and trusted, such SSO capabilities can significantly improve the user experience.
Content Providers can also use information, e.g. user credentials, which is provided directly by the user on a first access, and then automatically provided by the user-agent on subsequent accesses. Recommended methods for this include:
Other user information and delivery context characteristics may be used to provide a more personalized experience, e.g.
As device API's that will enable Web applications access to these types of functions are being developed in a variety of standards activities and vendor-specific initiatives, they may be available to the Web application.
Personalized services that rely upon user entry of information should retain that information to avoid the need to re-enter it upon each site access or use session, especially given the difficulty of doing so through mobile devices. Users are likely to quit using services that ask for the same information often.
Information retention is possible by using cookies, as hidden information in content (e.g. forms, URL parameters, Javascript variables), in server-side databases, etc. The duration of retention should be matched to the type of application and typical user session profile, e.g. how often users typically access the application and how long they interact with it during each use.
Related to the more frequent use of personal information by mobile Web applications is the need to secure that information from eavesdropping or tampering when exchanged over the Internet. In order to ensure privacy and information accuracy you should only used trusted information, and protect any personally identifiable information, especially user identifiers or keys to user identity. While the need to protect personal information is not unique to the mobile environment, due to the typical resource limitations of mobile devices and mobile networks, developers should carefully weigh the impact of information security methods (e.g. use of secure HTTP), and consider more efficient design alternatives where appropriate. The overall goal for security is to use efficient methods to protect any personally identifiable information, and especially user identifiers or keys to user identity.
Personally identifiable information (e.g. user identity or information usable as a key to user identity) should only be accepted or sent securely. This will ensure the confidentiality and integrity of the information. Information is personally identifiable if it is by itself directly related to an individual, e.g. a user's public identity such as name or phone number, or can be correlated to an individual by being exchanged along with other personally identifying information.
Unless a user identity is provided by the user over a secure connection, or from a tusted third party (e.g. a Service Provider or Identity Management / SSO Provider as described in 4.1.1 Use Automated Means for Obtaining Personalizing Information), Content Providers should not trust its use for delivery of personal information. Content Providers should consult the documentation provided by the Service Provider for details on how to access trusted user identities.
When they are provided by the user or user-agent, user identities should only be exchanged between user-agent and content server using secure methods (e.g. HTTPS), or as securely hashed information (e.g. included as URL parameters, POST data, or cookies). 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.
Since information is not personally identifiable unless it can be associated with an individual, e.g. a zip code which is by itself not personally identifiable, such information can be exchanged in the clear if the correlating information is itself secure, e.g. as a securely hashed identifier. As long as an application meets the basic objective that user identities are protected during exchange, other information can be exchanged in the clear.
Applications should ensure the user is aware of application behaviors that may affect the overall service experience, and that the user is offered options for control over the behaviors. For example, while it can significantly simplify the user experience, frequent data exchange with servers can significantly impact service cost and battery life.
Device API's that are available to Web applications are being developed in a variety of standards activities and vendor-specific initiatives, e.g. for:
Such API's are likely to be available in devices in the near term. 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 potentially experience-affecting functions, and given effective means to control them, or the opportunity to opt-out of application/function use.
Users should be informed if applications will make automatic data requests that can impact service cost, and should be given information that will help the user assess the significance of that impact. While the significance ultimately may depend upon information that only the user knows (e.g. their data service plan), having such notices up-front can avoid unexpected negative side-effects, e.g. significant usage charges or effect upon battery life.
Applications should disclose, in a clear and useful way, the basic nature of their automatic use of the Internet for data exchange, e.g.:
While use of personal or contextual information can enhance service effectiveness, applications should ensure that the user is aware of such information use and exchange.
The following information should be disclosed:
Disclosures about application behavior are useful (i.e. result in user awareness of the implications of using an application) only if they are provided at a useful time and in useful ways.
Disclosures should be provided during application selection/loading or first use of sensitive functions.
Disclosures should be automatically provided e.g. as a user dialog, or easily accessible to the user e.g. via an "about this application" menu option.
In BP1, HTTP cookies and redirection were recommended to "not be relied upon" due to constraints of limited-capability mobile browsers and slower mobile networks. MWABP however recognizes that cookies are widely supported by current mobile browsers, and mobile network speeds have considerably increased since BP1. Thus while the BP1 recommendations are still useful to consider when the delivery context can't be determined, MWABP focuses on use of HTTP cookies and redirection for capable browsers and mobile networks.
MWABP clarifies how HTTP cookies and redirection can fulfill useful purposes in the mobile context. Cookies support statefulness and personalization in browsers, two considerations which can simplify the user experience and add value to content and services. Redirect supports server-server interaction via the browser, which is often essential for distributed services which rely upon partitioning of service functions across different servers, or for automated Identity Management / SSO. The restrictions recommended in BP1 prevented these application design approaches from being leveraged for mobile Web applications. However MWABP recognizes that since BP1, both web clients (e.g. browsers) and networks have evolved considerably in capability.
As compared to their use for web browser applications, cookies and redirect may play less of a role in maintaining statefulness and personalization for non-browser Web applications. Application-specific methods may be used, and may include use of more advanced technologies that are not available to some browsers, e.g. persistent storage. However, support for statefulness and personalization will still need to consider similar issues, e.g. state preservation/recovery and traffic overhead. As well, distributed services may still rely upon redirect for Web applications.
The overall goal is to set reasonable expectations on the impact for use of cookies and redirect in service delivery to browsers and Web applications, and to address alternatives for maintaining statefulness and personalization.
Unless a sensitive application behavior is essential to the application, users should be given the option to control the behavior. If the behavior is essential to the application, users should be given the option to opt-out of application use.
Users should be given easy-to-use controls to personalize application behavior, e.g.
If user control over sensitive application functions is not provided, users should be given the chance to opt-out for the function, or to terminate the application.
User control preferences should be saved by the application to avoid the need to reenter them each time the application is used.
Cookies may play an essential role in application design. However since they may be lost, applications should be prepared to recover the cookie-based information when necessary. If possible, the recovery should use automated means, so the user does not have to re-enter information.
Server databases can be used to store user information with persistence longer than typical session or cookie lifetime. Applications can be designed to recognize loss of cookie information, and direct the user or user-agent to a resource through which the information can be recovered from a database server. After recovery, the user or user-agent may be directed to a server which then provides service based upon the restored cookie information. These methods can increase information persistence, while limiting database server expense.
Request redirection (e.g. through HTTP or meta refresh methods) is a typical method for a service to automatically obtain necessary information from a different server. Such redirect based API's are very common in Web applications, and play an useful role in automated personalization for mobile Web applications, e.g. to avoid manual information entry. However latency, efficiency, and interoperability considerations benefit from minimizing the number of automated redirects in a sequence, for this purpose.
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, e.g. to a second information-providing server based upon the information obtained from the first information-providing server, a landing page can be used to break up the overall sequence, into two automated redirect sequences with a user "continue" click in the middle. This has the effect of reducing the apparent latency for the user, but should be balanced against the need for an extra user action, as four redirects in sequence (when necessary) are rarely an interoperability issue.
Web applications can have a significant impact upon the limited resources of mobile devices, and the cost of service in mobile networks. As a result, Web applications should use device and network resources conservatively.
The amount of network traffic that Web applications generate can have a very significant impact on service cost, especially for applications that autonomously interact with network-based services. These costs can be borne by the user and/or network service provider. Users with usage-based service plans can find themselves responsible for huge charges. Network service providers can bear these costs for users that subscribe to "bucket" or unlimited service plans, and as a result may only recommend or support efficient applications for use with such plans.
Web applications can also significantly affect the typically-limited battery life of mobile devices, e.g. through network traffic, screen updates, and processor/memory-intensive operations.
Compress content for efficiency in delivery. Balance use of compression with the potential cost, e.g. to battery life for compress/uncompress operation. Use techniques if possible that are more efficient, e.g. tokenization.
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, and is most useful for text-based content e.g. markup languages and documents. HTTP compression is used for transport efficiency, and can significantly reduce the data usage and transfer time for web pages. 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 user-agent as indicated by the HTTP Accept-Encoding header.
Application compression, as compared to transport compression, involves the optimization of the content as stored and used by the user-agent. For examplem, while HTTP compressed content is usually uncompressed before being put into a browser cache, application compressed content may be stored in the optimized form. Application compression techniques can include simple optimization of application size (e.g. only send essential content), or application tokenization. Tokenization techniques that may be supported include:
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. Be mindful that background polling of servers on a mobile device can cause costly data usage and drain the battery. For applications that automatically issue network requests, e.g. dynamically updating applications built using AJAX methods and XMLHttpRequest in particular, managing data usage should be a key consideration.
Overall data usage effectiveness can be improved by:
Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods. While scheduled pull is a useful method for content that is regularly published, e.g. news/traffic/weather etc., some service types such as messaging/social-networking and "breaking news" monitoring can greatly benefit from use of push methods in terms of overall traffic effectiveness and timely content delivery.
Push method support may be disclosed through a User Agent Profile document if published by the device vendor, and may be known through other means e.g. a DDR.
If supported by the user-agent, options for Push methods include:
This section elaborates on the best practices of BP1 [section ref].
Developers sometimes don't consider the impact of the size of their application content, e.g. web pages, on mobile browsers. Recognizing that you are developing for a mobile Web application, and using effective techniques for minimizing the overall application size, will improve the user experience for mobile Web applications.
Optimize use of CSS, e.g. avoid overuse of nested css classes that can bloat repeated blocks of content. Instead, make good use of selectors to minimize the size of repeated blocks of HTML. Bear in mind that css is easier to cache than generated HTML pages. For example, this...
style.css .contact > div { float:left; } .contact > div > img { border:1px solid #ccc; padding: 3px; } .contact > ul { padding-top:3px; } .contact > ul > li { font-weight:bold; } .contact > ul > li:first-child + li { color:#777; font-weight:normal; } content.html <li class="contact"> <div><img src="#" alt=""></div> <ul><li>name</li><li>status</li><li>address</li></ul> </li>
Is much more compact than this... (if the element of HTML content is some repeated block, e.g. contact, stock entry, orders, etc)
style.css .thumbnail { float:left } .mountedimage { border:1px solid #ccc; padding:3px; } .details { padding-top:3px; } .name { font-weight:bold; } .status { color:#777; } .address { font-weight:bold; } content.html <li> <div class="thumbnail"><img class="mountedimage" src="#'" alt=""/></div> <ul class="details"><li class="name">name</li><li class="status">status</li><li class="address">address</li></ul> </li>
Note that the cost of CSS optimization needs to be balanced against impacts to maintainability. A way to retain maintainability is to optimize the CSS at point of delivery, instead of designing optimizations into the application.
Developers sometimes use scripting to create basic framework parts of their document. This has a higher cost in terms of content size and battery, rather than creating the framework in HTML.
Use markup language to create the minimal page framework and flesh out repetitive/dynamic aspects of the page using javascript. For example:
This section elaborates on the best practices of BP1 [section ref].
When an application depends upon multiple external script files, it typically must retrieve them separately from the main resource (e.g. web page) itself. This can increase data usage and service latency. Overall reduction of the number and size of script files can avoid these effects.
If your application depends upon external scripts:
Note that caching can also diminish the overhead for transfer of external script files, however as script files are collected into single packages, the efficiency of caching may diminish. So you should seek an optimum balance between script aggregation and cache efficiency..
See http://developer.yahoo.com/yui/compressor/ for an example approach to script compression.
Various design techniques can negatively impact battery life. These should be avoided and alternate techniques used where possible, to Use Power-Efficient Methods.
Use script only for the dynamic aspects of the user interface. DOM manipulation and creation of new nodes can consume a lot of battery at the device side, so as much as possible create user interface elements using the markup language and modify (if needed) those elements using scripting. For example:
Web applications should be designed with consideration that users often want to use multiple/different devices to access services. Keeping such goals in mind will enhance the usefulness of Web applications, especially those that do offer multi-device access options, e.g. mobile and desktop.
Web applications may enable a user to access services simultanously from multiple devices, or switch devices while retaining a consistent application state from the user's perspective. Current mobile devices may be able to access services via multiple networks, and have advanced interactive multimedia capabilities, e.g. support for streaming services. Because of these advanced capabilities, service convergence is occuring between mobile devices and other terminal domains (e.g. PC's, Web-enabled TV's or set-top boxes, or other consumer electronics devices). These various terminals, networks, services, and content are beginning to coexist in the realm of the Web. Web application providers should thus consider this emerging heterogenous environment in the spirit of the One Web.
Support for seamless content mobility enables mobile user to support a continuous service experience when changing from device to device. To support this, Web applications may need access to context information about the user, current used device(s), and network(s). Methods of accessing context information are described in 4.10 Handling Delivery Context Variation. Methods of accessing device information are described in 4.9 Handling Device Capability Variation.
As addressed in BP1, presentation issues of mobile devices can also be applicable to Web applications in general, e.g.
However, advanced web browser features and evolving web technologies are adding additional specific issues that need to be addressed in the mobile context, including:
Use script for the dynamic aspects of the user interface
Use script for the dynamic aspects of the user interface
The ECMAScript focus method can be used to move the focus to the part of a page that has changed, e.g. for automatically updating pages. If unexpected, this can confuse or irritate the user, especially if returning to the previous focus is not easy. It can also make an application unusable, if the focus changes prevent the user from using other parts of the application.
Use the ECMAScript focus method only if it is essential to use of the application, and does not inhibit user control/interaction.
As addressed in BP1, issues of interaction with applications on mobile devices can also be applicable to Web applications in general, e.g.
However, evolution of mobile devices is adding additional specific issues that need to be addressed in the mobile context, including:
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.
If you want the user to be able to easily take a device-specific action such as making a phone call to a number included in a web page, use URI schemes supported by the device. This will allow the user to take the action using a normal means, i.e. clicking a link.
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, and may be known through other means e.g. a DDR.
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 or through a DDR.
Device capability variation is a basic characteristic of the mobile web environment. The need to consider it when selecting, adapting, and delivering content and services is essential effectiveness of mobile Web applications.
Addressing this challenge also depends upon knowing which device and/or user-agent is in use (or intended to be served by the application), and its specific capabilities.
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.
Typically used methods of device capabilities detection:
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:
It can be tricky to determine the supported script capabilities for a device. Use of reliable methods is recommended.
When it is unknown whether a user-agent supports Javascript, 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 }
It can be complex to select and adapt content based upon dynamic assessmement 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.
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:
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.
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.
Detect browser capabilities or user preferences, and react accordingly with graceful degradation or progressive enhancement of Javascript/ECMAScript.
Separate behavior from content and presentation, for graceful degradation and progressive enhancement.
[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>
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.
Detect browser capabilities or user preferences and react accordingly.
Separate behavior from content and presentation, for graceful degradation and progressive enhancement.
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.
Delivery context variation is another basic characteristic of the mobile web environment. Variation occurs in several aspects, e.g.
MWABP addresses these aspects in the following ways:
The focus of the MWABP document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to a Web Runtime. The "Web Runtime" means in this case a Web application execution environment that provides support for application use of web technologies (e.g. CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), in particular as envisioned for use by Mobile Widgets. To ensure the applicability is clear, the recommendations address the functions of a Web application, rather than the specific client/framework in which they execute. The reasoning is that what is a good guideline for user experience improvement in one type of Web application running in a browser, is likely a useful guideline for Web applications being provided in other clients.
[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.