Authoring Scenarios for Device Independence

Informal public draft of possible W3C Note
29 July 2002

This version:
http://www.w3.org/2001/di/public/as/as-draft-20020729.html
Latest version:
http://www.w3.org/2001/di/public/as/
Previous version:
No previous public version
Editor:
Rhys Lewis (Volantis Systems) <rhys.lewis@volantis.com>
Contributors:
See Acknowledgements

Comments Included in this Version

Comments have been added to this document. Each is numbered according to the associated ToDo list. Each is also marked according to the action taken or required, if any.

Abstract

The document provides a discussion of several scenarios that web site authors commonly face when making content and applications available to users with devices of various capabilities The document examines the effects on authors and the implications for authoring techniques that assist in the preparation of sites that can support a wide variety of devices.

Status of this Document

This document has no official standing. It is an informal draft made available for comment and early feedback. It may contain sections that are incomplete or inconsistent.

This is a working draft and, as such, is subject to change. In particular, the number of example scenarios used to illustrate the discussion will grow in future versions of this draft.

This document is published as part of the W3C Device Independence Activity by the Device Independence Working Group. It is a deliverable as defined in the Charter of that group.

Comments on this document may be sent to the public www-di@w3.org mailing list (archived at http://lists.w3.org/Archives/Public/www-di/).

A list of current W3C Recommendations and other technical reports can be found at http://www.w3.org/TR.

Table of Contents

1 Introduction

1.1 Scope

(020714-048 - Investigate) Should the Scope section be called Goals to be in line with Device Independence Principles?

This note reviews the the challenges that web authors face in supporting access to their sites from a variety of different devices with a wide range of capabilities. The number and variety of types of device used to access the web continues to grow. As the resulting diversity increases, it becomes ever more difficult for authors to support the existing range of web sites and applications that are currently available. Any site, from the simplest home page to the most complex interactive application can be affected by the need to support access from a variety of types of device. The precise level of impact tends to increase with site complexity.

In addition to the challenges associated with supporting existing types of application, new devices offer additional opportunities for authors. For example, mobile devices are often aware of their location. This can allow appropriately authored applications to provide more useful information to users, for example. As another example, new types of device may be able to support interaction with the user via a range of modalities. They might operate with a conventional display under certain circumstances but use voice under others. Authors need to be able to support such additional capabilities where they exist.

The burden placed on authors by the diversity of newer devices is significant. The affordability of creating and maintaining web sites and applications that support a range of devices is a major concern. Without mechanisms to alleviate the authoring efforts associated with creating and supporting such a large set of diverse devices, authors will not be in a position to provide the universal access that is such an important aspiration of the web.

One primary objective of this note is to identify the difficulties that authors face in an environment in which there is an increasingly diverse set of devices used to access web sites. Another objective of the note is to define the implications of these challenges for any mechanisms intended to help authors deal with this diversity.

The scenarios discussed in this note and the resulting conclusions of this note will form one of the bases for future work carried out by the Device Independence Working Group (DIWG).

The following list summarises the overall goals for authoring techniques that aim to assist authors in supporting the diversity in devices. Throughout this document such approaches are referred to by the term authoring techniques that assist DI.

  1. Authoring techniques that assist DI should allow creation and delivery of sites and applications with at least the range of function already available in the existing web, but with the added capability of supporting all applicable devices.
  2. Authoring techniques that assist DI should allow authors to exploit new capabilities in devices within the sites and applications that they create.
  3. Authoring techniques that assist DI should support all applicable devices within the effort and cost constraints acceptable to the author

The term applicable devices is used to emphasise the observation that some functions might not be available on some devices. For example, it would probably not be appropriate to attempt to stream a movie to a device that supports only audio modality. The choice of whether or not a device is an applicable device probably rests with the author, unless there is some technical restriction in the device that prevents a particular function being supported.

(020617-003) Stephane Maes comments:
I would recommend that device-independent authoring be defined as:

In addition, device-independent authoring relates:

The present document should target the compilation of authoring scenarios used or proposed today to address one of all of the items above.

(020714-002) Lalitha comments:
IMHO this is actually 2 goals - ability to author and deliver (new) content for multiple devices, and, abiltity to render existing apps to multiple delivery contexts (in other words backward compatibility)

Axel comments:
It I would be nice to target both goals (new and old content), however I'm pretty unsure whether it is possible to deliver the same quality for both sources. There might be special annotation for customization in the new content that won't be there for the old sources, unless they are added afterwards (that implies that we allow external modeling). However to get right expectation it should be stated that DI for old application might imply worse quality or extra work.

Shlomit comments
I believe that backward compatibility is not an authoring issue. After all the targeted sites for backward compatibility had been authored already. We might choose to mention this important issue and point out to where it is addressed, but imho, this is not the place in which we need to address this issue. I believe it is an important issue and should affect new UA’s. Maybe the newly authored sites need to be recognized as such so that the old ones, by default, will be recognized as old and will therefore be treated differently. The main assumption in backward compatibility is that the author does not touch the old site, yet the new UA handles it correctly.

Rhys adds:
The comments above show that there is not yet concensus on whether or not we should explicitly discuss the need to provide the means to support existing sites or not within this document. From a practical point of view, it is clear that mechanisms that allow reuse of existing sites in part or in full are of significant commercial interest. However, we have not reached concensus about whether or not to cover this issue in this particular note. Could we have more discussion of this item please?

1.2 Audience

This note is intended as background material for people interested in the problems associated with delivering content and applications from web sites to devices with very different capabilities.

In particular, the audience for this note includes:

1.3 Organisation of the Material

The note starts by examining the various roles that authors can play in the development of a web site. It then describes the notion of applications on the web and looks at the various kinds of content that is employed. Discussion then turns to analysis of the diversity of devices and the means by which they connect to the web. The implications of the ability of users to tailor their experience of the web are then covered, together with discussion of accessibility. Finally, the implications of supporting multiple devices on the affordability of site creation are discussed.

Throughout the discussion, the note describes the needs of authors and the consequent implications for authoring techniques that aim to help them in their tasks. These implications effectively form the basis for a set of requirements on such techniques.

1.4 Terminology

The Device Independence Working Group defined a number of terms in the working draft entitled Device Independence Principles. The terms are summarised in the Glossary of the draft.

This note makes use of a number of terms from the Device Independence Principles. A few of the terms are reproduced here for convenience.

access mechanism
a combination of hardware (including one or more devices and network connections) and software (including one or more user agents) that allows a user to perceive and interact with the Web using one or more interaction modalities (sight, sound, keyboard, voice etc.)
adaptation process
a process of selection, generation or modification that produces some presentation data in response to a requested Web page identifier in a given delivery context
customised presentation
a functional presentation of a Web page that is well enough adapted to a given delivery context to meet the quality criteria of the author
device
an apparatus through which a user can perceive and interact with the Web
delivery context
a set of attributes that characterises the capabilities of the access mechanism and the preferences of the user
functional presentation
a presentation that enables the user to complete, via a given access mechanism, the function intended by the author for the given Web page identifier
user agent
a process within a device that renders the presentation data for a Web page into physical effects that can be perceived and interacted with by the user

2 Authoring Roles

This note discusses various scenarios concerned with authoring web sites. However, the term "Authoring" covers a wide variety of activities, particularly where the site in question implements significant application function in addition to information presentation. This section describes the various activities usually associated with web site creation in terms of a set of roles that are commonly undertaken by its authors. A role is not necessarily identified with an individual author. It is possible, and for small sites quite likely, that more than one role will be performed by an individual. Conversely, for very complex sites, a given role might be distributed among several authors.

There are three broad categories of web site authors. One category includes the designers of the site's user interface, including its look and feel. A second category includes the creators of all of the site's content. The final category includes the creators of the business logic associated with the site.

While no categorisation like this is perfect, it gives a framework in which to discuss specific scenarios in the rest of the note. The remainder of this section covers these three categories of authoring roles in more detail and introduces some of the potential impacts on them caused by a need to support a wide range of devices.

2.1 Interface Designers

The design of a site is associated closely with the way it appears to its users. The usability of a site is heavily influenced by its design. The following sections categorise the various roles that site designers play.

(020714-070)Axel comments:
I have a feeling that there are too much of those designer and it's becoming hard to distinguish between them. For me a Layout Designers takes care about the Style, Font's, Colors .... Anyhow this might be handled different in other companies and for completeness it might be OK to include them.

Even so I would like to propose an additional designer that takes care about the device specific implementation of controls, layout... This designer needs to be a device expert in terms of Usability and  the specific functions on a device. The reasoning behind that is that I don't want application authors nor Layout Designers (that care more for branding and stuff) to care about the device dependent part, because of their lack of experience. 

Rhys adds:
The role of a Layout designer is just layout. Styles, colours fonts and so on are the preserve of the stylistic designer. We are discussing roles here not individuals. We said at the Ottawa face to face that it would be normal for a single designer to take on more than one role. In practice, the separation of layout design from other aspects of style is quite important and I think this definitely deserves to be viewed as a separate role.

As for device expertise, most site developers that I have experience of are not device experts and are very keen that the DI authoring technique they use protects them from having to invest in that expertise. Luu made the point at the Ottawa face to face that in general authoring should work at the level of device capability and not at the level of support for specific devices. So, I'd prefer not to add this role which seems to be contrary to that goal.

Resolution:
On the DIWG call 2002-08-14 it was decided that some discussion that device expertise needs to be added. Device expertise needs to be captured somewhere within the overall adaptation process but that it should be expressed in a way that is reusable. The aim is to avoid the requirement for every author to have device expertise. The discussion should be in the section on authoring roles but should avoid identifying this in such a way that there is a presumption that individuals are always required for this role.

2.1.1 Layout Designers

Layout designers specify the physical placement of material on the output of the device. Typically this involves the arrangement of text, associated images and other media within a single page. However, the role of the layout designer changes when the access device has output mechanisms other than visual display. For example, the designer may need to specify the sequence in which information is spoken. The options available to the layout designer are heavily influenced by the capabilities of the target device, such as the size and resolution of its display.

2.1.2 Stylistic Designers

The stylistic design of a site is essentially its "look and feel". It includes the selection of fonts and colours and the development of graphics used for elements such as icons, branding and backgrounds. It also includes stylistic elements of other kinds of media, such as audio and video. For example, where a device has spoken output, stylistic design might include the selection of the qualities of the particular voice used under various circumstances. Stylistic design is also heavily influenced by the capabilities of the target device and preferences expressed by the user.

(020714-079) Shlomit comments:
The paragraph of the stylistic design should not interrupt the flow of the others that are closely related. I would move it to the beginning or the end of the Design section.

Rhys adds:
I feel that this is a fairly natural place for this section and I'd prefer to leave it here if that's ok.

2.1.3 Interaction Designers

Interaction designers specify the way that users interact with a site. In particular, interaction designers specify how interactions occur within a page. This might include defining the order in which data is entered on a particular page. It might also include defining the particular kind of user interface abstraction employed for entering each value. Interaction design takes place at a level abstract from the particular capabilities of the device. For example, an interface designer might specify that data entry for a particular field uses a mechanism where the user selects a single value from a set. The stylistic designer might interpret this as use of a drop-down list control on a particular device.

Interaction design is often more abstract than other aspects of the design. It may be less influenced by the nature of the target device. Often, the same or similar interaction can be implemented on a wide range of devices, if a sufficiently abstract view is taken. The W3C XForms specification is an example of such an abstraction.

2.1.4 Navigation Designers

Navigation designers specify the paths that visitors may take through a site. Navigation is, of course, implemented by the use of links. The way in which such links are represented is defined by the stylistic design. For example, links might be presented as a list of text items, or as a complex, dynamic cascading menu. In either case, it is the set of links, rather than its presentation, that defines the available navigation from the current page.

(020714-071)Axel comments:
Question for me to understand: Is interaction design is more inner-page design and navigation design is more between pages? If so the interaction design is more related to "controls"  while Navigation Design is the linkage. In my opinion an interaction designer that defines the flow of a single application page (e.g. ordering of data entries) should as well design the overall flow of the application for consistency reasons.

Rhys adds:
I think the distinction is more between traditional user interface actions and navigation. We've tended to think about the core of XForms, for example, as interaction. I think you are right about the navigation point. We tend to think of navigation term more in terms of moving between pages. However, in a multi-device environment, the navigation used with one kind of device may be very different from that on a different device. What appears to be navigation between pages on one device might be presented as navigation within a page on a different device. Indeed, it might not be navigation at all on some devices.

Your point on interaction design is well made. In certain parts of an application, navigation is an important part of the overall interaction. Designing which parts of an interaction go into which pages and the order in which those are presented is a key aspect of design. However, this is not the only place in which navigation design is important. Since, once again, this section discusses roles. I think it's fine to distinguish navigation design (which, for example, can include the creation of the site map), from interaction design, (for example the design of a form). It would be fine for an individual to take on both roles in particular pieces of work.

Shlomit comments:
When we deal with an audio site, the navigation, layout and interaction become one due to the linear nature of  a single channel through which the user and the site interact. While the two dimensions of a graphic display allow us to think separately about layout and navigation, we cannot do it when the site is audio in nature. I also do not see the need to put navigation and interaction as two separate design issues. My tendency would be to speak about the three under the title of “interaction†and recognize that in a graphic display the navigation and the intercation can be thought of separately from the layout.

Rhys adds:
There are certainly situations in which the mode of interaction for navigation is the same as that of for example, data entry. However, that does not mean that the two operations are identical. Navigation is a different operation from that of supplying a value in a form input field. In an audio interaction, for example using a VoiceXML site and a telephone, the user expresses all operations as voice commands or key pad entries. However, navigation is still fundamentally different from supplying values for input fields.

So, in summary, I think there are two distinct roles, but, as mentioned above, sometimes these overlap in certain aspects of the design.

2.2 Content Creators

The content used on a site includes text, graphics, images, audio and video resources. Development of these resources is the task of content creators. There is some overlap here with stylistic design. For example, the icons to be used on a site might be designed by a stylistic designer but created as part of the content of the site. Development of content can demand many skills. Creation of text content requires conventional writing skills while development of images and graphics needs expertise in the graphics arts. Audio content for a site might include music and may require another set of performance and production skills.

(020714-080)Shlomit comments:
It so happened to be that the stylistic designer has the SKILLS required to create a logo but the HATS of logo design and stylistic design do not overlap. We should not mix skills, roles, and individuals. We can say a word in the beginning of the Roles Section about how one individual might wear a few hats and how a role might require more than one skill and therefore might be distributed among few individuals, but we should keep clear the separation between skills and roles. I would, therefore, reconsider the previous paragraph. This remark is in th espirit of my suggested modification to the opening paragraph of Section 2.

Content creation is often directly affected by the need to support many types of target device. It may be necessary to create different versions of content, particularly images, audio and other rich media, to cater for the different capabilities of various devices. Creation of alternate forms of content may also be necessary so that material can be delivered to devices that cannot support particular kinds of content. Increasingly, authors prepare content that includes more semantic information. For example, textual web content is often constructed using XML documents where the markup indicates the purpose of the material rather than defining its presentation. This aspect of content creation becomes increasingly important as the need to support a variety of devices with very different capabilities increases.

2.3 Business Logic Creators

Sites that support applications typically require business logic to be implemented. Applications made available by enterprises in support of their business are a good example. On-line shops, for example, fall into this category.

Business logic must be designed and developed. The design of business logic can be relatively abstract if best practice application design is followed. However, the details of its implementation usually depend heavily on the capabilities of the particular type of server on which the site is running. Business logic can be shielded from the details of the device being used by the interaction design.

2.4 Interactions Between Roles

This section is under construction.

(020714-008) Lalitha commented:
Illustrations in the context of use cases/ scenarios would be quite helpful. We should give an example. Such as, Here is a music company. Music content is created as .mp3 files. It is then transformed into .au. The navigation designers do this and the interaction designers do that. It is marked up in this way for this device, etc.

(020624-009) The DIWG F2F meeting in Ottawa commented:

Discuss the data that flows between different authoring roles
Rhys adds:
Axel has provided one possible view of the relationships
in the following diagram
. However, see the discussion in 020714-070 about the device designer role.

Axel's view of relationships

(020714-056) Luu comments:
This would be a good place to insert a graphic illustrating the workflow processes involved in authoring different kinds of web sites, from simple information presentation sites to complex interactive application sites

(020714-072) Axel comments:
Question: Who connects the business data and the content: The Business Logic Creator or the Content creators?

Resolution:
On the DIWG call 2002-08-14 it was agreed not to go to this level of detail in discussion of the roles associated with authoring.


2.5 Summary

Design and implementation of a web site involves a number of activities that can be categorised in terms of the roles of the authors that perform them. Some of these activities are more abstract than others and, as a result, their authors are less likely to be affected by the particular device being used to access the site. Later sections of this note describe in more detail how specific features of sites, users, devices and the networks that connect them affect the requirements placed on mechanisms that support device independence.

(020714-081) Shlomit comments:
I am not sure of the role of section 2.5. I do not see the need for a summary paragraph.

3 Applications and Content

(020617-005)  Stephane Maes comments:
We may want to select a few applications that covers these categories, explain them one and for all and then see what are the different approaches to DI author or re purpose them.

Rhys Lewis adds:
I think you are right. The discussion of re purposingg and new authoring is orthogonal to application types. Perhaps we should have a section at the end of each of these chapters, or at the end of the document, that gathers together the 'lessons' of the examples into some kind of requirement for the authoring work. One approach would be to break out repurposing and new authoring requirements in that/those sections.

(020714-049) Luu comments:
I think it would be useful in sections 3.x - 6.x to hi light the various roles that we define in section 2 so that readers can focus on the items that are applicable to them.  For every instance of the word "author", use instead the more specific authoring role that is applicable.
 

(020714-050) Luu comments:
Also, in keeping with the charter description of this document, we might want to have specific requirements hi lighted in sections 3.x - 6.x.  We could number them "AS-nn: Requirement name" similar to DIP's "DIP-nn: Principle name" and style them similar to DIP's principles.  Instead of "Implications for Approaches that Support DI", should we use "Requirements for device independent authoring techniques"?

(020729-002) Rotan comments:
We should ensure that at least one of the scenarios that we use includes a printer

This section provides detailed discussion of site features that authors would like to be able to provide to end users. Web sites can be considered as applications that consist of content, presentation, navigation and business logic. There is a wide range of types of such applications. They range from the simplest, non-interactive applications, whose prime role is to inform, to complex, highly functional applications offering services such as e-commerce. In practice, many web sites consist of a combination of various kinds of application.

The section first examines the implications of application interactivity. Then it discusses the types and sources of content used in such applications. discuss various types of content. In each case the implications for authors of the need to support multiple devices is considered. The implications for any authoring technique that seeks to support device independence is also considered.

3.1 Application Interactivity

3.1.1 Non-Interactive Applications

The simplest kinds of applications involve no user interaction. They present information but do not offer any interaction, other than simple navigation. This kind of application is seen in simple personal home pages where the content is also usually static. Applications that can present selected content, such as product catalogues and sites that distribute news articles may also be essentially non-interactive. In these types of application, there may be business logic associated with the retrieval of the data, even though the presentation is non-interactive. In the case of sites that distribute news articles, for example, the presentation is often common to all articles. The content varies from article to article. It is typically retrieved from a content management system or database. There is no user interaction, other than navigation, despite the fact that there may be business logic associated with retrieving the correct article.

(020714-073)Axel comments: Essentially for non-interactive applications is in my view that the application remains the same independent on what data is submitted. The application does not react on user input (except navigation). I would therefore consider applications or pages that are created from database as non-interactive as long as data input does not effect the application. E.g. if the selection the first digit in an address book modifies the pages so only the appropriate names  (all names starting with a) are shown then I would already assume that the application is interactive

Shlomit comments:
It will help to support the last sentence with an example.

Rhys adds:
I've expanded the news article into an example.

3.1.1.1 Considerations for Authors

From an author's perspective, creating the simplest pages should be the simplest operation. This is as true when supporting multiple devices as when supporting just a single device. The overhead of supporting multiple devices must not be prohibitive, even when the page is simple. Ideally, it should be small in comparison with the effort required to write the page for a single device.

Simple pages may require business logic and access to dynamically acquired or generated data. Consequently, authors may need to be able to combine such data sources with the ability to support presentation on multiple devices.

Even the simplest, non-interactive applications usually rely on the ability of the user to navigate between pages. Navigation designers would like to be able to specify this navigation once, despite the fact that differences in capabilities mean that the details often need to be varied between different devices.

Variations in device capability can affect a number of aspects of the way in which material is delivered to them and presented. One obvious consideration is the total amount of material that the device can accommodate in a single page. Authors may wish to vary the amount of information presented for a given page on different devices. On small devices, for example, authors may wish to present some kind of summary rather than the full information. Alternatively, an author might wish to present all of the information by structuring it as a set of smaller pages, requiring additional navigation.

Content creators need ways to provide alternate versions of media assets for use by different kinds of device while maintaining the same information semantics. For example, a particular picture might need to be supplied as a PNG image for use on a personal computer, a smaller PNG image for use on a personal digital assistant and a WBMP image for use on WAP phone. For some devices, which accept more than one type of a particular asset, a content creator may wish to select the kind that gives a higher quality presentation.

(020714-059) Luu comments:
We should consider using "resources" instead of "assets"
Resolution:
On the DIWG regular teleconference call on 2002-08-14 it was agreed that this change would be made.

Content creators may wish to provide assets of a completely different type for use on certain kinds of device. Rather than a video clip, an audio clip might be appropriate on a device with no display. Likewise, an image might be an appropriate alternative on a device with a display but no video capability. In the absence of any appropriate media capability, content creators may need to be able to specify text to be used in its place.

3.1.1.2 Implications for Authoring Techniques that Support DI

From the authoring considerations, it is possible to infer some desirable characteristics of authoring techniques that aid in development of non-interactive applications that support multiple delivery contexts.

  1. Authoring techniques should make it simple to develop simple applications. In addition, the effort involved in developing more complex applications should scale smoothly with their complexity.
  2. Authoring techniques should minimise the overhead associated with the need to support different navigation schemes to present the same material on different devices.
  3. Authoring techniques should support the ability to vary the amount of material delivered to different devices and to change the way it is organised for presentation.
  4. Authoring techniques should support the use of different versions of media, such as images and audio clips, on different devices.

The ability to integrate dynamically acquired or generated content with presentation suitable for multiple devices, is a server implementation issue. It has no direct bearing on the requirements for authoring techniques that support device independence.

3.1.2 Interactive Applications

Interactive applications can involve any of the features of non-interactive applications but add some kind of user input and control operations. The normal expression of such an interaction in existing applications delivered via the web is the construct known as the Form. Fields of various kinds are presented to the user and receive input of various types. These basic kinds of interaction are described in this section. In later sections, more complex interactions involving explicit use of functions executing on the device are considered.

3.1.2.1 Considerations for Authors

Interactive applications can use any of the features of non-interactive applications. Consequently, all of the authoring considerations for non-interactive applications apply.

The interaction capabilities of various devices vary enormously. For example, some have full keyboards, some have tiny keypads, while some have no keyboard at all. Some have sophisticated pointing devices, some have styli and some have only keys with which to select and navigate. Some allow full audio interaction and some allow none. Interaction designers would like to be able to minimise the effort involved in defining an interaction for different devices that may have very different user interface capabilities.

Basic navigation was included in the discussion of non-interactive applications. Navigation is often an important feature of interactive applications and frequently involves more sophisticated client-side function. In addition to user interfaces and navigation, interactive applications may also provide the ability for users to control embedded rich media players via user interface controls. Interaction and navigation designers  need to be able to supply these user interfaces and provide facilities for more complex navigation.

3.1.2.2 Implications for Authoring Techniques that Support DI

Once again, from the authoring considerations, it is possible to infer some desirable characteristics of authoring techniques that aid in development of applications that support multiple delivery contexts.

  1. Authoring techniques should offer authors the ability to abstract as much of the specification of an interaction as possible. This reduces the need to specify separate interactions for each type of device. Standards such as the W3C XForms specification offer a good example of how some kinds of interaction can be abstracted.
  2. Authoring techniques should offer this kind of abstraction capability for data entry, data selection, control functions and navigation.
  3. Authoring techniques should extend their support, for the ability to vary the amount of material delivered to different devices and the way it is organised for presentation, to include elements concerned with interaction.
(020714-074)Axel comments:
In addition to that device classifications might lead to device classes that share a certain behaviour in terms of interaction
Rhys adds:
I think this is a discussion point. So far we've resisted the temptation to discuss new techniques in this note. We have referred to other standards work but not suggested new solutions. While Axel's comment is perfectly valid, and indeed is exploited in some commercial implementations of DI authoring, it might be better to delay discussion of new solutions until the Interaction Markup deliverable.

3.2 Application Dynamics

3.2.1 Static Content

Static content is material that is authored directly into the page. Often this consists of text and of fixed media assets, referenced explicitly from elements in the page. This type of content is most usually associated with the simplest, non-interactive applications, such as personal home pages.

3.2.1.1 Considerations for Authors

The main consideration for this kind of content is the same as for the kind of applications that use it. In particular, it must be simple to use this kind of simple content with multiple devices. This is the kind of content most often used by the least experienced authors.

3.2.1.2 Implications for Authoring Techniques that Support DI
  1. Authoring techniques should make it easy to use this simplest form of content when authoring pages

3.2.2 Dynamically Acquired Raw Application Data

Authors frequently need to integrate application data with presentation when creating web pages. In this discussion, raw application data is considered to be data that does not contain any information that controls its own presentation. This kind of data might consist of product numbers, product names and prices in a product catalogue, for example. The raw data might be retrieved from a database and merged with additional material to create the finished page.

Raw application data can be dynamically acquired from many kinds of source, including

Data returned from these types of source might be in a variety of formats. Web services, for example, return data as XML documents. Other sources might return it as comma separated lists, individual fields or in proprietary formats. Whatever its source, the common feature of this type of data is that it includes no information that controls its own presentation.

3.2.2.1 Considerations for Authors

Authors should be able to create applications that support multiple delivery contexts while using this type of content without excessive effort.

(020714-064)Luu comments
Replace "Authors" with "Content creators"
in the previous paragraph
Rhys adds:
Again, I'm not sure this is correct. It's not only content creators that are involved in development of the application components the use raw application data. I think the generic term Authors is probably best here.

3.2.2.2 Implications for Authoring Techniques that Support DI

The process of integrating raw application data with material that controls presentation does not directly concern authoring techniques that support DI. This level of integration is normally provided by the programming or transformation capability of the run time system on which the web site is executing.

There is one potential issue for authoring techniques that support DI. This concerns situations in which the amount of application data to be presented is not known until execution time. As a result, it is possible that there will be more data than the device, or at least the chosen layout can accommodate. This suggests the following implication:

  1. Authoring techniques that support DI should provide facilities that assist authors in managing the integration of application data with presentation material to accommodate the limitations in display size and storage capability.

(020714-084) Shlomit comments:
If some of the raw data is  provided by the client and is feeding the business logic, there are considerations that affect the page design. Typically the author would try to minimize the number of interactions between the client and the server and this, of course, affects a page design. When the interaction is audio and completely linear-serial, the author might take advantage of the client’s resources and, when possible, collect client’s input before sending it to the server.  

Rhys adds:
I think this section was originally written considering only server-side data. This is an interesting point and deserves inclusion. I think that the section on application interactivity could be the best place. Comments please.

3.2.3 Dynamically Acquired Data Containing Presentation Markup

Authors may need to integrate dynamically acquired content, that itself includes presentation markup, within their own markup when creating web pages. The dynamically acquired material might originate in a database, or other form of system for managing content. It might also originate from a partner's web site.

(020714-065)Luu comments
Replace "Authors" with "Content creators"
in the previous paragraph
Rhys adds:
Again, I'm not sure this is correct. It's not only content creators that are involved in development of the application components the use this type of application data. I think the generic term Authors is probably best here.

In contrast with raw application data, this kind of content includes information that controls its own presentation. In existing applications, this material usually consists of specific statements written in a markup language such as HTML. Elements such as headings and paragraphs are quite common, for example. However, not all the content for a page is necessarily retrieved dynamically. The final page could be the result of merging static content with static presentation and dynamic content, for example.

Examples of pages often created using this type of approach include

3.2.3.1 Considerations for Authors

Authors need to be able to integrate their presentation easily with content that is marked up in a variety of ways that may be incompatible with the target device.

3.2.3.2 Implications for Authoring Techniques that Support DI

The integration of application data that includes material that controls its own presentation is of direct concern to authoring techniques that support DI. There are two basic situations that might apply. The presentation material in the data might be device-specific or it might be device-independent.

In either case, the authoring technique in use will need to transform the embedded material into a form appropriate for the target delivery context. Transformation of device-independent representations, is a simpler task. Indeed it is probably the case that there is no way to guarantee that automatic transformation of device-dependent material can, in general, lead to a even a functional presentation. As a simple example of the challenge, imagine transforming 100 search results from your favourite search engine for delivery to a WAP mobile phone, using only inspection of the HTML generated for presentation on a personal computer.

In general, device-independent representations of presentation must have features that facilitate this kind of mapping, since that is the principle on which they work. Consequently, such representations should be easier to transform when encountered within dynamically acquired data.

(020729-004) Lalitha commented:
We should add discussion of presentation-independent markup in dynamically acquired data

3.2.4 Dynamically Acquired Media Assets

Just as with markup, some applications require dynamic selection of media assets for use in particular pages. For example, in a catalogue application, some of the raw application data might define the image that illustrates a particular product. Where multiple devices are in use, it must be possible to select or create appropriate versions for the particular device in use.

3.2.4.1 Considerations for Authors

Authors need to be able to acquire information about the media assets to be used dynamically and then use that information to ensure that an asset appropriate for the device is actually used.

3.2.4.2 Implications for Authoring Techniques that Support DI

The needs of the author lead to the following desirable characteristics of authoring techniques that support multiple devices.

  1. Authoring techniques should be able to support the use of different versions of media assets of different devices
  2. It should be possible to specify the set of assets to be considered for use
  3. Authoring techniques should provide the ability to create an appropriate media asset by conversion from an equivalent asset with different properties, if necessary.
  4. It should be easy to influence the selection operation to ensure that appropriate assets are used for particular devices

3.3 Applications with Client-Side Function

Many practical applications in current web sites rely on execution of some function on the user's device. In this note it is termed client-side function to distinguish it from application function executing on web servers.

The program code associated with client-side function is highly dependent on the user's device. It is sensitive to the precise details of the execution environment on the device. For most types of application, this environment is provided by the User Agent being used on the device. This is normally termed the browser. Often, and especially with smaller devices, there is a single user agent available for a given device. On larger devices, there may be a choice. For example, there are HTML and WML user agents available for some current Personal Digital Assistants. For personal computers, a large range of different user agents is available.

Different device and user agent combinations often require different languages for client-side function. Languages in common use include:

However, even when the same language is used, details in the execution environment can mean that different programming code is required to implement the same client-side function on different devices.

Client side function is used for a variety of purposes. Often it is used to provide advanced navigation function through the use of user interface controls such as drop down or cascading menus. It is also used to provide features such as immediate user input validation, improving responsiveness by eliminating the need for data to be returned to the server for checking. It may even be used to cause dynamic changes to the capabilities of the device itself by, for example, downloading additional information, such as a media codec.

3.3.1 Considerations for Authors

Applications that use client-side function are usually interactive. Consequently, all of the considerations for non-interactive and interactive applications apply to them as well.

The client-side programming capabilities of devices vary enormously. Even within individual client-side languages, differences in the execution environment mean that different code can be needed when different user agents are in use. Authors would like to be able to specify functions that require client-side support in ways that avoid the need to write different code for each individual combination of device and user agent. However, there may be situations, especially when a presentation needs to be customised for a particular delivery context, where an author will need the ability to create specific client-side function. In addition, authors need to be able to provide functional presentations that are equivalent to those that use client-side function, even when the device and user agent in use cannot provide the appropriate client-side function and all processing must occur on the server.

(020714-062)Luu comments
Replace "Authors" with "Content creators"
in the previous paragraph
Rhys adds:
I don't think this is actually the correct change. Content creators are not necessarily the only authors that might do this. Navigation implementers might use client side capabilities such as drop-down menus for example. I think the generic term Authors is probably best here.

3.3.2 Implications for Authoring Techniques that Support DI

From the authoring considerations, it is possible to infer some desirable characteristics of approaches that aid in development of applications that support multiple delivery contexts.

  1. Authoring techniques should allow authors to make use of advanced client-side capabilities including the ability to execute code
  2. Authoring techniques should allow interactions to be created that exploit client-side function without the need for the author to provide the code explicitly. This implies that the interaction abstractions used by the author are sufficiently powerful to hide the device-specific differences that affect the implementation. The approach can then provide appropriate implementations of the client-side function for each supported combination of device and user-agent. It can also provide a server side implementation for use when client-side function is not available or is inappropriate.
  3. Authoring techniques should allow authors to provide client-side function explicitly if needed to support a customised presentation.

3.4 Applications Using Rich Media Content

Any application, whether interactive or not, may include rich media content, such as audio or video clips. Where such an application is interactive, part of its interaction with the user may involve control of the playback of the rich media content. Rich media applications may support sources that stream content, such as Internet Radio or Video feeds.

3.4.1 Considerations for Authors

Where the application is non-interactive, all authoring considerations for non-interactive applications apply. Similarly, where the application is interactive, all considerations for interactive applications apply. If the application involves control of the way in which the rich media is presented, this may involve the use of client-side function. In this case, all considerations for applications that make use of such function also apply.

As with other forms of media, such as images, content creators may need to be able to supply rich media assets in various forms to cater for the needs of various devices and networks. Versions appropriate to particular media players may need to be provided, for example. In addition, to accommodate differences in network bandwidth, different degrees of compression might also need to be supported.

(020714-075) Axel comments:
Streaming media was mentioned as content before. I belief that streaming media is out of scope ?!
Rhys adds:
Do you mean that DI authoring should not provide support for streaming media? Personally I don't think we should restrict our scope by ignoring streaming media, especially given the likely commercial interest in mobile devices with streaming audio and video capabilities on 3G networks. This is another point for general discussion I think.

(020714-082) Shlomit comments:
When modifying navigation from a graphic presentation to a voice interaction, the navigation tree must be linearised. This is a subject that deserves our attention but maybe it is sufficient to just mention it here without diving into the technical approach of how to handle it.

Rhys adds:
This is a good comment. However, I'm not sure this is the best place for it. Rich media content is usually associated just with output. I think of watching video clips or listening to music rather than performing some interactive operations. Perhaps it should be in a section where we are discussing navigation? I'd be interested in further comments on this.

3.4.2 Implications for Authoring Techniques that Support DI

Once again, from the authoring considerations, it is possible to infer some desirable characteristics of approaches that aid in development of applications that support multiple delivery contexts.

  1. Authoring techniques should be able to support the use of different versions of rich media assets on different devices.
  2. Authoring techniques  should support the ability to control rich media interactions on different devices in different ways. This implies that the interaction abstractions used by the author should be sufficiently powerful to hide the device and user-agent specific differences that affect the implementation.
(020714-083) Shlomit comments:
Approaches should allow for recognising menus and present them consecutively for audio environment and  in parallel for graphic environment.
Rhys adds:
Same additional comment as for 020714-082 above.

3.5 Applications Supporting Synchronised Access Mechanisms

This section is under construction. The details of its content have not yet been established.

3.6 Application Complexity

There is a huge diversity of applications delivered via the web. We've already seen a number of classes of application, from the simplest, non-interactive sites, characterised by personal home pages, to the most sophisticated, interactive sites, using dynamic content and often encountered in connection with commercial activity, such as e-commerce.

3.6.1 Considerations for Authors

The level of effort required of authors in constructing a site should not be disproportionate to the site's level of sophistication and complexity. In particular, it should be relatively simple to build simple applications that support multiple devices. This will allow even inexperienced authors to benefit from having their applications universally available.

As well as supporting simple sites, Authoring techniques that support DI should allow construction of sophisticated applications that satisfy the needs of even the most demanding authors. This will allow sophisticated sites to be made available universally.

3.6.2 Implications for Authoring Techniques that Support DI

The needs of the author lead to the following desirable characteristics of authoring techniques that support multiple devices.

  1. Authoring techniques should support the full range of applications from the simplest to the most complex
  2. Authoring techniques should scale smoothly in complexity as the underlying application becomes more sophisticated

4 Devices and Access Mechanisms

The challenge presented by the growth of diversity in the kinds of device that are used to access the web is often not appreciated by people not intimately involved in providing support for them. This section examines the types of device currently in use, the ways in which they connect to the web and the consequent implications for authors.

The networks used to connect to the web can play an important part in the overall characteristics of the attached device. Both devices and networks are considered in this section.

4.1 Device Diversity

Until the appearance of mobile devices, such as WAP enabled mobile phones, there was relatively little diversity between the means by which users accessed the web. The differences in capabilities between the dozen or so different browsers available for the computers most used to access web content were, and still are, accommodated by custom code being added to sites. Though the browsers do differ in detail, it is quite possible to build a wide variety of types of application that work tolerably well, by making broad assumptions about the capability of the user's system and by providing additional textual material to aid accessibility.
(020714-076) Axel comments:
in terms of technology, usability ... AS: Those assumptions should not only technical overlaps in my opinion. One of the most urgent problems is usability therefore the broad assumptions should (also) base on usability of devices.

Rhys adds:
The assertion about building applications that work tolerably well across a variety of user's systems relates to the current situation on the web where most people use PC type browsers and the differences relate mainly to the details of the way specific HTML features and client side programming work.
It is not meant to imply that this is the way forward. Do you think that we need more clarification here to make this clear?

However, the situation with respect to devices is changing rapidly. At the time of writing, there are now several hundred different types of device that can have web access. Among these devices there are huge variations in capability of processing, display and input.

As an example of the variability, consider some common categories of device that can access the web.

(020714-078) Axel comments:
Classification that compare devices from a usability perspective might be added later
Rhys adds:
It is not clear to me that such a classification is possible. It seems to me that the usability of a device is not an absolute metric. It depends on the person using it. Someone with visual impairment may well find a full colour PDA less usable than a telephone with a numeric keypad for certain operations. Usability is a combination of some metrics of the device itself together with preferences expressed by the particular user. Could we have some additional views on this please?

Workstations
In this category are the familiar types of computer most usually associated with access to the web. It includes personal computers, laptops, and high performance workstations. Devices in this category tend to have powerful processors, large displays, sound output, large amounts of memory and persistent local storage. They usually provide a graphical user interface and have input capabilities that include a keyboard and pointing device, such as a mouse or touchpad. They may be portable. They are able to use a range of different network connections, both wired and wireless and varying considerably in speed.
Personal Digital Assistants (PDA)
Physically much smaller than workstations, PDA's still tend to provide reasonable sized displays, and sound output. They have less powerful processors and less memory than workstations and much less persistent local storage. Input capabilities are also more limited, often employing a stylus and writing surface on the display, or a miniature keyboard. PDA's are similar to workstations in the range of available network connections they support. They are portable.
Mobile Phones
The emphasis for mobile phones is on portability, small size and light weight being important design goals. There is also a need for extended battery life. As a result, mobile phones tend to have lower power processors and less memory than PDA's. They also have smaller screens and most have only a numeric keypad that doubles as a keyboard using special input methods. Network connections are via the phone's link to it's network. The connection speeds typically available tend to be lower than those usually used with workstation devices.
Voice Systems
Voice systems provide connection to the web from standard telephone handsets. Portability depends on the portability of the handset used to access them. They have no display, output being spoken to the user. Input is either via voice recognition, or by means of the numeric keypad on the handset. Network connections to the web are wired and are usually high speed.
Printers
Printers provide non-interactive presentations of web pages. They exhibit a huge variety of physical sizes, resolutions, printing technology and speed.

Subsequent sections consider in detail the differences between devices that are most important, in terms of their ability to affect the presentation of material from the web.

4.1.1 Considerations for Authors

The range of capabilities of the large number of different devices that now have the ability to access the web is a major challenge for authors. In addition, new devices with different capabilities are being released regularly. Authors need authoring techniques that can allow them to support the diversity of existing devices without requiring excessive effort.

The large number of devices becoming available means that authors are often unaware of new developments. Even if they are, there is often a limited ability for them to update their applications to support every new device that appears. Consequently, authors would like access to authoring techniques that can provide some level of support to new devices without needing any changes to existing applications.

4.1.2 Implications for Authoring Techniques that Support DI

To support the enormous variability in device characteristics, authoring techniques that support DI should

  1. Allow authors to support a wide variety of device capabilities without excessive effort
  2. Provide mechanisms that allow authors to express the presentation they need while abstracting the capabilities of the device
(020714-085)Shlomit comments:
I am not sure that I understand this bullet. Do you mean here that there is the need to express needed capabilities of the device in an abstract manner?

Rhys adds:
I've reworded the bullet a little. I think the sense we are trying to get is that authors should be able to express the presentation in terms of the capabilities of the device, not just its name.

  1. 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
(020714-085)Shlomit comments:
Do you mean here to provide backward compatibility for future, yet non existing devices?
Rhys adds:
Yes, except that I would probably term it forward compatibility. There are examples of systems that can automatically cater for new devices without requiring that authors change their sites. There are practical limitations of course. The new devices must bear a reasonable behaviourrnce to something already in existence. However this tends to be the case for the majority of new devices released.

(020714-067)Luu comments:
While it's implied, I think it might be worth mentioning the following two requirements either here or at the end of section 4.2:

Device independent authoring techniques must provide access to delivery context information.  This allows designers and content creators to associate different designs, content, behavior, media resources, etc. to different devices.

Device independent authoring techniques should provide access to specific capabilities of a delivery context.  This allows designers and content creators to more effectively associate different designs, content, behavior, media resources, etc. to different devices by targetting specific capabilities instead of specific devices.

Rhys adds:
The first of these seems to dictate a particular implementation model. It seems to imply that as an author, I'll have to write pages that include statements like 'If device capability X then do Y'. This is how some systems work, but others have declarative semantics that mean the author does not explicitly need to use delivery context information in a procedural sense. The second is probably alright, specifically because it avoids the use of 'must' but we should discuss these.


Resolution
On the DIWG call 2002-08-14 it was agreed that there should be some comments in this section about the relationship between delivery context and authoring. The comment should cover author's needs and expectations about being able to specify aspects of presentation based on properties available via the delivery context. The comments must be made in a way that does not effectively specify any particular implementation.

4.2 Awareness of the Access Mechanism

The access mechanism by which the application and the device communicate may consist of many components. The characteristics of the access mechanism certainly include the characteristics of the device itself and of the network by which it is connected to the web. In this section, some of these characteristics are described to see why they are important in the presentation of applications. 

This section is not an exhaustive discussion of these characteristics, nor does it describe the environment in which such information is made available to authoring techniques that support DI. That discussion can be found in the document "Delivery Context for Device Independence". This section confines discussion to the importance of some of the key characteristics for authors. In general terms, authors need to be able to express their instructions about the way that access mechanism characteristics are used in determining how material is adapted for presentation on the target device.

Users may be able to personalise various characteristics of their device. The effect of this type of capability on authoring techniques that support DI is discussed in  Personalisation. This section confines its discussion to the underlying physical characteristics of the devices and access mechanisms.

(020714-088)Shlomit comments:
Personal preferences of the client (e.g. large fonts) need to be fit the screen constraints.
Rhys adds:
We have a section on personalisation later, so I simply added a reference to it here.

4.2.1 Device Characteristics

Some characteristics of the access mechanism are closely associated with the device. This section covers some of the more important of these characteristics.

4.2.1.1 Screen Size and Resolution

The physical size of the display on a device is almost invariably a static property. The physical resolution of the display, for example, the number of pixels in the horizontal and vertical directions, is also essentially static. However, the resolution actually in use in any particular situation might be different from the natural values associated with the device hardware. It is quite common, for example, for CRT and LCD displays to be able to operate in a variety of modes when attached to devices such as personal computers and workstations. These modes often include the ability for the display to act as a window onto a larger desktop. While such resolution changes are less common on smaller devices, such as PDA's, it is, nonetheless, possible to find displays used in portrait or landscape mode in different situations.

The way in which a device is used also has implications for the effective size and resolution of its screen. Digital television systems, for example, have resolutions approaching those of a basic personal computer. However, the distance from user to device is much larger for a television system than for a personal computer. As a result, it is necessary to use larger fonts and images than would be the case for a personal computer, and the effective size of the screen is less.

Screen size and resolution are particularly important for authoring techniques that support DI. Not only are they important considerations in defining the appropriate visual media assets to use, they are also a major determinant in the design of the physical layout of the presentation. Authors may need to design different physical layouts and different ways of organising presentation of material to take account of differences in the size and resolution of the displays in use.

(020714-087)Shlomit comments:
The use of the device is also related to the screen constraints. The distance, for instance, of the viewer from the screen (e.g. iTV) requires large fonts and therefore affects the layout and the design of the page.

Rhys adds:
I've included an additional paragraph on viewing distance.

4.2.1.2 Colour capability

The colour capability of the display on a device is also usually a static property. However, user agents may elect not to use the full capability, leading to variability in colour support. For colour displays and printers, it is often expressed simply as some measure of the number of different shades and colours that the display can generate. In more demanding applications, for example those that demand photo realism, knowledge of other parameters such as the gamma factor of a display or the physical characteristics of the ink and paper used for printing, are important in generating customised presentations.

The colour capability of a display is important for authoring techniques that support DI. Like physical screen size, colour capability can be important in defining the appropriate visual media assets to use, particularly where multiple versions with different colour properties are available.

4.2.1.3 Video capability

Some devices are inherently capable of displaying video clips. Others depend upon browsers or installed applications to provide the support. Once again, although the capability may vary based on configuration or installation of special software, video capabilities are usually considered as a static property of the device. As with other media assets, the primary importance, from the standpoint of authoring techniques that support DI, is in ensuring that appropriate versions are used that are compatible with the device's capabilities.

4.2.1.4 Audio capability

As with video capabilities, some devices are inherently capable of playing audio clips. Others depend upon browsers or installed applications to provide the support. Indeed, it is common for the same software to provide both audio and video capabilities. As with video, although the capability may vary based on configuration or installation of special software, audio capabilities are usually considered as a static property of the device. As with other media assets, the primary importance, from the standpoint of authoring techniques that support DI, is in ensuring that appropriate versions are used that are compatible with the device's capabilities.

In addition to this consideration, however, audio has other potential alternate uses in authoring techniques that support DI. Under the right circumstances, appropriate audio might provide a useful alternative to video or image media assets on devices with no display, for example.

4.2.1.5 Input capabilities

Input capabilities on devices vary enormously. Workstation devices with full keyboards are usually considered convenient for input of large quantities of data. Mobile phones, often with little more than a simple keypad, are generally considered not to be. In some situations, it might be possible for users to express personal preferences associated with particular device input capabilities. Such preferences are discussed in Physical Input and Output

The ease of use of a device's input facilities is of importance to an interaction designer. It might be that the interaction between an application and its users needs to be simplified for use on devices without sophisticated input capabilities. In the extreme case, complete functions might be omitted when such a device is in use. Complex application registration procedures, for example, that require completion of relatively large forms with many fields may simply be inappropriate on, for example, basic mobile phones.

The importance of knowledge of a device's input capabilities to authoring techniques that support DI is in providing the ability for designers to control how interactions are expressed on devices with very different capabilities.

4.2.2 Network Characteristics

Some characteristics of an access mechanism are closely associated with the network through which the device is connected. This section describes theses characteristics.

4.2.2.1 Declared bandwidth

The declared bandwidth, is the bandwidth, and hence the speed of data transfer, inherently associated with the device and the network it is connected to. The declared bandwidth for an access mechanism is a static property. For a mobile phone on the GSM network, for example, the declared bandwidth might be 2400 baud. The actual bandwidth will vary from minute to minute and will depend on many factors, including how busy the network is. However, the declared bandwidth is a reasonable starting point for making decisions about how the application runs based on the speed with which data can be exchanged with the end user.

Bandwidth can be an important consideration for authoring techniques that support DI. Content creators may wish to make available versions of media assets, often the largest single items on a page, specifically optimised for low bandwidth connections. A content creator might even prefer to provide alternatives, such as text, for use on very slow connections, for example. On faster connections, they might want to provide versions of video clips compressed by different amounts to accommodate access mechanisms with a variety of different bandwidths.

4.2.2.2 Actual bandwidth

Some access mechanisms provide information about the bandwidth that is currently available to the device. Where this information is available, it can be used in conjunction with, or in place of the declared bandwidth just discussed. The implications for DI of actual bandwidth values are identical to those for declared bandwidth. The only difference is in the timeliness of the values.

4.2.3 Other Characteristics

There are other characteristics of the access mechanism that may not easily be assigned to device or network. These characteristics are covered in this section.

4.2.2.1 User preferences

In the discussion so far, only characteristics of the access mechanism itself have been considered. However, end users may have a significant effect on the characteristics of the device, for example, if they are able to personalise its properties. The personalisation of the access mechanism for the purposes of Accessibility warrants its own section in this note. They are covered later in the section Personalisation and Accessibility.

4.2.2.2 Location

Some mobile devices and access mechanisms are able to report their current location. This is clearly a dynamic characteristic of the device. While other dynamic characteristics can have an influence on presentation, location is more likely to have an effect on content. For example, an application that presents information about retail opportunities will tailor the content presented based on the user's location. However, the way in which the material is presented is not likely to be sensitive to the user's location. Location is likely to be more interesting for applications than for authoring techniques that support DI.

(020714-047) Rotan commented:
I think the point about the difference between characteristics that affect presentation and those that affect content should be promoted to a separate section earlier in this document. It is a very important point and deserves early clarification. In essence: the only characteristics that DI is concerned with are those that may influence the format and structure of content, and not of the information represented by the content. Location is a very good example of a characteristic that may influence the information within the content but not its format or structure.
Rhys added:

This is an important summary list, but I'm not sure if it belongs here or in the DCO document. I've added this to the list for investigation.

(020714-090) Shlomit commented:
Users€™s location might cause a change in language and this does affect the presentation, not only the content.
Rhys adds:
At the face to face in Ottawa, I think we decided that this was not the case. I would personally be somewhat inconvenienced if my mobile phone suddenly switched into French as I emerged from the Channel Tunnel at Calais! You are absolutely right that change of language affects presentation, but I don't believe that location influences language in general.

(020714-091) Shlomit commented:
In fact, for applications, location might be quite challenging. If we speak, for example, about transactions, change of country might have many consequences. Is location in our scope? If not, we might mention it and then say that this is not in the DI scope. Or maybe, like later with personalisation, we do include certain simple things related to location like money format.
Rhys adds:

I think we have come to an opinion that location does not directly influence presentation. The current wording of the section takes this position. I have not made any further changes to it.

4.3 Changes in the Access Capability

Where systems support access from multiple devices, it can be necessary to consider the effect of the same user accessing applications from different devices at different times. Essentially, the nature of the access method changes between successive accesses to the application.

This section describes scenarios in which this might occur.

4.3.1 Shared Bookmarks

User's may need to access the same URIs with different devices. Consider the following scenario.

Shared Bookmark Scenario

Ms. Kaseem is a teenager with low vision who is also deaf. She uses the Web to find new restaurants to go to with her friends and classmates. At home she uses a combination of screen magnifier and screen reader with refreshable braille to browse the Web. She also has a portable braille device which she uses in public places such as malls and restaurants. (See the teenager example from How People with Disabilities Use the Web [PWD] for a detailed outline of the use case).

(020714-068)Luu commented:
The PWD link is not correctly specified

This particular example is based on a user with a need for accessibility. The need for access to applications from multiple devices is, of course, not restricted to users with special accessibility needs. The important point for this discussion is that it may be very convenient for the devices used to be able to share bookmarks of important applications.

Authors would like their sites to be accessible via URIs that can be used from multiple devices with a minimum of effort. From the perspective of an authoring technique that supports DI, this probably implies that it is advantageous for the URI's associated with pages that support DI to be independent of the device accessing them.

4.3.2 Access Method Alteration During a Transaction

The natural consequence of the ability for a user to access the same applications on a variety of devices is that they may wish to start a business transaction on one device and complete it on another. Consider the following scenario:

Transaction Continuation Scenario

Angela subscribes to a service run by a local concert hall that informs her of late availability of tickets at discount prices. At work one morning, she receives notification of availability of tickets for a concert including Mahler's Fifth Symphony. She has been waiting for the opportunity to take her mother to a Mahler concert for some time. Using her PC she provisionally books two tickets in prime locations in the knowledge that she must purchase them within 6 hours or lose the booking. She bookmarks the acknowledgement returned by the concert hall and synchronises it with her PDA. Later in the day, on the way back to the office after a meeting with a client, she finally manages to contact her mother, who is delighted at the invitation and looking forward to the concert. Angela realises that she must confirm the booking soon. She returns to the concert hall's application using her PDA and mobile phone. She confirms the booking and pays for the tickets.

In this scenario there is an explicit change of access method during the transaction. The booking is made on one device, the payment on another. Much of the capability required to do this is, of course, a function of the application. It must be able to maintain the state of the transaction over some period of time. Indeed, there is probably little impact on the presentation of the requirement to provide this capability as long as the authoring technique being used does not preclude it.

(020714-092) Shlomit comments:
I am afraid that this is not the best scenario. Even if both the reservation and the purchase happen on the same device, it is not right to consider them as two parts of the same transaction. It is quite likely that Angela closes the connection with the concert hall€™s web site (or , if not, being timed out by the concert Hall€™s server) and opens a new communication after her conversation with her mother.

I tried to come up with a somewhat different scenario. How about the following: Angela purchases tickets on her PDA while walking andrds her office. She reaches her desk while in the midst of the transaction and wishes to switch to her PC on which she can view a map of the concert hall and  the available seats.

Rhys adds:
Actually, I think the scenario is fine as it stands. It depends on the definition of transaction. It is common to consider a 'business transaction' which spans many steps, each of which itself might be a transaction in the traditional sense (two-phase commit etc.). This is what we have here. There is a significant literature on technologies for direct support of such long running, multi-step transactions, which are also known as sagas. Regardless of the underlying application technology, I think its fine to describe this scenario as a transaction.

(020617-007) Stephane Maes comments:
There is another related scenario here. This occurs when there is a change in the synchronization granularity.

(020617-008) Stephane Maes comments:
There is another related scenario here. This occurs when there is a change in the number of channels.

5 Personalisation and Accessibility

The ability for an author to exercise some level of control over the presentation of a web site is an important capability of the web. Not only does it allow users to specify their own personal preferences, it is also an important component in the ability for the web to provide presentations that increase accessibility.

This section discusses the authoring implications of personalisation in general and at how that may affect accessibility in particular.

5.1 Personalisation

The term personalisation, when used in relation to web sites and applications, covers much more than the ability for a user to influence aspects of its presentation. Increasingly, applications offer users the ability to tailor the function available to best suit their needs. Much of this personalisation activity is related to application function that does not directly affect the presentation or user interface. However, that part of personalisation that is relevant for presentation is of direct concern to authors when creating sites that support multiple delivery contexts. A user might, for example, select one particular type of presentation capability on the device in preference to others. Equally, a user might wish to prevent use of a particular device capability.

It is theoretically possible for a user to change the personalisation associated with the presentation of material on their device as often as they wish. In practice, however, changes in personalisation during a particular interaction are likely to be relatively infrequent.

(020714-089) Shlomit commented:
While user preference can be changed as frequently as the user desires, from the application perspective it is static, I believe. It is unlikely that the preferences  will change during a single run of an application.
Rhys adds:
I've taken the liberty of adding the change for this comment to the section on personalisation.


From the viewpoint of authors and of authoring techniques that support DI, the ability to personalise presentation effectively provides additional criteria that effect the process by which output is specialised for a particular delivery context.

5.1.1 Physical Input and Output

Many of the presentation properties that a user may wish to personalise are associated with the physical input and output operations of the device. For example, a user might choose to modify the font sizes or colours used by a page to improve legibility. Likewise, a user might prefer writing on a device over using its input keys. They might elect to avoid using the keyboard of the device, preferring to make use of its handwriting recognition capabilities instead.

Some kinds of device even allow a user to select the resolution of the display in use and to change between portrait and landscape modes.

Where a device offers multiple modalities, a user might choose to use other than the default. This could be for reasons associated with accessibility. Accessibility will be discussed in a later section. It could also be that in certain circumstances one particular modality of the device is more appropriate than another. For example, there might be a mobile device that offers a conventional display and miniature keyboard, but that offers the alternative of audio output and voice recognition. While at home or in the office, a user might prefer to use the display and keyboard, but might change the modality to be voice-based while using it in the car.

5.1.1.1 Considerations for Authors

From the perspective of the author, the ability of a user to specify preferences may mean that additional materials need to be provided. Personalisation of presentation generally works well within the bounds of the materials that author allows or supports. Consequently, it is possible that support for preferences associated with presentation could cause the need for different versions of content, stylistic information layout and media to be available.

Authors need access to techniques that make the creation and management of this material as simple as possible.

5.1.1.2 Implications for Authoring Techniques that Support DI

From the considerations for authors, the following requirements arise.

  1. Authoring techniques that support DI should allow presentation-related personalisation information to be included during the process of specialisation of material for the device.
  2. The modality of the device should also be taken into consideration during the adaptation process

5.1.2 Language

Like personalisation, the selection of the language to be used to communicate with the user has many implications for web sites and applications. However, only a few of those implications are directly related to the presentation of the material.

One aspect of presentation that can be affected by language, is layout. For example, the direction in which the characters of a particular language is rendered might affect whether a portrait or landscape layout is more appropriate for a particular part of the page. Similarly, the length of words in a particular language might cause the need for the arrangement of labelled buttons in a form to be altered to optimise the use of the available space.

In addition, where media assets, such as images, contain text, it will be necessary to include additional versions to support multiple languages.

5.1.2.1 Considerations for Authors

From the perspective of the author, the presentational aspects of supporting multiple languages does not really introduce any fundamentally new challenges. However, language support can mean that additional versions of layouts, media and stylistic information might be needed.

5.1.2.2 Implications for Authoring Techniques that Support DI

From the discussions it is clear that

  1. Authoring techniques that support DI should allow language to influence the adaptation process under the appropriate conditions
  2. In particular, authoring techniques should allow language to influence the choice of the layout and styles used for particular devices
  3. Although not strictly a DI issue, authoring techniques that support DI might usefully support the ability to include language in the control of selection or creation of the media assets to be used for a particular device.

5.1.3 Cost

In some geographies and for some networks, users might be especially sensitive to the cost of transmission of material between their device and the servers that provide it. In this kind of situation, users might employ personalisation to control such costs. For example, a user might elect to view only small, greys cale images as opposed to the large colour images that their device can support. Similarly, they might elect not to receive images at all, preferring some kind of alternate, text based representation of the information.

Consider the following scenario:

Mr. Wright has purchased pre-paid GPRS enabled re purposings sons, Jimmy and Tommy. While they both like to download the latest Dennis the Menace cartoon from the same Web site, Jimmy and Tommy however have different views on how to spend the $30 pre-paid card their dad has given them. Jimmy prefers the cartoon to be downloaded as high resolution images most of the time, while Tommy prefers a small picture in low resolution graphics, thus saving up to chat with his friends via instant messages later.

5.1.3.1 Considerations for Authors

Once again, from the perspective of the author, the presentational aspects of supporting personalisation based on cost does not really introduce any fundamentally new challenges. However, this type of personalisation might mean that additional versions of materials, and in particular media assets, might be needed.

5.1.3.2 Implications for Authoring Techniques that Support DI

There are really no new implications for authoring techniques that support DI. The same kinds of issues arise as have been covered already. The difference here is in the motivation of the user for applying the personalisation.

5.2 Personalisation for Accessibility

(020617-010)Stephane Maes comments:
The discussion should address:

(020617-011) Stephane Maes comments:

It is possible to view accessibility as one of the applications of personalisation. From a user's perspective it is, of course, much more than the ability to change presentation to match taste. Accessibility concerns the ability of users to change presentation to allow them to perceive and use the information conveyed and to interact with the application.

The mechanisms involved in supporting accessibility are, however, just the same as those for personalisation of presentation. The considerations for authors are the just the same, as are the implications for authoring techniques that support DI.

5.3 Specialised Devices for Accessibility

Although personalisation used for accessibility is essentially the same as personalisation for other reasons, at least in a technical sense, devices that promote types of accessibility may be very different from those normally encountered. In particular, there may be devices which produce output, such as Braille, that is very different from that normally encountered. In this example, of course, the output is an entirely new modality.

5.3.1 Considerations for Authors

Once again, the implications for authors centre around the need to provide content, layout and thematic information that is appropriate for the new types of device. This is, in principle, a simple extension of ideas that have already been discussed several times. However, the new feature here is the potential need for radical approaches where the device has capabilities, such as Braille output, that are very different from those associated with more conventional systems.

Many of the issues may, in fact, be design related rather than implementation related. The rules for layout of an appealing and attractive web page for display on a Braille device are likely to be very different from those for use on a conventional PC display.

5.3.2 Implications for Authoring Techniques that Support DI

The implications for authoring techniques that support DI are not very different from those already discussed. As long as the mechanisms are available to create or select different content, layout, thematic information and media assets, support for new devices is in principle possible. In addition, however, newer devices for accessibility may well be multi-modal. Consequently, all of the implications already discussed for those types of devices will also apply here.

6 Affordability

(020624-018) The DIWG F2F in Ottawa commented:

(020624-019) The DIWG F2F in Ottawa commented:

(020624-021 The DIWG F2F in Ottawa commented:

(020714-069) Luu commented:
I'm not sure if this is a topic for affordability, but we should mention somewhere that DI authoring techniques must support existing infrastructure, i.e. be backward compatible with existing technology.  For example, while we advocate CC/PP as the preferred mechanisms for determining delivery context, DI authoring techniques must also work with pre-CC/PP mechanisms, e.g. user-agent HTTP header.

Rhys adds:
This is a very interesting point, with which I happen to disagree. I think we need to discuss this further. Personally, I don't think we can require that a technique be fully backward compatible in order to qualify as being one which supports DI. It is clear that there is a need for mechanisms that are backward compatible. Indeed this is the case for all existing commercial solutions. I think it is highly desireable that mechanisms be backward compatible. However, I don't think we can demand that this be the case. I do agree, however, that any new work we do, which proposes mechanisms for DI, must take into account the reality of the existing set of standards and practices in common use on the web.


Resolution
On  the DIWG call 2002-08-14 it was agreed not to raise these particular issues here. The concensus was that  these are issues for the techniques document. This document should remain independent of implementation.

In a very real sense, almost all of the considerations for authors, that have been discussed in this note, are associated with the affordability of creating applications. It is possible to support access the web from a large number of different access mechanisms by writing an entire site for each one. This is not, however, an affordable solution when the number of devices involved is several hundred and growing continually.

Affordability is an important consideration for authors when making the decision to participate in any new technology. There are a number of individual considerations for authors, associated with affordability. Each is considered in the this section. They include familiarity, the costs of device diversity, the possibility of automatic support for devices and the ability to target effort in customising the presentation.

6.1 Familiarity

One good way to reduce the cost of an implementation is to ensure that existing skills can be easily transferred. If authors find an approach familiar, they can become productive with it quickly and without the need for lengthy retraining. They may also be able to use familiar tools with the new approach.

Many existing W3C recommendations are applicable in providing elements of authoring techniques that support DI. These recommendations are already familiar to web authors. They can provide the basis for such approaches whilst allowing authors to apply their knowledge and expertise.

6.1.1 Implications for Authoring Techniques that Support DI

To maximise familiarity, Authoring techniques that support DI should be based on existing W3C recommendations wherever possible. In particular:

  1. Elements, of an authoring technique supporting DI, that involve explicit definition of presentational markup should be based on the W3C XHTML family of specifications
  2. Elements, of an authoring technique supporting DI, that involve explicit definition of interaction models should be based on the W3C XForms specification
  3. Elements, of an authoring technique supporting DI, that involve transformation of information between forms should be based on the W3C XML and XSLT specifications
  4. Any new definitions that fall completely outside the realm of existing, presentation-related recommendations should be based on the W3C XML specification

6.2 Device Diversity

There are now literally hundreds of different devices that have the capability to connect to the web. There is enormous diversity in the facilities offered by such devices. This diversity poses a significant challenge for authors.

There are, of course, basic standards covering groups of devices. For small, mobile, devices, for example, W3C recommendations, such as XHTML Basic and candidate recommendations, such as CSS Mobile Profile might be used. Alternatively, the device might follow the Open Mobile Association's WAP Specifications. Frequently, however, there is variation in the way in which manufacturers implement the standards. Sometimes the implementation maybe incomplete. Sometimes the implementation may extend beyond the standard. Authors must find ways to cater for this level of variability even within a specific standard.

The standards that are applicable to web access from devices rightly do not constrain the physical characteristics of the device itself. As has already been mentioned, display size, media capabilities, input mechanisms and even modalities can vary greatly between devices. Applications designed to run on a device with one particular set of such characteristics behave poorly or fail to work at all when the device has characteristics very different from those envisaged by the author. New network capabilities, associated with technologies such as GPRS (General Packet Radio Service) and the so-called third generation, high speed, networks compound the challenge for authors.

Another challenge for authors is not simply the diversity of the devices that already exist, but the rate at which new devices are being introduced. The potential maintenance effort associated with keeping a web site current while supporting new devices as they appear is very significant.

6.2.1 Functional Presentation

A functional presentation of an application is one that allows the user to complete the function intended by the author on a particular device. Although functional, the presentation is not necessarily optimised for the device, or other aspects of the delivery context. In addition, it does not necessarily exploit any special capabilities that the device may possess. Functional presentations can play an important role in improving the affordability of an authoring technique that supports DI. In particular, affordability can be improved greatly if a functional presentation can be created with a minimum of authoring effort, and without the need for the author to have specific expertise concerning the device being supported.

6.2.2 Customised Presentation

In contrast with functional presentations, customised presentations are specifically tailored to the target device and delivery context. A customised presentation probably implies that an author has provided additional materials over and above those required for a functional presentation to improve the overall experience of using the application for the end user.

The degree to which a presentation is customised should be under the control of the author. From an affordability standpoint, an author should be able to apply as little or as much customisation as is necessary to achieve the overall quality of application interaction appropriate for the device and delivery context in question. In addition, the effort required to customise a presentation should rise smoothly. There should not be a large increase in cost associated with a small change in the customisation of the presentation.

6.2.3 Considerations for Authors

Authors are faced with major challenges as device diversity increases. The effort in just maintaining a site can quickly become unaffordable as the number of devices increases. In addition, as new devices appear there may be time pressures in providing support that may also be difficult to satisfy.

Authors can also be faced with the challenge of maintaining expertise in the characteristics of a large and growing set of devices. Once again, the challenge of simply maintaining the device expertise can quickly overwhelm the available resources. Affordability is compromised, for example, if support for new devices requires authors to change the application. Authors would like functional presentation on the majority of new devices to be provided automatically.

Authors should be able to create functional presentations for additional devices with little or no effort and without the need for special expertise. They should be able to invest as little or as much additional effort in customising presentation for selected devices and delivery contexts.

6.2.4 Implications for Authoring Techniques that Support DI

The challenges of supporting large numbers of diverse devices suggest the following characteristics of approaches that support DI:

  1. Authoring techniques should allow authors to support a wide variety of devices with diverse capabilities with a minimum amount of effort
  2. Authoring techniques that support 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.
  3. Authoring techniques that support DI should allow functional presentations to be created with a minimum of effort.
  4. Authoring techniques that support DI should allow authors to customise presentations for particular devices or classes of device.
  5. Authoring techniques that support DI should allow authors to exploit the capabilities of a device in a customised presentation if the wish to do so.
  6. Authoring techniques that support DI should allow authors to choose how much effort to invest in customising presentation for particular devices or classes of device.
  7. The relationship between the amount of effort invested by an author and the level of customisation of the presentation should be simple and smooth with no discontinuities.
  8. Authoring techniques that support DI should allow support for functional presentation, on devices not considered during development of an application, to be provided without the need for additional authoring effort wherever possible.

6.3 Reuse

Reuse of materials is another way to enhance the affordability of support for multiple devices. There are two broad aspects of reuse. The first is the ability to author new material that can be shared by presentations used for multiple devices. The second is the ability to use materials previously authored for single device versions of an application in a new version that supports many different devices.

6.3.1 Considerations for Authors

The desirability of reuse for authors is self evident. There is a significant reduction in effort required for developing application presentations if new material can be authored once and reused across many devices. Likewise, if existing material can be used in a new site that supports a range of devices, overall effort can be reduced.

Authors would like to be able to use new materials to support a range of devices wherever possible. They would also like to be able to use materials that already exist in creating new applications or new versions of applications.

6.3.2 Implications for Authoring Techniques that Support DI

Some aspects of reuse are associated with the tools that an author employs to develop a site. For example, reuse of image assets can be made possible with tools that convert them to forms useful on different kinds of device. A large, colour image implemented using the Portable Network Graphics (PNG) encoding could be converted to a small bitmap for use on a mobile phone, for example.

Other aspects of reuse can depend on fundamental properties of the authoring technique used. Authoring techniques that clearly separate device dependent and device independent aspects of authoring, for example, enable reuse of the device independent material. In addition, authoring techniques that allow automatic support for new devices as they appear, without the need for changes to applications, are also providing reuse.

  1. Authoring techniques that support DI should allow for significant reuse of material
  2. Authoring techniques that support DI should encourage reuse by providing a clear separation between material that is device independent and material that is device dependent.
  3. Authoring techniques that support DI should allow support for functional presentation, on devices not considered during development of an application, to be provided without the need for additional authoring effort wherever possible.

7 Conclusions

This section will be completed once the findings of the note are complete It will summarise those findings and in particular the implications for authoring techniques that support DI generated by the needs of authors.

A References

XForms 1.0
XForms 1.0, Micah Dubinko, Josef Dietl, Andrew Layman, Leigh L. Klotz, Jr., Roland Merrick, T. V. Raman, 2002. W3C Working Draft available at: http://www.w3.org/TR/xforms.
XHTMLâ„¢ 1.0: The Extensible HyperText Markup Language
XHTMLâ„¢ 1.0: The Extensible HyperText Markup Language, Steven Pemberton, Murray Altheim, Daniel Austin, Frank Boumphrey, John Burger, Andrew W. Donoho, Sam Dooley, Klaus Hofrichter, Philipp Hoschka, Masayasu Ishikawa, Warner ten Kate, Peter King, Paula Klante, Shin'ichi Matsui, Shane McCarron, Ann Navarro, Zach Nies, Dave Raggett, Patrick Schmitz, Sebastian Schnitzenbaumer, Peter Stark, Chris Wilson, Ted Wugofski, Dan Zigmond, 2000 W3C Recommendation available at: http://www.w3.org/TR/xhtml1.
Extensible Markup Language(XML) 1.0
Extensible Markup Language(XML) 1.0 (Second Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, 2000. W3C Recommendation available at: http://www.w3.org/TR/REC-xml.
XSL Transformations (XSLT)
XSL Transformations (XSLT), James Clark, 1999. W3C Recommendation available at: http://www.w3.org/TR/xslt.
XSL Transformations (XSLT) Version 2.0, Michael Kay, 2002. W3C Working Draft available at: http://www.w3.org/TR/xslt20.
XHTMLâ„¢ Basic
XHTMLâ„¢ Basic, Mark Baker, Masayasu Ishikawa, Shinichi Matsui, Peter Stark, Ted Wugofski,Toshihiko Yamakami, 2000. W3C Recommendation available at: http://www.w3.org/TR/xhtml-basic.
CSS Mobile Profile 1.0
CSS Mobile Profile 1.0, Ted Wugofski, Doug Dominiak, Peter Stark, 2001. W3C Recommendation available at: http://www.w3.org/TR/css-mobile.
WAP 2.0 Specifications
WAP 2.0 Specifications, Open Mobile Association specifications available at: http://www.wapforum.org/what/technical.htm.
Device Independence Principles
Device Independence Principles, Roger Gimson, 2001. W3C Working Draft available at: http://www.w3.org/TR/di-princ.

B Acknowledgements

This document was produced by members of the Device Independence Working Group, whose membership is shown below. It does not yet represent a consensus view.