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

Mobile Web for Social Development Roadmap published — 30 November 2009

I'm glad that the Mobile Web for Social Development Interest Group I have been co-chairing eventually published its mobile Web for social development roadmap, its most important deliverable.

This is finalizing 16 months of hard work and discussions. We hope now to receive comments from different groups including the Web Accessibility Initiative, the W3C Internationalization Working Group, Mobile Web Best Practices, Voice Browser, but also from the community working in the field (NGOs, development agencies, etc.).

I believe this document is an important milestone in the path to extend the frontier of the Web in developing regions. It is the first document published by W3C that investigate the potential of the Web and mobile technologies in the Social Development domain, and identifies technology (and other) gaps to be bridged in the future by W3C, the Web Foundation and others.

It is also in my opinion a useful resource for those in the field willing to mainstream mobile technologies in their project. Having discussed with and visited different organizations deploying mobile content and applications in the field, I have come to realized that many of them have a vision of how ICT can help achieving their own goals/impact, but are missing an overview of the available technology landscape. They are usually moving from the vision to the tools directly: looking at what they can find on the market, and using it. I think that it is critical to add an intermediary step, before moving to the tools, to look at the specific needs, profile and requirements of the targeted end-users, the objective of the application, and the complete life-cycle of the project before choosing a particular (set of) technology(ies). The MW4D roadmap hopes to fill this gap, helping organizations to understand the technology landscape and informing them on the critical factors to consider before choosing one specific option.

Obviously, this is only a first step. They are lots of directions to explore. For instance, the document does not investigate specific application fields, and it would be interesting to understand the specificities of each domain (health, government, education, etc.), to identify patterns or information needs that are relevant to these domains, and how to address them. The current roadmap also focuses on using mobile phones to access content, but not to author or deliver content. If mobile phones are really the “computer for Africa”, it is critical to investigate how these devices could become an authoring platform, or a delivery platform (e.g. hosting a web server to deliver content and share information with surrounding clients).

This are only a few examples of potential future items for our group. The group just got an extension till the end of February 2010 to build a new charter, and define its future. Note that the MW4D IG is a public Interest Group, and does not require W3C membership to participate. See details on how to join the MW4D IG.

Therefore, I encourage everybody interested in this topic to join the group, the mailing-list and the bi-monthly teleconferences to participate in the work on this future new charter.

I also encourage everyone to read the published MW4D roadmap and provide feedback!


MWI on Twitter — 4 September 2009

As quite a few of you have already found out, info on MWI is available on twitter (and has been for a while; on an "experimental" basis).

There are currently two MWI-related twitter channels:

  • mobiweb: The main MWI channel. It distributes RSS feeds of MWI news as blog entries and shared bookmarks from the folks working on MWI at W3C. It also contains "sponatenous" tweets by MWI folks, e.g. live reporting from conferences relevant for MWI.
  • pmobiweb: Distributes the RSS feed of the popular "Planet Mobile Web". Most importantly, it provides an archive of past entries (since the planet does not provide an archive of older entries).
Hope this is useful, and if you want, follow us!
by Philipp Hoschka in Current state Permalink

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.

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.
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="">
   <link rel="alternate" media="handheld" href="" />
   <link rel="alternate" media="screen" href="screen.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.

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

:: Next Page >>

Contacts: Dominique Hazael-Massieux