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
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.
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
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
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
archive; in particular, look under the directory
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: 
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.
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.
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?
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.
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:
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
less solves some of these, as well as providing
additional features. Use Archie to locate current copies of these tools.
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. 
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.
Here are some examples of how an archive might be useful:
Your message should include in the body a subscription request of the form:
subscribe cwis-l John Doe
You may find archived discussions of this mailing list particularly useful, as other CWIS administrators have faced similar issues. To see the index of log files, send the following e-mail:
Mecklermedia publishes a print journal devoted to this topic. The journals is called CWIS and appears quarterly (ISSN 1065-0741).