Mobile Web Application Best Practices

Basic Guidelines

W3C Editor's Draft 21 May 2008

This version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080521 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-20080514 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.

---

Abstract

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.

TODO: Exorcise references to Web 2.0 "interactive web technologies" "ajax"

Status of this Document

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.

Table of Contents

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.4.4 Phasing
     1.5 Relationship to other Best Practices and recommendations
     1.6 Longevity and Versioning
2 Requirements
3 Structure of Best Practice Statements
4 Best Practice Statements
     4.1 Personalization
         4.1.1 Use Automated Means for Obtaining Personalizing Information
         4.1.2 Retain Personalizing Information
     4.2 Security and privacy
         4.2.1 Protect Personal Information Used in Transactions
     4.3 User awareness and control
         4.3.1 Inform the User About Automatic Use of Networks
         4.3.2 Inform the User About Use of Personal Information
         4.3.3 Provide Disclosures that are Timely and Accessible
         4.3.4 Provide Control over Application Behavior
     4.4 Use of cookies and redirection
         4.4.1 Automatically Recover Cookie-Based Information
         4.4.2 Minimize Redirects in Server-Server API's
     4.5 Conservative use of resources
         4.5.1 Use Transfer Compression for Content
         4.5.2 Minimize Automatically Issued Network Requests
         4.5.3 Use Push Methods to Reduce Pull Traffic
         4.5.4 Minimize Application Size
         4.5.5 Minimize DOM Manipulation
   �      4.5.6 Minimize External Script Files
         4.5.7 Use Power-Efficient Methods
     4.6 One Web
         4.6.1 Offer Synchronized View for Multi-Device Capable Applications
     4.7 Presentation Issues
         4.7.1 Use Scripting for User Interface
         4.7.2 Don't Move the Focus on Updates
     4.8 Interaction Issues
         4.8.1 Use URI Schemes for Device Functions
     4.9 Handling Device Capability Variation
         4.9.1 Use Device Capability Detection
         4.9.2 Use Reliable Methods for Determining Script Support
         4.9.3 Use Device Classification to Simplify Content Selection/Adaptation
         4.9.4 Provide Alternatives to Client-Side Scripting
         4.9.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS
     4.10 Handling Delivery Context Variation
     4.11 Applicability to Non-Browser Web Runtime Environment
5 Acronyms

Appendices

Appendix: Best Practice Dependent Device Properties
A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)

---

List of Best Practices

The following Best Practices are discussed in this document and listed here for convenience.

1. [AUTOMATE_PERSONALIZATION] Use Automated Means for Obtaining Personalizing Information

2. [RETAIN_PERSONALIZATION] Retain Personalizing Information

3. [PROTECT_PERSONAL_INFO] Protect Personal Information Used in Transactions

4. [DISCLOSE_AUTOMATION] Inform the User About Automatic Use of Networks

5. [DISCLOSE_PERSONAL_INFO_USE] Inform the User About Use of Personal Information

6. [PROVIDE_EFFECTIVE_DISCLOSES] Provide Disclosures that are Timely and Accessible

7. [PROVIDE_USER_CONTROL] Provide Control over Application Behavior

8. [RECOVER_COOKIES] Automatically Recover Cookie-Based Information

9. [MINIMIZE_REDIRECT] Minimize Redirects in Server-Server API's

10. [USE_CONTENT_COMPRESSION] Use Transfer Compression for Content

11. [MINIMIZE_AUTOMATIC_REQUESTS] Minimize Automatically Issued Network Requests

12. [USE_PUSH_METHODS] Use Push Methods to Reduce Pull Traffic

13. [MINIMIZE_APPLICATION_SIZE] Minimize Application Size

14. [MINIMIZE_DOM_MANIPULATION] Minimize DOM Manipulation

15. [MINIMIZE_EXTERNAL_SCRIPTS] Minimize External Script Files

16. [USE_POWER_EFFICIENT_METHODS] Use Power-Efficient Methods

17. [SYNC_VIEW_ACROSS_DEVICES] Offer Synchronized View for Multi-Device Capable Applications

18. [USE_SCRIPTING_FOR_UI] Use Scripting for User Interface

19. [RETAIN_FOCUS_ON_UPDATES] Don't Move the Focus on Updates

20. [USE_DEVICE_URI_SCHEMES] Use URI Schemes for Device Functions

21. [DETECT_DEVICE_CAPABILITIES] Use Device Capability Detection

22. [DETECT_SCRIPT_SUPPORT] Use Reliable Methods for Determining Script Support

23. [CLASSIFY_DEVICES] Use Device Classification to Simplify Content Selection/Adaptation

24. [MATCH_SCRIPTING_SUPPORT] Provide Alternatives to Client-Side Scripting

25. [MATCH_CSS_SUPPORT] Provide for Both Graceful Degradation & Progressive Enhancement of CSS

---

1 Introduction

1.1 Purpose of the Document

This document sets out a series of recommendations designed to enable development and delivery of [interoperable?] Web applications on mobile devices. Focus on precise and correct for first pass. -adam_gmail_account 6/17/08 8:31 AM 

The recommendations are offered to creators, maintainers and operators of Web applications.

1.2 How the Best Practices are Organized

The document is organized as follows:

• Introduction. Describes the audience, purpose and scope of the document.
• Requirements. An illustration of the type of problems that the Best Practices are intended to address.
• Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.
• Best Practices. The statements themselves.
• Acronyms
• Appendices
• Sources
• Related Reading
• Acknowledgements
• References

1.3 Audience

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 primarily targeted at Web developers, although others, such as interaction and graphic designers, and tool developers, are encouraged to read it.

1.4 Scope

Needs tightening. Editorial pass, etc. -adam_gmail_account 6/17/08 8:38 AM 

These recommendations (MWABP) add to the recommendations in Mobile Web Best Practices (BP1) in a number of ways. Where BP1 referred primarily to the extension of Web browsing onto mobile devices, this document considers the development of Web applications for mobile devices. In doing so it expands on the Best Practice [DEVICE_CAPABILITIES] which recommends taking advantage of device capabilities, but does not give examples of such capabilities, nor how to exploit them. It also specifies a number of Best Practices that were omitted from BP1 either unintentionally, or because at the time their use was not sufficiently established to be considered Best Practice.

1.4.1 Best Practices

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.

1.4.2 Web Application

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.

TODO: move 4.11 to here.


1.4.3 Mobile Context

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 to the limitations of the mobile context (e.g. small screen, poor connectivity), and 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).

TODO: Add more detail on mobile context.


1.4.4 Phasing  - TODO: REMOVE

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".

1.4.5 Criteria for Best Practice recommendations

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:

• will improve Web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful
• if they are relevant to the mobile context
• is implemented and recommended for broader use
• should remain relevant as technology evolves

1.5 Relationship to other Best Practices and recommendations

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].

1.6 Longevity and Versioning

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.

2 Requirements - TODO: REMOVE

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.

3 Structure of Best Practice Statements

The Heading

The functional area that is addressed by the statements.

The Statements

One or more Best Practice statements, identified in the following way:

[EXAMPLE] This is a Best Practice statement.

What it means

An explanation of the significance of the statements under this heading.

How to do it

A discussion of techniques and some suggestions as to how to implement.

References

Where appropriate, references to related WCAG points and other immediate references from the preceding text.

4 Best Practice Statements

4.1 Personalization

Personalization often increases user value / experience. This 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. 

TODO: REMOVE GREYED OUT

4.1.1 Use Automated Means for Obtaining Personalizing Information

[[ KAI: Will come up with specific points on privacy. ]]

[[ Please note, privacy (& other) regulations are great and should always be observed. ]]

4.1.1.1 What it means

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. 

UNCLEAR -- rephase to avoid privacy issues. -adam_gmail_account 6/17/08 8:54 AM 

4.1.1.2 How to do it

Intent: Minimize user pain to obtain personal information. 1) Username / password. 2) NetOp -adam_gmail_account 6/16/08 1:21 PM 


Put non netOp approaches first. Trim words. -adam_gmail_account 6/16/08 1:11 PM 


JO: Need to clarify that relation with operator is required for this first point...   -adam_gmail_account 6/17/08 8:59 AM 

TODO: Switch order to make "straight-internet connection" option first.

JO with add informative appendix on relationships with information / service providers.

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:

• user login via HTTP Digest Authentication
• user login via HTTP Basic Authentication over secure connections (HTTPS)
• user login through a Web form which is delivered over a secure connection




Other user information and delivery context characteristics may be used to provide a more personalized experience, e.g.

• photos, audio/video clips
• personal information, e.g. contacts, calendar
• location

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. TODO: REMOVE THIS

4.1.2 Retain Personalizing Information

4.1.2.1 What it means

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.

4.1.2.2 How to do it

Cookies / Unique URL -adam_gmail_account 6/16/08 1:13 PM --> Link to BP1 re: cookies not always working. Remove form elements option


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.

4.2 Security and privacy

...For the sake of efficiency do not use HTTPS unnecessarily.

Intent seems to be: don't send user identifying information in plain-text. Match level of security to level of sensitivity. -adam_gmail_account 6/16/08 1:14 PM 


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. performance implications of using 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.

4.2.1 Protect Personal Information Used in Transactions --- CHANGE TO: Something along these lines.

DKA: Favour more specific examples...

4.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. 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.

4.2.1.2 How to do it

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.

4.3 User awareness and control

4.3 Currently: Inform the user about automatic use of networks - Poor user-experience. Inform the user about use of personal information -          Possible conflict with system dialogues. Provide disclosures that are timely and accessible Provide control over application behaviour

Proposed: Inform user about automatic use of networks and provide -          Reword to require only an icon of some description. Inform user about use of personal information -          ? [remove] Provide means to control automatic network access - Focus this BP to be about enabling the user to switch off network access.

TODO: Split out network access from PIM access.

1. Network. Indicate automatic network accesses and provide control.

2. PIM --> Inform user of requirements of application to be full featured, and actions that will trigger request to PIM information... Make requests for PIM information active. If permission is denied fail gracefully. 

Ed: Context does matter, but balance against negatives... Don't access PIM information unncessarily. Minimize the Faustian aspects of your application.

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:

• 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)

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.

4.3.1 Inform the User About Automatic Use of Networks

4.3.1.1 What it means

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.

For Many application types this is unacceptable user-experience. E.g. Mobile IM. Propose simpler: indicate when network access is happening and provide link to disable. -adam_gmail_account 6/16/08 1:18 PM 


4.3.1.2 How to do it

Applications should disclose, in a clear and useful way, the basic nature of their automatic use of the Internet for data exchange, e.g.:

• how often the application will interact via the Internet, e.g. every 5 minutes, hourly, daily
• how long the automatic behavior will continue
• how heavy the overall data usage is expected to be, or type of service plan recommended (e.g. 10 MB/month, or unlimited usage plan)

4.3.2 Inform the User About Use of Personal Information

4.3.2.1 What it means

What happens here? Usually, will be a system prompt on accessing PIM information. Require that application level duplicates this ? At the least?  -adam_gmail_account 6/16/08 1:20 PM 


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.

4.3.2.2 How to do it

The following information should be disclosed:

• the types of personal information (data or contextual information, e.g. location) that will be used by the application
• what personal information will be exchanged via the Internet, and how it will be secured

4.3.3 Provide Disclosures that are Timely and Accessible

4.3.3.1 What it means

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.

4.3.3.2 How to do it

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.

4.3.4 Provide Control over Application Behavior Propose: Absorb into 4.3.1 / 4.3.2 -adam_gmail_account 6/16/08 1:26 PM 

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.

sec. 1.5 ? -adam_gmail_account 6/16/08 1:24 PM 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.

KEY POINTS HERE SHOULD BE MOVED INTO COOKIES AND REDIRECT SECTION

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.

4.3.4.1 What it means

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. Do we mean degrade gracefully if required information not available. -adam_gmail_account 6/16/08 1:25 PM 

4.3.4.2 How to do it

Users should be given easy-to-use controls to personalize application behavior, e.g.

• If an application uses AJAX requests to poll for updates from a server, the user should be able to turn off the polling, or adjust the schedule.
• Users should be able limit application use of personal data, or delivery of it over networks.
• Users should be able limit application use of sensitive device API's, e.g. location, filesystem, PIM data, media recording, etc.
• Users should be able to select the security level for requests and data sent over networks.

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.

4.4 Use of cookies and redirection

TODO: Cookies and redirection don't belong together...

Separate to: Client Side Storage and move redirects into "Minimize Network Access" 

4.4 Currently: Automatically recover cookie-based information   Minimize redirects in server-server APIs.

Suggest: Make this more about being robust against loss of cookie information. The recover description is too complex. In how to do it section suggest cookie information retain only non-essential information and user-identify, and large amounts of personalisation be pushed back to DB so it can be recovered. Move this to “conservative use of resources”

 

4.4.1 Automatically Recover Cookie-Based Information

4.4.1.1 What it means

Intent is: Be robust against partial or complete loss of cookies. -adam_gmail_account 6/16/08 1:34 PM 


Control the amount of information stored the client (in cookies ?) -- server-side copy, multichannel access.

  - HTML5 & other client-side DBs -- use for speed of access rather unique information ... under how to do it: there are a number of mechanisms... cookie size is limited.

Offline operation ?

Multichannel access to services ?

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. As far as possible, the recovery should use automated means, so the user does not have to re-enter information.

4.4.1.2 How to do it

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. Back up large chunkcs of user-info to server to protect against loss. -adam_gmail_account 6/16/08 1:35 PM 

Cookie and redirects don't sit well together. Move this to minimize resource user. -adam_gmail_account 6/16/08 1:37 PM 


4.4.2 Minimize (Unnecessary) Redirects in Server-Server API's --- MOVE TO CONSERVATIVE USE OF RESOURCES.

[[ Web Applications and authentication tend to increase the likelihood of there being redirects (e.g. for authentication). ]]

301 & 302 REDIRECTS -- call out differences with META redirects mentioned in BP1.

4.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 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.

4.4.2.2 How to do it

Avoid specific number of redirects. -adam_gmail_account 6/17/08 10:16 AM 

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.

TODO: Balance not needlessly interrupting user flow against using landing pages to improve perceived latency. Usability BP ?

NB FROM KAI: Make sure we don't overplay dangers of network use. Confine to one section, don't keep returning to it.

4.5 Conservative use of resources

4.5 Currently: Use transfer compression for content Minimize automatically issued network requests   Use push methods to reduce pull traffic Minimize application size Minimize DOM manipulation Minimize external script files.   Use power-efficient methods

Suggest: Good, just trim some words. Application compression ? Batching together, use of chunked responses, back off during inactivity. MIDP reference out of scope ? Too much detail. Remove code snippets, refer to: whitespace stripping, css pre-processing, javascript obfuscation. Disagree. Not dominant factor. Cut this BP. Cut -- absorb into minimize application size. Or change to: minimize network requests required to load page Cut -- Not dominant effect and somewhat misleading. Useful point in: back off network access -> move this to minimize automatically issued network requests.

 

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.

4.5.1 Use Transfer Compression for Content

4.5.1.1 What it means

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. 

Avoid "balance this against that" by providing more concrete numbers. KAI will show us... text = yes, binary = no.  -adam_gmail_account 6/17/08 10:24 AM

1. Type of network / effective bandwidth

2. Type of processor / operating env of device.

3. Size of data to be transferred.

4. Rate of compression achievable (e.g. text vs binary files).

e.g. in apache you can specify mime-types to compress or not. -adam_gmail_account 6/17/08 10:26 AM 


4.5.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, 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.

TODO: Point out that it's pointless compressing binary data (e.g. images). Not worth compressing very small files...?

Absorb into tokenisation BP. -adam_gmail_account 6/17/08 10:39 AM 

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:

• Efficient XML Interchange, EXI  Unless and until this is a done deal we shouldn't mention it. -adam_gmail_account 6/17/08 10:40 AM 
• WAP Binary XML encoding (WBXML)  out of scope. -adam_gmail_account 6/17/08 10:40 AM 

4.5.2 Minimize Automatically Issued Network Requests

4.5.2.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.


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. Already covered -adam_gmail_account 6/16/08 2:03 PM 

4.5.2.2 How to do it

Proposed:


Batch requests together.

Back off during periods of inactivity.


Contextual factors -- roaming ? ---> is an important reason why the user needs control ? refer back to it here ?

Low bandwidth version ? is a nice to have but depends on application... "If it makes sense for your application consider providing a low-bandwith mode of operation..." [If it's mobileOK?] -adam_gmail_account 6/17/08 10:52 AM 

Try to offer a low-bandwidth alternative if possible in order to provide value to the user in as many contexts as possible, allow the user to disable if not...

Kai: Enumerate anti-patterns... ? -adam_gmail_account 6/17/08 10:46 AM 

PROPOSAL --- A pet-store application to demonstrate best-pratices ???? -adam_gmail_account 6/17/08 10:48 AM 

Overall data usage effectiveness can be improved by:

• Applications can minimize the number of interactions with the server, e.g. via XMLHttpRequest, by following some basic guidelilnes, e.g.:
  • wait until there is sufficient value to the user before sending requests, i.e. focus on how the request improves the user exerience
  • if there is no direct value to the user from sending individual requests, bundle transactions by combining multiple operations into one, e.g. for prefetching data that is known to be useful at a later time
• Applications can vary network request intensity based upon the current value to the user, depending e.g. upon whether the user is actively using the application, whether new information is ready to be uploaded/downloaded, etc. Applications that are designed to "back off" automatic behaviors during low-value periods can improve the overall cost effectiveness of their use. Example criteria for determining the useful transaction rate:
  • based upon intensity of user interaction with the application, e.g. if use slows down considerably for an extended period, the application may assume a lower user benefit from network traffic
  • based upon success ratio of network transactions, e.g. number of messages received for mail/social-networking applications, news feed items published, etc
  • based upon typical usage patterns, e.g. reduced automated transactions at night or periods of typical low usage/success
• If possible, use awareness of the current serving bearer network type, and roaming status, to select an appropriate intensity of network requests

4.5.3 Use Push Methods to Reduce Pull Traffic

4.5.3.1 What it means

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.

4.5.3.2 How to do it 

All push methods require mediation of �third-party... "Because it requires mediation it requires additional administrative actions"  -adam_gmail_account 6/17/08 11:02 AM 

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:

your mileage may vary... "be aware that user experience of push mechanisms varies across devices"  -adam_gmail_account 6/17/08 11:06 AM 

• OMA Push same as WAP Push ??? -adam_gmail_account 6/17/08 11:01 AM , as is a widely supported enabler providing methods for user-confirmed and automatic content push, directed to mobile browsers and other user-agents
• Binding between applications and short message service (SMS) messages received on particular ports, e.g. through the MIDP Push Registry  remove. "vendor-specific mechanisms"... too opaque ? -adam_gmail_account 6/17/08 11:03 AM 

4.5.4 Minimize Application Size

whitespace stripping ? tokenization  -adam_gmail_account 6/16/08 3:27 PM 


TODO: Remove detailed css comments. Add side-note consider the use of css selectors.... ? See: Ed's reference.

4.5.4.1 What it means

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.

Selectors execute more quickly on devices... -adam_gmail_account 6/17/08 11:09 AM 

4.5.4.2 How to do it

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.

NEW BP added to minimize network requests: don't require additional request for JSON packet.

4.5.5 Minimize DOM Manipulation / Limit (DOM Manipulation) processing required before initial page display.

Remove this, move points into a presentation BP about minimizing processing before ... -adam_gmail_account 6/17/08 12:58 PM 

DON'T: Retain this as a placeholder pending some benchmarks on impact of DOM manipulation...  -adam_gmail_account 6/17/08 1:01 PM 

Have a separate BP that refers to loading spinner to provide immediate feedback -adam_gmail_account 6/17/08 12:58 PM 

Another BP about providing immediate feedback to user actions since there is additional latency caused by device processing and network hit... -adam_gmail_account 6/17/08 12:59 PM 

(Comment that javascript processing before page first will make initial user experience slower).

Use efficient DOM manipulation ?

initialization is slower with too much DOM ?

(Using inner HTML instead of DOM manipulation...)

Progressive rendering... page will get rendered as it streams.

4.5.5.1 What it means

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.

4.5.5.2 How to do it

Use markup language to create the minimal page framework and flesh out repetitive/dynamic aspects of the page using javascript. For example:

• For a page displaying 100 contacts, the data for those contacts is much more compactly transmitted as a JSON string [JSON] than as fully-rendered HTML.
• The framework page ideally contains no dynamic data so it can be much more aggressively cached.
• A "loading" spinner can be displayed while an asynchronous request is made to get the guts of the data. Since a small and/or aggressively cached html page would load quickly this creates a better user-experience overall.

4.5.6 Minimize External Script Files Move this into minimize network requests -adam_gmail_account 6/16/08 3:28 PM 

Remove this and add to network requests... -adam_gmail_account 6/17/08 1:08 PM 

Minimize references to other resources in your script files...  -adam_gmail_account 6/17/08 1:08 PM 

Potentially a new BP to talk about benefits of deferred binding as traded against benefits to preloading. -adam_gmail_account 6/17/08 1:09 PM 

NEW BP: Benchmark external vs inline... (some evidence apps download much faster if inlined) -adam_gmail_account 6/17/08 1:10 PM

NEW BP: Minimize page transitions within functional areas of the application -adam_gmail_account 6/17/08 1:12 PM  

4.5.6.1 What it means

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.

4.5.6.2 How to do it

If your application depends upon external scripts:

• Reduce the number of HTTP GETs required to retrieve the script files, e.g. by
  • Keep the number of script files to a minimum, e.g. by combining several script files into one
  • Send the scripts and main page together as a multipart/related package
• Reduce the size of your script files, e.g. by
  • Removing whitespace and comments
  • Making variable names in the code shorter
  • Use HTTP 1.1 compression [5.5.1 Support HTTP 1.1 Compression] when sending script files

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.

4.5.7 Use Power-Efficient Methods

Particularly around keeping connections open and making multiple requests... -adam_gmail_account 6/17/08 1:14 PM 

Currently refers to DOM manipulation as key danger, but wireless usage probably more dominant... Potentially gunzip -adam_gmail_account 6/17/08 1:14 PM

TREAT THIS AS A PLACEHOLDER... We need something on power efficiency but not sure what to say yet. -adam_gmail_account 6/17/08 1:16 PM 

Limiting DOM manipulation has impact on initial usage as well as power efficiency.

Scott is going to add some draft text here... -adam_gmail_account 6/17/08 1:18 PM 

NEW BP: ? What can be done about the screen fading out when you tend to look at web-apps without interacting... Null gestures ? "If you capture all events keep one of them no-op.." --> But this isn't possible right now. Feedback to openAjax as request to browsers.  -adam_gmail_account 6/17/08 1:20 PM

4.5.7.1 What it means

Various design techniques can negatively impact battery life. These should be avoided and alternate techniques used where possible, to Use Power-Efficient Methods.

4.5.7.2 How to do it

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:

• When a page is first served from the server side, it should contain all the markup that declares and populates user interface elements (forms, selects, input, etc). If rich interactions are needed later then use scripting to mutate or modify the DOM of the page.
• Update existing elements for new content, instead of creating new high-level elements. Elements that must be added should be appended after the focus point as a parent of an existing element, instead of the document. For example, use an existing <div> element as the parent for new content, without removing/recreating the parent <div> itself. (from http://www.unc.edu/webaccess/training/ajax/ajax_best_practices.pdf)




4.6 One Web

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.

Two facets: 1) Supporting broad range of devices. 2) A person owning multiple devices and accessing simultaneously -adam_gmail_account 6/17/08 1:28 PM 

Specifically call out desktop / mobile -adam_gmail_account 6/17/08 1:32 PM 

Should you have a parallel version for devices that don't support scripting... Open question ?  -adam_gmail_account 6/17/08 1:36 PM 

4.6.1 Offer Synchronized View for Multi-Device Capable Applications

4.6.1.1 What it means

Web applications may enable a user to access services simultanously from multiple devices, or switch devices while sharing 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.

4.6.1.2 How to do it

This is facilitated by storing personalisation information on the server and making it accessible across different interfaces... See BP xxx ? -adam_gmail_account 6/17/08 1:30 PM 

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.

4.7 Presentation Issues --> User Interaction Issues / User Interface Issues

+ Scott's comments:

Focus based vs pointer based. (It is necessary to consider all these variants).

Pointer = no mouse-over... need to identify what will happen when you tap a UI element. Something analogous to standard underlined link: Ensure that active content is suitably signalled. With touch-based you can random-access links but with pointer-based you can't. Ensure that you distinguish between interaction models when designing your application. 

TODO: Add an editorial note to review and assess BP1 navigation advice

---

When you change a page, how do you let the user know you've changed it... e.g. Yellow Fade Technique

If you need to change the view... animation helps maintain user orientation ?

How do you signal off-screen events... ?

Don't do CPU intensive things with content that is off-screen.

Using client-side scripting to improve perceived performance... Provide immediate feedback to user actions

TODO: Making the grain-size smaller so that things happen more fluidly.

Preloading ? -- (for specific reasons).

Text entry... random access to text boxes... Keyboard might pop-up, information relating to ... (reference input mode attribute -- XHTML Basic 1.1... is referenced in BP1)

Consider the impact on the CPU of your user-interface... Ensure that (superfluous) animations are visually pleasing

--> Hash URLs to enable browser history and allow deep links into application.

--> Collapsing multiple views onto single page... ? But maintaining multiple pages for functionally separate chunks.

As addressed in BP1, presentation issues of mobile devices can also be applicable to Web applications in general, e.g.

• variations in page rendering/layout in different devices
• context/overview constraints due to limited screen size and the limited amount of visible material
• dependency upon scrolling through material
• presentation space expense for images and navigation links
• overall lack of site/content cohesiveness due to fragmentation of display and site structure

However, advanced web browser features and evolving web technologies are adding additional specific issues that need to be addressed in the mobile context, including:

• support for popup windows and layers which can overlap partially/fully
• support for popup menus
• dynamic changes in screen orientation
• need for content adaptation (e.g. image resizing/cropping) due to variable presentation space
• overall usability issues resulting from more complex presentation options

4.7.1 Use Scripting for User Interface Expand to extoll benefits of using client side scripting to improve user-experienc -adam_gmail_account 6/16/08 3:30 PM 

http://developer.apple.com/webapps/designingcontent.php

<meta name="viewport" content="width = 320" />
		<meta name="viewport" content="initial-scale=2.3, user-scalable=no" />

4.7.1.1 What it means

Use script for the dynamic aspects of the user interface

4.7.1.2 How to do it

Use script for the dynamic aspects of the user interface

Some new Presentation Related BPs -- action Scott.

What are the generalisable BPs from Apple doc that we don't have already -adam_gmail_account 6/17/08 1:55 PM 

TODO: ? Disable page zooming if inappropriate to your application

TODO: ? Set sensible viewport for your page

TODO: ? If designing for touch devices... a finger is 44 pixels high.

TODO: Add some forward-looking statement about browser features that will be coming.

Ongoing action on Scott to add some details here... -adam_gmail_account 6/17/08 1:56 PM 

4.7.2 Don't Move the Focus on Updates

4.7.2.1 What it means

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.

4.7.2.2 How to do it

Use the ECMAScript focus method only if it is essential to use of the application, and does not inhibit user control/interaction.

4.8 Interaction Issues

TODO: Interaction Issues and Presentation issues become one section

As addressed in BP1, issues of interaction with applications on mobile devices can also be applicable to Web applications in general, e.g.

• limited keypad, e.g. 16-key, leading to difficulty in selecting \characters, and the need for application help in selecting the input character type
• physical keying difficulty due to small key size
• form field navigation
• overall difficulty in entering text impacting usability, e.g. for forms and long URLs
• no pointing device
• variations in softkeys for navigation and local application menus

However, evolution of mobile devices is adding additional specific issues that need to be addressed in the mobile context, including:

• new pointing methods, e.g. touch screens
• dynamic changes in keyboard layout, e.g. between 16-key, querty, and soft keyboards
• solve the top left navigation problem [need a definintion of what this is, and consideration of whether it is actually testable]

4.8.1 Use URI Schemes for Device Functions

4.8.1.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.

4.8.1.2 How to do it

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.

4.9 Handling Device Capability Variation

4. 9 Use reliable methods for determining script support   Use device classification to simplify content selection Provide alternatives to client-side scripting

Placeholder? Needs reworking since currently there is a typo. Make BP more specific ? Cut. Design advice rather than BPs. Is this about degrading nicely ? Lots of superfluous text. Not sure I like progressive enhancement or that it looks like a good idea ? Cut references to progressive enhancement ?

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.

4.9.1 Use Device Capability Detection [[ INCLUDE NOTE THAT THIS IS NOT FULLY BAKED ]]

4.9.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) -- [REF DDWG, though it's not the only way] based upon device identification, e.g. based upon the user-agent header.

What do we want to say ? -- 1) Determine whether device supports scripting? 2) Level of script support 3)  -adam_gmail_account 6/17/08 3:01 PM 

BP: Adapt application behaviour in response to device capabilties

Detection of capabilities: 1) Profiling, 2) Dynamic detection... (Is a more accessible approach). -- A discussion around when it makes sense to do it on the device or on the server... what options are open to you.

There are two things here: 1) Device; 2) Browser -adam_gmail_account 6/17/08 3:08 PM --

Browser deficiencies... work around deficiencies if you want to ... ?

4.9.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
  
  
  Ref: CT doc wrt to x-device headers ... ?  -adam_gmail_account 6/17/08 3:14 PM 
  
  
  TODO: Placeholder to elaborate on role of proxies

4.9.2 Use Reliable Methods for Determining Script Support

4.9.2.1 What it means

It can be tricky to determine the supported script capabilities for a device. Use of reliable methods is recommended.

4.9.2.2 How to do it

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 }

4.9.3 Use Device Classification to Simplify Content Selection/Adaptation

--> Because otherwise you feel that you have to deal with every device... Making it clear that application-specific bucketing is a reasonable approach.

Placeholder: Possibly reference DD Structures if ready  -adam_gmail_account 6/17/08 3:20 PM 

4.9.3.1 What it means

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.

4.9.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 (a DDR) used by the Content Provider, and content then provided consistent with the assigned class.

There is not one almighty DDR so be careful of wording.

4.9.4 Provide Alternatives to Client-Side Scripting

Roll into One Web section... Fundamental design decisions so would expect to see them earlier in the doc. Add to One Web the notion that if you want your application to be accessible across broad range of devices you might want to create an non-js version...  -adam_gmail_account 6/17/08 3:24 PM 

ARIA ? -- Accessible Rich Interface Applications.

JAVASCRIPT and screen-readers and accessibility

Providing a none Javascript version is laudible for One Web and for accessibility... 

( Alan has an action for text around javascript and accessibility )

4.9.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.

4.9.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.
TODO: Boil this down into something more BP and consider removing... RAISE AN ISSUE ON THIS..
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>

4.9.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS

TODO: BP ON USE OF SVG... WICD? 

4.9.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.

4.9.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.

4.10 Handling Delivery Context Variation

NOTHING ACTUALLY ACTIONABLE HERE - NO BPs. REMOVE IT.

MOVE SOME SENTIMENTS INTO MINIMIZE TRAFFIC

[[BP: Detecting delivery context on the fly (e.g. chunking / non-chunking) but further along flow in other to not interrupt user activity.]] 

Delivery context variation is another basic characteristic of the mobile web environment. Variation occurs in several aspects, e.g.

• the type of serving network (e.g. GPRS, UMTS, WiFi) and related properties such as typical bandwidth and network services
• the network service provider currently providing service
• the type of device to which service is being provided (see 2.9 Handling Device Capability Variation)

MWABP addresses these aspects in the following ways:

• delivery context property awareness in general, e.g. methods of determining current value of properties whether known by the device or by the network only
• issues for specific delivery context properties, e.g. network bandwidth, roaming, location, network services (e.g. proxy services such as content transformation and user authentication/identification)

4.11 Applicability to Non-Browser Web Runtime Environment MOVE TO SCOPE

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.

5 Acronyms

DDRDevice Description Repository. A system hosting device capability information, for use by Content Providers and application developers in selecting, adapting, and delivering content and services based upon the capabilities of the device in use.

Appendix: Best Practice Dependent Device Properties

[To include the set of minimum device properties supporting specific best practices.]

A Sources (Non-Normative)

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

• to be added

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.

B Related Reading (Non-Normative)

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.

C Acknowledgements (Non-Normative)

• to be added

D References (Non-Normative)

D.1 MWI References

to be added

D.2 Sources

to be added

D.3 Device Independence

XMLDelivery 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

XMLExtensible 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-BasicXHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Working Draft, 5 July 2006 (See http://www.w3.org/TR/xhtml-basic/) CSSCascading 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) CSS2Cascading 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.0Hypertext 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

UAPROFOpen 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) WTAIWAP 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 3966The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December 2004 (See http://www.ietf.org/rfc/rfc3966.txt) RFC 2119Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997 (See http://ietf.org/rfc/rfc2119)

Agenda:

1. Scope (Are we done with this ?)

2. Section 2 has been all but removed? Can we remove it completely?

3. Existing BPs that need some attention.

    4.1 Personalization

    4.2 Security and Privacy      

    4.3 User Awareness and Control.

    4.4 Use of cookies and Redirection.

    4.5 Conservative use of resources

    4.6 One web

    4.7 Presentation issues

    4.8 Interaction Issues

    4.9 Handling Device Capability Variation

   4.10 Handling delivery context Variation -- [ not BPs, not in this section. Cut altogether ? ]

4. New BPs to be added.

New BPs to discuss

Use of WTAI: and TEL: URI schemes.

Designing for pointer / Designing for touch.

Stick to standards. (Does this need to be called out explicitly)

Set viewport size. <meta name="viewport" ...> --> Is this standard ?

Use #urls to maintain history

CACHING -- using static URLs to enable cachable resources. Caching within the session. 

TODO: Add modification based caching - KAI

Cache limited so don't blindly cache without value - Scott

Use simplest methods possible in order to acheive goals (since it'll be more likely to work across devices)... Often simpler things work more simply. [ But can we make a best-practice from this ? Too prescriptive of how people build their applications ]

Javascript libraries... Most existing frameworks won't work...  [ See OpenAjax for example. ] 

GUI design? -- leave for now.