Information Reuse in Hypermedia Applications
Franca Garzotto1, Luca Mainetti1, Paolo Paolini1,2
1Hypermedia Laboratory - Politecnico di Milano
Via Ponzio 34/5, 20133 Milano, Italy
2Università di Lecce - Informatics Engineering, Lecce, Italy
E-mail: [garzotto, mainetti, paolini]@elet.polimi.it
ABSTRACT
Reuse -- broadly defined as the use of existing information objects or software artifacts in different contexts and for different purposes -- is a technology for improving productivity, reducing the production effort and cost, and increasing the quality of end applications (promoting consistency and therefore improving usability).
Reuse is a crucial issue in hypermedia applications. Reuse may be applied to items of different sizes and different complexity (from an elementary value to a large structured portion of the application). It may involve several aspects of the hypermedia application (content, organisation, presentation and connections). It can be implemented with different techniques, by creating a new copy of an item, or by sharing the same item in two (or more) different contexts.
In this paper we analyse hypermedia reuse under these different viewpoints, discuss a classification of different types of reuse, and present a few examples from commercial and prototype hypermedia titles. From the analysis of these case studies we derive technical hints, recommendations and pitfalls-to-avoid, that would help hypermedia authors handle reuse in the most effective way possible. We also suggest reuse techniques that can be incorporated in future authoring systems.
KEYWORDS: hypermedia, reuse, authoring, design, models, evaluation, usability.
INTRODUCTION
The aim of this paper is to analyse the concept of reuse in hypermedia applications, to classify different types of reuse, and to assess how effective this technique might be. This work evolved out of our experience both in developing several hypermedia applications and in systematically inspecting many hypermedia titles and research applications. In the paper, we will discuss examples from commercial and prototype hypermedia, and from their analysis we will derive technical hints, recommendations and pitfalls-to-avoid that would help hypermedia authors handle reuse in the most effective way possible. Finally, we will suggest reuse methods that can be incorporated in future authoring systems.
Background
The notion of reuse is traditionally considered important for computer applications, and is divided in two broad different categories: reuse of software components and reuse of information. Reuse of software components means to be able to use a piece of code in different contexts or different systems [4]. Reuse of information, instead, means that a data item (simple or complex, traditional or multimedia) is used in two different applications, or in two different parts of the same application[1]. The software component or the data item may remain the same in the different contexts, or the existing artifact or information item may be modified (to meet specific system requirements or to satisfy different information needs). The latter case is sometime referred as leveraged reuse in the software engineering literature [15, 22]. In this paper, however, we will use the term "reuse" to indicate both situations.
For hypermedia applications, reuse takes both aspects: reuse of a piece of information (e.g. a graphic file or an entire node) and reuse of a software component (e.g., the code that controls the behaviour of a multimedia file [3, 9] or executes link-traversing actions). This paper will focus on reuse of information only, discussing the new requirements and types of reuse introduced by the peculiar features of hypermedia. Reuse of software components does not have substantially peculiar aspects in hypermedia with respect to traditional software applications; the interested reader can find in [15] an interesting source of information about reuse of software components.
Motivations
In hypermedia applications, there are two distinct situations for reuse of information. The first situation is the use of multimedia material from existing applications to build new ones [14]. In this situation, the main motivation for reuse is cost. Producing quality multimedia material is expensive and time-consuming; thus, using the same material for several applications is important, since the new applications will require less time for their development and will cost much less than developing their content totally from scratch[2].
The second situation for reuse of information is the case when, within the same application, the same material is presented in different contexts. The most important motivation for this kind of reuse is the improvement of usability, and therefore, the increase of quality of the application. Having the same item (either simple or complex) appearing in different places of the application has several advantages, all of them related to usability [8]:
· it enhances accessibility of the item itself, since several paths, in different contexts, lead to it [19], and the user can choose the most appropriate for his needs or expertise. As an example (from the Microsoft Art Gallery CD-ROM[3]), the same "painting" can be found in the application either within the set of works of its painter, or associated to the historical period in which it was painted, or included in a list of museum paintings organised by alphabetical order.
· it provides different points of views about the item itself, making the application more attractive and cognitively richer for the reader. As an example (still in the museum domain) consider that a "lecture" or "guided tour" about "Composition and Perspective" can present the same painting under a light completely different from its "standard" presentation "by Painter".
Additional motivations for using information objects in different contexts are cost, analogously to the previous case of reuse, and expansion of the "apparent" size of the application, possibly without affecting its physical size (depending on the technique to implement reuse, as explained in the next sections)[4]. The last is particularly relevant for applications with large amount of multimedia material.
The rest of this paper is organised as follows. In section 2, we will analyse the concept of hypermedia reuse of information under different viewpoints and discuss a classification of different types of reuse. Section 3 will present some examples of reuse in commercial or prototype hypermedia applications. In section 4 we will draw our conclusions and sketch the future directions of our work. The appendix will summarize very shortly the terminology of the hypermedia design model HDM [5, 7, 8, 10, 11] that is used in the paper to denote the various information structures of hypermedia applications.
TYPES OF INFORMATION REUSE IN HYPERMEDIA APPLICATIONS
In this section, we propose a classification of different types of reuse according to various "dimensions":
the implementation method (by-reference or by value)
the aspect of the information item affected by reuse: content, organisation, presentation, or connectivity
the type of modification performed to get a "copy" from the "original" item[5], e.g., which aspects remain the same, and which have been modified by adding or deleting something. We call original the item that we started with (i.e., what has to be reused), and the copy the other item that appears in the different context.
To make the discussion more readable, the following table summarises the symbols that will be used along the rest of this section:
Table of Symbols
Symbol
implementation
by Reference R
by-Value V
aspect involved
content c
presentation p
organization o
connectivity l
copy vs. original
equality =
addition +
difference -
alteration
Reuse
Implementation MethodsReuse may be implemented with two techniques, by-reference (R) or by-value (V). By-reference means that an item is referenced from (or it belongs to) two (or more) different contexts. By-value means that (at least) two copies of the same item exist in different contexts.
As we have discussed in the introduction, reuse can be applied within the same application or to generate a new application. From our experience, by-value is the most likely method for reuse if a new application is generated; by-reference is the most likely method of reuse within the same application. This preference is not mandatory, however. When a new application is generated, the two applications, for example, may share an on-line Data Base, where a single copy of each item is kept. On the contrary, within the same application, a new version of the same item can be generated, in order to avoid some technical problems (discussed below and in the next section).
The only special case is when the new application is physically separated from the original (e.g. a new CD-ROM): in this situation the only implementation method that makes sense is by-value (but, of course, by-reference reuse can be applied within the same CD-ROM).
Content
The term content refers to the actual information contained in an information item. We can have four different situations for reuse, with respect to the content of an item:
Reuse Type Symbol Meaning
content c = the content of the
equality copy is exactly the
same as the content
of the original
content c + the content of the
addition copy has something
more than the
original
content c - the content of the
subtraction copy has something
less than the
original
content c the content of the
alteration copy has something
more and something
less than the
original
Any kind of content reuse othet than equality creates implementation problems when the implementation method is by-reference[6]. Also by-value implementation may raise maintenance problems; if the two versions (original and copy) have to be kept aligned, whenever the original changes, the copy also must be (possibly automatically) updated. A careful versioning control system must be used in order to cope with the problem.
Nevertheless, the change of content, from original to copy, is often desirable. Some of the reasons could be the following:
content subtraction (c-):
- the content of the original is too large and must be reduced;
- the content of the original has some references to the context where the original itself was placed; these references must be eliminated, in order to avoid inconsistency with the new context [8];
content addition (c+):
- the original, taken out of its context, may be lacking some important pieces of information (even the title of the item may be missing, as will be exemplified in the next section); additional information must therefore be provided in the copy in order to make it "self-standing". In other words, the context of the original provided, implicitly, some further information that would be missing in the copy unless the content is modified.
- with the original content, it could be unclear why the item relates to the new context; therefore some additional pieces of information must be provided in order to establish the proper relationship.
Organization
The term organization refers to how an item is internally organized. We can have two different situations for reuse, with respect to the internal organization of an item:
Reuse Type Symbol Meaning
organization o = the internal
equality organization of the
copy is exactly the
same as the
organization of the
original
organization o the internal
alteration organization of the
copy is somehow
different with
respect to the
organization of the
original
If the reuse implementation method is by-reference, it is very difficult to achieve organization alteration. Therefore, when organization alteration is required, by-value reuse is the most common technique. For large items (containing several smaller sub-items), it is common that the alteration of the internal organization is implemented by-value, while the sub-items, if no other alteration is required, are reused by-reference (see the example on collection reuse in section 3).
Presentation
The term presentation refers to how an item is presented (i.e., visualized or played) to the reader. We can have four different situations for reuse, with respect to the presentation of an item:
Reuse Type Symbol Meaning
presentation p = the presentation of
equality the copy is exactly
the same as the
presentation of the
original
presentation p + the presentation of
addition the copy introduces
some new element
with respect to the
presentation of the
original
presentation p - the presentation of
subtraction the copy has
something less than
the original
presentation p the presentation of
alteration the copy has
something more and
something less than
the original
Very often, an alteration of presentation follows an alteration of content (or of connectivity, defined below), in the sense that more content (or more connectivity) requires more presentation, and less content (or less connectivity) requires less presentation. The opposite is not true, however. It is possible, in fact, to modify a presentation, without altering the content. A picture, for example, could be shown with a different size, or the items of a node could be arranged differently on the screen, without modifying their content [1].
Connectivity
The term connectivity refers to how an item is connected to the rest of the application, i.e., to the linking properties of the item. We can have four different situations for reuse related to the connections (links) of an item:
Reuse Type Symbol Meaning
connectivity l = the copy has exactly
equality the same connections
as the original
connectivity l + the copy has
addition additional
connections with
respect to the
original
connectivity l - the copy has less
subtraction connections with
respect to the
original
connectivity l the copy has
alteration different
connections with
respect to the
original
Taking decisions about the preservation of connectivity is difficult. Very often it is not clear how the links of an item should be preserved or modified in a different context [12]. Many surprising (or undesired) behaviours that we call "Wagner Tuba syndrome" found in several commercial applications are basically related to reuse of connections, as we will discuss with examples in the next section.
SOME EXAMPLES AND RECOMMENDATIONS FOR REUSE
This section presents some examples of reuse, taken from commercial applications and from prototype applications. Our case studies will be: "Art Gallery" 17 by Microsoft, "Musical instruments" [16] by Microsoft, "Polyptych" [20] and "MIPE" [18] by Politecnico di Milano. Lack of space forbids a systematic exploration of all possible situations; we just present a few interesting cases.
In the previous section, the various kinds of reuse were introduced in general terms, without the context of a specific data model. In the various applications analysed in this section, we will discuss how the various kinds of reuse can be applied to items of different sizes and different complexity, from an elementary value to a large structured portion of the application. This finer-grained analysis requires a reference model to describe precisely the information structures of a hypermedia application. For this purpose, we will adopt the primitives of HDM (Hypermedia Design Model [5, 7, 8, 10, 11]). The basic HDM terms needed for our discussion are the following: slot, node, component, entity, collection, collection node, collection member, (structural, collection, index, guided tour, applicative) link. The reader who is not familiar with HDM can find a very short introduction to these concepts in the Appendix.
The examples will proceed from the analysis of simple items (slot) to more complex structures (component, entity, collection); their reuse will be discussed along the five dimensions introduced in the previous section.
Example 1
Item type: Slot; reuse: (R, c=, p-, o=, l=)
In the delightful application "Musical Instruments" [16], the essential information is sound (of course). If we take the entity "Violin", for example, there is an audio slot that plays violin music for 10 seconds; it is used to identify the Violin's sound. The slot is presented (i.e. played) by clicking a standard "audio icon". It can be stopped, before the end, by clicking anywhere in the node.
The slot is reused (by reference, we guess) in several places. It is reused, for example, in the collection node for the collection "Violin and related instruments". In this copy, however the sound lasts for 2 seconds. We consider this situation as an example of presentation reuse (p-): only the presentation has changed, by simply shortening the length of the playing, but not the content[7].
From this example we derive the following considerations:
· first of all, it is better to not freeze, in the definition of multimedia slots, presentation features; in each different context, presentation may change.
In most approaches, presentation features are considered part of the definition of a multimedia object, while it should be better to associate (some of the) presentation features to the usage of an object. This change may imply a careful analysis of the possible presentation options from the early stages of design.
Multimedia slots with modified presentation (e.g. a miniaturized picture, or a miniaturized video, or a shortened audio) are sometime used to identify large objects of an application (as the case for violin above). The choice of the best multimedia slot as the "id" of a large object, with possible modifications of presentation, should be carefully investigated also in the early stages of design (not only at implementation time).
Example 2
Item type: Node; reuse: (V, c+c-,o=, p=p, l)
In the application "Art Gallery" [17], some nodes within entities "Paintings" are reused within special collections called Guided Tours [21] that represent lectures on a specific art subject (e.g., "Composition and Perspective"). They provide interesting examples of content reuse (by addition, c+, and subtraction, c-) and presentation alteration (p)
When in "Art Gallery" a node is placed in a Guided Tour, its content, in most cases, remains unchanged except for the addition of a new slot, an audio comment. The new slot plays several interesting roles. The most important role is to provide the motivations for putting the node in the Guided Tour (explaining, for example, why a node about "The Baptism of Christ" by Piero della Francesca is relevant for the Tour "Composition and Perspective"). An additional role of the audio comment is to provide some pieces of information that was "lost" by taking the node out of the original context. For example, in the node about "The Baptism of Christ", second step of the Tour "Composition and Perspective", the painter's name does not appear, probably because in the original context of the node this would be obvious. Thus the audio comment added in the new context provides the painter's missing name.
In a very few cases, something must be subtracted from the content. One example is at the fourth step of the guided tour "Composition and Perspective". The node being reused is "The Battle of San Romano", by Paolo Uccello. The text slot has been changed, since in the original use of this node the last paragraph had the purpose of introducing the other six nodes of the same painting. Since these other nodes are not included in the Guided Tour, the paragraph referencing them has been deleted.
The presentation of the copy is, in general, the same as the original[8], with the obvious need of taking care of the new active slot, the audio comment. The presentation of this new active slot somehow interferes with a previous active slot (animation) since the two interactions use different conventions in controlling the use of the "clicking" over the different areas of the screen. The resulting global interaction is quite confusing and hard to control [8].
Each node, in "Art Gallery", has two types of applicative links: generic links, implemented via hot-words, and schema links, that provide the most important connections, and must be activated through the See-Also button. When a node is reused in a Guided Tour, the generic links (that are less important) are retained, while the schema links are discarded (for implementation reasons, we guess).
The result of this reuse strategy is surprising: for example, from a painting it is possible to follow a generic link to a painter mentioned in the text description of the node as "friend" of the author of the painting, but there is no link to the author himself.
From these examples we can derive a few useful hints about reuse of nodes:
· audio is an excellent medium to reuse a node; it can provide the relationship between the copy and the new context where it is being placed.
· When a node is crafted, references to elements outside the node itself should be carefully avoided. These references are likely to create problems when the node is placed in a different context.
· Unnecessary changes of presentation should be avoided.
· Interactive presentation of active slots should sparingly use important resources as large areas of the screen; the addition of a new active slot, with its own need for interaction, may lead to unforeseen problems
· The implementation technique of links may severely limit their possibilities of reuse. Therefore reuse should be considered from the very beginning, as part of the design of connections and of the corresponding lay-out.
· It should be avoided to keep "less important" links in the copy while more important links are removed. If there are implementation problems, it may be wiser to eliminate all links from the copy.
Example 3
Item type: Component; Reuse: (R, c=, o=, p=, l= l )
In the application "Art Gallery" [17], a component of type "Painting" consists of several nodes, arranged in a sequence. In different parts of the application the same component is used in several entities, of different types, and provides examples of reuse by connectivity alteration (l).
A Painting component (see [8] for a better discussion) may be part of an entity "Painter", part of an entity "Historical Period", part of an entity "Picture Type", or part of an entity "General Reference". The content, the internal organization, the presentation (with a minor exception), and the connections are kept unchanged.
The painting component "The Baptism of Christ", by Piero della Francesca, for example, consists of a sequence of six nodes. It is reused in several entities (see Figure 1): "Piero della Francesca" (of type Painter); "Rest of Italy 1400-1450"[9] (of type Historical Period), "Altarpieces: Central panel" (of type Picture Type), "Baptism of Christ", "Disciples", "The Holy Spirit", "Jesus Christ", "Picture Space" and "Tempera" (all of them of type General Reference).
As far as connections are concerned, there are applicative links (implemented as generic embedded links or as schema links, activated via the button See-Also) and structural links associated to each node of a component. Structural links allow the reader to move from one node of the component to the next one, and often are activated via the button Next-Page[10]. When the last node of a component is reached, Next-Page leads to the first node of the next sibling component of the same entity. From the last node of "The Baptism of Christ", for example, different components are reached, depending on the context (entity) where the component is being reused (see Figure 1).
The navigation from the root component of an entity (say "Piero della Francesca") to any of the "children" components (i.e., the corresponding paintings), is implemented through embedded links; the navigation across sibling components is obtained via Next-Page; the navigation from a component to the "father" (root) of an entity is not straightforward: the button SeeAlso must be used, but all the roots of all the entities in which the component is reused can be reached, from any context! In other words, while the links among sibling components are context dependent, the links from component to root are context independent.
Reuse of components is prone to errors, and may induce some usability problems. We can observe a few weaknesses in the choices of Art Gallery:
the different treatment of links to siblings and links to father is confusing.
The fact that the meaning of Next-Page is radically different, in each context, while everything else seems to be the same, can be disorienting for the reader.
The accessibility of the root of the entity to which the component belongs and the accessibility of the collection to which the entity belongs are very poor.
In some situations, the reader may start with an entity, get to a component, and then be unable to go back to the entity itself (i.e., to its root or to its other components). The reason is that some of the links from component to entity are missing. From the component "The Baptism of Christ", for example, there is no link to "Tempera", nor to "Picture Space", despite the fact that "The Baptism of Christ" belongs to all those entities.
Our conclusion is that reusing components within different entities is clearly desirable, but difficult. All the structural links of the component (i.e. the link to the father, the links to the siblings and the links to the children) are potentially different for each copy of the component. If the reuse is implemented by-reference, the only way of reusing components is not to embed structural links within the component, but to implement them in a separate engine (that has the job of "computing" links according to context).
In Art Gallery a mixed decision seems to be taken: the links to siblings (Next-Page) are implemented via a separate engine, and therefore are context-sensitive e different for each context. The links to the father (the root of the entity), instead, are statically associated to the component itself (See-Also) and never change. This choice creates the inconsistent situation above described.
Example 4
Item types: Entity; Reuse: (V, c=, o=, p=, l)
In the application "Musical Instruments" [16], the basic entity type is "musical instrument", as it may be obvious. The same entity appears in several different collections, in order to provide different organizations of the material. The entity Violin, for example, appears, among other collections, in "A-Z of instruments" (that presents instruments in alphabetical order), "String Quartet" (within "Musical Ensembles") and "Violin and related instruments" (within "Families of instruments").
In each different collection, the entity retains is content, its organization, its presentation.
The situation of links is more complex instead. The entity Violin has always two links, labeled "types" and "See-Also". The link "types" leads to the collection-node "Violin and related instruments". The link "See-Also" shows four instruments ("Rebec", "Cello", Double Bass", "Viol") related to Violin, and we may consider it an applicative link (see the Appendix).
Collection links, instead, depend on the context. The meaning of the button "Next", correctly, changes according to the collection, in the following manner:
CONTEXT for Target of Target of a
VIOLIN NEXT link second NEXT
link
A-Z Wagner Tuba Whip
instruments
String Quartet Viola Cello
Violin and Viola Rebab Andaluz
related
instruments
The reuse of entities, within different collections, can always creates problems about the correct interpretation of collection links. Troubles, in fact, appear also within this application.
If we start from the "String Quartet" and we select Violin, and then activate the button "types", we are presented with the node associated to "Violin and related instruments". If we now select again Violin from there, we expect to have changed collection, therefore activating "Next" we expect to reach Viola and then Rebab Andaluz, as shown in the table above. In the application, instead, Viola and Cello are reached, since the collection links, mistakenly, do not follow the change of context.
Let us assume, now, that we start from String Quartet, select Violin and activate the button "See Also": a small Box with the four instruments ("Rebec", "Cello", Double Bass", "Viola") is displayed. If we close the Box, without selecting any instrument, and then we activate "Next", we reach "Wagner Tuba", fact that generates quite a surprise for the average reader!
What happens is that the collection links for "A-Z instruments" are mistakenly being used, despite the fact that this collection has never been activated.
Our observation is that when an entity is inserted in several collections, it may be difficult to decide, from the context, which collection links should be used, i.e., what's the meaning of "Next". A rigorous design model [6] is needed, without possible ambiguities.
What must be avoided is an inconsistency between the context, as perceived by the reader in a given situation, and the context, as defined by the application. The user expects the connections to follow the rules of the context that he believes being the current one; he will be surprised to see a behaviour related to some other context. We call "Wagner Tuba syndrome", the conflict between the apparent context for the user, and the choice of links made by an application. The choice of the term is not because this is the only application where such a conflict exists[11], but only because we find amusing this specific example.
Example 5
Item Type: Entity; Reuse: (R, c=, o=, p=, l= l)
The application MIPE [18] concerns issues of classic and modern philosophy, based on interviews to modern philosophers. The entities are grouped in the following entity types: "work", "interviewee", "philosophers", "fragments" (of interviews). Each entity has a complex inner organization, and also links to other entities (e.g. from "work" to "philosophers"). The multimedia part consists of video sequences containing the interviews and also actors reading anthology fragments of some famous philosophy works.
The same entity is reused in several collections. In this application, all the (structural and applicative) links of the entity are retained during reuse.
Some of the collections are just taxonomic (e.g. the list of works in alphabetical order, the list of philosophers in alphabetical order, the list of interviews by time, etc.). Other collections have different nature. The collections of type "lecture", for example, put together, in a sequence, entities of different types, in order to cover a specific subject (e.g. "Ethics for Aristotle", or "The notion of Justice"). In addition, beside predefined reuse, the designers wanted to be able to build additional collections at will[12] by choosing on-the-fly the items to be used. Entities are inserted in new collections simply marking any of its component while visiting them. In the new collection being built, the marked component will be presented by default as representative of the whole entity.
When the reader is using a collection (e.g. a lecture) only the collection links are made immediately available (see Figure 2). The reader must "suspend" the collection, in order to make the links of the current entity available (see Figure 3). When a collection is suspended the reader can then freely navigate using applicative and structural links of the application. A "resume" will return to the entity from which the collection was suspended, and the collection navigation will be resumed from there.
We can derive the following recommendations:
it can be necessary to keep collection links distinct from the other links, up to the point that they are mutually exclusive (if the collection is active, collection links only can be used; if the collection is suspended, the other links are available). This can help in avoiding the "Wagner Tuba syndrome" discussed in the previous example.
Allowing to insert an entity by choosing a specific component, can be exploited to provide interesting multimedia features. In MIPE, for example, if an entity (e.g. of type "fragments" or "work") is inserted in a new collection by marking the video component, the result is a collection that looks like an interactive video: the video components are automatically played in sequence. Whenever the reader suspends the collection, the video is paused, and all the remaining components of the entities as well as the other links become accessible.
Reusing entities within collections, therefore, can result in building, easily and safely, new multimedia presentations, still retaining the connections to the remaining of the application.
Example 6
Item Type: Collection; Reuse: (V, c=, o, p=, l=)
The application "Polyptych" [20] presents the foundation and results of a five-years research, led by the Poldi Pezzoli Museum in Milano, concerning history, art vicissitudes, reconstruction, restoration, of the so called "Agostinian Polyptych" by Piero della Francesca. This hypermedia provides some interesting example of organization reuse.
Among other collections, one is called "Dresses", discussing different cultural sources for the dress of Saints and Angels in the religious images of 14th century. For this collection we have two possible organizations: "linear" and "lattice". In the "linear" organization (which belongs to the original collection), the nodes are placed one after the other, in a sequence. The "lattice" organization of the copy, instead, provides a more elaborated topology, following the flow of different lines of argumentation. The members of the two collections -- the original and copy -- are shared. Thus content reuse is implemented by-reference. A navigational engine is used to compute collection links at run-time.
Our observation is that restructuring collections can be a powerful reuse technique to address the requirements of different categories of user. The linear organization, for example, is very easy to navigate through and it is therefore recommended for users with little or no previous knowledge on the subject. Lattice navigation is more complex to follow, since it often presents multiple navigation choices; we therefore recommend it for experienced users only.
CONCLUSIONS AND FUTURE WORK
Reuse of information items is already an important ingredient of most hypermedia applications. Reuse, in fact, is an critical factor for improving the quality (by improving usability) and reducing cost.
Reuse, however, does not come for free. Effective reuse requires a careful implementation and, above all, a careful design. From slots to nodes, from components to entities and collections, only a careful design, combined with a consistent implementation, can improve the possibility and the effectiveness of reuse. It is first of all a job for designers to avoid pitfalls and surprising (or undesired) behaviours of the application such as those discussed in this paper. Designers should have in mind a schema of reuse from the very beginning of their work, and should adopt a design model to describe their reuse choice, in order to avoid ambiguities and/or inconsistencies of specifications and to provide programmers with clear application requirements.
The analysis of information reuse discussed in this paper has no pretence of being exhaustive; it should be considered a proposal to stimulate a discussion related to information reuse within hypermedia applications and authoring systems. In our research work, we are currently focused upon integrating some reuse facilities in our development environments, to support what we call second level authoring.
Second level authoring has the goal of allowing a new author to reshape an existing application, in order to get a "customized" version of it. The main exploitation area that we have in mind is education. We are experimenting with a set of second-level authoring tools within GEPRO [10], a hypermedia course on "Production Management" (economic models, production phases, company cases). The features that we have (partially) provided in our tools are the following:
· Reuse of nodes, by re-reference, with content addition and deletion
· Reuse of nodes with (slightly) modified presentation
· Reuse of entities, with alteration of their internal organization
· Definition of new collections by reusing entities, to improve accessibility
· Creation of new, simplified entities (by omitting some components or linearizing their organization), to help the creation of new collections
· Hiding of some collections (for some users)
· Addition of new audio slots for reusing nodes in new collection, in order to "glue" together the members.
· Creation of new multimedia material, linked to pre-existing material (a different type of reuse, not discussed in this paper).
The idea is that for a specific educational purpose (say for a graduate course, or for an undergraduate course, or for a training short course, etc. ) a "second level author" (e.g., a professor from a different university) can get a specific version of the material created by the initial authors, reusing it in several fashions in order to personalize the application and to adapt it to his specific needs.
REFERENCES
1. Buchanan M.C., Zellweger P., "Automatic Temporal Lay-out Mechanisms". In Proc. ACM Multimedia'93, Anaheim, Ca, 1993
2. Cavallaro U., Garzotto F., Paolini P., Totaro D. "HIFI: Hypertext Interface for Information Systems". In IEEE Software, Nov. 1993
3. De Mey V., Gibbs S., "A Multimedia Component Kit". In Proc. ACM Multimedia'93, Anaheim, Ca, 1993 4. Frakes W.B., S.Isoda, "Success Factors of systematic reuse". In IEEE Software, Sept. 1994 5. Garzotto F., Paolini P., Schwabe D. "HDM -- A Model Based Approach to Hypermedia Application Design" In ACM Trans. Inf. Syst., 11 (1), Jan. 1993
6. Garzotto F., L. Mainetti, P. Paolini "Adding Multimedia Collections to the Dexter Model". In Proc. ECHT'94 -- ACM Conference on Hypermedia Technology, Edinburgh, UK, Sept. 1994
7. Garzotto F., Mainetti L., Paolini P., "Hypermedia Application Design: A Structured Approach". In Designing User Interfaces for Hypermedia, W. Schuler, J. Hannemann, N. Streitz (eds.), Springer Verlag, 1995
8. Garzotto F., Mainetti L., Paolini P. "Hypermedia Design, Analysis and Evaluation Issues", Comm. ACM 38 (2), Aug. 95
9. Gibbs S., Breiteneder C., Tsichritzis D., "Data Modeling of Time-Based Media". In Proc. ACM SIGMOD, Minneapolis (USA), May 1994
10. GEPRO, "Production Management"- an interactive multimedia text-book by Politecnico di Milano
11. Garzotto F., L. Mainetti, P. Paolini "HDM2: Extending the E-R Approach to Hypermedia Application Design". In Proc. ER'93 -- 12th International Conference on the Entity-Relationship Approach, Arlington (USA), Dec. 1993
12. Hardman L., Bulterman D.C.A., Van Rossum G., "Adding Time and Content to the Dexter Model". In Comm. ACM, 37 (2), Feb. 1994
13. HIFI, HDM+ User Manual, ESPRIT Project HIFI, 1993
14. Hodges M., Russell M. Sasnet, "Multimedia Computing -- Case Studies from MIT Project Athena", Addison Wesley, 1993
15. IEEE "Special Issue on Systematic reuse" -- IEEE Software, 11 (5) September 1994
16. Microsoft, "Musical Instruments", CD-ROM Microsoft Corporation, 1992
17. Microsoft, "Art Gallery -- The Collection of the National Gallery, London", CD-ROM Microsoft Corporation, 1993 18 MIPE -- "Multimedia Interactive Philosophy Encyclopedia", a joint project between Politecnico and RAI, the Public TV network in Italy
19. Nielsen J., "Usability Engineering", Academic Press, 1993
20 POLYPTYCH -- An interactive multimedia presentation, joint project between Politecnico di Milano and the Poldi Pezzoli Museum -- Milano
21. Trigg R.H., "Guided Tours and Tabletops: Tools for Communicating in a Hypertext Environment". In ACM Trans. Inf. Syst. 6 (4),1988 22. Wayne L.C., "Effects of reuse on Quality, Productivity and Economics". In IEEE-Software, 11 (5) September 1994
APPENDIX: A SHORT HDM GLOSSARY
HDM: a model developed over a number of years for designing hypermedia applications.
Slot: an atomic piece of information. It can be of a simple type, such as an integer, or of a complex type (e.g. a video synchronized with sound). The interaction with a passive media slot (e.g. an integer) is very simple, in general. The interaction with a multimedia slot can have complex features (e.g. controlling the playing of video).
Node: a navigational unit. To a node is associated a frame, i.e. an aggregate of slots. A node is, in general, also a unit of presentation (i.e. what is "shown" to the user). Passive media slots, in general, are presented at once. Active media slots may require a different strategy. When several active media slots are involved (say multiple sound tracks, videos, animations, etc.), there are complex issues concerning parallel presentations with proper synchronization, or well-sequenced presentations [3, 12].
Component: it is a group of nodes that constitute a logical unit.
Entity: it groups together a number of components, in a granule that corresponds to a real-world object. The arrangement of the components, within the entity, can vary, according to the structure of the entity itself. It is common the arrangement of entities as trees or sequences.
Collection: it is a set of items, called members of the collection [6]. A collection may play the role of a taxonomy (e.g. all Painters in alphabetical order) or may have the purpose of improving application readability (e.g. organizing Painters by place and period). It is often the case that there is a special node, the collection-node, associated to the collection itself, and connected to all the members
Link: connection among different items (i.e. entities, components, nodes or collections).
Structural links: they tie together the nodes belonging to the same components, and the components belonging to the same entity. Their structure is implicitly defined by the structure of the entity and component to which they belong
Collection links: they tie together the different pieces of a collection, i.e. the collection-node and the members. Their structure is implicitly defined by the structure of the collection. They can classified in Index links and Guided Tour links
Index links: they connect the collection node to each member of the collection, and viceversa. The Index navigation allows to move from an index (collection node) to a member, and, possibly, viceversa.
Guided Tour links: they connect together the different members of a collection. It is typical the arrangement of linear collections, where members are put in a sequence, with each member connected to a Next one and to a Previous one. A typical combination allows the random selection of a member (Index navigation), and from this the subsequent exploration of other members (Guided Tour navigation).
Applicative links: they connect together two items according to some intended application relationship. They can be classified as schema links, that belong to a defined link type, and generic links, that do not correspond to any predefined type.
Figure 1: Structural navigation for the component "The Baptism of Christ" (Piero della Francesca)
Figure 2: Reuse of entities: collection links are active; applicative links are not
Figure 3: Reuse of entities: applicative links are active; collection links are not
