Building a Campus-Wide Information System

Universities revolve around knowledge -- its discovery, dissemination and preservation. In order to achieve its knowledge mission, a university also must disseminate information about itself. Historically such information was presented in a variety of print media -- from campus maps to the course catalog to the library catalog to the faculty and student telephone books to newspapers and newsletters.

The deployment of campus computer networks, combined with the evolution of tools like Gopher and World-Wide Web, have made it possible for universities to make available online versions of documents traditionally offered in paper form. The term "campus-wide information system" or CWIS refers to a system that brings together online documents and ways to access campus computing resources under a single comprehensive umbrella.

A well-designed and carefully-constructed CWIS can be a very useful tool in helping a university document itself. But CWISes do not exist in a vacuum -- virtually every major university is now connected to the Internet, and in recent years Internet connectivity has extended to many smaller universities, colleges, and community colleges. (Indeed, the early 1990s have seen some secondary schools connect to the Internet.) With so many schools on the Internet, and with access for the public at large becoming more prevalent, a CWIS becomes not only useful for a campus' existing community; it becomes a valuable way for prospective members of the community to learn more about an institution. A university that does not see fit to establish a CWIS for its existing community may find itself at a disadvantage competing with other schools for faculty, staff, and students.

The CWIS is also visible to those who seek to collaborate with the university - - peer institutions that might enter into joint projects, smaller institutions that may view the university as a provider of some services, or agencies that are evaluating whether or not grant funds. A university may find that the costs involved in creating a solid CWIS are justified by the image projected to these constituencies.

The term "campus-wide information system" generally evokes the image of a school, and this chapter will focus mainly on CWISes in the education context. However, the notion of creating a centralized service that brings together documents and other computer services need not apply only to educational institutions. Businesses and governments would do well to consider the CWIS concept to build online information centers, whether serving a specific campus or the entire institution.

The most important aspect of the CWIS is the notion of gathering together information about the campus into a single location. The providers of that information can be as varied as all the departments on a campus, but for the CWIS to be effective, those seeking information should be able to find it by connecting to a single well-known service.

Origins of the CWIS Concept

Although hundreds of campus-wide information systems have flourished in the last few years --many deployed using client-server, network-oriented software -- the original CWISes were mainframe based. The precise birth of the CWIS concept probably cannot be determined definitively, but Cornell University is generally credited with deploying the first campus-wide information system. The tool was known as CUINFO. It was offered on Cornell's general-purpose academic IBM mainframe running the VM/CMS operating system. The original CUINFO system was created by Steve Worona. [1] CUINFO began service on October 10, 1982. Cornell had broad campus connectivity to its mainframes, and it encouraged widespread access to the mainframes by faculty, staff, and students. With so many users visiting this central service, the mainframe was a natural choice for deploying a centralized information system.

CUINFO grew into a very complete campus-wide information service. A glimpse of its topical breadth is obvious when you glance at its main menu from 1985:

CUINFO - Cornell University Information

Title      Contents                      Title      Contents 
---------- ----------------------------  ---------- ----------------------------
ABROAD     Information on Study Abroad   HOUSING    On- and Off-Campus Housing 
ACADEMIC   From Academic Offices/Depts   LIBRARIES  Schedules for all Libraries
ATHLETICS  Schedules, Facilities, etc.   MOVIES Cornell Cinema Schedule 
BUS        Bus Schedules                 MUSIC      Concerts, Folk Music, etc.
CALENDAR   Academic Calendar             OEO        Office of Equal Opportunity
CAREERNET  Alumni Career Advising Prog   PERSONNEL  Univ. Personnel Services 
CCS        Computer Services Info        PRELIMS    Schedule of Fall Prelims 
CHRONICLE  This Week's Headlines         RELIGION   Religious Services & Groups 
COLLOQ     Colloquia, Seminars, etc.     RESTS Off-Campus Restaurants 
CONNECTION The Cornell Connection        ROSTER     Courses -- Fall Term, 1985 
DINING     Campus Eateries               SEO        Student Employment Office 
DIRECT     Staff & Student Directories   SUPPORT    Student Support Services 
FINAID     Financial Aid Office          THEATRE    Campus Theatrical Events 
HEALTH     University Health Services    UPDATES    Recent CUINFO Updates

		 Please select a title.  (Blank line to exit.)
One of the most popular items on CUINFO was a sort of online advice column called Dear Uncle Ezra, which provided answers to problems unique to members of a campus community. Here is an example of Uncle Ezra wisdom, circa 1986: [2]
Dear Uncle Ezra...September, 1986

 ------------------------------- Page 1 of 82 ------------------------------ 
DEAR UNCLE                             9/26/86
				       JOHN DOE
Dear John,                                      9/30/86
     Happily, help is available.  The best place to start is at the
Learning Skills Center, 357 Olin Hall, 255-6310.  They have tutors,
tests, time management techniques, and study skills assistance.  Other
services can be found under "ACADEMIC" and "PERSONAL" in another part
of SOS for specific problems.
						Uncle Ezra
CUINFO grew in terms of its functionality and the breadth and depth of documents online. Over time, several other universities adopted the CUINFO software to serve the same function. Examples include Penn State, the University of Arkansas, and the WVNET network in West Virginia. The University of Rochester deployed a CWIS that was modeled after CUINFO in 1986; it was named cURio.

Other pioneering CWIS sites include:

Another mainframe-based CWIS was developed at Princeton University, which deployed a system known as Princeton News Network. [7] Like CUINFO, PNN was initially developed for VM/CMS. PNN went into production in December 1988. PNN evolved into a multi-platform system, with data served from the mainframe and from a Unix host. Eventually Princeton developed Unix and Macintosh clients for PNN. The PNN software was adopted for use by other early CWIS campuses, such as Northwestern, Arizona State, and the University of Alabama. Eventually over 100 sites licensed PNN (though some may not have placed it in production).

The pioneer mainframe CWIS sites have moved to tools like Gopher and World- Wide Web for their CWIS platforms. Cornell replaced CUINFO with a Gopher version in November 1993. Princeton decomissioned PNN in favor of Gopher in January 1994. The mainframe sites were looking for replacements more oriented to the client/server, open network model. In fact, Steve Worona, now an Assistant to the Vice President for Information Technologies at Cornell, says that in the early 90s Cornell nearly undertook designing their own protocol that would allow them to move their CUINFO mainframe service to a network/workstation environment, "but then we found out about Gopher, and it was exactly what we were looking for."

Today it is fashionable to dismiss mainframes as dinosaurs -- relics to be disposed of as quickly as possible. Still, it is important to realize that many of today's newer CWISes, while sporting fancy graphics and perhaps multimedia documents, probably are not as complete in their coverage of their campuses as the pioneering mainframe systems were. [8] CUINFO had more breadth and depth of documents online in their CWIS in 1986 than many sites have today under more modern tools. As Worona has been known to say, "An information system is 90% information and 10% system." Builders of CWISes would be wise to realize that getting the technology in place is only a part of the battle.

Even though the advent of the graphics-capable CWIS does not guarantee greater completeness of information, it does afford opportunities for documents to become more readable than flat ASCII text rendered in a typewriter font with no images. Universities are already beginning to exploit networked multimedia as a way to describe their campuses. For example, the University of Illinois has placed online via the World-Wide Web a lovely brochure describing much about the campus with accompanying images. A glance at this online brochure gives an idea of the potential for presenting a CWIS with rich embedded graphics. Here is the beginning of the brochure as rendered by Mosaic:

As Internet connectivity for the masses improves, more campuses will want to offer such online brochures, even including audio and moving images. It will always be important, however, to tell the story completely in text, so that those without access to multimedia facilities will continue to be able to read the information you want to convey.

Choosing a Platform

Just as any general Internet information provider must choose a hardware and software environment for the server, so must you as a CWIS administrator. Gopher and World-Wide Web are overwhelmingly popular software packages for CWISes. You must also choose a hardware platform. The analysis of hardware and software options outlined in Chapter 20 applies to you as a CWIS coordinator.

There are, however, examples of specialized software developed specifically for the CWIS application. At the very least, a new CWIS administrator would want to examine these alternatives to see their unique features. One example is Techinfo, developed by the Massachusetts Institute of Technology and in use there and at several other sites as their CWIS. Techinfo was desgined in 1989 and supports users with Techinfo client software and via a rich VT100 public client. Techinfo is available freely for other sites who wish to use it. To read more about Techinfo you can connect to the MIT service via Telnet (to; log in is automatic). [9]

Another site with a CWIS using unique technology is the University of California at Berkeley, which developed a system known as Infocal, the first CWIS based on an interoperable implementation of the Z39.50 protocol. Developed in the early 1990s, the Infocal server can accept Z39.50, Gopher, HTTP, CSO, and e- mail requests, in addition to a local Berkeley protocol. [10] To try this system, Telnet to

Another option to consider is a commercial product called VTX, marketed by Digital Equipment Corporation. VTX is in use at thousands of sites world-wide. With the first version deployed in 1984, VTX was one of the first commercial client/server products. Today VTX is used by many businesses as company- wide information services. A license fee is paid for the server, and client software is freely available. Clients are available for DEC's Ultrix platform, and for Windows. Clients can connect over Decnet as well as TCP/IP. VTX is multilingual; nine languages are supported. VTX supports indexes with exact- word, phrase, and Boolean searches.

VTX is integrated with DEC's office automation product, All-in-One. This means, for instance, that users can easily grab VTX-owned documents and mail them to other users; information providers can also exploit this integration, for instance posting a calendar from All-in-One to VTX. Sites that already have a DEC-based computing environment may be especially interested in VTX as an option.

The CWIS at North Carolina State University uses VTX; the example sessions connecting to NCSU shown in Chapter 2 show what how VTX looks to the VT100 user. [11]

Most CWIS software options make it possible for you to use more than one server computer if you so choose. For instance, your main Gopher server might point to other Gopher servers, either in your facility or elsewhere on campus, for specific documents or even specific folders. Exercise this option with discretion. Carried to an extreme, you might rely on dozens of separate servers, perhaps residing on the desktops of those who own or prepare a given document. This is appealing in terms of the distribution of control, but this model brings with it the significant chance that parts of your CWIS document structure will be inaccessible at any given time. Suppose a workstation with a particular document goes down, and that workstation is behind the locked door of an employee who is on vacation. Getting the data back online may be difficult.

By contrast, a centralized server often can be located in a computer room that is staffed by operators, who can restart the server in the event of outages, log problem reports, perform regular disk backups, and so forth. You may want to identify what parts of the CWIS are "mission-critical" information, and have a policy that such information must reside in the central server. With the right automated support tools (discussed later) you can make it as easy for your providers to post to the central server as it would be for them to maintain their documents on their own machines.

In general, a server offering Gopher or Web documents requires relatively little computing horsepower. Note that if you run a public client, such as the "curses" Gopher client or Lynx, you may find that the public client is consuming considerable resources. You will want to plan how powerful a server to use with your intended uses in mind.

Many campuses have found it useful to use a dedicated computer for their CWIS service. This has certain advantages: for instance, downtime for upgrades can be minimized, scheduled for a time when CWIS users are not likely to be online. The CWIS will not be subjected to CPU bottlenecks caused by other unrelated tasks -- and it will not cause such disruptions, either. This is not to say that a dedicated workstation is essential for a CWIS; many sites run on shared machines quite happily.

Many campuses have multiple Gopher or Web servers. If you are the central CWIS administrator, you will face this as a fact of life. In many cases this is appropriate for the college or department involved; they may possess the technical expertise necessary, and they may have a volume of documents and a rate of change in the online information that justify their own servers. A central CWIS should include pointers to such departmental servers (assuming they want the servers to be accessible to the outside world). You will also want to select specific documents located on the departmental servers that may be of campus-wide interest, and include pointers to these documents in the CWIS.

Although you should not discourage departmental servers, beware of fragmenting information across too many servers. To take the example of the course catalog again, imagine each department maintaining their own course list in their own formats. Students would find navigation among such a setup difficult at best. In such cases, department-specific information is still best placed in a centralized server in a consistent format. Of course, departments may want to supplement such information on their own servers; for instance, the Biology department might post announcements of new or one-time courses on its own server, with the official course descriptions and schedules delivered in the central listings. Departmental servers might include items such as departmental meeting minutes, schedules for departmental seminars, homework assignments for courses, pre-publication journal articles, etc. Individual professors might offer course notes, syllibi, and class assignments on either departmental servers, or on their own desktop servers.

The Root Menu and the Organization of Documents

Deciding what titles to include in the root menu (or initial screen, or home page) of your CWIS can be surprisingly problematic. It is hard to organize all of the information about a campus (perhaps also including pointers to the larger Internet) in a concise manner.

One school of thought holds that the initial menu should be concise and very general in its titles. Here is an example of a relatively terse menu that has received considerable praise since its introduction:

	     University of California - Santa Cruz, InfoSlug System

      1.  About UCSC InfoSlug/ -->  
      2.  Index to the InfoSlug Menu Tree 
      3.  The Academic Divisions/ 
      4.  The Campus/ 
      5.  The Classroom/
      6.  The Community/ 
      7.  The Computer Center/ 
      8.  The Library/ 
      9.  The Researcher/ 
      10. The Student Center/ 
      11. The World/
Others may feel that a longer list of initial choices, with more explanatory text, is more useful: The question of how broad and how verbose a root menu should be cannot be resolved to the satisfaction of all CWIS administrators; different people have different opinions on the matter. The mode of presentation of the root menu may affect your decision; the two-column presentation offered by CUINFO and by NCSU's CWIS seems to hold more initial choices better than a single-column display does. As a CWIS implementor you should at least be aware of the basic distinction, and you might want to spend some time exploring existing CWISes to see which ones you feel are most effective.

No matter how carefully you design your system, you may inadvertently make parts of it hard to navigate. You may find it useful to ask some testers not part of the menu design team to report on their first trips through the CWIS. They may be able to suggest improvements. Of course, you will not be able to please all customers, no matter how valiant your efforts, but real user experience can be helpful.

One challenge facing all CWIS administrators is that every information provider on campus believes his or her document deserves placement on the root menu. This can be a good argument for a brief root menu with no direct pointers to text documents: the information provider cannot complain as easily with no similar documents in the root menu as examples.

As you build your CWIS, some areas in your information hierarchy will inevitably be less fully-developed than others. It is tempting to implement the entire envisioned document structure, then fill in the folders as documents become available. This can lead to empty folders and blind alleys. Your users may be happier if you flesh out the tree structure only as documents become available to populate those folders.

Types of Information to Offer

Here are some of the broad categories of information you may want to include in your CWIS. This list is not meant to be exhaustive. As is true for menu design, you will want to look at other CWISes so as to benefit from others' choices as to what information to provide.

Documenting the Documents

Many CWIS administrators establish a policy of thoroughly documenting the documents they place online. This can be accomplished with a mechanism as simple as an "About" file in narrative form at the beginning of each folder. Information to be included with each document (or folder) may include: Some software platforms may provide more facilities for recording this sort of "meta information" than others. For instance, the Gopher+ standard was defined in part so as to provide named fields to hold these pieces of information. Over time we can expect Gpoher+ clients that display these fields, either all the time or upon request for a chosen document. If the CWIS platform you have selected does not provide specific fields for these items, you may want to establish a style sheet that calls for the information to be included with each document, for instance following all other text. If you have selected World-Wide Web as your platform, you might use hyperlinks for this purpose; the name of the author might be a selectable item, pointing to an online resume. In fact, the address tag is intended to provide a standard way to insert the e-mail address of the document's owner; in practice it is often included at the end of each document.

Your users will also find it useful for there to be a document in each basic area of the CWIS explaining who is responsible for that set of documents. For instance, in a Gopher-based CWIS, you might include an "About" file in each major folder, and include a standard paragraph that details what campus unit provided the information, how often it will be updated, etc. If your CWIS software does not support meta-information fields, you might use About files to save the effort of documenting each individual file.

In a Gopher-based CWIS you may want to use the ability to explicitly order the items in a folder so as to present them in a logical sequence. Details of this feature vary from server to server, but all provide a way to override alphabetic numbering.

Sometimes in a hierarchical menu system like Gopher you may have a folder with items that could be logically grouped into subsections, but you want the entire list to appear as a single menu. One trick used by some administrators is to use special characters in titles to provide visual separation on the screen. For instance, a menu of seminar titles might look like this:

		 Client software for the Gopher System

      1.  About Gopher clients in general 
      2.  Gopher information from U Minnesota 
      3.  ---------- MS-DOS Clients ------------- 
      4.  PC Gopher III --> 
      5.  U Texas "Curses" Client
      6.  ---------- MS-Windows Clients --------- 
      7.  HGopher 
      8.  WinGopher
      9.  ---------- Macintosh Clients ---------- 10.  TurboGopher
The titles with dashed lines are pseudo-documents, used simply as separators. Normally you would not expect users to select the separator titles. In fact, they might all point to the same physical file, which simply would include a line to the effect "This document is a separator in the menu; see the titles following the current one." Or, you could use type "i", the Gopher annotation type now supported by most clients, for the separator titles.

Of course, such shenanigans would not be necessary in an HTML (World-Wide Web) document. You would simply use headers or list structures to visually separate the logical groupings of items.

Specialized Documents

Chapter 20 gave some examples of how information providers offer online usage statistics. Some CWISes post such usage statistics online for readers to peruse. In particular, this allows campus information providers to see which documents are the most popular. Some sites merely provide a summary report. Other sites augment reports with a folder offering direct links to the ten most popular titles in the CWIS. Still other sites may offer online graphs showing usage. In most cases, these usage statistics are updated daily or weekly; some World-Wide Web services report utilization up to the minute. [12] Online usage logs should not include any information that shows specific activity by fully- qualified domain name of the client, so as to protect user privacy.

The CWIS can serve as a useful feedback mechanism. You can include a simple mechanism to allow users to leave comments. One approach is to publish an e- mail address for comments. A typical approach is to use a common mailbox address and use your server's mail forwarding capabilities to have copies of comments sent automatically to your CWIS team. A typical address might be of the form

A useful supplement to an e-mail comments address is an online Guest Book. This is a simple Telnet application that allows users to jot down comments. It can be gratifying as a CWIS administrator to receive comments from one's campus community and from all over the world. Software that can serve as a Gopher Guest Book is available on Minnesota's archive. [13]

Some CWIS administrators include a folder for reporting suggestions and the administrator's responses online in the CWIS itself. This has two benefits: your community sees that you respond to suggestions, and redundant suggestions are minimized.

Another useful specialized document is a list of recent updates. Such a list can take two forms: it could be an automated list generated from a script, or it can be a manually-updated list with a little bit of commentary describing new folders or documents. Some CWISes offer both. Depending on your CWIS software, the list might include hot links to the resources themselves. Your users may find the list of recent updates a useful way to stay abreast of new documents.

A CWIS will need to include complete information on the CWIS software, such as where to obtain client software. In the case of Gopher and World-Wide Web you can point to other online documents across the Internet, as well as providing specific local information.

Providing Navigation Aids

Your users will be able to better navigate the network of information you weave if you provide a document that gives some understanding of the overall plan. This can take the form of general explanation of how documents fall into main categories. If your CWIS is Gopher-based, you may want to prepare a "road map" that shows the lay of the land. An example of such a map appears in Chapter 16; you can produce a similar map using a tool called Gophertree. [14]

Another useful navigation aid is an index of all the titles in your CWIS. For Gopher CWISes, you might consider a tool called ts/tb. [15] It is also possible to build such an index with some custom programming and with WAIS as your search engine. Such an index will be most useful if the index itself is extremely visible, perhaps in the root menu (as is the case with the Infoslug Gopher menu shown earlier).

The CWIS Policy Committee

Depending on how computing services are governed on your campus, you may want to form (or have formed) a committee to advise on the formation of the CWIS, and perhaps even to help in the design of its layout. A committee can provide valuable insights during formation of the CWIS, especially if the members are drawn from diverse constituencies on campus. It's especially advisable to include representatives from the library, from the public relations area, and from other areas involved with traditional means of disseminating information.

Of course, everyone has had bad experience with committees, and if your CWIS is designed by committee, you run the risk of being told that's exactly what it looks like. It is important that the CWIS committee allow the CWIS administrator to continue to experiment with adjustments to the layout of the document structure, in light of feedback from users and new information to be posted.

Besides assisting in the formation of the CWIS, the policy committee can advise on issues such as what kind of documents are to be included, and what kinds of users will be encouraged, and what will be discouraged. For instance the committee may decide that parts of the CWIS are to be labeled as official unversity information, and may specify policies for approvals for posting in those areas. Other parts of the CWIS might be free of those strictures.

Go To Section 2 of Chapter 23
Chapter 23, Section 1. Copyright (c) 1994, Richard W. Wiggins. All rights reserved.