MWI Team Blog

Dispatches from members of the W3C Mobile Web Initiative Team

Categories: Current state (32) | Developing Countries (15) | Events (20) | Looking forward (13) | News (42) | Technical (33) |

All webs in one, One Web for all (part 3) — 1 April 2009

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:

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.

Example
If you start using the User-Agent HTTP header to adapt your content according to the capabilities of the requesting devices, ensure that the HTTP response you return contains the following HTTP header:
  Vary: User-Agent
Caches will then know that different versions of the page exist and are served depending on the User-Agent, and will not cache the response inappropriately.

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.
Example
The following HTML code says that the current version of the Web page is specifically tailored for mobile (handheld) devices and that there exists a desktop (screen) version of the Web page.
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>[title]</title>
   <link rel="alternate" media="handheld" href="" />
   <link rel="alternate" media="screen" href="screen.html" />
  </head>
 <body>
  [body]
 </body>
</html>

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.

Example
A Web page that contains the biography of an author along with contact details is not the same as a Web page that only contains the author's contact details. The latter page should not be regarded as a mobile version of the former one, but as a different page with a different URI. The latter page may be part of a mobile context where users are looking for practical information.

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 Permalink

Comments, Pingbacks:

Comment from: dani [Visitor] · http://daniiswara.net/
The conclusion of 3 series is nice.

For the one web, maybe I'll choose a simple and compact design layout. Not really the same version--at least there are CSS for special media, but something like content adaptation/negotiation will make it right for the users. Users only need to remember one URI.

I think, for a simple content, to make it ubiquitous with those rules is easier rather than a complex website.
PermalinkPermalink 2009-04-13 @ 14:49

Contacts: Dominique Hazael-Massieux