MWI Team Blog

Web authoring tools ease publication process. Simplicity comes with some loss of control over the generated content. There is hardly anything an authoring tool user may do to improve her content when the W3C mobileOK Checker reports that pop-up windows should not be used. So what?! I do not have any of these pop-up links in my content!

The underlying theme can be updated, but this approach works up to a point when e.g. the post would best be split into multiple pages when delivered on mobile devices. Authoring tools that do not provide content adaptation mechanisms need to be extended to be able to serve mobile-friendly content to mobile devices.

I have been working on an open-source suite of tools written in PHP lately, named mobileOK Pythia, designed to help generate mobileOK content and more generically speaking to help adapt content to fit the properties of the requesting device. Here is a short overview of the outcome of this work. More information (including crucial information about the choice of Pythia as a name ;)) can be found in the documentation of mobileOK Pythia.

This work is part of the MobiWeb 2.0 project supported by the European Union's 7th Research Framework Programme (FP7).

Plug-ins for WordPress and Joomla!

From a user's point of view, the visual and hopefully useful outcome of this work is the creation of the mobileOK Pythia plug-ins for WordPress and Joomla! that make it possible to generate mobileOK content with these tools.

The plug-ins feature:

• Device identification: based on WURFL, an open-source DDR published as an XML file, and accessed through a standard DDR Simple API interface.
• Content adaptation to fit the properties of the requesting device in terms of e.g. screen size, script support, page size limit.
• Theme switching: possibility to switch to a more mobile-friendly theme when the requesting device is identified as mobile.
• POWDER: a machine-readable mobileOK claim for the Web site can be automatically created and served using a POWDER document. The POWDER document is made discoverable through the addition of a Link HTTP header field as decribed in the POWDER Primer.
• W3C mobileOK Checker link: a link to the W3C mobileOK Checker is added next to the authoring input form to be able to assert the mobile-friendliness of the created content while it is being written.
• mobileOK theme: a mobileOK template may be installed with the plug-in.

The development of a third plug-in for Moodle has started but it is still work in progress.

There exist other plug-ins that provide similar functionality (see for instance WordPress Mobile Plugin, WordPress Mobile Pack, Mobilebot 1.0 or WAFL: Mobile Content Adaptation). mobileOK Pythia separates tool-specific functionalities from tool-agnostic libraries to ease porting to other tools. In particular, the plug-ins wrap the same extensible libraries:

• AskPythia to identify and retrieve the properties of the requesting device.
• TransPythia to adapt content based on the properties of the requesting device.

AskPythia

AskPythia is an open-source conforming implementation of the Device Description Repository Simple API in PHP. It is not a DDR but a wrapper to existing DDRs.

AskPythia ships with an implementation on top of the WURFL database that maps WURFL capabilities to properties defined in the Device Description Repository Core Vocabulary standard. Support for other DDRs is welcome!

Check AskPythia's documentation for more information.

TransPythia

TransPythia is a transcoding library that adapts content (HTML, CSS, images) based on the capabilities of the requesting device. The library ships with a set of transcoding actions that are particularly adapted to mobile devices and that may be extended as needed.

Main transformations are:

• Images conversion and adaptation: adapts images to match the requesting device's list of supported image formats and to fit the screen size. Removes images that cannot be converted or that are still too big for mobile consumption after conversion.
• Pagination: a generic pagination algorithm that may be used to paginate HTML pages or HTML fragments when the requesting device is identified as a mobile device.
• Tables linearization: to remove nested tables and linearize tables when the requesting device does not support them.

Check TransPythia's documentation for more information.

Feedback

If you would like to comment, contribute, report bugs or simply tell us what you think, you are very welcome! Feel free to send an email to the public-mobile-dev@w3.org mailing-list (with public archives).

by Francois Daoust in News, Technical Leave a comment

Version 1.2 of the W3C mobileOK Checker, released on Tuesday, helps Web authors focus on the failures that most affect the mobile-friendliness of their content, and returns the POWDER document Web authors may use as the basis of a mobileOK^® conformance claim.

Expandable sections

The reports returned by the mobileOK Checker can be long. That's not a bad thing, failure points need to be clarified. That said, scrolling over a long list of details is a tedious process and does not reveal the big picture. The new version adds unobtrusive (as in "works fine when Javascript is not enabled") Javascript to hide/show details. Details are hidden by default, simply click on a failure message to reveal its details!

Severity levels

A missing width attribute on an img element? That's a failure. Using frames? That's a failure. Obviously, the former case only slightly affects the mobile-friendliness of the page, while some mobile browsers won't even be able to render the page in the latter case. And yet both failures looked alike in the report, leaving the difficult task to evaluate the impact of a failure on the overall mobile-friendliness of the page to the reader.

Each failure now comes with a severity level:

• critical: such failures typically prevent the rendering of at least part of the page on most mobile devices! Critical errors are highlighted using a yellow background.
• severe: while such failures usually do not prevent the rendering of the page, they strongly impact the user experience.
• medium: some mobile constraints are not appropriately taken into account, e.g. the browser needs to retrieve more data than actually needed to render the Web page.
• low: useful improvements are possible.

Web authors who only have limited time available to fix failures may want to focus on the most severe failures first. The "Where to start..." section near the top of the report lists the top 3 failures to address right away.

Sprinkle POWDER on your mobileOK content

So your content is mobileOK? Congratulations! You may now wish to identify your content as mobileOK conformant. The Mobile Web Best Practices Working Group recently published the W3C mobileOK Scheme 1.0 note. It provides an overview of the mobileOK scheme and explains in particular how to claim mobileOK conformance.

One way to make such a claim is to use POWDER. When the page is mobileOK, the mobileOK Checker now returns a POWDER document you may use to advertise that the page is mobileOK^®. For instance, the mobileOK checker returns the following POWDER document when http://www.w3.org/Mobile/ is checked:

For more information on POWDER, please refer to the POWDER Primer.

... and more!

A few other features compose this summer release, such as the size of each resource that composes the page, or the repartition of points lost per severity level. The complete change log is detailed in the What's new? page.

Feedback welcome!

by Francois Daoust in News, Technical 3 comments

This post is the last post of the One Web series. Previous part focused on the theory behind One Web. Time to focus on One Web in practice!

Neo: I know One Web!
Morpheus: Show me.

One address space

One Web says that you should use one address space: the different versions of a resource should share the same URI used to access the resource from a desktop browser, a mobile device or a TV set.

The need to use one address space applies to all the resources of a given Web site, and not only to the main index page. Deep links (i.e. links to specific pages within a Web site) are common on the Web. The structure of your Web site should be consistent from one version to the other.

Thematic consistency

One Web says that a URI should return predictable results over time and across devices. A user that accesses a URI from different devices, e.g. from his desktop PC and from his mobile phone, should feel that is is the same. In other words, the different versions of a resource should be thematically consistent.

Thematic consistency does not mean that the content has to match exactly. It means that, as far as is reasonable:

• the information provided by the resource should be the same
• the color, the logos, the layout of the content should be close
• the functionality on different devices should be similar

In short, it means that users who switch from one device to another should not have to wonder: "Where is this piece of information I'm looking for? I know it's there, I saw it on my laptop!" A single glance at the different versions should be enough to say "OK, that's the same thing".

The best time to start worrying about thematic consistency is when you design your content:

• Focus on the content or functionality you are trying to provide
• Ensure that the material that is central to the meaning of the page can be easily found on the page (see the CENTRAL_MEANING best practice). Conversely, ensure that the material that is not does not catch the user's attention and could thus be removed to provide a light and short version without creating any thematic inconsistency.
• Prepare alternatives to content that may not be accessible by some devices
• Develop for the Default Delivery Context as a minimum common base, then enhance the user experience for specific classes of devices.

Starting from a default version of your content, there are different ways to enhance the user experience:

• through the use of CSS Media Types to handle both mobile and desktop style sheets. See for instance Return of the Mobile style sheet
• through the use of scripting that degrades gracefully when the device does not support it. See for instance Graceful degradation and progressive enhancement
• through content adaptation. See for instance... below.

Content adaptation

To start using content adaptation and return a version of a Web page that fits the capabilities of the requesting device, you first need to know what these capabilities are.

The requesting device can be identified from the HTTP headers sent in the request, and in particular from the User-Agent, Accept and Accept-Charset HTTP headers. Once identified, the capabilities of the device can be retrieved from a Device Description Repository, i.e. a database that describes mobile devices. There are multiple databases available. The Device Description Repository Simple API standard defines a common interface to access such databases.

Once you know the capabilities of the requesting device, you can eventually exploit them and adapt the response consequently. In the HTTP headers returned with the response, add a Vary HTTP header so that proxies between your server and the final client understand that you use content adaptation and do not incorrectly cache and serve a version of the page that does not match the user agent.

Content adaptation comes at a cost: that of having to maintain multiple versions of the same content. Since many devices share similar capabilities, it is good practice to use device classification, so that you only have to manage as few versions of a Web page as possible.

Think of users on the go

Once you've managed to create a few versions specifically tailored for a few classes of devices, you might want to go a bit further and start taking into account the context of the user at large. The capabilities of the user's device are but one side of the user context. Some other considerations:

• the network the device is connected to. A report from AdMob (PDF) shows that 8% of US mobile users browsed the Web over Wifi in November 2008. The usual mobile network constraints (low bandwidth, high latency, data cost) mostly do not apply to Wifi and you might want to provide an enhanced Wifi version. Conversely, when the user is roaming, bytes exchanged over the network are precious.
• the social context of the user. A user browsing on a couch has more time than a user walking in the street who probably just wants a precise piece of information right away. There again, this could lead to different versions.

The generic user context cannot be inferred from the request itself. The user needs to be able to switch from one version to the other, depending on his context. The context could be stored in a cookie, but cookies may be disabled or not supported. And so you need to use distinct URIs for the different contextual versions of a Web page in that case.

Wait! Doesn't that break the one address space rule? Not if you do it properly:

• Maintain and advertise a canonical URI for the Web page. The canonical URI should be used to bookmark the page and should return the most appropriate version of the Web page for the supposed context of the user.
• Ensure that the canonical page links to the other existing versions of the page, either explicitly using a link elements in HTML pages that users can follow, or implicitly using link elements in HTML pages so that machines (e.g. search engines or mobile browsers) can understand that the versions actually are different instances of the same resource.

Contexts and versions

What if contexts are so different that thematic consistency seems to be wholly inappropriate? If you find yourself in this situation, you've probably reached the point where you are trying to represent different pages using the same address, and we've seen in the previous post that this is bad practice. Different URIs should be used for the different pages and, although guiding users through the different pages is a good thing, there is no need for a canonical URI per se.

The dividing line between what constitutes variations of the same page and different pages around the same topic is fuzzy. As a possible rule of thumb, imagine a user being referred to the Web page by one of his friends. If some contexts would leave him wondering what his friend is talking about, different pages are probably needed. Note this only works provided that the reference is more generic than "look at this picture", or "look at the third menu item". Can you think of a better rule?

Wrapping up the One Web series

Neo: What did she tell you?
Morpheus: That I would find the One.

• One Web simply follows from the architecture of the Web.
• One Web is not one version!
• One address space should be used whenever possible.
• Versions of a Web site should be thematically consistent.
• The user context may encompass more than just his device.
• Keep ubiquity in mind while writing content, to reduce the number of versions needed and the amount of adaptation required
• Different contexts may go further than different versions.

by Francois Daoust in Current state, Technical 1 comment

This post is the second post of the One Web series, and tours the two principles and five good practices of the architecture of the Web that yield the core of One Web. It does stay on the theory side, but note it comes with small and handy figures :) Part 3 is now available.

A Web of URIs

The Architecture of the World Wide Web specification defines the Web as an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI). Hey, where are the links? Links are but a direct consequence of the use of global identifiers: any resource of the Web can link to any other resource, because each resource is precisely identified by its global identifier.

The global identifiers could have taken different forms. They happen to be URIs in practice. All linking mechanisms on the Web use URIs. URIs are identifiers, and should be regarded as such. In particular, they do not carry any information on the resource itself.

Links equal value

The value of the Web lies in its ability to link similar resources together, either through explicit links between the resources, or through implicit links (e.g. two resources targeting the same resource, two resources that match the same keyword search in a search engine). The value of the Web could be defined as the sum of the values of its resources.

The value of the Web is reduced each time a resource escapes or divides the Web. This happens when:

• Resources are identified with global identifiers that are not URIs as it de facto creates another Web and divides the information space into different spaces that cannot inter-communicate.

  Good practice: Identify resources with URIs

• A single URI identifies more than one resource. Resources identified by the URI are hidden from the rest of the world that can only link to the visible URI.

  Good practice: Use distinct URIs to identify distinct resources

  Example
  If we add two resources hidden behind resource A, we cannot tell whether resources B and C link to A or to one of the other resources. The value of A is reduced, say, to 2. The total value of the Web is reduced to 4.
  

• The URI of a resource changes. When a URI changes, links that used the previous URI are broken, reducing the value of the resources that contain the broken links. Cool URIs don't change!

  Good practice: URIs should be persistent

  Example
  When the URI of resource A changes, resources B and C now link to nothing. The value of resource A is reduced to 0. The total value of the Web is reduced to 2.
  

• The type of information carried out by a resource changes. Links to the resource are still valid, but their value is reduced because they now link to a different resource.

  Good practice: Resources should return predictable information

  This good practice does not mean that the content in itself cannot change. The actual content of a resource that returns "breaking news information about strikes in France" is likely to change pretty often, but it should always return "breaking news information about strikes in France".

  Example
  If the URI that used to identify resource A now identifies resource D, resources B and C now link to something by mistake. The value of resource D is simply 0. The total value of the Web is reduced to 2.
  

• Different URIs are used to identify the same resource. In this case, the problem arises because different resources that link to the resource will use different URIs, creating artificial copies of the resource.

  Good practice: Do not use different URIs to identify the same resource

  Example
  If resource A is identified by two different URIs, and resource B links to resource A using the first URI, while resource C uses the second URI, resources B and C now apparently link to two different copies of resource A and are not connected anymore. Their respective value is 0.
  
  Resource A is duplicated. One copy is the target of one link originating from resource B, the other from resource C. Each copy has thus a value of 1. The total value of the Web was reduced from 6 to 2!

One Web is NOT One Version

There is one important message that the One Web vision does not carry: an hypothetical need to return the same version for each and every device. A Web site may use content adaptation, i.e. return different versions of a resource depending on the capabilities of the device and/or the context of the user. In fact, content adaptation is explicitly encouraged to improve the user experience on devices. Exploit devices capabilities is one of the mobile web best practices, and it does fit One Web!

How many versions should there be? 1, 10, 100, 1000? Content authors will certainly want to reduce the number of versions they have to maintain to a bare minimum, to one whenever possible. With a little bit of (hard) work and the possible help of content adaptation tools, it is usually possible to generate all versions from one single source. Could this single source be served to everyone so that we could simply drop the need to adapt the content? In some cases, yes. The Web site of the W3C Mobile Web Initiative for instance does not use content adaptation (but for one or two exceptions that are out of scope of this post) and was designed to work on a majority of devices. One may argue that the content of this Web site is "simple". As of today, it is true that specific versions are required to take advantage of the specificities of various devices. I'll get back to that in the last part of this series. The one thing that I would like to stress out here is that One Web is neutral when it comes to specifying how many versions there should be, provided that the good practices mentioned above are applied, of course!

Fine. Now you know One Web. How does that connect to the real-world?

[On to part 3...]

by Francois Daoust in Current state, Technical 1 comment

This post is the first in a series of three posts on the One Web vision. Part 2 and part 3 are now available.

I can haz One Web

The W3C promotes the One Web vision. Every now and then, I hear the term coined in discussions around mobile Web standards and it usually follows some harsh complaint at our attempt to impose supposedly flawed Mobile Web Best Practices. Yes, the Mobile Web Best Practices standard is grounded on the One Web vision. No, it does not carry any stern restriction that would force authors to adopt a "one size fits all" line of conduct.

Since the One Web vision is essentially misunderstood, I thought I should debunk some of the myths that surround it and clarify the concept: what the theory is about, what it encompasses, what it implies and does not imply for the authoring of mobile-friendly Web content. I will try to keep things short and simple, and will not address too specific details here. I already kind of missed the "short" promise: this post is the first one in a series of three.

Before I start delving into the architecture of the World Wide Web (yes, it is fun!), you probably wonder why you should care about One Web to start with. Alright, let's have a quick look then!

One > two

Let's consider the following example:

Many existing Web sites follow the same pattern, but, this usually does not achieve the One Web vision. Why? We surely want to favor the development of mobile-friendly Web sites, don't we? Among other things, problems arise in this example because these Web sites now use two sets of addresses (URIs). Different areas are impacted:

• Missing content:
  Trimmed-down versions are usually synonym of extensive cuts in the amount of information that is accessible. Users on the go have many distractions and want to be able to find their way through the information easily. They surely want the browsing experience to be adapted to the device they are using, and that usually translates into shorter pages than the ones targeted at desktop browsers. But why would they want to access less information? Accessing the Web from a mobile device is not something users do because they have to, it is something they do because they want to, as pointed out by a study from IBM last October.
• Search engines
  Most search engines use the number of links that target a Web page to compute a rank used to sort search results. The higher the rank, the more visible a Web page becomes. Desktop Web pages that want to link to George's content will link to http://george.example.org, and mobile-friendly Web pages will surely link to http://mobile.george.example.org. Two consequences:
  • the mobile version of George's Web site does not inherit the rank of the desktop version. From the point of view of the search engine, the mobile version is simply a new Web site, not linked by anyone to start with, and thus unlikely to show up in results.
  • links to George's Web site now contribute to two different rank counters and do not sum up. George's Web site is not as visible as it could be.
• Shared bookmarks
  Many users share their bookmarks among different devices and/or among different groups of people using different devices. How could George's Web site be bookmarked? There is no canonical URI that could be used for all devices. The link to the mobile version of the Web site on the desktop home page is a good idea, but some devices may not be able to render this page at all. Even when they are, the user experience is poor because the user has to render a page that does not work properly, and to find his way to the mobile version link, before he can actually see the mobile version of the Web site.
• Branding
  Advertising multiple URIs leads to confusing messages. The following image shows an example of an advertisement to a Japanese Web site whose entry point depends on the mobile operator of the user.
  
  A study from Bango also reveals that more and more users actually type familiar URIs on their mobile devices. The familiar URIs are the ones they are used to entering on their desktop browsers. Users unaware of George's mobile-friendly version URI will keep entering http://george.example.org and miss the mobile version specifically tailored for them.

The solutions to these problems are in One Web, but we need to do a slight detour and visit the foundations of the Web before we get to One Web in practice.

[On to part 2...]

by Francois Daoust in Current state, Technical 4 comments