1 Introduction and Problem Statement

Along with the advent of the wireless Internet has emerged a unique set of challenges for the Web author. Not only does the developer have a much smaller screen on which to present his content, the devices that his audience may use to view the content are increasingly varied. It is becoming impractical to design multiple versions of a web site, each of which is geared toward a particular device or set of devices.

According to the W3C’s Authoring Scenarios[1] document, there are many implications to consider for content authors and authoring techniques. The following are addressed in this paper (section references refer to Authoring Scenarios document):

· Allow authors to support a wide variety of device capabilities without excessive effort (section 4.1.2)

· Protect applications from the appearance of new devices by providing mechanisms that allow them to be supported in some basic way without change to the existing site if at all possible (section 4.1.2)

· Authoring techniques that support Device Independence (DI) should allow authors to support a wide variety of devices with diverse capabilities without the need for detailed knowledge of the precise characteristics of each one. (section 6.2.4)

· Authoring techniques that support DI should allow authors to customise presentations for particular devices or classes of device. (section 6.2.4)

This position paper presents an alternative adaptation technique for delivering content and application to multiple devices, which takes advantage of device capabilities for a better user experience while keeping maintenance cost low and reuse of authored contents high.

2 Current Techniques

Table 1 lists some of the current techniques that try to address the above problem along with their respective advantages and disadvantages.

Technique	Advantages	Disadvantages
Abstracted API’s and Tags	· Abstracts device details	· Must maintain a local repository of profile information · Lack of granular control of user interfaces · Often times use vendor-proprietary tags and APIs
Direct Lookup	· Quick access to information · Gives granular control to authors	· Must constantly maintain profile information for accuracy and completeness · Does not take into account user preferences that can change in runtime · Author must add additional logic to make useful and efficient
HTTP Header Parsing	· Accurate information	· Limited information in header · Does not always take into account user preferences that can change in runtime · Author must add additional logic to make useful and efficient
Lowest Common Denominator (LCD)	· Least amount of work to implement	· “One size fits all” approach leads to very dull presentation · LCD profile could change with introduction of new devices · Still need to determine which markup language to serve (e.g. HTML, WML, XHTML?)
Profile Matching[2]	· Provides coarse grain technique of selecting presentation style	· Two profiles can contain ambiguous values – leading to unclear results or no matching at all
Stylesheet Selection	· Easily transforms XML content into other XML content (e.g. can display same content in HTML or WML)	· Author must have foreknowledge of device profiles to design stylesheets properly · No built-in mechanism to determine which stylesheet to select
Transcoding	· Abstracts device details	· Author who is using the transcoding technique must often times build his own repository of data · Unfriendly user interface due to trying to display content designed for PC to a wireless device

Table 1: Current DI Techniques

No single solution is the answer to the device independence problem.

3 A Solution

A solution that combines several of these techniques and extends them helps to alleviate the drawbacks. The “Add-On” technique combines the techniques of LCD, HTTP header parsing, profile matching and direct lookup.

The author begins by having a local repository of current profile information available to them. The author then must create profile groups that are broken up based on common features and navigation. Each of these groups will have an LCD profile associated with it. How many groups to create and which criteria to use is up to the author and will depend on the intended audience and content to be displayed.

The author then creates a base design for each group. This may be in the form of stylesheets, servlet pages or distinct static pages. These base designs are constructed using the LCD profile for each group. However, they should also have room for “add-ons”. For example, if an LCD profile for a group has a WML deck size of 1492 bytes, but several profiles in the group have larger deck sizes, the author can have an add-on to allow for larger deck sizes. In other words, the LCD profile is the author’s “baseline” design guide, but the add-ons allow the author to take advantage of additional capabilities within the group that don’t apply across the board.

Text Box: Retrieve corresponding base content Text Box: Determine correct profile group Text Box: Parse header for any additional information Text Box: Look up profile information in local repository This technique allows for different navigation and layout for different groups with the ability to take advantage of certain device's additional capability. Header information, though limited, can be helpful in determining user preferences and augmenting the profile originating from the profile repository. Figure 1 gives an overview of the process.

Figure 1: Add-on technique overview

Table 2 discusses how this technique overcomes some of the disadvantages of the previous techniques.

Current Technique	Current Disadvantages	How Solution Mitigates
Direct Lookup	· Must constantly maintain profile information for accuracy and completeness · Does not take into account user preferences that can change in runtime · Author must add additional logic to make useful and efficient	· Header information can sometimes reflect user preferences · Information about new devices (not contained in local repository) can be gleaned from header
HTTP Header Parsing	· Limited information in header	· Header information augments repository information – not sole source
Lowest Common Denominator (LCD)	· “One size fits all” approach leads to very dull presentation · LCD profile could change with introduction of new devices · Still need to determine which markup language to serve (e.g. HTML, WML, XHTML?)	· Add-ons allow author to take advantage of additional features, while still being able to leverage the LCD profile for a base design · Markup language should be criteria for determining profile groups
Profile Matching	· Two profiles can contain ambiguous values – leading to unclear results or no matching at all	· Profile groups should contain both user-agents and attribute ranges. Profiles can be matched using either approach.
Stylesheet selection	· Author must have foreknowledge of device profiles to design stylesheets properly · No built-in mechanism to determine which stylesheet to select	· Local repository provides user agent information to identify proper profile

Table 2: Advantages over current techniques

There are still disadvantages with this solution:

· Local repository must be maintained

· As new devices are added to the repository, LCD profiles for an author's particular group could change – perhaps causing a redesign

There is no easy way to get around maintaining a profile repository. With the exception of the HTTP Header technique, and perhaps the LCD technique, all the current techniques rely on having some form of repository of profile data available. Who maintains this repository can vary; it could be done by the author or by some commercial or community process. Nevertheless, there will be some form of repository in the process and someone must maintain it.

CC/PP and UAProf attempt to get around this requirement by placing profiles (or most likely a URI pointing to a server that contains the profile) in the header of an agent, however the net effect is that the "repository" is simply spread out over all the device manufacturer's servers at a substantial cost to them. Also, until these standards are fully accepted in the market, there must be support for those non-compliant devices that linger even after CC/PP gains momentum.

4 Conclusion [j1]

The Add-on technique provides content authors with a reliable and accurate method for presenting to a wide variety of devices. The four implications of device independent techniques outlined in the first section are achieved using this technique.

Implication	How Solution Mitigates
Allow authors to support a wide variety of device capabilities without excessive effort	Profile groups can be as coarse grained as the author desires.
Protect applications from the appearance of new devices by providing mechanisms that allow them to be supported in some basic way without change to the existing site if at all possible	Based on the preferred markup language given in the header, a new device can, at the very least, be given an LCD profile in its respective markup language.
Allow authors to support a wide variety of devices with diverse capabilities without the need for detailed knowledge of the precise characteristics of each one.	Profile groups can be as coarse grained as the author desires.
Allow authors to customise presentations for particular devices or classes of device.	Features of high-end devices can be utilized by add-ons to LCD profiles.

A different style or navigation for every device is impractical, while just one (LCD) navigation or style for all devices is not sufficient. Profile grouping gives the author enough flexibility to highlight certain device’s features, while easing the amount of up-front design work by grouping similar devices together.

[1] “Authoring Scenarios for Device Independence”, http://www.w3.org/2001/di/public/as/

[2] The term “profile matching” refers to the technique of matching an incoming profile against a known profile by comparing and contrasting attribute values to determine superiority, inferiority or equality.

1 Introduction and Problem Statement

2 Current Techniques

3 A Solution

4 Conclusion[j1]

4 Conclusion [j1]