A WWW Interface to an Adaptive Hypermedia System

Fredrik Espinoza and Kristina Höök

SICS, Box 1263, S-164 28 Kista, Sweden E-mail: espinoza@sics.se, kia@sics.se

Keywords: adaptive hypermedia, WWW, user modeling, multi-modality, information filtering


Java, HotJava, and Sun are trademarks of Sun Microsystems, Inc.
All other product names mentioned herein are the trademarks of their respective owners.

Abstract:

We tackle information overflow in an industrially produced on-line manual consisting of more than 500 documents of 5 to 20 pages of text and pictures. The manual is reorganized as an adaptive and highly interactive multi-modal hypertext system. A prototype implementation has been developed with a knowledge base in Prolog and an interface using WWW and Java.

In order to make the interface interactive we stretch the limits of html and the WWW. We generate an answer page consisting of graphs and text which the user is allowed to manipulate. The users can navigate in the information space by clicking in the graphs or by posing questions via menus. They can manipulate the answer generated by the system by closing or opening parts of the text. They can also pose follow-up questions on 'hot-words' in the text.

The choice of what information is made available is based on the users information seeking task, which we infer from their interaction with the system. The user can also actively change the assumed task, and thereby control the adaptive behavior of the system.

We stress the point that it is the combination of the multi-modal interface with adaptive information filtering that meets the individual users needs. Rather than abstracting the adaptive behavior as an interface agent, we present the adaptivity in domain dependent terms integrated with the whole interface.

Our realization of the system is through a knowledge representation implemented in SICStus Prolog Objects. The Prolog program will run as a process in the background and serve the remote Netscape clients. The interface is realized using dynamically generated html-pages, and graphs which are generated at the site of the Netscape client using a transferred Java applet.

We have evaluated the interface in our prototype with thirteen users as a part of bootstrapping the adaptivity. Their reactions were positive. They did not have any problems with distinguishing between different kinds of links available in our web-pages. They found the outlined adaptive scenario realistic.

1 Introduction

Information overflow can be tackled through adapting the information to a particular user or a group of users. We have studied the information overflow problem in one particular domain, the documentation of an object-oriented software development method, and designed an interactive, adaptive hyper-media system which utilizes WWW as its interface.

Until now, the WWW potential for interactivity has been very limited: the user can choose to follow or not follow links to other pages of information. We claim that it is important that the adaptive system is integrated with a highly interactive interface for two reasons. With an interactive system it will be easier for the user to correct any mistakes made by the adaptive system based on erroneous assumptions about the user. The second reason is that any modeling of the user can only be based on the users interaction with the system. If those interactions are limited to "clicking" on links in the hyper-media system, very little can be known about the user.

Our target domain requires that the interactive interface should be multi-modal, including both static text, generated text and generated graphics as output, and accepting both direct-manipulation and free form query input. These demands have forced us to design new ways of interacting with a WWW page that stretch the original hypertext metaphor. (By multi-modal we mean that the system generates, in this case, both graphs and text from a knowledge representation of the target domain. It also accepts both input via direct-manipulation and as queries.)

When realizing the system, our goal has been to create a modular solution. We separate the user model from the information in the database and we also separate the actual generation of the html-code from our database. This can be compared with Kay and Kummerfeld's approach which mixes the html-formatted information in the database with the user model (1994).

The separation of user model and information in the database is necessary since the information in the database is changed over time. In our target domain, a number of authors work with recurrent releases of the information database. It would be impossible to require that they would mingle the target domain information with user modeling control sequences.

The second separation is necessary to ensure that we can update our interface as the page viewers and html-standards are changed and enhanced. For example, we have recently re-implemented our presentation of the information to fit with the new Netscape viewer which includes Java virtual machine interface. This could be done without changing anything in our database of the software method.

We describe our approach to interactivity and adaptivity in section 3. In section 4 we describe the system architecture. The system is named PUSH (Plan- and User Sensitive Help). In order to make our reasoning concrete we start by describing the interface through an example in section 2.

The target domain

The information in our database is concerned with a Software Development Method (SDP) developed by Ellemtel Utvecklings AB. It is an object-oriented method. The method consists of processes that are activities done during the project phases, and objects that are e.g. specifications, pieces of code and similar, produced as a result of the method. Objects are the input and output of processes. In addition, objects are related to one-another with defined relationships as "is-a" or "part-of". Finally, processes are related to one-another so that one process comes before another, is part of another, or should be run in parallel. As can be understood from all this, the user is confronted with a difficult and complex information space.

The already available on-line manual consists of more than 500 documents of 5 to 20 pages of text and pictures. Our task in the PUSH project was to reorganize that manual into an adaptive and highly interactive multi-modal hypertext system. We have conducted several studies on how the users understand the method and how they search for information about it (Bladh and Höök 1995, Höök et al. 1996a), and the design of the adaptive hyper-media system presented here is based on those studies.

2 WWW Interface

In figure 1 we see a screen dump of our interface. It describes one process, 'iom,' in the SDP method. The answer page is divided into three frames (frames are subparts of the Navigator application window that can be scrolled and resized independently of each other and that each contain a web page):

GUI SCREEN DUMP

Figure 1. A screen-dump from the PUSH system.

3 Interactivity on several levels

The issue of trust is crucial when we design adaptive systems that alter their behavior in response to the users' actions, (Maes 1994). As pointed out by Judy Kay, (1994), no matter how clever inferences we make about the user characteristica, and will never be anything but a guess. One way of increasing the trust in the system, is to place some of the control over the system in the hands of the user. That is why we believe that our system should be interactive and allow the user to alter the output from the system.

Our system is interactive on several levels. It is interactive at the interface level, allowing the user to manipulate the output from the system. It is also interactive in terms of allowing the user to control the adaptivity. In order to realize the interactivity at these both levels, we have a dynamic interaction between the users' actions and the information system behind the scene. There are no ready-made html-pages that the user can down-load, instead we create the pages on the fly in response to the users' actions and history of actions.

Apart from the goal to make the output from the system interactive, our second design goal is to utilize the hypertext metaphor and de facto standard interaction with the WWW. It will be easier to learn our interface if it does not divert too much from the prevailing web style of interaction. This goal conflicts with the interactivity goal since WWW offers few possibilities for interaction. Still, we want to rely on the basic metaphor of pages and links as a means for moving between pages. The basic structure of our prototype is therefore that each object and process in the target domain will be presented in one answer page each. This page contains all the relevant information about the object or process, even if some of the information is hidden from the users immediate view.

The limitation of the potential nodes in the hyper-space to only one node per process or object also serves another purpose, namely to help our users with the "lost-in-hyper-space" problem. By limiting the nodes to be the whole description of a process or object, we make the hyper-space substantially smaller. An alternative would have been to divide the information into small, stand-alone units presented in one page each. This would have meant thousands of potential pages in this domain, so clearly that is infeasible given the goal that users will be trying to learn the structure of the whole method, not only tiny pieces of information about certain aspects.

The problem with our approach is that each page on a process or object might, if fully expanded, contain a lot of information. It is therefore crucial to structure the information within the page, and have means for navigation within a page.

Keeping our two design goals in mind, interactive but still web-like, let us start by describing the interactivity at the interface level.

3.1 Interactivity at the interface level

Graphs

In the screen dump in figure 1, we can see that the page is divided into different parts. The graphics frame serves two purposes. Firstly, it provides a comprehensive view of the information space at the current position; the graphs display all objects related to the current query as well as their relative positions. This gives the user an overview of the domain and also a means for navigation. Secondly, the graphs allow the user to navigate in the information space by clicking on objects in the graph. As the user clicks on an object the view changes to portray the new object and it's neighbors, and at the same time the appropriate textual information is retrieved and presented.

The presentation in the graphs meets the needs of users who are not so knowledgeable in SDP. They need to see how the objects are related to one another.

The graphs in our interface are not static pictures which are ready-made in our database. We generate the graphs from the object-oriented database the lies in the background. This means that whenever our database is updated, e.g. an object might be added or a relation changed, the graphs will immediately reflect the change.

Stretch-text

When the user has clicked on a certain process or object, they can also get a textual description of that process or object. There are many aspects that may be described: how to produce the object, how to work in the process, examples of objects, the purpose behind the process or object, etc. The user can either ask for a general summary, or just one specific aspect. In the figure above, the user has asked for a general summary of the process 'iom'. A set of 'information entities' are made available to the user. In the figure we see the 'summary' and the underlying 'purpose' of the process. The text frame is scrollable, and so there is more text available further down in that frame.

An 'information entity' is a stand-alone piece of information about one particular aspect of an object or a process. It is not necessary to read one information entity before another - there are no references between the entities. Our studies of the domain, and studies of similar domains (Svenberg 1995), show that this is not an impossible requirement on technical documentation: it is often written as a set of small stand-alone pieces of information.

In the underlying knowledge representation, the information is organized as objects (one for each process or object in SDP) with attributes. The attributes are the objects relation to other objects and also the information entities which describe the objects. So, each information entity constitute an attribute of the object. When we construct the textual presentation, some information entities will be ready-made texts in the database, other texts we generate from the information about the object. (We use an object-oriented terminology to describe our database, in other adaptive hyper-media systems, objects are named frames and their attributes are slots, see Brusilovsky (1996)).

In the interface, an information entity can be viewed as either a piece of text, or a part of the graphs. Sometimes an information entity is doubled so that we display, for example, input objects of a process in the graphs, and also as a piece of text.

The user can be dissatisfied with the provided information in the answer page, and is therefore allowed to manipulate the textual parts of the page. They can close or open the information entities through clicking in the guide frame next to the textual frame. By clicking on the name of the information entity displayed in the guide frame, the text will be inserted into the page. Another click on the information entity name in the guide frame will close that part of the text. This is what is named stretch-text (see also Brusilovsky (1996)). By opening and closing parts of the text, the user can create an answer page that is better fitted to their needs.

Hotwords

We also allow the user to pose follow-up questions on concepts that are crucial to the understanding of SDP. In the figure we can see that the concept 'object-oriented analysis' is marked as bold, and next to it we see a list of alternative follow-up questions that can be asked about this concept. In order not to disturb the users reading of the text, the alternative questions are only visible after clicking on the button next to the hotword. (We have borrowed the term hotword from (Kobsa et al. 1994) who use it to denote a marked word in the text that is a link to another piece of hypertext.) If the user chooses to follow one of these links, an explanation of the concept is inserted into the text frame below the current information entity. So, if we had clicked on 'Describe object-oriented analysis', an explanatory text would have been inserted between the 'summary' text and the 'purpose' text. At the same time, we insert the concept into the guide frame.

The hotwords and their associated follow-up questions allows the user to increase their knowledge of SDP. If they are already knowledgeable in SDP, they do not have to read irrelevant information about these basic concepts.

Menus

Finally, the user can also navigate by composing questions via menus, which is an important alternative to navigation in the graphs. A typical question can be 'describe process iom' which would render the answer page in figure 1. A more specific question could be 'provide an example of iom', which would result in an answer page with only one information entity open: the example text.

Allowing the user to pose questions is crucial if we want to meet the needs of experienced users. They do not want to spend time navigating to a particular piece of information, but instead just 'jump' to it.

3.2 Interactivity with the adaptivity

Even if the interactive WWW interface outlined above will be a powerful tool for information retrieval in this domain, we still have the problem of information overload. One answer page might turn out to be several pages long, and we know both form our own studies (Bladh and Höök 1995) and from studies of WWW usage (Nielsen 1995), that users tend not to read more than the first page of information.

This has caused us to try to find aspects of the users that can be used as a basis for information filtering. We found that the user's information seeking task was a good tool for determining which information entities would be most relevant to the user in a specific situation (Höök 1995, Höök et al. 1995). We constructed a hierarchy of information seeking tasks as a result of a task analysis on user's behavior in their daily work situation. Examples of tasks are: 'project planning', 'learning the structure of SDP', 'working in an activity within a process', etc.

So how can we know which information seeking task the user is performing in any particular situation? Our approach to knowing about the task is by combining a user-controlled and a self-adaptive approach (Höök et al. 1995, Höök et al 1996a). (Self-adaptive are such that the whole adaptive process is done by the system alone: the system initiates, proposes, decides, and executes the adaptive behavior (Kuhme et al. 1992)). According to Oppermann (1994) this middle route is to be preferred since the users must have control over the adaptivity, but they will not spend much time controlling it continuously. The adaptive hyper-media tool should optimally be a tool to aid the users in their daily work, not an obstacle that they have to actively adapt in order to make it work smoothly.

We allow the users to set which task they are working with initially, and then we use plan inference (i.e. inferring the users' underlying goal from their actions at the system) to update their assumed current task continuously (Waern 1994). The user can at any time change the inferred task to some other task, although we limit the set of potential tasks to those which will actually change the explanation in the current situation. (In figure 1 we see under the heading 'task' which information seeking task the system assumes that the user is performing. The task is marked bold that means that the user can click on it and alter it.)

Given that we know of the information seeking task, we utilize a set of simple rules that connect a question plus a task with the most relevant information entities. Examples of such rules can be found in figure 2.

Learning structure ->
Basic introduction, Purpose, List of activities, Input objects, Output objects, Relations to other processes, Simple example
Project planning ->
Project planning information, What is done in this process, Information model, Simple example
Performing an activity ->
Summary, How to work in this process, Release information, Input objects, Output objects, Relations to other processes, Entry criteria, Exit criteria, Information model, Advanced example, Frequently asked questions
Producing a product ->
Information model, What is done in this process, Release information
Figure 2. Four rules for the question 'Describe process X'. The information entities are only described by their name in this figure - no full example can be included due to a secrecy agreement with Ellemtel Utvecklings AB.

3.3 Meeting users' needs

As indicated in the text above, the whole solution with the multi-modal, interactive WWW interface, and the adaptivity, will provide the user with explanations which meet their needs. Since users differ in many respects, our approach has been to find a mix of non-adaptive and adaptive techniques that together meet the individual user. So we are adaptive to the information seeking task, but not to the knowledge of the user, or to their cognitive characteristics and preferences. In our studies, we did find that both the users knowledge and their spatial ability influenced their understanding of the domain and the documentation of it (Bladh and Höök 1995, Höök et al. 1996b).

By allowing the manipulation of the answer page, and in particular by the follow-up questions on concepts crucial to the understanding of SDP, we cater for the difference in knowledge held by the users. With the two ways of navigation in the information space, menus and graphs, and by presenting some information both in graph and textual form we attempt to cater for differences in spatial cognition (Höök et al. 1996b).

4 System Architecture

To make the more or less non-interactive WWW environment as interactive as possible several methods have be used: a Java program for client side graphics handling, a CGI program for dynamic generation of web pages, as well as an underlying adaptive database, implemented in SICStus Prolog objects. See figure 3. They have all played a part when brought together in the Netscape browser. The result is a platform independent, highly interactive, adaptive system for filtered information retrieval on the World Wide Web. This whole architecture is transparent to the user, who only sees Netscape.

Push Pic.
Figure 3. The architecture of the POP system.

4.1 Generating Web pages on the fly

There are several reason why the dynamic generation of web pages is preferable to keeping static pages on disk. For one there is the aspect of presenting information that is tailored to a specific user. Furthermore, if the information can be put together in a multitude of ways, the sheer number of possible variants can make static pages impractical.

In the PUSH system, pages are created in two distinct ways. One is for presenting the results of a new query to POP (the database part of the PUSH system) and the other is for filtering or modifying the currently displayed page. As a query is made to POP, certain data that is tailored to the current user is retrieved. This data is in the form of plain text containing tags signifying hot-words that lead to further queries. The data is channeled to the Page Generator, a CGI program, via a socket. The Page Generator parses the information and builds the finished page by incorporating HTML code into the textual data to construct interface tools such as clickable buttons and menus. When finished, the complete page is piped to the Netscape browser and displayed. The page is also cached to disk. It contains hidden formatting instructions that make it possible to alter the appearance of the page without accessing the database.

4.2 Generating the graphs

A graphics engine implemented as a Java applet takes care of the graphics functionality. At the onset of a query session when the initial page is served to the Netscape browser, the Java code is loaded. (Code written in the Java language runs on a virtual machine inside the web-browser. The same applet code can therefore be loaded into Netscape regardless of platform.) Throughout the query session, the Java program then receives and displays the graph data in it's frame in the Netscape browser. The graph data is read each time it is updated. This happens when the view of the information space changes, i.e. when a new object is viewed. Since there are follow-up questions in the text that do not result in a change of the object that is being viewed, but rather in an insertion of the answer into the existing text, the graphs serve to reinforce the sense of a current object.

4.3 Putting it all together - an interactive web application

The PUSH system is accessed remotely using the Netscape Navigator. A typical session starts with a user retrieving the initial PUSH page, which is the only page that is stored on disk. This is a template page that contains the interactive controls for choosing a query, as well as the Java applet displaying an initial overview of the information space. At this point the user is issued a session id that distinguishes the session from other potential simultaneous sessions, and an individual Prolog process is started. Each user communicates with their own Prolog process via a dedicated socket and both socket and prolog process exist as long as the session lasts. At the end of a session the user's prolog process is terminated so as not to hog the server system.

Each query starts the Page Generator CGI which sends the query parameters to the POP Prolog program. Since each query changes the state of the POP program to allow different follow up questions depending on the current context, and since the Page Generator is a CGI program that lives until the current query answer has been presented to the user, a scheme for saving the current state is needed. For example, the Page Generator must have a way of knowing to which of perhaps several different POP prolog processes to talk to, so the socket name is saved in each presented HTML page as a hidden input field. An example of such hidden instructions is the insertion of the menu of potential follow-up queries associated with a hotword when the user clicks on the hot-word button. This will not invoke a call to the Prolog process, but can be handled the Page Generator.

4.4 Advantages of remote access to the database

Remote access to a system such as PUSH, using the WWW, has a number of advantages:
  1. The Netscape Navigator and the Java language enables users on a number of different platforms to access common data using a common interface.
  2. The application software only needs to be implemented in one place, thus sparing users from the sometimes difficult task of down-loading and installing the software locally.
  3. All software and data updates are done at the server site. This means that the remote users can be assured that they have access to the latest information as soon as it is available. It also means that all users have access to the same information which is important when users are collaborating remotely.
  4. Adapting to new and improved protocols and standards such as HTML 3 or new versions of Java, is easier.
Our approach here may be compared with Kay and Kummerfeld's, that mingle the html-format and user modeling instructions with the information in the target domain (1994). In [Rice et al. 1995] much the same argument about WWW and its availability across platforms is made.

4.5 Limitations

At the present time the PUSH system uses beta versions of the Netscape Navigator (2bj) and the Java programming language. This puts certain restraints on the system. Apart from what is to be expected in terms of bugs or missing documentation, the Netscape Navigator has no support for socket communication in the Java implementation. This means that the graphical data for example, must instead be saved to disk by the POP program and read by the Java applet.

Several enhancements will be feasible within short. One of the advantages of using a widely spread web browser such as the Netscape Navigator as well as the up and coming Java language, is that as soon as advances are made to these products they can be taken advantage of in the PUSH system.

The graph data is transferred from the POP program to the Java applet by means of a file. Improvements to look forward to are the Java socket capabilities in Netscape, enhancements to the HTML standard, and for example HTML parsing and presenting capabilities in a Java text-area. This will allow us to completely remove the Page Generator component and instead have one, more complex, Java applet communicate with and present the information of the POP prolog server. For example, we hope to replace the current somewhat awkward way of posing follow-up queries to hot-words by pop-up venues.

Another great improvement to the system will be to allow authorized users to update the information database in POP by viewing and editing and finally uploading the content from a remote location.

5 An empirical evaluation

As indicated above, our prototype is not completely stable due to the problems with Java and Netscape. Even so, we were able to conduct a first evaluation of the interface parts of our system. The purpose was to collect information that would help us to bootstrap the adaptive parts of the system. At the same time as we collected that information we also logged the users actions and posed a number of queries to them on how the perceived the interface. Since the study was fairly small, only thirteen subjects, and done on a buggy prototype, the results should be viewed as tentative.

At the time of the study of the interface, we only had the graph and text frames. The guide frame had not yet been implemented. We did instead show our design with the guide frame as a picture to the subjects after their session with our system, and they all expressed a feeling that this would improve the interface.

5.1 Method

The subjects first got familiarized with the tool by just "clicking around". We pointed out the four different actions possible: clicking in the graphs, posing queries via menus, opening and closing stretch-text and posing follow-up queries on hotwords. They filled in a form about their background knowledge. They were then presented with different "tasks" and asked to pick one which fitted with what they knew about a particular part of the process, usually did, their background knowledge and work-style, etc. (as 'reverse engineering', 'project planning', 'learning structure', etc.). They were then asked to tell us which information about a process and an object would be most relevant given the task. In addition, some subjects performed two search tasks for specific pieces of information.

Finally, the subjects were asked to answer a set of follow-up questions on their impressions of the interface.

5.2 Results

In the introduction above, we mentioned two design goals: that the system should be interactive, but also that it should be web-like. So wanted to know whether our subjects would be able to understand which interactions were possible, and whether they could anticipate the result of those actions. First, we can observe that they all made use of the possibilities to click in the graphs and the stretchtext possibilities. Everybody used the possibility to pose a query via the menus of via hotwords a few times, although their main interaction was via the graphs. Second, when asked after the session whether they had found the "links" and possible actions at the interface understandable, 11 said that they had no problems, while two felt that as beginners they had problems. Two subjects (out of the 11) said that the result of a follow-up query on a hotword resulting in an insertion of an explanation into the current page should be better marked, perhaps with another color or indented.

Related to the possible actions at the interface, was whether they could make sense of how the information space was organized. On the query "Was the information space understandable (did you get lost at any point)?", 7 subjects claimed to have no problems, while 3 asked for go-back functions, and 2 were irritated by the fact that when they did what they felt was going back to a previous page, the system would have closed some IE's (this will not be the case in the adaptive system). Finally, one subject had problems with the navigation, but liked the possibility to have control over the textual parts and wanted those to be the basis for navigation rather than the graphs.

Concerning the graphs in the interface, the users were not confused by the fact that they were both used for navigation (implicitly posing queries) as well as for presenting information about the target domain. Some complained about the fact that they were designed to be quite small. In general, the impression was that the subjects would have liked to decide how big the graphs versus the text frames should be. Sometimes and for some subjects the graphs were more important, while for other the text was the main source of information.

So, in summary, it seems as though our subjects made use of the possible actions at the interface and they did not have too big problems with getting lost or understanding how to interact with the system. As this was used to bootstrap the adaptivity, we asked the subjects whether our "tasks" were realistic and whether they kind of adaptivity envisioned would be feasible. All seemed to find the scenarios realistic. Many added that what determined which information would be most relevant was also the project status. If they were just about to start a process, they would require information related to the learning task, while towards the end of a process, they would require very specific information on how to document the results of the process in the objects and the relations between the objects, etc.

Adding the project status to our system and using it as an additional source of information for the adaptive behavior, is considered and will be included in our future work.

6 Summary

By stretching the limits for what can be seen as a standard WWW-interaction, we have been able to implement a multi-modal interface to our adaptive information filtering system in a closed domain. It should be noted that we regard the combination of the interactive interface and navigation in the information space as part of the solution of how to meet the individual users needs. The adaptive parts of our system is an integral part of this solution.

We have also shown that it is possible to realize our interactive solution by using the Netscape Navigator and Java applets to communicate with a server-side database which generates the information needed.

Finally, we have made an initial evaluation of the interface which showed that it was comprehensible and fulfilled our demands on being interactive, yet web-like and intuitive. Next, we aim to perform a study on the adaptive behavior of the system.

References

Bladh, Malin and Höök, Kristina (1995) Satisfying User Needs Through a Combination of Interface Design Techniques, In: K. Nordby, P.H. Helmersen, D.J. Gilmore and S.A. Arnesen (eds.), Human-Computer Interaction INTERACT'95, Chapman & Hall, Oxford.

Brusilovsky, Peter (1996) Methods and Techniques of Adaptive Hypermedia, Journal of User Modeling and User-Adapted Interaction, special issue on Adaptive Hypermedia, UMUAI 6, in press.

HTML3 Specification, http://www.w3.org/hypertext/WWW/MarkUp/html3/CoverPage.html

Höök, Kristina (1995) Adaptation to the User's Task, SICS Research Report, SICS, Sweden.

Höök, Kristina, Karlgren, Jussi and Waern, Annika (1995) A Glass Box Approach to Intelligent Help, IMMI-1 (First workshop on Intelligent Multi-Modal Interaction), Edinburgh, U.K.

Höök, Kristina, Karlgren, Jussi, Waern, Annika, Dahlbäck, Nils, Jansson, Carl-Gustaf, Karlgren, Klas, and Lemaire, Benoit (1996a). A Glass Box Approach to Adaptive Hypermedia, Journal of User Modeling and User-Adapted Interaction, special issue on Adaptive Hypermedia, UMUAI 6, in press.

Höök, Kristina, Sjölinder, Marie and Dahlbäck, Nils (1996b) Spatial Cognition and Hypermedia Navigation, SICS Research Report, SICS, Sweden.

Java, the language, the Java home-page: http://java.sun.com/.

Kay, Judy (1994) Lies, damned lies, and stereotypes: pragmatic approximations of users, Fourth International Conference on User Modeling, Hyannis, Massachusetts, the MITRE corporation.

Kay, Judy, and Kummerfeld, R.J. (1994) An Individual Course for the C Programming Language , Proceedings of the Second Internation WWW conference'94 Mosaic and the Web. Kobsa, A., Muller, D. & Nill, A. (1994) KN-AHS: An Adaptive Hypertext Client of the User Modeling System BGP-MS, Fourth Int. Conference on UM Hyannis, MA, 1994.

Kuhme,T., Dieterich, H., Malinowski, U., and Schneider-Hufschmidt, M. (1992) Approaches to Adaptivity in User Interface Technology: Survey and Taxonomy. In: C. Unger and J. A. Larson (eds.): Proceedings of the IFIP TC2/WG2.7 Working Conference on Engineering for Human-Computer Interaction, Elsevier, North-Holland, 1992.

Maes, Patti (1994) Agents that reduce work and information overload, Communications of the ACM, July 1994, vol. 37, no. 7.

Nielsen, Jacob (1995) Interface Design for Sun's WWW Site, invited talk at the Interact'95 conference in Lillehammer.

Oppermann, Reinhard (1994) Adaptively supported adaptability, International Journal of Human-Computer Studies 40:455-472.

Rice, James, Farquhar, Adam, Piernot, Philippe, and Gruber, Thomas (1995) Lessons Learned Using the Web as an Application Interface, Knowledge Systems Laboratory, KSL-95-69, September 1995, http://WWW-ksl.stanford.edu/.

SICStus Prolog User's Manual (Release #3). Swedish Institute of Computer Science, Box 1263, S-164 28 Kista, Sweden, ISBN 91-630-3648-7.

Svenberg, Stefan (1995) Structure-Driven Derivation of Inter-Lingual Functor-Argument Trees for Multi-Lingual Generation, Licentiate thesis 498, Department of Computer and Information Sciences, Linköping Unviersity, Sweden.

Waern, A. (1994) Cooperative Enrichment and Reactive Plan Inference - applying plan inference outside Natural Language Dialog, SIG meeting at Fourth Int. Conference on UM ,Hyannis, 1994.

Author details

Fredrik Espinoza is a researcher at SICS. He is completing his MSc work on the WWW interface implemented described in here.

Fredrik's main interests lie within design of interfaces, both implementation and in understanding how to meet users needs.

Kristina Höök is a licentiate doctorate and researcher at SICS.

Her main interest lie within design of adaptive interfaces, design of explanation and in general Human-Computer Interaction. A special interest is in the role of individual differences, as spatial ability, in their effect on the design of interface.

Address SICS, Box 1263, S-164 28 Kista, Sweden
Tel +46 8 752 1500, Fax +46 8 751 7230
E-mail espinoza@sics.se E-mail kia@sics.se