Design Reuse in Hypermedia Applications Development
Gustavo Rossi
LIFIA, Fat. Cs. Exactas, UNLP, Argentina and CONICET
E-mail: gustavo@sol.info.unlp.edu.ar
Daniel Schwabe
Departamento de InformAtica.
PUC-RIO, Brazil.
E-mail: schwabe@inf.puc-rio.br
Alejandra Garrido
LIFIA, Fat. Cs. Exactas,
UNLP, Argentina
E-mail: garrido@sol.info. unlp.edu.ar
Canonical PDF source: https://dl.acm.org/doi/pdf/10.1145/267437.267444
267437.267444.pdf1007.36 KB
ABSTRACT
n this paper we discuss the use of design patterns for the process of building hypermedia applications. The idea of design patterns has been recently developed, and rapidly spread outside the object-oriented community to a general audience of software developers. By using patterns it is not only possible to document design experience with a very simple and comprehensible format, but also reuse the same experience several times for different applications. We argue that the hypermedia community will take a vital step towards better designs of hypermedia applications and systems by developing a pattern language for that domain.
KEYWORDS: Design Patterns, Pattern Hypermedia Design, Navigation, Interface Languages,
1 INTRODUCTION
Hypermedia
applications are usually built from scratch, which is not surprising given the relative youth of the hypermedia market. However, the key reason of why hypermedia components are not systematically reused is that current design approaches are not effective in helping the designer to reason in terms of composition of existing hypermedia structures. In the best case, interface widgets are reused in the context of a particular implementation setting. In [8] the authors analyze different aspects of software reuse in the context of hypermedia applications. Reuse of software components and reuse of information are discussed as two broad categories in which the notion of reuse may be useful in hypermedia applications. In this paper we argue in favor of another kind of reuse: reuse of design experience.
Hypermedia
applications are usually built from scratch, which is not surprising given the relative youth of the hypermedia market. However, the key reason of why hypermedia components are not systematically reused is that current design approaches are not effective in helping the designer to reason in terms of composition of existing hypermedia structures. In the best case, interface widgets are reused in the context of a particular implementation setting. In [8] the authors analyze different aspects of software reuse in the context of hypermedia applications. Reuse of software components and reuse of information are discussed as two broad categories in which the notion of reuse may be useful in hypermedia applications. In this paper we argue in favor of another kind of reuse: reuse of design experience.
Expert hypermedia designers typically do not solve every problem from scratch. They most of the time reuse solutions that they have used previously. It is common, however, that critical design decisions made while defining for example the interaction and navigational styles of an application usually remain hidden in code or are poorly documented. Many other decisions cannot even be deduced from either code or documentation. Those are strategies kept in the skillful designer’s mind as the result of all his/her previous experiences, and used by him at a very abstract level.
It is then reasonable to say that reusability of either design experience or design structures is the most valuable kind of reuse. From the expert’s point of view, it helps communicate the decisions made, or discuss the different alternatives with the rest of the working team in a simple and accurate way. Patterns provide a new vocabulary that is shared by team members, helping them to discuss about design at an abstract level. For non-experienced designers, it becomes easier to learn quickly through the comprehensible pattern format.
Consider the question of how a hypermedia designer can guarantee that the user always has a way to understand where he is, and where he is coming from, during navigation. A possible solution for this general problem would be to build a “History” object, that is, an object that is continuously informed about user navigational movements and that can be viewed upon demand. Note that the relationships among this object and other navigational and interface objects may vary from an application to another, in the same way that we may have different ways of viewing the history. Nevertheless, the very fundamental idea remains unchanged; this is a simple example of a design pattern.
Note that in the simple example above we are not using any particular design notation (e.g., HDM [5], RMM [11] or OOHDM [18]), though such a notation may be useful for expressing in a non-ambiguous way the relationships among objects in the solution. Although there is no consensus in the hypertext community about design methods, patterns transcend this dimension because they help to capture the essential aspects of design problems and their solutions. The main intent of this paper is to motivate the hypertext community to discuss the problem and eventually produce a pattern catalogue (as [4]) in which hypermedia design experience is recorded as a set of related patterns. Reasoning about abstract design structures in terms of design patterns is a key step towards reuse of hypermedia design experience.
In the following sections we introduce design patterns and pattern languages. We then propose a classification of patterns for different hypermedia development stages and show some examples for each different category. Finally, some further work towards the definition of a pattern language for hypermedia applications is discussed.
2 A BRIEF INTRODUCTION TO DESIGN PATTERNS
Design patterns are being increasingly used in software design [4] but, as far as we know, they remain unexplored in the hypermedia field and in particular for describing hypermedia navigational and interface architectures.
As previously stated, one of the most important kinds of reuse is design reuse, and design patterns are a good means for recording design experience. A design pattern systematically names, explains and evaluates an important and recurrent design in software systems. Design patterns make it easier to reuse successful designs and architectures [4]. They describe problems that occur repeatedly, and describe the core of the solution to that problem, in such a way that we can use this solution many times in different contexts and applications [7]. It is important to emphasize that patterns are not invented, but discovered in existing software or working environments.
A design pattern is described by stating the context in which the pattern may be applied, the problem and interacting forces that bring it to life, and the collaborating elements that make up the reusable solution. These elements are described in an abstract way because patterns are like templates that can be applied in many different situations. The important elements of a pattern are the responsibilities that must be assigned to each component and the thread of collaborations among them that solve the recurrent problem in the specific context. The consequences and tradeoffs of applying the pattern are also important because they allow evaluating design alternatives.
The main advantages of the use of patterns are summarized as follows, as discussed in [16]:
Patterns enable widespread reuse of software architectures. Reusing architectures is more valuable than reusing algorithms or data structures. In the case of hypermedia applications this is obvious because it is quite difficult to reuse concrete components.
Patterns improve communication within and across software development teams as they provide a shared concise vocabulary. Using patterns the level of discourse among team members bass a higher level of abstraction. For example instead of saying: “Let us create an index for all artworks under the same theme and give the user the chance of navigating through them”, we can say: “Let us create the navigational context Artwork-by-theme”.
Patterns explicitly capture knowledge that designers use implicitly. Though expert hypermedia designers usually make good decision they do not document what problem they are solving and the rationale for that solution. In particular, design patterns are helpful for training new developers as they can learn from others’ experience.
Pattern descriptions provide a framework for recording tradeoffs and design alternatives. This complements the previous statement as we have a clear understanding for adopting a particular solution.
Despite all these and other advantages, some considerations need to be taken in order to profit better from patterns, such as: including concrete examples to help understand how to implement a pattern when it is too abstract; choosing pattern names carefully and using them consistently; carefully documenting the contexts where patterns apply or not, and using a fixed, uniform and self-explained format to communicate clearly and concisely an integrated set of patterns.
The Patterns movement began in the area of architectural design almost 20 years ago with the work of Christopher Alexander [1]. Recently, the object-oriented community has begun to discuss the subject and there is already an impressive corpus of work being developed. This work has been mainly focused on two different areas: design patterns, and pattern languages. Design patterns are general enough to solve recurrent design problems in different domains. For example, the definition of a one-to-many dependency between objects so that when one object changes its state, all its dependents are notified and updated automatically (the Observer design pattern). Another design pattern appears when defining families of algorithms, encapsulating each one and making them interchangeable (the Strategy design pattern). Patterns are now considered the very basic building blocks of a software designer’s daily work.
In some domains such as, for example, communications or real-time systems, design problems may be more specific and therefore more specialized patterns arise [16]. They are usually the basis of a pattern language: a partially ordered set of related patterns that work together in the context of a certain application domain. Pattern languages are also being constructed for shaping up complex organizations and their development processes [3]. Those are called organizational patterns. The objective of our work is to establish the basis for a pattern language for hypermedia applications. A first step in that direction may be found in [13, 14].
There is no fixed format to describe patterns, although the essential elements must always appear: name, problem, solution, consequences. Design patterns are usually found in the format proposed by [4], named the “GOF’ format (standing for Gang-Of-Four, the authors of that book). It is very complete and detailed, which makes it almost straightforward to implement them in software. The GOF format allows recording both the rationale for using the pattern in the “Motivation” section and the tradeoffs involved in its use in the “Consequences” section.
More abstract patterns, i.e., those that encompass more abstract solutions that can be implemented in many different ways, as well as organizational patterns, usually appear in the “Alexandria” format. It contains name, context, problem, solution, and related patterns [1].
Patterns in a pattern language are usually related with each other. Relationships express that some patterns usually appear together, that some complementary or exclusive.
In our approach to build a pattern language for hypermedia, we find quite difficult to construct a single interrelated pattern language, expressed with a unique format. The reason is that we are not only talking about a particular domain, but about a complete paradigm. Moreover, patterns for hypermedia are related under different design and implementation concerns; for example, should we consider the same set of patterns when we are building a hypermedia substrate and when we are designing a hypermedia application?. In the first case we should use the GOF notation [4] because the designer is dealing with a more “conventional” software design problem where objects are commonly used to implement hypermedia abstractions (See [9] for example). In the latter, meanwhile, we should use the looser “Alexandrian” format in order to give the designer greater freedom during design and implementation. This is important if we want to achieve a wide use of these patterns , since the designer may not be using an object-oriented design method (like OOHDM), or his implementation environment may combine Java objects with HTML pages, or combine Toolbook scripts with relational databases, and none of these situations should prevent the use of patterns.
We have then divided our work in different categories of patterns that we explain in the next section. The pattern language will contain clusters of related patterns in each category. We will discuss this point again in section 5.
3 PATTERN CATEGORIES
We have organized the patterns into two categories accordingly to the different dimensions of applications inside the hypermedia space, named hypermedia systems, and hypermedia application patterns. The second category is itself sub-divided according to different design concerns, as outlined in Figure 1. These categories were defined based on our experience in designing hypermedia applications and in the use of patterns.
We have organized the patterns into two categories accordingly to the different dimensions of applications inside the hypermedia space, named hypermedia systems, and hypermedia application patterns. The second category is itself sub-divided according to different design concerns, as outlined in Figure 1. These categories were defined based on our experience in designing hypermedia applications and in the use of patterns.
-Hypermedia Systems. This category encompasses design patterns that can be used to construct hypermedia systems, i.e., those environments used to build hypermedia applications. They have a specific audience: hypermedia system developers. Although these patterns were discovered in object-oriented environments, it is not difficult to apply the core of the solution to other design strategies. Examples of design patterns from [4] applied in the development of hypermedia architectures are the Observer Design Pattern (used in the separation among the run-time and Storage layer in the Dexter Reference Model [10]) or the Composite Design Pattern (used in the implementation of Composites in the Devise Hypermedia Model [9]). Examples of hypermedia patterns in this category are Navigation Observer and Navigation Strategy, described in [13]. These patterns are better described in the GOF format, as explained in the previous section.
-Hypermedia Applicatiors. These patterns are meant for hypermedia application designers, regardless of the system they are using for the implementation. For this reason, these patterns have a more abstract solution, although they do not lack accuracy in describing the elements involved and their necessary interactions. The format used for these patterns is an “Alexandrian-like” format: name, intent, problem, solution, consequences, implementation, known-uses. We have further sub-classified these patterns into navigational and interface design patterns.
-Navigational Design. Patterns in this category help in organizing the navigational structure of the application in a clear and meaningful way for the intended readers. They address recurrent problems whose solution determines the degree of success of hypermedia applications. Examples include Navigational Contexts [14] and Active Reference.
-Interface Design. The pattern language for this stage gives some guidelines for a good organization of the information, in such way that interface elements interact for an effective presentation of the data. This pattern language could be also used outside hypermedia applications, in the broader context of GUI design. An example is the Information on Demand pattern [14].
4 SOME P AlTERNS FOR HYPERMEDIA
This section presents some patterns we have found in each of the different categories presented above: one hypermedia system pattern, two navigational design patterns, and one interface pattern. For the sake of conciseness we will not discuss the patterns in full detail. Moreover, as we want to stress the importance of patterns over a particular design solution, we omit presenting their tradeoffs.
This section presents some patterns we have found in each of the different categories presented above: one hypermedia system pattern, two navigational design patterns, and one interface pattern. For the sake of conciseness we will not discuss the patterns in full detail. Moreover, as we want to stress the importance of patterns over a particular design solution, we omit presenting their tradeoffs.
4.1 Navigation Observer: A hypermedia system pattern
Intent
Decouple the navigation process from the perceivable record of the process. Navigation Observer simplifies the construction of navigation history viewers by separating the hypermedia components (nodes and links) from the objects that implement both the record of navigation and its appearance.
Decouple the navigation process from the perceivable record of the process. Navigation Observer simplifies the construction of navigation history viewers by separating the hypermedia components (nodes and links) from the objects that implement both the record of navigation and its appearance.
Motivation
As previously stated a common situation found in many hypermedia applications is the requirement to record, in a user perceptible manner. the state of the navigation. In addition, as the navigation progresses, this record is automatically updated. For example, suppose we have a hypermedia application showing European cities, through which we navigate using different access structures and relationships. We may reach the same city through different navigation paths and we want to know which cities we have already visited. This can be achieved by having a map of Europe always visible in some portion of the screen. Whenever we visit a city, it is highlighted in this map, so we can instantly know which cities we have already visited during navigation.
As previously stated a common situation found in many hypermedia applications is the requirement to record, in a user perceptible manner. the state of the navigation. In addition, as the navigation progresses, this record is automatically updated. For example, suppose we have a hypermedia application showing European cities, through which we navigate using different access structures and relationships. We may reach the same city through different navigation paths and we want to know which cities we have already visited. This can be achieved by having a map of Europe always visible in some portion of the screen. Whenever we visit a city, it is highlighted in this map, so we can instantly know which cities we have already visited during navigation.
We could implement this behavior by requiring that objects representing cities (nodes in the hypermedia application) communicate with the object representing the map with the message highlight(self). However this solution would make the existence of different perceivable records difficult, since it creates a strong dependence between nodes and viewers, and requires modifying the hypermedia components for each new type of viewer that is defined.
So/ution
The most convenient way to implement these history viewers is to use the Navigation Observer pattern. Navigation Observer is useful in order to have a perceivable record of the nodes and links visited while navigating the hypermedia space. Furthermore, it makes this record independent of them, allowing changes in its presentation style according to user needs and preferences. Consequently, the same design and interface style can be reused in different applications. Navigation Observer decouples nodes from the navigation history and the history from its interface (viewers). This allows the variation of the type of viewer or of the implementation of history without affecting nodes.
The most convenient way to implement these history viewers is to use the Navigation Observer pattern. Navigation Observer is useful in order to have a perceivable record of the nodes and links visited while navigating the hypermedia space. Furthermore, it makes this record independent of them, allowing changes in its presentation style according to user needs and preferences. Consequently, the same design and interface style can be reused in different applications. Navigation Observer decouples nodes from the navigation history and the history from its interface (viewers). This allows the variation of the type of viewer or of the implementation of history without affecting nodes.
Structure
In Figure 2, we show the structure of the Navigation Observer pattern using OMT notation [15].
In Figure 2, we show the structure of the Navigation Observer pattern using OMT notation [15].
Participants
–Hypermedia Component, such as Node and Link, implements navigation and operations for displaying itself.
–Hypermedia Component, such as Node and Link, implements navigation and operations for displaying itself.
–History records the navigation history. Different sub- classes of History may be defined for filtering different history aspects.
–Abstract Viewer implements the abstract interface for different kinds of viewers.
–Concrete Viewer implements the operation display-History according to the type of user or preferences.
Collaborations
–Each time a hypermedia component is accessed, it sends the message record to the history, sending itself and the current context as the arguments, and the history registers it correspondingly.
–Each time a hypermedia component is accessed, it sends the message record to the history, sending itself and the current context as the arguments, and the history registers it correspondingly.
–When the user wants a perceivable view of navigation, the message viewHistory is sent to an instance of the corresponding ConcreteViewer, which in turn makes the current history perceivable.
–Concrete viewers interact with hypermedia components for performing goTo operations (i.e., the navigation m a hypermedia component in the history),
Consequences
–It decouples navigation from its history and the history from a particular way of displaying it.
–It decouples navigation from its history and the history from a particular way of displaying it.
–This decoupling allows the separation of the application-specific style of viewing the history from the navigation functionality.
–Some overhead can arise when the viewer is only interest in certain types of nodes. The viewer will have to interpret the history to filter out the type of nodes of interest, possibly making use of the context reformation.
Implementation
Several issues related with the implementation of Navigation Observer are discussed below.
Several issues related with the implementation of Navigation Observer are discussed below.
l-Different algorithms fur defining the history. Though histories may be regarded as simple stacks recording each visit to a hypermedia component, sometimes it could be necessary to provide viewers with some “condensed” history. This may happen either when the same object is visited more than once or when complex backtracking in a multiple windows environment occurs [2]. One possible approach is to define a different method in History that returns the record of navigation discarding duplicates and cycles. Another approach is to add this responsibility to viewer objects that may analyze the stack as needed, with the help of contextual information..
2-Viewers and histories as access structures. We can use the interface of a history as an access structure to nodes we have visited previously. In this case we need to implement a protocol connecting the viewer with nodes, possibly using the history as a mediator object. In many hypermedia environments this kind of “goto” operation is allowed, even in cases where viewers are implemented simply as a clickable list of node labels, as implemented in Netscape Navigator.
Implementing Navigation Observer in typical hypermedia environments is usually easy. It is important to stress that even in those settings not supporting objects it is advisable to decouple nodes, histories and viewers. When it is not feasible to separate navigation objects (nodes) from interface ones, as in Asymetrix’s Toolbook™, we collapse the history and its viewer in the same Toolbook object.
Known uses
Different hypermedia products provide a way of visualizing the navigation history. For example Microsoft’s Windows Help shows the history of a help session as a list of visited topics. Similarly, in some World Wide Web viewers like Netscape Navigator it is also possible to select a location from the navigation history. Though in Netscape only a text-based list is presented, the underlying structure of the application (running as a client of the WWW server) allows using Navigation Observer for building new types of viewers.
Different hypermedia products provide a way of visualizing the navigation history. For example Microsoft’s Windows Help shows the history of a help session as a list of visited topics. Similarly, in some World Wide Web viewers like Netscape Navigator it is also possible to select a location from the navigation history. Though in Netscape only a text-based list is presented, the underlying structure of the application (running as a client of the WWW server) allows using Navigation Observer for building new types of viewers.
4.2 Navigational Contexts: a navigational design pattern
Intent
Provide the user with closed navigational subspaces containing context-related guidelines and relationships, so that information can better be presented and comprehended. The same node is also allowed to look different when perceived from within different contexts.
Provide the user with closed navigational subspaces containing context-related guidelines and relationships, so that information can better be presented and comprehended. The same node is also allowed to look different when perceived from within different contexts.
Problem
Hypermedia applications usually involve dealing with collections of nodes (e.g., Paintings, Cities, Persons, etc.). These collections may be explored in different ways, according to the task the user is performing. For example, we may want to explore Paintings of an author, Paintings on a certain subject, etc., and it is desirable to give the user different kinds of feed-back in different contexts, while allowing him to move easily from object to object within the context. From a design point of view this situation may arise for example when traversing 1-to-n links, as shown in the next example.
Hypermedia applications usually involve dealing with collections of nodes (e.g., Paintings, Cities, Persons, etc.). These collections may be explored in different ways, according to the task the user is performing. For example, we may want to explore Paintings of an author, Paintings on a certain subject, etc., and it is desirable to give the user different kinds of feed-back in different contexts, while allowing him to move easily from object to object within the context. From a design point of view this situation may arise for example when traversing 1-to-n links, as shown in the next example.
Suppose that in an application about Painters and Paintings we reach “Van Gogh”, choose to navigate to his paintings and then arrive at “Sun Flowers”. Alternatively, we can also reach “Sun Flowers” while exploring Paintings about nature. It is clear that we will explore the same object under two different perspectives; for example while accessing it as a V an Gogh’ s work, we would like to read some comments about its relationships with other paintings by him, as well as having easy access to another painting he painted. On the other hand, as a painting on nature, it would be appropriate to read (or see) something about that subject and be able to access other paintings on the same theme (perhaps not Van Gogh’s). This means that we will need not only to present the information in a different way in both cases, but also to provide different links or indexes.
The problem exemplified above uncovers some underlying potentially conflicting requirements, since we want to access the same hypermedia component under different contexts. We need to group nodes under the same context and navigate through them using contextual links. On the other hand it is impractical and it may even shield inconsistency to have different objects to represent the same component when present in each different context. Furthermore, the current context of navigation is not a concern of the node—for example it is not appropriate that a node contains contextual links because those links depend on context information.
Solution
Decouple the navigational objects from the context in which they are to be explored, and define objects’ (contextual) peculiarities as Decorators [4] that enrich the navigational interface when the object is visited in that context.
Decouple the navigational objects from the context in which they are to be explored, and define objects’ (contextual) peculiarities as Decorators [4] that enrich the navigational interface when the object is visited in that context.
Navigational Contexts provides a way of organizing navigation. Navigational Contexts are composed of a set of navigational objects, i.e., Nodes (like Paintings) and Context Links (links that connect objects in a context). Nodes are decorated with additional information about a particular context and additional anchors for context links. The navigational context may also contain information about the context itself, for example an explanation about Paintings on Nature. When nodes are organized into navigational contexts we have a simple way of navigating through the different members of the set (by means of context links), and when the same node is accessed in different contexts it can exhibit different features (attributes and links) added by the context decorator. See Figure 3.
In Figure 4 we show m instantiation of Navigational Contexts in Microsoft’s Art Gallery. The object perceived by the user is a combination of a node (“The Abduction of Helen by Paris”) and a decorator (we call it InContext object) that adds information and anchors according to the context in which the node is being visited. Note that when using this pattern our design vocabulary is enriched with higher level concepts. In fact, we can say “this object appears in context a,b,c, etc., and for each context let us define this kind of InContext objects and context links”.
Some design decisions will lead us to several sub-patterns. For example, we may want to access every node in a context from within every other node, or may want to restrict navigation in such a way that we provide an index to the members of a context and we can only reach such nodes starting from the index but not from other nodes. When solving these design problems we can state the solution in an abstract, application-independent way and write it as a pattern, thus allowing others to share our expertise.
Implementation
Navigational contexts can be easily implemented in hypermedia environments, even those not supporting full object-orientation. However, we may have to take into account features of the implementation environment; for example when using Toolbook we can use groups to organize information that will only be meaningful only in a context and a script openInContext which manipulates the corresponding group. In the WWW things are more difficult; we can choose to statically generate all possibilities by concatenating the decorator object and the decorated one for each decorator/decorated pair or build the corresponding page dynamically.
Navigational contexts can be easily implemented in hypermedia environments, even those not supporting full object-orientation. However, we may have to take into account features of the implementation environment; for example when using Toolbook we can use groups to organize information that will only be meaningful only in a context and a script openInContext which manipulates the corresponding group. In the WWW things are more difficult; we can choose to statically generate all possibilities by concatenating the decorator object and the decorated one for each decorator/decorated pair or build the corresponding page dynamically.
Known uses
Navigational Contexts has been used in many successful hypermedia applications. For example in Microsoft’s Art Gallery, paintings of the London National Gallery are presented in different contexts: by place, period and subject; some anchors are used as decorators and allow accessing the next and previous painting in each context. In Portinari Project [12, 18], a collection of most important painting of Brazilian painter Candido Portinari, different families of navigational contexts have been defined: for example for each technique we can reach all paintings painted with that technique, for each Painting we can explore documents related with that painting, etc..
Navigational Contexts has been used in many successful hypermedia applications. For example in Microsoft’s Art Gallery, paintings of the London National Gallery are presented in different contexts: by place, period and subject; some anchors are used as decorators and allow accessing the next and previous painting in each context. In Portinari Project [12, 18], a collection of most important painting of Brazilian painter Candido Portinari, different families of navigational contexts have been defined: for example for each technique we can reach all paintings painted with that technique, for each Painting we can explore documents related with that painting, etc..
In Dorling Kindersley’ s The Way Thing Works it is possible to access machines either from an index or according to a physical principle.
In [6] Navigational Contexts are called “Collections” and the authors propose adding them as primitives in the Dexter Reference Model. In OOHDM we use Navigational Context as a design concept. This is an interesting use of a design pattern as a way to provide higher level design primitives to the hypermedia designer.
4.3 ACTIVE REFERENCE: A NAVIGATIONAL DESIGN PATTERN FOR MONITORING NAVIGATION
Intent
Provide a perceivable and permanent reference about the current status of navigation, combining an orientation tool with an easy way to navigate to a set of related nodes, at the same or higher status level.
Provide a perceivable and permanent reference about the current status of navigation, combining an orientation tool with an easy way to navigate to a set of related nodes, at the same or higher status level.
Problem
In many hypermedia applications involving spatial or time structures) we need to provide the reader with a way to understand where he is and help him decide where to go next. The usual solution would include an index (or other access structure) to the elements we intend the user to navigate. However, this solution will require the user to backtrack from the current node to the index to see where he is or to move to another node, while ensuring that its current position is highlighted in the index; see for example Art Gallery’s Historical Atlas.
In many hypermedia applications involving spatial or time structures) we need to provide the reader with a way to understand where he is and help him decide where to go next. The usual solution would include an index (or other access structure) to the elements we intend the user to navigate. However, this solution will require the user to backtrack from the current node to the index to see where he is or to move to another node, while ensuring that its current position is highlighted in the index; see for example Art Gallery’s Historical Atlas.
Solution
A good solution is to maintain an active and perceivable navigational object acting as an index for other navigational objects (either nodes or subindexes). In this way we will be able to interact with both the index and the target nodes. In Figure 5 we show the way in which this pattern has been used in Le Louvre™.
A good solution is to maintain an active and perceivable navigational object acting as an index for other navigational objects (either nodes or subindexes). In this way we will be able to interact with both the index and the target nodes. In Figure 5 we show the way in which this pattern has been used in Le Louvre™.
As we can see in Figure 5, the reader has a permanent reference about where he is located while he explores the museum. In particular he can choose to go to another region or room in the region. He can learn more about a particular region (the Interface Pattern Information on Demand is used to provide this information). It is very interesting in this example that the same pattern is applied twice in the same navigational structure.
When we use Active Reference the reader has a perceivable and permanent record about the current status of navigation and, in this way, we not only provide an orientation tool but also make them available while navigating the target nodes.
Consequences
When using Active Reference, the reader has a permanent feeling about where he is in the hyperspace and at the same time he can choose where to move next. Another interesting consequence is that since we are emphasizing location we may block the view of some content because of overlap of information on the screen. Notice that in the previous example the location of the room is highlighted over the room itself. Since deciding how to simultaneously show both navigational objects is an interface concern we do not discuss it further. The Information on Demand pattern can be used to accommodate information with a scarce interface space.
When using Active Reference, the reader has a permanent feeling about where he is in the hyperspace and at the same time he can choose where to move next. Another interesting consequence is that since we are emphasizing location we may block the view of some content because of overlap of information on the screen. Notice that in the previous example the location of the room is highlighted over the room itself. Since deciding how to simultaneously show both navigational objects is an interface concern we do not discuss it further. The Information on Demand pattern can be used to accommodate information with a scarce interface space.
Implementation
The implementation of this pattern will depend highly on the support and flexibility over the graphical interface provided by the environment. For instance, it depends on the kind of hypermedia-aware widgets that allow anchor definition. It also depends, for example, on available layering mechanisms in the implementation environment,
The implementation of this pattern will depend highly on the support and flexibility over the graphical interface provided by the environment. For instance, it depends on the kind of hypermedia-aware widgets that allow anchor definition. It also depends, for example, on available layering mechanisms in the implementation environment,
Known usesActive Reference has been used in many hypermedia applications. In Microsoft’s “Ultimate Frank Lloyd Wright” it has been applied to show his buildings in different states in the USA. It is possible to see all the works together with an active map showing where it is located and a list of other works in the same state.
In Microsoft’s Multimedia Beethoven we can access an active reference of the 9Th. symphony allowing us to select different movements and listen to them; we can also select another without needing to backtrack to an index.
In Grolier’s Encyclopedia Active Reference is used in a simpler but equally effective way. The reader has permanent access to a dictionary and to nodes accessed from the dictionary.
4.4 Information on Demand: an interface design pattern
Intent
Organize the information presented to the reader in a legible and comprehensible interface, by letting him decide which items he wants to see further described in the context of the same node. Prevent cognitive overhead.
Organize the information presented to the reader in a legible and comprehensible interface, by letting him decide which items he wants to see further described in the context of the same node. Prevent cognitive overhead.
Problem
Designers usually find themselves struggling to decide how to show the attributes and anchors of a node in such a way that both esthetic and cognitive aspects are taken into account. Unfortunately, the screen is usually smaller than what is needed and many times one cannot make use of other media (such as simultaneously playing an audio track and showing an image), either for technological or cognitive reasons.
Designers usually find themselves struggling to decide how to show the attributes and anchors of a node in such a way that both esthetic and cognitive aspects are taken into account. Unfortunately, the screen is usually smaller than what is needed and many times one cannot make use of other media (such as simultaneously playing an audio track and showing an image), either for technological or cognitive reasons.
When a node has a lot of information to be displayed we could define more than one page for the same node or use scrolling, but oftentimes this alternative does not yield an acceptable solution. Another alternative is to partition the node in such a way that we can use different windows for presenting the information, defining links among these new nodes. The problems with this solution are: first, in our attempt to match design with an implementation issue, we may define an attribute of a node as a separate entity, and in doing so we will end up distorting the application’s navigational structure. Consequently, the user will get the impression of dealing with multiple entities, becoming disoriented, while in fact he is accessing another part of the same conceptual entity.
Solution
Select the most important node’s attributes (including anchors) and make them perceivable in the interface. Provide a set of active interface objects (such as buttons) to let the user select other information to be shown. Use the same screen area to display different attributes. In Figure 6, taken from Le Louvre, we see an example of the use of this design pattern. Paintings have many attributes to be shown but not all of them are shown at the same time. In Figure 6.a we show which interface objets control the information displayed to the user. In Figure 6.b we show another “view” of the same node in which other attributes are displayed.
Select the most important node’s attributes (including anchors) and make them perceivable in the interface. Provide a set of active interface objects (such as buttons) to let the user select other information to be shown. Use the same screen area to display different attributes. In Figure 6, taken from Le Louvre, we see an example of the use of this design pattern. Paintings have many attributes to be shown but not all of them are shown at the same time. In Figure 6.a we show which interface objets control the information displayed to the user. In Figure 6.b we show another “view” of the same node in which other attributes are displayed.
Consequences
The Interface on Demand pattern raises an interesting discussion about what is navigation and what is an interface effect, i.e., when we navigate to another object and when we are just changing the appearance of the same navigational object. This issue is interesting as it helps us to find “good’ navigational objects by abstracting the way in which they are to be shown to the final user. In OOHDM, for example, we clearly separate navigational design from the design of the interface. In this way we can reason about navigation without considering further interface problems. In the example above we can model Paintings as objects containing information and anchors that do not need to be perceived at the same time (like a zoomed painting view or the textual information). Another interesting issue that arises when using Information on Demand has to do with providing cues about what we will get when demanding some additional information..
The Interface on Demand pattern raises an interesting discussion about what is navigation and what is an interface effect, i.e., when we navigate to another object and when we are just changing the appearance of the same navigational object. This issue is interesting as it helps us to find “good’ navigational objects by abstracting the way in which they are to be shown to the final user. In OOHDM, for example, we clearly separate navigational design from the design of the interface. In this way we can reason about navigation without considering further interface problems. In the example above we can model Paintings as objects containing information and anchors that do not need to be perceived at the same time (like a zoomed painting view or the textual information). Another interesting issue that arises when using Information on Demand has to do with providing cues about what we will get when demanding some additional information..
Implementation
When implementing information by demand we have to take into account some features of the supporting environment. While in Toolbook it is possible to easily implement the kind of interface effect that is usual in this pattern, when building web sites the solution is less obvious. In the web, we can implement a local scrolling effect, or choose to use frames and use a new window for each item of information presented. This last solution has some navigational problems because in fact we are activating another (sub) node.
When implementing information by demand we have to take into account some features of the supporting environment. While in Toolbook it is possible to easily implement the kind of interface effect that is usual in this pattern, when building web sites the solution is less obvious. In the web, we can implement a local scrolling effect, or choose to use frames and use a new window for each item of information presented. This last solution has some navigational problems because in fact we are activating another (sub) node.
Known uses
Information on demand has been widely used in different hypermedia applications. In Microsoft’s Art Gallery it is used to provide further reading about a Painting. When you click the “See Also” button you get a set of related issues that are in fact attributes of the current painting representing anchors to the desired information.
Information on demand has been widely used in different hypermedia applications. In Microsoft’s Art Gallery it is used to provide further reading about a Painting. When you click the “See Also” button you get a set of related issues that are in fact attributes of the current painting representing anchors to the desired information.
In the Passage to Vietnam CD ROM, Interface on Demand is applied to let the user read further information about a photograph. In this application the pattern is used not because screen space is scarce but because the authors do not want to “pollute” the (beautiful) photograph with textual information.
5 FURTHER WORK
We have presented the concept of design patterns and have shown how to apply the principles behind patterns to hypermedia design. We have also shown some simple but powerful design patterns: Navigation Observer, Navigational Contexts, Active Reference and Interface on Demand solving recurrent problems both for designers of hypermedia systems and hypermedia applications both at the navigational and interface level.
This research is part of our work on object-oriented hypermedia design using OOHDM. Though the very idea of patterns is somewhat independent of the method being used, it is clear that the underlying design framework has influenced our work. In particular, as OOHDM clearly separates conceptual, navigational and abstract interface design we have a first criteria to classify patterns according to the design activity in which they participate. For example we have identified many patterns at the navigational level, such as Navigation Strategy [13] and at the interface level such as Information on Demand and Interface Groups [14]. We strongly believe that discovering new patterns in well-designed hypermedia applications is a rewarding task as it increases the degree of expertise we, as a community, can share and transmit to others. The process of finding new patterns involves analyzing successful applications and reverse-architecting its underlying design structure [19]. In this case the focus is not only analyzing the application as in [7] but also discovering recurrent problems and the way they have been solved. It is not surprising that good applications apply a set of principles that can be systematized as patterns. Many of them are usually hidden in the particular instantiation of the problem so we must abstract from particular application details in order to come up with a general expression of the problem and its solution. Analyzing how we can implement the pattern in different hypermedia environments is quite important if we want our work to result profitable to others.
We are currently working in the definition of a Pattern Language, i.e. a set of design patterns that can be used together to end-up with well-designed, usable hypermedia applications. This language will consider two outstanding design concerns: the development of software support for achieving hypermedia behavior—we call this level hypermedia system level—and the one faced by designers when using hypermedia primitives to build high level, usable applications—the hypermedia applications level. Moreover, the pattern language may contain more specific “sub-languages” that deal with either particular design aspects such as navigation or interface or with more specialized applications like “information kiosks”. Though the field is rather new we believe several pattern languages will surely arise from our effort.
There is a growing agreement that a new generation of computer applications using hypermedia is now emerging. In applications combining navigation with more “conventional” behavior we will find many recurrent design problems that we, as a community, have already solved. The pattern language expresses this collective expertise.
ACKNOWLEDGMENTS
We wish to thank the anonymous reviewers for their valuable comments on the paper, which greatly helped to improve it.
Daniel Schwabe is partially supported by CNPq—Conselho National de Desenvolvimento Cientifico e Tecnológico, Brazil.
REFERENCES
1. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel: “A Pattern Language”. Oxford University Press, New Y ork 1977.
2. Bieber and J. Wang: “Backtracking in a multiple window environment”. Proceedings of ECHT’94, Edinburgh, September 1994, pp. 158-166.
3. Coplien. “A Generative Development-Process Pattern Language”, Pattern Languages of Programs 1, Johnson and Cunningham eds., Addison Wesley, 1995.
4. Gamma, R. Helm, R. Johnson and J. Vlissides: “Design Patterns: Elements of reusable object-oriented software”, Addison Wesley, 1995.
5. Garzotto, D. Schwabe, D. and P. Paolini: “HDM - A Model Based Approach to Hypermedia Application Design”. ACM Transactions on information Systems, 11 (1), Jan. 1993, pp. 1-26.
6. Garzotto, L. Mainetti, L. and P. Paolini: “Adding Multimedia Collections to the Dexter Model”. In Proc. ECHT’94-ACM Conference on Hypermedia Technology. Edinburgh, UK, Sept. 1994.
7. Garzotto, L. Mainetti and P. Paolini: “Hypermedia Design, Analysis and Evaluation Issues”, Comm. ACM, August 1995, pp. 74-86.
8. Garzotto, L. Mainetti and Paolo Paolini: “Information reuse in hypermedia applications”. Proceedings of Hypertext’96, Washington, 1996, pp. 93-104.
9. Gronbaek: “Composites in a Dexter-Based Hypermedia framework”. Proceedings of the ACM European Conference on Hypertext, (ECHT94), Edinburgh 1994, pp. 59-69.
10. Halasz F. and Schwartz, M.: “The Dexter Hypertext Reference Model”. Comm., of the ACM, February 1994, pp. 30-39.
11. Izakowitz, E. Stohr and P. Balasubramaniam: “RMM: A methodology for structured hypermedia design”. Comm. of the ACM, October 1995, pp. 34-44.
12. Lanzelotte, R.S.G.; M.P Marques, M.C,G. Penna, J.C. Portinari, I.D. Ruiz and D. Schwabe: “The Portinari Project: Science and Art team up together to help cultural projects”. Proceedings of the 2nd International Conference on Hypermedia and Interactivity in Museums (ICHIM’ 93), Cambridge, UK, September 199
13. Rossi, A. Garrido and S. Carvalho: “Design Patterns for Object-Oriented Hypermedia Applications”. Pattern Languages of Programs 2, Vlissides, Coplien and Kerth eds., Addison Wesley, 1996.
14. Rossi, D. Schwabe and A. Garrido: “Towards a Pattern Language for Hypermedia Applications”. Proceedings of the 3rd. Annual Conference on Pattern Languages of Programs, Monticello, Illinois, September 1996.
15. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W .Lorensen: “Object Oriented Modeling and Design”, Prentice Hall Inc. 1991.
16.Schmidt: “Using Design Patterns to develop reusable object-oriented communication software” Comm of the ACM, October 1995, 38(10), pp. 65-74.
17. Schwabe and G. Rossi: The Object-Oriented Hypermedia Design Model. Communications of the ACM, August 1995, pp. 45-46.
18. Schwabe, G. Rossi and S. Barbosa: “Systematic Hypermedia Design with OOHDM”. Proceedings of the ACM International Conference on Hypertext (Hypertext’96), Washington, March 1996.
19. Vlissides, J. Reverse architecture. Position paper for the Software Architecture Seminar, Daghstul, Germany, 1995 (available at http://st.cs.uiuc.edu/pub/patterns/papers/revarch.ps).
Permission to make digital/hard copies of all or part of this material for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear and notice is given that copyright is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers or to distribute to lists, require specific permission and/or fee.
Hypertext 97, Southampton UK
© 1997 ACM 0-89791-866-5...$3.50
[Source: Gustavo Rossi, Daniel Schwabe, and Alejandra Garrido. 1997. Design Reuse in Hypermedia Applications Development. In Proceedings of the Eighth ACM Conference on Hypertext (Southampton, UK) (HYPERTEXT ’97). Association for Computing Machinery, New York, NY, USA, 57–66. https://doi.org/10.1145/267437.267444.]
Containing:ABSTRACT2 A BRIEF INTRODUCTION TO DESIGN PATTERNS4.2 Navigational Contexts: a navigational design pattern 4.3 ACTIVE REFERENCE: A NAVIGATIONAL DESIGN PATTERN FOR MONITORING NAVIGATION4.4 Information on Demand: an interface design pattern 5 FURTHER WORKACKNOWLEDGMENTSREFERENCES
Published:8 mo. ago Friday, February 2nd, 2024
Author:
Z
z6MkqhcT...bjR3zNQbFirst Version
Powered by Mintter + The Hypermedia Protocol