A Preliminary Design for a 3-D Spatial User Interface for Internet Gopher Mark P. McCahill Distributed Computing Systems & Services University of Minnesota Thomas Erickson User Experience ArchitectÕs Office Apple Computer Introduction Internet Gopher is an information system used to publish and organize information on servers distributed across the Internet. Since its introduction in June, 1991 Gopher has become quite popular. In December 1993, there were over 4800 gopher servers accessible on the Internet, and well over 1.5 million items accessible in gopherspace. By March 1994 there were 6700 gopher servers accessible over the Internet. Gopher traffic across the NSFnet backbone has been increasing at an average rate of 20% a month during the last year, and GopherÕs share of the total NSFnet traffic has increased to about 3.5%. Because Gopher is a very distributed system, it is difficult to estimate the number of Gopher users. However, comparing GopherÕs portion of the NSFnet traffic to other popular protocols is a way to get a rough feel for GopherÕs popularity. Over the NSFnet, ftp makes up around 40% of the traffic, Netnews 10%, SMTP e-mail 6.7%, telnet 5.7%, and Gopher 3.5%. There are now at least 4 different Macintosh Gopher clients, 5 Windows clients, four clients for Unix/X-windows, two Amiga clients, a VMS client, and even Gopher clients for MVS and VM/CMS. All these clients have conceptually similar user interfaces. The typical gopher client present users with a directory hierarchy to navigate. Each gopher directory the user encounters may contain documents, search engines and other directories. The items in the gopher directory have both a content type associated with them and a name to be displayed to the user. Gopher clients traditionally display different icons for the various items and list the item names next to the icons while while using the name of the directory as a title of the window containing the directory. Some clients restrict the user to viewing each successive directory in a single window, while other clients allow for multiple windows (each successive directory is displayed in a new window). Gopher clients provide no representation of a Gopher Server as a whole (such as a diagram of the hierarchy); servers are represented simply as the root directory in a hierarchy. The aim of this paper is to sketch out a design for a new, 3-D space user interface for Gopher, and to capture some of the rationale behind the design. The design is motivated by a mix of pragmatic and exploratory impulses. On the one hand, there are several usage problems that would be difficult to solve within the constraints of the current interface metaphor. And, on the other hand, the advent of RISC-based personal computers means that there will be sufficient power to support a whole range of new behaviors, offering the prospect of transforming information systems into more flexible, information-rich environments. We will begin with a brief discussion of the motivating factors, and will then describe the initial design; comments on the design rationale will be inserted where appropriate. Problems and Prospects While the current user interface is popular, there are a number of well known usage problems: ¥ The lost-in-space problem. Users complain of feeling lost after navigating for a while and have difficulty remembering where they found an interesting item. In part, this due to the absence of any global representation of the structure of information hierarchy, and in part because the path followed by a user is either invisible or, at best, implicitly embodied in a stack of directory windows laid on top of one another. Users need an overview of gopherspace, within which they can see their locations and the paths they have followed. ¥ The grouping problem. Within a directory it is difficult to show relationships between items represented in a linear list. Some server administrators resort to putting items with blank names in their directories to group clusters of items. An analog of this problem occurs in lists of results generated by search engines. The results are typically sorted by relevance (as ranked by the search engine), but the user interface doesnÕt have a good way to convey their relative relevance. And, as in directories, it is difficult to show the clustering of related sets of documents. Ideally, both relevance to the search terms and ÒclosenessÓ to other documents (along a variety of user- specifiable dimensions) ought to be visible to the user at a glance. ¥ The browsing problem. It is difficult to browse because documents reflect so little of their content. All that is available is the itemÕs name and the information about the documentÕs type embodied in the icon.The userÕs only other option is to open the documentÑoften a time consuming processÑand see everything in the document. Neither option is supportive of browsing: users need to see more information about the content of a document without there being so much that they are unable to compare and contrast different documents. Such document representations will be referred to as proxies. In addition to remedying todayÕs usage problems, there are a number of intriguing prospects which a new interface could open to exploration: ¥ Leveraging social intelligence. Users browsing a large information space could benefit from the discoveries of previous visitors. Indications of the popularity, utility, or quality of particular documents, directories, or servers could be useful. Sometimes this information could be generated automatically by the client in response to user activity; or it might be interesting to allow users to attach comments and critiques to documents. Similarly, users with expertise in particular areas might create, define, and annotate documents relevant to a particular theme. ¥ Sense of place. Today, gopherspace is generic: any gopher directory looks just like all the others, regardless of where it is or what it contains. Providing a sense of place means moving from the generic to the particular, making it possible for an area of gopherspace to reflect something of its contents, and something about those who construct it, maintain it, and frequent it. The ability to provide a sense of place would have benefits for both administrators and users. It would provide a way for administrators to put their own personal stamp on their segment of gopherspace. Server administrators would like to be able to customize their areas, but, needless to say, given the constraints of a linear list of names and icons, opportunities for doing this are quite limited. Supporting customization by administrators is important because many Gopher servers are maintained by volunteers with little or no institutional support or recognition; anything which can increase the gratification administrators receive from their efforts will ultimately benefit gopherspace as a whole. Users too would benefit from a sense of place, in part because it is entwined with the ability to leverage social intelligence. In addition, providing such collectively generated traces enhances the sense of place, and transforms Gopherspace from something ÔownedÕ primarily by server administrators to a more public, collectively shaped sort of space. Given these capabilities, it is natural that some places will evolve into navigational landmarks. ¥ Information-rich environments that support human-human interaction. Turning to a data space for information is often a last resort; in many cases, people prefer to get information from other people. In fact, sometimes people search for documents, only as pointers to their authors. In a very real sense, a comprehensive data space will include people, not just documents. In a similar vein, although information access may be engaged in just for the fun of it, it is more often the means to some larger end. That is, people seek information because they are trying to solve a problem, test a theory, understand a concept, or communicate their understanding to others. In these cases, there is little reason to segregate information access from the other activities. The increasing computational power and bandwidth that is now available offer the prospect of moving from information-only spaces to information-rich environments which can support a broad range of activities. Initial Design Criteria The problems and prospects we have just covered map fairly cleanly into a few general design criteria. ¥ Richer representations for servers, directories, and documents. The lost-in-space problem suggests the need for a high level overview of gopherspace and landmarks. The grouping problem indicates the need for a representation of collections of documents that can represent their similarities and differences along a variety of dimensions; we shall refer to such representations as neighborhoods. Similarly, the use of proxies Ñ richer representations for individual documents Ñ would alleviate the browsing problem. ¥ Dynamic representations. Representations need to be able to change over time. Sense of place requires representations that can be customized by administrators and perhaps end users, and leveraging social intelligence requires representations able to reflect the interaction history of individual documents and collections of documents. ¥ Need for availability and addition of meta-information. All of these changes to the representations of components of Gopherspace require that meta-information about servers, directories, and documents be made available via the Gopher protocol. The prospects of providing a sense of place, and leveraging social intelligence, also involve adding meta- information, but this time the meta-information is external to gopherspace Ñ it is applied by users, or inferred by the system based on user interaction. Finally, meta-information will be required to support interactions among users. ¥ Backward compatibility. There is a final, very important, criterion not suggested by the preceding discussion. It is important to recognize that there is a large installed base of Gopher servers and clients, and a community of administrators and end usersÑGopher is as much a social phenomenon as a technology. Backward compatibility of any new client is essential for acceptance. It will be impossible to change all of gopherspace overnight, so any new client must handle both servers that have stored additional information (e.g., about relative clustering of items in document collections) and ancient unmodified servers. This must be done without stepping outside the new user interface metaphor. Client software that can synthesize the spatial scene from current gopher directory and item meta-information allows us maintain compatibility with all of the current gopher servers. A happy side effect of this approach is that server and network bandwidth demands are minimized since we do not require servers to render scenes and ship bitmaps of the scenes over the network. Backward compatibility issues are also addressed by using the Gopher+ protocolÕs item attributes to hold meta-information. Gopher+ item attributes provide an open-ended, extensible way of associating arbitrary meta-information with items and directories, and methods of accepting information sent from the client, so the user interface we propose will not require a new protocol. Why a 3-D spatial interface? First, note that 3-D space as a metaphor for information is nothing new; it is deeply embedded in our language. Without thinking about it, people use spatial and object-centered terms for discussing abstract concepts. We speak of getting overviews, seeing things from different perspectives, and grasping new ideas. Providing a 3-D spatial interface is, in part, just providing a concrete embodiment of language we already use. A 3-D spatial user interface for Gopher also allows us to address the problems and prospects weÕve just discussed. 3-D spaces give us more variables with which to construct the richer representations we need. For example, relationships between documents Ñ either manually defined by server administrators or automatically generated by search engines returning a set of hits to a query Ñ can be shown by various arrangements of document icons in a space. 3-D spaces can also give the user a stronger sense of place and minimize the feeling of being lost. If there are enough provisions for server administrators to customize the attributes of the space, a better defined sense of place will evolve and users will treat some collections of items as landmarks in gopherspace.Variables that server administrators can customize should include a texture (bitmap) which is painted onto the surface of 3-D icons and the relative position of 3-D icons. Another very valuable property of 3-D representations is that they implicitly include two representations: a surround view when you are "in" the 3-D space (suitable for viewing collections of documents), and a bird's eye view when you are "above" the 3-D space (suitable from providing the overview). The fact that the same conceptual model provides two different representations which are connected in a well understood way (and, in fact, which permit the transition from one to another to be shown) is very powerful. Another advantage of 3-D space is that it is familiar; people understand a lot about space. They are familiar with navigating space since this is something they do everyday of their lives to get from one place to another, and to manipulate objects and tools. Since people have little experience flying through space, we intend to implement constrained navigation, so that the user experience is something like driving a car. People also know that finding things in a space is not particularly easy (thus, we may be able to avoid raising expectations too high), and have a learned repertoire of techniques for finding things (consulting maps, following paths, asking a passerby) that can be embedded in the metaphor. Finally, when we are ready to put real-time IRC/talk capabilities into gopherspace, 3-D spaces provide a natural way of supporting interaction between people. As human beings, we understand a lot about the social characteristics of spaces.We understand the distinction between public and private spaces; we know that you have to pay to enter some spaces at which time you gain temporary rights to that space. We understand that particular activities, people, rituals, and behaviors are associated with particular types of spaces. We have spent out lives learning to recognize spatial cues: what entrances look like, what a bulletin board is, where you are likely to find a you-are-here map, and so on. All this knowledge can be leveraged in a spatial metaphor. Besides, itÕll be loads of fun. The Preliminary Design In this section we sketch out the preliminary design for the interface, with some comments on the rationale for various decisions. It is important to emphasize that this is the starting point, not the ending point. In general, the preliminary design is based on a combination of analysis and intuition; at this point, no testing or prototyping has been done, with the exception of a few mock-ups of 3-D icons and neighborhoods generated to facilitate discussion of how to design legible 3-D icons, and how to support navigation among them. We take it as a certainty that as we proceed both implementation constraints and feedback from prospective users will shape the design in major and unforeseen ways. For expository purposes we will describe the preliminary design in terms of three levels of representation Ñ the overview, the neighborhood, and the individual item. We will begin with the neighborhood, the representation for a collection of items with which the user is interacting. Next we will examine some details of the 3-D icons used to represent individual items. Finally, weÕll look at the representations which provide the overview of a particular server, and of gopherspace as a whole. In describing how users might interact with these representations, we will mostly focus on near future scenarios in which Gopherspace is still primarily used as an information system, with occasional allusions to farther out possibilities. The Neighborhood The neighborhood is the representation of the collection of items with which the user is interacting. Neighborhoods are either constructed by server administrators (as a directory in the the serverÕs file hierarchy) or generated by search engines in response to a user-entered query. Figure 1: the circular ÒStonehengeÒ icon arrangement. The Arrangement of the Icons We explored two representations of neighborhoods: circles and ÔstreetsÕ. Circular arrangements of items have a number of strengths. First, the user will generally have a straight on view of the fronts of a couple of 3-D icons, which is valuable because the fronts of these icons will generally contain details of their content. Since the user enters the neighborhood near the center of the circle of icons, the user is always going to be looking at something and it is difficult to drive off into limbo. A second useful property of a circular arrangement is that it is easy for the user to understand: the user can quickly get an idea of how many icons are in the neighborhood (based on the density of icons and the radius of the circle). The circular arrangement of icons defines an enclosed space that may be used as a collective gathering space for users. The circular arrangement also defines a center point, at which we will place a 3-D ÔkioskÕ icon that will function as the userÕs link back to the previous neighborhood, and as a sort of information desk for the neighborhood. If we allow for display of user-entered comments from the people who have visited this directory (i.e. graffiti) this should also appear on the kiosk. The street metaphor was investigated and rejected because the user is either facing down the axis of the street and has an oblique view of most of the faces of the icons, or is facing one side of the street and is required to turn fully around to view the next closest icon. It also may be difficult for users to tell how long a street is, and unless the street is short, it really has no center or natural gathering point. Finally, simple mock-ups of streets in a 3-D modeling program resulted in arrangements that felt very claustrophobic, since fairly large 3-D icons were necessary for information display purposes. A variant of the circular arrangement of items is the spiral.We intend to use the spiral arrangement for collections of icons generated by search engines in response to user queries. Formally, the spiral has a nice family resemblance to the circular arrangement so that it too defines an enclosed area with a center point; at the same time, its greater openness and dynamicism seems a good reflection of the transitory nature of most queries. Also, a spiral has directionality, and thus provides a natural ordering within which the relevance of items to the query can be reflected. That is, the more relevant the items, the closer they are to the root of the query; and, more generally, a search that returns a large number of very relevant items will have a tightly coiled spiral, whereas one with few relevant items will have a very loose spiral. figure 2: results of a search arranged in spiral fashion. Sound We intend to support the use of sound as a representation for a neighborhood. Sound is valuable because it can maintain the sense of being in a particular place, even when the place is too big or complex to be shown all at once. Server administrators should be able to define a digitized sound for sound-savvy clients to play while the user is within the directory... hopefully unobtrusive sounds similar to some of Brian EnoÕs ambient music. Sound can play a variety of other roles. It may be used to reflect activity of other users in the same or nearby neighborhoods. Variations in its timbre could be used to give hints as to the size of the neighborhood. Sounds could also be used as part of the proxy of an item, perhaps brought into play when a user comes near the icon: a directoryÕs proxy might use sound to give a hint of what the new neighborhood is like before the user enters it; a documentÕs proxy might use whispered text-to-speech to provide more detail about a documentÕs content.To make sound a common part of all 3-D space will require synthesizing sounds for gopher servers that do not provide a server-defined sound. Having the client software generate an ambient wind sound attenuated by the number (and type) of objects in the scene is probably the best approach creating sounds for servers that do not have their own. By making the attenuation of the ambient wind sound depend on the objects in the local space we can get automatically create variation in tone and timbre. Wear If usage information is available from the server, footprints (or some sort of dirt on the ground) can be used to show which of the items in the neighborhood are the most popular.This is like the worn marks on subway platforms in New York. You can predict where the doors of the subway train will be when it stops by looking at the worn spots on the platform. The same sort of cue can be used in a neighborhood to show users who want to follow the beaten path, where that path lies. The 3-D Icons 3-D icons vary along four dimensions: their form, their color, their texture, and the information about their content displayed on their fronts (this information is called a proxy). The basic form of a 3-D icon is a rectangular box with a top that represents the type of the object. Box-like icons are attractive since they keep the scene rendering requirements to a minimum by keeping the number of polygons down and simplifying hidden surface removal. Box-like objects also provide plenty of space to map textures, draw items names and other information, and can look vaguely like buildings people encounter in life. The Forms of 3-D Icons The general form of the icon indicates the type of object it represents: the constraints on the iconsÕ forms are that the iconÕs type should be recognizable from any direction (and ideally from a distance), that most icons have a large, flat surface area on which its proxy may be displayed, and that the form be relatively simple so that large directories displayed by clients on low-end machines not take excessively long to render. Figures 3 through 8 show initial passes on the forms for types of icons thus far envisioned. Figure 3:Document icon. Figure 4. Neighborhood icon Figure 5.Search engine icon Figure 6:interactive session icon Figure 7: Person icon Figure 8. Kiosk icon Color of 3-D Icons At the moment our intent is to use color as redundant information, to indicate the type of the icon. The advantage of this is that it will allow types to be distinguished in overviews. Dynamic Proxies The face of the 3-D icon is divided into areas used for the name of the item and the proxy. The title of the item is written across the top: on document icons there is a ridge wrapped around the icon about 80% of the way up the icon where the title is written; other icons have the title in the same location but without the ridge. Below the title is where the proxy is displayed. The proxy reflects something of the content of the object represented for the icon: for a picture, it might contain a thumb-nail sketch; for a text document it might contain key words; for a new neighborhood, it might contain an indication of the neighborhoodÕs size. On a layer underneath the proxy, and over all the rest of the 3-D icon, a server-defined texture map is displayed As the user approaches a 3-D icon, the amount of information displayed on the icon changes since there is more screen real estate to use for display and the user is presumably more interested in the item. From a long distance, only the general outline and color of the icon is readily discernible. At middle distance the texture map and name of the icon are visible. At close range, some proxies for the information within the icon become visible. What the proxies are will vary depending on the type of object. Directory icons may show a rough rendering of the content of the directory (i.e. the number and arrangement of the icons contained in that directory). Document proxies are probably the first part of the document or a diskette icon to show that the contents is a binary file. The document proxy referring to a Quicktime video might contain the poster view of the video, while a sound proxy might by an ear icon (or perhaps the sound plays at low volume?) When the user puts the mouse pointer over an item it may also develop a door or door knocker. Double clicking opens the item. Opening a document could result in a new window being displayed on the screen with the document contents inside. Alternatively the content of the 3-D icon for a document could be displayed on its face. Opening a directory results in a transition to a new directory (see the transition between directories section below Representing Overviews of Gopherspace We have not yet completely resolved how to represent overviews of sections of gopherspace larger than a neighborhood so the design in this section is very preliminary. However, such overviews are a valuable addition to the user interface; there are two sorts of overviews that users would like to have while navigating gopherspace. First, a map of items on the current server or items within a few hops of the current neighborhood (i.e. a regional overview) is appealing since this would help users understand what sort of neighborhood they are inside. This sort of local overview would also be useful as a proxy to be displayed for the neighborhood. The other sort of overview that users would like is map of large portions (or all) of gopherspace. Because Gopher is a distributed system without a compulsory server registration, there is no global list of all servers in gopherspace. In fact, maintaining such a list is a daunting prospect given the growth in number of gopher servers (3400 in September 1993, 4800 in December 1993, 6700 in March 1994). However, a map of the neighborhoods that the user has visited is feasible since the Gopher client software can build the map dynamically as the user explores new neighborhoods. Alternatively, some users may wish to download maps of Gopherspace, or portions thereof, from a global map server. Representing a NeighborhoodÕs region To represent a region, the client software explores the in vicinity of the current neighborhood by opening Gopher neighborhoods connected to the current neighborhood to some predefined depth (perhaps 3 hops). Once the client software has queried Gopher servers to build up an internal list of neighborhood contents in the region, an overview can be displayed to the user. One possibility for representation of the region around a neighborhood is to use PARC cone trees. Another possibility is to use 2-D projections of gopher hierarchy; the circular ÒStonehengeÓ neighborhood have a nice, legible circular projection as do the spiral neighborhoods which result from queries. Such an overview could look like figure 9. Figure 9: 2-d projected Overview Representing large parts of Gopherspace While 2-d projections of neighborhoods can be generated for a static region, representing a dynamically growing space using a Euclidian plane is problematic if users expect the neighborhood to stay in the same location and relative spatial relation to each other. The problem is that the layout of the overview changes and grows as the user explores gopherspace, and there may not be room to display a new neighborhood without moving the projections of neighborhoods already displayed (figure 10). Figure 10: Before and after exploring reference to neighborhood D To avoid this problem, either a non-Euclidean space or a different approach used (such as PARC cone trees). A non-Euclidean space would be something like a rubber sheet with neighborhoods acting like rocks on the sheet. The sheet would be stretched as new neighborhoods were added close to existing neighborhoods; how successful such a metaphor would be with users is open to conjecture. Navigating Gopherspace Navigating within a neighborhood Most people are familiar with navigating 3-D spaces since this is something they do everyday of their lives to get from one place to another. On the other hand, most people have little experience flying through space, so by limiting the number of options the user has for flying into limbo, we can make the user experience similar to some of the better arcade style games (like Spectre). By limiting the userÕs navigational controls to forward and back turn left, turn right we can make it easy to learn how to use the interface. By limiting the height of the 3-D icons, we can ensure that the iconÕs proxy will usually fit within the userÕs field of view, and thus we neednÕt worry about providing ways to look up or down, or left or right. Transition between neighborhoods When the user double-clicks on a 3-D icon representing another neighborhood, a bit of user interface sugar should be used to make it clear to the user they are traveling somewhere else... a rough equivalent of the zoomrect transition used on the Macintosh when an icon is opened. This is applied to directories, to search engines, and when the user double clicks on the central kiosk of a directory. If we handle this properly, it can also give the user something to look at while the client software sets up and renders the next neighborhood the user will view. For the neighborhood-to-neighborhood transition, the user automatically is sent on an trajectory leading them out of the current neighborhood and into the new neighborhood (show in figure 11). The trajectory starts with the user flying into the 3-D icon representing the neighborhood, then ÔflyingÕ over a grid. Flying here is flying in the sense of riding in an airplane as opposed to actively piloting a plane. figure 11: trajectory between directories The amount of time spent in flight depends on how long the software needs to fetch the information from the appropriate gopher server and render the next neighborhood. Once the next neighborhood is ready to be displayed to the user the flight over the grid ends with an approach over (and then down into) the new neighborhood. The user can get an idea of the general layout of the neighborhood during the approach and landing. The idea behind this trajectory is to give the user an increasing sensation of motion as they leave the immediate vicinity of the neighborhood they were in (take-off in a plane rising up from the current neighborhood), followed by a few seconds of apparent high- speed travel travel over an anonymous looking grid, culminating with a slow approach to the new neighborhood. It is important that the approach to the new neighborhood allows the user see the general arrangement of the neighborhood. To make this visible, the userÕs trajectory is one of swooping down from above (like a plane landing). The user is deposited near the central kiosk facing so that both a part of the kiosk and some of the items in the neighborhood are visible (figure 12). figure 12: initial view on entering a new directory Next Steps By default, the Gopher client generates the geometry and layout of the neighborhood within the userÕs computer, but it is important to allow server administrators some control over how clients display the neighborhood. The sorts of controls a server administrator could have are: layout within the neighborhood, sound, textures mapped onto icons, wear (usage information), and icon geometry. For an initial implementation, we plan to allow server administrators to define texture attributes for Gopher items (as a Gopher+ item attribute). Textures (bitmaps) are easy to generate and carry a lot of information; most server administrators do not have 3-D geometry design tools. Eventually we would like to allow mapping Quicktime or MPEG video onto the icons for a real Las Vegas-style user experience. Eventually the intention is to allow server administrators to design their own 3-D icons by defining the icon geometry for the client, but there are serious potential problems with ornate designs that take to much processing power to render in an acceptable time. Once server administrators can create their own icons, clients must take steps to protect themselves from badly designed icons. Since the client has no assurance the server administrator has done consistency checking, the clients would have to employ local zoning restrictions by refusing to render icons with excessive numbers of polygons (or non-convex polyhedra, or other items beyond the limits of the clientÕs 3-D rendering engine). Another issue that arises once server administrators can design their own icons is maintaining some sort of consistency for the user so that they are not confronted with neighborhoods where everything they know is wrong. When server administrators can design their own 3-D icons, we will strongly advocate that the tops of the icons remain the same throughout gopherspace. This will allow users to assume that if the icon has a slanted top, is is a search engine. Also, the basic box shape will probably be strongly mandated since clients software expects to be able to map textures and names onto the surface of the icons. Rather than try to implement customized icons initially, we think it is much more valuable to implement sound playback in the clients. Again, like textures, there are a variety of tool for creating and manipulating sound and it is easy for a server administrator to associate a Gopher+ item attribute containing a reference to a sound with an item or a neighborhood. Textures and sounds are very high priorities for implementation, but once these have been implemented, it makes sense to allow the server administrator some control over the layout of the icons in the neighborhood. This again requires clients to employ their own local zoning ordinances to check the reasonableness of the layout (disallowing overlapping polyhedra, for instance). The server administrator would define relative locations of items within the neighborhood as a Gopher+ item attribute. Conclusions As this is a report of work in progress, we have no real conclusions, as yet. It is worth noting that even in these earliest stages of design, we have had to deal with issues that lie outside the realm of the disciplines traditionally involved in interface design. What forms should 3-D icons have so that they are both simple and yet recognizable from many directions. What types of spatial layouts can help people remain oriented in a large space? What sort of layouts are legible both from the inside and from far away? How rapidly should a transition into a new spatial layout occur, so that the user can take in enough information to be oriented, but avoid boredom? Acknowledgements This paper is based on dreams and discussions that have been going on within part of the Gopher software development team (Paul Lindner, Farhad Anklesaria, David Johnson, Neophytos Iacovou) at the University of Minnesota over the last two years. We have also learned from the work on YORB, carried out by Dan OÕSullivan and his colleagues in the New York University School of Interactive Telecommunications. References Bush, V. As We May Think. Hill, et al. & Wroblewski, et. al. on soft-wear.