The University of Illinois at Urbana-Champaign (UIUC) campus-wide information system (http://www.uiuc.edu/) is a comprehensive information repository. It developed as a bottom-up, grassroots effort. I, a lowly graduate student, was able to gain responsibility for large sections of the UIUC web purely by being enthusiastic. In fact, the work described in detail in this chapter is the result of just part of one year of my time and one summer of a permanent staff member's time.
In this chapter, you learn about the design goals and procedures used to develop the system. I mention all the tools that were used, where to get them, and equivalent tools for non-UNIX systems. I also discuss problems encountered and-where possible-their solutions.
My implicit goal was to get more people using the Web. Just as e-mail becomes more useful the more people use it, universal Web usage enables you to envision a true "paperless office." More than just computerphobia has to be overcome to make the local web a valuable resource, however. The time required to find a computer, log in, fire up a browser, and find one piece of information (for example, a phone number) usually is longer than it takes to go to a paper resource (for example, a phone book). Thus, the web must provide a comprehensive resource so that one-stop information shopping is more time efficient than gathering paper documents. The information must be presented in a manner that simplifies data collection, either by providing search options or hypertext links to related documents. Finally, providing information that is difficult or impossible to get through traditional means also increases the local web usage.
The UIUC web provides a comprehensive set of resources that are far more detailed than this chapter can cover. This is due in large part to two rich information sets: one that is better than the paper version and one that is inaccessible elsewhere. The former set consists of heavily cross-linked versions of course descriptions and class schedules, eliminating the need for students to flip back and forth between different thick paper documents. The latter set contains geographical information about the campus: maps, floor plans, and a virtual walkthrough. Both resources have served as seeds for other projects. The on-line floor plans, for example, serve as a base for information about wheelchair access to campus buildings, and the hypertext version of the graduation requirements makes extensive use of the course information.
Perhaps the most "bang for the buck" was obtained by putting course information on the web. Although it is true that this information is commonly available in print, the information is scattered across a couple of books: the Timetable lists class times and locations, and the Courses Catalog is a catalog of course contents. Hypertext ties the information together into a package that is easier to use.
My own involvement in the UIUC web came about precisely because of the annoyances of flipping back and forth between the Courses Catalog and the Timetable. I was so frustrated by
filling out my course request form that I vowed to put all the engineering course descriptions and timetable information on the web.
Getting the timetable information was easy: it was already on-line in the UIUC "phonebook" database (CSO ph):
name: ge221 introduction to general engineering design.
text: fall95
: prerequisite: t a m 212 and 221, and c s 101.
: 3 hours.
: 03907 lect-disc b 10 m w f 216 trans bld
: b 11 w 216 trans bld
: 03908 lect-disc c 1 m w f 101 trans bld
: c 2 w 101 trans bld
I wrote a script that teased out the department abbreviation (or rubric), the course number, the course title, the prerequisites, and information about the specific sections. I made the record more visually appealing with judicious insertions of mark-up tags. It also was easy to create links from the course number to the course description, if I assumed that the course description URLs were derived from the same rubric and number in a regular fashion. Because I was creating the URLs for the course descriptions, this was a safe assumption. Had the Timetable and Courses Catalog appeared on the web at two different times or with two different authors, cross-linking them might not have been so straightforward.
The prerequisites were more difficult to handle. They frequently appeared in a list, with all but the first rubric omitted. For example, the following list does not have a rubric (t a m) preceding the second course number:
: prerequisite: t a m 212 and 221, and c s 101.
My script had some relatively simple rules for expanding lists, but it did not link all classes properly. The script recognized only the first two entries in the sequence t a m 150 and 151 (or 154), for example. Such cases were an overwhelming minority, however. A document that had most of the classes properly cross-linked was a vast improvement over a document that had no classes cross-linked. (Besides, I reasoned, the Timetable came out only three times a year; the handful of cases in the engineering college information that the script missed could be done by hand.)
After the timetable conversion script was working, I needed to create the files to which it linked. To get enough data to do a proof-of-concept implementation, I typed all the General Engineering course descriptions by hand. For example,
221. Introduction to General Engineering Design. Fundamental
concepts in the analytical modelling, classical and computer-based
analysis and design of structural and machine components
and assemblies; external loads, internal forces and displacements
in statically determinate and indeterminate configurations;
kinematics of linkages, gears, and cams; static forces
in machines. Prerequisite: Theoretical and Applied Mechanics
212 and 221, and Computer Science 101.
3 hours.
At first glance, parsing this natural-language text seemed a daunting
goal. But on second glance, I saw great regularity buried inside
the record. Records are separated by two newlines. The first piece
of the record is the three-digit course number, followed by the
course title, followed by a period. Prerequisite classes are listed
after the word Prerequisite,
and the last piece of the line is the course credit. After making
a full name-to-rubric translation table, I was able to pull out
all the required information.
| Tip |
Always take a second glance at natural-language text. You might find enough information in a regularly established form to be able to make useful hyperlinks. |
I had learned some important things from my work so far. In particular, I had learned that I did not want to type in the course descriptions for every single engineering class. Surely the text of the Courses Catalog existed on disk somewhere on campus; the trick was finding it. After about 10 phone calls, I learned that the possessor was Mark Netter in the Office of Facility Planning and Management.
Extracting a copy of the files took a bit of work. Mark had never seen the Web before, so he didn't really understand what I wanted to do. Furthermore, he had his doubts about handing over what was, in truth, a legally binding promise by the university of the course content. He certainly was justified in being concerned; I was just a maverick graduate student with no official charter or backing. I tried to persuade him that I'd be a good girl and not damage the integrity of the text, but he was unconvinced. "I'll have to speak to my boss, Jane Loeb, about this," he said with a furrowed brow.
It was all I could do to keep a straight face. You see, I went
to high school with Eric Loeb, his boss' son. Furthermore, Eric
was the main instigator of the Senator Kennedy (http://www.ai.mit.edu/projects/iiip/Kennedy/homepage.html)
and City of Cambridge (http://www.ai.mit.edu/projects/iiip/Cambridge/homepage.html)
WWW sites. So although it was a close call, I did get the data.
| Tip |
Getting information from a third party can take perseverance. Having either an official charter, friends in high places, or both helps. But remember, getting this information elsewhere beats typing! |
After I had the course descriptions in ASCII form, it took just a few more tweaks of my scripts to complete a fully functional, cross-linked courses catalog/timetable document. I was starting to bump up against my disk quota on my student account, however. I sent e-mail to Ed Kubaitis of the Computing and Communications Services Office (CCSO), letting him know that this new resource existed and asking whether I could get some disk space somewhere to put it.
CCSO could have been very bureaucratic and uptight. They could have quoted obscure policy to deny me additional resources or even to shut down my unsanctioned documents. Instead, they endeared themselves to me by enthusiastically supporting my efforts. When I left for the summer, I was happy to turn my project over to Mike Grady at CCSO. When I returned in the fall, I was happy to take a position with CCSO as UIUC Web master.
It is perhaps not surprising that Mike needed to do extensive rewrites of my volunteer, engineering-only hacks to turn them into robust scripts that would work for the whole university's offerings.
I had divided the engineering information into one file per department.
Mike found that for the larger departments, however, my scripts
would create files so long that download times were excessive
and, in some cases, crashed some browsers. Mike therefore put
each course in a separate file.
| Caution |
Keep your pages at less than 30KB. Longer documents take an unreasonable amount of time to load. Some browsers may crash if the pages are too large. |
As an official CCSO staff member, Mike had the contacts and standing to get daily updates of the timetable information from Administrative Information Systems and Services (AISS). Although this meant preparing a parser for a completely different format, the benefits of having-for the first time ever-a readily available, up-to-date timetable could not be ignored. Mike also made the scripts bulletproof-able to deal with typos, all variants of prerequisite listings, missing updates, and so on.
When I returned in the fall, Mike also told me that putting information on the Web had produced fundamental procedural changes at the Office of Facility Planning and Management. Course offerings change all the time, but the expense of paper printing meant that the Courses Catalog was published only every two years. At that point, there would be a flurry of activity to ensure that the catalog was internally consistent. Between printings, however, the office received absolutely no pressure to maintain internal consistency. To take advantage of Mike's ability to take updates at arbitrarily small intervals, they restructured the way they approached their data.
The resulting cross-linked documents have become a resource for
a wide variety of other documents: departments' home pages link
to their course offerings, students' resumes link to courses they've
taken, graduation requirements link to acceptable courses, and
so on.
| Tip |
People who are just starting to write HTML like to have something to link to. Good WWW resources act as seeds for further growth. |
Another example of a useful "seed" resource is a university's navigational system. A university provides nearly limitless opportunities to get lost. Meetings, seminars, classes, exhibits, and administrative errands pop up constantly-and usually are located across campus.
People take for granted that graphical navigational aids are unavailable: they scratch out elaborate textual instructions on yellow stickies for how to get from point A to point B. Unfortunately, these instructions are frequently difficult to interpret, leave out crucial pieces of information, or are just flat-out wrong.
The Web is a perfect vehicle for maps and floor plans. Not only
can it display images with casual ease, but those images can be
manipulated on-the-fly to highlight particular locations. Furthermore,
people easily can make links to the locations, the images can
be connected to one another via imagemaps, and the images can
be printed for on-the-go reference.
| Caution |
Providing maps and floor plans on the Web is not a project for the faint of heart or weak of resolve. The work is painstaking, tedious, and without immediate reward. This is not a job to turn over to college freshmen to do in their copious spare time. |
Full of enthusiasm for putting maps and floor plans on the Web, I immediately hit obstacles. The first was finding suitable floor plans to start from. Without too much trouble, I found floor plans of the engineering buildings (via the dean's office). However, these floor plans frequently were very faint, had a "dirty" background (from many generations of photocopying), or were woefully out of date. Worst of all, north was not always oriented up on the drawings. This fact might not bother anyone from mountainous regions, but in the flat, featureless Midwest, people demand that north be up.
I was certain that electronic versions of the floor plans had to exist somewhere; the computer revolution could not have passed by UIUC completely! Right after I started with CCSO in August, I started asking where the floor plans were. I got lots of hesitations, head-scratching, and more than one interrogation on why I wanted the information. I probably talked to 20 people before I finally found the Man with the Maps in October.
Fortunately, the Man with the Maps, William McKinney of Operations and Maintenance, thought it was a great idea, and he opened his whole electronic archive to me.
The next step was to convert William's AutoCAD drawings into GIFs that I could use. Translating the images required the following steps:
Rotating the drawing so that north was up When the floor plans were linked to maps, it was disorienting if the floor plan orientation didn't match the map orientation.
Resizing the drawing Ideally, the image should be small enough to fit inside a reasonably sized window, yet large enough that the room numbers can fit inside the rooms. These competing constraints were much less trouble for older buildings, which tend to be small and have big rooms, than for the newer buildings, which tend to be large buildings with small rooms.
Removing the room numbers Operations and Maintenance stuck the room numbers inside a circle in the doorway. Unfortunately, when the floor plans were small enough to be reasonable for a Web browser, those room numbers were too small to be legible.
Removing other extraneous drawing layers Some
blueprints had conduit, electrical wiring, or telecom wiring that
cluttered up the drawing.
| Tip |
If you're trying to translate images for a similar project, these first four steps are best done in AutoCAD because it is a vector-drawing package. Resizing GIFs with such fine line art causes large pieces of it to disappear, whereas AutoCAD can be scaled up or down infinitely. AutoCAD also has fine "layer" control-room numbers, annotations, and conduit can be removed cleanly without deleting chunks of important elements, such as walls. |
I converted the AutoCAD drawings to GIF by using the Grab feature of xv. (For more on xv, see Chapter 15, "Multimedia.") I hit Grab and used the middle mouse button to define a rectangular region to capture.
At this point, I used xv's color-editing features to change the colors. The drawings that came out of AutoCAD-red on black-looked sharp on-screen but were practically illegible when printed. I settled on a white background, black walls, and red room numbers. This color combination looks almost as good on-screen as the red on black, and it looks much crisper when printed.
I then used xpaint for the tedious process of reinserting the
room numbers. (See Chapter 15 for more
information on xpaint.) Microcomputer users can use any of the
many paint programs available; I personally like Photoshop on
both the Mac and PC.
| Caution |
I have not come across a version of xpaint that does not occasionally garble GIF files beyond recognition. On the other hand, it seems to be quite happy with TIFFs. In xpaint, I always save files as TIFFs and use xv to convert from TIFF to GIF. |
After I finished GIFs for all the floors in the building, I printed them (using a Web browser's Print option), slapped them onto a clipboard, and walked through the building. I made notes of stairs, ramps, entrances, bathrooms, lounges, photocopier rooms, mechanical or electrical rooms, janitorial closets, classrooms, department offices, society offices, elevators, and any other features of interest. Most important, I noted errors in the floor plan.
After returning from walking through the building, I made corrections to the floor plan, again using xpaint. I also made simple annotations: UP and DN for the stairs, the location of wheelchair entrances, and so on. When I was satisfied that the floor plan accurately reflected reality, I put the name of the building (and a big arrow pointing north) on the first-floor floor plan.
I then made an imagemap file using MapEdit. (For details on basic imagemaps and MapEdit, see Chapter 16, "Imagemaps.") PC users can use MapEdit for Windows (available at ftp://sunsite.unc.edu/pub/packages/infosystems/WWW/tools/mapedit); Mac users can use Mac-ImageMap (http://www.starnine.com/webstar.html) or WebMap (http://www.city.net/cnx/software/webmap.html). With MapEdit, I just had to click on two corners of the room and fill in the dialog box with the room number, and MapEdit made an imagemap file of the following form:
rect 114 290,174 326,92
After defining the room boundaries (a relatively dull and tedious task, even with MapEdit), I used a text editor to replace rect with, for example, rect http://www.uiuc.edu/cgi-bin/who_is_in?bldg=altgeld&room=. I also could have used a brief sed script:
s,rect ,rect http://www.uiuc.edu/cgi-bin/who_is_in?bldg=altgeld\&room=,
Note that it is easier to use commas as delimiters instead of slashes; note also that the ampersand (&) is a special character in sed (and vi) and must be escaped.
The imagemap thus is set up so that instead of a static HTML document, clicking on an imagemap gives the user the output of my CGI script who_is_in. The Perl script who_is_in reads in a data file (defined later in this chapter) to get the URL for the occupant of a specific room, and the browser is redirected to that URL. Putting in a level of indirection instead of returning the URL directly accomplishes many things all at once:
| Note |
The code for who_is_in and its related programs are available at http://www.uiuc.edu/navigation/tools/. |
I then entered occupancy information into a data file used by who_is_in. The file has four columns: owner, room number, URL, and occupant:
math 114 http://www.uiuc.edu/nav/data/lounge.html Lounge
This file is designed for easy maintenance. If the math department shuffles things around, for example, it is easy to delete all the lines that start with math and append the new information.
The following Perl fragment splits out the four fields:
# owner room URL occupant
if (/^([\w\-]*)\s+(\w*)\s+([\w*:\/\.~\'\-\#\+\?\%]*)\s+(.*)/) {
$owner = $1;
$room = $2
$url = $3;
$occupant = $4;
}
The if statement ensures that the lines follow a reasonable syntax and simultaneously chops it up into little pieces. Note that \s (Perl for any white space) is not a valid character inside the parentheses that define the first three fields. The last set of parentheses, defining the fourth field, allows any character (including white space).
I made generic files for common types of rooms (bathrooms, janitorial, and so on) and put those in the URL fields for such rooms. If I didn't know who or what was in a room, or if I didn't have a URL, I left it blank. This cavalier attitude on my part was due partly to expediency and partly to the belief that "Who is in this room?" is not a question that is asked nearly as often as "Where is this room?"
To show users where rooms are, I wrote the Perl script where_is. This script highlights a room in a building by drawing a circle around it. The script parses the environment variable QUERY_STRING (which usually is embedded in the URL) to determine the building name and room number desired.
From the room number, the floor number is determined, and the GIF and imagemap files are located.
The coordinates then are extracted from the imagemap file:
# Find all the lines that match the room and building
@match = grep(/bldg=$bldg/i && /room=$room\b/i, @lines);
# Throw away everything before the coordinates in the first match found
($throw_this_away, $coords) = split(/=$room\b/i, $match[0]);
# Pull out the coordinate pairs (split on whitespace)
($coord1, $coord2) = split(/\s/, $coords);
# Pull out the X and Y coordinates (split on commas)
($x1, $y1) = split(/,/, $coord1);
($x2, $y2) = split(/,/, $coord2);
The coordinates are passed off to a C program written by my office partner, Carlos Pero. I was fortunate that he was working on his coloring book (see Chapter 31, "A Web Coloring Book") at the same time I was working on this project.
Given the name/location of a GIF file (the floor plan), the center point, and radius (calculated from the coordinates extracted from the imagemap), Carlos's program generates a new GIF with a circle on it (see Fig. 32.1).
It was relatively painless from there to create an HTML "frame"
for this picture to plug into.
| Note |
Web clients do not start displaying data until the CGI script terminates. This means that if you remove your new GIF image before you exit the program, it won't be there when your browser tries to display it. Not ever deleting the file is not a legal alternative; eventually, you will run out of disk space. For that reason, where_is does the following: at the beginning of where_is, it checks the directory where the GIF files are stored. If any GIFs that are more than one hour old are lying around, where_is removes them. |
With only minor modifications, I enabled where_is to work with campus maps as well as floor plans. If the room is omitted, where_is looks up which of the several maps the building is on, looks up the imagemap, slices and dices, and draws a circle around the building.
where_is does the same thing if it can't find a floor plan for a building. This way, people can fully specify the location of their office; for example, they can use
http://www.uiuc.edu/cgi-bin/where_is?bldg=dkh&room=101
even if the floor plans for David Kinley Hall aren't ready yet. In that case, David Kinley Hall is circled on a campus map (see Fig. 32.2).
Figure 32.2: Circling a building.
When the floor plans for David Kinley Hall are ready, this link shows room 101 circled-with no additional action needed on the part of the link author.
Maps can be nested. On every frame surrounding a circled room or building, where_is creates a link: Where am I?. If the user is looking at 114 Transportation Building and clicks on Where am I?, the user next sees a map of the engineering campus with the transportation building circled. Clicking on Where am I? again yields a map of the whole UIUC campus, with the engineering campus circled. Clicking again gives a map of Champaign-Urbana with UIUC highlighted. Clicking again gives a map of Champaign County. (I wanted to be able to zoom out to the solar system, but I haven't yet found good non-copyrighted maps for the next levels.)
It would have been far easier to write where_is to take the arguments of image, x, y, and radius, but I think that would have been a mistake in the long run. People don't say, "My office is on the third floor of the English Building between coordinates 103,107 and 146,152"; they say, "My office is in 301 English Building." By having where_is take the building and room as arguments, it becomes easier for users to make links to their offices. It also becomes easier to write scripts to automatically wrap hyperlinks around room locations in existing text.
I will admit right now that the document set I describe here was made exclusively for show. Although the Courses Catalog and Timetable really are useful, they are about as sexy as toast. I needed something glitzy for a conference and needed it in two weeks. I wasn't sure how long it would take to whip up the floor plans, so I decided instead to make a virtual walkthrough of the campus, inspired by Kevin Hughes's Honolulu Community College work (http://www.hcc.hawaii.edu/). Figure 32.3 shows a screen from the walkthrough.
Figure 32.3: Walking around campus.
CCSO had an Apple QuickTake digital camera, which I hogged for about a week, running around campus. I made a number of mistakes, which perhaps my successors can avoid:
| Tip |
When you're taking pictures for a virtual walkthrough, stick to either the center of the road or the lane in which cars driving that direction face. |
I was fortunate cartographically, however. Because East Central Illinois is as topologically varied as a pancake, and because Urbana's street layout was determined by people and not by cows, the streets are in a nearly perfect, rectangular grid. Streets run north and south or east and west on campus, with no in-betweens. Therefore, connecting the images was easy: the only options were forward, left, right, and turn around.
The QuickTake 100 that I used could store 32 low-resolution images
or 8 high-resolution images. The quality of the low-resolution
images isn't great, but I didn't have time to run back to a computer
every eight pictures. Besides, I didn't have that much disk space!
| Tip |
To get the best possible image quality, use a film camera with a wide-angle lens and pay Kodak to make a PhotoCD. (Philip Greenspun has an excellent article on the how-tos of high-quality imaging at http://www-swiss.ai.mit.edu/philg/how-to-scan-photos.html.) |
| Tip |
Take east-facing pictures in the morning. Take west-facing pictures in the afternoon. Take north-facing pictures around noon. There is no good time to take south-facing pictures. (If you live in the southern hemisphere, reverse "north" and "south.") |
| Caution |
The QuickTake software names all batches of images the same (Image_1 through Image_32). You therefore need to be careful that the different batches of images stay in different directories until you've safely renamed them. |
Once at my workstation, I used xv to tweak the image quality and to convert the files from GIF to TIFF. (Photoshop works well for microcomputer users.) The QuickTake pictures look great on a Macintosh, but they are too dark on UNIX workstations. This difference in quality has to do with a different gamma correction in the monitors. To fix it, I use xv's ColEdit feature to change the gamma correction. I've found that a gamma correction of 1.3 or 1.4 works reasonably well, but hand-tweaking gives the best results.
The naming convention I used was very important in stitching all the pictures together. I named each image
on_street.direction.cross_street.gif
where direction was the direction the camera was pointing, on_street was the name of the street that the camera was aiming down, and cross_street was the intersecting street (perpendicular to the camera's line of sight). Thus, for a picture at the intersection of Green and Mathews, facing north on Mathews, the name of the picture is mathews.n.green.gif.
For pictures taken in the middle of a block, I created imaginary streets. These streets had the name of the parallel street that was just east or south with a + sign appended. Thus, the picture I took facing north on Mathews, a half-block north of Green, is named mathews.n.green+.gif.
The regular topography and file-naming conventions allowed me to make the frames (the HTML documents that the pictures plugged into) automatically. I embedded knowledge in the script about the order of the streets via Perl's handy associative arrays. For example,
$northof{"green"}="boneyard";
$northof{"boneyard"}="western";
I also made a list of where buildings were
$bldgat{"firelane+.n.illinois" = "union";
$bldgat{"burrill+.s.green"} = "altgeld";
And I made a list of where the edge of the known universe was
$bldgat{"harvey.n.springfield"} = "NULL";
$bldgat{"main+.w.wright"} = "NULL";
Armed with this information, my scripts could just walk through all the picture points and create the appropriate frames. The frames were given the same name as the picture (with .html replacing .gif). The appropriate frame was linked to the Go Forward label by changing the cross street. Turn Around was linked to the frame found by flipping the direction. Turn Left and Turn Right frames were found by swapping cross_street and on_street and transforming the direction.
If a building was in the Go Forward direction, then the text above the picture was replaced with Enter building. Clicking on that text takes the user into the building lobby-a document with information about the building. Each lobby has the building name, the street address, the latitude and longitude, and a brief discussion of the building's history and/or purpose.(See note) When available, the first-floor floor plan, exterior pictures of the building, and a detailed description of a building's architectural details also are present.
Instead of making static HTML frames, the frames almost could have been generated with a CGI script. There were just a few irregularities in the street layout, however. (For example, there are two streets between Mathews and Wright south of Springfield, but north of Springfield there is only one.) More important, disk space is cheaper than processor power, especially for such small text documents.
The virtual walkthrough is linked tightly with the rest of the navigational system. Many of the first-floor floor plans' imagemaps are set up so that clicking near a building entrance takes you to the view that you would see when going out that door. And, just as the building "lobbies" can be entered from the walkthrough, many building lobbies have Exit to Street links. And, just as clicking on a building on one of the campus maps takes you to a building lobby, clicking on a street takes you to the virtual walkthrough frame for that location.
As I mentioned at the beginning of this section, I did the walkthrough purely for glitz. After all, I reasoned, my primary "customers" live here; they know what the place looks like. I thought that prospective students might like to take a look around, but I doubted that colleges are chosen on the basis of what the outsides of buildings look like. I forgot about two groups of constituents, however. The first group consists of prospective students with restricted mobility. Through the virtual tour, they can see that Urbana truly is as flat as a board.
However, the most emotional reaction that I got was from a group I'd overlooked despite being a member myself: alumni. UIUC has undergone an enormous amount of construction since the football team started winning 10 years ago. Because Urbana is not exactly on the major travel routes, most alumni have not had a chance to see the results of the new construction. They really appreciate being able to wander around their old stomping grounds!
Although the UIUC web is very advanced in terms of services available, my colleagues and I still are grappling with some fundamental questions about the presentation. Unfortunately, there are no right answers-only wrong ones.
How many decorative images should be put on a page? The more images, the more professional it looks. The more images, the easier it is to develop a distinctive look and feel for the site. However, the more images, the longer a page takes to download.
If I knew that every single one of the users was sitting at a Sparc 20 and coming across the campus backbone, the choice would be obvious. I know that this is emphatically not the case, however. About half of our accesses are from off campus, with about nine percent from overseas. Even locally, the access speed is uncertain. I personally dial in from home on a Mac IIcx with a 9600 baud modem.
One trade-off is in verbosity. External users might like a bit of an introduction to the campus-how many students attend, what facilities are available, what awards and rankings UIUC has garnered, and so on. Local users might only be annoyed at having to wade through so much text.
Experienced users favor terse indexes that can be navigated quickly. Novice users favor more explanation and hand-holding.
Another trade-off is in document length. Should one index take
up several screenfuls, or should the index be split hierarchically,
with each leaf node being very small? The answer to this question
again depends on the user's configuration. If the user has a very
slow connection and is running a browser that starts displaying
information before the end of the document is loaded, one long
file probably is preferable. If the user has a blazingly fast
connection, the smaller files probably are preferable.
| Note |
The HTTP protocol has what is called slow start handshaking. This means that the shorter the file, the more traffic overhead (as a percentage) there is. Transmitting one long file can be significantly faster than transferring the same number of bytes as many short files. |
Netscape provides a number of extensions to HTML that, properly used, can make documents much more visually appealing. These documents can look singularly unattractive, however, when viewed with a browser that follows the proposed standards more closely. Although data seems to indicate that a majority of users use Netscape, a significant minority does not.
Given that Mosaic was developed at UIUC, it was clear to me that UIUC pages needed to conform strictly to the proposed standards. Other institutions will need to wrestle with this issue.
Some concern has been raised lately about the anarchistic nature of the UIUC web. Administrators are worried about the lack of rules concerning what material is acceptable for inclusion in the Web and how it should be presented. They also are concerned about forgeries and misinformation.
Unfortunately, the Web does not lend itself well to centralized control. Because any computer on campus can become a server, finding violations would require active patrolling. Because the information can change in a heartbeat, ensuring continual compliance is impossible.
Furthermore, UIUC cannot control anything off campus. If I put up a parody of the Department of Civil Engineering's web page on another server, UIUC has very little legal recourse. (Parody is specifically deemed to be "fair use" under U.S. copyright laws.)
And although someone coming through http://www.uiuc.edu
probably won't run across that page, someone coming from one of
the Web search tools (such as Lycos http://lycos.cs.cmu.edu
or WebCrawler http://webcrawler.com/)
clearly might. If the browser doesn't display the URL (as is Netscape's
default behavior), that user might think that the parody page
originated at UIUC.
| Note |
I've seen some administrators hesitate about putting information on the Web because of concerns of forgery. An institution is actually more vulnerable to misinformation if no official site exists; a bogus page can be tossed up even if an official page does not exist. Furthermore, the existence of an official page dilutes the effect of a bogus page. If Lycos finds two UIUC Civil Engineering Department pages, the alert user might recognize that something is amiss. If Lycos finds only one document, the user has to be much more alert to notice that something is amiss. |
| Note |
It is an extremely good idea to put the name of the institution in the title and/or beginning of the document. Not only does this help identify the page when someone reaches it from nonstandard paths (for example, Ed Kubaitis's Random Yahoo! Link at http://www.cen.uiuc.edu/cgi-bin/ryl), but it also helps search tools find your document. Lycos indexes only the first 20 lines or first 20 percent of a document, for example-whichever is smaller. |
I enjoy the conceit that the effort that has gone into these systems has been well spent. Users from around the world access the course and navigational pages about 75,000 times per month.
It would be presumptuous to claim credit for all of the half-million accesses per day to the top-level server (www.uiuc.edu), or for the existence of the 276 other HTTP servers on campus. However, the Courses Catalog and Timetable show the possibility of writing scripts to convert text files to HTML and the added value of a hypertext presentation. The navigational system demonstrates the potential of dynamic graphics for displaying information that is otherwise not available. The systems described in this chapter therefore have been valuable building blocks for other projects and good examples of the capabilities of the Web.