What This Thesis is Not About

Guide to The Thesis

First, in chapter two, a background to adaptive systems is given. Various aspects of adaptive systems, like what can be modelled of the user’s characteristics, how to represent the model, how to adapt the interaction, etc., are discussed. In particular adaptive hypermedia systems are described. Finally, POP is characterised in terms of this classification. The purpose of this chapter is to make the reader aware of the various dimensions of adaptive systems that have to be considered when a design process starts. The reader who is already familiar with adaptive systems can skip this chapter entirely.

For the sake of clarity of presentation, the presentation of POP is divided into four parts: knowledge acquisition / design / implementation / and evaluation / even if these were in reality intermingled. Unfortunately this means that explanations of certain aspects of POP will be repeated – the advantage is that it should be possible to read each chapter without having read the previous ones.

In chapter three where the knowledge acquisition is described, a short introduction to the particular domain studied, SDP, and the project PUSH are provided, and then we turn to the empirical studies that preceded the design. Our perspective is to make these studies serve as a source of inspiration for the design, not as a prescription for exactly how the system should work. The chapter starts by describing our method for knowledge acquisition and its basis in other methods for task analysis and knowledge acquisition, before the four different studies performed on different aspects of users’ needs and understanding of the SDP domain are described.

In chapter four, we come to the design of our hypermedia system, POP. The target domain for our system was an object-oriented software development method, SDP. The description of that domain easily lent itself to a hypermedia oriented design where the nodes corresponded to the various objects in the method, and the links corresponded to the relations between those objects as defined by the SDP method.

We arrived at the design basis for our system, the glass box view, after considering (in particular the critique of) three different intelligent interface research areas: intelligent tutoring systems, plan inference in natural language systems, and explanation generation in knowledge-based systems. The explanation generation area contributed a basis for how to generate explanations consisting of texts and graphs in the different nodes of the hypermedia structure. The plan inference area contributed methods for how to follow users’ actions, within and between nodes, in order to infer their information-seeking task upon which, in turn, the choice of information content in the node could be based. The intelligent tutoring systems area contributed a perspective on how users acquire knowledge and how tools that provide information should be designed to meet users’ learning needs. We were also influence by other subfields within the area of intelligent interfaces, such as the agent area, the multimodal interface area, etc., but we limit the description to these three areas since they were most crucial in forming the design basis. In chapter four we shall provide a short introduction to each of these three fields to provide the necessary background to understand what ideas we borrowed from each area.

After motivating the glass box view, we discuss how we have realised it in our design – the main point is to provide an adaptive solution that provides users with control. The choice to adapt to users’ information-seeking tasks rather than their background knowledge, role or cognitive characteristics (such as e.g. their spatial ability) is motivated.

In chapter five, an overview of the implementation is given, first in terms of how the interface works, and then in terms of how the actual implementation was done (the system architecture, knowledge representation, etc.).

In order to establish the best relationship between what is inferred from users’ actions and the adaptation, several rounds of studies may be needed. The last part of the development cycle of an adaptive system should therefore be a ‘bootstrapping’ process where this relationship is gradually developed and refined. In chapter six, the bootstrapping process in PUSH is described.

Our last study evaluated the adaptive system in comparison with a non-adaptive variant of the same system. This last study is also described in chapter six.

In chapter seven, we summarise and discuss potential future work.

Finally, before we start, let us describe a couple of situations when a typical user will turn to the POP help system proposed in this thesis:

As the system designer starts working early in the morning, he discovers that he has forgotten how to design the ideal object model of the subsystem he is supposed to define this week. In an open the WWW browser Netscape window he enters the POP on-line manual system on SDP searching for information on ideal object modelling. He reads a short introduction to the purpose of the ideal object modelling process, but he feels that this information is just too abstract and there is too much information on how to think and how to work. Instead he jumps to the description of the object type that is going to hold the specification he probably should start with today; the IOM object type. He tells the system that he wants to work ”backwards” in a reverse engineering fashion, and the system then adapts its answer to only contain information fitted to his needs. In the answer page he finds an example that he can use as a starting point for how to write his specification. He is happy that he did not have to go and ask the guy next door for help - again.

In the afternoon, he has to go to a project meeting. His project manager seems extremely stressed, and is distributing tasks to all of the project members. He tries to stir out the window and look as though he is not there, but that does not help. His project manager turns to him and says that he has to help her make an estimate on how much time should be allocated for the next phase of their project. Inside he sighs, but as usual, he makes sure to look interested and says that this should not be a problem: when does she want the information? As he goes back to his room he decides that the best approach should be to first read a bit of the documentation on the processes that are involved in the next phase, and see if any of them can be skipped or at least parts of them. Since the switchboard system they are building is fairly small, they have been able to avoid some of the more elaborate parts of SDP in earlier stages of the project. He tells POP that he now wants project planning information about the following process, the real object modelling process. POP generates an answer page with information fitted to his needs. In particular, there is one piece of information on which activities that can be skipped. He marks this information, and then follows the links to the object types that should be produced to check how much needs to be done in each one of them.