Copyright©2003W3C® (MIT ,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark,documentuse andsoftwarelicensing rules apply.
This document discusses the challenges that authors commonly face whenbuilding web content and applications that can be accessed byusers viaa wide variety of different devices with different capabilities. The documentexamines the effects on authors and the implications for authoring techniquesthat assist in the preparation of sites that can support a wide variety ofdevices. As a consequence, it also derives a set of requirements for suchtechniques.
This document is one of a series produced by the Device IndependenceWorking Group, part of theW3C DeviceIndependence Activity. The DIWG activity statement can be seen athttp://www.w3.org/2001/di/Activity.
Other documents in the series address the implementation of solutions tothe requirements raised here. For example, there are documents in the seriesreviewing current techniques that can be used to address these requirementsand exploring how future versions of existing W3C specifications can providesolutions.
Details of the entire series of documents can be found on theW3C Device Independence Activity homepage.
This section describes the status of this document at the time of itspublication. Other documents may supersede this document. A list of currentW3C publications and the latest revision of this technical report can befound in theW3C technical reports indexat http://www.w3.org/TR/.
This document is one of a series produced by the Device IndependenceWorking Group, part of theW3C DeviceIndependence Activity. The DIWG activity statement can be seen athttp://www.w3.org/2001/di/Activity.
This document is a W3C Working Group Note. It represents the views of theW3C Device Independence Working Group at the time of publication. There arecurrently no plans to amend this document further. Publication as a WorkingGroup Note does not imply endorsement by the W3C Membership.
Comments on this document can be sent towww-di@w3.org, the public forum fordiscussion of the W3C's work on Device Independence. To subscribe, send anemail towww-di-request@w3.orgwith the word subscribe in the subject line (include the word unsubscribe ifyou want to unsubscribe). Thearchive for the listis accessible online.
Patent disclosures relevant to this document may be found on theWG patent disclosurepage.
This note reviews the challenges that web authors face in supportingaccess to their sites from a variety of differentdevices.with a wide range of capabilities. This variability in device capabilityraises issues for authors and the tools they use to create sites. We use thetermAuthoring Challenges to encompass the sets of issues raised byvarious usage scenarios when considered in conjunction with the need tosupport a wide variety of devices with various capabilities.
The number and variety of types of device used to access the web continuesto grow. As the resulting diversity increases, it becomes ever more difficultfor authors to support the existing range of web sites and applications thatare currently available. Any site, from the simplest home page to the mostcomplex interactive application can be affected by the need to support accessfrom a variety of types of device. The precise level of impact tends toincrease with site complexity.
In addition to the challenges associated with supporting existing types ofapplication, new devices offer additional opportunities for authors. Forexample, mobile devices are often aware of their location. This can allowappropriately authored applications to provide more useful information tousers, for example. As another example, new types of device may be able tosupportinteractionwith the user via a range ofmodalities.They might operate with a conventional display under certain circumstancesbut use voice under others. Authors need to be able to support suchadditional capabilities where they exist.
The burden placed on authors by the diversity of newer devices issignificant. The affordability of creating and maintaining web sites andapplications that support a range of devices is a major concern. Withoutmechanisms to alleviate the authoring efforts associated with creating andsupporting such a large set of diverse devices, authors will not be in aposition to provide the universal access that is such an important aspirationof the web.
This note discusses the challenges that authors face when building sitesthat can be accessed by a variety of devices. It enumerates individualchallenges and describes the consequences for any techniques devised toassist authors.
This note explicitly avoids discussion of solutions to the requirementsthat it raises. Those discussions can be found in other documents in theseries produced by the Device Independence Working Group and available viathe home page of theW3C DeviceIndependence Activity.
This note is one of the deliverables of the Device Independence WorkingGroup. It has the following specific goals.
Identify the difficulties that authors face in an environment in whichthere is an increasingly diverse set of devices used to access web sites.
Identify the implications for authoring techniques that may assist authorsin creating sites that can be accessed using a variety of devices andnetworks with different capabilities. These implications will form the basisfor further work in identifying and developing appropriate techniques.
This note is intended as background material for people interested in theproblems associated with delivering content and applications from web sitesto 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 inthe development of a web site. It then describes the notion of applicationson 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 meansby which they connect to the web. The implications of the ability of users totailor their experience of the web are then covered, together with discussionof accessibility. Finally, the implications of supporting multiple devices onthe affordability of site creation are discussed.
Throughout the discussion, the note describes the needs of authors and theconsequent implications for authoring techniques that aim to help them intheir tasks. These implications effectively form the basis for a set ofrequirements on such techniques. Statements of each of these requirements areincluded as appropriate in the sections in which they arise. They arehighlighted within the text and identified with labels of the formDIAC-n.n, wheren represents a number.
The Device Independence Working Group has defined a number of terms in itsdocumentGlossary of Terms for DeviceIndependence. This note makes use of a number of terms defined in thatdocument.
This note discusses various challenges encountered when authoring websites. However, the term "Authoring" covers a wide variety of activities,particularly where the site in question implements significant applicationfunction in addition to information presentation. This section describes thevarious activities usually associated with web site creation in terms of aset of roles that are commonly undertaken by its authors. A role is notnecessarily identified with an individual author. It is possible, and forsmall sites quite likely, that more than one role will be performed by anindividual. Conversely, for very complex sites, a given role might bedistributed among several authors.
There are three broad categories of web site authors. One category includes the designers of the site'suser interface, including its look and feel. A second category includes thecreators of all of the site's content. The final category includes thecreators of any business logic associated with the site.
While no categorization like this is perfect, it gives a framework inwhich to discuss specific scenarios in the rest of the note. The remainder ofthis section covers these three categories of authoring roles in more detailand introduces some of the potential impacts on them caused by a need tosupport a wide range of devices.
The design of a site is associated closely with the way it appears to itsusers. The usability of a site is heavily influenced by its design. Thefollowing sections categorize the various roles that site designers play.
Layout designers specify the physical placement of material on the outputof the device. Typically this involves the arrangement of text, associatedimages and other media within a single page.However, the role of the layout designer changes whenthe access device has output mechanisms other than visual display. Forexample, the designer may need to specify the sequence in which informationis spoken. The options available to the layout designer are heavilyinfluenced by the capabilities of the target device, such as the size andresolution of its display.
The stylistic design of a site is essentially its "look and feel". Itincludes the selection of fonts and colors and the development of graphicsused for elements such as icons, branding and backgrounds. It also includesstylistic elements of other kinds of media, such as audio and video. Forexample, where a device has spoken output, stylistic design might include theselection of the qualities of the particular voice used under variouscircumstances. Stylistic design is also heavily influenced by thecapabilities of the target device and preferences expressed by the user.
Interaction designers specify the way that users interact with a site. Inparticular, interaction designers specify how interactions occurwithin a page. This might include defining the order in which datais entered on a particular page. It might also include defining theparticular kind of user interface abstraction employed for entering eachvalue. Interaction design takes place at a level abstracted from theparticular capabilities of the device. For example, an interface designermight specify that data entry for a particular field uses a mechanism wherethe user selects a single value from a set. The stylistic designer mightinterpret this as use of a drop-down list control on a particular device.
Interaction design is often more abstract than other aspects of thedesign. 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 ofdevices, if a sufficiently abstract view is taken. TheW3C XForms specification is an example of such anabstraction.
Navigation designers specify the paths that visitors may take through asite.Navigationis usually implemented by the use of links. The way in which such links arerepresented is defined by the stylistic design. For example, links might bepresented 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, thatdefines the available navigation from the current page.
The content used on a site includes text, graphics, images, audio andvideoresources.Development of these resources is the task of content creators. Developmentof content can demand many skills. Creation of text content requiresconventional writing skills while development of images and graphics needsexpertise in the graphics arts. Audio content for a site might include musicand may require another set of performance and production skills.
Content creation is often directly affected by the need to support manytypes of target device. It may be necessary to create different versions ofcontent, particularly images, audio and other rich media, to cater for thedifferent capabilities of various devices. Creation of alternate forms ofcontent may also be necessary so that material can be delivered to devicesthat cannot support particular kinds of content.Increasingly, authors prepare content that includesmore semantic information. For example, textual web content is oftenconstructed usingXML documents where the markupindicates the purpose of the material rather than defining how a user willexperience it. This aspect of content creation becomes increasingly importantas the need to support a variety of devices with very different capabilitiesincreases.
Sites that support applications typically require business logic to beimplemented. Applications made available by enterprises in support of theirbusiness are a good example. On-line shops, for example, fall into thiscategory.
Business logic must be designed and developed. The design of businesslogic can be relatively abstract if best practice application design isfollowed. However, the details of its implementation usually depend heavilyon the capabilities of the particular type ofserveron which the site is running. Business logic can be shielded from the detailsof the device being used by the interaction design.
Interface designers typically begin work from some overall description ofthe site that is to be created. In commercial site development this is oftenin the form of a creative design brief, shown in the figure. From this brief,the various designers create materials used in defining the presentation ofand interaction with the site. Layout designers produce representations ofthe physical placement of material for the various pages involved. This oftenstarts life in the form of wire frame drawings and is eventually convertedinto markup that implements the layout.
Stylistic designers, also working from the brief, create precisedefinitions for the stylistic elements of the design, eventually convertingthem into concrete definitions represented, for example, as one or moreCSS2 style sheets.
Interaction designers will also use the design brief to createrepresentations of the flows that occur within the interactions between theuser and the application. These might initially be represented as flowdiagrams, for example. Eventually these will be converted into the markupthat provides the controls used within the interaction and the specificationfor any business logic associated with processing the interactions.
Navigation designers use the design brief to create representations of therelationships between pages and the paths that can be used to traverse thesite. Eventually these relationships form the site map.
When content creators build pages for the site, they rely on the layoutsdeveloped by layout designers and the style specifications built by thestylistic designers. Content creators also build the appropriate forms ofimages and other rich media resources specified for the site.
Business logic creators build the executable code associated with thesite. Usually, part of this logic will be associated with processing userinteractions and will be based on specifications from the various designers.Some of it may involve use of materials developed by content creators. Stillother elements of the code will be based on the specification of theapplication logic associated with the site. This is shown in the figure asthe application and business model.
This section provides detailed discussion of features that authors wouldlike to be able to provide to end users. Web sites can be considered asapplications that consist of content, presentation, navigation, interaction,and business logic. There is a wide range of types of such applications. Theyrange from the simplest, non-interactive applications, whose prime role is toinform, to complex, highly functional applications offering services such ase-commerce. In practice, many web sites consist of a combination of variouskinds of application.
The section first examines some general authoring goals and then looks atthe implications of the degree of interactivity of various applications. Itthen goes on to discuss the types and sources of content used in suchapplications. In each case the implications for authors of the need tosupport multiple devices with differentdeliverycontexts are considered. The implications for any authoring techniquethat seeks to support device independence is also considered.
The need to support access from a variety of devices andaccessmechanisms with a variety of delivery contexts should not restrict thetypes of application that authors can create. Essentially, authors would liketo be able to deliver the same kinds of application routinely available onthe web today. In addition, where new devices and networks provide additionalcapabilities, authors need to be able to exploit them without compromisingthe way that applications behave on devices without those capabilities.
Authors would like to be able to create applications with the same kind offunction as are available on the web today and to make them available to awide range of devices and with a variety of delivery contexts.
Authors would like to exploit additional capabilities of specific newdevices, networks and delivery contexts without compromising the ability oftheir applications to be accessed from devices without those capabilities.Theuserexperience provided on devices that lack specific capabilities will notnecessarily be customized but must befunctional .
Authors need to be able to afford to develop applications that can supportaccess from a wide variety of devices and networks with varied capabilitiesand delivery contexts.
Authoring techniques that support DI should support deliveryof the full range of existing types of application found on the web andshould make it possible for authors to make such applications available to awide variety of devices and networks with varied delivery contexts.
Authoring techniques that support DI should support deliveryof applications that exploit new capabilities in devices and networks withoutcompromising the ability of the application to be used on devices that lackthose capabilities.
Authoring techniques that support DI should make it possiblefor applications to be developed that support access from devices andnetworks that with a wide variety of capabilities without requiring excessiveeffort on the part of authors.
The simplest kinds of applications involve no user interaction. Theypresent information but do not offer any interaction, other than simplenavigation. This kind of application is seen in simple personal home pageswhere the content is also usually static. Applications that can presentselected content, such as product catalogs and sites that distribute newsarticles may also be essentially non-interactive. In these types ofapplication, there may be business logic associated with the retrieval of thedata, even though theuserexperience is non-interactive. In the case of sites that distribute newsarticles, for example, the presentation is often common to all articles. Thecontent, however, varies from article to article. It is typically retrievedfrom a content management system or database. There is no user interaction,other than navigation, despite the fact that there may be business logicassociated with retrieving the correct article.
From an author's perspective, creating the simplest pages should be thesimplest operation. This is as true when supporting multiple devices andmultiple delivery contexts as when supporting just a single device. Theoverhead of supporting multiple devices must not be prohibitive, even whenthe page is simple. Ideally, it should be small in comparison with the effortrequired to write the page for a single device and delivery context.
Simple pages may require business logic and access to dynamically acquiredor generated data. Consequently, authors may need to be able to combine suchdata sources with the ability to support its presentation on multiple deviceswith varied delivery contexts.
Even the simplest, non-interactive applications usually rely on theability of the user to navigate between pages. Navigation designers wouldlike to be able to specify this navigation once, despite the fact thatdifferences in capabilities mean that the details often need to be varied foruse on different devices with different delivery contexts.
Variations in device capability can affect a number of aspects of the wayin which material is delivered to them and presented. One obviousconsideration is the total amount of material that the device can accommodatein a single page. Authors may wish to vary the amount of informationpresented for a given page on different devices. On small devices, forexample, authors may wish to present some kind of summary rather than thefull information. Alternatively, an author might wish to present all of theinformation by structuring it as a set of smaller pages, requiring additionalnavigation.
Content creators need ways to provide alternate versions of mediaresources for use by different kinds of device and delivery context, whilemaintaining the same information semantics. For example, a particular picturemight need to be supplied as a PNG image for use on a personal computer, asmaller PNG image for use on a personal digital assistant and a WBMP imagefor use on WAP phone. For some devices, which accept more than one type of aparticular resource, acontent creator may wish tooffer the kind that gives a higher quality user experience.
Content creators may wish to provide resources of a completely differenttype for use on certain kinds of device and delivery context. Rather than avideo 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 adisplay but no video capability. In the absence of any appropriate mediacapability, content creators should be able to specify text to be used in itsplace.
Authoring techniques that support DI should make it simple todevelop simple applications. In addition, the effort involved in developingmore complex applications should scale smoothly with their complexity.
Authoring techniques that support DI should minimize theeffort associated with the need to support the different navigation schemesthat may be necessary in order to present the same material on differentdevices with different delivery contexts.
Authoring techniques that support DI should support theability to vary the amount of material delivered to different devices withdifferent delivery contexts, and to change the way that it is organized forpresentation and user interaction.
Authoring techniques that support DI should support the useof different versions and types of media, such as images and audio clips, ondifferent devices with different delivery contexts.
Interactive applications can involve any of the features ofnon-interactive applications but add some kind of user input and controloperations. The normal expression of such an interaction in existingapplications delivered via the web is the construct known as theForm. Fields of various kinds are presented to the user and receiveinput of various types. These basic kinds of interaction are described inthis section. In later sections, more complex interactions involving explicituse of functions executing on the device are considered.
Interactive applications can use any of the features of non-interactiveapplications. Consequently, all of the authoring considerations fornon-interactive applications apply.
The interaction capabilities of various devices vary enormously. Forexample, some have full keyboards, some have tiny keypads, while some have nokeyboard at all. Some have sophisticated pointing devices, some have styliand some have only keys with which to select and navigate. Some allow fullaudio interaction and some allow none. Interaction designers would like to beable to minimize the effort involved in defining an interaction for differentdevices with different delivery contexts and that may have very differentuser interface capabilities.
Basic navigation was included in the discussion of non-interactiveapplications. Navigation is often an important feature of interactiveapplications and frequently involves more sophisticated function thatexecutes on theclient.In addition to user interfaces and navigation, interactive applications mayalso provide the ability for users to control embedded rich media players viauser interface controls. Interaction and navigation designers need to be ableto supply these user interfaces and provide facilities for more complexnavigation.
Once again, from the authoring considerations, it is possible to infersome desirable characteristics of authoring techniques that aid indevelopment of applications that support multiple delivery contexts.
Authoring techniques that support DI should offer authors theability to abstract as much of the specification of an interaction aspossible. This reduces the need to specify separate interactions for eachtype of device and delivery context.
Standards such as theW3C XForms specificationoffer a good example of how some kinds of interaction can be abstracted.
Authoring techniques that support DI should offer this kindof abstraction capability for data entry, data selection, control functionsand navigation.
Authoring techniques that support DI should extend theirsupport, for the ability to vary the amount and organization of materialdelivered to different devices with different delivery contexts, to includeelements concerned with interaction.
Static content is material that is authored directly into the page. Oftenthis consists of text and of fixed media resources, referenced explicitlyfrom elements in the page. This type of content is most usually associatedwith the simplest, non-interactive applications, such as personal homepages.
A major consideration for this kind of content is the same as for the kindof applications that use it. In particular, it must be simple to use thiskind of content to support multiple devices and delivery contexts. This isthe kind of content most often used by the least experienced authors.
Content creators may wish to present different sets of information ondifferent devices in different delivery contexts. For example, on a smallmobile phone it may be impractical to display the entire contents of a newsarticle. It may be better to display headlines and summaries rather than thefull text. In addition, authors may wish to provide different media resourcesfor different devices and delivery contexts.
Even when content is essentially static, it may be necessary to providealternate versions for use on different devices and delivery contexts.Together with the need for simplicity, this leads to the following set ofimplications for authoring techniques that support DI.
Authoring techniques that support DI should make it easy touse this simplest form of content when authoring pages.
Authoring techniques that support DI should be able tosupport the use of different versions of text content on different deviceswith different delivery contexts.
Authoring techniques that support DI should be able tosupport the use of different versions of media resources on different deviceswith different delivery contexts.
Authoring techniques that support DI should support theability for alternative resources to be specified for use in creating theuser experience.
Authoring techniques that support DI should provide theability to select an appropriate resource from the alternatives availableaccording to the capabilities of the device and the attributes of thedelivery context.
Authoring techniques that support DI should provide theability to create an appropriate media resource by conversion from anequivalent resource with different properties, if necessary.
Authoring techniques that support DI should provide authorswith the ability to control which media resources are used on particulardevices and delivery contexts.
Authors frequently need to integrate application data with material thatcreates the user experience, when creatingwebpages. In this discussion, raw application data is considered to be datathat does notcontain any information that directlycontrols the user experience. This kind of data might consist of productnumbers, product names and prices in a product catalog, for example. The rawdata 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 ofsource, including
Data returned from these types of source might be in a variety of formats.Web services, for example, return data asXMLdocuments. Other sources might return it as comma separated lists, individualfields or in proprietary formats. Whatever its source, the common feature ofthis type of data is that it includes noinformation that controls the user experience.
Authors should be able to create applications that support multipledevices and access mechanisms with varied delivery contexts while using thistype of content without excessive effort.
The process of integrating raw application data with material thatcontrols user experience does not directly concern authoring techniques thatsupport DI. This level of integration is normally provided by the programmingor transformation capability of the run time system on which the web site isexecuting.
There is one potential issue for authoring techniques that support DI.This concerns situations in which the amount of application data to bepresented is not known until execution time. As a result, it is possible thatthere will be more data than the device, or at least the chosen layout canaccommodate. This suggests the following implication:
Authoring techniques that support DI should providefacilities that assist authors in managing the integration of applicationdata with definitions of the user experience to accommodate the limitationsin display size and storage capability associated with certain classes ofdevice and delivery context.
Authors may need to integrate dynamically acquired content, that itselfincludes markup to control user experience, The dynamically acquired materialmight 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 includesinformation that controls the user experience. Inexisting applications, this material usually consists of specific statementswritten in a markup language such as HTML. Elements such as headings andparagraphs are quite common, for example.However,not all the content for a page is necessarily retrieved dynamically. Thefinal page could be the result of merging static content that defines part ofthe 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 contentthat is marked up in a variety of ways that may be incompatible with thetarget device and delivery context.
The integration of application data that includes material that affectsaspects of the user experience is of direct concern to authoring techniquesthat support DI. There are two basic situations that might apply. Thematerial in the data might be device-specific or it might bedevice-independent.
In either case, the authoring technique in use will need to transform theembedded material into a form appropriate for the target device, accessmechanism and delivery context. Transformation of device-independentrepresentations, is a simpler task. Device-dependent material poses greaterdifficulties. Indeed it is probably the case that there is no way toguarantee that automatic transformation of device-dependent material can, ingeneral, lead to even afunctional user experience. As a simple example of the challenge, imaginetransforming 100 search results from one of the popular search engines fordelivery to a WAP mobile phone, using only inspection of the HTML generatedfor use on a personal computer.
In general, device-independent representations that affect user experiencemust have features that facilitate this kind of mapping, since that is theprinciple on which they work. Consequently, such representations should beeasier to transform when encountered within dynamically acquired data.
Authoring techniques that support DI should providefacilities that assist authors in managing the integration of material thatitself includes device-independent content.
Authoring techniques that support DI should providefacilities that assist authors in managing the integration of material thatitself includes device-dependent content.
Authors may need to integrate dynamically acquired content that itselfincludes markup that does not directly affect the user experience, withintheir own markup when creating web pages. This kind of markup could, forexample, consist of XML that defines certain application data. This kind ofmarkup is not normallyrenderedwithout some kind of transformation. In the case of XML, for example, themost natural transformation would be to apply an XSLT style sheet to convertthe markup to a form that can be rendered within the overall userexperience.
Transformation processes that add material associated with userexperiences to material previously free of this type of definition areoutside the scope of the discussion of device Independence. However, sincesuch processes may form a key part of the overall implementation of anapplication, it is important that authoring techniques that support DI do notpreclude such techniques.
Authoring techniques that support DI should not prevent theinclusion and transformation of dynamically acquired content thatincorporates markup that is free of definitions that directly affect the userexperience.
Just as with markup, some applications require dynamic selection of mediaresources for use in particular pages. For example, in a catalog application,some of the raw application data might define the image that illustrates aparticular product. It must be possible to select or create appropriateversions of media resources for the particular device and delivery contextbeing used.
Authors need to be able to specify dynamically the media resources to beused in a page.
The needs of the author lead to the following desirable characteristics ofauthoring techniques that support device independence.
Authoring techniques that support DI should allow authors tospecify dynamically the media resources to be used when creating a userexperience.
Many practical applications in current web sites rely on execution of somefunction on the user's device. In this note it is termedclient-sidefunction to distinguish it from application function executing on webservers.
The program code associated with client-side function is highly dependenton the user's device. It is sensitive to the precise details of the executionenvironment on the device. For most types of application, this environment isprovided by theuseragent being used on the device. This is normally termed thebrowser.Often, and especially with smaller devices, there is a single user agentavailable for a given device. On larger devices, there may be a choice. Forexample, there are HTML and WML user agents available for some currentPersonal Digital Assistants. For personal computers, a large range ofdifferent user agents is available.
Different device and user agent combinations often require differentlanguages for client-side function. Languages in common use include:
However, even when the same language is used, details in the executionenvironment can mean that different programming code is required to implementthe same client-side function on different devices.
Client-side function is used for a variety of purposes. Often it is usedto provide advanced navigation function through the use of user interfacecontrols such as drop down or cascading menus. It is also used to providefeatures such as immediate user input validation, improving responsiveness byeliminating the need for data to be returned to the server for checking. Itmay even be used to cause dynamic changes to the capabilities of the deviceitself by, for example, downloading additional information, such as a mediacodec.
Applications that use client-side function are usually interactive.Consequently, all of the considerations for non-interactive and interactiveapplications apply to them as well.
The client-side programming capabilities of devices vary enormously. Evenwithin individual client-side languages, differences in the executionenvironment mean that different code can be needed when different user agentsare in use. Authors would like to be able to specify functions that requireclient-side support in ways that avoid the need to write different code foreach individual combination of device and user agent. However, there may besituations, especially when a user experience needs to be customized for aparticular delivery context, where an author will need the ability to createspecific client-side function. In addition, authors need to be able toprovide functional user experiences that are equivalent to those that useclient-side function, even when the device and user agent in use cannotprovide the appropriate client-side function and all processing must occur onthe server.
From the authoring considerations, it is possible to infer some desirablecharacteristics of approaches that aid in development of applications thatsupport multiple delivery contexts.
Authoring techniques that support DI should allow authors tomake use of advanced client-side capabilities including the ability toexecute code.
Authoring techniques that support DI should allowinteractions to be created that exploit client-side function without the needfor the author to provide the code explicitly. This implies that theinteraction abstractions used by the author are sufficiently powerful to hidethe device-specific differences that affect the implementation. The approachcan then provide appropriate implementations of the client-side function foreach supported combination of device and user-agent.
Authoring techniques that support DI should allowinteractions to be created that do not depend on the availability ofclient-side function in all delivery contexts. A server side implementationmust be able to provide a functional user experience for use when client-sidefunction is not available or is inappropriate.
Authoring techniques that support DI that support DI shouldallow authors to provide client-side function explicitly if needed to supportaharmonized user experience.
Any application, whether interactive or not, may include rich mediacontent, such as audio or video clips. Where such an application isinteractive, part of its interaction with the user may involve control of theplayback of the rich media content. Rich media applications may supportsources that stream content, such as Internet Radio or Video feeds.
All of the considerations discussed inStatic Content, in connection with mediaresources, 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 mediaresources in various forms to cater for the needs of various devices andnetworks. Versions appropriate to particular media players may need to beprovided, for example. In addition, to accommodate differences in networkbandwidth, different degrees of compression might also need to besupported.
In addition, however, rich media resources are often associated withinteractive capabilities. For example, embedded media players often providethe ability to control the playback of video and audio material, allowing itto be paused, restarted and stopped by the user.
Once again, from the authoring considerations, it is possible to infersome desirable characteristics of approaches that aid in development ofapplications that support multiple delivery contexts.
Authoring techniques that support DI should support theability to control rich media interactions on different devices withdifferent delivery contexts in different ways. This implies that theinteraction abstractions used by the author should be sufficiently powerfulto hide the device and user-agent specific differences that affect theimplementation.
Devices that can support concurrent communication over multiple modalitiessimultaneously are likely to become common in future. Such devices willrequire that operations in eachmodalitybe synchronised with one another. This is likely to place additional needs onauthors and on the systems that support them.
TheW3C Multimodal InteractionActivity addresses issues such as these. DIWG recognizes that additionalrequirements for support of device independence will arise as a result ofthis work.There is a huge diversity of applications delivered via the web. We'vealready seen a number of classes of application, from the simplest,non-interactive sites, characterized by personal home pages, to the mostsophisticated, interactive sites, using dynamic content and often encounteredin connection with commercial activity, such as e-commerce.
The level of effort required of authors in constructing a site should notbe disproportionate to the site's level of sophistication and complexity. Inparticular, it should be relatively simple to build simple applications thatsupport multiple devices and delivery contexts. This will allow eveninexperienced authors to benefit from having their applications universallyavailable.
As well as supporting simple sites, authoring techniques that support DIshould allow construction of sophisticated applications that satisfy theneeds of even the most demanding authors. This will allow sophisticated sitesto be made available universally.
The needs of the author lead to the following desirable characteristics ofauthoring techniques that support multiple device and delivery contexts.
Authoring techniques that support DI should support the fullrange of applications from the simplest to the most complex
Authoring techniques that support DI should scale smoothly incomplexity as the underlying application becomes more sophisticated
Applications and sites are often constructed by combining togethermaterials created at different times by different authors. The use of a mediaresource, such as an image, within a page of HTML provides a simple exampleof this. The text and the image are created separately and aggregated toprovide the final user experience. In this case, aggregation takes place inthe user agent. The individual resources being aggregated are known asauthored units.
Aggregation plays an important role in many practical implementations ofweb applications. For example, in a portal the results of processing severalapplications are brought together to provide a single user experience.Typically, the aggregation is carried out on the server supporting the portalitself. In some senses this capability is a server-side version of theaggregation carried out by user agents for specific types of content.
When supporting delivery contexts that have limited facilities forpresentation and interaction, it is often necessary to divide up resources toenable them to be used. For example, rather than delivering a large resourceto the device, a set of smaller resources with appropriate navigation can beused. Such division of material to support particular delivery context isknown asdecomposition.
Decomposition may be automated or may be under some level of authorcontrol. For some purposes and for some delivery contexts, it may besufficient for decomposition to be based simply on structural informationassociated with the authored units. For other purposes and for other deliverycontexts, authors may need some level of control over the decompositionprocess. In particular, authors usually wish to exercise some level ofcontrol over decomposition when it is being used to harmonize the userexperience in a particular delivery context rather than simply to overcomethe physical limitations of the associated device.
It is, of course, quite valid to create a resource by aggregation ofauthored units and then to decompose it for use on a small device. Suchoperations are common in portal applications, for example.
Anauthoredunit is a set of material created as a single entity by an author.Authored units can participate in aggregation operations. For example, anauthored unit might consist of statements in a device-independent markuplanguage that, when aggregated with additional statements from other sources,provides the basis for a user experience. The term is not restricted tomarkup, however. Any type of content might be created as an authored unit.
Authored units do not have to participate in aggregation. A singleauthored unit might be a complete description of a user experience, forexample. A simple web page, written in HTML and which references no externalresources, such as media or style sheets, is an example of such an authoredunit.
A number of aggregation mechanisms already exist within current W3Cstandards. Some of these mechanisms are specific to a particular type ofinformation set, such as anXSLT style sheet. Othersare more general.
TheXML Inclusions model is an example of thetype of aggregation envisaged as appropriate for use with authored units. Itappears to offer the appropriate level of function while retainingindependence from specific types of information set.
Authors need to be able to create authored units that can participate inaggregation operations if desired.
Authors need to be able to specify how a resource may be decomposed foruse in a delivery context for which it would be unsuitable in itsentirety.
Authoring techniques that support DI should explicitlysupport aggregation operations that allow authored units to be assembled aspart of the process of creating a user experience.
Authoring techniques that support DI should explicitlysupport decomposition of resources. Such decomposition should be capable ofbeing performed automatically or under author control.
Navigationis the means by which users alter theirfocusof attention. This can result in a different part of anactive perceivable unit becoming the focus of the user's attention, forexample. It can also result in a differentperceivableunit becoming active.
In HTML, for example, links between pages provide navigation across andbetween web sites. Links within pages provide more localized navigation. Inother markup languages, such links may provide quite different function. InWML, for example, internal links provide navigation that cannot be accessedwith more physical methods, making the loaded page behave more like part of asite.
The definition ofnavigationused by DIWG deliberately excludes mechanisms that change the focus ofattention without using mechanisms explicitly provided within the perceivableunit. Scrolling, for example, is not considered to be a navigationmechanism.
Some navigation may be explicitly authored. Other navigation may need tobe generated automatically from more abstract definitions. Such definitionscan allow different navigation to be generated depending on the deliverycontext.
Authors need to be able to specify relationships between and withinauthored units in ways that allow the appropriate navigation to be generatedduringadaptation.This allows for very different navigation to be implemented for use indifferent delivery contexts.
Authoring techniques that support DI need to provide mechanisms throughwhich authors can represent relationships that can form the basis ofnavigation generated during adaptation.
Authoring techniques that support DI should support abstractrepresentations of the relationships between and within authored units fromwhich specific navigation can be generated during adaptation
The vast majority of existing web sites and applications have been createdfor access from conventional personal computers and workstations. These sitesare 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 createdto 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 witholder applications that are not device independent and that are not beingrewritten.
Authoring techniques that support DI should allow materialfrom existing applications to be reused when constructing new, deviceindependent applications. Authoring techniques should allow such reuse at thetime the new application is being constructed. Authoring techniques shouldalso allow such reuse at the time the new application executes.
The challenge presented by the growth of diversity in the kinds of devicethat are used to access the web is often not appreciated by people notintimately involved in providing support for them. This section examines thetypes of device currently in use, the ways in which they connect to the weband the consequent implications for authors.
The networks used to connect to the web can play an important part in theoverall characteristics of the attached device. Both devices and networks areconsidered 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 usersaccessed the web. The differences in capabilities between the dozen or sodifferent browsers available for the computers most used to access webcontent were, and still are, accommodated by custom code being added tosites. Though the browsers do differ in detail, it is quite possible to builda wide variety of types of application that work tolerably well, by makingbroad assumptions about the capability of the user's systemand by providing additional textual material to aidaccessibility.
However, the situation with respect to devices is changing rapidly. At thetime of writing, there are now several hundred different types of device thatcan have web access. Among these devices there are huge variations incapability of processing, display and input.
As an example of the variability, consider some common categories ofdevice that can access the web.
Subsequent sections consider in detail those differences between devicesthat are most important, in terms of their ability to affect the final userexperience.
The range of capabilities of the large number of different devices thatnow have the ability to access the web is a major challenge for authors. Inaddition, new devices with different capabilities are being releasedregularly. Authors need authoring techniques that can allow them to supportthe diversity of existing devices without requiring excessive effort.
In addition, authors need to be able to use abstract representations ofthe capabilities of devices in creating their materials. They should, forexample, be able to access properties such as the physical dimensions of adisplay or the number of pixels per millimeter using representations that arethemselves independent of the device.
A number of characteristics of authoring techniques are highly desirablein supporting the wide range of capabilities of devices.
Authoring techniques that support DI should allow authors tocreate applications that support a wide variety of device capabilities.
Authoring techniques that support DI should providemechanisms that allow authors to express the user experience they wish toachieve using abstract representations of the underlying capabilities of thedevice.
Authoring techniques that support DI should providemechanisms that allow authors to express the layout of material that variesbetween 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 communicatemay consist of many components. The characteristics of the access mechanismcertainly include the characteristics of the device itself and of the networkby which it is connected to the web. In this section, some of thesecharacteristics are described to see why they are important in the generationof the final user experience.
This section isnot an exhaustive discussion of thesecharacteristics, nor does it describe the environment in which suchinformation is made available to authoring techniques that support DI. Thatdiscussion can be found in the documentDeliveryContext Overview for Device Independence. This section confinesdiscussion to the importance of some of the key characteristics for authors.In general terms, authors need to be able to express their instructions aboutthe way thataccess mechanism characteristics areused in determining how material is adapted to create the user experience onthe 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 DIis discussed inPersonalization. Thissection confines its discussion to the underlying physical characteristics ofthe devices and access mechanisms.
Some characteristics of the access mechanism are closely associated withthe device. This section covers some of the more important of thesecharacteristics.
The physical size of the display on a device is almost invariably a staticproperty. The physical resolution of the display, for example, the number ofpixels in the horizontal and vertical directions, is also essentially static.However, the resolution actually in use in any particular situation might bedifferent from the natural values associated with the device hardware. It isquite common, for example, for CRT and LCD displays to be able to operate ina variety of modes when attached to devices such as personal computers andworkstations. These modes often include the ability for the display to act asa window onto a larger desktop. While such resolution changes are less commonon smaller devices, such as PDAs, it is, nonetheless, possible to finddisplays used in portrait or landscape mode in different situations.
The way in which a device is used also has implications for the effectivesize and resolution of its screen. Digital television systems, for example,have resolutions approaching those of a basic personal computer. However, thedistance from user to device is much larger for a television system than fora personal computer. As a result, it is necessary to use larger fonts andimages than would be the case for a personal computer, and the effective sizeof the screen is less.
Screen size and resolution are particularly important forauthoring techniques that support DI. Not only arethey important considerations in defining the appropriate visual mediaresources to use, they are also a major determinant in the design of thephysical layout of the user experience. Authors may need to design differentphysical layouts and different ways of organizing the way material is madeavailable to the user to take account of differences in the size andresolution of the displays in use.
The color capability of the display on a device is also usually a staticproperty. However, user agents may elect not to use the full capability,leading to variability in color support. For color displays and printers, itis often expressed simply as some measure of the number of different shadesand colors that the display can generate.In moredemanding applications, for example those that demand photo realism,knowledge of other parameters such as the gamma factor of a display or thephysical characteristics of the ink and paper used for printing, areimportant in generating a harmonized user experience.
The color capability of a display is important for authoring techniques that support DI. Like physicalscreen size, color capability can be important in defining the appropriatevisual media resources to use, particularly where multiple versions withdifferent color properties are available.
Some devices are inherently capable of displaying video clips. Othersdepend upon browsers or installed applications to provide the support. Onceagain, although the capability may vary based on configuration orinstallation of special software, video capabilities are usually consideredas a static property of the device. As with other media resources, theprimary importance, from the standpoint of authoring techniques that supportDI, is in ensuring that appropriate versions are used that are compatiblewith the device's capabilities.
As with video capabilities, some devices are inherently capable of playingaudio clips. Others depend upon browsers or installed applications to providethe support. Indeed, it is common for the same software to provide both audioand video capabilities. As with video, although the capability may vary basedon configuration or installation of special software, audio capabilities areusually considered as a static property of the device. As with other mediaresources, the primary importance, from the standpoint of authoringtechniques that support DI, is in ensuring that appropriate versions are usedthat are compatible with the device's capabilities.
In addition to this consideration, however, audio has other potentialalternate uses in authoring techniques that support DI. Under the rightcircumstances, appropriate audio might provide a useful alternative to videoor image media resources on devices with no display, for example.
Input capabilities on devices vary enormously. Workstation devices withfull keyboards are usually considered convenient for input of largequantities of data. Mobile phones, often with little more than a simplekeypad, are generally considered not to be. In some situations, it might bepossible for users to express personal preferences associated with particulardevice input capabilities. Such preferences are discussed inPhysical Input and Output
The ease of use of a device's input facilities is of importance to aninteraction designer. It might be that the interaction between an applicationand its users needs to be simplified for use on devices without sophisticatedinput capabilities. In the extreme case, complete functions might be omittedwhen such a device is in use. Complex application registration procedures,for example, that require completion of relatively large forms with manyfields 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 providingthe ability for designers to control how interactions are expressed ondevices with very different capabilities.
Some characteristics of an access mechanism are closely associated withthe network through which the device is connected. This section describesthese characteristics.
The declared bandwidth, is the bandwidth, and hence the speed of datatransfer, inherently associated with the device and the network it isconnected to. The declared bandwidth for anaccessmechanism is a static property. For a mobile phone on the GSM network, forexample, the declared bandwidth might be 2400 baud. The actual bandwidth willvary from minute to minute and will depend on many factors, including howbusy the network is. However, the declared bandwidth is a reasonable startingpoint for making decisions about how the application runs based on the speedwith which data can be exchanged with the end user.
Bandwidth can be an important consideration forauthoring techniques that support DI. Content creators may wish to makeavailable versions of media resources, often the largest single items on apage, specifically optimized for low bandwidth connections. A content creatormight even prefer to provide alternatives, such as text, for use on very slowconnections, for example. On faster connections, they might want to provideversions of video clips compressed by different amounts to accommodate accessmechanisms with a variety of different bandwidths.
Some access mechanisms provide information about the bandwidth that iscurrently available to the device. Where this information is available, itcan be used in conjunction with, or in place of the declared bandwidth justdiscussed. The implications for DI of actual bandwidth values are identicalto those for declared bandwidth. The only difference is in the timeliness ofthe values.
There are other characteristics of the access mechanism that may noteasily be assigned to device or network. These characteristics are covered inthis section.
In the discussion so far, only characteristics of the access mechanismitself have been considered. However, end users may have a significant effecton the delivery context if, for example, they are able to personalize variouscharacteristics of the device. Such personalization, whether for reasons ofpersonal preference or for the purpose of accessibility is covered later inthe sectionPersonalization andAccessibility.
Some mobile devices and access mechanisms are able to report their currentlocation. This is clearly a dynamic characteristic of the device. While otherdynamic 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 mighttailor the content presented based on the user's location. However, the wayin which the material is presented and the nature of any interaction is notlikely to be sensitive to the user's location. Location is likely to be moreinteresting for applications than for authoring techniques that supportDI.
Where systems support access from multiple devices, it can be necessary toconsider the effect of the same user accessing applications from differentdevices at different times. Essentially, the nature of theaccess method changes between successive accesses tothe application.
This section describes scenarios in which this might occur.
User's may need to access the sameUniform Resource Identifiers (URI) with different devices. TheOne User, Multiple DevicesScenario illustrates this need. This particular example is based on auser with a need for accessibility. The need for access to applications frommultiple devices is, of course, not restricted to users with specialaccessibility needs. The important point for this discussion is that it maybe very convenient for the devices used to be able to share bookmarks ofimportant applications.
Authors would like their sites to be accessible via URIs that can be usedfrom multiple devices with a minimum of effort. From the perspective of anauthoring technique that supports DI, this implies that it is advantageousfor the URIs associated with pages that support DI to be independent of thedevice accessing them. The need for device independent URIs arises inprinciple DIP-2 of theDevice IndependencePrinciples.
One natural consequence of the ability for a user to access the sameapplications on a variety of devices is that they may wish to start abusiness transaction on one device and complete it on another. TheTransaction Continuation UsageScenario illustrates this usage. In this scenario there is an explicitchange of access method during the transaction. The booking is made on onedevice, the payment on another. Much of the capability required to do thisis, of course, a function of the application. In particular, it must be ableto maintain the state of the transaction over some period of time.
The requirement to provide this capability probably has little additionalimpact on the user experience. All that is necessary is that the authoringtechnique being used does not preclude it.
The perceived usability of a particular application depends on manyfactors, including how it has been authored and the preferences of the userusing it. Users with specific disabilities, for example, may perceiveusability very differently.
The inherent capabilities of the device play an important role in overallusability. For example, it is probably wise for an author to avoid askingusers to enter large volumes of text if they are accessing the applicationfrom a typical mobile phone. The keyboards of such devices are not ideal forthe task.
It would be very useful for authors to have available some absolute metricof usability associated with each technical feature of a particular device.These metrics might define how usable the keyboard is, how good thehandwriting recognition and so on. However, such metrics are notoriouslydifficult to specify and to measure. In addition, the values associated withsuch metrics need to be subject to preferences so that individual users mayexpress their view of the usability.
Though the Device Independence Working Group recognizes the desirabilityfor such metrics, their development and specification is considered outsidethe scope of its current work.
Authors need to consider the implications for the usability of theapplications they create when accessed through devices with differingcapabilities.
Authoring techniques that support DI should allow authors tocreate user experiences in which the usability is appropriate within a widerange of delivery contexts.
The ability for a user to exercise some level of control over theirexperience of a web site is an important capability of the web. Not only doesit allow users to specify their own personal preferences, it is also animportant component in the ability for the web to provide user experiencesthat increase accessibility.
This section discusses the authoring implications of personalization ingeneral and at how that may affect accessibility in particular.
The termpersonalization, when used in relation to web sites andapplications, covers much more than the ability for a user to influence theirexperiences. Increasingly, applications themselves offer users the ability totailor the function available to best suit their needs. Much of thispersonalization activity is related to application function that isindependent of the user experience itself. However, that part ofpersonalization that is relevant for presentation is of direct concern toauthors when creating sites that support multiple delivery contexts. Forexample, a user might select one particular type of user experience on thedevice in preference to others. Equally, a user might wish to prevent use ofa particular device capability.
It is theoretically possible for a user to change the personalizationassociated with the user experience on their device as often as they wish. Inpractice, however, changes in personalization during a particular interactionare 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 providesadditional criteria that affect the process by which a resource is adaptedfor use in a particular delivery context.
Many of the user experience properties that a user may wish to personalizeare 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 apage to improve legibility. Likewise, a user might prefer writing on a deviceover using its input keys. They might elect to avoid using the keyboard ofthe device, preferring to make use of its handwriting recognitioncapabilities instead.
Some kinds of device even allow a user to select the resolution of thedisplay in use and to change between portrait and landscape modes.
Where a device offers multiple modalities, a user might choose to useother than the default. This could be for reasons associated withaccessibility. Accessibility will be discussed in a later section. It couldalso be that in certain circumstances one particular modality of the deviceis more appropriate than another. For example, there might be a mobile devicethat offers a conventional display and miniature keyboard, but that offersthe alternative of audio output and voice recognition. While at home or inthe office, a user might prefer to use the display and keyboard, but mightchange the modality to be voice-based while using it in the car.
From the perspective of the author, the ability of a user to specifypreferences may mean that additional materials need to be provided.Personalization of the user experience generally works well within the boundsof the materials that an author allows or supports. Consequently, it ispossible that support for preferences associated with the user experiencecould cause the need for different versions of content, stylisticinformation, layout and media to be available.
Authors need access to techniques that make the creation and management ofthis material as simple as possible.
From the considerations for authors, the following requirements arise.
Authoring techniques that support DI should allowpersonalization information that relates to the user experiences to beincluded during the process of adaptation of material for use in theparticular delivery context.
Authoring techniques that support DI should take intoconsideration the modality of the device during the adaptation process.
Like personalization, the selection of the language to be used tocommunicate with the user has many implications for web sites andapplications. However, only a few of those implications are directly relatedto the user experience associated with the material.
One aspect of the user experience that can be affected by language, islayout. For example, the direction in which the characters of a particularlanguage is rendered might affect whether a portrait or landscape layout ismore appropriate for a particular part of the page. Similarly, the length ofwords in a particular language might cause the need for the arrangement oflabeled buttons in a form to be altered to optimize the use of the availablespace.
In addition, where media resources, such as images, contain text, it willbe necessary to include additional versions to support multiple languages.
From the perspective of the author, support for multiple languages doesnot really introduce any fundamentally new challenges. However, languagesupport can mean that additional versions of layouts, media and stylisticinformation might be needed.
From the discussions it is clear that
Authoring techniques that support DI should allow language toinfluence the adaptation process under the appropriate conditions
In particular, authoring techniques that support DI shouldallow language to influence the choice of the layout and styles used inparticular delivery contexts
Although not strictly a DI issue,authoring techniques that support DI might usefully support the ability toinclude language in the control of selection or creation of the mediaresources to be used for a particular device.
In some geographies and for some networks, users might be especiallysensitive to the cost of transmission of material between their device andthe servers that provide it. In this kind of situation, users might employpersonalization to control such costs. For example, a user might elect toview only small, gray scale images as opposed to the large color images thattheir device can support. Similarly, they might elect not to receive imagesat all, preferring some kind of alternate, text based representation of theinformation.
TheData Transmission Cost Scenariogives an example.
Once again, from the perspective of the author, the user experienceaspects of supporting personalization based on cost does not really introduceany fundamentally new challenges. However, this type of personalization mightmean that additional versions of materials, and in particular mediaresources, might be needed.
There are really no new implications for authoring techniques that supportDI. The same kinds of issues arise as have been covered already. Thedifference here is in the motivation of the user for applying thepersonalization.
It is possible to view accessibility as one of the applications ofpersonalization. From a user's perspective it is, of course, much more thanthe ability to change a user experience to match taste. Accessibilityconcerns the ability of users to change the user experience to allow them toperceive and use the information conveyed and to interact with theapplication.
The mechanisms involved in supporting accessibility are, however, just thesame as those for personalization of the user experience. The considerationsfor authors are the just the same, as are the implications for authoringtechniques that support DI.
Issues relating to authoring of content for greater accessibility areaddressed in theWeb Content Accessibility Guidelinesrecommendation and that issues relating to accessibility in authoring toolsare addressed in theAuthoring Tool AccessibilityGuidelines recommendation.
Although personalization used for accessibility is essentially the same aspersonalization for other reasons, at least in a technical sense, devicesthat promote types of accessibility may be very different from those normallyencountered. In particular, there may be devices which produce output, suchas Braille, that is very different from that normally encountered. In thisexample, of course, the output is an entirely new modality.
Once again, the implications for authors center around the need to providecontent, layout and thematic information that is appropriate for the newtypes of device. This is, in principle, a simple extension of ideas that havealready been discussed several times. However, the new feature here is thepotential need for radical approaches where the device has capabilities, suchas Braille output, that are very different from those associated with moreconventional systems.
Many of the issues may, in fact, be design related rather thanimplementation related. The rules for layout of an appealing and attractiveweb page for display on a Braille device are likely to be very different fromthose for use on a conventional PC display.
The implications for authoring techniques that support DI are not verydifferent from those already discussed. As long as the mechanisms areavailable to create or select different content, layout, thematic informationand media resources, support for new devices is in principle possible. Inaddition, however, newer devices for accessibility may well be multi-modal.Consequently, all of the implications already discussed for those types ofdevices will also apply here.
In a very real sense, almost all of the considerations for authors, thathave been discussed in this note, are associated with the affordability ofcreating applications. It is possible to support access to the web from alarge number of different access mechanisms by writing an entire site foreach one. This is not, however, an affordable solution when the number ofdevices involved is several hundred and growing continually.
Affordability is an important consideration for authors when making thedecision to participate in any new technology. There are a number ofindividual considerations for authors, associated with affordability. Each isconsidered in the this section. They include familiarity, the costs of devicediversity, the possibility of automatic support for devices and the abilityto target effort in customizing the user experience.
One good way to reduce the cost of an implementation is to ensure thatexisting skills can be easily transferred. If authors find an approachfamiliar, they can become productive with it quickly and without the need forlengthy retraining. They may also be able to use familiar tools with the newapproach.
Many existing W3C recommendations are applicable in providing elements ofauthoring techniques that support DI. These recommendations are alreadyfamiliar to web authors. They can provide the basis for such approacheswhilst allowing authors to apply their knowledge and expertise.
To maximize familiarity, authoring techniques that support DI should bebased on existing W3C recommendations wherever possible. In particular:
Elements, of an authoring technique supporting DI, thatinvolve explicit definition of presentational markup should, if possible, bebased on existing markup specifications, for example theXHTML family of specifications,SMIL andSVG.
Elements, of an authoring technique supporting DI, thatinvolve explicit definition of interaction models should, if possible, bebased on theW3C XForms specification.
Any new definitions that fall completely outside the realm ofexisting, presentation-related or interaction-related recommendations should,if possible, be based on the W3CXML specification
Elements, of an authoring technique supporting DI, thatinvolve transformation of information between different markup-basedrepresentations should, if possible, be based on the W3CXML andXSLT specifications.
There are now literally hundreds of different devices that have thecapability to connect to the web. There is enormous diversity in thefacilities offered by such devices. This diversity poses a significantchallenge for authors.
There are, of course, basic standards covering groups of devices. Forsmall, mobile, devices, for example, W3C recommendations, such asXHTML Basic andCSSMobile Profile might be used. Alternatively, the device might follow theOpen Mobile Alliance'sWAP Specifications. Frequently,however, there is variation in the way in which manufacturers implement thestandards. Sometimes the implementation may be incomplete. Sometimes theimplementation may extend beyond the standard. Authors must find ways tocater for this level of variability even within a specific standard.
The standards that are applicable to web access from devices rightly donot constrain the physical characteristics of the device itself. As hasalready been mentioned, display size, media capabilities, input mechanismsand even modalities can vary greatly between devices. Applications designedto run on a device with one particular set of such characteristics behavepoorly or fail to work at all when the device has characteristics verydifferent from those envisaged by the author. New network capabilities,associated with technologies such as GPRS (General Packet Radio Service) andthe so-called third generation, high speed, networks compound the challengefor authors.
Another challenge for authors is not simply the diversity of the devicesthat already exist, but the rate at which new devices are being introduced.The potential maintenance effort associated with keeping a web site currentwhile supporting new devices as they appear is very significant.
A functional user experience is one where the user is able to complete thefunction intended by the author on a particular device within a particulardelivery context. Although functional, the user experience is not necessarilytailored for the device, or other aspects of the delivery context. Inaddition, it does not necessarily exploit any special capabilities that thedevice may possess. The ability to provide a functional user experience canplay an important role in improving the affordability of an authoringtechnique that supports DI. In particular, affordability can be improvedgreatly if a functional user experience can be created with a minimum ofauthoring effort, and without the need for the author to have specificexpertise concerning the device and delivery context being supported.
A harmonized user experience is one specifically tailored to the targetdevice and delivery context. Creation of a harmonized user experience usuallyrequires that an author has provided additional materials over and abovethose required for a functional version.
The degree to which a user experience is harmonized should be under thecontrol of the author. From an affordability standpoint, an author should beable to apply as little or as much customization as necessary to achieve alevel of harmonization appropriate for the device and delivery context inquestion. In addition, the effort required to harmonize a user experienceshould rise smoothly. There should not be a large increase in cost associatedwith a small change in the level of harmonization of the user experience.
Authors are faced with major challenges as device diversity increases. Theeffort in just maintaining a site can quickly become unaffordable as thenumber of devices increases. In addition, as new devices appear there may betime pressures in providing support that may also be difficult to satisfy.
Authors can also be faced with the challenge of maintaining expertise inthe characteristics of a large and growing set of devices. Once again, thechallenge of simply maintaining the device expertise can quickly overwhelmthe available resources. Affordability is compromised, for example, ifsupport for new devices requires authors to change the application. Authorswould like functional user experiences on the majority of new devices to beprovided automatically.
Authors should be able to create functional user experiences foradditional devices with little or no effort and without the need for specialexpertise. They should be able to invest as little or as much additionaleffort in customizing user experiences for selected devices and deliverycontexts.
The large number of devices becoming available means that authors areoften unaware of new developments. Even if they are, there is often a limitedability for them to update their applications to support every new devicethat appears. Consequently, authors would like access to authoring techniques that can provide some level ofsupport to new devices without needing any changes to existingapplications.
The challenges of supporting large numbers of diverse devices suggest thefollowing characteristics of approaches that support DI:
Authoring techniques should allow authors to support a widevariety of devices with diverse capabilities without excessive effort.
Authoring techniques that support DI should allow authors tosupport a wide variety of devices with diverse capabilities without the needfor detailed knowledge of the precise characteristics of each one.
Authoring techniques that support DI should allow functionaluser experiences to be created for multiple devices without excessiveeffort.
Authoring techniques that support DI should allow authors tocustomize user experiences for particular devices or classes of device.
Authoring techniques that support DI should allow authors toexploit the capabilities of a device in a harmonized user experience if theywish to do so.
Authoring techniques that support DI should allow authors tochoose how much effort to invest in customizing the user experience forparticular devices or classes of device. The relationship between the amountof effort invested by an author and the level of customization achievedshould be simple and smooth with no discontinuities.
Authoring techniques that support DI should allow support forat least a functional user experience to be provided, on devices notconsidered during development of an application, without the need foradditional authoring effort wherever possible.
Reuse of materials is another way to enhance the affordability of supportfor multiple devices. There are two broad aspects of reuse. The first is theability to author new material that can be shared by user experiences usedfor multiple devices. The second is the ability to use materials previouslyauthored for single device versions of an application in a new version thatsupports many different devices.
The desirability of reuse for authors is self evident. There is asignificant reduction in effort required for developing user experiences ifnew 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 ofdevices, overall effort can be reduced.
Authors would like to be able to use new materials to support a range ofdevices wherever possible. They would also like to be able to use materialsthat already exist in creating new applications or new versions ofapplications.
Some aspects of reuse are associated with the tools that an author employsto develop a site. For example, reuse of image resources can be made possiblewith tools that convert them to forms useful on different kinds of device. Alarge, color image implemented using the Portable Network Graphics (PNG)encoding could be converted to a small bitmap for use on a mobile phone, forexample.
Other aspects of reuse can depend on fundamental properties of the authoring technique used. Authoring techniques thatclearly separate device dependent and device independent aspects ofauthoring, for example, enable reuse of the device independent material. Inaddition, authoring techniques that allow automatic support for new devicesas they appear, without the need for changes to applications, are alsoproviding reuse.
Authoring techniques that support DI should allow forsignificant reuse of material.
Authoring techniques that support DI should encourage reuseby providing a clear separation between material that is device independentand material that is device dependent.
Authoring techniques that support DI should allow support forfunctional user experiences to be provided on devices not considered duringdevelopment of an application, without the need for additional authoringeffort, wherever possible.
Testing of applications that support multiple devices and deliverycontexts can be onerous. Often, the only avenue open to authors anddevelopers is to test the application for correctness on real examples of thedevices that must be supported. Emulators are available but vary in thefidelity with which they mimic the behavior of the devices they represent.
The Device Independence Working Group recognizes that assistance intesting could be a valuable aid to affordability. However, it is felt thatsuch assistance is an implementation issue and is an area that can providedifferentiation between vendor offerings.
Ms. Kaseem is a teenager with low vision who is also deaf. She uses theWeb to find new restaurants to go to with her friends and classmates. At homeshe uses a combination of screen magnifier and screen reader with refreshablebraille to browse the Web. She also has a portable braille device which sheuses in public places such as malls and restaurants. (See theteenagerexample fromHow People with Disabilities Use theWeb for a detailed description of the use case).
Angela subscribes to a service run by a local concert hall that informsher of late availability of tickets at discount prices. At work one morning,she receives notification of availability of tickets for a concert includingMahler's Fifth Symphony. She has been waiting for the opportunity to take hermother to a Mahler concert for some time. Using her PC she provisionallybooks two tickets in prime locations in the knowledge that she must purchasethem within 6 hours or lose the booking. She bookmarks the acknowledgmentreturned by the concert hall and synchronizes it with her PDA. Later in theday, on the way back to the office after a meeting with a client, she finallymanages to contact her mother, who is delighted at the invitation and lookingforward to the concert. Angela realizes that she must confirm the bookingsoon. She returns to the concert hall's application using her PDA and mobilephone. 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 fromthe same Web site, Jimmy and Tommy however have different views on how tospend the $30 pre-paid card their dad has given them. Jimmy prefers thecartoon to be downloaded as high resolution images most of the time, whileTommy prefers a small picture in low resolution graphics, thus saving up tochat with his friends via instant messages later.
Calvin Mentmore is a sales representative who is rarely in the office. Hismain role is to make his customers aware of new products. He knows that forhis business, putting a good-quality personalized brochure into the hands ofhis customer, while explaining the benefits of the product, leads to moresales. Being mainly on the road, he uses a phone-connected laptop or PDA topersonalize product literature before a customer visit. Bandwidth is oftentoo limited for Calvin to download the resulting high-resolution brochure.Instead, using the same URI, he requests a thumbnail view of the brochurepages on the screen and then prints a medium-resolution image of only thepages he has customized on his portable wireless printer, to check they arewell-paginated and contain the right information. He emails theURI of the personalized brochure to his customer for the unlikely eventof the customer browsing it on the web in advance. Calvin calls in at a localprinting service on his way to the customer, gives them the brochure URI, andlets their printer fetch the high-quality version of the brochure directlyfrom his office website, which is printed and bound ready for him to hand tothe customer during the visit.
This document discussed the challenges that authors commonly face whenbuilding web content and applications that can be accessed by users via awide variety of different devices with different capabilities. The documentexamined the effects on authors and the implications for authoring techniquesthat assist in the preparation of sites that can support a wide variety ofdevices. As a consequence, it derived a set of requirements for suchtechniques.
Within the discussions in this document, a significant number of specificrequirements for systems that support DI authoring have been identified. Inthe following sections, these are grouped into general categories to providean overall summary of the requirements.
The following members of the W3C Device Independence Working Group havehelped develop this Working Draft through their comments, proposals anddiscussions at teleconferences, face-to-face meetings and via the groupdiscussion list.
At the time of publication, the principal and active members of the groupwere as follows:
The following were members of the group at earlier stages of itsdrafting: