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. We expect the implementation of the design will proceed through (at least) two stages: first, we will focus on creating a 3-D information space; only later will we integrate the functionality necessary for supporting social interaction.
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 the 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. Then we'll look at the representations which provide the overviews of regions and of gopherspace as a whole. Finally we will describe interactions in gopherspace, including: opening documents, navigating around a neighborhood, moving from one neighborhood to another, and user-user interaction.
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 2. 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 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 3. Results of a search arranged in spiral fashion.
Sound
We intend to support the use of sound as part of 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 (Gaver, et al, 1991; Cohen, 1993). Variations in its timbre could be used to give hints as to the size of the neighborhood (Gaver, 1989). In the physical world, sounds also play an importnat role in supporting the feeling of a sense of place (Southworth, 1969).
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.
Interaction Traces
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
In our design, 3-D icons can vary along three dimensions: form, surface characteristics (color and texture), and information about the icon's content (name and proxy).
The Forms of 3-D Icons
The basic form of a 3-D icon is an approximately rectangular box 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 that people encounter in life.
The 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 4 through 9 show initial passes on the forms for types of icons.
Figure 4. Document icon.
Figure 5. Gateway icon
Figure 6. Search engine icon
Figure 7. Interactive session icon
Figure 8. Person icon
Figure 9. Kiosk icon
The objects represented by the icons are mostly analogous to types of icons in gopherspace today (documents, search engines, interactive sessions, and gateways to other directories). Two new types are kiosk and person icons: kiosks have been described in the preceding section; person icons are place holders for icons which will represent users when the environment is able to support synchronous social interaction.
Surface Characteristics of Icons
Surface characteristics of icons include color and texture. 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. Texture is a variable the server administrators will be able to customize; they will be able to define the texture as a bitmap that will be painted onto the surface of the icon, and onto which other information (e.g. proxies) will be mapped).
Information about the Content of the Icon
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. Researchers have suggested a number of possiblities for proxies which would be interestingto explore in this context (Houde, et al. 1993; Wroblewski, et al., 1994).
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 since 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 proxies for the information within the icon become visible; as the user approaches even closer to an icon, more information might become available.
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. Sounds could also be used as part of the proxy of an item, perhaps brought into play when a user comes very 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; and of course icons for audio and video files could just play part of the soundtrack.
Representing Overviews of Gopherspace
The purpose of an overview is to give users a glimpse of the larger context in which they are situated. In the current design, all overviews take the form of 2-D maps, which can be brought up in a window separate from that containing the 3-D view. There are three sorts of overviews that seem likely to be of use: an overview of the neighborhood; an overview of the local region of gopherspace; and an overview of all of gopherspace.
Overview of the Neighborhood
The collection of items will either be the current directory or the results of the most recent search. The overviews will 2-D projections of the neighborhood as seen from overhead: that is, either the "stonehenge" arrangement or a spiral of icons. Colors will enable users to distinguish the type of the icon (since, in a 2-D projection this will probably not be readable from the icon's form).The specific ways in which these overviews will be used is yet to be determined, but such views could obviously provide the user with a you-are-here orientation, and a way of quickly assessing the size and relative proportion of icon types in a particular collection. A miniature version of this overview could also be used as a proxy for a gateway icon.
Overview of the Region
We haven't decided precisely what a region should be. We will take as our working definition that a region is comprised of the current neighborhood, neighborhoods directly connected to that neighborhood by gateways, and (perhaps) neighborhoods connected to those. An alternate possiblity is to define the region as the server the user is currently on. Note that since any of the gateways may be to directories on different servers, the two definitions of a region are quite distinct, rather than the second being a superset of the first. One consequence of this is that the first type of neighborhood will have to be computed on the fly by querying other gopher servers for the structures of relevant (i.e. connected) neighborhoods. Given a definition of a region, the region overview will be generated in the same way as that for the individual neighborhood (see figure 10 for an abbreviated example).
Overview of Gopherspace
Finally, an overview of all (or at least large portions) of gopherspace would be useful. However there are two practical problems. First, it is difficult to identify the contents of gopherspace. Because Gopher is a distributed system without a compulsory server registration, there is no global list of all servers in gopherspace. 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). The second problem is that the contents of gopherspace are constantly changing: new servers come on line, other servers go off line, directories are added, deleted or reordered, and items are added or deleted. The most feasible alternative is to encourage individuals within the Gopher community to use software to generate maps, which could be made available on map servers for those who wish them. Although it may strike the reader as a case of wishful thinking, similar efforts have produced gopher-related tools like Veronica and Archie.
Assuming the existence of a relatively up-to-date list of the contents of gopherspace, the question of how to represent the overview of gopherspace remains to be dealt with. Given the magnitude of Gopherspace--thousands of servers, millions of items--representing it (or even significant subsets of it) with miniature 2-D projects of the neighborhood is out of the question. Even were this possible, representing a dynamically growing space using a Euclidian plane is problematic: when new servers, neighborhoods, or items are added, the new items must be put somewhere, and this will often result in distorting the structure of the overview. This is a problem insofar as one of the purposes of an overview is to provide a consistent frame of reference for the user.
A solution that addresses both of these problems is to use a more symbolic overview, projected on a frame of reference that is independent of the content of gopherspace. The obvious candidate is a map of the physical world. This has three advantages. First, people are relatively familiar with the structure of the physical world. The advantage here is simply one of mnemonics: people have a better chance of remembering where they saw something interesting if they can associate it with a known physical locale (in fact an ancient mnemonic technique known as the method of loci is based on this). The second advantage of a map of the physical world is that although Gopher servers can, in principle,be located anywhere, in fact they are often located in physical proximity to the groups the maintain them. Thus, the relationship between real world location and the type of information server found there is not wholly arbitrary. Thus, someone interested in information about visiting Japan might well want to look for Gopher servers in Tokyo; someone interested in Artificial Intelligence would be well advised to search MIT, CMU,and Stanford for servers; someone interested in Blues music might try New Orleans or the Smithsonian. The third advantage of a map-based overview is simply that we believe people will like it. It will emphasize their ability to virtually travel across the world, finding information in various locales, and will give people a sense of power and excitment.
In the absence of programmatically generated overviews of gopherspace, one initial step would be to have the client construct overviews of the areas of gopherspace that the user has visited. While this will be useful only for seeing where one has been, and not for aiding exploration of new areas of gopherspace, it is better than nothing. And this would provide placeholders in both the user interface and protocols for more comprehensive overview information that may eventually become available.
Interaction in Gopherspace
In this section, we briefly summarize the sorts of interactions that can occur in 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.
Interaction Details: Steering and Opening
We have not yet decided on how to carry out interaction at the most basic level. It will be desirable to open (and therefore to select items); and it will be necessary to start, stop, and change the direction of movement in Gopherspace. One possiblity is to ignore selection, and to allow items to be opened by driving into them (O'Sullivan, 1994). Alternatively, we can allow users to navigate around the space, and then select items and open them. In this case, either screen controls will be needed for one or both options, or use of the command key with the mouse will be necessary to disambiguate between the steering and opening modes. Onscreen controls seem to be the better option, both in terms of ease of learning and use, and because they could support a wider range of low level operations. For example, a single click might be used to choose an option to scan the neighborhood, taking the user on a circular path around the inner periphery of a neighborhood -- if clicks, and click-and-holds were used to steer, this could quickly become physically tiring).
In most cases, opening an item would result in a new window being displayed on the screen. If the item is a document, the window would of course contain the contents of the document. If the item was an interactive session or search engine, it would contain whatever prompts are generated by session host or search engine. If the item is a gateway to a neighborhood, 'opening' the gateway results in a transition to the new neighborhood. If the item is the kiosk icon in the center of a neighborhood, it returns the user to the previous neighborhood.
Transition between Neighborhoods
When the user 'opens' a gateway, visual and sonic feedback should be used to make it clear to the user they are traveling somewhere else; this is a rough equivalent of the zoomrect transition used on the Macintosh when an icon is opened. This happens when a user enters a gateway or kiosk, or executes a search on a search engine. If we handle this properly, it should 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 goals is to produce the experience of entering the icon, emerging into an open space, and zooming into the new neighborhood (shown in figure 12). The experience would be something like a roller-coaster ride, as the user follows a predetermined course and cannot steer. If the neighborhood is on a different information server, the first part of the 'ride' might be through an abstract grid, representing a transistion between servers. 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.
Figure 12: Trajectory between neighborhoods.
The idea behind this trajectory is to give the user a sensation of 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 so that they can get a sense of the number and type of items in it. 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 13).
Figure 13. Initial view on entering a new neighborhood
Interacting with Other Users
The details of this remain to be worked out. However, as a very rough first pass, we'll assume that interaction occurs in a MUD-like fashion using MUD conventions, with a separate window appearing to support textual dialogs between different users in the same neighborhood (see Curtis, 1992; Bruckman & Resnik, 1993; Erickson, 1993; Rose, 1994 ).
System Architecture, Protocols, and Zoning
The 3-D user interface described here will be rendered and managed entirely by the client software. No changes to Gopher servers will be required, at least for the information environment phase of the implementation. 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.
An exception to this client-centered approach arises when we allow server administrators to control over the appearance of servers they administer. By default, the Gopher client generates the geometry and layout of the neighborhood within the user's computer, but sense of place requires that we provide administrators with control over things like the layout within the neighborhood, sound, textures mapped onto icons, and perhaps icon geometry. We have reached no final decision on what to do, but our plan for the initial implmentation is to send the client formulae for server-specific textures and sounds (as Gopher+ item attributes), which the client can then recognize. Sounds and textures (bitmaps) are easy to generate and carry a lot of information; most server administrators do not have 3-D geometry tools needed to facilitate modifying icon geometries. Eventually we would like to allow mapping Quicktime or MPEG video onto the icons for a real Las Vegas-style user experience.
An open question is how much control to give server administrators over the look of their areas. On the one hand, server administrators could be allowed to design their own 3-D icons; they could define the icon geometry, which would then be shpped to the client for rendering. However, there are several possible problems here. Two of the most serious have to do with efficiency and consistency. For example, ornate designs might take too much processing power to render in an acceptable time on all platforms. Once server administrators can create their own icons, clients must take steps to protect themselves from badly designed icons; the clients might 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). Similarly, once the server administrator has control over the layout of the icons in the neighborhood, clients will need to employ their own local zoning ordinances to check the reasonableness of the layout (disallowing overlapping polyhedra, for instance).
A more serious problem is that of consistency: users would presumably like to be able to recognize particular types of documents, regardless of what server they're on. Users entering a new neighborhood that happens to be on a different server should not have to stop and figure out what a document icon looks like in this neighborhood; there should be a family resemblance that users can rely on. One solution is to allow the form, or a portion of their form (e.g., the tops of the icons) of the icon to stay constant throughout gopherspace. This would 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 the client expects to be able to map texture, names and the document's proxy onto the surface of the icons.