W3C Mobile Web Initiative Position Paper

Submitted by Opera Software ASA
Timo Bruns, Vice President, Business Development
Ove Ranheim, Spesifications Manager, Smart Phone Product Line

This document is Opera Software ASA's response to the Mobile Web Initiative Workshop's call for participation.

The main focus of the paper is how to make mobile devices first class citizens on the Web. As the uptake of mobile and embedded devices is growing fast, a significant amount of users may soon have mobile devices as their primary device for accessing the Web.

To make the Web accessible to these devices, the barriers to its content must be removed. Existing sites often have bindings to particular browsers, platforms, or screen sizes. These bindings are not a result of the W3C specifications, and there is a movement towards less cluttered markup with separate styling. The resulting sites are not only innately "phone enabled"; they benefit the Web on any device, as the sites are leaner and faster, and easier to maintain.

A more serious barrier has been the creation of mobile content formats separately from Web content. While mobile devices in the past had severely limited capabilities, they will soon reach a level where they are capable of desktop-like operations. WAP 1 and WAP 2 have been attempts to define subsets which would be mobile specific, slowing down the uptake of the full Web. To avoid creating yet another WAP, the amount of mobile-specific technologies should to be reduced, and convergence with existing Web technologies preferred.

The faults have not been solely on the mobile side. Often W3C specifications have not properly considered the need to work across a wide range of capabilities and under diverse circumstances. If W3C specifications need profiling for mobile devices, the specifications themselves are probably too large.

The final barrier to overcome is to make authoring for the mobile Web less of a chore and more of an opportunity. At the current stage, the mobile Web participants are beggars that are happy to get content — any content. But that will not be satisfactory to our users in the long run.

CSS allows authors to keep visual identity while ensuring beautiful presentations across any range of devices. Lean content does not have to be dumb content. The principle of degrading gracefully will have to go two ways. Less capable devices will have less dynamism, but should still be able to display what they are capable of. Similarly, content enhanced for the mobile Web (with support for communication, location, and integration) should also work with non-mobile browsers.

We propose a two-stage approach. We need to work with what is here, encourage a more accessible and mobile-friendly style of coding, use the existing mobile-specific profiles as a staging post, and continue support for the decreasing number of devices that are not yet capable of handling the full Web.

We must also tear down the iron curtain between the mobile device and desktop worlds, and promote authoring techniques and languages that will span the divide without the author having to create device-specific content.

Rationale Behind Unified Web Browsing

Universal access

The challenge for mobile access is the same as for Web accessibility in general; content creators with a deadline do not respond well to learning and using techniques they do not consider relevant to their line of work if there is not anything in it for them. Making device- dependent content in multiple versions is not the way to go.

Web designers have a problem with what they cannot see. Opera has had great success with a "Small screen" display option in the desktop browser. It is hard to visualize the impact that a design choice has on phone rendering when it is abstract. When you can see a simulation on the screen in front of you, it is made a lot easier.

Interoperability

The mobile landscape is much too divergent for an 'optimised for X' approach to be viable. Devices span all capability levels. The same content needs to run correctly irrespective of the device hardware, software or browser manufacturer, therefore a set of best practises is required.

Modularity, not profiles

The lowest-common-denominator approach limits the natural evolution of the Web. Specifications and recommendations must be modular and scalable to meet tomorrow's needs as well as today's.

Evolution, not revolution

The authors and implementors must see a clear migration path from where they are to where they are going. The Web should be available now and in the future without being taken down for construction in the meantime. By putting the burden on the content authors to comply with multiple and changing standards, they will either stick with what works with their target device, or they may opt for non-Web based solutions.

Users should not be exposed to authoring errors

HTML may have given us a lot of headaches by being too flexible, but it is a sensible best efforts approach to display what can be displayed, instead of discarding everything that does not validate. Validation should happen as early and close to the author as possible.

Shared Specifications for the Mobile and the Stationary Web

On markup

We recommend support for the HTML and XHTML family, and find SVGT 1.1 support to be useful. This will provide a capable set of markup standards meeting the converging needs.

On styling

CSS 2.1 should become the foundation for styling. Not only is it widely used today, it also offers a functional solution which does not fragment.

On scripting

ECMAScript 262, 3rd edition is recommended as a foundation for scripting. It is compatible with JavaScript 1.5 and enables support for the majority of the use cases which currently cannot be handled by markup alone.

On DOM

In order to break away from static viewing of pages and prepare for Web applications, we recommend support for DOM2 as well as examining further uptake of DOM.

Responses to the Mobile Web Browsing Topics

Requirements

Use cases for the mobile Web
There is no separate mobile Web, any more than there is an office Web, a home Web, a leisure Web, or an airport Web. The ways in which the the Web is accessed, depend on cost, technology, usability, and situation. Initially the cost and technology constrained Web use to data look-up or download and as infotainment while travelling or in similar situations. As phone browsing becomes more fun, the Web use becomes more diverse.
How the mobile user experience differs from the fixed user experience
The differences can be summed up as adding constraints and freedom. With a phone you need to do more with less, and the constraints are most obvious to the user. It is slower, has smaller displays, is more expensive, and has lower usability. In many ways the mobile user experience is burdened with the same accessibility issues as people with disabilities. It also offers freedom. With the mobile Web you bring your computer with you. This gives the mobile Web an immediacy the desktop Web experience does not have; it is more social, and it can adapt to where you are.

Strategic issues

How can we enable the Web to be made as seamless, uncomplicated and reliable an experience on mobile devices as it is on desktop devices?
We should avoid introducing new fragmentation into content creation on top of the existing ones.
How can we make more users "light up" the mobile devices they already have to access the Web?
The first turn-off is to get the device configured for browsing, something that can be a daunting task even for an enthusiast. This is getting better as more and more devices can either be preconfigured or have the settings downloaded and installed. The second is if you fire up your phone browser and find nothing useful there. This is overcome when users have a choice to access both value-added content in the operator portal and the Web.
Is it possible to accommodate the need for a different user experience on mobile platforms while avoiding Web fragmentation?
Yes, by limiting the number of profiles, we enable compliance and conformance of the Web content. And in doing so we actually unify the user experience.
How can users discover Web sites that work well on mobile devices? Do we need a new "virtual library" for the mobile Web?
The initially available selection of Web sites will likely be geared towards operator portals and content designed for the device. There is no need to offer a virtual library. It also runs counter to the Web's underlying idea of sharing. When one user forwards a URL to another, or links to it on his Web page, he will not ask what device the recipient is using.
How can we make mobile Web content easier for content and service providers?
Mandating validated XHTML without offering the tools to do this easily is a barrier to a broader adoption of XHTML. We should work with content tool vendors to create tools with integrated validation, which would be able to identify and fix obvious errors without user intervention.

Technology issues

How can we make better use of existing technologies and specifications? Are there gaps? Is there a need for new technologies?
What is currently missing is a supplement to best practices, namely 'bad practices' for authoring. It would be equally important to document items outside the scope of the various existing profiles, in order to make educated judgments on the disadvantages of using a mobile profile instead of the full Web equivalent. Also, a move towards a more dynamic Web requires increased adoption of the DOM.
What technologies are needed to enable uniquely mobile capabilities that go beyond browsing?
Authoring for capabilities beyond those found in the static Web, such as "radio" interface, location awareness, handwriting, or telephony should be offered as modular extentions to existing capabilities.
What is the conceptual architecture for the mobile Web?
It is no different to that of the existing Web. Apart from adding a few uniquely mobile characteristics, such as location awareness, the existing architecture will serve the mobile space just as well as it has served the non-mobile so far.

Summary

To make the mobile Web fun and viable, it cannot stay separate from the full Web. This best-of-both-worlds approach will avoid fragmentation of Web and enable users to make full use of the content out there.

In order to get there, we propose this approach:

Opera has already demonstrated that the full Web can be a reality on small devices. What is required next, is to define the steps that raise the bar from viewing the Web to interacting with it.

Opera Software ASA