Promoting the CWIS

A big part of building a CWIS is evangelism. Although much of the campus will instantly agree that such a comprehensive central information service is a good idea, getting information providers to provide, and users to use, can be a challenge. Examples of evangelism include: A special challenge is deploying client software around the campus. To encourage users to install client software, you can emphasize the advantages - - better user interface, better access to information -- in all the forums listed above. Make sure the telephone help line staff are familiar with client options. Consider putting up local copies of the client software for access via anonymous FTP, with the clients preconfigured to connect to your CWIS.

One strategy for promoting your CWIS (or any online service on the Internet) is to give it a proper name. Examples of such names include InfoSlug at the University of California - Santa Cruz; GopherBlue at the University of Michigan; and KUfacts at the University of Kansas. A catchy name can serve as a useful "handle" so that the name of the CWIS comes readily to mind. Moreover, your CWIS name can refer to your entire campus-wide information system, even if parts of it are implemented across technologies. For instance, KUfacts can refer to both Gopher and World-Wide Web views of the integrated service at Kansas.

Encouraging Campus Information Providers

In order to populate your CWIS with useful information from around the campus, you will need to "sell" your potential information providers on the value of using the CWIS. They need to see how online publishing will assist them in their missions. Again you might think of yourself as an evangelist, pleading your case rationally, but with religious fervor. Some of the advantages that you might tout include: Direct evangelism of information providers can include telephone calls or e-mail to them when new documents are announced or old ones are updated. As you work with a new provider, you will often find that, like many other users, they have not yet installed client software on their workstations. You may want to allocate some staff time to the special task of helping information providers get client software installed and configured. By providing them with a better view of the CWIS, you encourage them to contribute their documents as well.

One way to assist new providers is to prepare a document describing their options for posting information on the CWIS. Explain the formats you can accept, how to convert documents from popular word processor formats (such as Word Perfect, Microsoft Word, etc.), any policy guidelines, etc. Place this how- to document online on the CWIS as well as making it available in print form.

In general, it is not advisable to post information without contacting the "owner" of the document on campus. Although you may feel that information already provided to the public in print form is fair game for online posting, some information providers may have specific concerns about online distribution. You should identify the owner(s) of documents and be sure they approve the posting on the CWIS first.

You will want to establish guidelines as to how large a quantity of information you are willing to post at no charge. Some campus providers may come to you with huge databases they wish to add to the CWIS, which may strain your available disk resources. With disk prices falling, reasonable charging can recover such costs. (On the other hand it is desirable to avoid charging if possible for "reasonably small" documents in order to encourage all providers.)

At some points your evangelism may be too successful: A flood of documents may appear at once from providers who all expect fast posting. Take comfort in this sign of success.

Automating Document Posting

By allowing automated posting of documents in the CWIS, you make it easy for your providers and for yourself. Automation is most important for documents that change frequently and that can be prepared by the provider in a "CWIS- ready" format easily. It is not advisable to provide direct access to the file system of your CWIS server; this makes it too easy for posting errors to take place, sometimes with extreme consequences. Instead, you want to provide a scheme whereby an automated process picks up documents sent to a staging area and places the documents in appropriate spots. You can take several approaches in the automation process.

A common approach to automating the posting of documents submitted by information providers is to provide a staging area into which the users can FTP their submissions. You migh allocate a special user ID that corresponds to each online document (or set of documents). The provider transfers a new version of the document into the staging area. In the common case of a Unix-based server, a cron job checks each staging area periodically to see if new submissions are present. If so, the document is automatically posted into the appropriate spot in the file system. Scripts to perform this sort of trick are often written in Perl.

Alternatively, you may want to set up a mechanism that accepts documents from your information providers via e-mail. Some providers may be more comfortable with e-mail as their means of submission. Again, scripts to perform this type of updating are often written in Perl. Some public-domain tools, such as a program named deliver, can help you automate this process; deliver parses incoming e-mail message headers, splitting off files and running scripts as appropriate.

It is a good idea for your automated scripts to send an e-mail note back to the information provider for each posting received. This lets the provider know that an update is about to take place. This is especially important if you choose an e-mail based automated posting option, because it is relatively easy for a nefarious user to forge such postings. If you mail a note back to the presumed information provider, and if your automated process defers actual posting to the CWIS for a few hours, you will have the opportunity to interrupt a pending bogus posting. The deliver tool allows such automated reminders. [17]

Tools like deliver are commonly available for anonymous FTP; use Archie to locate a copy near you. You can also look for tools in the archive for your specific CWIS platform. For instance, Gopher administrators may want to use tools available on the boombox.micro.umn.edu archive; in particular, look under the directory /pub/gopher/Unix/GopherTools.

If your campus has deployed a network-wide file system, you may be able to use that system to help providers deliver documents for posting on the CWIS. For instance, the University of Notre Dame has made such use of the Andrew File System. Information providers are able to update documents located in areas allocated to the under AFS; AFS permissions preclude a provider from writing outside the designated areas. Additionally the Notre Dame system allows authorized users to submit documents via e-mail. The following graphic depicts how the Notre Dame system works: [18]

While automation can greatly ease your burden as CWIS administrator, it is axiomatic that no automated system runs smoothly in all cases. You will want to review recent postings periodically to ensure that various automated posting scripts are doing their jobs. From time to time your scripts will need tuning in order to repair problems. Commercial products such as VTX may require less use of customized scripts; eventually, we might expect to see commercially supported Gopher or Web servers that provide built in tools that address many of the database side of running a CWIS.

Replacing Print Documents

One estimate holds that 10% of the cost of running a university is related to printing. Even if accurate, that figure no doubt overstates the amount of money that could be saved by moving to online publication; there are certain fixed costs that continue no matter how a document is "published," and online publishing, while inexpensive, is not free.

Nonetheless, online publishing of documents does provide opportunities for saving money as well as saving trees. Most CWIS administrators do not set as a goal the elimination of print editions of particular documents. Instead, the primary goal is getting versions of those documents online. Once the concept of online delivery has been proven, the owners of documents will in some cases come forward, proposing that the online version become the only means of delivery. Earlt candidate documents might be those that are expensive to publish and are amenable to online delivery. An example might be a manual of business procedures -- the sort of document that is large, referred to only occasionally, but keenly sought when an individual needs to know a particular piece of information. Online publication can be superior to the print edition in such a case; the paper version tends not to be updated as frequently as it should, and it tends to be located somewhere far away from the person who wants it at any given instant.

CWIS administrators and their information providers would not want to move a given document to exclusive online delivery without careful consideration. Has access to the CWIS reached a broad enough audience to justify removal? You do not want to stop paper publication if you will lose a large part of your audience.

Also, be sure that the CWIS is not the only location of some vital piece of information. A classic example is the telephone directory: you do not want the CWIS to be the only repository of this information. For instance, you may need to be able to look up the phone number of a member of the CWIS team when the server is down!

Cases in which you and your information providers have decided to use the CWIS as the exclusive means of distributing a document may present a golden marketing opportunity. For instance, one university decided to provide the list of team schedules in the intramural basketball league only on the CWIS; no paper schedules would be handed out. Student use of the CWIS increased dramatically. Of course, such as scheme can only succeed if access to the CWIS is well-deployed, both via dialup and campus computer labs.

CWIS Accessibility

Many users may have workstations that lack sufficient resources (memory, disk space, CPU horsepower) to adequately run the appropriate client program. Others may have the ability but lack the inclination. In order to serve such users you may want to run a public client, such as Lynx or the public Gopher client.

Lynx may be especially useful for you if your CWIS rests upon a combination of Gopher and Web services. The view of Gopher documents via Lynx is essentially as complete as your users would experience with the public Gopher client; furthermore, Lynx offers a very usable way to browse the World-Wide Web. Rather than run both a public Gopher client and Lynx, many campuses are finding a single Lynx service meets the Gopher and the Web requirements with less confusion for users.

The public client can also make it easy for your campus community to tap into the CWIS from off-campus. The computer running the public client service will need to be accessible from the terminal server into which public users dial. If that service supports SLIP or PPP, your users will also have the option of installing client programs such as Mosaic on their remote machines.

You will always want to emphasize to users that their best view of your CWIS is obtained with the use of client programs; at the same time, you will want to design your CWIS so as to reach the widest possible audience. For instance, if you rely heavily on graphics in your documents, you may not be able to reach some of your audience. At a minimum, it is a good idea to label your inline images, so that those users accessing the CWIS via Lynx (or with deferred image downloading in Mosaic) will be able to see what isn't on screen. If a lot of your users come in over slow links, it is a good idea to also label file sizes. Your users may choose to invoke a download option for items of special interest. In dealing with graphics, it is also a good idea to view documents on a variety of classes of computer monitors and adapter cards, to see how your users in the field actually see the same documents.

Be judicious in your use of advanced Web features such as the Imagemap support. If an Imagemap is your way of presenting a root menu -- i.e. the user clicks on a graphical icon to select a document area -- will users who do not have access to Mosaic still be able to make sense of and navigate your CWIS?

Public Kiosks

Most campuses offer information booths or displays that contain maps and printed guides to campus. In some cases you may want to consider installing public kiosks that can access the CWIS as a way to provide more complete and more up-to-date information.

Such kiosks need to be in a secure area. You may want to designate a machine in a staffed microcomputer laboratory as CWIS terminals. In less secure areas you may want to anchor the workstation securely in a physical cabinet. Some CWIS administrators have opted to set up touch-screen terminals, so as to minimize problems of accidental or malicious rebooting of the kiosk terminal.

For greatest security, some sites have begun to use "boot ROMs" in PC- compatible machines to force the workstation to bootstrap load over the network. The workstation may not even have a local hard disk in this sort of environment. A system image including startup commands is downloaded over the network. This makes it extremely difficult for a malicious browser to reboot the machine and damage its software configuration.

You may want to restrict the documents that can be viewed in the kiosk. If your kiosk is capable of showing Usenet News articles, for instance, you may find the display dominated by people who are reading various news groups, making the kiosk unavailable to visitors who need to learn about campus. There are various approaches to follow. You might create a custom server that has pointers to those documents that you want to deliver on the CWIS, for instance. Some clients will allow you to specify a parameter that serves as a starting point; for instance, some Gopher client let you specify an initial selector string, which could correspond to a part of the Gopher hierarchy suitable for the CWIS users.

Setting up this sort of kiosk can require a fair amount of custom work, both in building the physical kiosk and in setting up software. Standard tools such as Gopher clients are developed primarily for the desktop market, not for the specialized kiosk application. But some CWIS administrators have found the effort worthwhile. In the long run we may see commercial products offered that address this need.

Exploiting Existing Online Databases

Any campus that has not embarked upon building a CWIS probably alreadyhas some information available online in one form or another. If you are responsible for establishing a CWIS from square one, you will want to take advantage of such online information where feasible. Gopher, World-Wide Web, and other tools will generally allow you to provide Telnet access to external hosts; simply by putting pointers into existing services (assuming they accept inbound Telnets) you can begin to organize such resources.

Note, however, that having the user invoke a number of separate Telnet- accessible services can interrupt the smooth delivery of information you can offer with native documents. Most Gopher clients, for instance, issue a warning when you exit to a Telnet process; also, most clients present the required login information to the user in a dialog box, and the user is required to type in login information. This is not as easy on the user as clicking on a document and having it appear on the screen.

Furthermore, one of the basic ideas of a CWIS is to present information in a common form. A myriad of separate external host services, perhaps each with its own search language, is exactly what we are trying to move away from in building a CWIS. The goal with the CWIS is to make information accessible in a comprehensive, central repository. The more documents you can offer in the native format, the better. When weighing whether to use an external search tool, ask yourself what the typical mode of access to the document will be -- what kind of searches will the typical user want to perform?

Consider the university course catalog as an example. Suppose your campus has an existing course catalog browsing facility online, and the question is whether to use that tool, or to export the information to be loaded as documents in your new Gopher service. An external search engine might be able to present the catalog with more sophisticated search capabilities than a tool like Gopher can offer. Your users, however, are likely to want to browse the catalog as much or more than they want to search it. If the catalog is organized into a logical hierarchy, students and others will be able to quickly zoom in on the information they want. Moreover, the titles in the catalog will appear in Gopherspace indexes such as Veronica; if the course catalog is buried in an external search mechanism, the course titles will be invisible to Internet indexing tools.

Here is an example showing how a catalog might be presented in Gopher, from the University of Minnesota:

In some cases, existing external databases may be so large, or the search processes so elaborate, that the only viable option is to offer Telnet access to the existing services. Examples might include the library catalog and various large databases provided with proprietary search software. The external search engines will be superior to the Gopher or Web browsing model in such cases. Fortunately there are ways to provide inbound Telnet access to most such services, even if they are mainframe resident, if the host has a TCP/IP connection to the campus network.

A particular issue is what sort of telephone lookup software is offered on the campus network. Choices include:

The strategy of using an index in the native CWIS can be surprisingly effective; the user types in a surname, and quickly hones in on specific choices. Other mechanisms require the use of gateways, or, in the case of QI/PH, the launching of a separate client program on behalf of the user. The choice of which of these technologies to use will depend on the general computing and networking strategies on the campus; i.e. the decision may not rest with the CWIS administrator. Whoever makes the choice of what technology to use may find it helpful to see what similar institutions have selected.

Security Concerns

More and more copyrighted and licensed materials are appearing on campus networks. Where possible you may want to add pointers to these resources via the CWIS. Note, however, that the terms of your licenses will typically restrict the sort of access you may provide. In some cases a resource is licensed for campus-wide use; in other cases access is limited to a department; in still other cases an item, such as a CD-ROM, is licensed for non-networked single- user delivery. As a CWIS administrator you will want to work with your information providers to ensure that any items you point to are in fact available for distribution to a campus-wide or world-wide audience.

Several CWIS servers provide for IP-address limitations on incoming users, either for the entire server's document base, or on a folder-by-folder basis. This can allow you to limit access to documents served by the CWIS to the campus community. You will need to be sure that the server does not accept the IP address of terminal servers accepting anonymous dialup users if the vendor of a licensed resource is concerned about local or long distance telephone users tapping into the resource.

In cases where online resources must be limited to the campus community, often the external database will have a built-in authorization check, often asking the reader to enter a student number or staff ID number. If the resource is available on a host that is Internet-visible, such authorization is essential. In some cases your information providers may rely upon the IP address of the user to verify that a person is on campus. This can open an inadvertent back door if the CWIS points to it. For instance, suppose you list such a resource in your Gopher-based CWIS. From the point of view of the machine serving the information, the Gopher server is on-campus, so it passes the IP address test. But if you are running a public "curses" client on that server, and if it accepts incoming users from around the Internet, then all of those users will appear to be local.

Another back door can be inadvertently opened if someone else on campus runs a server that accepts dialup or inbound Telnet users. If their server points to a resource whose access is offered on a campus-only basis by your CWIS server, the locality test can be passed for users who are not local. As CWIS administrator you will have to work with the other server administrator to resolve the problem.

Any authorization scheme that relies on IP addresses opens up the possibility of back doors. An example of another back door can affect Gopher-based CWISes. Because the Gopher can act as a proxy client for FTP services, it will open an FTP session on behalf of a client that requests a file accessible for campus- only access. Thus your Gopher server can open up access to files that a campus FTP administrator believes are limited to on campus delivery. In fact, if a user is willing to construct the appropriate "FTP:" selector string, your server can be tricked into FTPing files from servers to which it has no document pointers! As CWIS administrator you will want to work with campus FTP administrators so that they are aware of this issue. The mechanics of this security hole are depicted below.

If you run a public client, you will want to be careful to avoid some specific security problems. If your public client can launch a Telnet session, a user can under certain circumstances escape to a Telnet prompt, and subsequently can "open" a connection anywhere on the Internet. This can potentially enable the anonymous user to attack remote hosts. A version of Telnet called telnot can be found on various FTP archives; this tool closes the hole. There are also security problems with the standard more text browser under Unix; a tool called less solves some of these, as well as providing additional features. Use Archie to locate current copies of these tools.

The CWIS and the Handicapped

A campus-wide information system can be very helpful for members of the campus community who are challenged by visual, hearing, or physical impairments. Information that previously was available only in printed form, for instance, becomes accessible to the blind. Consider the experience of Michael Hudson, a staff member at the Office of Handicapper Services at Michigan State University:

I wanted to drop a quick line and tell you how much Gopher means to me. I discovered Gopher about two months ago and cannot believe how much information is out there. I have found the new Veronica option very helpful as it allows me to build a directory of items that are specific to my interest. This is undoubtedly a great service for anyone who finds it. However, for me it is unbelievable. I am legally blind and I have always said that the most difficult aspect of blindness is the lack of readily available information. Gopher has the ability to change all of that. For the first time, I feel like I can easily and independently access important campus and worldwide information. . . . I use a speech synthesizer and a PC compatible computer to access the Gopher system.

The "talker" technology Hudson refers to is available in relatively inexpensive forms; audio cards such as the Soundblaster for the PC come equipped with software that is able to pronounce common words (and spell the words it cannot pronounce). Special-purpose hardware and software may be even better equipped to meet such needs.

It is hard to overstate how great an advantage this can afford. Consider, for example, the ability to easily read campus newspapers and newsletters, once they are available on the CWIS. Although there exist reading machines that can scan such materials optically, performing the text-to-audio function fairly effectively, use of these systems can be cumbersome with print matter in the form of newspapers. By placing the machine-readable version of the newspaper available online, your CWIS extends this information resource to the visually impaired in a consistently usable form.

Nore that the graphical user interface is antithetical to the use of such tools. A blind user obviously does not benefit from pull-down menus navigated by use of the mouse. By contrast, a talker works well with software such as the Gopher curses client. The user can become adept at navigating menus by using a consistent number of strokes of the cursor key. [19]

Similarly, those with hearing impairments may find a CWIS quite useful. However, if, as multimedia tools become more common, you as a CWIS administrator begin exploiting the potential for audio narration, you should bear in mind that exclusive reliance on audio may disenfranchise part of your audience. With a little more effort, the text script associated with audio documents can be made available online alongside the audio selections -- the equivalent of closed captioning on television.

The CWIS as Historical Archive

When you add documents to the CWIS, you are capturing a snapshot about some slice of the campus history. Once you've placed a document online, it is quite easy to set up a corresponding archive of that document. Such an archive can serve as a useful repository for an online historical record.

Here are some examples of how an archive might be useful: