Mobile Web Browsing gets WICD
Date: Sep 2, 2005
"The nice thing about standards is that you have so many to choose from," famously quipped computer science professor Andrew Tanenbaum. Fast forward to 2005 and the situation has become even more complex, especially in the landscape of overlapping and conflicting Web and XML "standards." If you want to create content for mobile devices, you have an especially dizzying array of these standards to choose from. The World Wide Web Consortium (W3C) has developed, and promotes, XHTML Basic as the solution for mobile browsing. The Open Mobile Alliance (OMA) has developed XHTML Mobile Profile (XHTML-MP) as its solution for mobile browsing. XHTML builds on XHTML Basic but adds features required for mobile handsets. NTT DoCoMo's i-mode system uses C-HTML (Compact HTML). Some devices are starting to support W3C's Scalable Vector Graphics format for scalable graphics and animation. Some support Macromedia's (Adobe's?) Flash format.
Even if you do choose a set of formats, how do you best combine these formats, which were often created by disparate groups of people with scant regard for the integration of their standard with other standards and formats? What's a Web developer to do?
W3C, in close coordination with the OMA, is quietly working on a new technology to address this situation and make the standards landscape more navigable for those who wish to create interactive content for mobile browsing.
Last Autumn, W3C kicked off a new effort, the Compound Document Formats (CDF) working group. This group has been running for the past year to develop rules for combining different XML formats, particularly in the user interface domain, and specifically focusing on mobile browsing. Why mobile browsing? It's an area that badly needs this kind of triage.
The second part of the draft Compound Document recommendation document specifies the Web Interaction Compound Document (WICD – pronounced "wicked") profile. This so-called profile is essentially a set of rules for the reliable combination XHTML and SVG content in a mobile browsing context. What are the issues here?
One of the key issues inherent in developing for mobile browsers these days is that the actual user experience of the same page will often differ between different browsers on different handsets. This problem should be familiar to anyone who's tried to use different desktop browsers, say Opera, Firefox and Internet Explorer, on the same content. For example, your bank's web site may look and work fine on IE but could seem to have strange formatting or at worst-case be completely non-functional on Firefox. This is often due to the different ways in which the browser vendor has implemented the Web standards. Web sites are written according to how these browsers implement the standards, not according to the standard itself, because content and service providers on the Web have to provide a functional user experience (they can't afford to wait for the browser vendor to fix their bugs) and they often only have the resources to test their Web site on a limited number of browsers (if only .05% of your customer base are using one browser, you're not likely to put time and money into testing your service on any other browsers).
The thing is: if you as a user, on a desktop PC, find that you can't use a web site, you at least have a fighting chance: you can ostensibly download another browser and try it in that one.
Mobile web users largely do not have this luxury. They are constrained to use the single version of the single Web browser that was installed in their phone at the factory. Their only upgrade option is to buy a new phone, and even then, most mobile phone users are not aware of their browser vendor. And unlike Web browsing on the PC, there are numerous vendors in the marketplace.
So what does this all have to do with combination of XML document formats? The issues that the CDF specification and WICD profile are tackling are mostly in the area of user agent behavior. This is to foster a more predictable user experience – when you hit the same page or service from different handsets you should get a (more or less) similar user experience.
So what does such a compound document look like? As simple combination of XHTML and SVG might look like this:
)
Figure 1 Credit: Opera Software
The XHTML document that created the above (foo.html):
<?xml version="1.0"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>circles</title> </head> <body> <h1>This is the text</h1> <p><object height="350" width="600" type="image/svg+xml" data="circles.svg"/</p> </body> </html>
And the referenced SVG document (circles.svg):
<?xml version="1.0" encoding="UTF-8"?> <svg xmlns="http://www.w3.org/2000/svg"> <g fill-opacity="0.7" stroke="black" stroke-width="0.2cm"> <circle fill="red" cx="6cm" cy="2cm" transform="translate(0,50)" r="100"/> <circle fill="blue" cx="6cm" cy="2cm" transform="translate(70,150)" r="100"/> <circle fill="green" cx="6cm" cy="2cm" transform="translate(-70,150)" r="100"/> </g> </svg>
Reference vs. Inclusion
The CDF working group has defined two methods for combination of XML documents, combination by reference and combination by inclusion. What's the difference? Combination by reference is like referencing an image or any other object (actually it leverages the <object> tag) to combine content. Combination by inclusion involves actual mixing of XML vocabularies in the same document. For various reasons, the group has chosen to focus on the first, combination by reference, for the first release of their specification, and for the combination of XHTML and SVG. This approach leverages the already-existing <object> tag to embed SVG content, and specifies the semantics used with that tag.
Combination by inclusion is a different ball game. The next work of the CDF working group will focus on combination of XML vocabularies by inclusion – that is, mixing tags from different XML namespaces in the same document.
Events
One of the key issues the CDF group has been tackling over the past year has to do with events. When you have DOM events (such as a "click" event or a change of "focus") in one part of the document (say, the XHTML part) these events may need to propagate to one or more child (SVG) documents and vice versa. This kind of event propagation can enable interactivity features (such as an SVG animation kicking off in one part of the screen when the user selects an item in another part of the screen).
Four-Way Navigation
Web browsing on the PC, whether a laptop or desktop, is accomplished using a pointing device – such as a mouse. Most mobile phones feature a four-way rocker switch or joy-stick which allows you up, down, left, right and "select" or "OK." This kind of navigation is especially problematic in arbitrary two-dimensional layouts such as the one below:
)
How to allow a four-way navigation to navigate an arbitrary two-dimensional layout has been up to each browser implementer – the result is that there is now a variety of navigation methods out there. While variety is the spice of life, in this case it blocks adoption of a technology because there is a new learning curve for users for each device they pick up, to access the same content or service. The problem becomes even more acute when in the context of navigating a two-dimensional space the user can navigate in to an interactive SVG space (sometimes rendered by a browser plug-in and sometimes rendered by a browser itself) which itself may have focusable items and then back out into an XHTML-defined space.
The red arrows in the above diagram illustrate a standard way to implement this. The CDF specification specifies this in detail and thereby sets a bar for browser vendors – thus enabling a more predictable user experience across different devices and browser implementations.
Interoperability
One of the goals of the WICD profile is to promote content interoperability between implementations. Below, you can see three different handsets with different screen sizes and different browsers displaying the same content (written in a preliminary version of the WICD specification) with a more-or-less the same look and feel. These are not beta devices – they are real production models with real production software running on them. WICD is not theoretical. It is here now and it can enable a rich user experience across an increasing number of real devices.
)
What about Web Applications?
Everyone is talking about Web applications these days -- basically a fancy name for Java(ECMA)script code that runs in the browser to make the client smarter. Proponents of the so-called AJAX technique advocate using mini-applications within the browser to "asynchronously" fetch information in the background while managing the display to the user. These techniques can provide a greatly enhanced user experience. In particular, in the mobile content world, where latency and connection speed are still key issues, the potential benefits of this approach are many. The WICD document profile provides plays well in this space because implementations will allow client-side (e.g. ECMAScript) code to create even more dynamic presentation in the browser – for example, by triggering SVG animations. Meanwhile, W3C is talking about starting up another group to actually standardize many of the techniques involved in creating Web applications – watch this space.
First Draft
WICD is a work in progress, but it is on a fast track. The intention of the CDF working group is to bring the CDF specification and WICD profile to "Recommendation" status (W3C's term for a released specification) by early next year. In the mean time, the group needs feedback from all sectors of the content and mobile industries.
Links:
The CDF working group's draft: http://www.w3.org/TR/WICD/
The CDF working group: http://www.w3.org/2004/CDF/