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.
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:
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
I AM FAILING EVERYTHING. I NEED SERIOUS HELP.
SINCERELY,
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:
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.
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
techinfo.mit.edu; 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
infocal.berkeley.edu.
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.
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:
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.
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.
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
comments@gopher.msu.edu.
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.
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).
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.