[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

A Preliminary Design for a

Found at: cyber.dabamos.de:70/gopher/gophercon/gc94/papers/3Dgopherspace.txt

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.

		

		

		

NEW PAGES:

[ODDNUGGET]

[GOPHER]