You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2825 lines
140 KiB
2825 lines
140 KiB
<!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"><rhys.lewis@volantis.com></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, &#34276;沢
|
|
淳 (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>
|