Visual specification of adaptive hypermedia

Toni Alatalo, Harri Oinas-Kukkonen, Janne Peräaho
Department of information processing sciences
University of Oulu

[email protected]
[email protected]
[email protected]

1. Introduction
2. Background
- 2.1. Hypermedia modelling
- 2.2. Adaptive hypermedia
3. The modelling method
4. Discussion and conclusions
References
Notes

Abstract

This paper presents a technique for modelling adaptivity in hypermedia design specifications. The technique complements existing methods, such as OOHDM, which lack means for visualizing adaptivity in the design diagrams. The solution is to modify the meaning of standard UML association classes to specify conditions in the relationships in the static class diagrams, resulting in different hypermedia content / structure based on e.g. properties of the individual user or the usage context. Examples illustrate how the method has been used to model both user adaptivity (personalization) and adaptivity to time and place (contextuality in mobile use). Combined use of the static structural diagrams featured here with the alternative behavioral state diagrams, and experiences from more complex systems, is expected from future research.

1. Introduction

Several methods for modelling hypermedia have been proposed, such as OOHDM by Schwabe and Rossi (1998), OO-HMethod by Gómez et al. (2000) and a OOHDM-compliant UML extension by Hennicker and Koch (2000). Typically these feature modelling the hypermedia system using class diagrams, which give a static model of the system. Furthermore, the adaptive hypermedia design method (AHDM) by Koch (1998) includes designing user models within the design process. Also, OOHDM has been extended to support designing personalized applications in Rossi et al. (2001). However, none of these methods have means for visually modelling the adaptivity of content and structure. For that purpose, an approach utilizing state charts instead of class diagrams has been proposed by Dolog and Bieliková (2002a). They argue that state diagrams are better suited than structural modelling especially for personalized or adaptive hypermedia (Dolog and Bieliková 2002b). Here we describe how adaptive hypermedia designs for similar purposes can be visualized in static / structural class diagrams too, as has been drafted earlier in Alatalo and Peräaho (2001a; 2001b). The aim is to base the evaluation of the applicability of both approaches in more complex and real-world systems, and their possible combined uses, in future works.

Adaptive systems can be very complex, and designing a successful use experience can be tricky. The goal here is to achieve a concise visual representation of how the adaptation logically occurs, to aid in seeing alternative solutions and managing the overall design.

The rest of this publication is structured as follows: in the next chapter a short overview of hypermedia modelling and adaptive hypermedia is given. Then in chapter three the technique for modelling adaptivity in class diagrams is presented, demonstrating it with two different kind of examples. Concluding discussion is presented in chapter 4.

2. Background

Here brief overviews to the two main branches of underlying research are given -- namely to hypermedia modelling and adaptive hypermedia -- focusing on how they are applied in this work.

2.1. Hypermedia modelling

This work is based on the well-known principle of separation of content and views in the hypermedia models, such as the object-oriented hypermedia development model OOHDM (Schwabe and Rossi 1998). That means that in hypermedia systems designed according to that principle the underlying content and functionality of the system are separated from how the information is viewed and through what kind of user interface the functionality is provided. Thereby different views and interfaces to the same system can be made for e.g. different users, devices or usage contexts. In OOHDM, the levels of design are: (Schwabe and Rossi 1998)

Conceptual Design: models the semantics of the application domain

contains all the information and functionality in the system
there is only a single one for the whole system
can be thought of as the database / class library design

Navigational Design: takes into accound user profiles and tasks

here classes are hypermedia nodes, which define views to the underlying information and functionality (can be thought of as database queries)
several navigational designs can be made to suite different needs

User Interface Design: perceivable objects, layout

Here the focus is on navigational design, and specifically how to model adaptivity in a single navigational class diagram so that it is different for different users or in different contexts.

2.2. Adaptive hypermedia

De Bra, Eklund et al. (1999) define adaptive hypermedia as a collection of nodes and links, accompanied by user profiles used to adapt the presentation. Also Brusilovsky (1996) specifies having a user model as the criteria for a hypermedia system to be adaptive. In our research, we have approached the issue in a more general way. While adapting to users is certainly central in many applications, in our view it is not all there is to adaptivity. For example in mobile usage the use context, e.g. time and place, are common factors to adapt to. Of course those can be seen as the properties of the user too, but as they may well be used without having any personal information about the user, it may be misleading to think of them as parts of a user profile. Thus here adaptive hypermedia is understood as hypermedia that is adaptive respect to something, depending on the application domain.

Also, one of us has sketched a framework which separates between adapting to difference (e.g. to different users, devices or usage places or times-of-day) and adapting to change (i.e. changes in the whole system due to e.g. changes in the requirements as time passes). The work here addresses the former type (difference adaptivity), and may not apply to the latter type (change adaptivity), which is covered in e.g. Truex et al. (1999). Interestingly, Bieliková and Habala (2004) have presented an approach for time-based adaptation in adaptive hypermedia systems, also supporting domain model changes. In this paper, the latter of the two examples features time constrained adaptation based on the time of the day, which is correctly mentioned by Bieliková and Habala (2004) as an example of time-based adaptivity. However, that is difference adaptivity, and not adapting to changing requirements: it is about a different time of the day, but in the same way every day, and not about the emergence of new requirements and features as time passes. So a more detailed analysis of adaptivity to change is outside the scope of this work.

Regarding the techniques for adaptive hypermedia, Brusilovsky (2001) presents a variety of tools for both adaptive navigation and presentation. The work here is orthogonal to the specific techniques in the sense that what we present is a way to specify conditions in the design diagrams, and hence the range of possible adaptation techniques is defined by what and how the actual design method (e.g. OOHDM) specifies content and navigation. For example, conditional inclusion of text fragments in a node is supported when using this technique with OOHDM, because OOHDM models nodes as navigational classes, and UML class diagrams feature composition/aggregation as a relation type, hence enabling specifying them conditionally.

3. The modelling method

Here the modelling method is presented by first describing the general ideas and then illustrating the use with two examples. The first example features personalization (a user-adaptive system) and content adaptivity, whereas the latter adapts to the location and time of use, resulting in different navigational behaviour. The purpose of the examples is not to be new outstanding innovations in hypermedia design, but they were selected more as typical examples of basic adaptive hypermedia in order to demonstrate the method.

3.1. The metamodel: capturing adaptation heuristics

From the point of view of adaptation, we see systems having components in different roles: a) things to which other things adapt, and b) the things that adapt. Furthermore, there are rules which define how the adaptation goes. For example in a personalized system, things to which other things adapt (group a) are typically properties of the user profile. So in the design of adaptivity the first basic step is to identify these components. What is more, we propose identifying the rules for adaptation as a kind of rulesets, or what we call heuristics, and defining them preferably as capturing some meaningful high-level concept. This is to make the actual design of e.g. adaptive navigational diagrams more powerful, as will be demonstrated in the examples in the next part. Particularly we advocate the use of UML stereotypes, possibly with accompanying graphic symbols, for depicting the different kind of adaptation rules.

In the actual design diagrams, the proposed method utilizes the standard UML association classes, which are normally used to provide additional information about associations, to specify conditions for the existence of the association (or any other relation type in the class diagrams).

3.2. Example 1: user-based adaptation

First, let's examine a user-adaptive system. In this case, the system contains articles (publications) concerning a research project, which should be available in different degrees for different users. So in the conceptual model there must be at least two classes, Publication and User. For designing the adaptivity, it is recognized that the User class is something to which the views of the Publication information adapt.

Figure 1. The conceptual schema of the user-based adaptation example.

Based on the (here imaginary) requirements specifications, it is identified that there are three different classes of users with different needs: 1. financiers, 2. researchers and 3. the press. Of these researchers need access to the full contents of the articles, but there is a need to restrict access to project members only. So there are two kind of adaptation rules: one based on the role of the user, and another based on the security classification.

Figure 2. The role and security classification based adaptation rules.

This enables us to specify a user-adaptive view of the publications, where different summaries of the work are given to press and financiers, an abstract is shown to any researcher, and full contents are shown for the ones who are project (here: OWLA) members.

Figure 3. A navigational class (i.e. a hypermedia node) that is different for different users. The details of the rules can be hidden in this high-level view.

3.3. Example 2: Time- and location-based adaptation

In another example, let's consider mobile usage (e.g. by using a mobile phone or a PDA). The application is a restaurant information system, which has basic information about the various places, including end-user ratings, and also more elaborate reviews of them. Here we have two use cases: 1. A mobile user is hungry, and does not know where to go to eat, so he/she needs to find a place that can satisfy the hunger soon enough but with an adequate quality too. 2. A mobile user is standing by a foodplace, wondering whether it's a nice one - not necessarily being hungry right now, but perhaps trying to decide about going there some time later - and would like to have more information about the place.

Figure 4. Two different cases for mobile use of the food place information system.

As a solution to these needs, we see that the system needs to be sensitive to time and place, but not necessarily to any personal information. For the use case 1, where the user is hungry, the system needs to know which restaurants are open at the time of the query, and also which of them are near enough for the user to go to. The opening and closing times of a place, and obviously the location of the place, are hence necessary properties of the restaurant/place objects. The views to the information will adapt to the combinations of the current time & location of the user, and the opening times and locations of the restaurants. There is, however, no information of the users in the system -- just the time & place of usage in the query. Therefore, the system is in a way adaptive to the relevant properties of the restaurants. How exactly that is designed is described in the following.

In the first scenario, we decided to recommend food places based on availability. Earlier we recognized that FoodPlace objects hold all the relevant information, including reviews, opening and closing times, and location which are needed for making recommendation. To satisfy the needs set by the first use case, one should determine if a food place is currently open and if it is reasonably near. In addition food places need to be ordered by their reviews. We create two heuristics: Open, which determines if food place is currently open, and Near, which determines if a food place is near the user requesting recommendation.

In the second use case, the system should display information about the food place whereby the requesting user is now. For this purpose we create a heuristic AtDoor.

Figure 5. The three adaptation rules compare values of the usage setting, namely time and place, with the properties of the food places.

With these heuristics specified, we now have the tools to make an illustrative navigational design diagram. Here, instead of OOHDM, we decided to use an alternative notation by Hennicker and Koch (2000). In the resulting navigational structure model, which corresponds to the context diagram in OOHDM, two ways to access food place information are specified to satisfy the use cases.

First there is an index called RecommendedFoorPlaces, which is shown when the user is not by any place (which is probable when he/she has no idea about where to eat). This index shows basic information of up to ten individual places, but only ones that are open, and sorted by proximity (nearness). The individual items are also links to full information about that particular place.

Alternatively, when the user is right by some place, it is assumed that information about that place is wanted and the system shows it immediatelly -- no matter whether it is open or closed.

Figure 6. The navigational structure diagram of the mobile food place information service.

For a full description of this design, which is actually based on an existing real system that is in use, see Alatalo and Peräaho (2001b).

Some remarks of the use of the modelling technique in the navigational structure diagram in figure 6 are in place. The so-called 'AtDoor' associative classes, specifying the alternative transitions resulting from the initial query, are simple Boolean conditions as usual using this technique. But the more complex specification of the link from index 'RecommendedFoorPlaces' to the individual place information views demonstrates a different kind of use. First, there two rules are combined, simply connecting them with an 'and' statement. Also, the keyword 'by' is used to note that the rule is used to select a subset of results from a larger set. The cardinality of the relationship (1..10) specifies that up to 10 can be shown in the index (the limitations of mobile devices were the basis of this design decision). Just by looking at the specification, it is ambiguous whether the results are sorted by nearness, or if the ones that satisfy the conditions are in an arbitary order. In fact, it is also not a trivial decision from a user point of view either: it may not be wise to exclude an otherwise fit place if it's a bit further away than others, if it's still near enough. For the sorting the rule for 'nearness' should return a non-boolean value, e.g. a decimal number from 0-1, like in fuzzy logic. More definite specification of such advanced techniques for this method are to be investigated in future research. In that it should be kept in mind how normal OOHDM context diagrams also use the keyword 'by' similarly for ordering of items in views (Schwabe and Rossi 1998).

4. Discussion and conclusions

A method for modelling adaptivity in hypermedia design diagrams was presented. Unlike an alternative approach by Dolog and Bieloková (2002a; 2002b), which advocates the use of behavioral models / state diagrams, the method presented here can be applied with the more typical structural diagrams of existing hypermedia modelling methods. Also, to complement such approaches for designing personalization as Rossi et al. (2001) and Koch (1998), the method presents a technique for visualizing the adaptivity in the design diagrams. By capturing underlying adaptation rules under higher-level concepts, such as nearness, the resulting overall e.g. navigational diagrams can achieve promising expressiveness and clarity.

However, there are areas where the presented method currently falls short. For example, Dolog and Bieloková (2002a) present a case where the user model used in the adaptation is updated after certain navigation has happened. The technique there is to specify link transitions with three parameters: received event, guard and effect (action expression). In that case, the guard condition is related to the user knowledge of a certain topic, which is followed by two actions: displaying related information and updating the level of knowledge in the user model. We have presented no alternative technique for such purposes. Perhaps the way to address this in future work would be to explore ways of using both techniques together -- structural views for higher-level overviews, capturing specifics of the interactions in more detailed statecharts. Also Dolog and Bieloková (2002b) argue for the usefulness of static diagrams too. Concrete examples of combined uses, and especially experience from applying these methods in complex real-world systems, are greatly needed and hopefully resulting from future research.

Another interesting area of future work would be tool development for modelling adaptivity. For example to support this method here a UML class diagram modelling tool could be modified to support conditional relations, so that example values could be given to the components that the system is adaptive to, and the resulting diagram would show.