Well-Constructed Gophers: Is Your Gopher Golden?

Since its release into the public domain, the University of Minnesota's Gopher1 software has grown into one of the de facto standards on the Internet. The reasons for this are many and perhaps ineffable, but clearly the hierarchical interface provided through the Gopher client/server is relatively easy to use (cf. Archie/FTP), and relatively easy to set up and administer. As librarians and others begin to include networked information resources in their collections, many will strive to select high-quality Gophers and create high-quality Gopher servers. This article is successful if it can help information professionals in both the creation and selection of Gophers.

In the fall of 1993, several librarians at Indiana University created the Indiana University-Bloomington Library Gopher Server (IUBLGS) to serve the needs of the Indiana University community. The administrators of the IUBLGS aimed to simplify access to existing local electronic resources while providing access to newly-accessible Internet resources. Future development of the IUBLGS will stress its role as a reference collection for end users who are not in the library building.

Through interviews with the creators of the IUBLGS, and informal electronic surveys with network users, I have developed a general schema for the appraisal of Gopher servers. The schema directs evaluators to analyze Gophers on anatomic grounds, and to consider contextual factors such as selection and accessibility. The utility of such a schema derives from its simple application in assessing and improving resources, as well as in the possible stimulation of discussion.

I. Introduction/Motivation

Many casual users of Gopher rely on the hierarchical structure imposed on the information contained in the Internet by the individual providers and administrators of the various Gopher servers. At present, many Gopher administrators have put little effort into organizing their Gopher. Just as much of the rest of the Internet, "Gopherspace" (all the Gophers in the world, taken collectively) is still largely an anarchy.2 Thus, it is imperative that librarians bring their experience and skills in organizing information to the Internet. At this early stage, some libraries are bringing up Gophers; hopefully, these Gophers will set an example for others who are attempting to organize Gopherspace and the Internet writ large.3

On a rather obvious and important level, if the language used in the Gopher directories is ambiguous, obscure, or misleading, users may have great difficulty identifying relevant resources. A fundamental assumption of this article is that critically-minded Internet users can analyze certain aspects of "Gopherspace" to identify characteristics that make certain resources more accessible, useful, helpful, or whatever users want to get out of them. For the rest of this article, I assume that open public access is inherently good. Thus, in attempting to explain and list the characteristics of a well- constructed Gopher, I take "well-constructed" to mean "easy to identify and use by most users."

While some Gopher users rely on navigating through server menus, many users avoid most of the hierarchy provided by individual Gophers by relying on Veronica 4 (for searching the Internet as a whole), Jughead (for searching single servers or sets of servers), and using bookmarks to create their own menus of useful and relevant resources. These "Veronica/bookmark" people probably rely much less on the structure of any particular Gopher server. Each method has inherent advantages and disadvantages, but there are some valuable clues to Gopher use in both kinds of behavior.

Some Gopher administrators want to keep their information somewhat hidden from the world-at-large. Others see their charge in terms of providing access to all who happen to find their host. For those in the Net community who wish to obscure the information and services that they provide, I suggest that they would be very effective in doing so if they contradict the intent of the directives of this article, and purposely create a "poorly-constructed Gopher." Particularly, Gopher administrators can easily name files and directories such that users will be lucky to find anything at all. For instance, obscure menu language (e.g., using numbers and peculiar words as menu choices or file names) will prevent all but accidental Veronica contact from occurring.

In the next two sections, I present factors involved in the quality of a Gopher server. Section II contains several "anatomic" or "structural" factors, and section III contains a set of more contextual concerns. Section IV contains a short explanation of how to apply the factors as a general schema for Gopher server evaluation. Section V is a short conclusion, which contains some general comments on the schema developed here, its usefulness for evaluating Gopher servers, and some suggestions for extending the kinds of concerns expressed here into the World Wide Web.

II. Anatomical/Structural Factors

Individuals surveyed mentioned over forty different factors, which I have condensed into the eight anatomical factors listed below. While the goals of the administrators of individual Gopher servers can help determine the relevance of each factor, a truly public-minded Gopher owner will try to address the concerns implicit in each factor. The idea here is to stimulate thinking, and have the structure of a Gopher be the result of intentional actions.

1. Menu language

The menu names should be clear and precise, strongly hinting at what is to be found by selecting the item. Too many Gophers have menu titles that are totally uninformative or misleading.

2. Classification

Depending on the resource being organized, different classification schemes are appropriate. For information that is geographical in nature, a geographical organization can be extremely appropriate. However, most users seem to prefer a subject-based organization for most resource types. In the case of access to different types of resources (e.g., WAIS databases or FTP archives), it may be appropriate to organize resources of a particular type together in one submenu. The problems inherent in subject classification (e.g., "controlled" as opposed to "natural" language) can be avoided by organizing by resource type, although this requires folks to do more manual searching.

Another frustrating feature of many Gopher servers is the division of similar information into disparate parts of the hierarchy. Some Gopher servers seem to be more sensitive to local and/or administrative hierarchies than to sorting by subject or information type. While Gopher server administrators may intend for their resource to be used by a fairly narrow clientele, the actual user base can be hard to predict. As such, if the provider of the resource allows public access, it makes sense to organize in a way that both neophytes and experienced users will find helpful.

3. Maintenance & monitoring

Many users point to the necessity of diligent monitoring by the Gopher owner. One of the most frustrating things that all Gopher users face is the menu selection that points to nowhere. That is, either the address of a resource has changed, or the resource is no longer available. As addresses change, Gopher owners must change their addressing files to keep access current. As it is, users have trouble differentiating between a host that is too busy, and a connection that is simply no longer viable.

It is also important that there be constant monitoring of off-site resources based on the quality of their information and/or organization. That is, if there is off-site "good stuff," it is imperative that selection of these items for inclusion on local menus be accompanied by continued monitoring to check if the resource is still a viable and valuable.5

4. Menu structure and heavily-used resources

Users are often frustrated by having to dig around for the most commonly-used stuff. While bookmarks provide an obvious answer for the experienced user of a particular Gopher, some users complain that they cannot find some expected or obvious resource. For example, one user mentioned that it is best in an academic Gopher, especially an explicitly "library" Gopher, to find access to the institution's OPAC (Online Public Access Catalog) at or near the top menu level. This gets at the general idea that it should be obvious, from the root level, where the user can find access to the most heavily used local resources.

5. Linear menu structure

This may be the trickiest of the factors to state in any general way. One major complaint is that there are often too many selections at the root level of many Gophers. The advantageous thing about longer menus is that they leave a shallower structure beneath them. However, too much in one menu can be overwhelming. Two users suggest that a 5-deep structure should be about the maximum. Others suggest that the number of choices should be no greater than eighteen on any one menu.6 Eighteen is roughly the number displayed in a single screen by some client software, especially non-window-based clients.

A few users suggest that blank lines be put to good use. That is, perhaps the Gopher administrator could use all eighteen lines, but only nine would have any text, the rest being empty ("dummies"), with no links to anything. Another suggestion is to use the first few items as dummies, putting helpful information in the place of selectable menu items. The first line of every menu in the KIDLINK Gopher (intended for 10-15 year-olds) is left blank to help users avoid the common error of accidentally selecting the first item. In any event, depth and length should be justifiable. Today's users should not be forced to use a hierarchy that the Gopher administrator set up in an attempt to create a structure that is consistent with extant or extinct non-Gopher structure. It is also important to remember that "Veronica/bookmark" people do not rely on menu structure as heavily as other types of users. When Veronica or Jughead is the major access point to a particular Gopher resource, the administrator may not need to worry so much about this part of the schema.

6. Location: Where in the Net is this?

Good Gophers help the user know where in the ether they are. Some Gophers seem to obscure this information. This factor is important in light of the fact that some users are not aware of the "show attributes" functions that are likely available from their client software. In the long run, this is perhaps more an issue for the writers of the client software than anyone else. Perhaps future releases of the Gopher client software could always display the URL (Uniform Resource Locator) for the current menu or file across the top of the screen or window. A related concern is that informational resource files should contain some indication of their origin/authorship. Administrators should consider placing such information at the top of all informational files.

7. Text formatting

Non-window-based Gopher clients limit the number of lines of text displayed on each screen. With this in mind, Gopher managers should try to limit shorter text files to about twenty lines. Creators of longer files should also be aware that small amounts of text sometimes run onto a brief or empty final screen.

1. Audience & service

Does the intended audience have access to the Gopher server and knowledge of it? Does the resource serve their needs? Does the Gopher help the provider serve the audience better? Since Gophers are such diffuse resources, the issue can arise as to who is getting the most out of your Gopher. Some Gophers should fill specific needs, are those needs/purposes being fulfilled? What do the log files say about where connections are coming from and which aspects of the gopher are being accessed frequently or infrequently?

2. Fit with existing resources

While many locales have the resources to bring up a Gopher server, the question still remains as to whether the local commitment exists to maintain and/or improve the resource over a longer period. If the goal is to provide a resource that is to be transparent and heavily-used, the institution must dedicate itself to providing the resources to support the Gopher server. If the goal is to provide something ephemeral, then this factor may not apply. What other resources are available locally? How does this Gopher server complement, supplant, obscure, or complement existing resources? The idea here is that Gopher owners need to consider automation support and other contexts surrounding their Gopher server. If the Gopher server duplicates existing resources, will it replace them, fall into disuse, or something in between?

IV. Application of the Schema

V. Conclusion

Too many of the characteristics of many Gopher and Web servers are accidental. By paying attention to the minutiae of their resources, Internet resource administrators can improve their product, and thereby improve its usefulness to many users. While the list of factors I offer is not complete, it is a good start on coming to terms with the characteristics that evaluators should consider in the construction and evaluation of Gophers and Web pages. Creators of World Wide Web pages should pay special attention to the length of their pages, and try consider the utility of adding or subtracting a few lines to get better fit for non-windows-based clients like Lynx. Web providers also need to consider the utility of providing graphically-oriented pages when many users have neither the bandwidth access, nor the local computing power to use them effectively, if at all.

I hope that schemes such as this will become standard reading for network administrators who are bringing up Gophers or other networked information resources.7 As with more traditional information resources, librarians can, and should lead the way in organizing the Internet. Let our Gophers be an example of all we have to offer. ¤

Notes

2. For an concise and helpful discussion of the anarchy of Gopherspace, see Snyder, J. (1994), "Diving into the Internet: The trouble with Gopher," Internet World, 5(2): 30-34. Snyder's article also contains some insightful cautionary guidelines.

3. The benefits of this can be two-fold. First, a Gopher is a reasonable way to provide a gateway to a large variety of networked information resources. Second, integrating the Internet into reference can apparently improve relations with the campus computing department. See Still, J. & J. Alexander (1993), "Integrating Internet into reference: Policy issues," College & Research Libraries News, 54(3): 139-140. For a further discussion of the general issues to be considered by libraries in offering Internet access, see Radcliff, C., Du Mont, M., & J. Gatten (1993), "Internet and reference services: Implications for academic libraries," Library Review,42(1): 15-19.

4. Veronica is a Gopherspace application that allows users to search various aspects of Gophers worldwide. For a general discussion of Veronica, see Machovec, G. (1993), "Veronica: A Gopher navigational tool on the Internet," Information Intelligence: Online Libraries and Microcomputers, 11(10): 1-4.

5. The identification and monitoring of resources by librarians is discussed, along with training issues, in Kalin, S. W. & R. Tennant (1991), "Beyond OPACs... The wealth of information resources on the Internet," Database, 14(4): 28- 33. See also Lynch, C. A. & C. M. Preston (1990), "Internet access to information resources," Annual Review of Information Science and Technology, 25: 263-312.

6. Gopher administrators can take stock in the fact that a "full" Gopher server (18 choices on every menu with a five-deep structure) would have 1,889,568 menu choices at the deepest level, and a total of 2,000,718 menu choices throughout. Of course, this assumes that no links above the deepest level lead off-site. I am unaware of any Gopher that provides access to anything close to 2 million items.

7. For example, there is an excellent set of files called "Gopher Tips," (URL: ftp://ftp.einet.net/pub/GOPHERJEWELS-TIPS/) available from the EInet ftp site, and maintained as part of the Gopher Jewels Project (URL: gopher://cwis.usc.edu:70/11/Other_Gopher_and_Information_Resources/Gophers_by_Subject/Gopher_Jewels).

Jeff Kosokoff is an administrator of the web server for the School of Library and Information Science at Indiana University in Bloomington, Indiana.

Copyright © 1995 by J. E. Kosokoff. All Rights Reserved.