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 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 http://george.example.org to access the regular desktop version
  • go to http://mobile.george.example.org 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 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.
    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 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 Permalink

Performance tests and mobile browsers — 6 October 2008

Many of the recent announcements in the desktop browsers world have been focusing around how this or that browser improved performance-wise, in particular in their Javascript engine: Mozilla's TraceMonkey, Google Chrome's v8 engine, Webkit's Squirrelfish, etc.

And these claims are generally supported by results of getting these engines through a variety of performance test suites. These include:

All these tests certainly provide a lot of incentives for desktop browsers vendors to compete on performance.

But do they help in the mobile world?

Unfortunately, most of these tests are so CPU, network and memory intensive that they are mostly useless on most mobile browsers, even on fairly recent devices, as the Mobile Web Test Suites Working Group discovered by running them on a sample of browsers/devices.

The Test Suites Working Group is considering providing more mobile-friendly versions of these test suites as a result, but before we put any resources into this, we are looking for feedback on:

  • whether this would be a useful service, esp. to browser vendors, and mobile web advocates,
  • whether anyone has already started such an effort, either as part of one of the existing performance tests, or entirely separately.

Should you have any view on this, please comment below, or send your feedback to our mailing list (public-mwts@w3.org) or to me privately (dom@w3.org).

by Dominique Hazael-Massieux in Technical Permalink

SVG in the iPhone — 11 September 2008

Doug Schepers, the W3C Staff Contact of the SVG Working Group, points out that support for SVG has landed on the iPhone with the release 2.1 of the firmware.

Hopefully this will bring more visibility to SVG, which I believe has a really big role to play in the mobile world.

by Dominique Hazael-Massieux in Technical Permalink

<< Previous Page :: Next Page >>

Contacts: Dominique Hazael-Massieux