Development of the University of Illinois Web

Methodology

Because so little precedent had been set on the Web, the procedure for developing documents was of necessity quite experiential. I learned what I could from other web sites, developed pages and code, and revised them based on my own observations and the copious feedback received.

One thing to note is that the Web is very forgiving. Unlike paper documentation, the overhead associated with releasing a new version of the information is negligible. Furthermore, electronic feedback is very easy and very immediate. This tighter bond between publishers and readers means that if there is an error on a page, the maintainer will find out about it sooner or later.

Implementation Decisions

perl

For the sections of the UIUC Web that were dynamically generated (mostly the navigation system), the programming language perl was chosen as the implementation language. Perl is a scripting language particularly well suited to text manipulation. It is an interpreted language, and so is somewhat slower than a compiled language like C. However, at the commencement of the project, the demands on the computer running the web server were so minimal that this did not appear to be an issue. Furthermore, many of the scripts would only execute infrequently, with the results of the execution being stored for common retrieval.

Mosaic Compatible

The two most popular graphical browsers available were Mosaic and Netscape, a Mosaic spin-off. Netscape supports extensions to HTML that did not originate with the official standards body, and that are not recognized by Mosaic. In many places, this has caused no little soul-searching as people grappled with the decision of whether or not to use the Netscape extensions. Because Mosaic was developed at the University of Illinois, I had no such dilemma. The resources that I developed used no extensions specific to Netscape.

Design Principles

Conversion Not Creation

Given that by this point in the mid-90's, almost all documents start their lives on hard disks somewhere, and given the number of documents that exist, it was logical to decide to focus on converting existing documents instead of generating new documents, scanning documents using optical character recognition, or re-typing the text of old documents.

Text Over Graphics

For the early work, I used no decorative graphics. I knew that there were many users on campus who did not have particularly fast machines, and that many people from off-campus (and a few on-campus) accessed the Web using relatively slow modems. I thus made the conscious decision to avoid graphics unless the graphic was the item of interest, as is true for e.g. a map.

As time went on, and the site became more formal, decorative graphics were essentially mandated by the Office of Public Affairs. While I resisted initially, I now recognize that decorative graphics do add value: they are a form of conspicuous consumption that shows that an organization has adequate resources to be able to to devote some to artwork. Still, I fought to keep the artwork small and to make sure that users could still navigate adequately if they set their browser such that images would not be downloaded.

Strongly Cross-Linked

It would have been easy to put information on-line in its plain-text form. The information usually came from the providers in that form. However, raw text is less legible and hence less usable than the equivalent paper version. Related paper documents could instead be converted into cross-linked documents on-line, i.e. with hyperlinks connecting the two documents tightly. The ease of shifting between documents is thus a strong value added to the original text. Thus emphasis was placed more on making highly cross-linked documents than on sheer volume of documents.

Regular Addressing

To make it easy for subsequent users to link to documents, the Uniform Resource Locators (URLs) for documents were made as regular as possible. The URLs were in fact so regular that in some cases, it was possible to automatically create hyperlinks in raw text via a perl script.

Instrument Code

It was relatively simple to instrument the code so that if an error condition was detected, the program sent email to me with pertinent information. This gave far more and better diagnostic information than users tend to give.

Go on to Framework
Go back to Objectives

Go up to Table of Contents

Kaitlin Duck Sherwood