Copyright ©2002 W3C ® ( MIT , INRIA , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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.
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.
(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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
|
This section is under construction. |
(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.
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.
(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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
(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.
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
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.
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
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.
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.
The needs of the author lead to the following desirable characteristics of authoring techniques that support multiple devices.
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.
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.
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.
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.
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.
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.
|
This section is under construction. The details of its content have not yet been established. |
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.
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.
The needs of the author lead to the following desirable characteristics of authoring techniques that support multiple devices.
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.
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?
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.
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.
To support the enormous variability in device characteristics, authoring techniques that support DI should
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.
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.
Some characteristics of the access mechanism are closely associated with the device. This section covers some of the more important of these characteristics.
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.
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.
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.
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.
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.
Some characteristics of an access mechanism are closely associated with the network through which the device is connected. This section describes theses characteristics.
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.
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.
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.
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.
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.
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.
User's may need to access the same URIs with different devices. Consider the following scenario.
Shared Bookmark ScenarioMs. 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.
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 ScenarioAngela 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.
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.
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.
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.
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.
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.
From the considerations for authors, the following requirements arise.
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.
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.
From the discussions it is clear that
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.
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.
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.
(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.
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.
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.
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.
(020624-018) The DIWG F2F in Ottawa commented:
(020624-019) The DIWG F2F in Ottawa commented:
(020624-021 The DIWG F2F in Ottawa commented:
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.
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.
To maximise familiarity, Authoring techniques that support DI should be based on existing W3C recommendations wherever possible. In particular:
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.
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.
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.
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.
The challenges of supporting large numbers of diverse devices suggest the following characteristics of approaches that support DI:
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.
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.
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.
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.