The W3C Device Independence Activity includes the Device Independence Working Group (DIWG) which is in the process of creating a W3C Note reviewing current, standards-based techniques that may be useful in creating web sites that are device independent. As part of this work, DIWG invited Volantis Systems Ltd. and others to contribute information about commercial systems used to create and operate sites that support access from a wide variety of different devices with a wide range of characteristics. The aim is to illustrate additional techniques not generally available through existing standards.
This short paper outlines some specific characteristics of the approach that Volantis' products use to support device independence. It focuses primarily on mechanisms not currently available within existing standards and recommendations. In particular it discusses:
Subsequent sections in this paper address these and other topics in more detail.
The approach is based on the principles described in the DIWG's Device Independence Principles document. The techniques address many of the issues raised in the DIWG's Authoring Challenges document.
The DIWG has defined a number of terms, related to device independence, in its document Glossary of Terms for Device Independence. This contribution makes use of a number of those terms.
It is worth mentioning that the techniques described here are the result of more than three years practical experience in the creation and operation of sites that support a variety of devices. They have been used in well over 100 commercial projects over a wide range of size and complexity, from small simple static sites to large, highly dynamic, production applications. They are being used to support live systems that provide access for a wide range of types of device, including mobile phones, interactive television systems, personal digital assistants, smartphones and voice response systems.
The principle of separation of concerns first appeared within the realm of software engineering. Indeed it underpins practically all modern software engineering methods. Separation of concerns refers to the ability to identify, encapsulate and manipulate separately those parts of a system that are relevant to a particular concern.
A good example of the application of this principle outside the confines of software engineering is the separation of content and styling through the use of CSS with markup authored in, for example, XHTML. In this case, the content is written in XHTML while the styling associated with the presentation of the material is held in a separate CSS style sheet.
Volantis' approach extends the notion of separation of concerns to encompass other aspects of a web page. These include the physical layout of material and the use of media resources in addition to use of style sheets. More specific details are given later. In essence, any aspect of a web site that is inherently device dependent can be separated from the content and dealt with independently. The content, which is then essentially device independent, references any device dependent components using appropriate URLs. The references themselves are device independent. However, during the dereferencing process, adaptation occurs resulting in a user experience tailored to the device.
Authors can create multiple versions of device dependent resources for use in particular delivery contexts . A version might be very specific, applying to only a single type of device. Alternatively it might be reusable across a whole set of devices. This capability allows authors to choose how much effort is employed on supporting a particular type of device. It provides direct authoring support for the concepts of functional and harmonized user experiences.
One practical benefit from the separation of concerns is that materials can easily be reused. It is common, for example, for a single CSS style sheet to be used with a large number of pages of content in contemporary web sites. Modifications to the style of an entire site can be made simply by updating the appropriate style sheet. Similarly, separate explicit representations of layout and of media resources provide additional and significant opportunities for exploiting reuse.
Separation of concerns also allows tools to be created that concentrate on particular types of material and provide specialist support. Again, CSS provides some good examples. A number of vendors provide CSS editors that include facilities that assist in creation of valid style sheets. These facilities can include the ability to test the resulting style sheet for validity. They may also include the ability to prompt the author with appropriate values for particular fields where the allowable values are defined in the CSS specification. These additional types of facility offer considerable benefits for authors in comparison to the use of a general purpose text editor, for example.
These kinds of specialist tools are equally applicable to other kinds of resource. Even though a layout may be represented as an XML infoset, for example, a text-based XML editor may not be the most productive tool for creating or modifying it. Visual tools can offer significant benefits over text-based methods.
Volantis, has created a set of tools specifically designed to assist in the authoring of the various kinds of resource associated with its products.
Volantis provides an explicit model of the physical layout of material within a page. The content refers to a particular layout by means of a device independent URL. During adaptation, the most appropriate version of the layout for the current delivery context is selected from the available alternatives.
The following example discusses some content and part of a particular layout definition to which it refers.
<canvas layoutName="news">
<pane name="headline">
<h1>Flash Floods Devastate South of England!</h1>
</pane>
<pane name="summary">
<p>Last night's thunderstorms brought flooding to wide
areas of the south of England. Many roads are impassable today
and a number of villages have been cut off.</p>
</pane>
<pane name="details">
<p>In Hampshire, emergency services have been working through
the night to help the people of Twyford, seriously affected by
the storms.</p>
<p>In West Sussex, as the clean up operation continues,
contractors are working against the clock to shore up sea
defences in preparation for some of the highest spring tides
to be seen for the last twenty years.</p>
<p>Though Dorset escaped the worst of the damage, many minor
roads are passable only with extreme caution. Police are
urging drivers not to make any journeys that are not strictly
necessary.</p>
</pane>
<pane name="additionaldetails">
<p>The chaos has prompted the government to act to .....
...
...
</p>
</pane>
</canvas>
The example shows, a news story that is to be made available to a variety of different devices with different delivery contexts. This markup represents the device-independent content. The majority of the markup consists of elements familiar from XHTML. There are, however, two additional elements.
The first is the <canvas> element, which defines the top level authored unit containing device independent markup. This is the authored unit associated with the device independent URL used by the browser to reference this material. The layoutName attribute is a reference to the layout to be used. This is a URL referring, in this case, to a local layout named news. The contents of the layout are discussed below.
The second additional element is <pane>. This is a named area of a layout into which content can be targeted. It is similar in concept to a <region> in SMILTM.
In the example, sets of content to be targeted to various panes are enclosed within <pane> elements. It is also possible to specify a destination pane name on any element that can be targeted, providing a capability similar to that in SMIL for targeting content to regions.
<layoutFormat name="news">
...
...
<basicDeviceLayoutFormat deviceName="supadupa">
<gridFormat rows="2" columns="1">
<gridFormatRow>
<paneFormat name="headline"/>
</gridFormatRow>
<gridFormatRow>
<paneFormat name="summary"/>
</gridFormatRow>
</gridFormat>
</basicDeviceLayoutFormat>
...
...
<basicDeviceLayoutFormat deviceName="PC">
...
...
</basicDeviceLayoutFormat>
</layoutFormat>
The second part of the example is an extract from the layout itself. The <layoutFormat> element surrounds a set of <basicDevicelayoutFormat> elements each associated with a specific device or class of devices. One device dependent layout is shown for a mythical supadupa device, while another, for all PC class devices, is also shown, but without detail.
Associating layouts with named devices or classes of device has turned out in practice to be particularly convenient and is popular with authors. Grouping and hierarchy allows similar devices to be supported using common versions of layouts, rather than requiring every device to have its own.
In this particular example, the headline and summary panes are defined within the layout for the supadupa device. This example uses a grid-based layout with two rows in a single column. The result is that the panes are arranged vertically with headline above summary. This might be an appropriate arrangement for a small, mobile phone, for example. The relationship between the content and its destination in the layout is controlled by the name of the pane that it references.
No detailed positioning or size information is expressed explicitly in this example. This allows the browser to control these aspects of the perceivable unit. However, layout designers can specify additional information within the layout if desired. In addition, properties of the layout can also be influenced by associated stylistic information.
Other versions of this layout could arrange the panes in completely different ways, of course. There is no layout information within the device independent markup. It contains only references to panes. Consequently, the device independent markup is completely independent of the actual arrangement of panes within a given instance of a layout.
A simple mechanism for content control can be established using a basic rule concerning panes. If a pane referenced by the content does not exist in the version of the layout being used for the current delivery context, the content is omitted from the perceivable unit and consequently is not delivered to the device.
From the previous example, this rule results in only the content targeted at the headline and summary panes being delivered to the supadupa device. This might be appropriate if the device is, for example, a small mobile phone. Other versions of the layout, for example that for a PC, contain definitions for all panes, resulting in all of the content being delivered.
Although very basic, this technique is useful and can be employed to good effect in a variety of situations where simple content control is needed. The device independent markup remains free of conditional expressions and control of the content to be shown is completely within device dependent resources, in this case the layout.
Techniques for content variation based on layout may not be sufficient for every eventuality. They are complementary to techniques that act within the content markup itself. Volantis also includes such additional content selection techniques in its products. One such technique is discussed in Generalized Content Selection
Another facility that can be controlled via an explicit layout allows authors to specify how material is broken up for delivery to smaller devices. Within the layout definition, an author can specify sets of panes that constitute a single delivery unit. Volantis terms theses sets fragments. Each fragment is delivered as a separate page. The adaptation automatically creates the additional navigation required to allow users to access the material in different fragments. Authors can control various aspects of this generated navigation through properties associated with the layout and any associated stylistic information.
This mechanism provides authors with very precise control over the way in which material is organized for delivery to the device. Since the control is specified within device dependent material, very different organizations of the material can be easily created for use on different devices in different delivery contexts. The device independent content is unaffected. The relationship between the panes and fragments defines how the content is broken up.
This approach to decomposition is complementary to those that use hints within structured material to define points where adaptation may automatically choose to break materials into smaller units. Such techniques allow less precise control but are eminently suitable in particular situations. Volantis supports such hint-based techniques in addition to those based on layout.
CSS includes some capability for supporting different delivery contexts through use of Media Queries. This allows selection of different sets of stylistic information within a single style sheet to satisfy the needs of broad categories of device. However, the available facilities are not really ideal for coping with the very large numbers of types of device now available.
Volantis' approach to stylistic information is similar to that used for layout. A canvas can specify an entity known as a theme using a URL. A theme can be thought of as a set of CSS style sheets, each associated with a particular device or group of devices. Authors use a tool that is in essence a visual CSS editor to create and modify stylistic information.
During adaptation, the appropriate style sheet is chosen from the theme. Depending on the capabilities of the device, this may be used directly, may be converted to a different version of CSS or may be emulated in device-dependent markup.
In just the same way that different stylistic information or different layout may be needed to satisfy the needs of a particular delivery context, different versions of media resources may also be required. Images provide a simple example. On a desktop computer with large screen, a page may be able to include a large, detailed full color image for a particular purpose. The same page, used on a small mobile phone, may require a much smaller version of the image, and perhaps in grey scale rather than color. Different versions of the image, for use in different delivery contexts, can be created explicitly by an author. Alternatively, they can be created automatically by conversion from a master version. This type of conversion is usually known as transcoding.
As with layouts and stylistic information, the device independent markup references a media resource, such as an image, using a device independent URL. During adaptation, the most appropriate version of the resource for the current delivery context is selected from the available alternatives or created by transcoding. For example, using the <img> element, the src attribute is a device independent URL which references the resource for the image. The most appropriate version of the image is chosen or created during adaptation and is made available to the device.
In addition to support for the usual kinds of media, including images, audio and video, Volantis also includes this mechanism for text. It is convenient where, for example, different alternate text might be needed for an image depending on the delivery context. It may be possible to provide more comprehensive alternate text on a desktop computer, for example, than on a small mobile phone.
As has already been already noted, the mechanisms for content selection available in existing W3C recommendations, such as CSS, are not really ideal for providing the kind of generalized facilities needed to support very large numbers of types of device. As a result, DIWG has been working internally on generic mechanisms appropriate for use within an environment that is itself an XML document.
To assist in these discussions, Volantis proposed one particular content selection mechanism and has recently implemented it. The proposal is based on explicit markup which allows the content of one or more sub elements to be included, according to rules expressed as XPath expressions.
The following example illustrates the mechanism.
<select precept="matchevery">
<when expr="device:isInstanceOf('PC')">
<pane name="details">
<img src="pcimage"/>
</pane>
</when>
<when expr="number(device:getPolicyValue('PixelsX')) > 640">
<pane name="details">
<p>In Hampshire, emergency services have been working through
the night to help the people of Twyford, seriously affected by
the storms.</p>
<p>In West Sussex, as the clean up operation continues,
contractors are working against the clock to shore up sea
defences in preparation for some of the highest spring tides
to be seen for the last twenty years.</p>
<p>Though Dorset escaped the worst of the damage, many minor
roads are passable only with extreme caution. Police are
urging drivers not to make any journeys that are not strictly
necessary.</p>
</pane>
</when>
<otherwise>
<pane name="summary">
<p>Last night's thunderstorms brought flooding to wide
areas of the south of England. Many roads are impassable today
and a number of villages have been cut off.</p>
</pane>
</otherwise>
</select>
The example shows the select element being used to target content to different classes of device. The example is contrived to illustrate a number of features of the mechanism rather than being realistic.
The select element precept attribute controls its overall operation. In the example, it is set to matchevery. This causes the content of every when clause whose expr attribute evaluates to true to be included within the infoset. Other values of precept allow selection of just the first when clause whose expr attribute evaluates to true. Other uses of the expr attribute provide convenient short hand representations when the same expression is tested in every when clause.
The content of the otherwise element are used if no when clauses are used.
In the example, the content of each expr attribute is an XPath expression that evaluates to a boolean. These expressions include XPath functions that can access various information including that in the delivery context. For example, the function call device:isInstanceOf('PC') returns true if the device associated with the delivery context is considered to be some kind of personal computer. This result involves inference from the values actually associated with the delivery context. The expression number(device:getPolicyValue('PixelsX')) returns the width of the display associated with the device in pixels, as an XPath number, then used for comparison in the second when element.
It is worth pointing out here that the exact set of XPath functions that might be used, the parameters that they might accept and their relationship with the delivery context, are the subject of active discussion within DIWG at present. The ones used in the example are simply illustrations that work with the current Volantis representation of delivery context. The provision for namespace support within XPath function names allows distinction between sets of functions used within such expressions. In the example, the functions use the namespace prefix device.
The effect of the example is to include the image in the details pane or all PC class devices. Any devices with physical screen width of at least 640 pixels receive the text in the details pane. So PC's that are at least 640 pixels wide receive both image and text. Other devices that are not PC's but that do have screens at least 640 pixels wide receive only thext in the details pane. Finally, devices that are not PCs and do not have screens at least 640 pixels wide receive the summary information in the summary pane.
Although the example and the current implementation relates only to content, there is no particular relationship between the markup used to define the content selection and the content being selected. The same markup and expressions could be used to select layouts, stylistic information, media resources and indeed any material that is sensitive to the delivery context.
This paper has illustrated a number of techniques that are in use in one particular set of commercial products. These techniques extend existing standards and recommendations to assist in the construction of web sites and applications that can support wide varieties of devices with very different characteristics. They are the result of considerable practical experience in the construction and operation of such sites.