Interactive Dialogue Model: a Design Technique
for Multi-Channel Applications
Davide Bolchini (1)
Paolo Paolini (1)(2)
(1) Tec Lab, Faculty of Communication Sciences, University of Lugano, Via G. Buffi, 13 - 6900
Lugano TI, Switzerland
Tel. +41 58 666 47 13
Fax. +41 58 666 46 47
Email: [email protected]
(2) Hypermedia Open Centre, Department of Electronics and Informatics, Politecnico di Milano,
Via Ponzio, 64/A 20120 Milano, Italy.
Tel. +39 02 2399 3520
Fax. +39 02 2399 3411
Email: [email protected]
1
Abstract
Multichannel applications deliver the same content and a “similar interactive experience” using different
devices and different technologies (e.g. web sites, palm held devices, car navigators, or interactive TVs).
Various channels imply a number of differences, including screen (size), keyboard (size), pointing
devices, output devices, performances, and the context of use (standing, sitting, walking, etc.). In most
cases, today, applications for different channels are designed and implemented almost “independently”,
with ineffectiveness for the developers (high costs) and ineffectiveness for the users (loss of consistency
across the different channels and the perception that they are “different applications”).
This paper presents IDM (Interactive Dialogue Model), a novel design model specifically tailored for
multi-channel applications. The background research, moving from linguistic theories and practices, has
led us to the development of a “channel-independent” design model (based on dialogue primitives).
Design can start in a “conceptual”, channel-independent fashion, and then proceed into a further “logical”
design oriented toward specific channels of communication. Designing an interactive application in two
steps (channel-independent first, and channel-dependent later) allows a number of advantages without
making more cumbersome the overall design process.
Beside the emphasis on multi-channel, IDM has additional distinctive features: it is lightweight, providing
a few set of primitives (and a simple graphic notation) which are easy to learn and teach. Moreover, it is
suitable for brainstorming and generating ideas at early stage during design (or during the shift from
requirements to design); finally, it is cost-effective (it requires little effort from designers) and modular
(designers can take the part they wish, not being forced to “all or nothing”).
IDM has been validated both in the academic and industry environments, providing excellent results so
far.
2
Keywords: dialogue, dialogue strategy, conceptual design, channel-dependent design, channelindependent design, design process, multichannel design, interactive applications.
3
Introduction
Lightweight design processes and usability are being recognized, more and more, as relevant for all the
design methodologies, and for the design of interactive applications in particular. Different factors are
being implied here:
o
It must be easy to teach the design methodology (and the design model) to anyone (from students
to practitioners). Professionals, especially, do not have time and resources to invest for learning
new methodologies; one of the success factors of “Entity Relationship” (probably the most
successful design model, ever) stems from the fact that it was very easy to transmit its basic
concepts, both in academia and professional environment.
o
It must be possible to use the design model for brainstorming, i.e. for generating and discussing
ideas among developers, with stakeholders, and with potential users). It is of little use to have a
design model capable of representing only fully developed solutions.
o
It must require little time to write down design ideas: developers do not like to spend too many
resources in preliminary activities.
o
It must be possible to move, smoothly, from a general design, to more detailed design, without
need for excessive reworking and without need for completeness; in other words, even an
incomplete design document must be useful and understandable.
Other factors could be added to the above list. That is enough to set the scene for this work. The
complexity and the “richness” of the design model is not what we are aiming for. Simplicity and
“usability” of the design model itself, and of the corresponding design methodology, is our goal.
Even with the above requirements, there is apparently no need for further design models or
methodologies: the literature about design models is (over)abundant, as it is discussed in the “Related
Work” section.
4
Besides technical (minor) differences, however, current design models share a common feature: they are
all based upon an information-navigation paradigm to describe the user interaction. Especially in the field
of web application design, this legacy is due to the conceptual background underlying the origins of the
World Wide Web, which derive from the Hypertext and the Data Base field: a network of links
interconnects pieces of information (nodes). In this scenario, it should not surprise that the nature of the
technology available strongly influenced (if not determined) the concepts used to describe, design and
evaluate the applications. Consider, for instance, concepts such as nodes, units, information pieces,
entities, slots, links or classes. In this perspective, current design models consider interaction design as the
activity in which the application behavior and the interface/navigation components are described.
Motivation
Why should designers be forced to design the user experience in terms of how the application behaves? If
the user is the focus of the design effort, we should shape the user’s interaction experience first and first
most from her perspective, and not from the point of view of the technological architecture needed. To
this end, we argue that it is possible to express the features of the user interaction in terms of a dialogue,
and not in terms of data structures. If this interaction is a sort of dialogue, designers should conceive and
create dialogues and dialogue strategies, and only then derive sound information architectures as a
support for it, and not the other way around. Assuming that designers should be concerned about the
effectiveness of the interaction with the user, a dialogue-based approach to interactive application design
is far more natural than an information/navigation-based approach: it avoids being concerned, from the
beginning, with pages, or information units, or technologies to be used, and allows staying focused on the
user interactive experience.
Starting from this assumption, this paper presents IDM (Interactive Dialogue Model), a dialogue-based
design model to shape interactive applications. The model offers a set of simple primitives to describe the
5
user-application dialogue that has to be supported to meet the requirements. IDM is particularly suitable
for content-intensive or information-intensive interactive applications, whereas the major reward for the
user experience is a rich set of content and messages to explore. IDM is certainly suitable for designing
information-rich applications available in the form of traditional websites, but also for hypermedia
applications in general, such as the ones available on different channels (palm, kiosks, smart phones,
embedded navigators, etc). Given its content-oriented and hypertext-oriented nature, IDM is not
particularly suitable – in its current form – for transactional or operation-intensive applications, or for
small applications with high emotional impact and trivial content structure. IDM can be used for these
kinds of application, but we are convinced that it does not provide an added-value for the design in these
situations with respect to other approaches.
To illustrate vividly the primitives and the use of IDM, we will show real examples from the design of a
running
web
application
which
we
developed:
the
website
“Munch
und
Berlin”
(www.munchundberlin.org) and the corresponding PDA application. The applications were realized for
the State Museum in Berlin within the HELP EU-funded project with the aim of providing to the general
public (including users with visual disabilities) a website promoting the temporary exhibition of Edvard
Munch’s prints. Besides a variety of innovative accessibility design features specifically tailored for blind
users (which are not the central theme of this paper), the site was designed using the dialogue-based
design technique proposed in this work and represents the first success case of IDM multi-channel design.
In fact, thanks to IDM, the application has been designed and realized for two different channels: the web
site and a palm-held application.
As it will be showed, the proposed design model offers an innovative approach to interaction design
which enables to focus upon the essential features of the dialogue (between the user and the interactive
application), and to discuss them at the light of the requirements. Technological details and fully
developed specifications can be introduced later - if deemed necessary - by using existing design
approaches.
6
The rest of the paper is organized as follows: in the related work section, some relevant approaches to
interactive application design (especially in the field of web, hypertext and hypermedia design, and
Human-Computer Interaction) are overviewed. The basics of the dialogic approach to interaction design
are introduced and IDM (Interactive Dialogue Model) is illustrated in detail in its key elements:
Conceptual IDM (C-IDM), Logical IDM (L-IDM) and Page IDM (P-IDM). A discussion of the IDM
design process is provided and concluding remarks are drawn on the basis of the design technique
presented and of initial results of the validation of IDM. Finally, important directions for future research
are outlined.
Related Work
We will briefly review a few of the several models that have been proposed for the task of designing
complex interactive (hypermedia) applications. We have no intention to make an exhaustive bibliography,
but rather to quote some of the several approaches from where we have “borrowed” ideas, concepts and
(less often) terminology.
Over the last decade, a number of structured design models and methodologies have been proposed for
designing the features of an interactive application at a proper level of abstraction. Especially in the field
of web design, various sets of concepts, process guides and notation primitives have been developed,
partly extending existing modeling approaches for hypermedia (and traditional hypertext applications),
and partly introducing novel concepts for dealing with website features.
Although the design methods and models share at a higher level a common goal, which is enabling to
document design decisions before implementing the application, they have several differences, including
their main application domains, the level of coverage of the design process, and the level of support
provided at different stages [1].
7
HDM (Hypermedia Design Model) is an early E/R-based design model proposed by Garzotto et al. [2] to
define the structure and navigation of large-scale and read-only hypermedia systems. The model is
suitable for domains with a high level of organization, modularity and consistency. It focuses on
describing the information objects in terms of entities made of components containing units of
information as well as the navigation structure, independently of their implementation. The model also
defines a set of navigation patterns (such as index, guided tour and all the variants deriving from the
combination of these basic patterns), which are recurrent strategies for organizing the user’s navigation
among information units, entities and collections. An extended and richer version of HDM, called
W2000, has been defined to cope with the complexity of web information systems [7].
RMM (Relationship Management Methodology) [3] is suitable for structured hypermedia applications
and its design process consists of seven steps: entity-relationship design; slice design (grouping entity’s
attributes as node/presentation units called slice); navigational design (access methods: link, menus,
index, guided tour, indexed guided tour); protocol conversion design (converting design components into
physical objects); user interface design (screen layouts); run-time behavior design and construction and
testing.
OOHDM (Object Oriented Hypermedia Design Model) [4] is an OO-based design model, extending
HDM, which allows the specification of hypermedia applications as navigational views over a conceptual
model. Navigation units or nodes are mapped to conceptual classes; navigation links are mapped onto
relationships of the conceptual model, and the design and generation of OOHDM-based read-only web
sites is supported by a CASE tool called OOHDM-Web.
Following a similar object-oriented approach to conceptual design, OO-H method (Object-OrientedHypermedia Method) [12] proposes a sound design process for specifying the features of a web
application independently from their fruition device. The OO-H design starts from defining the domain
information structure captured in a UML-compliant class diagram. From there, different navigational
access diagrams (NADs) are specified for specific user profiles. The designer can either automatically
8
generate an early prototype of the application (thanks to the tools offered by the method) or further refine
the user interface by means of an Abstract Presentation Diagram (APDs) and a rich library of design
patterns.
The Enhanced Object-Relationship Model (EORM) [3] is an OO-based methodology based on three
frameworks: Class framework, which expresses the underlying information structure of the application,
the Composition framework, which expresses the rules through which navigation capabilities can be
defined on the basis of the class framework, and the GUI framework, which defines how the information
and navigation elements are presented to the user.
The Web Site Design Method (WDSM) [8] is a user-centred approach which starts from considering user
classes and their requirements in terms of preferences and views. On this basis, the model proposes to
design an information-intensive website in three main stages: object modelling, navigational design and
implementation design (presentation).
WebML (Web Modelling Language) is a high level, model-driven, and E/R-based (compatible with UML
class diagrams) design approach allowing a conceptual specification and automatic implementation of
data-intensive websites [9]. The approach proposes a structural model (data design), a hypertext model, a
composition model, a navigation model, a presentation model and a personalisation model. The model has
also a CASE tool called WebRatio.
A UML Web Application Extension (WAE) has also been recently proposed by Conallen [10] for coping
with the modelling issues required for developing complex web applications. Instead of distinguishing
between content, hypertext and presentation level, WAE models web pages at the server side and at the
client side by stereotyping UML classes. Stereotyped associations are used to represent hyperlinks and to
model the mapping between client pages and server pages. Data entry forms which can be part of client
pages together with their submit relationship to server pages are modelled by another class and
association stereotype, respectively. These technology-dependent and implementation-driven concepts are
9
used to describe the so-called user experience design, which is then mapped into a proper logical
architecture of the application.
The above examples are a few of the several proposals of design models and methodologies, all
essentially based upon an information-navigation paradigm. Let us examine now the background for the
dialogue-based approach.
The idea of describing human-computer communication as a dialogue is not new. Human-Computer
Interaction (HCI) research has been for long assumed that using an interactive application establishes a
sort of dialogue between the user and the application [11]. Therefore, the activity of specifying the
detailed interaction between a user and an interface has been often called dialogue design. Even the
terminology used for describing interface elements made often reference to the word “dialogue”. See for
example the term “dialogue box”, for describing a well-defined and coherent set of options or widgets the
user has to interact with (e.g. the dialogue box for setting the printer). This simple example suggests that
the notion of dialogue in designing an interface has always been implicitly held as a proper metaphor for
interpreting the interaction moves. In fact, in HCI literature, the word “dialogue” often replaces the word
“interaction”, as it is commonly used to describe the nature of the communication between the user and a
computer system [18]. Consequently, generic interaction modalities such form filling, menu selection,
icons and direct manipulation are considered under the label “dialogue types and techniques”. Multimedia
and non-graphical dialogues include further kinds of interaction, such as speech input, speech output,
voice mail, etc. [18]. To give a definition, dialogue in HCI is considered the “syntactic level of the
human-computer interaction” [19] in which the mechanism of the application is specified as it works for
the user. Dialogue design is therefore defined as the activity of defining the structure of the conversation
between the user and the system.
Although this assumption is clear and interesting on a theoretical basis, the HCI dialogue design
techniques which derive from these foundations have little (or nothing) to do with proper dialogic
concepts (as used in linguistics, semiotics and conversational theory). Most of the interaction design
10
notations familiar to HCI designers as diagrammatic tools (state transition networks, Petri nets, state
charts, flow charts, ecc.) or textual “dialogue” notations such as grammars, production rules, algebras or
formal specifications [19] have no concrete and convincing connection to the notion of the “dialogue”:
they only describe the application behavior, as if the dialogue metaphor had never been even considered.
So far, there is no evidence as to how a “dialogue” metaphor actually informs design models and
methodologies for interactive applications, besides using the word “dialogue”. It seems as the concept of
dialogue has been used without taking care of embedding dialogic notions and patterns (from linguistics
and semiotics studies) in the techniques used for designing interactive applications.
The WED approach: Web As Dialogue
If dialogues have to be designed, then design models should embody dialogic primitives and concepts. To
achieve this goal, important questions about the nature of the human-computer dialogue should be
investigated.
What sort of dialogue is it? What are the rules of this dialogue? How does it relate to human-human
dialogues? How can existing linguistic (rhetoric) theories and methods help us in shaping more effective
designs? How can dialogue-based methods help us improve the quality of interactive application design?
The WED research project (Web As Dialogue, Swiss National Research Foundation – FNSRS 105211102061/1), being conducted at the University of Lugano with the technological support of Politecnico di
Milano, focuses on these and other issues which have both practical and theoretical implications. The
general background for WED is the combination of long-term experience into design (from Milano)
combined with linguistic theoretical background (from the group of linguistic and communication
researchers in Lugano). Some of the theoretical questions being addressed concern dialogue modeling
(from the linguistic perspective), quality of dialogues and semiotics of dialogue interaction. “Phoric
moves” are also studied (how the different parts of a dialogue refer to each other): “anaphora” (i.e.
11
reference to previous parts of a dialogue) is the most important of them for web applications, given the
relevance of going “back” to previously visited pages [13][14]. For the purpose of this paper we focus
only on the pragmatic goals of WED:
a) Improving the quality and effectiveness of web applications, by “importing” dialogue techniques and
patterns that have been proved to be effective for human-to-human communication.
b) Improving the efficiency of the web design process by borrowing dialogue-based structuring
techniques.
c) Creating methodologies for web design based upon linguistic-terminology, in order to make them more
suitable for designers with non-technical background (i.e. graduated in humanities, communication
science, cultural heritage, tourism communication, art, literature, or philosophy, etc.).
d) Paving the way for a better understanding of the issues related to transferring a “visually supported
dialogue” (as it is the Web) into an “oral dialogue” (as for visually-impaired users or for people who
cannot look at the screen while interacting).
In the following of the paper we will focus on issues from “a” to “c”, deferring the reader to relevant
references [15][16] for “d”.
C-IDM Conceptual design (channel-independent)
If we agree that a “user experience”, i.e. the “history” of the interaction of a user with an interactive
application (e.g. a website), is a kind of dialogue, the application itself is a “dialogue generator”, meaning
that it serves for the actualization of a (large, but limited) number of possible dialogues. This is the reason
why WED has taken the approach of using a dialogue modeling style as basis for the design of interactive
applications. IDM (Interactive Dialogue Model), the modeling conceptual tool derived from WED, is the
result of the synthesis between design methods (as those described in the previous section) and
understanding dialogues [14].
12
A dialogue-based design offers a number of advantages:
•
It is conceptually simple even for people not used to design (e.g. content experts).
•
It is very close to the way requirements are specified [17], therefore allows for a better
traceability, i.e. keeping track of how the requirements were taken into account.
•
It captures the “essence” of the dialogues that the user can establish, avoiding all the details
connected to the technology of a specific channel.
•
As a special case of the last point, it is suitable for paving the ground for specific versions of the
dialogue aiming at users with special needs [15].
We have no space to discuss dialogue theories and models “per sè”, so we will provide the reader with
pieces of needed knowledge as they become necessary. The reader is referred to [13][14] for further
bibliography and information.
We are focusing on a subclass of possible dialogues, of which we will here highlight some of the
distinctive features. For the purpose of application design, we consider dialogues where the partners play
“unbalanced” or “asymmetric” roles; actually, in computer-human interaction, the application maintains
the “dominance” of the dialogue (i.e. deciding what to talk about), whereas the user can only select
among the limited set of possibilities foreseen by the designer.
An “asymmetric” dialogue can serve three different types of purposes: to convey information from a
subject to another (“informative dialogue”); to “convince” a subject about something that is the goal of
another subject ( “argumentative dialogue”); to allow a subject to perform some operations with the help
of another subject ( “operational dialogue”). Human dialogues, of course, are usually mixed. A dialogue
between a customer and a clerk, for example, is at the same time informative (the clerk provides
information about products, sale conditions, return policies, etc.), argumentative (the clerk is trying to
convince the customer to take some “BUY” decisions) and operational (the clerk will support the
13
customer in the paying procedure). The analogies with the requirements of an eCommerce web site are
striking: the web site must provide information to the user, convince the user (of adopting a suitable
buying pattern) and support the user in its buying-paying actions.
The above said, and given the scope of our project experience, this paper will only consider informative
and argumentative applications (dialogues): the operational part of an application will be dealt with in
another forthcoming paper.
The schema for an informative-argumentative dialogue is characterized by three different pieces of
information:
A. What can (should) be said?
B. What are the relevant changes of subjects to be supported?
C. What are the possible different ways to organize the dialogue, or, in other words, what are the
possible sequences of pairs <interaction, reply>?
Precise and detailed answers to the above questions can be provided only when a specific channel of
delivery has been chosen (determining factors like screen size, pointing mechanisms, available media,
performances, etc.), but important decisions can be taken in advance, in what we call “conceptual design”.
A conceptual schema, of an interactive application, must convey all the necessary “dialogue strategies”,
without (and before) digging into details depending on technical issues. The use of a conceptual schema is
multiple:
a) To support brainstorming among designers.
b) To allow traceability and comparison with requirements (e.g. needs and goals of the
stakeholders), and therefore to support discussion with stakeholders (are we taking the most
appropriate design decisions?).
c) To provide a firm suggestion to the technical designers, who must add details to it.
We propose C-IDM (Conceptual IDM) as a model for conceptual schema: it is simple to grasp, and
effective in representing the most relevant features of the application in terms of content of the dialogue
14
and dialogue moves. In fact, three simple design elements characterize C-IDM: “topic”, “relationship”,
and “group of topic”. An interactive application may describe a “topic” (e.g. a “print”, or a “technique”);
or it may allow the user to switch to a “related topic” (e.g. switching from a “print” to the “technique”
used for it); or it may allow the user to start from a “group of topics” (e.g. “the masterpieces”, or “the
prints dealing with sickness”) and then browse within the group.
The “informative” quality of the dialogue comes from the choice of the topics and the “objective ways” of
relating and grouping topics; the “argumentative” quality of the dialogues is based upon the choice of the
specific content associated to each topic, upon the “subjective ways” of relating topics and grouping
them.
The above simple ideas have been translated into the following C-IDM design primitives:
ƒ
Topic: something that can be the subject of conversation between the user and the interactive
application. “DRYPOINT” (a technique for prints), “THE SICK CHILD” (a print by Munch), and
“INTRODUCTION TO MUNCH” are example of topics, i.e. possible subjects of a dialogue between
the user and the application.
ƒ
Kind of Topic: the category of possible subjects of conversation. “technique”, “print” are kinds of
topic. “DRYPOINT is an example of “technique”.
ƒ
Change of Subject (or Relevant Relation): it determines how the dialogue can switch from a kind
of topic to another one. “made with” is a possible change of subject relating any PRINT to one
TECHNIQUE.
ƒ
Group of Topics: it determines a specific group of topics, possible subject of conversation.
MASTERPIECES is a specific group of PRINTS, while ALL_PRINTS is another, larger, group.
ƒ
Multiple Group of Topic: it determines a family of group of topics. It could be nice, for example, to
group the prints according to the themes, sources of inspiration for Munch. All the prints of the same
theme are a group of topics; “prints by theme”, overall, is a family of groups of topics (as many as
themes are). Each multiple group of topics has a corresponding ”higher-level” group of topics (e.g.
15
“all themes”), which allows to select the specific group of topics of interest (e.g. “prints about theme
“sickness”).
The above list of terms and concepts has a number of advantages over most of the current design models
and methods:
1. the number of concepts is short, and therefore easy to teach (and to learn);
2. despite their limited number, the concepts are expressive enough for describing the structure of most
(information intensive) applications;
3. the concepts (and terms) relate to the dialogue experience, rather than to informatics, therefore they
can be more effectively conveyed to people without a computer science or engineering background;
4. the concepts are abstract enough to allow an in depth comparison between requirements and design
decisions (if requirements have been explicitly stated, of course).
Table 1.1.: a “textual version” of a conceptual dialogue schema with C-IDM.
Topics:
•
•
•
EXHIBITION: an introduction to the exhibition
MUNCH: a brief introduction to Edvard Munch
CONTACT US: relevant contacts (physical & electronic)
Kinds Of Topic:
•
PRINT: the description of a print of the exhibition
•
PERIOD OF LIFE: the description of a specific period of life
•
ARTIST: the description of an artist, living in the same temporal frame as Munch
•
ARTISTIC MOVEMENT: the description of a relevant artistic movement that may have influenced Munch
•
TECHNIQUE: description of a technique used by Munch for his prints
Changes of Subject (Relevant Relations):
•
CREATED IN: print-period of life; if a print is the subject, you can switch to the corresponding period of life
•
MADE WITH: print-technique; if a print is the subject, you can switch to the corresponding technique
•
HAS BEEN USED FOR: technique-prints; if a technique is the subject, you can switch to the prints made with it
•
CONTEMPORARY: period of life-artistic movement; if a period of life is the subject, you can switch to the artistic movements active at the same time
•
ACTIVE IN: artistic movement-artist; if an artistic movement is the subject, you can switch to the artists being part of it
Groups of Topics:
•
MASTERPIECES: those prints that the curator consider the most representatives of the exhibition
•
ALL PRINTS: the complete set of the prints in the exhibition
•
TECHNIQUES: the complete set of techniques used by Munch
•
MUNCH’S LIFE: the complete set of periods of life of Munch
Multiple Groups of Topics:
•
Prints of the same theme: those prints associated to one of the themes source of inspiration for Munch
16
Figure 1.2: the “graphic version” of a conceptual dialogue schema with C-IDM. Please refer to the
complete IDM legenda in Figure 8.
Table 1.1 and Figure 1.2 show the complete schema for the Munch’s Exhibition application, above
mentioned (see www.munchundberlin.org). The reader should notice how the schemas convey in a simple
and effective manner the basic dialogue strategies underlying the application. Some of the information
conveyed, for example are the following: the dialogue can be about “prints”, “techniques”, “periods of
life”, etc. In addition, the dialogue can concern the “museum”, “the exhibition”, or “contact details”. If a
“print” is the subject, the dialogue can move from the print to the corresponding “technique” or the
“period of life” (when it was created, and so on). The dialogue about prints can start from a list of all of
them, from the masterpieces or from a thematic tour. Guessing the rest is left to the reader as a simple
exercise.
This schema, however, is not fully sufficient: additional information needs to be provided for a fully
satisfactory design document. Here is an outline of suggested additional information:
17
ƒ
Topic: description of the motivations (i.e. why it has been considered; what’s its purpose?);
description of the content (i.e. what can be said when the topic is “selected” as subject of the
dialogue?).
ƒ
Kind of Topic: description of the motivations (see above); description of the content (see above);
cardinality (i.e. an indication of the expected number of topics instances or exemplars: e.g. how many
prints do we expect to have?).
ƒ
Change of Subject (relevant relation): description of the semantics (i.e. what is the actual meaning of
the relations) and motivations (i.e. why it is considered important); cardinality (i.e. an indication of
the expected numbers: how many prints should we expect to have – on average – for a given
technique?).
ƒ
Group of Topics: description of the motivations (i.e. why it is group of topics useful-interesting and to
whom); cardinality (i.e. expected number of topics to be part of the group).
Design documents, as we have said in the introduction, do not need to be always complete. Designers
often want to negotiate strategic decisions with stakeholders and document those decisions, without being
forced to commit on premature details early in the development. Moreover, not all the choices need an
adequate explanation: they may be obvious in a given context. In many situations design documents can
be left “unfinished”, still fulfilling their role of conveying most of the ideas about the application. Even
with the enrichments above indicated, a conceptual design document can be kept very simple, easy to
write and effective for the reader.
In synthesis, the main advantages of the dialogue map shown in Figure 1.2 may be summarized as
follows:
a)
The schema is quite simple and it does not take too long to be sketched (any common editor tool
may fit).
b)
The schema expresses all the most relevant aspects of a “real life” interactive application.
18
c)
The schema conveys the basic interaction ideas, without commitment to a specific “channel” of
delivery.
d)
The schema can be used to brainstorm, debate alternatives, and discuss preliminary decisions.
As we will see in the next section, the conceptual schema can be translated in one or more logical
schemas, according to the choices made for a specific channel of communication.
L-IDM Logical Design (channel-dependent)
Once conceptual design has been defined, logical design starts taking decisions which are typically
dependent on a specific fruition channel through which the application may be conveyed (being it the
traditional web, an oral channel, an interactive TV or a mobile channel).
Whereas the C-IDM conceptual design schema defines the overall interaction strategy to be supported
during the dialogue with the user, designers can develop one or more logical designs, one for each
specific channel they want to design the application for. The logical design can be seen a detailed version
of the conceptual design, where details are decided on the basis of a variety of channel-dependent factors,
such as the constraints imposed by the type of device available on a given channel (e.g. screen size), the
pointing devices (e.g. keyboard, smart pen, mouse, scroller, audio input, touch pointers, eye-tracking
pointers), the media which can be used (e.g. audio, visual text, images, graphics, or video), the expected
performance, and the typical scenarios of use (e.g. home or office desktop use, walking or standing
contexts, mobile use on car, etc.).
All these “technicalities” may influence key decisions for the user experience, which concern at the
logical level the ways detailed pieces of content are split and structured, how and when navigation
possibilities are made available and may be traversed.
19
Starting from C-IDM, logical IDM design (called L-IDM) for a specific channel may be defined by
answering two basic questions. Which are the moves of dialogue? How these moves can be combined
together in the user experience?
A number of technical steps are necessary to address these questions:
a) organize each (kind of) topic into dialogue units, and define the possible dialogue flows across them;
b) organize the moves that allow the shift of subjects (traversing a relation between topics);
c) organize the dialogue units that allow the exploration of a group of topics;
In order to provide all the answers, we have developed the following design primitives for L-IDM:
o
Dialogue Act: a unit or move of the dialogue within a topic. The content of a topic is either
represented by a single dialogue act, or several of them. Decisions are based both on technical
considerations (the relevant features of the channel) and user profiles-needs.
o
Structural Strategy: the possible development of a dialogue for exploring a topic with more than one
dialogue acts. What must be specified are the initial dialogue act and the possibilities for changing the
dialogue from one act to another.
o
Transition Act: in case of changing subject from a (kind of) topic (e.g. “print”) to another (kind of)
topic (e.g. “technique”), no additional dialogue is needed, since the dialogue can immediately switch,
upon request. When the new subject is multiple (e.g. switching from “technique” to the “prints” made
with that technique), an additional part of dialogue is needed, that we call transition act. A transition
act is an essence a list of possible new topics (e.g. a list of prints made with the same technique).
o
Transition Strategy: the existence of the transition act, as explained above, does not entirely solve
all the problems. A dialogue sub-strategy must be developed to explain the way a user can access all
the new topics (all the “prints” made with the same technique, in the example).
o
Introductory Act: it is a piece of dialogue that allows the application (and the user) to consider the
group of topic as a whole. It consists, in general, of an introduction followed by a list of the topics
20
belonging to the group. Introductory acts are the unique starting points for the dialogue, in the sense
that any dialogue starts with an introductory act.
o
Subject Strategy: as it is the case for transition acts, creating introductory acts does not solve the
problem of “engaging a conversation” about the group of topics. There must be a dialogue strategy
coordinating how the conversation can involve the introductory act and support the access and
exploration of all the topics belonging to the group.
o
Multiple Introductory Act: it is an introductory act corresponding to a “Multiple Group of Topics”.
It is a strange technicality, not difficult to explain: if there is a group of “prints” for each “theme”
explored by Munch, we need an introductory act for each theme (listing all the prints related to that
theme), but we also need another introductory act listing all the themes, possibly accompanying the
list with an introduction and/or an explanation. Another way of saying is the following: for a multiple
group of topics we need a family of introductory acts (one for each theme, in the example) and a
further introductory act (the list of themes in the example), holding the family together.
On the basis of the same C-IDM schema (see Figure 1.2), the following two pairs of tables and figures
illustrate L-IDM design for a website (Table 2.1 and Figure 2.2) and for a hand-held device (Table 3.1
and Figure 3.2.).
Table 2.1: “textual version” of a logical dialogue schema, with L_IDM, for the web.
Dialogue Acts for topics:
•
EXHIBITION: EXHIBITION_welcome, EXHIBITION_practical-info, EXHIBITION_the-collection
•
MUNCH: MUNCH_essential-profile, MUNCH_munh-und-berlin, MUNCH_historical-background, MUNCH_bibliography
•
CONTACTS: CONTACTS_contacts
•
CREDITS: CREDITS_credits
•
MUSEUM: MUSEUM_practical-information, MUSEUM_locate-us, MUSEUM_history, MUSEUM_kulturforum.
•
LISTEN-TO-THIS-WEBSITE: LISTEN-TO-THIS-WEBSITE_listen-to-this-site, LISTEN-TO-THIS-WEBSITE_enhanced-accessibility, LISTEN-TOTHIS-WEBSITE_get-a-demo, LISTEN-TO-THIS-WEBSITE_about-this-project, LISTEN-TO-THIS-WEBSITE_try-yourself
Dialogue Acts for kinds of topics:
•
PRINT: PRINT_introduction, PRINT_big-image, PRINT_description
•
PERIOD-OF-LIFE: PERIOD-OF-LIFE_description, PERIOD-OF-LIFE_encounters, PERIOD-OF-LIFE_photo-gallery, PERIOD-OF-LIFE_historicalbackground
•
ARTIST: ARTIST_representative-works
•
ARTISTIC-MOVEMENT: ARTISTIC-MOVEMENT_distinctive-features
•
TECHNIQUE: TECHNIQUE_explanation
21
Transition Acts:
•
From Print- made with (1:1): Technique <direct>
•
From Technique – used for (1:n): List of Prints made with a given technique
•
From Period of life – influenced by (0:1): Artistic Movement <direct>
•
From Artistic Movement – represented by (1:n): list of Artists active in an Artistic Movement.
•
From Artist – Belonging to (1:1): ydiorect>
Introductory Acts:
•
MASTERPIECES: <intro_to_masterpiecs, list of prints>
•
ALL PRINTS: List of all Prints
•
TECHNIQUES: List of all the Techniques
•
MUNCH’S LIFE: List of all the periods of life
Multiple Introductory Acts:
•
PRINTS OF THE SAME THEME: list of the prints associated to one of the themes source of inspiration for Munch. <introduction to themes, list of
themes>
INTRO TO THEMES: <intro to themes (audio), list of themes: name>
Figure 2.2 shows a “graphic version” of Table 2.1.
Table 3.1: a logical dialogue schema, with L-IDM, for a hand-held device.
Dialogue Acts for topics:
•
EXHIBITION_intro (<audio 100 sec>)
•
MUNCH_essential-profile (<audio 100 sec>)
•
CONTACT US_contacts (<text 300 char>)
22
Dialogue Acts for kinds of topics:
•
[50-100] PRINT:
Print_intro (<1 image, text 50 char>)
Print_description (<audio 100 sec>)
•
[4-6]
PERIOD OF LIFE:
Period of Life_PhotoGallery (<[2-5] images + audio 30sec>)
Period of life_Description (<audio 60 sec>)
•
[4-10]
ARTISTIC MOVEMENT: artistic movement_distinctive-features (<audio 80sec>)
•
[5-8]
TECHNIQUE: technique_explanation (<audio 80sec>)
Transition Acts:
•
From Print- made with: technique <direct>
•
From Period of life – Influenced by: artistic movement <direct>
•
From Artistic Movement – Represented by: <list of artists: name, years>
Introductory acts:
•
MASTERPIECES:
<intro_to_masterpiecs (audio), list of prints: thumbnail, #, title>
•
TECHNIQUES:
<intro_to_techniques (audio), list of the techniques: name>
•
MUNCH’S: <-,list of the periods of life: name)
Multiple introductory acts:
•
PRINTS OF THE SAME THEME: <list of the prints : thumbnail, #, title>
INTRO TO THEMES: <intro to themes (audio), list of themes: name>
Figure 3.2. Graphic representation of the hand-held L-IDM.
Whereas the C-IDM conceptual map represents the utmost degree of interactivity potential (resembling
the richest channel of the ones available, such as the web for example), the L-IDM design defined a
subset of interactions which are sound and suitable for the channel at issue.
23
Based on our project experience, the common activities that can be done to specialize the conceptual map
into a “channel-dependent” version are the following:
o
Dialogue acts or entire topics may be removed
o
Relevant relations may be removed
o
Groups of topics may be removed or simplified
Based on the results of these decisions, the design should be refined without totally changing the overall
dialogue pattern. In fact, the user should perceive that s/he is dealing with the same application across
different channels. Design decisions made at this stage should cope with the trade-off between a unifying
user experience and the constraints imposed by each specific channel.
In the example illustrated in Figure 3.2., C-IDM map has been tailored by keeping most of the kinds of
topic but providing only key information (mostly communicated ”orally”), supported by few lines of text:
an explanation for the techniques, an introduction dialogue act for the print and a description of the
subject, a photo gallery and a description of relevant periods of life, essential information for artist and
artistic movements. Changes of topics have been reduced to simplify the navigation architecture, whereas
all the strategies for grouping topics have been kept to enable effective selection of the content anywhere
in the application.
Note that one of the design driver from passing from the conceptual design to the logical design is not
only the consideration of the technical constraints of the channel (screen, performance, I/O capability) but
also the context of use. By context of use we mean the typical situation in which a given channel is
foreseen to be used. Whereas the web version of the “Munch un Berlin” application is designed to be used
mainly for planning the visit to the museum, deciding what is worth visiting, gathering details to organize
the visit, or for freely browsing the content to get an idea of what is interesting to see, the hand-held
channel is designed to be use “on site”, that is in the museum while visiting the prints of the exhibition.
That means that the purpose of the hand-held is mainly to support the visit and enrich the visitor’s
experience, by explaining the prints that user is looking at (in the real museum), providing additional
24
information, and guiding him through the different museum rooms. It is clear that these are two different
contexts of usage: the website will probably be used at home by users who, comfortably sit, may or may
not have been in the museum. The hand-held will be used by users who are in the museum, standing or
walking, and are visiting the prints on exhibit. Taking into account the context of use of the different
channel is important to design effective experiences. In fact, the context of use impose constraints on the
design of the channels, such as restricting the navigation capabilities (not all links are relevant in any
context), reshaping the content (providing a different print description to people who are looking at the
prints and to people who never saw them), and provide additional guided tours or thematic paths.
P-IDM: From logical design to pages
IDM page design (P-IDM) means defining the elements to be communicated to the user in a single
dialogue act. With respect to previous decisions (see L-IDM map), designers have now to create the
actual pages containing the necessary elements to sustain the dialogue.
Note that page design should not yet go into wireframe design (defining the visual page grid), neither into
layout design (how elements are physically arranged in the grid), and neither into graphic design (actual
rendering of the visual elements in the page). Whereas all these aspects contribute to define the visual
communication strategy of the application (which graphic designers should define), page design provides
the proper input to these activities by specifying the important elements that should be in each page.
In this view, there are simple guidelines for transiting from L-IDM (channel design) to P-IDM (page
design):
•
Each dialogue act becomes a page type
•
Each introductory act becomes a page type
•
Each transition act becomes a page type
25
•
Relevant topics become landmarks (i.e. links present in (almost) any page). Landmarks
are usually either single topics or important groups of topics always accessible.
•
Relevant groups of topics become landmarks
Different page types can be easily derived from dialogue acts, introductory acts, and transitions acts. We
have a set of specific guidelines for page derivation. For the scope of this paper, let us consider the
following excerpt of the guidelines, namely those concerning the page design for the dialogue acts. A
page for a dialogue act (e.g. Introduction) of a kind of topic (e.g. Print) should basically contain:
Table 4. Description of page elements for a dialogue act.
Page element
Description
Content
The actual content of the dialogue act (being it in texts, graphics, voice,
video, audio, or any combination of these).
to pages of the other dialogue acts of the same topic
to pages of related topic (1:1) or to pages of transition acts (1:n)
Next-Previous (in case of guided tour) or to pages of introductory acts /
introductory act where I came from
where I am
to relevant sections of the site (pages of single topics, or group of topics)
Structural links (if any)
Transition links (if any)
Group of topic links
Orientation info (if any)
Landmarks
These hints serve as a reminder for the designer about the elements to consider when building a page.
Visual communication designers can then make layout and graphic decisions on the basis of this input, so
to create mock-up prototypes or the finally rendered page (see Figure 5).
26
Figure 5. “Introduction” dialogue act of the exemplar of the topic Print: “Moonlight. Night in St.
Cloud”.
The page in Figure 5 shows the page version for sighted users. At www.munchundberlin.org, if you
activate a common screen-reader (e.g. jaws) you can listen to the corresponding version of the site for
visually-impaired users. Given the same P-IDM design, the “oral” page for visually-impaired users
organizes the elements in a different way, namely more usable when processing the page with a screenreader. Strategies for page design for visually-impaired users can be found in [16, 17].
27
Figure 6. Hand-held page of the topic Print: “Moonlight. Night in St. Cloud”.
According to the corresponding L-IDM design, also the hand-held page design has been realized taking
into account the specific features of the PDA channel. Figure 6 shows the same content page of Figure 5
for the hand-held device. Note the elements on the page: for each print, in fact, according to the logical
design, there are presentation information (one image of the print and basic data) and an audio description
running (on demand). The link to technique is offered and the group of topics links to the introductory
acts are displayed. In the PDA page design, all page elements have been kept (properly deriving them
from the PDA logical design) except the landmarks, which would have occupied too much room on the
page, leaving aside the relevant content of the dialogue acts. Landmarks, in fact, are not strictly related to
the current topic of the dialogue, but they are links to general sections of the site (e.g. the Museum,
Munch, Print, Credits, Contacts). These links are present on the PDA homepage, but they have not been
displayed on every page (for space reasons). However, to provide an “exit point” to the user from the
28
current dialogue topic, we just kept the landmark “home” (leading to the homepage), which is the only
way to leave the current dialogue context and start again from choosing other topics.
IDM Design Process
In terms of relationships with other models, IDM (as OOHDM, W2000 and WEBML) has a clear root on
HDM [2]. But with respect to other evolutions, which have tried to move design down toward
implementation (adding features and details), IDM has moved in the opposite direction: moving closer to
requirements and brainstorming. In this sense it can be used also in conjunction with other design models.
As shown in Figure 7, IDM can be used right after the requirements elicitation phase for brainstorming
and getting down the main design ideas. During the iteration between the requirements definition and the
design brainstorming, IDM can support the elaboration of design ideas in a structured and systematic way
(thus providing a clear “direction” to the brainstorming). The use of conceptual IDM helps designers not
to forget important interaction capabilities (thinking to various ways to access the content by devising
groups of topics, clustering content into kinds of topic, defining relations between topics relevant for the
users) and to make new ideas and potential solutions emerge. During this progressive design elaboration,
requirements have the chance to be better understood, refined, proofed and validate, against concrete
dialogic solutions. The interplay between requirements analysis and high-level design (captured through
C-IDM) is an essential element of the development process of interactive applications, which should
balance creativity to meet user’s and stakeholder’s needs with an organized and structured design work.
Once one or more channels of interaction have been selected, L-IDM may be used to specify the concrete
dialogue features of the application, thus keeping coordinated the designs, which are rooted in the
common C-IDM. L-IDM supports the specifications of the channel-specific features and may also give
hint to re-understand requirements which were vague or ill-defined. In fact, as the channel design takes
29
shape, the requirements for the content are much better elaborated, as well as the navigation mechanism
to be supported.
Figure 7. The development context for IDM.
After the development of L-IDM, the project can alternatively move toward “traditional” implementation
(or prototype) development, or follow a more technical design model (WEBML or W2000 for example)
for documenting and specifying in detail the information architecture, the detailed links and the
application behavior. At the Politecnico di Milano, students enrolled in the course “Design of
Multichannel Web Applications” successfully followed this development path. They made the conceptual
and logical design with IDM, and developed detailed specifications with WebML and the corresponding
tool (WebRatio), so to move smoothly towards the implemented application. In fact, L-IDM can be well
mapped onto very structured design models (see for instance those commented in the Related Work
section), providing an input of detailed requirements which have to be further translated in system
30
solutions (see Figure 7). If we consider WebML, for instance, IDM topics provides input for defining the
information objects of WebML, whereas relevant relations are the basis for establishing the navigation
mechanisms among information objects. Groups of topics provides an input for the definition of the
indexes to the content pages of the access structures, whereas the dialogue acts give a high-level hint for
the content of every page unit to be defined.
If, alternatively, the IDM straightforward process is followed (thus without using any of the existing
structured methos), designers can create the page types for each channel on the basis of the logical design.
Page design is soon followed by prototype development, which may help to vividly demonstrate the
dialogue at work.
Conclusions and Validation
As a preliminary observation, we must notice that IDM is the first design model to explicitly
acknowledge the notion of multichannel application as a novel important issue, to be dealt with specific
design techniques.
IDM may appear an over-simplified model, with respect to “competitors”, as those listed in the
references. However, its simplicity has been gained not at expenses of expressiveness, but at the expenses
of “technical details”. IDM, in fact, is intended as a model for “brainstorming design”, where people with
different background (content experts, communication experts, computer scientists, graphic designers,
marketing people, etc.) throw in ideas, evaluate and discuss them. A number of experiences (both in
academia and industry environments) have proved that IDM, by eliminating technical details and
encouraging the expression of more semantic features1, works beautifully for this purpose: it can be used
from the very early stage of design (when decisions are still in the clouds), down to moment when details
1
When a topic is described, for example, in C-IDM, the “attributes” of the content cannot be specified, but rather
designers are encouraged to define the “communication feature” (the key message of the content) and the “purpose”
of the topic.
31
start to surface. Other, more technical models (W2000 and WEBML, for example) do not allow semantic
annotation, but rather require the expression of a number of details, that cannot be known at
brainstorming phase: they can be used to record decisions already made, rather than helping to make
decisions.
A second point is that the simplicity and the dialogue-oriented terminology of IDM does not intimidate
anyone, and allows everybody around the table to discuss design issues. More tech-oriented model, in the
best case, may be used to “communicate” design to non-technical people, but cannot be used by them for
freely discussing ideas.
A third, crucial point, is about “usability” of a design model, which entails at least two key performance
indicators: the amount of time required for teaching the model and the amount of time necessary to sketch
the design of an application. The reduction of the time for teaching the model has been astonishing: in an
engineering environment the time has been cut down to 25% (moving from either W2000 or WEBML),
with no loss at all in understanding the issues. The reduction of time required to sketch the design of an
application (by several groups of students) can be estimated in approximately 50% (with a similar
reduction of the paper being produced). Also, a few experiments of “transfer” to industry have shown that
half day is enough to convey effectively all important ideas in details, compared with 1.5 or 2 days
usually required.
The fourth, and most important issue of all, is about quality of design. We have verified something that
was a hypothesis: simplifying the technique and encouraging brainstorming (besides being less
“expensive” in terms of time) generally produce better design, in the sense of requirements and goals
satisfaction. Designers can focus and discuss about the possible choices and their tradeoffs, and this leads
to better solutions.
Currently, IDM is being used in 7 different courses of Politecnico di Milano (3 undergraduate and 4
graduate ones), and 5 different courses at University of Lugano (2 undergraduate and 3 graduate ones): it
has shown to be tremendously effective, significantly reducing the teaching-learning effort and
32
dramatically improving the quality of design. We will discuss one example, to give an idea of what
happened. TEC-CH (Technology-Enhanced Communication for Cultural Heritage) is an international
Master Programme (in English) awarded by the University of Lugano (first edition: October 2004). We
have enrolled 11 students (from Switzerland, Italy, Romania, Sri Lanka, Ghana, Nigeria, and USA), 8 of
which have never designed an interactive application in their life, and only one of which with experience
in computer programming. 8 hours lecture on IDM where sufficient for conveying the technique; in a 3
weeks intensive class they were able to produce 3 complete projects (for real life problems), technically
correct and, above all, superb in terms of design solutions.
As far as non-academic environments are concerned, we had a number of episodes of transferring the
methodology to industries (in the area of Milan, in Rome and Southern Italy): in all situations IDM was
highly appreciated for its simplicity, coupled with expressiveness and “efficiency”. In these contexts we
also used IDM also for “reverse engineering”, i.e. conceptualizing what existing applications do. Industry
people were pleased of the possibility of easily visualize a complex application and, through the IDM
notation, to discuss how their applications worked. As far as we know those companies have plan for
internal extensive use of IDM, outside of the groups that initially cooperated with us.
Other plans for technology transfer outside the academic environment are discussed in the section about
future work.
Future Work
IDM is currently being used, in our group, for a number of design efforts concerning Cultural Heritage,
Public Administration, eLearning, Tourism, and other application areas. The “channels” being considered
include the Web, palm-held devices and the “oral channel” (for blind users and for on-board mobile
devices). Specific guidelines for each channel are being developed.
In terms of improvements of the model, five main issues are being tackled:
33
ƒ
Input: when the information flows from the user toward the application. We are introducing a
two-way dialogue (with bi-directional dialogue acts) and we will soon be in the position of
providing a simple and effective solution. This development was “forced” by an industry partner
whose application was mainly a “data entry” complex information system.
ƒ
Operations-Transaction: we have already introduced the possibility of specifying the “user point
of view” about operations (i.e. what type of actions, beside navigation, (s)he can perform and
what is their perceived meaning). However, we have a conceptual problem to be solved (common
to all conceptual design model): the “deep semantics” of some operations (e.g.. reserving a seat
for a show) implies interference with other users (e.g. what does the manager of the theater
perceive as effect of the user operation; what do the other users perceive?). In order to model this
phenomenon, it is apparently necessary to model implementation details (e.g. how the reservation
is implemented on an underlying data base), and this will contradict a lot of the IDM foundations.
We are working together with industry partners to shape a viable solution.
ƒ
Transfer to industry: this is among the top priorities of our research effort. We are preparing
paper material, traditional courses and online courses, in order to win the challenge. We cannot
expect industry designers to read academic papers. Even in the case they read them, it is hard for
them to be able to derive practical implications. We, as part of the scientific community, must
move toward practitioners and win this battle: convincing them that a careful design (with any
model, in a sense) may be effective and produces better applications.
ƒ
Specialization of IDM: we are planning to build, with IDM, a number of application frameworks
(from requirements to design) for specialized areas. Our teaching experience to practitioners has
shown that teaching the methodology is much more effective if all examples and discussions are
about a specific domain that they know well. Our teaching experience to students has shown that
learning how to take design decisions is far more effective when there is some degree of shared
understanding of the specific set of requirements of an application area. The first area of
34
specialization we are working is Cultural Heritage (intended as small museums, archaeological
parks afterward and cultural portals), partly with the financial support of two networks of
excellence of the European Union: EPOCH [21] (about the use of Technology for Cultural
Heritage), and DELOS [22] (about Digital Libraries). Recently, thanks to the MAIS project [20],
IDM is also being tested and improved during the design of families of multi-channel applications
in the tourism domain.
ƒ
IDM and Semantic Web: lack of space prevents us to fully describe the range of applicability of
IDM. A variant of it, for example, is being used to model the content and the semantics of
dialogues among human beings. A number of “real life” doctor-patient dialogues (about cancer
treatment) have been recorded and analyzed: the “corpus” of dialogues has been described using
an IDM description of “dialogue acts” and their semantics interrelationships. This effort has
shown that IDM is capable of modeling “dialogue ontologies”, i.e. common semantic structures
supporting a number of dialogues. In this effort, we acknowledge that a dialogue ontology is
different from a domain ontology: for example, we have described how doctors talk to patients
about cancer treatment, not what cancer treatment is in general as a field. In this light, it is part of
our future work to further expand our understanding of the notion of “dialogue ontology” (e.g. a
C-IDM schema of a website could be considered as the ontology underlying all the possible
sessions – dialogues – with that website) and its relationship with the larger field of semantic
web.
Legenda
35
Figure 8. IDM Legenda for conceptual and channel design.
References
[1] Woukeu, A., Carr, L., Wills, G. and Hall, W. (2003) Rethinking Web Design Models: Requirements
for Addressing the Content. Technical Report ECSTR-IAM03 -002, Department of Electronics and
Comnputer Science, University of Southampton.
[2] Garzotto F., Paolini P. (1993) HDM- A Model-Based Approach to Hypertext Application Design. In
ACM Transactions on Information Systems, Vol. 11, No1 January p1-26.
[3] Isakowitz T, Stohr EA., Balasubramanian P. (1995) RMM: A design Methodology for Structured
Hypermedia Design. In Communications of the ACM Vol.38 No8 August pp 34-44.
[4] Rossi G, Schwabe D, Guimaraes R. (2001) Designing Personalized Web Applications. In proceedings
WWW10, Hong-Kong, May.
[5] Lange DB. (1996) An Object-Oriented design Method for Hypermedia Information Systems. In
Journal of Organizational Computing & Electronic Commerce, Vol. 6 (3).
36
[6] Nanard, M., Nanard, J., King, P., IUHM, A Hypermedia-Based Model for Integrating Open Services,
Data and Metadata, in Proc. Hypertext ’03 Conference, 2003.
[7] UWA consortium, Hypermedia and Operation Design: Model, Notation, and Tool Architecture, UWA
Project, IST-2000-25131, Deliverable D7, <www.uwaproject.org>, 2001.
[8] De Troyer, O., Leune, C., WSDM: a User-Centered Design Method for Web Sites, in Proceedings 7th
International Wolrd Wide Web Conference, Brisbane, 1997.
[9] Ceri, S., Fraternali, P., Bongio, A. et al., Designing Data-intensive Web Applications, Morgan
Kaufmann, 2002.
[10] Conallen, J., Building Web Applications with UML (second edition), Addison-Wesley, 2003.
[11] Andersen, P.B., A Theory of Computer Semiotics, Cambridge University Press, 1997.
[12] Gómez, J., Cachero, C., Pastor, O., Conceptual Modeling of Device-Independent Web Applications,
IEEE Multimedia, April-June 2001 (Vol. 8, No. 2).
[13] Bolchini, D., Paolini, P., IDM: Interactive Dialogue Model: towards a dialogue-based approach to
design interactive hypermedia applications, Deliverable D3 – WED (Web As Dialogue), FNSRS 105211102061/, May 2004.
[14] Rocci, A., Paolini P., Towards a model for the analysis and annotation of information dialogues,
Deliverable D1 – WED (Web As Dialogue), FNSRS 105211-102061/, May 2004.
[15] Di Blas, Paolini, Speroni (2004). Web Accessibility for Blind Users Towards Advanced Guidelines.
UI4ALL Conference (User Interfaces for All), Wien.
[16] Di Blas, Paolini, Speroni, Capodieci (2004). Enhancing accessibility for visually impaired users: the
Munch's exhibition. Museums and the Web 2004 Conference, Arlington, USA.
[17] Bolchini, D., Paolini, P. (2004). Goal-driven requirements analysis for hypermedia-intensive Web
applications. Requirements Engineering Journal, Springer, RE03 Special Issue 9 2004: 85-103.
37
[18] Hewett, T., Baecker, R.M. et al., Dialogue Techniques, ACM SIGCHI Curricula for HumanComputer Interaction, ACM Special Interest Group on Computer-Human Interaction Curriculum
Development Group, available at: http://sigchi.org/cdg/cdg2.html.
[19] Dix, A., Finlay, J., Abowd, G., Beale, R., Human-Computer Interaction, Prentice Hall, 2002 (second
edition).
[20] MAIS project (Multichannel Adaptive Information Systems), project funded by the Italian Ministry
of Education and Research (MIUR), http://black.elet.polimi.it/mais/index.php.
[21] EPOCH – European Research Network in Processing Open Cultural Heritage (Contract N. IST2002-507382), funded by the European Union, http://www.epoch-net.org.
[22] DELOS – European Research Network of Excellence on Digital Libraries, (Contract N. IST-2002507618), funded by the European Union, http://delos-noe.iei.pi.cnr.it.
38
Authors
Davide Bolchini
Davide Bolchini is senior researcher at the TEC-Lab of the University of Lugano, lecturer of Usability at
the Master Program in Technology-Enhanced Communication for Cultural Heritage (www.tecch.unisi.ch) and lecturer of Usability of Interactive Applications at Politecnico di Milano. His research
focuses on web requirements analysis, conceptual design and usability evaluation methodologies. He is
member of the Usability Professional Association (UPA), ACM and IEEE. Contact him at the TEC-Lab,
Faculty of Communication Sciences, University of Lugano, via G. BUffi 13 – TI 6900 Lugano,
Switzerland; [email protected].
Paolo Paolini
Paolo Paolini is Full Professor of Computer Graphics and Multimedia at Politecnico di Milano - Italy. He
is also director of HOC-Hypermedia Open Center - at Politecnico di Milano and scientific coordinator of
the TEC lab at the University of Lugano. He has a Master and PhD in Computer Science from the
University of California at Los Angeles (UCLA). He is one of the leading figures, world-wide, in the area
of web design, being the co-author of HDM, the first structured approach to Web design and hypermedia,
from which a number of similar approaches have been originated in the last ten years. Contact him at
39
Politecnico di Milano, Hypermedia Open Centre, Department of Electronics and Informatics, Politecnico
di Milano, Via Ponzio, 64/A 20120 Milano, Italy; [email protected]
40