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 firstname.lastname@example.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.
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.
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 have 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 undertaken by authors. Where a site is small and relatively simple, it is common for many if not all of these roles to be performed by a single author. Where a site is large and complex, roles are commonly assigned to individual specialists.
There are three broad categories of web site authors. One category includes creation of all aspects of the design of a site, including its look and feel. A second category includes the creation of all of the content used on the site. The final category includes all aspects of the creation 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.
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.
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.
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.
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 application function require some level of business logic to be developed. Applications made available by enterprises in support of their business are a good example. On-line shops fall into this category.
Business logic must be designed and developed. Whereas the design of business logic can be relatively abstract, its implementation usually depends heavily on the capabilities of the particular server on which the site is running. There is usually little, if any, effect on the business logic caused by the target device. The business logic is usually shielded from the device by the interaction design.
This section is under construction.
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.
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 practice applications are rarely completely non-interactive. However, the considerations are equally valid for non-interactive sections of applications that also include interactive operations.
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 different 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.
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 an implementation issue. It has no direct bearing on the requirements for authoring techniques that support device independence.
Interactive applications can involve any of the elements 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 function 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. Authors 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. Indeed, different devices may even support different interaction modalities, such as sound rather than vision.
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. Authors need to be able to supply these user interfaces and 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.
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:
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.
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.
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 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 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.
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, authors 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.
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 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.
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.
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
The access mechanism by which the application and the device communicate may consist of many individual components. The characteristics of the access mechanism certainly include the characteristics of the device itself and of the network by which it is attached to the web. In this section, we'll look at some of these characteristics and 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 to authors. In general terms, authors need to be able to influence the way that access mechanism characteristics are used in determining how material is adapted for presentation on the target device through that mechanism.
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.
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.
The colour capability of the display on a device is also usually a static property. 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 author. 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 authors 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 attached 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. Authors may wish to make available versions of media assets, often the largest single items on a page, specifically optimised for low bandwidth connections. An author might even prefer to provide alternatives, such as text, for use on very slow connections, for example. On faster connections, authors 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.
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 parts of the web 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).
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 to be able to provide shared bookmarks 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 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.
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.
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 discusssions 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 PDAs for his 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.
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.
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 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.
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.