Design Reuse in Hypermedia Applications
Gustavo Rossi
LIFIA, Fat. Cs. Exactas, UNLP, Argentina
and CONICET
E-mail: gustavo@sol.info, unlp.edu.ar
ABSTRACT
In this paper we discuss the use of design patterns for the
process of building hypermedia applications. The idea of
design patterns has been recently developed, and rapidly
spread outside the object-oriented community to a general
audience of software developers. By using patterns it is not
only possible to document design experience with a very
simple and comprehensible format, but also reuse the same
experience several times for different applications. We
argue that the hypermedia community will take a vital step
towards better designs of hypermedia applications and
systems by developing a pattern language for that domain.
KEYWORDS: Design Patterns, Pattern
Hypermedia Design, Navigation, Interface
1 INTRODUCTION
Hypermedia applications are usually built from scratch,
which is not surprising given the relative youth of the
hypermedia market. However, the key reason of why
hypermedia components are not systematically reused is that
current design approaches are not effective in helping the
designer to reason in terms of composition of existing
hypermedia structures. In the best case, interface widgets are
reused in the context of a particular implementation setting.
In [8] the authors analyze different aspects of software reuse
in the context of hypermedia applications. Reuse of software
components and reuse of information are discussed as two
broad categories in which the notion of reuse may be useful
in hypermedia applications. In this paper we argue in favor
of another kind of reuse: reuse of design experience.
Expert hypermedia designers typically do not solve every
problem from scratch. They most of the time reuse solutions
that they have used previously. It is common, however, that
critical design decisions made while defining for example
the interaction and navigational styles of an application
usually remain hidden in code or are poorly documented.
Many other decisions cannot even be deduced from either
code or documentation. Those are strategies kept in the
skillful designer’s mind as the result of all his/her previous
Perrmssion to make &gitaI/hard copies of all or part of this material for
personal or classroom use is granted without fee provided that the copies
are not made or disbibuted forprofitorcommercial advantage,thecopy-
rightnotice,thetitleofthepublication anditsdateappear,andnouceis
giventhat copyright is by permission of the ACM, Inc. To copy otherwise,
to republish, to post on servers or to wkrribute to lists.
permission and/Or fee
Hypertext 97, Southampton UK
IO 1997 ACM 0-89791 -866-5 ...$3.50
Development
Daniel Schwabe Alejandra Garrido
Departamento de InformAtica. LIFIA, Fat. Cs. Exactas,
PUC-RIO, Brazil. UNLP, Argentina
E-mail: schwabe@inf.puc-rio.br E-mail: garrido@sol.info. unlp.edu.ar
experiences, and used by him at a very abstract level.
It is then reasonable to say that reusability of either design
experience or design structures is the most valuable kind of
reuse. From the expert’s point of view, it helps communicate
the decisions made, or discuss the different alternatives with
the rest of the working team in a simple and accurate way.
Patterns provide a new vocabulary that is shared by team
members, helping them to discuss about design at an
abstract level. For non-experienced designers, it becomes
easier to learn quickly through the comprehensible pattern
format.
Languages, Consider the question of how a hypermedia designer can
guarantee that the user always has a way to understand
where he is, and where he is coming from, during
navigation. A possible solution for this general problem
would be to build a “History” object, that is, an object that is
continuously informed about user navigational movements
and that can be viewed upon demand. Note that the
relationships among this object and other navigational and
interface objects may vary from an application to another, in
the same way that we may have different ways of viewing
the history. Nevertheless, the very fundamental idea remains
unchanged; this is a simple example of a design pattern.
Note that in the simple example above we are not using any
particular design notation (e.g., HDM [5], RMM [11] or
00HDM [18]), though such a notation may be useful for
expressing in a non-ambiguous way the relationships among
objects in the solution. Although there is no consensus in the
hypertext community about design methods, patterns
transcend this dimension because they help to capture the
essential aspects of design problems and their solutions. The
main intent of this paper is to motivate the hypertext
community to discuss the problem and eventually produce a
pattern catalogue (as [4]) in which hypermedia design
experience is recorded as a set of related patterns.
Reasoning about abstract design structures in terms of
design patterns is a key step towards reuse of hypermedia
design experience.
In the following sections we introduce design patterns and
pattern languages. We then propose a classification of
patterns for different hypermedia development stages and
show some examples for each different category. Finally,
requiresspecific some further work towards the definition of a pattern
language for hypermedia applications is discussed.
2 A BRIEF INTRODUCTION TO DESIGN PATTERNS
Design patterns are being increasingly used in software
design [4] but, as far as wc know, they remain unexplored in
the hypermedia field and in particular for describing
hypermedia navigational and interface architectures.
As previously stated, one of the most important kinds of
reuse is design reuse, and design patterns are a good means
for recording design experience. A design pattern
systematically names, explains and evaluates an important
and recurrent design in software systems. Design patterns
make it easier to reuse successful designs and architectures
[4]. They describe problems that occur repeatedly, and
describe the core of the solution to that problem, in such a
way that we can use this solution many times in different
contexts and applications [7]. It is important to emphasize
that patterns are not invented, but discovered in existing
software or working environments.
A design pattern is described by stating the context in which
the pattern may be applied, the problem and interacting
forces that bring it to life, and the collaborating elements
that make up the reusable solution. These elements are
described in an abstract way because patterns are like
templates that can be applied in many different situations.
The important elements of a pattern are the responsibilities
that must be assigned to each component and the thread of
collaborations among them that solve the recurrent problem
in the specific context. The consequences and tradeoffs of
applying the pattern are also important because they allow
evaluating design alternatives.
The main advantages of the use of patterns are summarized
as follows, as discussed in [16]:
Patterns enable widespread reuse of software architectures.
Reusing architectures is more valuable than reusing
algorithms or data structures. In the case of hypermedia
applications this is obvious because it is quite difficult to
reuse concrete components.
Patterns improve communication within and across
sojlware development teams as they provide a shared
concise vocabulqy. Using patterns the level of discourse
among team members bass a higher level of abstraction. For
example instead of saying: “Let us create an index for all
artworks under the same theme and give the user the chance
of navigating through them”, we can say: “Let us create the
navigational context Artwork-by-theme”.
Patterns explicitly capture knowledge that designers use
implicitly. Though expert hypermedia designers usually
make good decision they do not document what problem
they are solving and the rationale for that solution. In
particular, design patterns are helpful for training new
developers as they can learn from others’ experience.
Pattern descriptions provide a framework for recording
tradeoffs and design alternatives. This complements the
previous statement as we have a clear understanding for
adopting a particular solution.
Despite all these and other advantages, some considerations
need to be taken in order to profit better from patterns, such
as: including concrete examples to help understand how to
implement a pattern when it is too abstract; choosing pattern
names carefully and using them consistently; carefully
documenting the contexts where patterns apply or not, and
using a fixed, uniform and self-explained format to
communicate clearly and concisely an integrated set of
patterns.
The Patterns movement began in the area of architectural
design almost 20 years ago with the work of Christopher
Alexander [1]. Recently, the object-oriented community has
begun to discuss the subject and there is already an
impressive corpus of work being developed. This work has
been mainly focused on two different areas: design patterns,
and pattern languages. Design patterns are general enough to
solve recurrent design problems in different domains. For
example, the definition of a one-to-many dependency
between objects so that when one object changes its state, all
its dependents are notified and updated automatically (the
Observer design pattern). Another design pattern appears
when defining families of algorithms, encapsulating each
one and making them interchangeable (the Strategy design
pattern). Patterns are now considered the very basic building
blocks of a software designer’s daily work.
In some domains such as, for example, communications or
real-time systems, design problems may be more specific
and therefore more specialized patterns arise [16]. They are
usually the basis of a pattern language: a partially ordered
set of related patterns that work together in the context of a
certain application domain. Pattern languages are also being
constructed for shaping up complex organizations and their
development processes [3]. Those are called organizational
patterns. The objective of our work is to establish the basis
for a pattern language for hypermedia applications. A first
step in that direction may be found in [13, 14].
There is no fixed format to describe patterns, although the
essential elements must always appear: name, problem,
solution, consequences. Design patterns are usually found in
the format proposed by [4], named the “GOF’ format
(standing for Gang-Of-Four, the authors of that book). It is
very complete and detailed, which makes it almost
straightforward to implement them in software. The GOF
format allows recording both the rationale for using the
pattern in the “Motivation” section and the tradeoffs
involved in its use in the “Consequences” section.
More abstract patterns, i.e., those that encompass more
abstract solutions that can be implemented in many
different ways, as well as organizational patterns, usually
appear in the “Alexandria” t’ormat. It contains name,
context, problem, solution, and related patterns [ 1].
Patterns in a pattern language are usually related with each
other. Relationships express that some patterns usually
appear together, that some patterns are mutually
complementary or exclusive.
In our approach to build a pattern language for hypermedia,
we find quite difficult to construct a single interrelated
pattern language, expressed with a unique format. The
reason is that we are not only talking about a particular
domain, but about a complete paradigm. Moreover, patterns
for hypermedia are related under different design and
implementation concerns; for example, should we consider
the same set of patterns when we are building a hypermedia
substrate and when wc are designing a hypermedia
application?. In the first case we should use the GOF
notation [4] because the designer is dealing with a more
“conventional” software design problem where objects are
commonly used to implement hypermedia abstractions (See
[9] for example). In the latter, meanwhile, we should use the
looser “Alexandrian” format in order to give the designer
greater freedom during design and implementation. This is
important if we want t~~ achieve a wide use of these
patterns , since the designer may not be using an object-
oriented design method (like 00HDM), or his
implementation environment may combine Java objects with
HTML pages, or combine Toolbook scripts with relational
databases, and none of these situations should prevent the
use of patterns.
We have then divided our work in different categories of
patterns that we explain in the next section. The pattern
language will contain clusters of related patterns in each
category. We will discuss this point again in section 5.
~T~ewf
%pplkati(ms
,’
Hypermedia Systems Hypermedia applications
Navigational
Interface
Figure 1: Hypermedia
3 PAlTERN CATEGORIES
We have organized the patterns into two categories
accordingly to the different dimensions of applications
inside the hypermedia space, named hypermedia systems,
and hypermedia application patterns. The second category is
itself sub-divided according to different design concerns, as
outlined in Figure 1. These categories were defined based on
our experience in designing hypermedia applications and in
the use of patterns.
-Hypermedia Sysferns. this category encompasses design
patterns that can be used to construct hypermedia systems,
i.e., those environments used to build hypermedia
applications. They have a specific audience: hypermedia
system developers. Although these patterns were discovered
in object-oriented environments, it is not difficult to apply
the core of the solution to other design strategies. Examples
of design patterns from [4] applied in the development of
hypermedia architectures are the Observer Design Pattern
(used in the separation among the run-time and Storage layer
in the Dexter Reference Model [10]) or the Composite
Design Pattern (used in the implementation of Composites
in the Devise Hypermedia Model [9]). Examples of
hypermedia patterns in this category are Navigation
Observer and Navigation Strategy, described in [ 13]. These
patterns are better described in the GOF format, as
explained in the previous section.
-Hypermedia App/icatior?s. These patterns are meant for
hypermedia application designers, regardless of the system
they are using for the implementation. For this reason, these
patterns have a more abstract solution, although they do not
lack accuracy in describing the elements involved and their
necessary interactions. The format used for these patterns is
an “Alexandrian-like” format: name, intent, problem,
solution, consequences, implementation, known-uses. We
have further sub-classified these patterns into navigational
and interface design patterns.
-Navigational Design. Patterns in this category help
in organizing the navigational structure of the application in
a clear and meaningful way for the intended readers. They
address recurrent problems whose solution determines the
degree of success of hypermedia applications. Examples
include Navigational Contexts [14] and Active Reference.
Design
12eveiopmenf Stages
design
patterns space
-/ntetiace Design. The pattern language for this
stage gives some guidelines for a good organization of the
information, in such way that interface elements interact for
an effective presentation of the data. This pattern language
could be also used outside hypermedia applications, in the
broader context of GUI design. An example is the
Information on Demand pattern [14].
4 SOME PAlTERNS FOR HYPERMEDIA So/ution
This section presents some patterns we have found in each The most convenient way to implement these history
of the different categories presented above: one hypermedia viewers is to use the Navigation Observer pattern.
system pattern, two navigational design patterns, and one Navigation Observer is useful in order to have a perceivable
interface pattern. For the sake of conciseness we will not record of the nodes and links visited while navigating the
discuss the patterns in full detail. Moreover, as we want to hypermedia space. Furthermore, it makes this record
stress the importance of patterns over a particular design independent of them, allowing changes in its presentation
solution, we omit presenting their tradeoffs. style according to user needs and preferences. Consequently,
the same design and interface style can be reused in different
4.1 Navigation Observer: A hypermedia system pattern applications. Navigation Observer decouples nodes from the
navigation history and the history from its interface
Intent (viewers). This allows the variation of the type of viewer or
Decouple the navigation process from the perceivable of the implementation of history without affecting nodes.
record of the process. Navigation Observer simplifies the
construction of navigation history viewers by separating the Structure
hypermedia components {nodes and links) from the objects In Figure 2, we show the structure of the Navigation
that implement both the record of navigation and its Observer pattern using OMT notation [15].
appearance.
Participants
Motivation –Hypermedia Component, such as Node and Link,
As previously stated a common situation found in many implements navigation and operations for displaying itself.
hypermedia applications is the requirement to record, in a
user perceptible manner. the state of the navigation. In –History records the navigation history. Different sub-
addition, as the navigation progresses, this record is classes of History may be defined for filtering different
automatically updated. For example, suppose we have a history aspects.
hypermedia application showing European cities, through
which we navigate using different access structures and –Abstract Viewer implements the abstract interface for
relationships. We may reach the same city through different different kinds of viewers.
navigation paths and we want to know which cities we have
already visited. This can be achieved by having a map of –Concrete Viewer implements the operation displuy-lfistory
Europe always visible in some portion of the screen. according to the type of user or preferences.
Whenever we visit a city, it is highlighted in this map, so we
can instantly know which cities we have already visited Collaborations
during navigation. –Each time a hypermedia component is accessed, it sends
the message record to the history, sending itself and the
We could implement this behavior by requiring that objects current context as the arguments, and the history registers it
representing cities (nodes in the hypermedia application) correspondingly.
communicate with the object representing the map with the
message highlight(self). However this solution would make –When the user wants a perceivable view of navigation, the
the existence of different perceivable records difficult, since message viewHisto~ is sent to an instance of the
it creates a strong dependence between nodes and viewers, corresponding ConcreteViewer, which in turn makes the
and requires modifying the hypermedia components for each current history perceivable.
new type of viewer that is defined.

lHypermediaCom~onent
.. ~ _ _ _ _ _ _
I r t I
- navigate () subject - viewHistory ()
? History 4
- goTo (object)
- record (object)
- backtrack (from)
=
- reset ()
ConcreteViewer
ConcreteHypermediaComponent
- viewHistory ()
E - goTo (object)
Figure 2: Navigation Observer pattern
–Concr-efe viewer-s interact with hypermedia components for
performing goTo operations (i.e., the navigation m a
hypermedia component in the history),
Consequences
–It decouples navigation from its history and the history
from a particular way of displaying it.
–This decoupling allows the separation of the application-
specific style of viewing the history from the navigation
functionality.
–Some overhead can arise when the viewer is only interest
in certain types of nodes. The viewer will have to interpret
the history to filter out the type of nodes of interest, possibly
making use of the context reformation.
hnplementaticm
Several issues related with the implementation of Navigation
Observer are discussed below.
l-Diflerent algorithms fur dejining the history. Though
histories may be regarded as simple stacks recording each
visit to a hypermedia component, sometimes it could be
necessary to provide viewers with some “condensed”
history. This may happen either when the same object is
visited more than once or when complex backtracking in a
multiple windows environment occurs [2]. One possible
approach is to define a different method in History that
returns the record of navigation discarding duplicates and
cycles. Another approach is to add this responsibility to
viewer objects that may analyze the stack as needed, with
the help of contextual information..
2-Viewers and histories as access structures. We can use
the interface of a history as an access structure to nodes we
have visited previously. In this case we need to implement a
protocol connecting the viewer with nodes, possibly using
the history as a mediator object. In many hypermedia
environments this kind of “goto” operation is allowed, even
in cases where viewers are implemented simply as a
clickable list of node labels, as implemented in Netscape
Navigator.
Implementing Navigation Observer in typical hypermedia
environments is usually easy. It is important to stress that
even in those settings not supporting objects it is advisable
to decouple nodes, histories and viewers. When it is not
feasible to separate navigation objects (nodes) from
interface ones, as in Asymetrix’s ToolbookTM, we collapse
the history and its viewer in the same Toolbook object.
Known uses
Different hypermedia products provide a way of visualizing
the navigation history. For example Microsoft’s Windows
Help shows the history of a help session as a list of visited
topics. Similarly, in some World Wide Web viewers like
Nctscape Navigator it is also possible to select a location
flrorn the navigation history. Though in Netscape only a text-
based list is presented, the underlying structure of the
application (running as a client of the WWW server) allows
using Navigation Observer for building new types of
viewers.
4.2 Navigational Contexts: a navigational design pattern
Intent
Provide the user with closed navigational subspaces
containing context-related guidelines and relationships, so
that information can better be presented and comprehended.
The same node is also allowed to look different when
perceived from within different contexts.
Problem
Hypermedia applications usually involve dealing with
collections of nodes (e.g., Paintings, Cities, Persons, etc.).
These collections may be explored in different ways,
according to the task the user is performing. For example,
we may want to explore Paintings of an author, Paintings on
a certain subject, etc., and it is desirable to give the user
different kinds of feed-back in different contexts, while
allowing him to move easily from object to object within the
context. From a design point of view this situation may arise
for example when traversing 1-to-n links, as shown in the
next example.
Suppose that in an application about Painters and Paintings
we reach “Van Gogh”, choose to navigate to his paintings
and then arrive at “Sun Flowers”. Alternatively, we can also
reach “Sun Flowers” while exploring Paintings about nature.
It is clear that we will explore the same object under two
different perspectives; for example while accessing it as a
Van Gogh’s work, we would like to read some comments
about its relationships with other paintings by him, as well
as having easy access to another painting he painted. On the
other hand, as a painting on nature, it would be appropriate
to read (or see) something about that subject and be able to
access other paintings on the same theme (perhaps not Van
Gogh’s). This means that we will need not only to present
the information in a different way in both cases, but also to
provide different links or indexes.
The problem exemplified above uncovers some underlying
potentially conflicting requirements, since we want to access
the same hypermedia component under different contexts.
We need to group nodes under the same context and
navigate through them using contextual links. On the other
hand it is impractical and it may even shield inconsistency to
have different objects to represent the same component
when present in each different context. Furthermore, the
current context of navigation is not a concern of the node _
for example it is not appropriate that a node contains
contextual links because those links depend on context
information.
 Context
node

Decorator

Node
Figure 3: Navigational Context

Solution containing the same nodes, etc. Thus, we can further

Decouple the navigational objects from the context in which catalogue navigational contexts according to the criteria
they are to be explored, and define objects’ (contextual) used to define its elements ([18]).
peculiarities as Decorators [4] that enrich the navigational
interface when the object M visited in that context.
The Abductwn of Helen by Paris
Fra ANGELICO (Followar)
Navigational Contexts provides a way of organizing About 14S0

navigation. Navigational Contexts are composed of a set of Wc-4508x61c7n

)+3 591, PWcllaUi rw
navigational objects, i.e., Nodes (like Paintings) and Context
Links (links that connect objects in a context). Nodes are TM, panel q h.w be.
putof+hdewmuonof.
decorated with additional information about a particuku P16a of fumubm, ~bly
.nlull~ctast
context and additional anchors for context links. The
navigational context may also contain information about the
context itself, for example an explanation about Paintings on
Nature. When nodes are organized into navigational
contexts we have a simple way of navigating through the
different members of the set (by means of context links), and
when the same node is accessed in different contexts it can
exhibit different features (attributes and links) added by the
\ I
context decorator. See Figure 3.

In Figure 4 we show m instantiation of Navigational

Contexts in Microsoft’s Art Gallery. The object perceived
by the user is a combination of a node (“The Abduction of
Helen by Paris”) and a decorator (we call it InContext
object) that adds information and anchors according to the
context in which the node is being visited. Note that when
using this pattern our design vocabulary is enriched with
higher level concepts. In fact, we can say “this object
appears in context a,b,c, etc., and for each context let us
define this kind of InContext objects and context links”.
Consequences
When organizing navigation with this pattern the set of
navigable objects is partitioned into groups of closely
related objects (paintings on the same theme, comments on a
painting, documents related with the same painting, etc.),
that are supposed to provide the user with an intuitive and
more comfortable navigational path. We have found the
need for applying the navigational contexts pattern in many
design problems: for example for organizing targets of l-to-
n links, for providing a navigational structure for all
instances of the same class, for traversing all parts of a
composite structure, for defining different guided tours
Figure 4: Navigational Contexts in Art Gallery
Some design decisions will lead us to several sub-patterns.
For example, we may want to access every node in a context
from within every other node, or may want to restrict
navigation in such a way that we provide an index to the
members of a context and we can only reach such nodes
starting from the index but not from other nodes. When
solving these design problems we can state the solution in an
abstract, application-independent way and write it as a
pattern, thus allowing others to share our expertise.
Implementation
Navigational contexts can be easily implemented in
hypermedia environments, even those not supporting full
object-orientation. However, we may have to take into
account features of the implementation environment; for
example when using Toolbook we can use groups to
organize information that will only be meaningful only in a
context and a script openInContext which manipulates the
corresponding group. In the WWW things are more
difficult; we can choose to statically generate all possibilities
by concatenating the decorator object and the decorated one
for each decorator/decorated pair or build the corresponding
page dynamically.
Known uses
Navigational Contexts has been used in many successful
hypermedia applications. For example in Microsoft’s Art
Gallery, paintings of the London National Gallery are
presented in different COIILeXtS: by place, period and subject;
some anchors are used as decorators and allow accessing the
next and previous painting in each context. In Portinari
Project [12, 18], a collection of most important painting of
Brazilian painter Candido Portinari, different families of
navigational contexts have been defined: for example for
each technique we can reach all paintings painted with that
technique, for each Painting we can explore documents
related with that painting, etc..
In Dorling Kindersley’s The Way Thing Works it is possible
to access machines either from an index or according to a
physical principle.
In [6] Navigational Contexts are called “Collections” and
the authors propose adding them as primitives in the Dexter
Reference Model. In 00HDM we use Navigational Context
as a design concept. This is an interesting use of a design
pattern as a way to provide higher level design primitives to
the hypermedia designer.
4.3 ACTIVEREFERENCE: A NAVIGATIONAL DESIGN
PATTERN FOR MONITORING NAVIGATION
Intent
Provide a perceivable and permanent reference about the
current status of navigation, combining an orientation tool
with an easy way to navigate to a set of related nodes, at the
same or higher status level.
Problem
In many hypermedia applications (particularly those
involving spatial or time structures) we need to provide the
reader with a way to understand where he is and help him
decide where to go next. The usual solution would include
an index (or other access structure) to the elements we
intend the user to navigate. However, this solution will
require the user to backtrack from the current node to the
index to see where he is or to move to another node, while
ensuring that its current position is highlighted in the index;
see for example Art Gallery’s Historical Atlas.
Solution
A good solution is to maintain an active and perceivable
navigational object acting as an index for other navigational
objects (either nodes or subindexes). In this way we will be
able to interact with both the index and the target nodes. In
Figure 5 we show the way in which this pattern has been
used in Le Louvre’”’.
Figure 5: Active References in Le Louvre
As we can see in Figure 5, the reader has a permanent
reference about where he is located while he explores the
museum. In particular he can choose to go to another region
or room in the region. He can learn more about a particular
region (the Interface Pattern Information on Demand is used
to provide this information). It is very interesting in this
example that the same pattern is applied twice in the same
navigational structure.
When we use Active Reference the reader has a perceivable
and permanent record about the current status of navigation
and, in this way, we not only provide an orientation tool but
also make them available while navigating the target nodes.
Consequences
When using Active Reference, the reader has a permanent
feeling about where he is in the hyperspace and at the same
time he can choose where to move next. Another interesting
consequence is that since we are emphasizing location we
may block the view of some content because of overlap of
information on the screen. Notice that in the previous
example the location of the room is highlighted over the
room itself. Since deciding how to simultaneously show
both navigational objects is an interface concern we do not
discuss it further. The Information on Demand pattern can
be used to accommodate information with a scarce interface
space.
hnplementation
The implementation of this pattern will depend highly on the
support and flexibility over the graphical interface provided
by the environment. For instance, it depends on the kind of
hypermedia-aware widgets that allow anchor definition .It
also depends, for example, on available layering
mechanisms in the implementation environment,
Known uses
Active Reference has been used in many popular
hypermedia applications. In Microsoft’s “The ultimate
Frank Lloyd Wright” it has been applied to show his
buildings in different states in the USA. It is possible to see
all the works together with an active map showing where it
is located and a list of other works in the same state.
In Microsoft’s Multimedia Beethoven we can access an
active reference of the 9 1%. symphony allowing us to select
different movements and listen to them; we can also select
another without needing to backtrack to an index.
In Grolier’s Encyclopedia Active Reference is used in a
simpler but equally effective way. The reader has permanent
access to a dictiomuy and to nodes accessed from the
dictionary.
4.4 Information on Demand: an interface design pattern
Intent
Organize the information presented to the reader in a legible
and comprehensible interface, by letting him decide which
items he wants to see further described in the context of the
same node. Prevent cognitive overhead.
Problem
Designers usually find themselves struggling to decide how
to show the attributes and anchors of a node in such a way
that both esthetic and cognitive aspects are taken into
account. Unfortunately, the screen is usually smaller than
what is needed and many times one cannot make use of
other media (such as simultaneously playing an audio track
and showing an image), either for technological or cognitive
reasons.
El
Ac,,v,,.wfiu!,
C+, uxs COntm[l,
”g
the iorormaum
vm~.xed LOthe I:AI
Figure 6a: Interface showing the painting as the main
interface object
When a node has a lot of information to be displayed we
could defhre more than one page for the same node or use
scrolling, but oftentimes this alternative does not yield an
acceptable solution. Another alternative is to partition the
node in such a way that we can use different windows for
presenting the information, defining links among these new
nodes. The problems with this solution are: fwst, in our
attempt to match design with an implementation issue, we
may define an attribute of a node as a separate entity, and in
doing so we will end up distorting the application’s
navigational structure. Consequently, the user will get the
impression of dealing with multiple entities, becoming
disoriented, while in fact he is accessing another part of the
same conceptual entity.
Solution
Select the most important node’s attributes (including
anchors) and make them perceivable in the interface.
Provide a set of active interface objects (such as buttons) to
let the user select other information to be shown. Use the
same screen area to display different attributes. In Figure 6,
taken from Le Louvre, we see an example of the use of this
design pattern. Paintings have many attributes to be shown
but not all of them are shown at the same time. In Figure 6.a
we show which interface objets con~ol the information
displayed to the user. In Figure 6.b we show another “view”
of the same node in which other attributes are displayed.
Consequences
The Interface on Demand pattern raises an interesting
discussion about what is navigation and what is an interface
effect, i.e., when we navigate to another object and when we
are just changing the appearance of the same navigational
object. This issue is interesting as it helps us to find “good’
navigational objects by abstracting the way in which they
are to be shown to the final user. In OOHDM, for example,
i3uucwp#@Jw’duL anaill c.mil@mpm5 pu@ms. 00
9* *W9 de. mndmt*. C@Dmml&m
am~l.,# mf
Figure 6.b: Interface on Demand. A textual attribute is
perceived
we clearly separate navigational design from the design of
the interface. In this way we can reason about navigation
without considering further interface problems. In the
example above we can model Paintings as objects
containing information and anchors that do not need to be
perceived at the same time (like a zoomed painting view or
the textual information). Another interesting issue that arises
when using Information on Demand has to do with
providing cues about what we will get when demanding
some additional information..
implementation
When implementing information by demand we have to take
into account some features of the supporting environment.
While in Toolbook it is possible to easily implement the
kind of interface effect that is usual in this pattern, when
building web sites the solution is less obvious. In the web,
we can implement a local scrolling effect, or choose to use
frames and use a new window for each item of information
presented. This last solution has some navigational problems
because in fact we are activating another (sub) node.
Known uses
Information on demand has been widely used in different
hypermedia applications. In Microsoft’s Art Gallery it is
used to provide further reading about a Painting. When you
click the “See Also” button you get a set of related issues
that are in fact attributes of the current painting representing
anchors to the desired information.
In the Passage to Vietnam CD ROM, Interface on Demand
is applied to let the user read further information about a
photograph. In this application the pattern is used not
because screen space is scarce but because the authors do
not want to “pollute” the (beautiful) photograph with textual
information.
5 FURTHER WORK
We have presented the concept of design patterns and have
shown how to apply the principles behind patterns to
hypermedia design. We have also shown some simple but
powerful design patterns: Navigation Observer,
Navigational Contexts, Active Reference and Interface on
Demand solving recurrent problems both for designers of
hypermedia systems and hypermedia applications both at the
navigational and interface level.
This research is part of our work on object-oriented
hypermedia design using 00HDM. Though the very idea of
patterns is somewhat independent of the method being used,
it is clear that the underlying design framework has
influenced our work. In particular, as 00HDM clearly
separates conceptual, navigational and abstract interface
design we have a first criteria to classify patterns according
to the design activity in which they participate. For example
we have identified many patterns at the navigational level,
such as Navigation Strategy [13] and at the interface level
such as Information on Demand and Interface Groups [ 14].
We strongly believe that discovering new patterns in well-
designed hypermedia applications is a rewarding task as it
increases the degree of expertise we, as a community, can
share and transmit to others. The process of finding new
patterns involves analyzing successful applications and
reverse-architecting its underlying design structure [19]. In
this case the focus is not only analyzing the application as in
[7] but also discovering recurrent problems and the way they
have been solved. It is not surprising that good applications
apply a set of principles that can be systematized as patterns.
Many of them are usually hidden in the particular
instantiation of the problem so we must abstract from
particular application details in order to come up with a
general expression of the problem and its solution.
Analyzing how we can implement the pattern in different
hypermedia environments is quite important if we want our
work to result profitable to others.
We are currently working in the definition of a Pattern
Language, i.e. a set of design patterns that can be used
together to end-up with well-designed, usable hypermedia
applications. This language will consider two outstanding
design concerns: the development of software support for
achieving hypermedia behavior—we call this level
hypermedia system level—and the one faced by designers
when using hypermedia primitives to build high level,
usable applications—the hypermedia applications level.
Moreover, the pattern language may contain more specific
“sub-languages” that deal with either particular design
aspects such as navigation or interface or with more
specialized applications like “information kiosks”. Though
the field is rather new we believe several pattern languages
will surely arise from our effort.
There is a growing agreement that a new generation of
computer applications using hypermedia is now emerging.
In applications combining navigation with more
“conventional” behavior we will find many recurrent design
problems that we, as a community, have already solved. The
pattern language expresses this collective expertise.
ACKNOWLEDGMENTS
We wish to thank the anonymous reviewers for their
valuable comments on the paper, which greatly helped to
improve it .
Daniel Schwabe is partially supported by CNPq - Conselho
National de Desenvolvimento Cientifico e Tecno16gico,
Brazil.
REFERENCES
1, Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I.
Fiksdahl-King e S. Angel: “A Pattern Language”. Oxford
University Press, New York 1977.
2. Bieber and J. Wang: “Backtracking in a multiple 12. Lanzelotte,R.S.G.; M.P Marques, M.C,G. Penna, J.C.
window environment”. Proceedings of ECHT’94, Portinari, I.D. Ruiz e D. Schwabe: “The Portinari
Edinburgh, September 1994, pp. 158-166. Project: Science and Art team up together to help
cultural projects”. Proceedings of the 2nd International
3. Coplien. “A Generative Development-Process Pattern Conference on Hypermedia and Interactivity in
Language”, Pattern Languages of Programs 1, Johnson Museums (ICHIM’93), Cambridge, UK, September 1993
and Cunningham eds., Addison Wesley, 1995.
13. Rossi, A. Garrido and S. Carvalho: “Design Patterns for
4. Gamma, R. Helm, R. Johnson and J. Vlissides: “Design Object-Oriented Hypermedia Applications”. Pattern
Patterns: Elements of reusable object-oriented software”, Languages of Programs 2, Vlissides, Coplien and Kerth
Addison Wesley, 1995. edr., Addison Wesley, 1996.

5. Garzotto, D. Schwabe and P. Paolini: “HDM - A Model 14. Rossi, D. Schwabe and A. Garrido: “Towards a Pattern
Based Approach to Hypermedia Application Design”. Language for Hypermedia Applications”. Proceedings of
ACM Transactions on information Systems, 11 (1), Jan. the 3rd. Annual Conference on Pattern Languages of
1993, pp. 1-26. Programs, Monticello, Illinois, September 1996.

6. Garzotto, L. Mainetti and P. Paolini: “Adding 15. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and
Multimedia Collections to the Dexter Model”. In Proc. W .Lorensen: “Object Oriented Modeling and Design”,
ECHT’94-ACM Conference on Hypermedia Prentice Hall Inc. 1991.
Technology. Edinburgh, UK, Sept. 1994.
16. Schmidt:” Using Design Patterns to develop reusable
7. Garzotto, L. Mainetti and P. Paolini: “Hypermedia object-oriented communication software” Con-m of the
Design, Analysis and Evaluation Issues”, Comm. ACM, ACM, October 1995, 38(10), pp. 65-74.
August 1995, pp. 74-86.
17. Schwabe and G. Rossi: The Object-Oriented
8. Garzotto, L. Mainetti and Paolo Paolini: “Information Hypermedia Design Model. Communications of the
reuse in hypermedia applications”. Proceedings of ACM, August 1995, pp. 45-46.
Hypertext’96, Washington, 1996, pp. 93-104.
18. Schwabe, G. Rossi and S. Barbosa: “Systematic
9. Gronbaek: “Composites in a Dexter-Based Hypermedia Hypermedia Design with 00HDM”. Proceedings of the
framework”. Proceedings of the ACM European ACM International Conference on Hypertext
Conference on Hypertext, (ECHT94), Edinburgh 1994, (Hypertext’96), Washington, March 1996.
pp. 59-69.
19. Vlissides, J. Reverse architecture. Position paper for the
10. Halasz e M. Schwartz: “The Dexter Hypertext Reference Software Architecture Seminar, Daghstul, Germany,
Model”. Comm., of the ACM, February 1994, pp. 30-39. 1995 (available at http://st.cs.uiuc. edu/pub/patterns/
papers/revarch.ps ).
11. Izakowitz, E. Stohr e P. Balasubramaniam: “RMM: A
methodology for structured hypermedia design”. Comm.
of the ACM, October 1995, pp. 34-44.