Copyright © 2006-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes the W3C mobileOK Trustmark. mobileOK defines machine-readable content labels which may be applied to content to indicate that the content and its delivery pass a suite of tests based on the Mobile Web Best Practices document [BestPractices]. The Mobile Web Best Practices Working Group is creating these labels to help promote development of an effective user experience for mobile users of the web.
This document is directed primarily at mobile content authors, tools developers and content providers. Readers are expected to be familiar with the Mobile Web Best Practices document [BestPractices].
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/.
This is a first Editor's Draft of the W3C MobileOK scheme; this document establishes the rough shape of the mobileOK scheme. It lacks many details, and it is subject to significant change. This document should not be taken to reflect group consensus. The Working Group is seeking feedback on the general direction of the document.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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.
This document is a working draft, and liable to change. It currently contains errors, ommissions, and editorial notes (the latter are marked out with a distinctive style, as is this parenthesis).
This document describes the W3C mobileOK scheme (referred to here as simply "mobileOK"), version 1.0.
mobileOK is a scheme comprised of two content labels, called mobileOK Basic [Basic] and mobileOK Pro [Pro]. These machine-readable labels may be applied to content to indicate that the content and its delivery pass a suite of tests based on the Mobile Web Best Practices document [BestPractices].
mobileOK Basic tests are based upon a limited subset of the Mobile Web Best Practices and are all machine-verifiable. Conformance to mobileOK Basic requirements is thus simple to check or verify. Content bearing this label has taken some basic steps to provide an effective experience for mobile users, and been tested by checking software.
mobileOK Pro tests are based upon a significantly larger subset of the Mobile Web Best Practices, and are a superset of mobileOK Basic tests. These tests are not all machine-verifiable and require verification by a human. Content bearing this label has taken significant steps to provide an effective experience for mobile users, and has been tested by a person (optionally with the assistance of software when applicable).
Note that not all Mobile Web Best Practices map to a test in mobileOK conformance tests. Some best practices, like EXPLOIT_DEVICE_CAPABILITIES , are advisable but may not meaningfully translate into concrete tests, whether machine- or human-verifiable.
mobileOK says nothing about what may be delivered to non-mobile devices from that URI; however, note that a mobileOK URI must return mobileOK content by default if the nature of the user agent (desktop or mobile) cannot be reliably determined.
A mobileOK label also does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.
The Mobile Web Best Practices document [BestPractices] and Techniques document [Techniques] @@Issue: the Techniques wiki is not in development. Should we remove this reference or just note that the target is dead? have already enumerated much of what it takes to deliver an effective user experience to users of mobile devices. mobileOK complements this effort by providing machine-readable labels for mobileOK content. The presence of standard mobileOK labels may catalyze production of effective content for mobile users, and tools to create and detect this content, and even create demand for this content. It is hoped that this ultimately improves the quantity, quality and usability of Web content available to mobile devices.
mobileOK has value at many points in the content authoring and delivery chain for mobile devices. These are developed in more detail in the Use Cases, but the main audiences are briefly listed here:
Developers who create content which follows Mobile Web Best Practices, and which passes tests outlined in this document, have added value for mobile users. They can advertise this to consumers of their content through the mobileOK labels.
Likewise, tools that can produce, parse, adapt or manipulate mobileOK content (browsers, content management systems, authoring tools, content adaptation systems, etc.) add value for authors, and can advertise this capability.
Sites that are concerned with providing a quality experience to mobile users can look for a mobileOK label when acquiring content and tools.
Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK label and possibly prioritize mobileOK content.
End consumers of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content.
Certification providers may wish to offer to certify conformance to mobileOK tests; entities such as content providers that come to rely on mobile content may require more verification that content they provide is mobileOK.
The precise form of the mobileOK label has not yet been finalized, however, MWBP expects to use the work of the POWDER working group [POWDER] to provide a standard encoding for mobileOK labels. In addition, a visual label (banner or icon) will (probably) be made available, to provide an indication to users that a Web page, site, or application meets mobileOK Basic [Basic] or Pro [Pro] requirements.
The abstract model for mobileOK exists independently of any particular technology. However, the expectation is that mobileOK will typically be encoded in [POWDER], a vocabulary of [RDF] that has the following basic structure:
Content which bears a mobileOK label may optionally advertise this by displaying a mobileOK logo (to be produced). Adding even a small logo image to a page increases the time and bandwidth needed to access that page; therefore, it is recommended that the mobileOK logo be displayed on relatively few key pages, if at all. If one URI returns content differently for desktop computers and mobile devices, and delivers mobileOK content to mobile devices, then the mobileOK logo may be included on the desktop rendering of the page as well.
Ace Content Provision has a substantial desktop presence and wants to reach a mobile audience with its new service. Naturally it is keen to have its content display as well as possible on mobile devices and so develops its web site in accordance with the Best Practices.
Ace is keen to advertise the existence of its mobile tailored services and show that its high quality brand value extends to this area. It believes that the mobileOK claim will carry more weight, especially among search engines tuned to mobile devices, if endorsed by a trusted third party. This is particularly true of those claims related to non machine-testable aspects of mobileOK.
One of Ace Content Provision's main distribution channels is a mobile network operator that requires content on its portal to be certified as being mobileOK by one of a short list of preferred certification providers. In order to offer a flexible and competitive service, the certification provider offers several levels of service. These range from automated checking of machine-testable Best Practices through to frequent checks by human reviewers. For Ace Content Provision, this is worthwhile as an ongoing service. For other providers the balance of cost and assurance is best met by assessment at service launch and on major update thereafter.
A content developer wants to create high quality user experiences on multiple devices. Sensibly, the developer chooses to use an adaptation approach which supports mobileOK. They create device independent content together with styling and layout, using W3C standards such as DIAL and CSS.
When a device makes a request, the adaptation system uses the various materials provided by the author to construct and deliver an appropriate page that conforms to mobileOK. It automatically marks the page with the mobileOK label. If the author has requested inclusion of the mobileOK logo, the adaptation system adds it to the page.
A content syndicator / aggregator gets content from many sources. Some may be internal to the company, some may be external partner companies; in fact some content from partners can be sent directly to the client using inclusion via iFrames for example. In short, the content syndicator has, in some sense, very little control over the syndicated content.
Since the mobileOK label can only apply to the full page delivered to the end user, the content syndicator must ensure in some fashion that the content from partners does not invalidate the label. Thus the syndicator wants partners to make mobileOK conformance claims about their content to which they can be held accountable. This may include information about who is making the claim.
Joe Lambda wants to make a web site about his holidays for a couple of friends to follow, and be sure that it can be read on mobile phones. He reads the mobileOK documents, and makes sure he follows the requirements, so he can put the mark on his pages and his friends can check they will work before they download them.
The use case requires no-cost use of the label and that the label should be sufficiently simple that it can be added by the normal processes used for web development.
It would be nice to have tools to assist in testing, to add the label when tests have been met, and to note that something important has changed and that content needs to be re-tested.
A search engine wants to provide search services over mobile content for the benefit of its mobile users. When crawling the web it wants to easily discover all content that is usable to a mobile device, especially content designed specifically for mobile devices. It wants to evaluate how good the mobile content is and index it. When serving queries from mobile devices, it wants to return the best mobile content that matches the query.
One might imagine several things a search engine would want from the mobileOK label. The one that seems vital to making mobileOK useful to the search engine is detecting that a page at least says it is mobileOK and thus is trying to be a good mobile page.
There are a couple things that would be nice to have. First is an easy way to discover many mobileOK resources at once -- for example all mobileOK URL in a directory or domain. Next is a way to at least partially verify that a page does comply with mobileOK tests as claimed. Last is a way to identify claims of partial conformance, so that the search engine can customize its offerings to a particular profile of requirements. For example in a real use case, I have a phone that has a certain set of constraints, but is much more powerful than the baseline device -- specifically I don't care whether content relies on JavaScript or not, since my browser supports it, so I want content that meets various other requirements whether or not they meet any requirements on script.
A software developer is prioritizing fixing problems in rendering content appropriately. Being able to gather a collection of mobileOK content provides a useful test set, that allows prioritizing development based on what we trust to be the approach to content that more people will be using -- chasing a growing, rather than diminishing, market.
So the use case would require a discoverability mechanism for mobileOK content, and people using mobileOK.
It would be very helpful to have some reasonably reliable and simple method of verifying the claim.
An operator might use the mobileOK label to predict which content and sites would work better on the mobile devices of its customers. By detecting the existence of this label, an operator might apply different prices to the data traffic, provide better network caching for those sites and in some cases enrich the communication (policies at network transcoders, more parameters, etc.).
An agent is set to crawl the Web to collect content to be presented in an ATOM feed that is updated daily. Several criteria are used sequentially to decide whether content resolved at a particular URI should be included or not, including mobileOK conformance.
The crawler detects a mobileOK label describing content at http://mobile.example.org. The label itself comes from a server the crawler recognizes as being trusted. Although the label is digitally signed, for efficiency, this is not checked before the crawler passes the content on to the next stage in the evaluation process for possible inclusion in the ATOM feed.
At http://new.example.org content is again described by a mobileOK label. This time, however, the label is on a server the crawler has not encountered before and so it does not know, yet, whether to trust the claims or not. The data in the label carries a valid digital signature and so the content is passed on to the next stage in the evaluation process for possible inclusion in the ATOM feed. If it is subsequently included, the newly discovered server will be added to the list of trusted sources as will the digital certificate.
Finally the crawler discovers content at http://bad.example.org that is again claimed to be mobileOK. The server is not recognized and the digital signature is not valid for the data in the label. It is therefore rejected and content is not forwarded to the next stage in the evaluation process.
The following requirements were considered in the development of mobileOK.
The editor would like to thank members of the BPWG for contributions of various kinds.
The editor acknowledge significant written contributions from: