This document discusses the challenges that authors commonly face when building web content and applications that can be accessed by users via a wide variety of different devices with different 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. As a consequence, it also derives a set of requirements for such techniques.
This document is one of a series produced by the Device Independence Working Group, part of the W3C Device Independence Activity. The DIWG activity statement can be seen at http://www.w3.org/2001/di/Activity.
Other documents in the series address the implementation of solutions to the requirements raised here. For example, there are documents in the series reviewing current techniques that can be used to address these requirements and exploring how future versions of existing W3C specifications can provide solutions.
Details of the entire series of documents can be found on the W3C Device Independence Activity home page.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is one of a series produced by the Device Independence Working Group, part of the W3C Device Independence Activity. The DIWG activity statement can be seen at http://www.w3.org/2001/di/Activity.
This document is a W3C Working Group Note. It represents the views of the W3C Device Independence Working Group at the time of publication. There are currently no plans to amend this document further. Publication as a Working Group Note does not imply endorsement by the W3C Membership.
Comments on this document can be sent to firstname.lastname@example.org, the public forum for discussion of the W3C's work on Device Independence. To subscribe, send an email to email@example.com with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.
Patent disclosures relevant to this document may be found on the WG patent disclosure page.
This note reviews the challenges that web authors face in supporting access to their sites from a variety of different devices. with a wide range of capabilities. This variability in device capability raises issues for authors and the tools they use to create sites. We use the term Authoring Challenges to encompass the sets of issues raised by various usage scenarios when considered in conjunction with the need to support a wide variety of devices with various 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.
This note discusses the challenges that authors face when building sites that can be accessed by a variety of devices. It enumerates individual challenges and describes the consequences for any techniques devised to assist authors.
This note explicitly avoids discussion of solutions to the requirements that it raises. Those discussions can be found in other documents in the series produced by the Device Independence Working Group and available via the home page of the W3C Device Independence Activity.
This note is one of the deliverables of the Device Independence Working Group. It has the following specific goals.
Identify the difficulties that authors face in an environment in which there is an increasingly diverse set of devices used to access web sites.
Identify the implications for authoring techniques that may assist authors in creating sites that can be accessed using a variety of devices and networks with different capabilities. These implications will form the basis for further work in identifying and developing appropriate techniques.
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. Statements of each of these requirements are included as appropriate in the sections in which they arise. They are highlighted within the text and identified with labels of the form DIAC-n.n, where n represents a number.
The Device Independence Working Group has defined a number of terms in its document Glossary of Terms for Device Independence. This note makes use of a number of terms defined in that document.
This note discusses various challenges encountered when 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 any business logic associated with the site.
While no categorization 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 categorize 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 colors 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 abstracted 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
is usually 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
Development of these resources is the task of content creators. 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 how a user will
experience it. This aspect of content creation becomes increasingly important
as the need to support a variety of devices with very different capabilities
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.
Interface designers typically begin work from some overall description of the site that is to be created. In commercial site development this is often in the form of a creative design brief, shown in the figure. From this brief, the various designers create materials used in defining the presentation of and interaction with the site. Layout designers produce representations of the physical placement of material for the various pages involved. This often starts life in the form of wire frame drawings and is eventually converted into markup that implements the layout.
Stylistic designers, also working from the brief, create precise definitions for the stylistic elements of the design, eventually converting them into concrete definitions represented, for example, as one or more CSS2 style sheets.
Interaction designers will also use the design brief to create representations of the flows that occur within the interactions between the user and the application. These might initially be represented as flow diagrams, for example. Eventually these will be converted into the markup that provides the controls used within the interaction and the specification for any business logic associated with processing the interactions.
Navigation designers use the design brief to create representations of the relationships between pages and the paths that can be used to traverse the site. Eventually these relationships form the site map.
When content creators build pages for the site, they rely on the layouts developed by layout designers and the style specifications built by the stylistic designers. Content creators also build the appropriate forms of images and other rich media resources specified for the site.
Business logic creators build the executable code associated with the site. Usually, part of this logic will be associated with processing user interactions and will be based on specifications from the various designers. Some of it may involve use of materials developed by content creators. Still other elements of the code will be based on the specification of the application logic associated with the site. This is shown in the figure as the application and business model.
This section provides detailed discussion of 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, interaction, 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 some general authoring goals and then looks at the implications of the degree of interactivity of various applications. It then goes on to discuss the types and sources of content used in such applications. In each case the implications for authors of the need to support multiple devices with different delivery contexts are considered. The implications for any authoring technique that seeks to support device independence is also considered.
The need to support access from a variety of devices and access mechanisms with a variety of delivery contexts should not restrict the types of application that authors can create. Essentially, authors would like to be able to deliver the same kinds of application routinely available on the web today. In addition, where new devices and networks provide additional capabilities, authors need to be able to exploit them without compromising the way that applications behave on devices without those capabilities.
Authors would like to be able to create applications with the same kind of function as are available on the web today and to make them available to a wide range of devices and with a variety of delivery contexts.
Authors would like to exploit additional capabilities of specific new devices, networks and delivery contexts without compromising the ability of their applications to be accessed from devices without those capabilities. The user experience provided on devices that lack specific capabilities will not necessarily be customized but must be functional .
Authors need to be able to afford to develop applications that can support access from a wide variety of devices and networks with varied capabilities and delivery contexts.
Authoring techniques that support DI should support delivery of the full range of existing types of application found on the web and should make it possible for authors to make such applications available to a wide variety of devices and networks with varied delivery contexts.
Authoring techniques that support DI should support delivery of applications that exploit new capabilities in devices and networks without compromising the ability of the application to be used on devices that lack those capabilities.
Authoring techniques that support DI should make it possible for applications to be developed that support access from devices and networks that with a wide variety of capabilities without requiring excessive effort on the part of authors.
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 catalogs 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 user
experience is non-interactive. In the case of sites that distribute news
articles, for example, the presentation is often common to all articles. The
content, however, 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.
From an author's perspective, creating the simplest pages should be the simplest operation. This is as true when supporting multiple devices and multiple delivery contexts 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 and delivery context.
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 its presentation on multiple devices with varied delivery contexts.
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 for use on different devices with different delivery contexts.
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 resources for use by different kinds of device and delivery context, 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 resource, a content creator may wish to offer the kind that gives a higher quality user experience.
Content creators may wish to provide resources of a completely different type for use on certain kinds of device and delivery context. 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 should be able to specify text to be used in its place.
Authoring techniques that support DI should make it simple to develop simple applications. In addition, the effort involved in developing more complex applications should scale smoothly with their complexity.
Authoring techniques that support DI should minimize the effort associated with the need to support the different navigation schemes that may be necessary in order to present the same material on different devices with different delivery contexts.
Authoring techniques that support DI should support the ability to vary the amount of material delivered to different devices with different delivery contexts, and to change the way that it is organized for presentation and user interaction.
Authoring techniques that support DI should support the use of different versions and types of media, such as images and audio clips, on different devices with different delivery contexts.
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 minimize the effort involved in defining an interaction for different devices with different delivery contexts and 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 function that executes on the client. 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.
Authoring techniques that support DI should offer authors the ability to abstract as much of the specification of an interaction as possible. This reduces the need to specify separate interactions for each type of device and delivery context.
Standards such as the W3C XForms specification offer a good example of how some kinds of interaction can be abstracted.
Authoring techniques that support DI should offer this kind of abstraction capability for data entry, data selection, control functions and navigation.
Authoring techniques that support DI should extend their support, for the ability to vary the amount and organization of material delivered to different devices with different delivery contexts, to include elements concerned with interaction.
Static content is material that is authored directly into the page. Often this consists of text and of fixed media resources, 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.
A major 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 content to support multiple devices and delivery contexts. This is the kind of content most often used by the least experienced authors.
Content creators may wish to present different sets of information on different devices in different delivery contexts. For example, on a small mobile phone it may be impractical to display the entire contents of a news article. It may be better to display headlines and summaries rather than the full text. In addition, authors may wish to provide different media resources for different devices and delivery contexts.
Even when content is essentially static, it may be necessary to provide alternate versions for use on different devices and delivery contexts. Together with the need for simplicity, this leads to the following set of implications for authoring techniques that support DI.
Authoring techniques that support DI should make it easy to use this simplest form of content when authoring pages.
Authoring techniques that support DI should be able to support the use of different versions of text content on different devices with different delivery contexts.
Authoring techniques that support DI should be able to support the use of different versions of media resources on different devices with different delivery contexts.
Authoring techniques that support DI should support the ability for alternative resources to be specified for use in creating the user experience.
Authoring techniques that support DI should provide the ability to select an appropriate resource from the alternatives available according to the capabilities of the device and the attributes of the delivery context.
Authoring techniques that support DI should provide the ability to create an appropriate media resource by conversion from an equivalent resource with different properties, if necessary.
Authoring techniques that support DI should provide authors with the ability to control which media resources are used on particular devices and delivery contexts.
Authors frequently need to integrate application data with material that creates the user experience, when creating web pages. In this discussion, raw application data is considered to be data that does not contain any information that directly controls the user experience. This kind of data might consist of product numbers, product names and prices in a product catalog, for example. The raw data might be retrieved from a database and merged with additional material, that applies style and formatting, to create the user experience.
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 the user experience.
Authors should be able to create applications that support multiple devices and access mechanisms with varied delivery contexts while using this type of content without excessive effort.
The process of integrating raw application data with material that controls user experience 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:
Authoring techniques that support DI should provide facilities that assist authors in managing the integration of application data with definitions of the user experience to accommodate the limitations in display size and storage capability associated with certain classes of device and delivery context.
Authors may need to integrate dynamically acquired content, that itself includes markup to control user experience, 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 the user experience. 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 that defines part of the user experience together with dynamic content, for example.
Examples of pages often created using this type of approach include
Authors need to be able to integrate their materials easily with content that is marked up in a variety of ways that may be incompatible with the target device and delivery context.
The integration of application data that includes material that affects aspects of the user experience is of direct concern to authoring techniques that support DI. There are two basic situations that might apply. The 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 device, access mechanism and delivery context. Transformation of device-independent representations, is a simpler task. Device-dependent material poses greater difficulties. 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 even a functional user experience. As a simple example of the challenge, imagine transforming 100 search results from one of the popular search engines for delivery to a WAP mobile phone, using only inspection of the HTML generated for use on a personal computer.
In general, device-independent representations that affect user experience 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.
Authoring techniques that support DI should provide facilities that assist authors in managing the integration of material that itself includes device-independent content.
Authoring techniques that support DI should provide facilities that assist authors in managing the integration of material that itself includes device-dependent content.
Authors may need to integrate dynamically acquired content that itself includes markup that does not directly affect the user experience, within their own markup when creating web pages. This kind of markup could, for example, consist of XML that defines certain application data. This kind of markup is not normally rendered without some kind of transformation. In the case of XML, for example, the most natural transformation would be to apply an XSLT style sheet to convert the markup to a form that can be rendered within the overall user experience.
Transformation processes that add material associated with user experiences to material previously free of this type of definition are outside the scope of the discussion of device Independence. However, since such processes may form a key part of the overall implementation of an application, it is important that authoring techniques that support DI do not preclude such techniques.
Authoring techniques that support DI should not prevent the inclusion and transformation of dynamically acquired content that incorporates markup that is free of definitions that directly affect the user experience.
Just as with markup, some applications require dynamic selection of media resources for use in particular pages. For example, in a catalog application, some of the raw application data might define the image that illustrates a particular product. It must be possible to select or create appropriate versions of media resources for the particular device and delivery context being used.
Authors need to be able to specify dynamically the media resources to be used in a page.
The needs of the author lead to the following desirable characteristics of authoring techniques that support device independence.
Authoring techniques that support DI should allow authors to specify dynamically the media resources to be used when creating a user experience.
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 user experience needs to be customized 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 user experiences 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.
Authoring techniques that support DI should allow authors to make use of advanced client-side capabilities including the ability to execute code.
Authoring techniques that support DI should allow interactions to be created that exploit client-side function without the need for the author to provide the code explicitly. This implies that the interaction abstractions used by the author are sufficiently powerful to hide the device-specific differences that affect the implementation. The approach can then provide appropriate implementations of the client-side function for each supported combination of device and user-agent.
Authoring techniques that support DI should allow interactions to be created that do not depend on the availability of client-side function in all delivery contexts. A server side implementation must be able to provide a functional user experience for use when client-side function is not available or is inappropriate.
Authoring techniques that support DI that support DI should allow authors to provide client-side function explicitly if needed to support a harmonized user experience.
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.
All of the considerations discussed in Static Content, in connection with media resources, also apply to rich media resources. As with other forms of media, such as images, content creators may need to be able to supply rich media resources 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.
In addition, however, rich media resources are often associated with interactive capabilities. For example, embedded media players often provide the ability to control the playback of video and audio material, allowing it to be paused, restarted and stopped by the user.
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.
Authoring techniques that support DI should support the ability to control rich media interactions on different devices with different delivery contexts in different ways. This implies that the interaction abstractions used by the author should be sufficiently powerful to hide the device and user-agent specific differences that affect the implementation.
Devices that can support concurrent communication over multiple modalities simultaneously are likely to become common in future. Such devices will require that operations in each modality be synchronised with one another. This is likely to place additional needs on authors and on the systems that support them.The W3C Multimodal Interaction Activity addresses issues such as these. DIWG recognizes that additional requirements for support of device independence will arise as a result of this work.
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, characterized 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 and delivery contexts. 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 device and delivery contexts.
Authoring techniques that support DI should support the full range of applications from the simplest to the most complex
Authoring techniques that support DI should scale smoothly in complexity as the underlying application becomes more sophisticated
Applications and sites are often constructed by combining together materials created at different times by different authors. The use of a media resource, such as an image, within a page of HTML provides a simple example of this. The text and the image are created separately and aggregated to provide the final user experience. In this case, aggregation takes place in the user agent. The individual resources being aggregated are known as authored units.
Aggregation plays an important role in many practical implementations of web applications. For example, in a portal the results of processing several applications are brought together to provide a single user experience. Typically, the aggregation is carried out on the server supporting the portal itself. In some senses this capability is a server-side version of the aggregation carried out by user agents for specific types of content.
When supporting delivery contexts that have limited facilities for presentation and interaction, it is often necessary to divide up resources to enable them to be used. For example, rather than delivering a large resource to the device, a set of smaller resources with appropriate navigation can be used. Such division of material to support particular delivery context is known as decomposition.
Decomposition may be automated or may be under some level of author control. For some purposes and for some delivery contexts, it may be sufficient for decomposition to be based simply on structural information associated with the authored units. For other purposes and for other delivery contexts, authors may need some level of control over the decomposition process. In particular, authors usually wish to exercise some level of control over decomposition when it is being used to harmonize the user experience in a particular delivery context rather than simply to overcome the physical limitations of the associated device.
It is, of course, quite valid to create a resource by aggregation of authored units and then to decompose it for use on a small device. Such operations are common in portal applications, for example.
An authored unit is a set of material created as a single entity by an author. Authored units can participate in aggregation operations. For example, an authored unit might consist of statements in a device-independent markup language that, when aggregated with additional statements from other sources, provides the basis for a user experience. The term is not restricted to markup, however. Any type of content might be created as an authored unit.
Authored units do not have to participate in aggregation. A single authored unit might be a complete description of a user experience, for example. A simple web page, written in HTML and which references no external resources, such as media or style sheets, is an example of such an authored unit.
A number of aggregation mechanisms already exist within current W3C standards. Some of these mechanisms are specific to a particular type of information set, such as an XSLT style sheet. Others are more general.
The XML Inclusions model is an example of the type of aggregation envisaged as appropriate for use with authored units. It appears to offer the appropriate level of function while retaining independence from specific types of information set.
Authors need to be able to create authored units that can participate in aggregation operations if desired.
Authors need to be able to specify how a resource may be decomposed for use in a delivery context for which it would be unsuitable in its entirety.
Authoring techniques that support DI should explicitly support aggregation operations that allow authored units to be assembled as part of the process of creating a user experience.
Authoring techniques that support DI should explicitly support decomposition of resources. Such decomposition should be capable of being performed automatically or under author control.
Navigation is the means by which users alter their focus of attention. This can result in a different part of an active perceivable unit becoming the focus of the user's attention, for example. It can also result in a different perceivable unit becoming active.
In HTML, for example, links between pages provide navigation across and between web sites. Links within pages provide more localized navigation. In other markup languages, such links may provide quite different function. In WML, for example, internal links provide navigation that cannot be accessed with more physical methods, making the loaded page behave more like part of a site.
The definition of navigation used by DIWG deliberately excludes mechanisms that change the focus of attention without using mechanisms explicitly provided within the perceivable unit. Scrolling, for example, is not considered to be a navigation mechanism.
Some navigation may be explicitly authored. Other navigation may need to be generated automatically from more abstract definitions. Such definitions can allow different navigation to be generated depending on the delivery context.
Authors need to be able to specify relationships between and within authored units in ways that allow the appropriate navigation to be generated during adaptation. This allows for very different navigation to be implemented for use in different delivery contexts.
Authoring techniques that support DI need to provide mechanisms through which authors can represent relationships that can form the basis of navigation generated during adaptation.
Authoring techniques that support DI should support abstract representations of the relationships between and within authored units from which specific navigation can be generated during adaptation
The vast majority of existing web sites and applications have been created for access from conventional personal computers and workstations. These sites are not, in general, well suited for access from other types of device. Indeed, they are not accessible at all from many devices.
Authors need to be able to reuse existing material not originally created to support device independence. This might be, for example, because a new, device-independent version of the application is being constructed. Alternatively, it might be because the new application must integrate with older applications that are not device independent and that are not being rewritten.
Authoring techniques that support DI should allow material from existing applications to be reused when constructing new, device independent applications. Authoring techniques should allow such reuse at the time the new application is being constructed. Authoring techniques should also allow such reuse at the time the new application executes.
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 those differences between devices that are most important, in terms of their ability to affect the final user experience.
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.
In addition, authors need to be able to use abstract representations of the capabilities of devices in creating their materials. They should, for example, be able to access properties such as the physical dimensions of a display or the number of pixels per millimeter using representations that are themselves independent of the device.
A number of characteristics of authoring techniques are highly desirable in supporting the wide range of capabilities of devices.
Authoring techniques that support DI should allow authors to create applications that support a wide variety of device capabilities.
Authoring techniques that support DI should provide mechanisms that allow authors to express the user experience they wish to achieve using abstract representations of the underlying capabilities of the device.
Authoring techniques that support DI should provide mechanisms that allow authors to express the layout of material that varies between different devices with different delivery contexts. In particular, they should support different spatial and temporal layout of material.
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 generation of the final user experience.
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 Overview 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 to create the user experience on the target device.
Users may be able to personalize various characteristics of their device. The effect of this type of capability on authoring techniques that support DI is discussed in Personalization. This section confines its discussion to the underlying physical characteristics of the devices and access mechanisms.
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 PDAs, 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 resources to use, they are also a major determinant in the design of the physical layout of the user experience. Authors may need to design different physical layouts and different ways of organizing the way material is made available to the user to take account of differences in the size and resolution of the displays in use.
The color 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 color support. For color displays and printers, it is often expressed simply as some measure of the number of different shades and colors 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 a harmonized user experience.
The color capability of a display is important for authoring techniques that support DI. Like physical screen size, color capability can be important in defining the appropriate visual media resources to use, particularly where multiple versions with different color 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 resources, 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 resources, 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 resources 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 these 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 resources, often the largest single items on a page, specifically optimized 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 delivery context if, for example, they are able to personalize various characteristics of the device. Such personalization, whether for reasons of personal preference or for the purpose of accessibility is covered later in the section Personalization 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 the user experience, location is more likely to have an effect on the content itself. For example, an application that presents information about retail opportunities might tailor the content presented based on the user's location. However, the way in which the material is presented and the nature of any interaction 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 Uniform Resource Identifiers (URI) with different devices. The One User, Multiple Devices Scenario illustrates this need. 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 implies that it is advantageous for the URIs associated with pages that support DI to be independent of the device accessing them. The need for device independent URIs arises in principle DIP-2 of the Device Independence Principles.
One 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. The Transaction Continuation Usage Scenario illustrates this usage. 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. In particular, it must be able to maintain the state of the transaction over some period of time.
The requirement to provide this capability probably has little additional impact on the user experience. All that is necessary is that the authoring technique being used does not preclude it.
The perceived usability of a particular application depends on many factors, including how it has been authored and the preferences of the user using it. Users with specific disabilities, for example, may perceive usability very differently.
The inherent capabilities of the device play an important role in overall usability. For example, it is probably wise for an author to avoid asking users to enter large volumes of text if they are accessing the application from a typical mobile phone. The keyboards of such devices are not ideal for the task.
It would be very useful for authors to have available some absolute metric of usability associated with each technical feature of a particular device. These metrics might define how usable the keyboard is, how good the handwriting recognition and so on. However, such metrics are notoriously difficult to specify and to measure. In addition, the values associated with such metrics need to be subject to preferences so that individual users may express their view of the usability.
Though the Device Independence Working Group recognizes the desirability for such metrics, their development and specification is considered outside the scope of its current work.
Authors need to consider the implications for the usability of the applications they create when accessed through devices with differing capabilities.
Authoring techniques that support DI should allow authors to create user experiences in which the usability is appropriate within a wide range of delivery contexts.
The ability for a user to exercise some level of control over their experience 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 user experiences that increase accessibility.
This section discusses the authoring implications of personalization in general and at how that may affect accessibility in particular.
The term personalization, when used in relation to web sites and applications, covers much more than the ability for a user to influence their experiences. Increasingly, applications themselves offer users the ability to tailor the function available to best suit their needs. Much of this personalization activity is related to application function that is independent of the user experience itself. However, that part of personalization that is relevant for presentation is of direct concern to authors when creating sites that support multiple delivery contexts. For example, a user might select one particular type of user experience 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 personalization associated with the user experience on their device as often as they wish. In practice, however, changes in personalization during a particular interaction are likely to be relatively infrequent.
From the viewpoint of authors and of authoring techniques that support DI, the ability to personalize the user experience effectively provides additional criteria that affect the process by which a resource is adapted for use in a particular delivery context.
Many of the user experience properties that a user may wish to personalize are associated with the physical input and output operations of the device. For example, a user might choose to modify the font sizes or colors 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. Personalization of the user experience generally works well within the bounds of the materials that an author allows or supports. Consequently, it is possible that support for preferences associated with the user experience 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.
Authoring techniques that support DI should allow personalization information that relates to the user experiences to be included during the process of adaptation of material for use in the particular delivery context.
Authoring techniques that support DI should take into consideration the modality of the device during the adaptation process.
Like personalization, 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 user experience associated with the material.
One aspect of the user experience 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 labeled buttons in a form to be altered to optimize the use of the available space.
In addition, where media resources, such as images, contain text, it will be necessary to include additional versions to support multiple languages.
From the perspective of the author, support for 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
Authoring techniques that support DI should allow language to influence the adaptation process under the appropriate conditions
In particular, authoring techniques that support DI should allow language to influence the choice of the layout and styles used in particular delivery contexts
Although not strictly a DI issue, authoring techniques that support DI might usefully support the ability to include language in the control of selection or creation of the media resources to be used for a particular device.
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 personalization to control such costs. For example, a user might elect to view only small, gray scale images as opposed to the large color 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.
The Data Transmission Cost Scenario gives an example.
Once again, from the perspective of the author, the user experience aspects of supporting personalization based on cost does not really introduce any fundamentally new challenges. However, this type of personalization might mean that additional versions of materials, and in particular media resources, 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 personalization.
It is possible to view accessibility as one of the applications of personalization. From a user's perspective it is, of course, much more than the ability to change a user experience to match taste. Accessibility concerns the ability of users to change the user experience 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 personalization of the user experience. The considerations for authors are the just the same, as are the implications for authoring techniques that support DI.
Issues relating to authoring of content for greater accessibility are addressed in the Web Content Accessibility Guidelines recommendation and that issues relating to accessibility in authoring tools are addressed in the Authoring Tool Accessibility Guidelines recommendation.
Although personalization used for accessibility is essentially the same as personalization 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 center 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 resources, 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 to 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 customizing the user experience.
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 maximize familiarity, authoring techniques that support DI should be based on existing W3C recommendations wherever possible. In particular:
Elements, of an authoring technique supporting DI, that involve explicit definition of presentational markup should, if possible, be based on existing markup specifications, for example the XHTML family of specifications, SMIL and SVG.
Elements, of an authoring technique supporting DI, that involve explicit definition of interaction models should, if possible, be based on the W3C XForms specification.
Any new definitions that fall completely outside the realm of existing, presentation-related or interaction-related recommendations should, if possible, be based on the W3C XML specification
Elements, of an authoring technique supporting DI, that involve transformation of information between different markup-based representations should, if possible, be based on the W3C XML and XSLT specifications.
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 CSS Mobile Profile might be used. Alternatively, the device might follow the Open Mobile Alliance's WAP Specifications. Frequently, however, there is variation in the way in which manufacturers implement the standards. Sometimes the implementation may be 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 user experience is one where the user is able to complete the function intended by the author on a particular device within a particular delivery context. Although functional, the user experience is not necessarily tailored 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. The ability to provide a functional user experience 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 user experience can be created with a minimum of authoring effort, and without the need for the author to have specific expertise concerning the device and delivery context being supported.
A harmonized user experience is one specifically tailored to the target device and delivery context. Creation of a harmonized user experience usually requires that an author has provided additional materials over and above those required for a functional version.
The degree to which a user experience is harmonized should be under the control of the author. From an affordability standpoint, an author should be able to apply as little or as much customization as necessary to achieve a level of harmonization appropriate for the device and delivery context in question. In addition, the effort required to harmonize a user experience should rise smoothly. There should not be a large increase in cost associated with a small change in the level of harmonization of the user experience.
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 user experiences on the majority of new devices to be provided automatically.
Authors should be able to create functional user experiences 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 customizing user experiences for selected devices and delivery contexts.
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.
The challenges of supporting large numbers of diverse devices suggest the following characteristics of approaches that support DI:
Authoring techniques should allow authors to support a wide variety of devices with diverse capabilities without excessive effort.
Authoring techniques that support DI should allow authors to support a wide variety of devices with diverse capabilities without the need for detailed knowledge of the precise characteristics of each one.
Authoring techniques that support DI should allow functional user experiences to be created for multiple devices without excessive effort.
Authoring techniques that support DI should allow authors to customize user experiences for particular devices or classes of device.
Authoring techniques that support DI should allow authors to exploit the capabilities of a device in a harmonized user experience if they wish to do so.
Authoring techniques that support DI should allow authors to choose how much effort to invest in customizing the user experience for particular devices or classes of device. The relationship between the amount of effort invested by an author and the level of customization achieved should be simple and smooth with no discontinuities.
Authoring techniques that support DI should allow support for at least a functional user experience to be provided, on devices not considered during development of an application, without the need for additional authoring effort wherever possible.
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 user experiences 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 user experiences 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 resources can be made possible with tools that convert them to forms useful on different kinds of device. A large, color 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.
Authoring techniques that support DI should allow for significant reuse of material.
Authoring techniques that support DI should encourage reuse by providing a clear separation between material that is device independent and material that is device dependent.
Authoring techniques that support DI should allow support for functional user experiences to be provided on devices not considered during development of an application, without the need for additional authoring effort, wherever possible.
Testing of applications that support multiple devices and delivery contexts can be onerous. Often, the only avenue open to authors and developers is to test the application for correctness on real examples of the devices that must be supported. Emulators are available but vary in the fidelity with which they mimic the behavior of the devices they represent.
The Device Independence Working Group recognizes that assistance in testing could be a valuable aid to affordability. However, it is felt that such assistance is an implementation issue and is an area that can provide differentiation between vendor offerings.
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 for a detailed description of the use case).
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 acknowledgment returned by the concert hall and synchronizes 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 realizes 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.
Mr. Wright has purchased pre-paid GPRS enabled mobile phones for his sons, Jimmy and Tommy. While they both like to download the latest cartoons 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.
Calvin Mentmore is a sales representative who is rarely in the office. His main role is to make his customers aware of new products. He knows that for his business, putting a good-quality personalized brochure into the hands of his customer, while explaining the benefits of the product, leads to more sales. Being mainly on the road, he uses a phone-connected laptop or PDA to personalize product literature before a customer visit. Bandwidth is often too limited for Calvin to download the resulting high-resolution brochure. Instead, using the same URI, he requests a thumbnail view of the brochure pages on the screen and then prints a medium-resolution image of only the pages he has customized on his portable wireless printer, to check they are well-paginated and contain the right information. He emails the URI of the personalized brochure to his customer for the unlikely event of the customer browsing it on the web in advance. Calvin calls in at a local printing service on his way to the customer, gives them the brochure URI, and lets their printer fetch the high-quality version of the brochure directly from his office website, which is printed and bound ready for him to hand to the customer during the visit.
This document discussed the challenges that authors commonly face when building web content and applications that can be accessed by users via a wide variety of different devices with different capabilities. The document examined 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. As a consequence, it derived a set of requirements for such techniques.
Within the discussions in this document, a significant number of specific requirements for systems that support DI authoring have been identified. In the following sections, these are grouped into general categories to provide an overall summary of the requirements.
The following members of the W3C Device Independence Working Group have helped develop this Working Draft through their comments, proposals and discussions at teleconferences, face-to-face meetings and via the group discussion list.
At the time of publication, the principal and active members of the group were as follows:
The following were members of the group at earlier stages of its drafting: