A proposal for a CWIS

The previous chapters have described networked information services in general. This chapter contains a concrete proposal to harness many of the facilities that are technically possible into a framework that is especially useful for -- and usable by -- researchers in the humanities.

A CWIS is a `Campus-Wide Information System.' This proposal is not so ambitious as to really want a single system for the whole of the university. The proposed system is meant to provide information for a single faculty only. Other faculties are expected to create their own systems. The people working in the faculty of arts clearly expect other kinds of information, presented in other ways, than members of other faculties.

This chapter therefore outlines a proposal for a `Faculty-wide information system,' targeted especially at a faculty of arts and in particular at the faculty of arts in Groningen. It is a proposal for a minimal system plus extensions that are subject to availability of resources. The next paragraphs describe the facilities provided to the user, the hardware requirements and limitations, the support effort, maintenance and management, expected needs for user guidance and education, and the CWIS's face to the outside world.

Goals

A CWIS is more than a few pieces of software. It is also a collection of data and a policy for providing access to that and other information. There must also be provisions for long-term maintenance and user support.

The system proposed here has a threefold goal: provide an integrated and easily accessed channel for the faculty to distribute information to its members; to give researchers inside the faculty a way of accessing information elsewhere in the world; and to give both the faculty and its members a medium for offering information to the outside world.

Derived goals are, among other things: to bring people into contact with each other; to make people aware of the capabilities of new technologies, such as hypertext and multimedia; and to make data that has traditionally been difficult to come by available to many more people.

For the moment, the CWIS will be restricted to the Internet network. That means it will be accessible by everybody in the faculty, but not to people working from home. That restriction is imposed since it seems better to implement the system in an environment where the chances of success are high and where the hardware has the required capacity or is very close to it. Once enough experience has been gained with the system, an attempt can be made to widen the system. By that time connectivity to private homes should also have improved, thanks to the promised ISDN. (ISDN is already possible in some cities, but it is expensive and there is still little experience with it.)

Services offered

A faculty of arts harbours many different kinds of scholars. Even within a single department, people will need very different types of information. On many subjects a researcher may find that his closest colleague works at another university. A CWIS must therefore support cooperation and exchange of information with researchers elsewhere in the world. This support includes E-mail, mailing lists and small-scale electronic publishing.

On the other hand, there is also information that is useful to many people at one site, such as thesauri, dictionaries, course schedules, local events, grants programs, and opening hours. Such information should be maintained in the CWIS itself.

E-mail

All researchers should have access to an easy to use, yet powerful, E-mail system. The E-mail client must of course support MIME.

Not all correspondents elsewhere will have E-mail, so it may be a good idea to have a mailer that automatically sends a fax or even an old-fashioned letter when no other address is available.

Some people may want to have incoming faxes and letters also delivered to them as E-mail. Unfortunately, this cannot be done automatically, unless OCR systems become much better.

It would also be convenient if the E-mail software knew enough about mailing lists (in particular Listservs) to offer commands for subscribing & unsubscribing from them, and maybe more. Many Listservs can now be contacted interactively, allowing even for immediate response.

Another way to accomplish this would be to create a special HTTP server that could subscribe & unsubscribe people. It would probably be less convenient to use than the same functionality built into the client-side software, but it might be easier to implement.

Other features that people have asked for in E-mail software:

Like most other parts of the system, the E-mail part works best through `direct manipulation,' which gives the user the maximum amount of control over the processes. It should for example be possible to interrupt or cancel any action.

Mailing lists

People may want to set up a mailing list of their own for discussions with colleagues from elsewhere. Such mailing lists are not created very often. It would be enough if the system manager could create them when a user requested it. The possibility to ask for such a list should of course be advertised somewhere.

Sending to mailing lists is easy enough with normal mail software. Replying to mail from a mailing list is not so easy; depending on the type of list-server, the reply may go to the whole list or to the sender. A smarter mail program will offer a choice between `reply' and `follow-up' (or `group reply').

Small-scale e-publishing

Occasionally, people may want to make some data available to colleagues (or students). They must be able to put such files `into the system,' which means they must have some storage space that is accessible to them as well as to the system and there must be a procedure for making the data known to the CWIS.

Things can get complicated if the provided data is not static (a file) but dynamic (a program that runs in response to a query). Dynamic data is likely to be rare, however, and it is probably enough if the system administrator knows how to set it up.

E-published data is most useful if the CWIS itself can understand it (as opposed to merely retrieving it). Either the system must know the format or the author must have authoring tools to apply the system's format; maybe both.

Since WordPerfect is the most common program for creating text, the system should at least be able to interpret WP files. If the system is built around WWW, two things must be done: the WP file must be encapsulated in a MIME document and the client (browser) must have a way of displaying WP formatted text.

It is also a good idea to have a conversion program from WP to something else (such as HTML) that the server can use when a less capable client requests the file in a different format. Maybe such a program could be a student project.

A general SGML viewer should also be part of the system. Just as for WP files, there should also be filters for documents that are coded with SGML tags other than the standard HTML ones. Exactly how such texts should be formatted and displayed is a matter that still has to be investigated.

To take this one step further: the system could be based on the HyTime standard for multimedia documents (ISO/IEC DIS 10744). This means that the native format for all (or as many as possible) documents in the CWIS is SGML with HyTime as the means of linking documents together. See below.

Some of the data might be meant for just a handful of people. An authorization scheme has to be devised for this. The obvious solution would be a username & password, but the client software must be able to send an encrypted password. The WWW people are working on a protocol extension for this.

The author of the E-published files must be able to deny or allow certain people access, without too much knowledge of the system's internals and without help from the system manager.

A Faculty Standards Committee could advise on the list of supported file formats for different types of data and make sure that sufficient conversion tools are available.

Generally useful data

A number of services or collections of information could be maintained directly by the CWIS. This concerns information mainly for local use, such as a thesaurus, dictionary, telephone directory, encyclopedias, or foreign language dictionaries or even translators.

Some of the data is relatively stable, other data has to be kept up to date, preferably by the providers of the information, not by the system manager. This includes opening hours, local events, help desk addresses, course schedules and other course information, availability of syllabi, (abstracts of) technical reports, papers and theses.

There is a still a problem with the library catalogue. The only way of contacting the on-line catalogue (of the university library and of most other libraries) is via a telnet session. This makes it virtually impossible to integrate the library into the other information services. Unless the library offers a lower-level protocol (e.g., ANSI Z39.50, as used by WAIS), the library will remain difficult to use. Copying information from the library catalogue into other applications will also be difficult.

Miscellaneous elements

There are many more services and types of information that could be provided through the CWIS. Although it would probably be unwise to try to incorporate all of them right from the start, the system's developers should take into account that things like those mentioned below may be required at a later time. Here is a list of suggested extensions:
talk
let people type messages to each other in real time, either from person to person or in groups (chat).

scrawl
the same, but also allowing simple sketches to be drawn interleaved with the text.

teletext
a gateway could be established between the teletext service from the t.v. and the CWIS. (Such a service is currently being run by the Vrije Universiteit Amsterdam; best access is through the graphic interface at the TU Eindhoven.)

secure communications
users could be given the option of using public key encryption for their mail.

slide show
one way of using the E-publishing capabilities of the system is to prepare a set of slides, then go to a lecture hall and call up the slides from there. The lecture hall may even be in another city.

Travel agency
People sometimes need to go to conferences or meetings in other countries. The CWIS could have a link to the faculty's travel agent, so that they can see for themselves what flights and hotels are available. They could even send a request to the travel agent to make a booking, although a telephone call may be safer in this case.

Classified ads
The CWIS could provide an area where people can advertise things to sell, requests for help, experiments that require guinea pigs, etc. In short: a bulletin board.

Hardware

Only a few people can have access to X terminals, an equally small number uses Macs, and a large majority only has PCs. At the moment not every PC can run Windows, but that should change within about a year. It is recommended that the development effort is concentrated on the MS Windows and X Windows environments, as these will be the major platforms for the whole of the faculty.

All connections within the faculty are over Ethernet lines. The PCs are connected in a Novell LAN, but all of them can use TCP/IP as well.

The CWIS server and all centrally maintained data can best be kept on a dedicated Unix machine with ample disk space. For better balancing of the work load it is advisable to keep the NNTP server (for Usenet news) on a separate machine (as it already is).

There may be additional servers on other machines, catering for data that is maintained decentrally.

The disk space requirements are difficult to predict, since all of the Internet services are growing explosively. Some parts grow as much as 25-fold every year. More and more people use the network, and they transfer larger amounts of data. New, often surprising applications of network services are invented every month. But to name a concrete size: 2 to 4 Gigabytes of disk space should be enough initially.

There should also be a colour scanner and possibly equipment to `grab' video frames. Some people already have a small hand-held scanner at home, but digitising equipment at the faculty is scarce. The little equipment there is is accessible (with some difficulty) to no more than a dozen people.

Access from home

There are a few dial-in modem lines to the Unix machines, but not to the Novell file servers. This means that people working from home cannot access LAN-based programs, nor their own files. Solutions to this problem are either technically difficult and expensive or incomplete and insecure.

Better support for people working from home will have to be provided some time in the future, but this report cannot yet make any recommendations.

Access to the CWIS from home is somewhat easier to set up. The best solution (from the user-interface point of view) seems to be to use the SLIP protocol from home, so that the same Windows-based CWIS client program(s) can be used both from the office and from home. This is possible since SLIP emulates a TCP/IP connection over a serial (modem) line. However, there are still some problems to be solved, such as the scarcity of unique Internet numbers, and security issues.

Further research is needed into this matter, both into the technical difficulties and the problems that non-technical people will face when trying to set up a connection from home.

Human resources

A CWIS consists not only of hardware and software, but to be successful it needs some human effort as well. This comprises support, maintenance and management.

Support

A new program, especially one that introduces new concepts, should be supported by a help desk. Although the goal is that the program is so intuitive and easy that people will need no help at all, it is impossible to guarantee this.

The CWIS will require some amount of work from the people at the help desk, but hopefully not so much as to require an extra employee.

The help desk is the contact point for all questions regarding the CWIS. And although it will not be able to do anything about errors in information that is provided by a third party, it must still be ready to listen to complaints about such information, for users will not be able to distinguish between the interface and the information itself, at least initially.

A nice service to the users would be a complaints department where people can deposit complaints and suggestions about third party services and that would try to contact the authors of the information on behalf of the users. Of course, the complaints can also be sent by E-mail, that may even be the preferred way of communication.

Maintenance

Part of the maintenance will be done by the system administrator, in so far as it is concerned with the software and the central server. But the aim is that various people take care of the information that they are responsible for, without help from the computing centre.

How this will be organized -- and whether it needs to be organized at all -- is something that needs to be addresses towards the end of the first project year, once the infrastructure is ready.

Management

Responsibility for the software and for the central information server will lie with the computing centre, so it is logical to appoint it as the co-ordinator of the whole CWIS The tasks of the manager include keeping a list of people responsible for important pieces of information, providing them with help, periodic checking of user satisfaction, looking out for and establishing `standards' or recommendations, etc.

The management could make use of a committee, with a name such as Faculty Standards Committee (FSC). More ideas about such a committee can be found in the `Ideas' chapter.

User education

Even if the software that is distributed to the users is extremely easy to use, it cannot be expected to explain all of the concepts behind it. There should be a paper manual that people can take home and read at their leisure. A condensed version may be available on-line.

The quickest way to teach people how to use the system is to give a short course, with hands-on training. A single session is not enough for people without any prior knowledge, but 4 or 5 sessions of 1½ hour should be adequate.

Neither the manual, not the course, nor the on-line help will be perfect. They may contain omissions, and some people will need extra guidance to cross a mental barrier. A help desk must be available for extra, personal help. Users should be encouraged to contact the help desk by E-mail, since this makes most efficient use of the help desk personnel's precious time. A telephone should be available for really serious cases.

Of course, the help desk personnel should follow a training course even before the regular users. This course must be given by the developers. Subsequent courses are maybe better given by other people.

For many aspects of the system there is no substitute for hands-on experience. Like with any complex machinery, one must experience it to become comfortable with it. To accomplish this, people must be lured into using the system, either with promises of real benefits or with immediate satisfaction. Games and puzzles can serve for this purpose.

A part of the introduction to the University of Illinois at Urbana-Champaign. The full document is available through WWW.

Presentation to the outside world

The CWIS is also the face of the faculty to the outside world, and as such it should include on its opening screen a choice of information about the faculty and its surroundings. This part of the information must be in English.

Before the CWIS is `officially' announced to the world, this information must be present. That means that it has to be written -- or collected -- immediately at the start of the project.

The system can also act as a convenient channel for publishing information. It could offer electronic copies of dissertations that are produced by faculty members, pre-prints of articles, datasets that were produced during some research, etc.

The figure shows the introductory page of the CWIS of the university of Illinois, a fairly typical example.

Software recommendations

Step one: WWW

Currently, the faculty uses elm under Unix and Pegasus Mail (Pmail) on the Novell PC LAN. Elm is capable of working with MIME, although in a rather primitive and poorly documented way. It is likely that the next version of Elm will have a better integrated interface. Pmail is also MIME-capable.

Neither package will develop the other features mentioned above, such as commands for mailing lists, fax and paper mail. Some other programs, such as some Usenet readers and WWW browsers, offer integrated mailers, but they are not full-fledged mail programs.

Information from outside the faculty will most likely be available through one of the well-known protocols: FTP, Gopher, HTTP (for WWW), Z39.50 (for WAIS) and NNTP (for Usenet). The different protocols have different capabilities, but also much overlap, as explained in previous chapters. The user should not be bothered with the protocols. Therefore, one-protocol programs such as Trumpet, PC-Gopher, xrn, xwais, hngopher, and ftp are of no use and should not be supported (which is not the same as forbidden). Only WWW browsers like Mosaic and Cello come close. They still lack mature E-Mail support.

So it is apparent that none of the existing programs has developed far enough away from its technical roots. Even WWW is not capable enough in its present form, although it is clearly on the right track. The WWW concept is sufficiently simple and general to easily encompass the concepts behind the other systems. The proposed HTML standard even includes MIME support, so it also forms a good base on which to build a mail program.

It shouldn't be too hard to create an information navigator that is basically an improved WWW browser. The navigator should be able to retrieve, present and manipulate data from FTP, Gopher, WWW, NNTP (as e.g., Mosaic already does), as well as from WAIS, mail boxes and local mail folders. Retrieved data may be printed or stored locally. It should also include a mailer and Usenet poster.

At least under Unix, a programmer who understands all the formats and protocols should be able to create such a program in a few months. All the parts of the software are already available (C source) in such packages as Mosaic, mm, rn, htmllib, etc.

Step two: HyTime

The best system, in view of expected future developments, could be a system that does not use HTML for its hypertext & hypermedia documents, but full SGML with HyTime as the format for the links. HTML is also an application of SGML, but it is not HyTime compatible. HyTime is an ISO standard, and it is supposed to be the most powerful and most portable format for multimedia and hypermedia documents.

However, before a real commitment to HyTime is made, an assessment of its real merit has to be made. The standard is still so new and so little understood, that the claims made by its authors are difficult to evaluate at this moment. So although it is clear that HTML is not powerful enough in its current form, while HyTime is, it may still turn out to be the case that the ISO standard is too difficult or too inefficient.

Hardware recommendations

The hardware for the project is needed for three tasks: developing the client software for MS Windows, the same for the X Window System, and as a central information server. The latter two tasks can be done with the same machine; modern workstations have powerful enough disk handling to double as a server.

The PC could be a 486DX66, with 12 Mb RAM, SuperVGA, 300 Mb harddisk, sound-card, ethernet and a CD-ROM. It is essential that the machine is more powerful than the average user's machine, since developing the software typically requires much more resources than running the completed version.

The workstation must be ready for the expected large amounts of data and heavy traffic that it will have to deal with after a while. Possible specifications are: 64 Mb RAM, 2 Mg harddisk, DAT backup drive, CR-ROM, 8-bits kleur 1280x1024 pixels, direct-video card, small video camera, headphone & microphone. A machine like the HP/Apollo 9000/735 or a similar one from Silicon Graphics should be adequate.

In addition, it is recommended to have a colour scanner and an OCR system available, to speed up the process of digitizing information. The video camera could of course be used to scan photos, but a flatbed scanner is more convenient and has a much higher resolution.

A system for digitizing slides would also be nice to have, but because of the high cost it is probably better to wait for it to become available because of some other project. (Such projects are being set up at the moment.)

Measuring the success

It is possible -- to a certain extent -- to measure how well the CWIS satisfies user needs. Several aspects of the system can be evaluated by measuring user performance and comparing it to preset goals. Some of these aspects (or usability attributes, according to Hix & Hartson) are: For some of these aspects benchmarks must be defined, in this case tasks that a user must perform within a certain time or without errors. Other aspects can be measured with questionnaires. A good questionnaire would be QUIS (see Hix and Hartson). QUIS lets users assign numbers from 1 (worst) to 9 (best) to several detailed aspects of a user interface.

Before the system is evaluated, a target value must be set, so that it is possible to decide if it can be considered successful. Tasks that were possible with earlier systems can also be compared.

Here are some of the possible measurements:

Related projects

Since this project only deals with network-based services, it might be a good idea to start a parallel project to increase awareness of the possibilities of stand-alone computers. There are many tools available beyond simple word-processing.

The GHETA archive & project is a good example of the use of an electronic archive for primary sources (articles, reports). It may even be extended to be an archive for datasets as well. The development of GHETA and of the proposed CWIS could be co-ordinated, one serving as the testing ground for the other.

The Computing Centre of the University of Groningen is also planning to develop a next-generation CWIS. They plan to work on server software and security and are looking for a suitable client to work with their server. It seems a good idea to try to coordinate the efforts.

The future

The short-term goal of the CWIS is to provide an integrated information infrastructure, by means of an easy to use client program. The initial version should be attractive, but it will obviously not be perfect. The longer term goal is to improve the system with features that are missing or incomplete in the proposal above, and of course to improve the usability of the client program.

Examples of problems that need to be addressed later are: