Submitted for publication.
Do not copy, quote or cite without author permission.

History-Rich Tools
for Social Navigation

Alan Wexelblat
MIT Media Lab
Software Agents Group

Abstract: I present a research framework and some tools developed as part of an ongoing effort into defining and using interaction history as part of a user interface for social navigation; that is, using traces left by past users to help current users find and understand information.



Digital information lacks history. It lacks the texture and depth and richness that comes from being used by many hands over much time. Where the physical world is rich with cues and montages that we take advantage of constantly, our data remains sterile. When we open a word processing document or visit a web site it is as though we were the first and only people ever to handle these data.

Contrast this with a borrowed book or a lived-in house; both are rich with the markers of previous use and these markers (the dog-eared pages, the padded arch of a low doorway) serve as pointers and help us make better use of the information and the space.

I am investigating how interaction history can be used in digital information. My chosen problem domain is social navigation -- the process of using cues from other people to help you find information and potentially to understand more fully what it is that you have found.

The project has two components: an attempt to define what goes into the field of interaction history, and a series of prototypes oriented toward the social navigation problem. This paper briefly covers the first aspect and then spends most of its length on the particular tools created so far, and some interesting insights generated from them.

As this is an ongoing research project, we do not present any numerical or statistical conclusions. Instead, this paper shows a number of interesting examples, which I believe are indicative of the potential of applying this technology to the problems of social navigation.

Interaction History

The history of interaction of objects are the accumulated records of what has been done, with emphasis on sequences of actions, relationships of elements on which the user has acted, and the resulting structures. History modifies an object's state, but not just any accumulation of state modifications are interesting history, as illustrated in Figure 1. This diagram is reproduced in Brand's "How Buildings Learn" [1] and credited to Krier [9], page 36.

Figure 1 -- History versus Accumulation

The modifications or additions that make up interaction history affect not just the object but our perceptions of, and uses for, the object. That is, interaction history changes how we see things, what we think is appropriate for things, and how we think about things. For example, near the end of 1997 news stories began appearing indicating that certain artworks appearing prominently in public American museum collections had been plundered by the Nazis [19]. This bit of history did not change the objects themselves in any way. Instead it changed our perceptions of them. What had been done in the past changed our ideas on how to treat the objects in the present.

Interaction history implies both the presence of an actor and the presence of an acted-upon (object, collection, space, etc). It also implies the presence of time; history is not about what is happening now so much as it is about what happened in the past. Thus, we can infer a third party, the observer, who notices the relationship between actor and acted-upon. The observer may also have been the actor in the past, but there must be some intervening time, even if it is only a moment, in which the actor can step back from the object and reflect on the interaction. Clearly what counts as relevant interaction history for one observer may not be relevant for other observers.

We use interaction history information daily in the physical world. Objects often carry their histories with them, as in the examples of the dog-eared book and padded doorframe above. Physical objects often change in response to use: brass shows a patina where human sweat and friction have been applied, stone stair treads show curvatures worn by thousands of shoes passing over them, etc. We make use of these traces, often without conscious thought, as when we let a book fall open to a particular page because it has been opened to this page often in the past.

Since the interaction between participants and objects takes place in a cultural context, interaction history is also embedded in a cultural context. If your culture does not include certain concepts, then it may not be possible to make use of the history shown by the objects. For example, Hutchins [8] describes differences between ship navigation as practiced by Western and South Sea Islands cultures. One of the major differences is that the islanders do not make the mental transformation to see geography from a fictional "bird's eye" point of view. Instead, they see themselves navigating from the surface of the sea, where navigation takes place in real life.

Without a cultural basis for this transformation, one of the major artifacts of Western navigation, the map or chart, is completely inaccessible to them. To us, having grown up in a map-using culture, the necessary mental transformation is so common that we think of it as "natural" and go on using it without thought. We forget that maps make no sense unless we project our viewpoints out to some imaginary place far above the surface depicted on the chart. Without this transformation, the common interaction history artifacts -- such as the lines connecting the series of position fixes made by the ship's navigation team -- are completely useless. To the islander, the chart is meaningless scribbles, to us Westerners it is an open book written in our native (cultural) language.

One of the most important goals of our project is to find ways to make interaction history information as easily and naturally available in the digital world as it is in the physical. This effort is inspired by original work done by Hill and Hollan in the early 90s [4] [6]. We also owe the term "history-rich object" to them.

Dimensions of History

The first challenge is to characterize the problem space. We use six major dimensions to describe the area we mean by "interaction history." These dimensions describe a large set of possible forms of history and many possible systems which could be built. In the real world, objects typically show several forms of history at the same time.

An important part of this research is finding useful points in this multidimensional space for history to be shown in computer interfaces. This problem is attacked below.

Dimension 1 -- Visibility of Purpose

Purpose relates to why something was done. Some forms of history show only what was done but give no reasons. A later user must infer the reasons, if they are important. At the other end of the spectrum, some forms of history show "why it was done" so that we understand motivation, but not what happened.

In the physical world, we might see that the pages of a book have been selectively dog-eared, but not understand why. Alternatively, we might know that our colleague uses this technique to mark pages from which he wants to draw quotations, but not see which quotes had been extracted. In the digital realm, we could imagine a collaborative editing tool which would allow users to see what text had been removed by others, but not why. A different interface could allow authors to attach rules explaining why they made changes so that co-authors could see the notes.

Dimension 2 -- Kind of Information

There are an infinite variety of kinds of interaction history information that can be captured. What kinds of information are available are, to a large degree, dependent on the purpose of the observer. For example, a doorknob may show a particular pattern of wear accumulated over time, which may be important to someone interested in affordances (that is, how people have handled the knob). Alternatively, someone interested in the history of the building might take note of whether the knob was made of expensive brass or cheap aluminum.

One of the key distinctions in kind of history information is accumulation versus sequence. Some forms of history accrete, and are represented as changes in the state of an object; some forms are sequential and make the sequence longer as more history is added. Think of the difference between the accumulated wear on a road versus the added position fixes on a navigational chart. Figure 1 shows the difference between simple accumulation (the pile on the right) and historical accumulation (the building on the left). The problem of characterizing kinds of history information is addressed in more detail below

Dimension 3 -- Rate/Form of Change

History moves forward, building as more interactions take place. However, there are also two other processes occurring at the same time. One is "fading," the other is "obscuring." In a fading process, history-rich objects are replaced, people move on taking organizational memory with them, and history is discarded because it is no longer important or lost because people forget and there is no longer a record to remind them. In an obscuring process, records of new interactions cover up old ones. History is often layered and while this layering often gives a richness, it also covers up.

Fading can be characterized as a decay function, much as we talk about decay functions for signals. Both the accretion and decay functions will vary in any history-rich interface. A key benefit of modeling interaction history explicitly in digital systems will be to help users distinguish discarding from forgetting.

Dimension 4 -- Degree of Permeation

Permeation is the degree to which interaction history is a part of the history-rich objects. History may be inseparable from the object, as in the worn-stairs example, or it may be completely separate, as in the stolen-art example. In a history-rich interface, we must decide how closely to link the objects of interaction and the history information.

In most cases, the history information must be kept peripheral, as it should be an enhancement to the user's task environment. If interacting with the history information becomes a central focus, we have probably changed the task too much. An appropriate analogy here is to a painting: the painting may be appreciated for what it is alone, or it may be framed. A good frame will enhance our interaction with the picture; it complements our looking. Interaction history is like the frame; the picture is the information to which the history relates.

Dimension 5 -- Personal versus Social

History can be intimate to a person -- what have I done? Or it can be social -- what has been done here? Many tools focus on personal histories; for example, the facilities within web browsers that allow users to see and revisit sites they have been to in the recent past. Group histories are more rare but, we believe, more valuable because most problem-solving tasks are collaborative in nature. One of the primary benefits of interaction history is to give new users the benefit of seeing what was tried in the past. In fact, the slogan for our project is:

We all benefit from experience;
preferably someone else's

The other value of group history is that it promotes organizational learning. While it is true that organizations cannot learn unless individuals within the organization learn, it is also true that if the learning is confined to individuals then it cannot benefit the group as a whole.

Dimension 6 -- Active versus Passive

Most interaction history is passive; it is recorded and made available without conscious effort. When we prop open a cookbook so that we can read the recipe while our hands are busy, we do not think of ourselves as recording our favorite recipes. But that is, passively, what we are doing. We could actively record the same information and we often do, but this takes additional thought and effort. Unfortunately, the "good stuff" may be in the active history. Just as we may make many editing changes to a document (passive history) before committing a new version to a repository (active history) we often find that people take the time to record history because they feel it is important. The challenge for history-rich interfaces is to find a good balance, allowing history to be passively collected while still capturing enough of the right data.

Interaction History Framework

Since we cannot possibly characterize all the kinds of information available, we use the following framework to organize this dimension (Dimension 2 from above). It focuses on the uses to which interaction history might be put. The framework is intended to be usable in two directions. The first takes the approach of looking at the kind of information available (grouped loosely into "who," "what," "how," and "why") and asserts tasks or problems for which that kind of interaction history information would be valuable. Conversely, one could start with a particular problem in mind and see what kind(s) of interaction history should be captured to help with that problem.

Problem Domain

In order to investigate the possible forms of interaction history, we have chosen to focus on the domain of social navigation. That is, literally, using information from others to help you find what you want.

Probably the most common form of social navigation is information recommendation, sometimes referred to as social filtering [15]. Information, usually in the form of ratings, from other users is applied to help the current user. This is done either by selecting one or a few items from a large database of potentially recommendable items, or by ordering, rating or filtering information items based on past ratings data. Systems which fall into this category include the Bellcore video recommender [5], the MIT Media Lab's HOMR music-recommendation system [14], the Do-I-Care Agent (DICA) for Web pages [16], and the Usenet news rating system GroupLens [12].

Although this sort of recommendation is "navigation" in a sense, we are more interested in the literal problems of finding one's way around. We believe this task is an appropriate one because it is an increasing problem in large information spaces such as the World Wide Web and because it is a task which normally makes use of traces and history information. Hutchins' book Cognition in the Wild [8] gives an elaborate description both of the artifacts used in modern ship navigation and the particularly social nature of the task.

To help in our Web-based social navigation task, we were inspired by three artifacts common to many forms of navigation in the real world: maps, trails (or paths), and signposts. We are investigating how these tools can be made history-rich or used in a history-rich interface.

Tools Built

As part of this project we have been developing prototypes associated with helping us understand the issues around interaction history. We have built several tools to use history in the display of navigation information. Each of the tools represents a point in the multidimensional space sketched out above. The project, called Footprints (by analogy with the footprints we leave in the physical world) involves deploying and testing these tools in both controlled situations and users' normal browsing environments.

Footprints uses information from web server logs to see where users have gone, and then processes that information into various displays, illustrated below. Thus, all the prototypes so far fall into the "passive" side of dimension 6, in that the user leaves these history traces without any extra effort. The next version of the system, which should be deployed early in the spring, will allow users to create signposts, an active form of history. Signposts will also give users the chance to leave more purposive information (why they navigated where they did). We are presently designing a tool to ease creation or selection of purposive information.

extended document transition The kind of information gathered is, at base a series of A->B transition pairs, where A and B are World Wide Web documents and the transition is any navigation technique used by people to get from document A to document B. This is often clicking in their web browser on a link embedded in the HTML of page A which takes them to page B, but can also be typing in a URL or selecting a bookmark. The system combines these simple transition pairs into more complex structures, such as the one to the right. That is, the document B and all documents used to reach it as well as all documents reached from B. The system also assembles linear sequences of transitions into trails, as described below.

The first version of the system [17] used maps, as shown in Figure 2. These maps take the information about which pages at a Web site the user has visited and construct a directed graph representation: nodes are pages, and edges are traversals used to get from one web page to another.

The map in Footprints is displayed using a hyperbolic geometry, in the style of Lamping et al's work at Xerox PARC [10]. This particular representation was chosen because it has the ability to deal with kinds of graphs produced by our interaction histories. In particular, these graphs are both highly nonplanar and highly disconnected. That is, they are likely to have a large number of edge crossings no matter what layout method is used and users will probably want to look at different parts of the map separately.

Not all pages at a site are represented in a Footprints map; only those actually visited by users. Edges, as noted above, may be created by users clicking on URLs within the page, or by any other means, such as the user selecting a bookmark or typing in a new URL. In some ways, these "other" links are more interesting, in that they show transitions between pages which do not exist in the HTML but which users feel are appropriate for one reason or another. This is an insight into users' cognitive models of how information should be related, a point which is addressed in more detail below.

Maps and other tools in this project are not merely representations, but are also active navigation aids. Users can single-click on any of the nodes to bring up the title of the document represented by that node (Figure 3). Double-clicking on a node brings up the corresponding page in the user's web browser.

Footprints also supports a list tool (Figure 4) providing a scrollable list of the titles of the nodes in a map. The list is also navigable; double-clicking on any title brings up the corresponding page in the browser. Views are coordinated so that when a node is selected in one view it is also selected in the other. This helps users maintain their orientation and location as they move around.

Usage maps provide an interesting complement to the conventional quantitative (hit-count) based methods of looking at Web traffic. These maps show sequence, obviously, but at a higher level they can be seen to expose the kinds of experiences which users can get from a web site. This information is useful for two classes of users:

Figure 5 and Figure 6 show four different kinds of experience within the same interaction history map. The circled sets of node visits show the experiences. We have named these experiences for ease of reference, but have not developed an ontology or taxonomy of possible experiences.

The first experience (upper right part of Figure 5) I call "narrative" because it takes the form of a traditional story: tell me something, tell me something else, then tell me another thing, with only minor diversions off the main thread, probably for explanations of specific points.

This sort of experience works well for users, who want a slower-paced or simpler introduction to material. A user who preferred to dive right in might look instead for a "storefront" experience, such as the one in the lower left of Figure 5. In this experience (as in the aisles of a store) there is a rich interconnection of items, with no obvious natural sequence among them.

The other two experiences seen in this map are the "central message" and the "in and out" experiences illustrated in Figure 6. In the central message a large number of nodes lead into a central node. The converse in and out pattern involves a central node which spreads out links to a number of subsidiary pages, each one hop away from the main or central page. This seems to result from users' actions in visiting sites arranged with a primary page that has a list of links. Users visit this page first. They then select one of the links from the list ("in"), look at the page, then use the browser's "back" button to go back to the main page ("out") and repeat the process ("in" again).

Note that we are not attempting to say that one sort of experience is good or bad or better than another. For example, the central message can be very bad if the external pages are all advertisements leading to your Web site and the central page is your front page. In this case, your ads are clearly working, since they are bringing people to your web site. But they are not going anywhere inside your site, which probably indicates a problem with the site. Conversely, if the external pages are all descriptions of your products and the central page is the "give us your credit card number" page then this sort of experience is probably just what you'd want to see, since it indicates an interest in ordering your products. The point is that this sort of information is different from, and in many ways complementary to, the standard quantitative hit-count based approaches. History shows us the experience.

As noted, this experience information is valuable both for users who want to know what kind of experience they can expect from an information space, and for information designers. Designers can both look at an ongoing experience and can compare experiences based on changes they make to the information presentation. Clearly, any given presentation of a set of information favors some experiences and discourages others, but users are persistent. As any UI evaluation professional knows, users will be very inventive in trying to do things they think ought to be do-able, no matter how hostile the interface may be to their doing it. When such connections show up across many users, the wise information designer will work to accommodate them.

In many ways maps (and the trails discussed below) are a vast oversimplification of the information used to create them. An edge in a map shows which documents it connects, the direction of travel, and the use of that transition path relative to other transitions in the map. It is possible to extract a wide variety of other history information from the data and to show this additional information in the map representation or in another form. For example, mean and standard deviation numbers could be generated for each link. Links could be filtered and shown or not shown based on a number of factors, such as similarity of purpose of past users to the present user. Additional uses such as these are presently being investigated. We will return to this issue in the Status section.

Version 2 -- Trails and Annotations

Of course, experiences in Web browsing are rarely confined to one site. Therefore, our latest version allows users to be followed across multiple web sites as they browse. The result is a set of trails of pages which are connected both directly (by links on the pages) and indirectly (by other actions the user takes). These trails are then compared to show relative levels of use. The levels are also color-coded for ease of recognition, as shown in Figure 7.

In order to help users identify which are the most and least-used trails, color-coded words are placed next to the end nodes of trails based on their level of use.

Also as with maps, this view is a fully active navigation aid. Users can single-click on nodes to see their titles (thus the stair-step representation, which leaves room for text display). Double-clicking on a node brings it up in the corresponding browser window.

However, the trails representation does not stay static as the map does. When the user moves to a new page, either by clicking on a node in the trails view, clicking on a URL in the Web page, or typing in a URL, the trails view adjusts. It always shows all and only the trails relevant to a given page. For example, in Figure 7, the user is on the page listing the publications of the Software Agents group; this node is highlighted in black.

In this case (as in many others) there are a number of different trails which include this page on them. The system displays all that it knows about all the paths; however, to minimize visual clutter and help give a sense of decisions, the system combines trails which have a common starting point so that similar paths are shown merged. For example, imagine that the four paths on the right are in the database.

4 paths

Then if the user was looking at page B, the representation would be as shown at the right.

The two representations of 'D' are not collapsed since they represent different paths through the space. The multiple representations of A and B are collapsed, however, since their positions in the path space are identical.

at document B

If the user now selects page C, the representation would change to that shown at right.

The A->B->D->F path is removed from the display because it is no longer relevant. Other paths containing page C (which do not also contain page B) would be shown if they were in the database.

at document C

If we think of the map representation as the highest level in the sense that it overviews a set of history information from a great virtual altitude point of view, then the trails representation is slightly lower level. The same interaction history information as was shown on a map can also be shown in the trails; however, the trails separate out the sequences. In this sense, maps are a merged set of trails. Annotations, presented below, are a level below trails.

Paths reveal even more about how users experience information, presumably because they come to the data space (Web site) with different needs or levels of interest. Figure 8 shows three different trails which exist in our database relating to a paper [2] written by Leonard Foner about an agent called Julia. In the Web-based version of the paper, it is broken up into different segments which can be navigated to in different ways. In Figure 8, the user is looking at the "Why Julia wins" section of the paper and we can see that there are three ways that people have used to get to this point.

In the least-used trail (bottom of Figure 8), users have started with the Agents group publication page, and skimmed the article, stopping after reading the "Why Julia Wins" page. More users (topmost trail in Figure 8) start elsewhere, presumably are less familiar with the concept of agents, and come to the "Why Julia wins" page only after visiting the page on "Crucial notions." These users then go on to other pages. Interestingly, the largest group (highest percentage) of users who visit this page come in from offsite, read several sections of the paper then stop (or go elsewhere). Note that there may be other users who visit other sections of the paper but skip this one. This example is interesting not because it shows anything particularly profound, but because it illustrates how three different models of how to read this paper can co-exist. We all "know" that writing papers on the Web is not like writing them in text, but as far as I know there has been no attempt before now to capture different ways that Web-based presentations are actually being read. History gives us a way to see these models and possibly manipulate them.

The next example, Figure 9, shows an interesting dichotomy in how people make and use Web pages. It shows two paths which include the home page of Pattie Maes, who heads the Software Agents group. In the more often used path (the bottom of Figure 9), people start offsite at the "PowerGrid Journal" page. This journal has reprinted an article written by Maes [11], and in the Web version of the article, each page is given its own Web page. People who make it through the article are curious, and follow a link from there to Maes' home page. Since their interest is in software agents, they then go on to read about the Software Agents Group by visiting our group home page.

A different group of people start off searching for sites about software agents and for some reason find themselves interested in the people who make such agents. They then follow a link to a page on our Web server which describes the people in our group, including Maes. These people, once they have gotten to her page, continue to be interested in her personally and visit her page of family pictures.

One of the hardest problems in classical information retrieval [13] is the question of deciding what a document is "about." Various solutions, such as keywords, abstracts, and machine-generated summaries have been tried, each with varying degrees of success. The more homogeneous a document is, the more likely these methods are to succeed. Home pages on the Web are an uniquely bad data set for this kind of technique, because they are so diverse and so heterogeneous. Even within a single person's home page there are likely to be a number of sections about quite different things. Finding a single thing which a home page (or even most Web pages) are "about" is a recipe for failure.

Interaction history solves this problem by allowing multiple senses of "about" to co-exist. In Figure 9, we see that Maes' home page is in some sense about Maes-the-researcher and also in some sense about Maes-the-family-person. This multiplicity is natural in our everyday lives where we all play multiple roles, sometimes simultaneously. Objects may have multiple uses: books can be doorstops or window props or even hammers in the right situations.

In addition, these multiple senses can aid our understanding. Earlier I argued that interaction history was valuable in part because it helped to provide context for information to which users can navigate. Figure 9 provides an example of this: we understand much better who Maes is if we can see her not only as the leader of the Software Agents Group, but also as a person.

On-board information: annotated pages

As noted above, one of the major aspects of interaction history is the degree to which it is connected to the object itself. The tools discussed so far -- maps, lists and trails -- all use windows separate from the user's browser window. We are also beginning to experiment with on-board information, in the form of annotations placed within the Web pages themselves.

Figure 10 shows a Web page with the annotations turned on. The annotations appear in the form of percentages attached to each link which can be detected in the HTML of the page. They represent the percentage of people visiting this page who followed each of the links off the page. This is, essentially, the same information as is present in the trails discussed above, but shown from a still "lower" point of view, in comparison to the view given by maps and by trails.

There are, however, some important differences. First off, the annotations are in numerical terms rather than the categorical (lightly used... heavily used) terms used to describe trails. Second, the annotations do not represent all the data that is available. Any links which exist but are not represented in the HTML of the document (for example in imagemaps or cgi-bin generated links) cannot be annotated.

In addition, the Web presents a number of difficulties for displaying on-board -- that is, highly connected -- interaction history information. The display parameters which one might manipulate in a traditional user interface, such as color, font type and size, and location of the displayed information, are all under the control of the page designer. An interaction history system which attempted to use any of these parameters for history display would risk obscuring or even destroying the very information which it was trying to augment.

This augmentation is key; we must remember that interaction history is not the point of the user doing the browsing and may in many cases not even be relevant to her accomplishing her task. If dealing with history information becomes the task, then we have done something wrong, much as someone who cuts pages out of a book may make impossible the later use of that book for its original intended purpose.

Even with these limitations, however, annotations may yet prove to be useful. They show very directly which options are of most interest to users; for example, in Figure 10 most people who visit the page are clearly interested in learning in about Programming by Example. Far fewer are repeat visitors (who likely clicked on "What's new here?"). In addition, the sum total of all the links followed is about one third of all the visitors. That is, two thirds of people who visited this page went somewhere other than to a page linked to this one. That indicates that either many people came to this page in error (which may be a problem with pages that link to this one), that this page answered their question or satisfied their curiosity, or that this page is simply not enticing enough. Separating out these reasons requires a different sort of history information, which is discussed in the Future Work section.

Behind the Scenes

The first version of the Footprints tools used a Java applet to create and control the maps. However, we wanted more flexibility and the ability to work with more browsers, so we changed our design for the current version. The current design is represented in Figure 11.

Figure 11 -- Footprints Architecture

In this design we use a proxy server, which is implemented in a Java program. This server handles communication with Web servers out on the net, but also includes a communication path to get data from the Footprints database. The proxy handles displaying the map and trail windows as well as inserting annotations into the Web pages, if the user requests them.

The use of a central database is an obvious drawback. In an ideal world, interaction history information would be present and kept with every digital object. However, until we reach that sort of world, we are using a central database for convenience and simplicity, even though this slows down the interaction by approximately a factor of two.

This architecture is primarily useful because it frees us from the constraint of depending on the browser manufacturers to support the latest versions of Java, which we may need. In most ways our proxy server is like any other, but it allows us to modularly control the HTTP stream into and out of the browser. This is convenient for us, as we wish to continue adding and testing different interaction history tools.

The proxy also has a simple control panel which allows users to individually turn on and off the various history tools. In addition, if users do not want to use the system, it is a simple button press to turn off the proxy in their browser's preferences.

There is also a Footprints Web site which allows users to download the latest versions of the software and to search the database for trails of interest, based on simple keyword matching.

Status and Future Work

The Footprints tools are presently being given to beta-test users. In addition, we are beginning a series of experiments to determine the effectiveness of interaction history information for a social navigation task.

One of the key unanswered questions in this project is exactly what history information should be shown in each of the tools. As noted in the discussion of maps, we are in fact showing very few of the possible bits of information that could be displayed. To some extent, this is based on advice and early experience [7] and a concern that showing too much history information would distract people from their primary tasks.

We are also considering ways in which various factors could be systematically applied as filters against the basic history information. So, for example, users might want to filter which paths they see based on how recently the paths have been used, or based on some measure of how "hot" the information is.

As noted above, the tools we have built so far concentrate on the passive side of Dimension 6. Version 3 of Footprints, which is currently in design and should be deployed this spring, will contain tools to allow users to input a more active form of history. Currently under consideration are tools which will accept comments on pages and trails that the user has seen or followed, and a mechanism to allow users to specify why they have visited a particular page.

Once these active-history tools have been designed they will also be tested. Similarity of purpose may turn out to be a useful filter, as noted above. However, we want to make sure that this project does not simply become another "guides" project in which people are encouraged to follow paths laid down by some authority [18]. Footprints is much more concerned with the ability of communities of users to allow their own uses of the objects to be seen.


It is early in the project to draw any grand conclusions. At this point, our efforts are primarily aimed at demonstrating that the idea of interaction history is a valid one and that we can indeed transfer from the physical world useful notions of navigation which can be appropriately applied to social navigation in an information space. The examples in this paper are intended to show that not only is this possible, but that even simple tools can be extremely effective in helping users accomplish tasks which are difficult or impossible without interaction history information. We believe we have demonstrated usefulness in four areas so far:

  1. discerning what kind(s) of experiences an information space might offer;
  2. expressing different ways of looking at a hypertext (Web) document;
  3. understanding different, orthogonal senses of a complex document;
  4. increasing understanding by providing multiple ways to reach the same information.

More tools need to be created, and more testing needs to be done, but I believe that the examples shown here hold promise for convincing others that interaction history can have useful and even surprisingly good effects on the problem of social navigation.


Copyright © 1998 Alan Wexelblat

Alan Wexelblat <>
Except where otherwise noted.
Last modified: Tue Mar 10 16:13:15 1998