index.html 140 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <title>Authoring Challenges for Device Independence</title>
  <style type="text/css">
    h5.impl { font: bold italic 100% sans-serif; margin-bottom: 0 }
    p.impl { background-color: #FFFFE0; color: black; border: thin solid;
             margin-top: 0; margin-bottom: 10px; padding: 5px }

    </style>
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"
  rel="stylesheet" type="text/css">
</head>

<body lang="en">

<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72"></a>

<h1 id="title">Authoring Challenges for Device Independence</h1>

<h2>W3C Working Group Note 1 September 2003</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/NOTE-acdi-20030901/">http://www.w3.org/TR/2003/NOTE-acdi-20030901/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
    href="http://www.w3.org/TR/acdi/">http://www.w3.org/TR/acdi/</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/WD-acdi-20021018/">http://www.w3.org/TR/2002/WD-acdi-20021018/</a></dd>
  <dt>Author:</dt>
    <dd>Rhys Lewis (Volantis Systems) <a
      href="mailto:rhys.lewis@volantis.com">&lt;rhys.lewis@volantis.com&gt;</a></dd>
  <dt>Contributors:</dt>
    <dd>See <a href="#sec-acknowledgements">Acknowledgements</a></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
©2003 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a> <sup>®</sup> ( <a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a> , <a
href="http://www.ercim.org/"><abbr
title="European Research Consortium for Informatics and Mathematics ">ERCIM</abbr></a>
, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p>
</div>
<hr title="Separator for header">

<h2><a name="abstract">Abstract</a></h2>

<p>This document discusses the challenges that authors commonly face when
building web content and applications that can be accessed by <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user">users</a> 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.</p>

<p>This document is one of a series produced by the Device Independence
Working Group, part of the <a href="http://www.w3.org/2001/di/">W3C Device
Independence Activity</a>. The DIWG activity statement can be seen at <a
href="http://www.w3.org/2001/di/Activity">http://www.w3.org/2001/di/Activity</a>.</p>

<p>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.</p>

<p>Details of the entire series of documents can be found on the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a> home
page.</p>

<h2><a name="status">Status of this Document</a></h2>

<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a>
at http://www.w3.org/TR/.</em></p>

<p>This document is one of a series produced by the Device Independence
Working Group, part of the <a href="http://www.w3.org/2001/di/">W3C Device
Independence Activity</a>. The DIWG activity statement can be seen at <a
href="http://www.w3.org/2001/di/Activity">http://www.w3.org/2001/di/Activity</a>.</p>

<p>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.</p>

<p>Comments on this document can be sent to <a
href="mailto:www-di@w3.org">www-di@w3.org</a>, the public forum for
discussion of the W3C's work on Device Independence. To subscribe, send an
email to <a href="mailto:www-di-request@w3.org">www-di-request@w3.org</a>
with the word subscribe in the subject line (include the word unsubscribe if
you want to unsubscribe). The <a
href="http://lists.w3.org/Archives/Public/www-di/">archive</a> for the list
is accessible online.</p>

<p>Patent disclosures relevant to this document may be found on the <a
href="http://www.w3.org/2001/di/Disclosures.html">WG patent disclosure
page</a>.</p>

<h2><a name="contents">Table of Contents</a></h2>
<ul class="contents">
  <li><a href="#sec-introduction">1 Introduction</a>
    <ul class="contents">
      <li><a href="#sec-scope">1.1 Scope</a></li>
      <li><a href="#sec-goals">1.2 Goals</a></li>
      <li><a href="#sec-audience">1.3 Audience</a></li>
      <li><a href="#sec-organisation">1.4 Organization of the
      Material</a></li>
      <li><a href="#sec-terminology">1.5 Terminology</a></li>
    </ul>
  </li>
  <li><a href="#sec-authoring-roles">2 Authoring Roles</a>
    <ul class="contents">
      <li><a href="#sec-designers">2.1 Designers</a>
        <ul class="contents">
          <li><a href="#sec-layout-designers">2.1.1 Layout Designers</a></li>
          <li><a href="#sec-stylistic-designers">2.1.2 Stylistic
          Designers</a></li>
          <li><a href="#sec-interaction-designers">2.1.3 Interaction
            Designers</a></li>
          <li><a href="#sec-navigation-designers">2.1.4 Navigation
            Designers</a></li>
        </ul>
      </li>
      <li><a href="#sec-content-creators">2.2 Content Creators</a></li>
      <li><a href="#sec-business-logic-creators">2.3 Business Logic
        Creators</a></li>
      <li><a href="#sec-interactions-between-roles">2.4 Interactions Between
        Roles</a></li>
    </ul>
  </li>
  <li><a href="#sec-applications-content">3 Applications and Content</a>
    <ul class="contents">
      <li><a href="#sec-application-general">3.1 General Considerations</a>
        <ul class="contents">
          <li><a href="#sec-application-consid">3.1.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-application-impl">3.1.2 Implications for
            Authoring Techniques that support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-application-interactivity">3.2 Application
        Interactivity</a>
        <ul class="contents">
          <li><a href="#sec-non-interactive-applications">3.2.1
            Non-Interactive Applications</a></li>
          <li><a href="#sec-interactive-applications">3.2.2 Interactive
            Applications</a></li>
        </ul>
      </li>
      <li><a href="#sec-application-dynamics">3.3 Application Dynamics</a>
        <ul class="contents">
          <li><a href="#sec-static-content">3.3.1 Static Content</a></li>
          <li><a href="#sec-dynamic-raw-data">3.3.2 Dynamically Acquired Raw
            Application Data</a></li>
          <li><a href="#sec-dynamic-presentation">3.3.3 Dynamically Acquired
            Data Containing Presentation Markup</a></li>
          <li><a href="#sec-dynamic-markup">3.3.4 Dynamically Acquired Data
            Containing Other Markup</a></li>
          <li><a href="#sec-dynamic-media-resources">3.3.5 Dynamically
            Acquired Media Resources</a></li>
        </ul>
      </li>
      <li><a href="#sec-client-function">3.4 Applications with Client-Side
        Function</a>
        <ul class="contents">
          <li><a href="#sec-client-function-auth">3.4.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-client-function-impl">3.4.2 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-appl-rich-media">3.5 Applications Using Rich Media</a>
        <ul class="contents">
          <li><a href="#sec-appl-rich-media-auth">3.5.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-appl-rich-media-impl">3.5.2 Implications for
            Approaches that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-appl-sync">3.6 Applications Supporting Synchronized
        Access Mechanisms</a></li>
      <li><a href="#sec-appl-complexity">3.7 Application Complexity</a>
        <ul class="contents">
          <li><a href="#sec-appl-complexity-auth">3.7.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-appl-complexity-impl">3.7.2 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-aggr-auth-unit">3.8 Authored Units, Aggregation and
        Decomposition</a>
        <ul class="contents">
          <li><a href="#sec-aggr-auth-unit-defn">3.8.1 Authored Units</a></li>
          <li><a href="#sec-aggr-auth-unit-incl">3.8.2 The XML Inclusions
            Aggregation Model</a></li>
          <li><a href="#sec-aggr-auth-unit-auth">3.8.3 Considerations for
            Authors</a></li>
          <li><a href="#sec-aggr-auth-unit-impl">3.8.4 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-relationship-navigation">3.9 Relationships and
        Navigation</a>
        <ul class="contents">
          <li><a href="#sec-relationship-navigation-auth">3.9.1
            Considerations for Authors</a></li>
          <li><a href="#sec-relationship-navigation-impl">3.9.2 Implications
            for Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-existing-apps">3.10 Existing Applications</a>
        <ul class="contents">
          <li><a href="#sec-existing-apps-auth">3.10.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-existing-apps-impl">3.10.2 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#sec-device-access">4 Devices and Access Mechanisms</a>
    <ul class="contents">
      <li><a href="#sec-device-diversity">4.1 Device Diversity</a>
        <ul class="contents">
          <li><a href="#sec-device-diversity-auth">4.1.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-device-diversity-impl">4.1.2 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-aware-access">4.2 Awareness of the Access
        Mechanism</a>
        <ul class="contents">
          <li><a href="#sec-aware-device-characteristics">4.2.1 Device
            Characteristics</a></li>
          <li><a href="#sec-aware-network-characteristics">4.2.2 Network
            Characteristics</a></li>
          <li><a href="#sec-aware-other-characteristics">4.2.3 Other
            Characteristics</a></li>
        </ul>
      </li>
      <li><a href="#sec-changes-access">4.3 Changes in the Access
        Capability</a>
        <ul class="contents">
          <li><a href="#sec-shared-bookmarks">4.3.1 Shared Bookmarks</a></li>
          <li><a href="#sec-access-change-transaction">4.3.2 Access Method
            Alteration During a Transaction</a></li>
        </ul>
      </li>
      <li><a href="#sec-usability">4.4 Usability</a>
        <ul class="contents">
          <li><a href="#sec-usability-auth">4.4.1 Considerations for
            Authors</a></li>
          <li><a href="#sec-usability-impl">4.4.2 Implications for Authoring
            Techniques that Support DI</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#sec-pers-access">5 Personalization and Accessibility</a>
    <ul class="contents">
      <li><a href="#sec-personalisation">5.1 Personalization</a>
        <ul class="contents">
          <li><a href="#sec-physical-io">5.1.1 Physical Input and
          Output</a></li>
          <li><a href="#sec-language">5.1.2 Language</a></li>
          <li><a href="#sec-cost">5.1.3 Cost</a></li>
        </ul>
      </li>
      <li><a href="#sec-pers-for-access">5.2 Personalization for
        Accessibility</a></li>
      <li><a href="#sec-devices-accessibility">5.3 Specialized Devices for
        Accessibility</a>
        <ul class="contents">
          <li><a href="#sec-devices-accessibility-auth">5.3.1 Considerations
            for Authors</a></li>
          <li><a href="#sec-devices-accessibility-impl">5.3.2 Implications
            for Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#sec-affordability">6 Affordability</a>
    <ul class="contents">
      <li><a href="#sec-familiarity">6.1 Familiarity</a>
        <ul class="contents">
          <li><a href="#sec-familiarity-impl">6.1.1 Implications for
            Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-affordability-device-diversity">6.2 Device
        Diversity</a>
        <ul class="contents">
          <li><a href="#sec-functional-user-experience">6.2.1 Functional User
            Experience</a></li>
          <li><a href="#sec-customised-user-experience">6.2.2 Customized User
            Experience</a></li>
          <li><a href="#sec-affordability-device-diversity-auth">6.2.3
            Considerations for Authors</a></li>
          <li><a href="#sec-affordability-device-diversity-impl">6.2.4
            Implications for Authoring Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-reuse">6.3 Reuse</a>
        <ul class="contents">
          <li><a href="#sec-reuse-auth">6.3.1 Considerations for
          Authors</a></li>
          <li><a href="#sec-reuse-impl">6.3.2 Implications for Authoring
            Techniques that Support DI</a></li>
        </ul>
      </li>
      <li><a href="#sec-testing">6.4 Testing</a></li>
    </ul>
  </li>
  <li><a href="#sec-scenarios">7 Usage Scenarios</a>
    <ul class="contents">
      <li><a href="#sec-scenarios-user-mult-devices">7.1 One User, Multiple
        Devices Scenario</a></li>
      <li><a href="#sec-scenarios-txn-continuation">7.2 Transaction
        Continuation Usage Scenario</a></li>
      <li><a href="#sec-scenarios-txn-continuation">7.2 Transaction
        Continuation Usage Scenario</a></li>
      <li><a href="#sec-scenarios-data-cost">7.3 Data Transmission Cost
        Scenario</a></li>
      <li><a href="#sec-scenarios-printing">7.4 Printing Scenario</a></li>
    </ul>
  </li>
  <li><a href="#sec-conclusions">8 Conclusions</a>
    <ul class="contents">
      <li><a href="#sec-conclusions-categorising">8.1 Categorizing the
        Challenges</a></li>
    </ul>
  </li>
  <li><a href="#sec-references">A References</a></li>
  <li><a href="#sec-acknowledgements">B Acknowledgments</a></li>
</ul>

<h2><a name="sec-introduction">1 Introduction</a></h2>

<h3><a name="sec-scope"></a>1.1 Scope</h3>

<p>This note reviews the challenges that web authors face in supporting
access to their sites from a variety of different <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-device">devices</a>.
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 <em>Authoring Challenges</em> 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.</p>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-interaction">interaction</a>
with the user via a range of <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-modality">modalities</a>.
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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a href="http://www.w3.org/2001/di/">W3C Device
Independence Activity</a>.</p>

<h3><a name="sec-goals"></a>1.2 Goals</h3>

<p>This note is one of the deliverables of the Device Independence Working
Group. It has the following specific goals.</p>

<h4 id="sec-authoring-considerations">Authoring Considerations</h4>

<p>Identify the difficulties that authors face in an environment in which
there is an increasingly diverse set of devices used to access web sites.</p>

<h4 id="sec-authoring-implications">Authoring Implications</h4>

<p>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.</p>

<h3><a name="sec-audience"></a>1.3 Audience</h3>

<p>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.</p>

<p>In particular, the audience for this note includes:</p>
<ul>
  <li>individuals from W3C Member organizations with an interest in authoring
    for multiple devices</li>
  <li>members of W3C Working Groups who are evolving existing markup
  standards</li>
  <li>companies engaged in developing systems that support authoring for
    multiple devices</li>
  <li>individuals and organizations that design and develop web
  applications</li>
  <li>device experts</li>
</ul>

<h3 align="left"><a name="sec-organisation">1.4 Organization of the
Material</a></h3>

<p>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.</p>

<p>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
<strong>DIAC-n.n</strong>, where <strong>n</strong> represents a number.</p>

<h3><a name="sec-terminology">1.5 Terminology</a></h3>

<p>The Device Independence Working Group has defined a number of terms in its
document <a href="#ref-diwgglos">Glossary of Terms for Device
Independence</a>. This note makes use of a number of terms defined in that
document.</p>

<h2><a name="sec-authoring-roles">2 Authoring Roles</a></h2>

<p>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.</p>

<p>There are three broad categories of web site authors. <a
name="020729-008A"></a> 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.</p>

<p>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.</p>

<h3><a name="sec-designers">2.1 Interface Designers</a></h3>

<p>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. <br>
</p>

<h4><a name="sec-layout-designers">2.1.1 Layout Designers</a></h4>

<p>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. <a
name="020729-008C"></a>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.</p>

<h4><a name="sec-stylistic-designers">2.1.2 Stylistic Designers</a></h4>

<p>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. <br>
</p>

<h4><a name="sec-interaction-designers">2.1.3 Interaction Designers</a></h4>

<p>Interaction designers specify the way that users interact with a site. In
particular, interaction designers specify how interactions occur
<em>within</em> 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.</p>

<p>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 <a
href="#ref-xforms">W3C XForms</a> specification is an example of such an
abstraction.</p>

<h4><a name="sec-navigation-designers">2.1.4 Navigation Designers</a></h4>

<p>Navigation designers specify the paths that visitors may take through a
site. <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-navigation">Navigation</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. <br>
</p>

<h3><a name="sec-content-creators">2.2 Content Creators</a></h3>

<p>The content used on a site includes text, graphics, images, audio and
video <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-resource">resources</a>.
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. <br>
</p>

<p>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. <a
name="020714-006"></a>Increasingly, authors prepare content that includes
more semantic information. For example, textual web content is often
constructed using <a href="#ref-xml">XML</a> 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
increases. <br>
</p>

<h3><a name="sec-business-logic-creators">2.3 Business Logic Creators</a></h3>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-server">server</a>
on which the site is running. Business logic can be shielded from the details
of the device being used by the interaction design.</p>

<h3><a name="sec-interactions-between-roles">2.4 Interactions Between
Roles</a></h3>

<p><img src="./ASRoleInt.png"
alt="Illustration of the interactions between authoring roles"></p>

<p>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.</p>

<p>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 <a
href="#ref-css2">CSS2</a> style sheets.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2><a name="sec-applications-content">3 Applications and Content</a></h2>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-delivery-context">delivery
contexts</a> are considered. The implications for any authoring technique
that seeks to support device independence is also considered.</p>

<h3><a name="sec-application-general">3.1 General Considerations</a></h3>

<p>The need to support access from a variety of devices and <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-access-mechanism">access
mechanisms</a> 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.</p>

<h4><a name="sec-application-consid">3.1.1 Considerations for Authors</a></h4>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user-experience">user
experience</a> provided on devices that lack specific capabilities will not
necessarily be customized but must be <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-functional-user-experience">
functional</a> .</p>

<p>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.</p>

<h4><a name="sec-application-impl">3.1.2 Implications for Authoring
Techniques that Support DI</a></h4>

<h5 class="impl"><a name="diac-3.1">DIAC-3.1: Application Scope</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.2">DIAC-3.2: Extensible Capabilities</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.3">DIAC-3.3: Affordability</a></h5>

<p class="impl">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.</p>

<h3><a name="sec-application-interactivity">3.2 Application
Interactivity</a></h3>

<h4><a name="sec-non-interactive-applications">3.2.1 Non-Interactive
Applications</a></h4>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user-experience">user
experience</a> 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. <br>
</p>

<h5>3.2.1.1 Considerations for Authors</h5>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a name="020714-058C"></a>content creator may wish to
offer the kind that gives a higher quality user experience.</p>

<p>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.</p>

<h5>3.2.1.2 Implications for Authoring Techniques that Support DI</h5>

<h5 class="impl"><a name="diac-3.4">DIAC-3.4: Simplicity</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.5">DIAC-3.5: Navigation Variability</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.6">DIAC-3.6: Organization
Variability</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.7">DIAC-3.7: Media Variability</a></h5>

<p class="impl">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.</p>

<h4><a name="sec-interactive-applications">3.2.2 Interactive
Applications</a></h4>

<p>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
<em>Form</em>. 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.</p>

<h5>3.2.2.1 Considerations for Authors</h5>

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

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-client">client</a>.
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.</p>

<h5>3.2.2.2 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<h5 class="impl"><a name="diac-3.8">DIAC-3.8: Interaction Abstraction</a></h5>

<p class="impl">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.</p>

<p>Standards such as the <a href="#ref-xforms">W3C XForms</a> specification
offer a good example of how some kinds of interaction can be abstracted.</p>

<h5 class="impl"><a name="diac-3.9">DIAC-3.9: Interaction Abstraction
Scope</a></h5>

<p class="impl">Authoring techniques that support DI should offer this kind
of abstraction capability for data entry, data selection, control functions
and navigation.</p>

<h5 class="impl"><a name="diac-3.10">DIAC-3.10: Interaction Organization
Variability</a></h5>

<p class="impl">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.</p>

<h3><a name="sec-application-dynamics">3.3 Application Dynamics</a></h3>

<h4><a name="sec-static-content">3.3.1 Static Content</a></h4>

<p>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.</p>

<h5>3.3.1.1 Considerations for Authors</h5>

<p>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.</p>

<p>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.</p>

<h5>3.3.1.2 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<h5 class="impl"><a name="diac-3.11">DIAC-3.11: Simple Content</a></h5>

<p class="impl">Authoring techniques that support DI should make it easy to
use this simplest form of content when authoring pages.</p>

<h5 class="impl"><a name="diac-3.12">DIAC-3.12: Text Content Variety</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.13">DIAC-3.13: Media Resource
Variety</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.14">DIAC-3.14: Media Resource
Specification</a></h5>

<p class="impl">Authoring techniques that support DI should support the
ability for alternative resources to be specified for use in creating the
user experience.</p>

<h5 class="impl"><a name="diac-3.15">DIAC-3.15: Media Resource
Selection</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.16">DIAC-3.16: Media Resource
Conversion</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.17">DIAC-3.17: Author Control of Media
Resource Use</a></h5>

<p class="impl">Authoring techniques that support DI should provide authors
with the ability to control which media resources are used on particular
devices and delivery contexts.</p>

<h4><a name="sec-dynamic-raw-data">3.3.2 Dynamically Acquired Raw Application
Data</a></h4>

<p>Authors frequently need to integrate application data with material that
creates the user experience, when creating <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-web-page">web
pages</a>. In this discussion, raw application data is considered to be data
that does not <a name="020714-005A"></a>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.</p>

<p>Raw application data can be dynamically acquired from many kinds of
source, including</p>
<ul>
  <li>Relational Databases</li>
  <li>Remote Transactional Applications</li>
  <li>Remote Messaging Applications</li>
  <li>Web Services</li>
</ul>

<p>Data returned from these types of source might be in a variety of formats.
Web services, for example, return data as <a href="#ref-xml">XML</a>
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 <a
name="020714-005C"></a>information that controls the user experience.</p>

<h5>3.3.2.1 Considerations for Authors</h5>

<p>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.</p>

<h5>3.3.2.2 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<p>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:</p>

<h5 class="impl"><a name="diac-3.18">DIAC-3.18: Application Data
Integration</a></h5>

<p class="impl">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.</p>

<h4><a name="sec-dynamic-presentation">3.3.3 Dynamically Acquired Data
Containing Markup</a></h4>

<p>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.</p>

<p>In contrast with raw application data, this kind of content includes <a
name="020714-005E"></a>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. <a name="020729-009N"></a>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.</p>

<p>Examples of pages often created using this type of approach include</p>
<ul>
  <li>News articles</li>
  <li>Product catalogs</li>
  <li>Search results</li>
  <li>Portal pages that integrate material from many sites</li>
</ul>

<h5>3.3.3.1 Considerations for Authors</h5>

<p>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.</p>

<h5>3.3.3.2 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-functional-user-experience">
functional user experience</a>. 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.</p>

<p>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.</p>

<h5 class="impl"><a name="diac-3.19">DIAC-3.19: Integrating Device
Independent Content</a></h5>

<p class="impl">Authoring techniques that support DI should provide
facilities that assist authors in managing the integration of material that
itself includes device-independent content.</p>

<h5 class="impl"><a name="diac-3.20">DIAC-3.20: Integrating Device Dependent
Content</a></h5>

<p class="impl">Authoring techniques that support DI should provide
facilities that assist authors in managing the integration of material that
itself includes device-dependent content.</p>

<h4><a name="sec-dynamic-markup">3.3.4 Dynamically Acquired Data Containing
Other Markup</a></h4>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-rendering">rendered</a>
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.</p>

<h5>3.3.4.1 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<h5 class="impl"><a name="diac-3.21">DIAC-3.21: Integrating Markup that is
Free from User Experience Definitions</a></h5>

<p class="impl">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.</p>

<h4><a name="sec-dynamic-media-resources">3.3.5 Dynamically Acquired Media
Resources</a></h4>

<p>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.</p>

<h5>3.3.5.1 Considerations for Authors</h5>

<p>Authors need to be able to specify dynamically the media resources to be
used in a page.</p>

<h5>3.3.5.2 Implications for Authoring Techniques that Support DI</h5>

<p>The needs of the author lead to the following desirable characteristics of
authoring techniques that support device independence.</p>

<h5 class="impl"><a name="diac-3.22">DIAC-3.22: Dynamic Media Resource
Specification</a></h5>

<p class="impl">Authoring techniques that support DI should allow authors to
specify dynamically the media resources to be used when creating a user
experience.</p>

<h3><a name="sec-client-function">3.4 Applications with Client-Side
Function</a></h3>

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

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user-agent">user
agent</a> being used on the device. This is normally termed the <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-browser">browser</a>.
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.</p>

<p>Different device and user agent combinations often require different
languages for client-side function. Languages in common use include:</p>
<ul>
  <li>Java applets</li>
  <li>JavaScript</li>
  <li>ECMAScript</li>
  <li>WMLScript</li>
</ul>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-client-function-auth">3.4.1 Considerations for
Authors</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-client-function-impl">3.4.2 Implications for</a> <a
name="020714-061H"></a>Authoring Techniques that Support DI</h4>

<p>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.</p>

<h5 class="impl"><a name="diac-3.23">DIAC-3.23: Use of Client-Side
Function</a></h5>

<p class="impl">Authoring techniques that support DI should allow authors to
make use of advanced client-side capabilities including the ability to
execute code.</p>

<h5 class="impl"><a name="diac-3.24">DIAC-3.24: Abstraction of Client-Side
Function</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.25">DIAC-3.25: Independence from Client-Side
Function</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.26">DIAC-3.26: Explicit Use of Client-Side
Function</a></h5>

<p class="impl">Authoring techniques that support DI that support DI should
allow authors to provide client-side function explicitly if needed to support
a <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-harmonized-user-experience">
harmonized user experience.</a></p>

<h3><a name="sec-appl-rich-media">3.5 Applications Using Rich Media
Content</a></h3>

<p>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.</p>

<h4><a name="sec-appl-rich-media-auth">3.5.1 Considerations for
Authors</a></h4>

<p>All of the considerations discussed in <a
href="#sec-static-content">Static Content</a>, 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.</p>

<p>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.</p>

<h4><a name="sec-appl-rich-media-impl">3.5.2 Implications for Authoring
Techniques that Support DI</a></h4>

<p>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.</p>

<h5 class="impl"><a name="diac-3.27">DIAC-3.27: Rich Media Interaction
Variability</a></h5>

<p class="impl">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.</p>

<h3><a name="sec-appl-sync">3.6 Applications Supporting Synchronized Access
Mechanisms</a></h3>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-modality">modality</a>
be synchronised with one another. This is likely to place additional needs on
authors and on the systems that support them.</p>
The <a href="http://www.w3.org/2002/mmi">W3C Multimodal Interaction
Activity</a> addresses issues such as these. DIWG recognizes that additional
requirements for support of device independence will arise as a result of
this work.

<h3><a name="sec-appl-complexity">3.7 Application Complexity</a></h3>

<p>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.</p>

<h4><a name="sec-appl-complexity-auth">3.7.1 Considerations for
Authors</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-appl-complexity-impl">3.7.2 Implications for</a> <a
name="020714-061J"></a>Authoring Techniques that Support DI</h4>

<p>The needs of the author lead to the following desirable characteristics of
authoring techniques that support multiple device and delivery contexts.</p>

<h5 class="impl"><a name="diac-3.28">DIAC-3.28: Range of Complexity</a></h5>

<p class="impl">Authoring techniques that support DI should support the full
range of applications from the simplest to the most complex</p>

<h5 class="impl"><a name="diac-3.29">DIAC-3.29: Scalability of
Complexity</a></h5>

<p class="impl">Authoring techniques that support DI should scale smoothly in
complexity as the underlying application becomes more sophisticated</p>

<h3><a name="sec-aggr-auth-unit">3.8 Authored Units, Aggregation and
Decomposition</a></h3>

<p>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 <a
href="#sec-aggr-auth-unit-defn">authored units</a>.</p>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-decomposition">decomposition</a>.</p>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-aggr-auth-unit-defn">3.8.1 Authored Units</a></h4>

<p>An <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-authored-unit">authored
unit</a> 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.</p>

<p>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.</p>

<h4><a name="sec-aggr-auth-unit-incl">3.8.2 The XML Inclusions Aggregation
Model</a></h4>

<p>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 <a href="#ref-xslt">XSLT</a> style sheet. Others
are more general.</p>

<p>The <a href="#ref-xinclude">XML Inclusions</a> 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.</p>

<h4><a name="sec-aggr-auth-unit-auth">3.8.3 Considerations for
Authors</a></h4>

<p>Authors need to be able to create authored units that can participate in
aggregation operations if desired.</p>

<p>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.</p>

<h4><a name="sec-aggr-auth-unit-impl">3.8.4 Implications for Authoring
Techniques that Support DI</a></h4>

<h5 class="impl"><a name="diac-3.30">DIAC-3.30: Aggregation</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-3.31">DIAC-3.31: Decomposition</a></h5>

<p class="impl">Authoring techniques that support DI should explicitly
support decomposition of resources. Such decomposition should be capable of
being performed automatically or under author control.</p>

<h3><a name="sec-relationship-navigation">3.9 Relationships and
Navigation</a></h3>

<p><a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-navigation">Navigation</a>
is the means by which users alter their <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-focus-of-attention">focus
of attention</a>. This can result in a different part of an <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-active-perceivable-unit">
active perceivable unit</a> becoming the focus of the user's attention, for
example. It can also result in a different <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-perceivable-unit">perceivable
unit</a> becoming active.</p>

<p>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.</p>

<p>The definition of <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-navigation">navigation</a>
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.</p>

<p>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.</p>

<h4><a name="sec-relationship-navigation-auth">3.9.1 Considerations for
Authors</a></h4>

<p>Authors need to be able to specify relationships between and within
authored units in ways that allow the appropriate navigation to be generated
during <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-adaptation">adaptation</a>.
This allows for very different navigation to be implemented for use in
different delivery contexts.</p>

<h4><a name="sec-relationship-navigation-impl">3.9.2 Implications for
Authoring Techniques that Support DI</a></h4>

<p>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.</p>

<h5 class="impl"><a name="diac-3.32">DIAC-3.32: Abstract
Relationships</a></h5>

<p class="impl">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</p>

<h3><a name="sec-existing-apps">3.10 Existing Applications</a></h3>

<p>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.</p>

<h4><a name="sec-existing-apps-auth">3.10.1 Considerations for
Authors</a></h4>

<p>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.</p>

<h4><a name="sec-existing-apps-impl">3.10.2 Implications for Authoring
Techniques that Support DI</a></h4>

<h5 class="impl"><a name="diac-3.33">DIAC-3.33: Existing Applications</a></h5>

<p class="impl">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.</p>

<h2><a name="sec-device-access"></a>4 Devices and Access Mechanisms</h2>

<p>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.</p>

<p>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.</p>

<h3><a name="sec-device-diversity">4.1 Device Diversity</a></h3>

<p>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 <a
name="020729-012"></a>and by providing additional textual material to aid
accessibility.</p>

<p>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.</p>

<p>As an example of the variability, consider some common categories of
device that can access the web.</p>
<dl>
  <dt>Workstations</dt>
    <dd>In this category are the familiar types of computer most usually
      associated with access to the web. It includes personal computers,
      laptops, and high performance workstations. Devices in this category
      tend to have powerful processors, large displays, sound output, large
      amounts of memory and persistent local storage. They usually provide a
      graphical user interface and have input capabilities that include a
      keyboard and pointing device, such as a mouse or touch pad. They may be
      portable. They are able to use a range of different network
      connections, both wired and wireless and varying considerably in
    speed.</dd>
  <dt>Personal Digital Assistants (PDA)</dt>
    <dd>Physically much smaller than workstations, PDAs still tend to provide
      reasonable sized displays, and sound output. They have less powerful
      processors and less memory than workstations and much less persistent
      local storage. Input capabilities are also more limited, often
      employing a stylus and writing surface on the display, or a miniature
      keyboard. PDAs are similar to workstations in the range of available
      network connections they support. They are portable.</dd>
  <dt>Mobile Phones</dt>
    <dd>The emphasis for mobile phones is on portability, small size and
      light weight being important design goals. There is also a need for
      extended battery life. As a result, mobile phones tend to have lower
      power processors and less memory than PDAs. They also have smaller
      screens and most have only a numeric keypad that doubles as a keyboard
      using special input methods. Network connections are via the phone's
      link to it's network. The connection speeds typically available tend to
      be lower than those usually used with workstation devices.</dd>
  <dt>Voice Systems</dt>
    <dd>Voice systems provide connection to the web from standard telephone
      handsets. Portability depends on the portability of the handset used to
      access them. They have no display, output being spoken to the user.
      Input is either via voice recognition, or by means of the numeric
      keypad on the handset. Network connections to the web are wired and are
      usually high speed.</dd>
  <dt>Printers</dt>
    <dd>Printers provide non-interactive user experiences. They exhibit a
      huge variety of physical sizes, resolutions, printing technology and
      speed. Though printers are often considered as peripherals attached to
      workstations, increasingly they are available with direct network
      connections or as peer devices with wireless connections to PDAs and
      phones. Because they offer much higher resolution than displays, and
      because they are inherently paginated, they may require specific
      representations to be created to make best use of their
    capabilities.</dd>
  <dt>Interactive Television Systems</dt>
    <dd>Television set-top boxes can provide access to the web as well as to
      broadcast content. As broadcasters explore the use of interaction, they
      are increasingly looking to web technologies to deliver their
      interactive content. Though televisions may provide large screens,
      their effective resolution is limited by the longer typical viewing
      distance. In addition, their interaction may be limited to those
      available on a remote control with tabbing rather than pointing
      capabilities.</dd>
  <dt>Screen Readers</dt>
    <dd>Screen readers provide access to and interaction with information
      presented by a computer system, for users who are unable to use
      conventional, visual displays. When used in conjunction with a standard
      browser, they provide access to the web, using modalities such as
      speech or Braille.</dd>
</dl>

<p>Subsequent sections consider in detail those differences between devices
that are most important, in terms of their ability to affect the final user
experience.</p>

<h4><a name="sec-device-diversity-auth">4.1.1 Considerations for
Authors</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-device-diversity-impl">4.1.2 Implications for</a> <a
name="020714-061P"></a> Authoring Techniques that Support DI</h4>

<p>A number of characteristics of authoring techniques are highly desirable
in supporting the wide range of capabilities of devices.</p>

<h5 class="impl"><a name="diac-4.1">DIAC-4.1: Device Capability</a></h5>

<p class="impl">Authoring techniques that support DI should allow authors to
create applications that support a wide variety of device capabilities.</p>

<h5 class="impl"><a name="diac-4.2">DIAC-4.2: Capability Abstraction</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-4.3">DIAC-4.3: Layout</a></h5>

<p class="impl">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.</p>

<h5>Other Considerations</h5>
A number of other considerations of the influence of device diversity on the
affordability of application development are covered in the section <a
href="#sec-affordability-device-diversity">Affordability and Device
Diversity</a>.

<h3><a name="sec-aware-access"></a>4.2 Awareness of the Access Mechanism</h3>

<p>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.</p>

<p>This section is <em>not</em> 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 <a href="#ref-di-dco">Delivery
Context Overview for Device Independence</a>. 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 <a name="020714-030E"></a>access mechanism characteristics are
used in determining how material is adapted to create the user experience on
the target device.</p>

<p>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 <a href="#sec-personalisation">Personalization.</a> This
section confines its discussion to the underlying physical characteristics of
the devices and access mechanisms.</p>

<h4><a name="sec-aware-device-characteristics">4.2.1 Device
Characteristics</a></h4>

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

<h5>4.2.1.1 Screen Size and Resolution</h5>

<p>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.</p>

<p>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.</p>

<p>Screen size and resolution are particularly important for <a
name="020714-061S"></a>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.</p>

<h5>4.2.1.2 Color Capability</h5>

<p>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. <a name="020714-045"></a>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.</p>

<p>The color capability of a display is important for <a
name="020714-061T"></a> 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.</p>

<h5>4.2.1.3 Video capability</h5>

<p>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.</p>

<h5>4.2.1.4 Audio capability</h5>

<p>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.</p>

<p>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.</p>

<h5>4.2.1.5 Input capabilities</h5>

<p>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 <a
href="#sec-physical-io">Physical Input and Output</a></p>

<p>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.</p>

<p>The importance of knowledge of a device's input capabilities to <a
name="020714-061X"></a> authoring techniques that support DI is in providing
the ability for designers to control how interactions are expressed on
devices with very different capabilities.</p>

<h4><a name="sec-aware-network-characteristics">4.2.2 Network
Characteristics</a></h4>

<p>Some characteristics of an access mechanism are closely associated with
the network through which the device is connected. This section describes
these characteristics.</p>

<h5>4.2.2.1 Declared bandwidth</h5>

<p>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 <a name="020714-030G"></a>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.</p>

<p>Bandwidth can be an important consideration for <a name="020714-061Y"></a>
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.</p>

<h5>4.2.2.2 Actual bandwidth</h5>

<p>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.</p>

<h4><a name="sec-aware-other-characteristics">4.2.3 Other
Characteristics</a></h4>

<p>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.</p>

<h5>4.2.2.1 User preferences</h5>

<p>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 <a href="#sec-pers-access">Personalization and
Accessibility.</a></p>

<h5>4.2.2.2 Location</h5>

<p>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.</p>

<h3><a name="sec-changes-access">4.3 Changes in the Access Capability</a></h3>

<p>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 <a
name="020714-030M"></a>access method changes between successive accesses to
the application.</p>

<p>This section describes scenarios in which this might occur.</p>

<h4><a name="sec-shared-bookmarks">4.3.1 Shared Bookmarks</a></h4>

<p>User's may need to access the same <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-uniform-resource-identifier">
Uniform Resource Identifiers (URI)</a> with different devices. The <a
href="#sec-scenarios-user-mult-devices">One User, Multiple Devices
Scenario</a> 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.</p>

<p>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 <a href="#ref-di-princ">Device Independence
Principles</a>.</p>

<h4><a name="sec-access-change-transaction"></a><a
name="020714-030N"></a>4.3.2 Access Method Alteration During a
Transaction</h4>

<p>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 <a
href="#sec-scenarios-txn-continuation">Transaction Continuation Usage
Scenario</a> 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.</p>

<p>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.</p>

<h3><a name="sec-usability">4.4 Usability</a></h3>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-usability-auth">4.4.1 Considerations for Authors</a></h4>

<p>Authors need to consider the implications for the usability of the
applications they create when accessed through devices with differing
capabilities.</p>

<h4><a name="sec-usability-impl">4.4.2 Implications for Authoring Techniques
that support DI</a></h4>

<h5 class="impl"><a name="diac-4.4">DIAC-4.4: User Experience
Usability</a></h5>

<p class="impl">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.</p>

<h2><a name="sec-pers-access">5 Personalization and Accessibility</a></h2>

<p>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.</p>

<p>This section discusses the authoring implications of personalization in
general and at how that may affect accessibility in particular.</p>

<h3><a name="sec-personalisation">5.1 Personalization</a></h3>

<p>The term <em>personalization</em>, 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.</p>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-physical-io">5.1.1 Physical Input and Output</a></h4>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h5>5.1.1.1 Considerations for Authors</h5>

<p>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.</p>

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

<h5>5.1.1.2 Implications for Authoring Techniques that Support DI</h5>

<p>From the considerations for authors, the following requirements arise.</p>

<h5 class="impl"><a name="diac-5.1">DIAC-5.1: User Experience
Personalization</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-5.2">DIAC-5.2: Modality</a></h5>

<p class="impl">Authoring techniques that support DI should take into
consideration the modality of the device during the adaptation process.</p>

<h4><a name="sec-language">5.1.2 Language</a></h4>

<p>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.</p>

<p>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.</p>

<p>In addition, where media resources, such as images, contain text, it will
be necessary to include additional versions to support multiple languages.</p>

<h5>5.1.2.1 Considerations for Authors</h5>

<p>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.</p>

<h5>5.1.2.2 Implications for Authoring Techniques that Support DI</h5>

<p>From the discussions it is clear that</p>

<h5 class="impl"><a name="diac-5.3">DIAC-5.3: Language-Dependent User
Experience</a></h5>

<p class="impl">Authoring techniques that support DI should allow language to
influence the adaptation process under the appropriate conditions</p>

<h5 class="impl"><a name="diac-5.4">DIAC-5.4: Influence of Language on User
Experience</a></h5>

<p class="impl">In particular, authoring techniques that support DI should
allow language to influence the choice of the layout and styles used in
particular delivery contexts</p>

<h5 class="impl"><a name="diac-5.5">DIAC-5.5: Influence of Language on Media
Resources</a></h5>

<p class="impl">Although not strictly a DI issue, <a name="020714-062I"></a>
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.</p>

<h4><a name="sec-cost">5.1.3 Cost of Access</a></h4>

<p>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.</p>

<p>The <a href="#sec-scenarios-data-cost">Data Transmission Cost Scenario</a>
gives an example.</p>

<h5>5.1.3.1 Considerations for Authors</h5>

<p>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.</p>

<h5>5.1.3.2 Implications for Authoring Techniques that Support DI</h5>

<p>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.</p>

<h3><a name="sec-pers-for-access">5.2 Personalization for
Accessibility</a></h3>

<p>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.</p>

<p>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.</p>

<p>Issues relating to authoring of content for greater accessibility are
addressed in the <a href="#ref-wcag">Web Content Accessibility Guidelines</a>
recommendation and that issues relating to accessibility in authoring tools
are addressed in the <a href="#ref-atag">Authoring Tool Accessibility
Guidelines</a> recommendation.</p>

<h3><a name="sec-devices-accessibility">5.3 Specialized Devices for
Accessibility</a></h3>

<p>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.</p>

<h4><a name="sec-devices-accessibility-auth">5.3.1 Considerations for
Authors</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-devices-accessibility-impl">5.3.2 Implications for</a> <a
name="020714-062M"></a>Authoring Techniques that Support DI</h4>

<p>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.</p>

<h2><a name="sec-affordability">6 Affordability</a></h2>

<p>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.</p>

<p>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.</p>

<h3><a name="sec-familiarity">6.1 Familiarity</a></h3>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-familiarity-impl">6.1.1 Implications for</a> <a
name="020714-062P"></a>Authoring Techniques that Support DI</h4>

<p>To maximize familiarity, authoring techniques that support DI should be
based on existing W3C recommendations wherever possible. In particular:</p>

<h5 class="impl"><a name="diac-6.1">DIAC-6.1: Presentation Markup</a></h5>

<p class="impl">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 <a
href="#ref-xhtml">XHTML</a> family of specifications, <a
href="#ref-smil20">SMIL</a> and <a href="#ref-svg11">SVG</a>.</p>

<h5 class="impl"><a name="diac-6.2">DIAC-6.2: Interaction Markup</a></h5>

<p class="impl">Elements, of an authoring technique supporting DI, that
involve explicit definition of interaction models should, if possible, be
based on the <a href="#ref-xforms">W3C XForms</a> specification.</p>

<h5 class="impl"><a name="diac-6.3">DIAC-6.3: Markup not Associated with User
Experience</a></h5>

<p class="impl">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 <a href="#ref-xml">XML</a> specification</p>

<h5 class="impl"><a name="diac-6.4">DIAC-6.4: Transformation of
Markup</a></h5>

<p class="impl">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 <a
href="#ref-xml">XML</a> and <a href="#ref-xslt">XSLT</a> specifications.</p>

<h3><a name="sec-affordability-device-diversity">6.2 Affordability and Device
Diversity</a></h3>

<p>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.</p>

<p>There are, of course, basic standards covering groups of devices. For
small, mobile, devices, for example, W3C recommendations, such as <a
href="#ref-xhtml-basic">XHTML Basic</a> and <a href="#ref-css-mobile">CSS
Mobile Profile</a> might be used. Alternatively, the device might follow the
Open Mobile Alliance's <a href="#ref-wap">WAP Specifications</a>. 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.</p>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-functional-user-experience">6.2.1 Functional User
Experience</a></h4>

<p>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.</p>

<h4><a name="sec-customised-user-experience">6.2.2 Harmonized User
Experience</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-affordability-device-diversity-auth">6.2.3 Considerations
for Authors</a></h4>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a
name="020714-061O"></a> authoring techniques that can provide some level of
support to new devices without needing any changes to existing
applications.</p>

<h4><a name="sec-affordability-device-diversity-impl">6.2.4 Implications for
Authoring Techniques that Support DI</a></h4>

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

<h5 class="impl"><a name="diac-6.5">DIAC-6.5: Minimization of Effort</a></h5>

<p class="impl">Authoring techniques should allow authors to support a wide
variety of devices with diverse capabilities without excessive effort.</p>

<h5 class="impl"><a name="diac-6.6">DIAC-6.6: Abstraction of Device
Knowledge</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-6.7">DIAC-6.7: Functional User
Experiences</a></h5>

<p class="impl">Authoring techniques that support DI should allow functional
user experiences to be created for multiple devices without excessive
effort.</p>

<h5 class="impl"><a name="diac-6.8">DIAC-6.8: Harmonized User
Experiences</a></h5>

<p class="impl">Authoring techniques that support DI should allow authors to
customize user experiences for particular devices or classes of device.</p>

<h5 class="impl"><a name="diac-6.9">DIAC-6.9: Exploitation of Device
Capability</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-6.10">DIAC-6.10: Scalability of Effort</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-6.11">DIAC-6.11: Future Device
Capabilities</a></h5>

<p class="impl">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.</p>

<h3><a name="sec-reuse">6.3 Reuse</a></h3>

<p>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.</p>

<h4><a name="sec-reuse-auth">6.3.1 Considerations for Authors</a></h4>

<p>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.</p>

<p>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.</p>

<h4><a name="sec-reuse-impl">6.3.2 Implications for</a> <a
name="020714-063C"></a>Authoring Techniques that Support DI</h4>

<p>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.</p>

<p>Other aspects of reuse can depend on fundamental properties of the <a
name="020714-063J"></a> 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.</p>

<h5 class="impl"><a name="diac-6.12">DIAC-6.12: Reuse</a></h5>

<p class="impl">Authoring techniques that support DI should allow for
significant reuse of material.</p>

<h5 class="impl"><a name="diac-6.13">DIAC-6.13: Separation</a></h5>

<p class="impl">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.</p>

<h5 class="impl"><a name="diac-6.14">DIAC-6.14: Reuse of Functional User
Experiences</a></h5>

<p class="impl">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.</p>

<h3><a name="sec-testing">6.4 Testing</a></h3>

<p>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.</p>

<p>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.</p>

<h2><a name="sec-scenarios">7 Usage Scenarios</a></h2>

<h3><a name="sec-scenarios-user-mult-devices">7.1 One User, Multiple Devices
Scenario</a></h3>

<p>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 <a
href="http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html#teenager">teenager
example</a> from <a href="#ref-pwd">How People with Disabilities Use the
Web</a> for a detailed description of the use case).</p>

<h3><a name="sec-scenarios-txn-continuation">7.2 Transaction Continuation
Usage Scenario</a></h3>

<p>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.</p>

<h3><a name="sec-scenarios-data-cost">7.3 Data Transmission Cost
Scenario</a></h3>

<p>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.</p>

<h3><a name="sec-scenarios-printing">7.4 Printing Scenario</a></h3>

<p>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 <a
href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-uniform-resource-identifier">
URI</a> 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.</p>

<h2><a name="sec-conclusions"></a>8 Conclusions</h2>

<p>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.</p>

<h3><a name="sec-conclusions-categorising"></a>8.1 Categorizing the
Challenges</h3>

<p>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.</p>

<h4><a name="sec-conclusions-comprehensive-scope">Provide Comprehensive
Scope</a></h4>
<a href="#diac-3.1">DIAC-3.1:Application Scope</a> <br>
<a href="#diac-3.18">DIAC-3.18: Application Data Integration</a> <br>
<a href="#diac-3.19">DIAC-3.19: Integrating Device Independent Content</a>
<br>
<a href="#diac-3.20">DIAC-3.20: Integrating Device Dependent Content</a> <br>
<a href="#diac-3.21">DIAC-3.21: Integrating Markup that is Free from User
Experience Definitions</a> <br>
<a href="#diac-3.28">DIAC-3.28: Range of Complexity</a> <br>
<a href="#diac-4.1">DIAC-4.1: Device Capability</a> <br>
<a href="#diac-4.4">DIAC-4.4: User Experience Usability</a> <br>


<h4><a name="sec-conclusions-smooth-extensibility">Support Smooth
Extensibility</a></h4>
<a href="#diac-3.2">DIAC-3.2: Extensible Capabilities</a> <br>
<a href="#diac-3.29">DIAC-3.29: Scalability of Complexity</a> <br>


<h4><a name="sec-conclusions-simplicity">Support Simplicity</a></h4>
<a href="#diac-3.4">DIAC-3.4: Simplicity</a> <br>
<a href="#diac-3.11">DIAC-3.11: Simple Content</a> <br>


<h4><a name="sec-conclusions-abstraction">Support Abstraction</a></h4>
<a href="#diac-3.8">DIAC-3.8: Interaction Abstraction</a> <br>
<a href="#diac-3.9">DIAC-3.9: Interaction Abstraction Scope</a> <br>
<a href="#diac-3.32">DIAC-3.32: Abstract Relationships</a> <br>
<a href="#diac-4.2">DIAC-4.2: Capability Abstraction</a> <br>


<h4><a name="sec-conclusions-dc-variability">Support Delivery Context
Variability</a></h4>
<a href="#diac-3.5">DIAC-3.5: Navigation Variability</a> <br>
<a href="#diac-3.6">DIAC-3.6: Organization Variability</a> <br>
<a href="#diac-3.7">DIAC-3.7: Media Variability</a> <br>
<a href="#diac-3.10">DIAC-3.10: Interaction Organization Variability</a> <br>


<h4><a name="sec-conclusions-author-spec-variability">Support Author
Specified Variability</a></h4>
<a href="#diac-3.12">DIAC-3.12: Text Content Variety</a> <br>
<a href="#diac-3.13">DIAC-3.13: Media Resource Variety</a> <br>
<a href="#diac-3.14">DIAC-3.14: Media Resource Specification</a> <br>
<a href="#diac-3.15">DIAC-3.15: Media Resource Selection</a> <br>
<a href="#diac-3.16">DIAC-3.16: Media Resource Conversion</a> <br>
<a href="#diac-3.17">DIAC-3.17: Author Control of Media Resource Use</a> <br>
<a href="#diac-3.22">DIAC-3.22: Dynamic Media Resource Specification</a> <br>
<a href="#diac-3.27">DIAC-3.27: Rich Media Interaction Variability</a> <br>
<a href="#diac-3.30">DIAC-3.30: Aggregation</a> <br>
<a href="#diac-3.31">DIAC-3.31: Decomposition</a> <br>
<a href="#diac-4.3">DIAC-4.3: Layout</a> <br>


<h4><a name="sec-conclusions-client-side-processing">Client-Side
Processing</a></h4>
<a href="#diac-3.23">DIAC-3.23: Use of Client-Side Function</a> <br>
<a href="#diac-3.24">DIAC-3.24: Abstraction of Client-Side Function</a> <br>
<a href="#diac-3.25">DIAC-3.25: Independence from Client-Side Function</a>
<br>
<a href="#diac-3.26">DIAC-3.26: Explicit Use of Client-Side Function</a> <br>


<h4><a name="sec-conclusions-extend-existing-markup">Extensions to Existing
W3C Standards</a></h4>
<a href="#diac-6.1">DIAC-6.1: Presentation Markup</a> <br>
<a href="#diac-6.2">DIAC-6.2: Interaction Markup</a> <br>
<a href="#diac-6.3">DIAC-6.3: Markup not Associated with User Experience</a>
<br>
<a href="#diac-6.4">DIAC-6.4: Transformation of Markup</a> <br>


<h4><a name="sec-conclusions-context-aware">Context Aware</a></h4>
<a href="#diac-5.1">DIAC-5.1: User Experience Personalization</a> <br>
<a href="#diac-5.2">DIAC-5.2: Modality</a> <br>
<a href="#diac-5.3">DIAC-5.3: Language-Dependent User Experience</a> <br>
<a href="#diac-5.4">DIAC-5.4: Influence of Language on User Experience</a>
<br>
<a href="#diac-5.5">DIAC-5.5: Influence of Language on Media Resources</a>
<br>


<h4><a name="sec-conclusions-affordability">Affordability</a></h4>
<a href="#diac-3.3">DIAC-3.3: Affordability</a> <br>
<a href="#diac-3.33">DIAC-3.33: Existing Applications</a> <br>
<a href="#diac-6.5">DIAC-6.5: Minimization of Effort</a> <br>
<a href="#diac-6.6">DIAC-6.6: Abstraction of Device Knowledge</a> <br>
<a href="#diac-6.7">DIAC-6.7: Functional User Experiences</a> <br>
<a href="#diac-6.8">DIAC-6.8: Harmonized User Experiences</a> <br>
<a href="#diac-6.9">DIAC-6.9: Exploitation of Device Capability</a> <br>
<a href="#diac-6.10">DIAC-6.10: Scalability of Effort</a> <br>
<a href="#diac-6.11">DIAC-6.11: Future Device Capabilities</a> <br>
<a href="#diac-6.12">DIAC-6.12: Reuse</a> <br>
<a href="#diac-6.13">DIAC-6.13: Separation</a> <br>
<a href="#diac-6.14">DIAC-6.14: Reuse of Functional User Experiences</a> <br>


<h2><a name="sec-references">A References</a></h2>
<dl>
  <dt><a name="ref-diwgglos"></a>Glossary of Terms for Device
  Independence</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/"><cite>Glossary
      of Terms for Device Independence</cite></a>, Rhys Lewis, 2003. W3C
      Working Draft available at:
      http://www.w3.org/TR/2003/WD-di-gloss-20030825/</dd>
  <dt class="label"><a name="ref-xforms"></a>XForms 1.0</dt>
    <dd><a href="http://www.w3.org/TR/xforms/"><cite>XForms 1.0</cite></a>,
      Micah Dubinko, Josef Dietl, Andrew Layman, Leigh L. Klotz, Jr., Roland
      Merrick, T. V. Raman, 2002. W3C Working Draft available at:
      http://www.w3.org/TR/xforms</dd>
  <dt class="label"><a name="ref-xhtml"></a> XHTML<sup>TM</sup> 1.0: The
  Extensible Hypertext Markup Language</dt>
    <dd><a href="http://www.w3.org/TR/xhtml1/"><cite>XHTML<sup>TM</sup> 1.0:
      The Extensible HyperText Markup Language</cite></a>, Steven Pemberton,
      Murray Altheim, Daniel Austin, Frank Boumphrey, John Burger, Andrew W.
      Donoho, Sam Dooley, Klaus Hofrichter, Philipp Hoschka, Masayasu
      Ishikawa, Warner ten Kate, Peter King, Paula Klante, Shin'ichi Matsui,
      Shane McCarron, Ann Navarro, Zach Nies, Dave Raggett, Patrick Schmitz,
      Sebastian Schnitzenbaumer, Peter Stark, Chris Wilson, Ted Wugofski, Dan
      Zigmond, 2000 W3C Recommendation available at:
      http://www.w3.org/TR/xhtml1</dd>
  <dt class="label"><a name="ref-smil20"></a> SMIL<sup>TM</sup> 2.0</dt>
    <dd><a href="http://www.w3.org/TR/smil20/"><cite>Synchronized Multimedia
      Integration Language (SMIL 2.0)</cite></a> Jeff Ayars, Dick Bulterman,
      Aaron Cohen, Ken Day, Erik Hodge, Philipp Hoschka, Eric Hyche, Muriel
      Jourdan, Michelle Kim, Kenichi Kubota, Rob Lanphier, Nabil LayaÃ¯da,
      Thierry Michel, Debbie Newman, Jacco van Ossenbruggen, Lloyd Rutledge,
      Bridie Saccocio, Patrick Schmitz, Warner ten Kate, 2001. W3C
      Recommendation available at: http://www.w3.org/TR/smil20/</dd>
  <dt class="label"><a name="ref-svg11"></a> Scalable Vector Graphics (SVG)
  1.1 Specification</dt>
    <dd><a href="http://www.w3.org/TR/SVG11/"><cite>Scalable Vector Graphics
      (SVG) 1.1 Specification</cite></a> Jon Ferraiolo, &amp;#34276;&#x6ca2;
      &#x6df3; (FUJISAWA Jun), Dean Jackson, 2003. W3C Recommendation
      available at: http://www.w3.org/TR/svg11/</dd>
  <dt class="label"><a name="ref-xml"></a>Extensible Markup Language(XML)
  1.0</dt>
    <dd><a href="http://www.w3.org/TR/REC-xml"><cite>Extensible Markup
      Language(XML) 1.0 (Second Edition)</cite></a>, Tim Bray, Jean Paoli, C.
      M. Sperberg-McQueen, 2000. W3C Recommendation available at:
      http://www.w3.org/TR/REC-xml</dd>
  <dt class="label"><a name="ref-xslt"></a>XSL Transformations (XSLT)</dt>
    <dd><a href="http://www.w3.org/TR/xslt"><cite>XSL Transformations
      (XSLT)</cite></a>, James Clark, 1999. W3C Recommendation available at:
      http://www.w3.org/TR/xslt</dd>
    <dd><a href="http://www.w3.org/TR/xslt20/"><cite>XSL Transformations
      (XSLT) Version 2.0</cite></a>, Michael Kay, 2002. W3C Working Draft
      available at: http://www.w3.org/TR/xslt20</dd>
  <dt class="label"><a name="ref-xhtml-basic"></a>XHTML<sup>TM</sup>
  Basic</dt>
    <dd><a
      href="http://www.w3.org/TR/xhtml-basic/"><cite>XHTML</cite></a><sup>TM</sup>
      Basic, Mark Baker, Masayasu Ishikawa, Shinichi Matsui, Peter Stark, Ted
      Wugofski,Toshihiko Yamakami, 2000. W3C Recommendation available at:
      http://www.w3.org/TR/xhtml-basic</dd>
  <dt class="label"><a name="ref-css-mobile"></a>CSS Mobile Profile 1.0</dt>
    <dd><a href="http://www.w3.org/TR/css-mobile"><cite>CSS Mobile Profile
      1.0</cite></a>, Ted Wugofski, Doug Dominiak, Peter Stark, 2001. W3C
      Recommendation available at: http://www.w3.org/TR/css-mobile</dd>
  <dt class="label"><a name="ref-wap"></a>WAP 2.0 Specifications</dt>
    <dd><a href="http://www.wapforum.org/what/technical.htm"><cite>WAP 2.0
      Specifications</cite></a>, Open Mobile Association specifications
      available at: http://www.wapforum.org/what/technical.htm.</dd>
  <dt class="label"><a name="ref-di-princ"></a>Device Independence
  Principles</dt>
    <dd><a href="http://www.w3.org/TR/di-princ/"><cite>Device Independence
      Principles</cite></a>, Roger Gimson, 2001. W3C Working Draft available
      at: http://www.w3.org/TR/di-princ</dd>
  <dt class="label"><a name="ref-di-dco"></a>Delivery Context Overview for
  Device Independence</dt>
    <dd><a href="http://www.w3.org/2001/di/public/dco/"><cite>Delivery
      Context Overview for Device Independence</cite></a>, Roger Gimson,
      2002. Informal public draft of possible W3C Note available at:
      http://www.w3.org/2001/di/public/dco</dd>
  <dt class="label"><a name="ref-xinclude"></a>XML Inclusions (XInclude)</dt>
    <dd><a href="http://www.w3.org/TR/xinclude/"><cite>XML Inclusions
      (XInclude) Version 1.0</cite></a>, Jonathan Marsh, David Orchard, 2002.
      W3C Candidate Recommendation available at:
    http://www.w3.org/TR/xinclude</dd>
  <dt class="label"><a name="ref-css2"></a>CSS2</dt>
    <dd><a href="http://www.w3.org/TR/REC-CSS2/"><cite>Cascading Style
      Sheets, level 2</cite></a>, Bert Bos, Hãkon Wium Lie, Chris Lilley, Ian
      Jacobs, 1998. W3C Recommendation available at :
      http://www.w3.org/TR/REC-CSS2</dd>
  <dt class="label"><a name="ref-wcag"></a>Web Content Accessibility
  Guidelines 1.0</dt>
    <dd><a href="http://www.w3.org/TR/WAI-WEBCONTENT/"><cite>Web Content
      Accessibility Guidelines 1.0</cite></a>, Wendy Chisolm, Gregg
      Vanderheiden, Ian Jacobs, 1999. W3C Recommendation available at :
      http://www.w3.org/TR/WAI-WEBCONTENT/</dd>
  <dt class="label"><a name="ref-atag"></a>Authoring Tool Accessibility
  Guidelines 1.0</dt>
    <dd><a href="http://www.w3.org/TR/ATAG10/"><cite>Authoring Tool
      Accessibility Guidelines 1.0</cite></a>, Jutta Treviranus, Charles
      McCathieNevile, Ian Jacobs, Jan Richards 2000. W3C Recommendation
      available at : http://www.w3.org/TR/ATAG10/</dd>
  <dt class="label"><a name="ref-pwd"></a>How People with Disabilities Use
  the Web</dt>
    <dd><a href="http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/"><cite>How
      People with Disabilities Use the Web</cite></a>, Judy Brewer, 2001. W3C
      Working Draft available at :
    http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web</dd>
</dl>

<h2><a name="sec-acknowledgements">D Acknowledgments</a></h2>

<p>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.</p>

<p>At the time of publication, the principal and active members of the group
were as follows:</p>
<dl>
    <dd>Stephane Boyera (W3C)</dd>
    <dd>Steve Farowich (Boeing)</dd>
    <dd>Roger Gimson (HP)</dd>
    <dd>Yoshihisa Gonno (Sony Corp)</dd>
    <dd>Guido Grassel (Nokia)</dd>
    <dd>Rotan Hanrahan (MobileAware Ltd)</dd>
    <dd>Kazuhiro Kitagawa (W3C)</dd>
    <dd>Markus Lauff (SAP AG)</dd>
    <dd>Tayeb Lemlouma (INRIA)</dd>
    <dd>Rhys Lewis (Volantis Systems Ltd)</dd>
    <dd>Roland Merrick (IBM)</dd>
    <dd>Franklin Reynolds (Nokia)</dd>
    <dd>Andreas Schade (IBM)</dd>
    <dd>Ryuji Tamagawa (Sky Think System)</dd>
    <dd>Luu Tran (Sun Microsystems)</dd>
    <dd>Michael Wasmund (IBM)</dd>
    <dd>Stan Wiechers (Merkwelt)</dd>
    <dd>Jason White (University of Melbourne)</dd>
    <dd>Candy Wong (NTT DoCoMo)</dd>
    <dd>Amy Yu (SAP AG)</dd>
</dl>

<p>The following were members of the group at earlier stages of its
drafting:</p>
<dl>
    <dd>Yasser AlSafadi (Philips Research)</dd>
    <dd>Abbie Barbir (Nortel Networks)</dd>
    <dd>Einar Breen (Adaptive Media)</dd>
    <dd>Shlomit Ritz Finkelstein (invited expert)</dd>
    <dd>Vidhya Golkar (Argogroup)</dd>
    <dd>Luo Haiping (Comverse)</dd>
    <dd>Eric Hsi (Philips Research)</dd>
    <dd>Lynda Jones (SHARE)</dd>
    <dd>William Loughborough (Smith-Kettlewell Institute)</dd>
    <dd>Stephane Maes (IBM)</dd>
    <dd>Kaori Nakai (NTT DoCoMo)</dd>
    <dd>Hidetaka Ohto (W3C/Panasonic)</dd>
    <dd>Garland Phillips (Motorola)</dd>
    <dd>Lalitha Suryanarayana (SBC Technology Resources)</dd>
    <dd>Yoshifumi Yonemoto (NTT DoCoMo)</dd>
</dl>
<hr width="100%" size="2">
</body>
</html>