Designing Computational Hypermedia Applications
This position paper analyses the problem of extending computational applications with hypermedia, from a design point of view. It focusses on the design of evolvable and easy-to-maintain applications combining hypermedia features with more conventional application behavior. The object-oriented hypermedia design method (OOHDM) is the conceptual basis of our approach. Using the visual tools provided by OO-Navigator, an object-oriented support environment for OOHDM, it is possible to construct computational hypermedia applications applying the concepts of the OOHDM. Also, the problem is analysed from a higher abstraction level. Design patterns are introduced and it is shown that they are a powerful tool to record and reuse designers\0xFFFD experience. A set of patterns for hypermedia applications that address problems both at the architectural, navigational and interface levels are presented. A reference architecture for computational hypermedia applications is outlined and further work in this area is discussed.
As reported by Bieber and Kacmar (1995), the use of hypertext functionality (HTF) in software systems provides benefits such as:
- Increasing user comprehension through interface enhancements.
- Obtaining new ways of viewing and manipulating the knowledge contained in the application by navigating (forward and backward) through items of interest.
- Being able to annotate the application with comments and relationships.
Building applications that combine hypertext navigation with more conventional computation is far from easy; these applications, from here on referred to as 'computational hypermedia applications' (CHAs), involve design aspects from high-level architecture to those related to the user interface. For instance, if we are extending a conventional application with hypertext features, we must define the way in which hypermedia components will interact with existing software modules. Even if we are building a new application from scratch, its domain model must be designed separately from navigation components, to maximize reuse and minimize maintenance costs. When many applications providing hypertext functionality are built, the obvious step forward is to simplify the process by building reusable classes or class libraries implementing the usual hypertext concepts such as nodes, links, paths, etc.
While the above issues are related to the organization of software components in a computational hypermedia application, there are other design problems to be solved: those related to the navigational and interface structures of the application. For example, nodes have to be organized to make navigation easier and to avoid cognitive overhead; the interface must be designed to be usable and intelligible, given that it must contain many different features, etc.
This paper presents a conceptual framework for reasoning about hypertext functionality from a design point of view. We are interested in obtaining a methodological approach allowing modular and structured construction of applications supporting both computational and hypertext features.
During the last three years we have been working on an object-oriented hypermedia design method (OOHDM) (Schwabe et al. 1996, Schwabe and Rossi 1995a, Schwabe and Rossi 1995b, Schwabe and Rossi 1994). We have built large, real hypermedia applications, including Web information systems, using this methodology. The paper first discusses the role of OOHDM as a design guideline to build computational hypermedia applications (Section 2). Using OOHDM a designer can build evolvable applications by clearly separating different design concerns: computations, navigation and interface.
Section 3 discusses how to implement this kind of application by focussing on a reusable software framework - OO-Navigator - that helps build computational hypermedia applications. This framework is composed of a set of classes that can be 'plugged' into the application\0xFFFDs components to implement navigation behavior. Though OO-Navigator is restricted to object-oriented applications, it gives a flavor of the design problems we encounter while designing this kind of system. We show how this framework supports the methodological view presented in Section 2.
Section 4 looks at the problem from a more abstract point of view, showing how the use of design patterns (Gamma et al. 1995), both general and specific to the hypertext field, can help in the process of building computational hypermedia applications. We show how the experience of designers in the hypermedia domain can be described using patterns.
A general architecture for CHAs is outlined in Section 5, showing the way it is derived from a set of patterns for hypermedia.
The relationships between the different issues discussed in the paper and the 'big picture' of our ongoing research are explained in Figure 1, which shows OOHDM as a methodology that is well suited for developing CHA. OO-Navigator is an object-oriented software platform for implementing these applications by reusing hypermedia components. This framework has been implemented by instantiating a set of architectural patterns that encapsulate design expertise common to CHA; these patterns provide knowledge to designers who want to implement features such as navigation and backtracking in their software systems. Finally, navigational and interface patterns deal with the navigational and interface structure of CHA. These patterns help the designer build applications in which users do not experience disorientation or cognitive overhead.
Figure 1. Design space in CHAs (full-size figure)
Throughout the paper the discussion is guided by an example application related to coast guard tasks. The coast guard takes information about migration, feeding, pollution, and other data concerning the ocean territory and fish protection. This information is constantly updated from fishing reports, which are generated by boatswains from vessels, and by ichthyologists at the port. Coast Guards must determine different types of zones, such as mating season zones, and must accept trips of companies via reports, taking into account means of fishing, fish species and their routes, etc.
2 Overview of the OOHDM
This section briefly explains why using a hypermedia design methodology is important while building CHAs. Typically, discussion of hypertext functionality has focused more on the articulation of applications and hypertext features than on the quality of the hypertext network itself. When building large applications, however, design problems associated with the navigational structure may severely compromise the overall quality of an application. We first summarize some of the best-known problems related to hypertext design. The OOHDM is introduced by describing the design activities it comprises and the relevance of this methodology to CHAs.
2.1 Problems of hypermedia design
In the last seven years there has been an interesting debate in the hypermedia community about the scope of hypermedia applications and the problems that designers and readers must face when building hypermedia applications. The first problem is related to an important issue in software engineering: if we want to design and implement high quality applications we need to understand the problem domain and build a model that abstracts domain objects, relationships and collaborations. In other words, we must understand the underlying application model before thinking in terms of hypertext components such as nodes and links connecting them (see, for example, Thuring et al. (1991)). CHAs push this issue further, as the hypertext component of these applications must be seamlessly integrated with the 'behavioral' component.
Navigation should not be considered just another kind of application functionality, however. As pointed out by Bieber and Vitali (1997), as applications move on to the Web (or on to intranets executing in servers accessed by Web browsers) there is a risk of losing the most appealing aspect of the Web: its hypertext structure. Designing the hypertext functionality of CHAs is a key activity if we want to obtain high quality applications in which the user can profit from forward and backward navigation without being disoriented and without suffering information overload.
2.2 Outline of the OOHDM
The OOHDM considers the hypermedia application development enterprise as four activities, performed in a mix of iterative and incremental styles of development; in each step a model is built or enriched. Table 1 summarizes the four activities: conceptual modeling, navigational design, abstract interface design, and implementation. The products generated by each activity and the abstraction mechanisms used throughout the process are described in the table.
|Conceptual modeling||Classes, sub-systems, relationships, attribute perspectives|| Object-oriented modeling constructs
generalization and specialization
| Model the semantics of the application
|Navigational design||Nodes, links, access structures, navigational contexts, navigational transformations|| Object-oriented views
User centered scenarios
|User\0xFFFDs profile and task. Emphasis on cognitive aspects|
|Abstract interface design||Abstract interface objects, responses to external events, interface transformations|| Abstract data views
| Mapping between navigation and
Composition and generalization/
| Model perceptible
objects, implementing chosen metaphors. Describe interface for navigational objects. Define layout of interface objects
|Implementation|| Running application
|Those supported by the target environment||Those provided by the target environment||Performance, completeness|
It should be stressed that typical design does not progress linearly from one activity to the next. In this sense, 'activities' here should be regarded as 'design aspects' that must be addressed in a complete design. A typical development will involve feedback loops as mentioned by Isakowitz et al. (1995) and Nanard and Nanard (1995), and the relation between design decisions can be recorded through a simple but powerful traceability model that allows changes in one design model to be mapped to parts of a previous one (backward traceability).
2.2.1 Conceptual modeling
During conceptual modeling, a model of the application domain is built using well known object-oriented modeling principles (Rumbaugh et al. 1991, Rational Corporation 1997), augmented with some primitives such as attribute perspectives. Conceptual classes may be built using aggregation and generalization/specialization hierarchies. The main concern during this step is to capture the domain semantics as 'neutrally' as possible, with little concern for the types of users and tasks. The product of this step is a class schema built out of subsystems, classes and relationships. Figure 2 presents the conceptual schema of the coast guard application. For the sake of simplicity only information objects are shown and complex behaviors in the schema are not included.
Figure 2. Conceptual model of the coast guard application (full-size figure)
When building CHAs or when extending conventional applications with hypertext functionality, the conceptual model represents the 'non-hypertext' component of the application.
If we are designing an application from scratch, the conceptual model will contain a precise specification of the application objects, their relationships and behaviors. In this case, if the target implementation environment is fully object-oriented, conceptual classes will be implemented in a straightforward way; OOHDM does not prescribe that we need objects in the implementation, however.
If, on the other hand, we are enriching a (non-object-oriented) legacy application with hypertext features, conceptual classes can be seen as 'wrapping' application data and functionality. Using wrappers as a previous step to re-engineering legacy applications is a well-known technique (Roth 1997) and we will not elaborate it further in this paper.
2.2.2 Navigational design
In OOHDM, an application is seen as a navigational view over the conceptual model (Figure 3). This reflects the view that the key distinguishing feature of hypermedia applications is the notion of navigation. In addition, the objects the user 'navigates' through are not conceptual objects, but rather other kinds of objects 'assembled' from the conceptual objects through a view mechanism. It is in this step that the designer takes into account the intended users, and the set of tasks they are to perform using the application. Thus, different applications may correspond to different views on the same domain.
Figure 3. Navigational and interface models as object-oriented views (full-size figure)
The navigational structure of a hypermedia application is defined by a schema specifying navigational classes that reflect the chosen view over the application domain.
In OOHDM there is a set of pre-defined navigational classes: nodes, links and access structures. The semantics of nodes and links are typical of hypermedia applications; access structures represent alternative ways of accessing nodes such as indexes, guided tours, etc. Nodes are defined as object-oriented views of conceptual classes defined during conceptual modeling using a query language similar to the one in Kim (1994), allowing a node to combine attributes of different related classes in the conceptual schema. They contain single typed attributes and link anchors and may be atomic or composites as in Gronbaek (1994).
In the same way, links reflect relationships intended to be explored by the final user. When an anchor is activated (for example, as the result of an interface event) its standard behavior is to activate the associated link, which in turn will open the target node. A full specification of OOHDM semantics can be found in Schwabe and Rossi (1998).
What is new in OOHDM with respect to CHAs is the explicit definition of a navigational model and a structured mapping of navigational objects to application (conceptual) objects. We do not conceive the process of adding hypertext functionality to an application as an anarchic one in which nodes and links are defined on the fly; rather we see it as the consequence of a careful analysis on the users\0xFFFD tasks and profiles. Even though, in many application domains, nodes and links may be defined dynamically, they should follow the navigational model, which express not only the way in which users will navigate the resulting hypermedia, but also the relationships among nodes and application objects. Figure 4 presents the navigational schema for the coast guard application.
Figure 4. Navigational classes in the coast guard application: a researcher view (full-size figure)
In the schema of Figure 4 we have filtered many relationships appearing in the conceptual schema of Figure 2; we have just emphasized the kind of navigation a researcher would need for his task. Some indexes have also been included: an index to FishSpecies, and index to Zones, etc.
In OOHDM the main structuring primitive of the navigational space is the notion of navigational context. A navigational context is a set of nodes, links, and other (nested) navigational contexts. They have been inspired in the idea of nested contexts (Casanova et al. 1991). Navigational contexts help to organize the navigation in such a way that users can easily explore meaningful sets of related information items.
Contexts may be defined intentionally or extensionally, i.e. by either defining a property that all nodes and links in the context hold or by enumerating its members. In OOHDM there are six pre-defined types of navigational contexts:
- Simple class-derived - all objects of a class that satisfy some property, e.g.' All FishSpecies in a Mating Zone'. A variant of this type is the query-based context, where the property is defined by the user at navigation time.
- Class-derived group - a set of simple class-derived contexts, where the defining property of each context is parametrized, e.g. 'FishSpecies by Mating Season' (rank can vary).
- Simple link-derived - all objects related to a given object, e.g. 'reports for a FishSpecies' (derived from link 1-to-n 'reports').
- Link-derived group - a set of link-derived contexts, each of which is obtained by varying the source element of the link, e.g. 'reports from a FishSpecies' (FishSpecies varies).
- Arbitrary - is an enumerated set, e.g. a guided tour, a selected set of FishSpecies.
- Dynamic - is a set where the elements change during navigation, e.g. navigation history.
InContext classes complement the definition of a navigational class (a node), indicating which information is shown and which anchors are available when accessing the node in a particular context. In our example when we explore a fish species in a mating season (context 'Fish by mating season') we may want to read some explanation about the mating season. Links and anchors are supposed to be automatically provided by the context such as, for example, those allowing navigation to the next and previous nodes within the context. In the same way, contexts may have an index pointing to its elements.
Navigational contexts are design structures that may be used in different application domains, even if we are not using OOHDM as a design methodology. In Section 4.3 we generalize the discussion of navigational contexts by presenting them as a design pattern.
2.2.3 Abstract interface design
Once the navigational structure of an application has been defined it must be made perceptible to the user through the application interface, which is done in this step by defining an abstract interface model. This means defining which interface objects the user will perceive, specifically, what different navigational objects will look like; which interface objects will activate navigation; the way in which multimedia interface objects will be synchronized; and which interface transformations will take place.
A clean separation between both concerns, navigational and abstract interface design, allows different interfaces to be built for the same navigational model, leading to a higher degree of independence from user interface technology, as well as allowing conformance with varying user needs or preferences. Unfortunately, design methods tend to deal with interface specification rather informally; in contrast, interactive (in particular, hypermedia) applications rely heavily on the interface, so it is critical to make a clear, formal specification that allows this aspect of the application to be evaluated and maintained.
In OOHDM we use the abstract data view (ADV) design approach for describing the user interface of a hypermedia application (Cowan and Lucena 1995). ADVs are formal models of interface objects that are specified by showing:
- The way in which they are structured using aggregation and generalization/specialization as abstraction mechanisms. ADVs express the static layout structure that implements the interface metaphor (Hannemann and Thuring 1993). Perception properties are also specified as attributes or parts of an ADV.
- The way in which they are statically related with navigation objects. We use configuration diagrams (Coleman et al. 1992) as a tool for expressing these relationships.
- How they behave when reacting to external events, in particular how they trigger navigation and which interface transformations occur when the user interacts with the application. We use ADV-charts (Carneiro et al. 1994), a derivative of state charts, that add both structural and behavioral nesting and a Petri-net-like notation for expressing synchronization issues which are common when dealing with multimedia data. ADVs allow complex interface transformations to be expressed and they can also delegate messages to application objects.
Since the modeling constructs we use during navigational and abstract interface design are quite similar, we obtain a seamless transition between both activities, which allows incremental construction of the navigational and abstract interface models. At the same time, relevant design decisions are recorded using a notation that is powerful and concise. A complete description of our approach for specifying hypermedia interfaces is in Rossi et al. (1995b).
To obtain a running implementation, the designer has to map the navigational and abstract interface models into concrete objects available in the chosen implementation environment. The model generated after performing conceptual, navigational and interface design, can be implemented in a straightforward way using many of the currently available hypermedia platforms such as the World Wide Web, Toolbook, MacWeb, Microcosm, etc. The use of a uniform set of modeling constructs (objects and classes) in our methodology allows a smooth transition from domain modeling to navigational and interface design. The implementation step does not require that an object-oriented environment be used, although it might make the job easier. For example, if we use the OO-Navigator framework (section 3) we can directly map conceptual classes to the OO-Navigator\0xFFFDs object level and build the navigational model by instantiating framework classes.
2.3 Relevance of the OOHDM with respect to CHAs
Some important aspects of OOHDM make the method suitable for designing CHAs: being object-oriented, it uses state-of-the-art software engineering to build complex applications. Since objects comprise both structure and behavior, we can express computations and their relations with hypertext in a straightforward way by defining how nodes and corresponding objects interact with each other. Other hypertext design methodologies such as RMM (Isakowitz et al. 1995), though containing semantically rich primitives, lack the expressive power of objects. Besides, the uniform communication model among interface, navigational and conceptual objects in OOHDM allows a seamless transition from each concern to others.
A designer building a CHA can follow OOHDM closely to model and implement an application. The conceptual model will specify the objects, relationships and collaborations, and the navigational model will specify the hypertext functionality.
In the coast guard application, for example, the conceptual model has been designed by reflecting the application domain; hypertext functionality has been added afterwards without compromising the application\0xFFFDs class structure. This separation helps improve design modularity and, as noted above, allows different hypertext views to be defined for different user profiles or interests.
In a complex application it may be hard to decide which conceptual objects will be mapped to navigation and then to interface objects. In this case, conceptual classes can be organized using Jacobson\0xFFFDs guidelines (Jacobson et al. 1992): classes abstracting information objects will be candidates to be mapped to hypermedia nodes. In the coast guard example, this is the case of FishSpecies, Vessel, Fisherman, etc. In contrast, classes providing either coordination control or algorithms (not shown in the example) will not need a hypertext view.
We have implemented a software substrate that allows the OOHDM methodological principles to be applied to concrete software developed using an object-oriented language. The following sections present OO-Navigator and analyse the most relevant design decisions behind its implementation.
3 OO-Navigator framework
Application frameworks are the state-of-the-art solution for building high quality applications in a particular domain by reusing an abstract design for that domain (Johnson and Foote 1988). An object-oriented (OO) application framework provides a set of classes that, when instantiated, work together to accomplish common tasks in the intended domain. Once the instances of classes in the framework begin their work, they manipulate the flow control of the entire application.
When many different applications must be constructed in the same domain, application frameworks provide 'templates' to support their variation. These templates usually have the form of abstract classes that must be subclassified with concrete classes, or filled with 'hook' methods that must be implemented by the application designer (Pree 1994). The designer of the framework must understand the domain and be able to decouple the concrete model of a particular application from the abstract model of the whole domain. New applications can be built by simply plugging framework and application components. Application frameworks have been built in areas such as user interface design (Krasner and Pope 1988, Woolf 1994) and graphical editors (Johnson 1992).
We have built an application framework (OO-Navigator) implementing the hypermedia functionality approach (Garrido and Rossi 1996, Garrido and Rossi 1999). The main goal of the framework is to help designers extend OO applications with hypertext features or build new applications that combine navigation with conventional computations. OO-Navigator provides intra-application linking and is different from other approaches, such as Hyperdisco (Wiil and Leggett 1996), from the open hypermedia systems community: OO-Navigator does not claim to be open, but in contrast is highly integrated with the underlying support environment.
The framework itself is formed by a set of classes that represent navigational components, plus an abstract collaboration model that 'connects' with any OO application, in different ways and contexts. This generality is achieved by allowing navigational components to be plugged into any application object. With this connection, nodes and links become 'observers' of those objects (Gamma et al. 1995), and each time an object changes its state, the node(s) mapping that object will immediately reflect that change. Moreover, nodes notify corresponding objects each time an interface event occurs.
In this way, application and navigational components remain separated in different layers, thus easing maintenance and evolution. The architecture of an application using the framework is divided in three layers:
- the object level, where the underlying application resides
- the hypermedia level, where the framework is defined
- the visual level, where the interface aspects are managed (objects belonging to the application or the framework may be part of this layer).
Figure 5 shows an outline of the architecture of an application using the hypermedia framework.
Figure 5. Objects, nodes and their relationships (full-size figure)
At this point let us assume an existing object level and let us play the role of the hypermedia designer. For each object in the object level the data of which we intend to explore with a hypermedia-like style, or the behavior of which we want to dispatch from a navigational interface, we may associate one or more nodes. Each node in turn may have different faces, one for each possible user profile or need. The hypermedia application should define all possible user profiles with which it can be accessed (see this mapping in Figure 5).
For each meaningful relationship in the object level that we pretend to navigate, links are created connecting corresponding nodes. We also define indexes and other access structures (Garzotto et al. 1993) providing access to nodes by querying the attributes of objects. Links are objects that map relationships in the object level (Figure 5).
When nodes, links and indexes are created, we are in fact instantiating corresponding classes in the framework and relating them with corresponding application objects.
Graphical interfaces are defined for each node and constitute the 'front-end' of the final CHA. An interface is composed of widgets. A widget may represent a data item mapped from an object (in the object level) into the node (hypermedia level), or it can be a kind of active object (e.g. a button) that dispatches some behavior from the object level. Moreover, widgets may contain 'sensible areas' that constitute the graphical representation of anchors for links (we use the term \0xFFFDanchor\0xFFFD here as the source of a link).
When an interface event occurs, it is handled by the activated interface widget. This widget, depending on its type and the way it was defined, will activate the associated anchor, so producing navigation, or will trigger methods in one or more objects associated with that node.
OO-Navigator is an open framework in that it is possible to implement new hypertext features besides existing ones; for example, we could specify different backtrack strategies as in (Bieber and Wan 1994) or implement different navigation history viewers (Rossi et al. 1995a) by adding new classes to the framework and customizing the standard behavior. Moreover, these extensions can be independent of any application.
The following section provides an overview of how the framework is used, giving a better insight into how the internal components work together with the application.
3.2 An outside look at the framework
This section outlines the steps that a software designer should follow when using OO-Navigator to add hypertext functionality to an object-oriented application.
Suppose that the activity of conceptual modeling, as described in OOHDM, has been performed. This is to say that the object level of the framework is complete. The focus is then on the navigational design, as defined by OOHDM, and we will work with the model of the hypermedia level defined by OO-Navigator.
The following is a rough enumeration of the steps that the hypermedia designer should follow to instantiate the hypermedia level:
- Create an instance of the class Hypermedia. This object is necessary to represent the entire hypermedia network. The Hypermedia object is also responsible for opening the first node and recording the history of user navigation.
- Define a 'point of view' for each different user profile and the transitions allowed among points of view. When using OOHDM different navigational models may be built for the same conceptual schema. User profiles in OO-Navigator allow different navigational views, intended for different users. the allowed transitions are then defined accordingly, when the same user may play different roles. For example, in the coast guard application, we may define the Manager and Ichthyologist views.
- Define node classes. A node-class defines common properties of a group of nodes that contain the same attributes, look alike and are related to other nodes in the same way. When extending an OO application, node-classes will be derived from application classes, i.e. objects belonging to an application class will usually be mapped to nodes belonging to the same node class. In our example, we could define 'FishSpecies', 'TripReport', 'Zone', etc., all as node-class. A node class is responsible of creating nodes for each existing object of the application class from which it was derived. Nodes are specialized in atomic nodes and composites. For example, 'FishSpecies' nodes should be atomic, while 'TripReport' nodes will be composed of 'FishingReport' nodes (because the coast guard model shows 'TripReport' as an aggregation of 'FishingReport' \0xFFFD see Figure 2).
- Specify node views for each user profile. The concept of 'point of view' allows a node to show a different subset of its information items and anchors for links, depending on the reader's profile. OO-Navigator supports the concept of NodeView to model the 'face' that a node will show for a particular point of view.
- Define access structures. Hypermedia applications usually provide different kinds of indexes that act as shortcuts to a set of nodes. These indexes may be simple lists of items or complex timelines that allow a node to be selected based on some of its attributes. An example in our application would be the index to navigate to instances of FishSpecies in a mating season using the Species' name.
- Define link classes and unclassified links. Links represent the association between two or more nodes. Link classes, meanwhile, represent the association between node classes. Link classes are derived from relationships in the object level. A link class is configured with its origin node class, its destination, cardinality of the destination (single or multiple), and the way the destination is obtained (statically defined, computed dynamically or created on activation of the link). The link class defined in this way automatically creates instances of TypedLink between the origin and destination. It is worth noting that the origin of a link is fixed at initialization time, but the destination may be computed during link activation.
After performing these steps a designer obtains a running application that combines objects derived from framework classes (we call them 'hypermedia components') with objects from the object level (domain objects). Hypermedia components control the execution of the application and forward messages to domain objects when needed. The flow of messages is the usual in object-oriented frameworks: domain objects act as information and behavior servers; hypermedia components, meanwhile, receive external events generated in the interface and either use them to activate navigation or broadcast them to the appropriate objects. When an interface widget receive an event it forwards the corresponding message to its associated node. If the widget was hypermedia-aware, the node will delegate the message to an anchor object and the anchor will communicate with its link, thus triggering navigation. If not, it will delegate the message to the object the node is 'observing'. Thus, we can easily integrate navigation with other computational behavior as nodes act as intermediate interfaces for application objects.
We have built a tool to help the designer configure the relationships between hypermedia components and domain objects (Vives et al. 1997). This tool provides facilities for 'drawing' the interface, selecting classes that will have a hypermedia 'view', creating links by 'point and click' actions, indicating the actions that have to be performed when external events are produced in the interface, etc.
3.3 Design of OO-Navigator
This section briefly reviews the most important design decisions taken to fulfill the requirements of OO-Navigator. The rationale behind this discussion is to provide the reader with a background to understand different design problems that appear while building CHAs. Each important design problem is presented together with our solution and a short explanation about the classes participating in that solution.
3.3.1 Relating application objects with hypermedia components
OO-Navigator aims to help a designer to retrofit existing OO applications, enhancing them with hypermedia functionality. Nodes are considered as an intermediate interface to application components, providing them with different faces depending on the user\0xFFFDs profile. The behavior of application components is not lost but augmented; this feature is implemented by nodes delegating any non-hypermedia event to the corresponding object in the application. In this way navigation and object behavior is integrated in a seamless way. Similarly, links are the mechanism to explore object relationships.
Nodes and links that emerge from application components follow the 'observer' mechanism of OO design. In this way, nodes not only know the object(s) they extend but also depend on them. The same thing happens with links that come from an associative object of the application, i.e. an object that represents a relationship. This 'dependency' means that any change in an application object will be reflected in the 'dependent' node or link. This relationship among nodes and objects, reflecting the observer design pattern (Gamma et al. 1995), dictates the most important architectural construct in the framework: application objects are clearly separated from nodes and nodes are decoupled from their interfaces.
3.3.2 Classifying nodes
An interesting issue arises when extending application objects that belong to the same class, i.e. they share the same behavior and structure. Nodes extending those objects should also share the same structure, interface and type of relationships. For example, all instances of the class FishSpecies should be extended by nodes that show the same structure, provide the same functionality, and have links to nodes that map the corresponding Migration objects.
An obvious solution would involve defining a class for nodes that extend objects of the same application class. For example, we would define the class FishSpeciesNode, the class MigrationNode, etc. This solution would end up in a class explosion that will be just a mirror of the underlying application class model, however. Besides, it would be impractical from the viewpoint of framework users to create so many classes when instantiating the framework.
We solved this problem by defining a class, NodeClass, the instances of which play the same role as traditional classes. In this way, for each application class that we intend to extend with hypertext functionality we will create an instance of NodeClass. In our example a possible instance would be 'fishSpecies'. This object is responsible for instantiating class Node for each different fishSpecies object, and giving each Node the structure (as an aggregation of elements) that will be used to show fish species in the CHA. Moreover, each node standing for an instance of class FishSpecies will 'know' to which instance of NodeClass it 'belongs'.
We used the same strategy with links by defining the class LinkClass. Its instances act as classes for the set of links mapping the same relationship. The solution of these problems resembles the use of the TypeObject Design Pattern (Johnson and Woolf 1997).
3.3.3 Extending an existing interface with hypermedia functionality
We have faced many applications in which it was difficult or even infeasible to completely re-engineer the user interface, replacing existing widgets with hypermedia-aware interface objects. For example, in the coast guard application existing browsers needed to be enriched in such a way that they could provide hypertext navigation.
A similar problem was solved by Microcosm (Davis et al. 1992) when dealing with third-party applications, allowing links to be defined from inside a Microsoft Word document to a Toolbook application or to a database, for example. In this case, re-engineering the interface made also no sense.
The solution to this problem in OO-Navigator comprises the class Navigator. An instance of this class acts as a 'transparent' over the node. Anchors for links are only shown on demand when the user explicitly wants to navigate. The designer may locate the anchors directly over interface widgets or as 'hot' words over a piece of text or other media.
The problems we faced while designing and implementing OO-Navigator are not exclusive to this particular system; in fact they are recurrent and appear each time a designer wants to implement hypertext functionality on top of software systems. In the same way, organizing the hypertext components and their interfaces involves different design problems that must be understood to improve the development of computational hypermedia applications.
The following section analyses the design of computational hypermedia applications with a view that is independent of the methods or tools used to develop them. We show that design experience can be recorded and reused by using design patterns.
4 Using design patterns while building CHAs
Even when using systematic methods and powerful support tools (like OOHDM and OO-Navigator), a designer must solve complex problems while building a CHA. As we have already mentioned, these problems may appear at different design stages. At the architectural level we have to design how to connect application objects to hypermedia components, and how to relate navigation with other application functionality (such as the access to databases), etc. During navigational design we must decide the extent of a node and how we relate nodes to reduce disorientation, etc. While designing the interface we must find ways to make information perceivable by conciliating different constraints such as reduced screen space, the need to present many different objects providing disparate functionality, etc.
The difference between an expert hypermedia designer and a novice is that the former uses personal experience to tackle these problems. Reusing design experience is difficult, however, because good design decisions often remain hidden in the designer\0xFFFDs mind and thus are difficult to share. Capturing and recording those alternatives and decisions is important to improve design reuse. In the hypermedia field, and more precisely when building complex computational hypermedia applications, we have found many different problems that recur and that are solved in a similar ways. This section introduces the idea of design patterns and shows their relevance for designing high quality computational hypermedia applications.
4.1 Design patterns: an introduction
Though originated in architectural design (Alexander et al. 1977), design patterns are increasingly being used in software development (Gamma et al. 1995). A design pattern systematically names, explains and evaluates an important and recurrent design in software systems. They describe problems that occur repeatedly, and describe the core of the solution to those problems, in such a way that this solution can be used many times in different contexts.
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 solves the recurrent problem in the specific context. The consequences and tradeoffs of applying the pattern are also important because they allow design alternatives to be evaluated.
In some domains such as, for example, communications or real-time systems, design problems may be more specific and therefore more specialized patterns arise (Schmidt 1995). 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. In this work we briefly describe a set of patterns that can be the basis of a pattern language for hypermedia. A first step in that direction can be found in Rossi et al. (1996), Garrido et al. (1997) and Rossi et al. (1997).
We have organized the set of patterns we found into two categories, according to the different design concerns of CHAs:
- architectural patterns
- application patterns.
4.1.1 Architectural patterns
This category encompasses design patterns that can be used to implement hypermedia functionality in software systems. Although these patterns were discovered in the context of the OO-Navigator framework , we will show that it is not difficult to apply the core of their solution in a more general context.
Architectural patterns encapsulate design experience related to the implementation of software components, providing navigation features and the way we can combine those components with other application functionality. Understanding these problems allows this architectural knowledge to be applied independently of the kind of application, platform and language being used. More general design patterns have been used repeatedly (perhaps unconsciously) in hypermedia environments. Examples of design patterns from (Gamma et al. 1995) applied in the development of hypermedia architectures are the Observer Design Pattern (used in the separation among the runtime and storage layer in the Dexter reference model (Halasz and Schwartz 1994)) or the Composite Design Pattern (used in the implementation of composites in the Devise Hypermedia Model (Gronbaek 1994)). Some new patterns in this category are presented in section 4.2.
4.1.2 Hypermedia application patterns
These patterns are meant for hypermedia application designers, regardless of the system they are using for the implementation.
Application patterns deal with the organization of content and the interface. They emphasize topological relationships among nodes, and relationships among interface objects. They can be applied to different kinds of hypermedia applications, such as interactive kiosks, Web sites and information systems, CD-ROM based catalogues, etc. In this paper we show how they can improve the design of CHAs. We have further subclassified these patterns:
- Navigational patterns help organize the navigational structure of the application in a clear and meaningful way for the intended readers. They address recurrent problems where the solution determines the degree of success of a hypermedia application. Examples include Navigational Contexts and Active Reference (see section 4.3).
- Interface patterns help the GUI designer to solve recurrent problems in hypermedia interfaces. These patterns could be also used outside hypermedia applications, in the broader context of GUI design. An example is the Information on Demand pattern (see section 4.4).
4.2 Using patterns in OO-Navigator
When designing OO-Navigator we found it useful to communicate important design decisions in the form of patterns. In this way we improved our vocabulary and, as a side effect, obtained more general solutions that can be applied in a broader context. We next present some of the most important architectural design patterns related to CHAs. To make this discussion more understandable we refer to the design problems presented in section 3.3. The problems and their solutions are quite general and can be applied in different situations.
Patterns are presented using a simplified version of the 'Alexandrian' format (Alexander et al. 1977).
4.2.1 Nodes as a navigational view
- Problem: How to add navigation capabilities to the components of an OO application, thereby adding hypermedia functionality to the application?
- Solution: Define a navigational layer between the application to be enhanced and its graphical interface, built from object observers that are called nodes. Implement the navigational behavior in nodes. Then define the GUI for each node by adding a means of activating the behavior of nodes and objects. This solution implies defining hypermedia nodes as dependent on an object or group of objects, thus separating hypertext functionality from the behavior of the application and from its interface.
- Related patterns: Navigation is performed by links (section 4.2.2) and activated by anchors (section 4.2.3). Nodes are observers (Gamma et al. 1995). Nodes are grouped in 'virtual' classes using Node-Class (section 4.2.5)
- Relevance to our work: This pattern defines the basic architectural structure of our framework because it dictates the way in which objects turn into hypermedia components and how the interaction among them takes place (section 2.2.1). The most important lesson for the field of CHAs is that defining hypertext components by decoupling them from the application objects helps in keeping the application modular and separating application behavior from navigation operations.
4.2.2 Links as a relationship view
- Problem: How to represent the relationships among the components of an application in such a way that they can be navigated?
- Solution: Define links as first-class objects; make each link represent a relationship of interest (in terms of navigation) between two or more objects, which must also have nodes as navigational views over them. Let links be responsible for the navigation process described above.
- Related patterns: Links are activated through anchors (section 4.2.3) in the origin node (section 4.2.1). Link classes are defined using the link-class pattern (section 4.2.5).
- Relevance to our work: Links connect nodes in OO-Navigator. They implement navigation by relying on relationships defined in the object model.
- Problem: How to activate links from within a node?
- Solution: Define anchors as the representation of links within a node, and make them responsible for link activation. An anchor relates a link marker to the link itself, so the link is independent of any means of activating it.
- Related patterns: Anchors activate links (section 4.2.2.) from the origin node (section 4.2.1).
- Relevance to our work: Defining anchors as separate classes allows the activation of a link to be treated with finer granularity. For example, we could define different anchor subclasses implementing different conditions for link activation. By using this pattern in CHAs, we have an interesting way to customize the hypertext functionality.
4.2.4 Navigation strategy
- Problem: How to allow static and dynamic computation of link destination to coexist in CHAs?
- Solution: Decouple links from the way their destination is obtained, defining a separate hierarchy of navigation strategies. Strategies should include: fixed endpoints, computed endpoints, dangling endpoints and lazy end-point creation (Rossi et al. 1996).
- Related patterns: This pattern is used when the link pattern (section 4.2.2) is used.
- Relevance to our work: Using this pattern we allow dynamic creation of links; in some computational applications (see e.g. Bieber and Kacmar (1995)) it is not possible to know the destination of a link in advance, so links must be created on-the-fly. Decoupling links from their end-points simplifies the link activation code.
4.2.5 Node class, link class
- Problem: How can node (and link) types be defined, according to the classes (and relationships) of an OO application that is extended with hypermedia functionality, or according to types defined by a database, thus automating or easing node creation?
- Solution: Define a class NodeClass the instances of which act as templates (classes) for nodes. Using this pattern we decouple Node from NodeClass; Node contains basic hypermedia functionality (reacting to anchor activation, for example) while instances of NodeClass act as templates for data and behavior. Make instances of NodeClass responsible for node creation. In this way nodes are automatically generated for each object of the corresponding (conceptual) class. When a new object of an application class is created, a node of the corresponding node class is created. In the same way, define LinkClass as a class the instances of which play the role of Type-Objects for instances of Link.
- Related patterns: NodeClass and LinkClass can be seen as an instantiation of the Type-Object pattern (Johnson and Woolf 1997) for the hypermedia domain. NodeClass is highly related to Node as a navigational view (section 4.1.1), and Link Class is related to Link as a relationship view (section 4.1.2).
- Relevance to our work: As explained in section 3.2.2, defining the class abstraction for nodes was essential in OO-Navigator. Mirroring the class hierarchy of the application would have resulted in a poor and difficult-to-maintain design. We solved this problem using Node Class.
4.2.6 Wrapper node
- Problem: How can we add navigational behavior to existing GUIs?
- Solution: Decorate the interface with a node wrapper. The wrapper will capture those interface actions dealing with navigation and will activate this kind of behavior, passing all other actions to the decorated interface (object). The wrapper has an associated group of wrappers for each widget in the decorated interface, such as Text Fields, List Fields, etc. Those widget wrappers are hypermedia-aware, that is, anchors for links can be defined and activated within their data. The main difference between nodes and wrapper nodes is that in the former we do not assume an existing interface, and thus their interface is built directly using hypermedia-aware widgets. While nodes as navigational views resemble the Observer design pattern, wrapper nodes resemble the Decorator design pattern (Gamma et al. 1995).
- Related patterns: Decorator (Gamma et al. 1995) and ode as a navigational view (section 4.2.1).
- Relevance to our work: Navigator nodes in our framework follow this pattern (section 3.3.3). We found this problem extremely relevant in the context of HTF because usually we struggle to make existing systems with their own interfaces hypertext aware. Wrapper nodes have been used in other systems, such as Microcosm (Davis et al. 1992), to implement navigation. The main differentiating feature of this solution is that it defines nodes explicitly, whereas Microcosm emphasizes links.
4.3 Navigation design patterns
As discussed, defining the navigational and interface structure of a hypermedia application is hard. Once we identified the recurrent problems we usually face during these design activities, however, we could record good solutions and make them available to designers. This section presents some patterns we discovered while building hypermedia applications, both stand-alone applications or more complex, computational applications. Notice that these patterns address more 'methodological' concerns than in section 4.2
4.3.1 Nodes as single units
- Problem: How do we decide the extent of a node?
- Solution: Make a node a single unit, self-contained entity of information, focused on a certain topic (Nielsen 1997). All data that is relevant for that entity should be included in the same node. When extending an OO application, we will generally map one application object to one node. Nevertheless, a whole real-world entity may usually be represented by more than one object, its information split among several objects that have to work together. In this case it is better to map all strongly related objects to the same node, if it is meaningful to see all the information together.
- Relevance to our work: When building CHAs it is important to take care on the granularity of nodes to avoid cognitive overhead. If information objects (such as Trips, Vessel, TripReports, etc.) have been correctly defined, corresponding nodes will also be well designed.
4.3.2 Link creation method
- Problem: When is it better to define static links, and when is it preferable to create links through computations?
- Solution: Static links are used in closed, static applications when maintainability in case of future change is not an issue, and when nodes are also created statically. Static links may be used in dynamic applications when the definition of a link computation is too complex, when the end-point node is difficult to change, or when the link is only temporary. Computed links should be preferred in dynamic applications where new nodes are also created dynamically, data is volatile and maintainability must be achieved efficiently. Also use dynamic links, even with statically created nodes, when it is possible to define link types (and automate link creation), and when the number of links of each type is considerable, i.e. the effort required to write a computation to create the links automatically is less than the effort to instantiate all links manually in a relationship between large sets of nodes.
- Relevance to our work: In computational applications it is impractical to define links manually and statically; relationships are often derived from relationships among objects that may change dynamically. In the coast guard example, reports about fishing are created dynamically and, in the same way, are related to an instance of the FishSpecies NodeClass.
4.3.3 Navigational context
- Problem: How to organize the navigational structure of an application, providing guidelines, information and relationships that depend on the current state of navigation?
- Motivation: Suppose we are navigating through species found in a trip report. We would want to access all such species easily. One way to achieve this would be to provide an anchor 'next' allowing us to navigate from one species to another. In the same way, when accessing each species in a report it would be reasonable to read some comment on the capture of such species during the trip. Meanwhile, we could access the same species while navigating through Fish Species in a zone; in this case going to the 'next' means something quite different, since we will be only interested in comments related to the corresponding zone. In both cases we are clearly accessing the same node, but under different contexts.
- Solution: Decouple nodes from the context in which they are to be explored, and define the peculiarities of a node as Decorators (Gamma et al. 1995) that enrich the navigational interface when the node is visited in that context. Navigational contexts are composed of a set of nodes (FishSpecies) and context links (links that connect nodes in a context). Nodes are decorated with additional information about a particular context and additional anchors for context links (Figure 6). The navigational context may also contain information about the context itself that will be shown in a context node. That node may provide an index to all nodes in the context or a link to the first one (as shown in Figure 6). Defining navigational contexts is important because they are high-level architectural constructs that help organize navigation in such a way that we can describe the navigational structure of a hypermedia application not only as a set of nodes and links but also as a set of contexts in which those nodes will be accessed. Figure 8, while explaining the information-on-demand interface pattern, shows how information in a node is enriched for a particular navigational context.
- Relevance to our work: Computational applications may involve hundreds of instances of different classes. If we want to let the user explore them easily, we should group nodes in sets following the navigational context pattern, thus allowing the same node to belong to more than one set and provide different links (and eventually information) when navigated in different contexts.
Figure 6. Fish species in a zone as a navigational context (full-size figure)
4.3.4 Active reference
- Problem: How can we 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 level of abstraction?
- Motivation: In many hypermedia applications (particularly those involving spatial or time structures) we need to provide the user with a way to understand where he or she is, and help decide where to go next. The usual solution would include an index (or other access structure) of the elements we intend the user to navigate. However, this solution will require the user to backtrack from the current node to the index or to move to another node, while ensuring that its current position is highlighted in the index. These navigational operations, moving backward to the index and forward to the target, may disorient the user, especially when there are many options at each step.
- 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). This object remains perceivable together with target objects, letting the user either explore those objects or select another related target. In this way, we will be able to interact with both the index and target nodes. Figure 7 shows an example of active reference in the context of the coast guard example. We can select a zone and a fish species in the zone and perceive the information about the species without losing the information about the zone and the set of species in that zone. 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 it available while navigating the target nodes. Figure 7 highlights two active indexes, one for zones and one for species. Notice that while exploring a species (anchovy in the example) the reader can see where he or she is (zone A1) and where to go next, e.g. selecting another species or another zone in the sea space.
Figure 7. Active reference in the coast guard system (full-size figure)
4.4 Interface patterns
User interface design is a complex task which mainly involves finding the right combination of elements (both in their number and in their spatial relations), in such a way that those elements interact for effective presentation of the information. We next present some simple but effective design patterns addressing interface problems.
4.4.1 Information on demand
- Problem: How to organize the interface so that we can make perceivable all the information in a node, taking into account both aesthetic and cognitive aspects?
- Solution: Present only a subset of the attributes, the most important ones, and let the user control which further information is presented on the screen by providing active interface objects (e.g. buttons). The activation of those buttons does not produce navigation to another node, they just cause different attributes of the same node to be shown. This strategy follows the 'What you see is what you need' principle. Figure 8 shows an example of information-on-demand for the coast guard system. Further information about the anchovy is presented to the reader when clicking the 'More' button. Notice that this information includes a reference to zone A1, i.e. the context in which the anchovy node is being accessed. As discussed, this is achieved by decorating the node with context-related information. There are considerations to take into account in this solution. Figure 8 uses a different window for showing additional information; conversely, we may use the same screen area to show different attributes. When dealing with other kind of media attributes we must analyse the situation carefully, for example, an audio recording does not use the screen; on the other hand, it may also distract the user\0xFFFDs attention, so it is wise to give the user the means to activate/deactivate it while it is being played. Other attributes will need to be synchronized, such as an animation and a recording explaining it, if they are to be perceived together.
- Related patterns: Node as a single unit (section 4.3.1), information-interaction decoupling (section 4.4.2) and behavioral grouping (section 4.4.3)
- Relevance to our work: The situation shown in Figure 8 recurs in applications in which we must show many information items for the same object (see, for example, Bieber and Kacmar (1995) for an example in the GIS area). The information-on-demand pattern helps to simplify the interface.
Figure 8. Showing additional information about a fish species (full-size figure)
4.4.2 Information-interaction decoupling
- Problem: How do you differentiate contents and various types of controls in the interface?
- Motivation: A node in a complex application displays different contents, and is related to many other nodes, thus providing many anchors. Moreover, if the node supplies in its interface other means of control activation besides navigation (see information-on-demand), the user may experience cognitive overhead. It is well known that when too many anchors are provided in a text the reader is distracted and cannot profit from all of them. For graphics, parts of them often provide some control activation that may be hard to foresee.
- Solution: Separate the input communication channels from the output channels, by grouping both sets separately. Allow the 'input interaction group' to remain fixed while 'the output group' reacts dynamically to the control activation. Within the output group, it is also convenient to differentiate the 'substantive information' (i.e. content) from the 'status information'. In the example shown in Figure 8, we consciously avoided including 'hot' words inside the text to separate what is being presented from the navigation and other kinds of controls.
- Relevance to our work: Information-interaction decoupling plays a critical role in CHAs because the information presented to the user may be obtained dynamically (either by querying a database or by performing some computations); embedding navigation controls inside a text or an image would be difficult unless the image is static (as, for example, the map of zones in Figure 8).
4.4.3 Behavioral grouping
- Problem: How to organize the different types of controls in the interface so that the user can easily understand them?
- Solution: Group control interface objects according to their functionality and make each group perceivable in a different screen area. For example, we should separate anchors for contextual navigation from those providing general controls and both groups from the one allowing the user to select which attributes are shown (see information-on-demand). Provide similar interface appearance inside each group to enhance comprehension. Figure 9 shows an example of behavioral grouping in the context of the coast guard system.
- Related patterns: Information-interaction decoupling (section 4.4.2) addresses the separation of data and control while this pattern solves the problem of grouping different kinds of controls.
- Relevance to our work: When extending computational applications with hypertext we will find many different kinds of behaviors to be triggered from the interface: general navigation controls, controls related with navigation inside a context, those dealing with the information-on-demand pattern, plus all functionality related to the underlying application functionality. Separating interface objects in groups allows the designer to make the interface more understandable to the final user.
Figure 9. Behavioral grouping in the coast guard application (full-size figure)
4.5 From patterns to applications
Navigational and interface design patterns are not used in isolation; they usually interact to produce better quality designs. As the reader may have noticed, the example we have just followed and presented in Figures 6 , 7, 8 and 9 shows how to combine different patterns for solving a particular problem and how they cooperate to get a good solution. While navigational context provides the higher-level navigational construct for organizing species in a zone, active reference let the user explore different zones and species easily. Information-on-demand prevents an excessive amount of information about each species being presented in the same screen space, while behavioral grouping helps make the functionality presented in the interface understandable.
It must be clear that previously presented patterns are independent of the methodology we are using to design a hypermedia application, and are also 'neutral' with respect to the implementation environment. However, when they are integrated with a systematic design method they can be even more powerful. For example, we have enriched the OOHDM notation by incorporating some patterns into its design primitives. For instance, navigational contexts can be described using a simple notation incorporated to the navigational design primitives.
Discovering patterns is a process that involves reflecting on existing designs, finding commonalties both in the kind of problems encountered and the solution to those problems. Once a pattern has been identified it must be formalized by using one of the existing templates for describing patterns. In our work we have found that a combination of the GOF notation (Gamma et al. 1995) with the 'Alexandrian' style is the best suited to these kind of applications. However, in some cases a more formal description of each pattern may be necessary; whereas most patterns can be described by relationship and interaction diagrams (in the style of UML (Rational Corporation 1997)), many of them are far more abstract and need a more 'natural' description. We are exploring how to make this kind of description more 'formal.
We next generalize our discussion on architectural, system-oriented patterns by analysing the problem of building CHAs from a broader perspective.
5 Summary: towards a reference architecture for HTFWe have analysed some design issues that arise when we build CHAs. We have emphasized the need for decoupling computational from navigational modules and the importance of documenting design decisions in the form of design patterns. This section outlines the main aspects of a general architecture for implementing CHAs. This architecture may be described in terms of some simple design patterns that work together to achieve this objective.
The first high-level design decision when building the HTF functionality of a software system is related to decoupling the application behavior from the hypertext features. This implies defining two different layers: one comprising the application components and the other dealing with hypertext functionality. In the context of our work, this problem is addressed by the 'node as a navigational view' design pattern. Though this pattern has been defined in the context of the OO-Navigator framework, its rationale may be applied even if we are working in a non-object-oriented environment.
The same reasoning may be applied to decoupling the navigation functionality from the interface; the relationships among interface and navigation objects also follow the Observer design pattern (Gamma et al. 1995). This separation allows us to treat both concerns separately.
Once we have decoupled the hypertext functionality from the rest of the application, we have to decide the way in which nodes and links interact with objects. Both the 'node as a navigational view' and the 'link as a relationship view' patterns address this problem: they state that nodes 'observe' application objects while links map relationships. Since we want objects and nodes to remain consistent with each other, we need to establish a 'subscribe/notify' relationship between them (Gammaet al. 1995). Each time an object changes its state, it notifies all nodes that are related to it. Moreover, changes originated in a node must be broadcast to corresponding objects. When links map relationships, we can obtain dynamic link end-points in a straightforward way.
As explained in section 3.3.3, a particular situation arises when the application to be extended (or some of its components) already has an interface. In this case the separation in three layers as discussed above is somewhat difficult. Nevertheless, it is possible to keep the separation in two layers: application (in this case the object representing the GUI), and navigational. The architectural style here is the one in the Decorator design pattern (Gamma et al. 1995).
Defining the navigation architecture leads to another set of interesting architectural problems. Though many of them have been extensively discussed in the literature (see, for example, Gronbaek (1994)), we briefly summarize them as a set of design guidelines:
- Decouple node, anchors and links. Separating these three types of hypermedia components allows, for example, to extend the functionality of each component to be extended by subclassing, i.e. we can have hierarchies of nodes, links and even anchors (Nanard and Nanard 1993).
- Decouple links from their end-points. Applying the navigation strategy design pattern, as discussed in section 4.2.4, simplifies the specification of multiple algorithms for calculating link end-points.
6 Concluding remarks
This paper has analysed the construction of computational hypermedia applications, i.e. those applications combining navigation with more traditional behavior. We have emphasized that development methodologies are important in this process because it involves many different and complex design problems. We have surveyed the object-oriented hypermedia design method (OOHDM), a systematic method for building high quality hypermedia applications. We have presented OO-Navigator, an object-oriented application framework aimed at supporting the construction of computational hypermedia applications.
We explained the role of design patterns in the construction of this kind of application, and presented several new design patterns aimed at recording design experience related to different issues in the development enterprise: architectural, navigational and interface design.
Finally, we outlined some architectural problems that must be taken into account when building computational hypermedia applications. These are general enough to be considered independently of the context in which the applications are being built, i.e. even if they are not built in an object-oriented environment or if they run in a centralized or distributed environment (the Web, for example).
We believe that developers must seriously consider the design problems we described in this paper, and that design patterns are a good vehicle for recording design experience gathered while building computational hypermedia applications. Design patterns also help novice designers to gain understanding about this domain. Higher level design and implementation structures such as software architectures and frameworks (like the OO-Navigator) should be developed in order to ease the tasks of designers and implementors in this promising area.
Bieber, M. and Vitali, F. (1997) "Toward Support for Hypermedia on the World Wide Web". IEEE Computer, Vol. 30, No. 1, January http://www.cs.unibo.it/~fabio/bio/papers/1997/IEEEC97/January/IEEEC0197.html
Carneiro, L.M.F., Coffin, M.H., Cowan, D. D. and Lucena, C.J.P. (1994) "An Experience Using Jasminum- Formalization Assisting With the Design of User Interfaces". Proceedings of the Workshop on the Software Engineering and Human-Computer Interaction: Joint Research Issues, Sorrento, Italy ftp: pub/ADV/theory/se-hci.ps.gz
Casanova, M.A., Tucherman, L., Lima, M.J., Netto,J. L. R., Rodriguez, N. and Soares, L.F.G. (1991) "The Nested Context Model for Hyperdocuments". Proceedings of Hypertext\0xFFFD91, San Antonio, TX (New York: ACM Press), pp. 193-202
Cowan, D. D. and Lucena, C. J. P. (1995) "Abstract Data Views: An Interface Specification Concept to Enhance Design for Reuse". IEEE Transactions on Software Engineering, Vol. 21, No. 3, March, 229-243
Davis, H., Hall, W., Heath, I., Hill, G. and Wilkins, R. (1992) "Towards an integrated information environment with open hypermedia systems". In Proceedings of the European Conference on Hypertext Technology (New York: ACM Press), pp. 181-190
Garrido,A., Rossi, G. and Schwabe, D. (1997) "Pattern Systems for Hypermedia". Proceedings of PLOP'97, Pattern Languages of Program Design, Allerton, IL, USA, September http://st-www.cs.uiuc.edu/users/hanmer/PLoP-97/Workshops.html
Garrido, A. and Rossi, G. (1999) "Capturing hypermedia functionality in an object-oriented framework". In Object-Oriented Application Frameworks, edited by R. Johnson and M. Fayad (John Wiley and Sons), forthcoming
Hannemann, J. and Thuring, M. (1993) "What matters in developing interfaces for hyperdocument presentation?" Workshop in Methodological Issues on the Design of Hypertext-based User Interfaces, Darmstadt, Germany, July
Nielsen, J. (1997) "Be Succinct! (Writing for the Web)". Alertbox, March 15 http://www.useit.com/alertbox/9703b.html
Rational Corporation (1997) The Unified Modelling Language http://www.rational.com/uml
Rossi, G., Schwabe, D., Lucena, C. and Cowan, D. (1995b) "An Object-Oriented Model for Designing the Human-Computer Interface of Hypermedia Applications". Proceedings of IWHD'95 (Springer-Verlag), pp. 131-152
Rossi, G., Garrido, A. and Schwabe, D. (1996) "Towards a pattern language for hypermedia applications". Proceedings of PLoP\0xFFFD96, Allerton, IL, USA http://www.cs.wustl.edu/~schmidt/PLoP-96/workshops.html
Roth, M. T. (1997) " Don't Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources". In Proceedings of VLDB\0xFFFD97 (Very Large Data Bases) http://www.almaden.ibm.com/cs/people/torkroth/
Schwabe, D. and Rossi, G. (1995a) "Building hypermedia applications as navigational views of an information base". Proceedings of the IEEE International Conference on System Sciences, Vol III, Hawaii, January, pp. 231-240
Thuring, M., Haake, J.M. and Hannemann, J. (1991) "What's ELIZA doing in the Chinese room? Incoherent hyperdocuments and how to avoid them". In Proceedings of Hypertext'91 (New York: ACM Press), pp. 161-177
Vives, F., Zanetti, P. and Garrido, A. (1997) "Adding Hypermedia Functionality to Object Oriented Applications". Fourth International Conference on Hypertexts and Hypermedia: Products, Tools, Methods, September, Paris, France, pp. 25 - 26