Introduction to Device Independence, Part 1

September 22, 2004

What is Device Independence?

Several years ago the only way to work with a web site was through a personal computer. There were different browsers, some of which were text-based terminals and others that were GUI apps. It was assumed that the “normal” user had a machine with a large color display with full graphic capabilities.

But in the past three to four years the number of different kinds of devices that can access the Web has increased significantly. And they have a wide variety of different capabilities: smart phones, mobile phones, voice response systems, PDAs, and even microwave ovens can access the Web.

The mission of the Device Independence activity of the W3C is to avoid fragmentation of the Web into spaces that are accessible only from certain types of devices. The goal of the Device Independence Activity is to develop ways for future web content and applications to be authored, generated, or adapted for a better user experience when delivered via many device types.

The general phrase "device independence" indicates this goal, although the access mechanisms may include a diversity of devices, user agents, channels, modalities, formats, etc. It is also touches on making the Web accessible to anyone, including those with disabilities. XML technologies help to achieve device independence, including XSL:FO, XSLT, SVG, and others.

Connectivity capabilities have also evolved, to include high-bandwidth modems, LANs, and wireless networks. Simultaneously, the needs and expectations of the user with regard to access, availability, and consumption of web content have also evolved. Users now expect to get to critical information through different access mechanisms from different locations and at different times during the day.

Content authors can no longer afford to develop content targeted for use via a single access mechanism. The key challenge facing them is to enable their content or applications to be delivered through a variety of access mechanisms with a minimum of effort. Implementing a web site or an application with device independence in mind could save money and assist authors in providing users with an improved user experience -- anytime, anywhere, and via any access mechanism.

Principles

Let’s look at Device Independence principles from three points of view: that of the user, the author, and the delivery mechanism.

User Perspective
It's important to enable the user to perceive and interact with the Web using many kinds of devices, or more generally, via many kinds of access mechanisms.

The access mechanism is an intermediary between the Web and the user. On one side it communicates with the Web using protocols and markup conventions; and on the other side it supports perception by, and interaction with, the user. From the user's point of view, an access mechanism often corresponds to a single device. A perceivable unit is a set of materials which, when rendered by a user agent, may be perceived by a user and with which interaction may be possible.

So by functional user experience we will mean a set of one or more perceivable units that enables a user to complete the function intended by the author for a given resource via a given access mechanism. The main user-related principle of Device Independence is: For some web content or application to be device independent, it should be possible for a user to obtain a functional user experience associated with its web page identifier via any access mechanism.

The goal is that a functional user experience should be possible via any access mechanism. The method by which presentation and interaction are provided may vary according to the different access mechanisms, but the possibility of a functional user experience should always exist.

The second user-related principle says that A web page identifier that provides a functional user experience via one access mechanism should also provide a user experience of equivalent functionality via any other access mechanism.
Authoring Perspective
When a request is made over the Web for a page, not only should the request specify the web page identifier for the page, but it should also provide enough information about the access mechanism and the user that the right kind of user experience can be provided.

An important part of this requirement is delivery context, which I will discuss in-depth in my next article. A delivery context is a set of attributes that characterizes the capabilities of the access mechanism and the preferences of the user. Delivery context information may be sent as part of each request, but this is not essential. The delivery context expresses the capabilities and preferences that may constrain the acceptable range of user experiences that can be delivered via a given access mechanism. In particular, the capabilities of the device, including the modalities and representations it supports, the characteristics of the network over which delivery occurs, and the preferences of the user may affect the user experience provided.

After the web-page identifier and delivery-context information have been sent to the server, the server-side adaptation occurs. It is a process of selection, generation, or modification that produces one or more perceivable units in response to a requested uniform resource identifier in a given delivery context. After that, the delivery unit is sent to the user. A delivery unit is a set of material transferred between two cooperating web programs as the result of a single HTTP request.

This leads us to the primary authoring-related principles. First, it should be possible to provide a functional user experience, in response to a request for a web page, in any given delivery context that has an adequate access mechanism. And, second, if a functional user experience of an application cannot be provided due to inherent limitations in the access mechanism, an explanatory message should be provided to the user.

It is unrealistic to expect an author to create different user experiences for every delivery context. Whenever possible, authored source content should be reused across multiple delivery contexts. By creating the content in XML, the same content can be adapted for different delivery contexts using XSLT or XQuery.
Delivery Perspective
The user agent is some software or firmware in a device (for example, a browser) that lets the user identify a web page to be rendered, assembles an appropriate request for that page (possibly including the delivery context), accepts the reply (delivery unit), and renders that reply into one or more perceivable units.

Before rendering, a user agent may apply client-side adaptation, perhaps under the control of adaptation preferences, to transform a delivery unit into a perceivable unit. It may be possible for a user agent, under the control of rendering preferences, to make local changes to a perceivable unit as it is rendered. This will depend on the local behavior of the user agent within the device. There are two relevant deliver principles at work here. First, the user agent should be able to associate the characteristics of the delivery context with a request for a particular web page. And, second, it should be possible for a user to provide or update any adaptation preferences as part of the delivery context.

.mobi Top Level Domain (TLD) Case

ICANN has received a proposal to introduce a Top Level Domain (TLD) specifically to identify, and possibly restrict, the type of user agent that can access the resources identified within this domain. The .mobi concept is strictly inconsistent with Device Independence principles, as long as content hosted at .mobi domains may be inaccessible from all devices except mobile devices.

Also, it is likely that there would be an ill-founded perception that ".mobi" sites should only link to other ".mobi" sites, to ensure that only tailored content is offered to mobile devices. This would create a web within the Web, potentially fragmenting the Web, and thereby harming it.

Conclusion

These principles can form the foundation of many approaches to achieving greater device independence. The principles are independent of any specific markup language, authoring style, or adaptation process. They do not propose specific requirements, guidelines, or technologies. In the next article we'll see how the Delivery Context can assist Device-independent presentation for the Web, as well as examine some current techniques for conveying delivery context information.