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 2) — 23 March 2009

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.

Principle: The Web is based on global identifiers

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.

Principle: URIs are opaque

Looking at your logs, you notice that some users try to access your Web site through mobile devices that only support WML. You decide to use content adaptation and create a WML version of your Web site for them. The problem is that the URI they use is Well, it is not a problem! URIs are opaque, you can simply go ahead and serve WML content for that URI when it is requested by WML-only mobile devices!

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.

Let's imagine that the Web is composed of three resources: A, B and C. Resources B and C link to resource A. The situation is represented in the diagram below.
The value of a Web with three resources is 6
Resources B and C get their value from the fact that they both link to resource A. For the sake of simplicity, let's say that their value is 1. Resource A gets its value from the fact that it is the target of two different links, and from the fact that resources B and C, at the origin of the links, have a value. Summing up, let's say that the value of resource A is 4. The total value of the Web in this case is 6.

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

    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.
    Hidden resources reduce the value of the Web

  • 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

    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.
    Broken links reduce the value of the Web

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

    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.
    Reusing the same URI for a different resource harms the Web

  • 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

    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.
    The value of a Web where two URIs identify the same resource is greatly reduced
    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 Permalink

All webs in one, One Web for all (part 1) — 17 March 2009

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:

George has been maintaining a Web site for the last few years. The Web site works well on usual desktop browsers but George recently started to receive feedback from users who had a very bad experience when trying to access the Web site from their mobile devices. George follows some of the recommendations of the Mobile Web Best Practices specification and prepares a simplified version of the Web site for mobile devices. He then advertises the new version:

  • go to to access the regular desktop version
  • go to to retrieve the mobile version of the site

To make sure that users find the mobile version of the Web site, he even puts a handy link to the mobile version on the home page of the desktop version.

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, and mobile-friendly Web pages will surely link to 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.
    Example of an advertisement on multiple URIs
    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 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 Permalink

Yours truly, the W3C mobileOK Checker — 4 February 2009

We've released a new version of the online W3C mobileOK Checker today.

A friendly "Please wait..." loading page is now displayed while the checker runs in the background. We've also started a help page to answer common questions you could have while reading a mobileOK report, and further clarified some of the messages returned by the Checker. A few other bug fixes complete the list of changes.

Are there questions you would like us to answer on mobileOK? Mobile tips and techniques you would like to discuss? Send your thoughts to the public mailing-list!

Do you have suggestions for the next release of the mobileOK Checker? Do you experience problems running it? Does it crash? Do you find that messages are obscure? Send your concerns to the public mailing-list!

The W3C mobileOK Checker is here to help you develop mobile-friendly content. We'd be happy to improve it!

by Francois Daoust in Current state Permalink

<< Previous Page :: Next Page >>

Contacts: Dominique Hazael-Massieux