These efforts have been extremely successful. High-level administrative officials have taken an active interest, usage by students, faculty, staff, administrators, and people from off-campus is high, and a permanent, full-time position has been created just to coordinate the university-level Web efforts.
In this paper, I will describe the work that I did over three semesters towards developing the UIUC Web. In particular, I will:
Until a few years ago, the only tool available on the Internet for distributing information to an unidentified audience was ftp (File Transfer Protocol). Using ftp software, people could access documents on any computer in the world, as long as the remote computer was connected to the Internet and configured with the proper software.
The ftp transactions used a very simple version of what is called a client-server architecture. One piece of software would be used by the person who wanted to get the information (the client), and another piece of software would be continuously running on the machine with the information (the server). To give an analogy, the server is like a butler for the computer. When a request is presented at the entrance to the computer, the server examines the request and determines if that request is understandable and can be fulfilled. If so, the server gets the information and presents it back to the requester. Thus clients can get information from the remote computer without being able to "enter" the computer themselves.
A big advantage of a client-server architecture is hardware and operating system independence. If the interface between the client software and the server software is very well defined, client and server software can be written for several different types of computers. A Macintosh can use ftp client software to connect to a ftp server running on a Cray, or vice versa. No longer were computers constrained to only communicate with other computers of the same type.
Unfortunately, finding and retrieving interesting resources with ftp was complicated. To look at a graph of stock prices, for example, might take the following steps:
Needless to say, the appeal of such operations was limited. In 1991, the University of Minnesota began development of a different client-server system called gopher. Gopher clients had a text-based, menu-driven, hierarchical organization of files, and allowed users to examine plain text files with the same software that they used to navigate through the menus. Furthermore, gopher provided an ability to search through all of a server's files for user-specified character strings, and allowed connecting other gopher sites to menu entries. This allowed people to aggregate information based on topic, even for information that was geographically dispersed. @@@gateway to programs? - have a call in to check@@@
@@@ Unsure of next paragraph - am checking ---- However, gopher clients were unable to access ftp sites. The negotiation (called a protocol) that took place between the client and server was different enough that ftp sites couldn't understand gopher requests, and gopher clients didn't even allow the users to ask for information from an ftp site. To go back to the butler analogy, it was as if a courier speaking English went to the back door, while the Chinese-speaking butler was waiting at the front door. If a consumer or provider wanted to make sure of their ability to communicate with all others, they would need software for both protocols - essentially having two couriers or two butlers, one speaking English and one speaking Chinese.@@@
Meanwhile, at Europe's CERN physics laboratory, a very small team had been working for about a year on a hypertext system, dubbed the World-Wide Web, for sharing research information. Tim Berners-Lee and Robert Cailliau envisioned a distributed hypertext system for publishing documents over the Internet to allow for better communication and archiving of knowledge in their organization.
CERN has an interesting environment. Not only does it have heterogenous hardware, software, and data formats, as is true in many companies, but many researchers are there for relatively short periods. This large population of transients leads to a form of organizational amnesia. Important information is lost every time a researcher returns to his or her "home" institution.
Berners-Lee and Cailliau felt that a system to allow for easier publishing of information would help defray this continual disappearance of organizational memory. Because of the environment they were in, it was clear to them that they needed a system that would be extremely flexible, open, and extensible. The system they developed, the World-Wide Web had all of the features of gopher in this regard, plus three more.
Because the specifications were an open standard, other people could and did develop WWW software. Two early browsers that came from outside CERN were Viola and Cello. Viola was developed by Pei Wei at Berkeley in January of 1993, and Cello was developed by Thomas Bruce at Cornell later in 1993. Both browsers used a page-oriented, multifont, point-and-click interface.
Meanwhile, two programmers at the University of Illinois' National Center for Supercomputing Applications (NCSA) developed a browser called Mosaic. Marc Andreessen and Eric Bina jointly developed this browser to not only have point-and-click capabilities, like Viola and Cello, but it also to display graphics in-line instead of spawning a separate image. This feature, good timing, and the resources available at NCSA to develop, publish, and support binary, ready-to-use versions for X Window, Mac, and PC clients made Mosaic far more popular than any of its contemporaries.
Rob McCool, who was also with NCSA, developed a web server, called httpd. Collaborating with the Mosaic team, McCool developed a mechanism that allowed a server to execute a program and send its outputs to the browser as if it were a static file. This Common Gateway Interface (CGI) allowed dynamic data to be transmitted over the web. Things as mundane as the local time in various places around the world, and as exotic as an interactive map of the world with arbitrary scale were placed onto the web using this CGI programs. Kevin Hughes, who was a student at Honolulu Community College, wrote an important CGI program that allowed for "clickable" images. regions could be defined inside an inline image; clicking in such an area would take the user to another URL. This was incorporated into NCSA's httpd distribution.
By this point, the Web had all the components needed for a universal user interface for unknown-audience document publishing. Independence of physical location, hardware, operating system, software, and transfer protocol for both servers and clients, and format independence for the data meant that practically anybody could easily publish and/or view information on the Web.
Furthermore, the Web being an open and extensible system meant that obsolesence would not be an issue for some time, if ever. New protocols and new data formats might spring up, but they would augment, not eliminate earlier versions. This, and the easy availability of free browsers, servers, and helper applications that were easy to install and use lead to a remarkable growth around the world in the Web.
The Computing and Communications Services Office (CCSO) had a server on-line with a web page for university-level information. However, the developer of that page, Ed Krol, was on leave at that time to promote his best-selling book, The Whole Internet User's Guide and Catalog. All that existed on the page was an image that changed automatically according to the current weather conditions, linked to the local weather forecast. This was technically a neat trick (requiring intelligent parsing of the local weather forecast), but limited in its utility.
There were also some UIUC sites with reasonable information that was restricted in scope. For example, Ed Kubaitis of CCSO had developed a rich set of indices to information available (mostly elsewhere on the web) of interest to the College of Engineering. The Departments of Electrical and Computer Engineering and Computer Science, the College of Agriculture and the Graduate College, and the student societies of Eta Kappa Nu and Association for Computing Machinery had pages available.
While there was a list of all the servers on campus, it was organized from a technology point of view - what computers hosted information instead of what information was provided. The sites also varied greatly in the amount and type of information served. The College of Agriculture, for example, used their web site mostly for training (e.g. how to use electronic mail) while the Department of Computer Science used its site to present reference material, centered around their advising handbook.
It was somewhat surprising how ad hoc and scattered the UIUC Web was. I believe that one reason why the UIUC Web was underpopulated was because so much Web development was happening at NCSA. Energetic computer science students who wanted to do something with the neat new technology were quickly hired by NCSA to work on Web tools, instead of playing on their own to develop Web content.
Another problem that was not unique to UIUC was that this technology landed in a gap between traditional departmental responsibilities. CCSO had the technical skills needed to publish on the Web, but were not chartered to do content development. The Office of Public Affairs and the Office of Publications develop documents for external and internal consumption, respectively, but had no experience with the Internet. To complicate matters, this medium needed to serve both internal and external consumers of information.
Furthermore, while at that time the technical underpinnings of the Web were complete, and Vice-President Al Gore had popularized the phrase "information superhighway", very few people had ever heard of the Internet. Even fewer had heard of the World-Wide Web. Of those who had heard of the Web, a significant number were certain that it would be at worst a mere fad, or at best quickly replaced by something more technologically advanced. The unfulfilled promises of multimedia and "the paperless office" had jaded many into a "wait-and-see" stance.
It was into this void that I jumped. I first developed pages for what was then my research group, the Illinois Genetic Algorithm Laboratory (IlliGAL). But what really got me started on university-level information was registering for classes in April of 1994. I got extremely frustrated at having to continuously move back and forth between the departmental graduation requirements, the course descriptions, and the schedule of when and where classes were offered. I recognized that this was a perfect application of hypertext, so developed a Web version of the Courses Catalog and Timetable, first for General Engineering classes and then for all classes in the College of Engineering and the Mathematics Department.
Because there wasn't a page for the General Engineering department where the lab's page and the registration material could be listed, I created a page for the General Engineering department. Because there wasn't a good place to list the General Engineering department or the college-level class information, I created a page for the College of Engineering.
At this point, I notified CCSO that the pages existed, and asked if they could perchance find some disk space available to me, as I was running close to my quota on my student account. This lead to my being offered, the next semester, an assistantship as Webmaster for the university. (As a graduate assistant, my salary was low enough that CCSO could easily afford to take a risk on this novel medium.) Thus, in August of 1994, I was given carte blanche to develop Web resources, with the explicitly broad directive, "Go do great things."
Developing a well-developed framework was thus a high priority. Not only would a good, centralized index of university resources be useful to people seeking information, but done properly, would encourage people to develop resources. Any comprehensive list of organizational units - with only the units providing web pages hyperlinked - would make immediately obvious the groups without web resources. I felt this might goad individuals from laggard organizations to push for development of their own web resources.
It was also clear that some significant resources should be developed to pull people into using the Web, and to act as exemplars of what could be done. I felt that there were several important features for exemplars. They should be items of wide interest and provide a better presentation of the information than the paper version. If the items were visually interesting and/or unavailable on paper, this would also encourage Web usage and thus development.
The resources that I decided to focus on pertained to the registration information that I had already started and those pertaining to navigational aids. Almost everyone on the campus is involved in some way with classes. (It is, after all, the university's stated mission.) As for the navigational aids, the University of Illinois is a geographically very large institution, with ample territory for getting lost. While some navigational resources are available -- for example, a map printed in all the phone books -- more detailed and sophisticated navigational resources were simply not available. Navigational systems have the added benefit of being visually appealing.
This was the motivation behind focusing on my three main objectives:
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.
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.
At first, almost everything was linked to from the top page in the hierarchy, the university's home page. As the local Web grew, however, it was necessary to expand the indices (with the help of the Publications Department) to more levels. The UIUC home page can be seen in Figure 1; pages of the second level can be seen in Figures 2 through 9.
There are two interesting things to mention. The first is that not everything was hyperlinked initially. In particular, the Colleges and Instructional Units page had links to only about a quarter of the units (with two more added quickly only because I myself developed skeletal home pages for those colleges in order to be able to "plug in" departments in those colleges).
The other is that is that many pages that are now at the third level have been moved down. These pages are primarily ones that deal with either entertainment or references, and consist mostly of links to resources outside the UIUC Web. Initially, because the UIUC Web was so sparse, outside links and/or links to things outside the main function of the university were more prominent. In particular, the References page used to be very prominent, and a fair amount of effort was taken to develop the sub-categories of references. More local, relevant content displaced those pages.
The transition to more layers of hierarchy was not without pain. One of the more challenging aspects of my job after the restructuring was tactfully explaining to people why their Web site didn't rate a mention at the top level of hierarchy. There was also a conflict between keeping the page length short and providing enough information that people could figure out what was at lower levels.
In addition to the pages in Figures 1 through 9 and the sub-pages on the References page (language, government, scientific, research, periodicals, geographic, financial, and fun), I developed indices to Big Ten schools, classes with Web resources, arts and entertainment, news, people, career information, sports and recreation, research laboratories, and research papers.
Furthermore, I developed a number of skeletal pages. These were usually done for personal reasons - because I myself had an affiliation or need. For example, I had a BS in Metallurgical Engineering and a need for a job, which lead me to develop the Materials Science and Engineering home page and an on-line resume book. Sometimes, however, I would create a page out of a need for a "bridge" between information that became available and the existing indices.
For these reasons, I developed the original pages for: the departments of General Engineering, Mechanical and Industrial Engineering, and Materials Science and Engineering, the Colleges of Engineering, Liberal Arts and Sciences, and Fine and Applied Arts, the Illinois Genetic Algorithms Laboratory, the Dean's Student Advisory Committee, the Society of Women Engineers, International Programs in Engineering, the Engineering Placement Office, awards, the Engineering Handbook, the Guide to Services, campus computer laboratories, and syllabi for several of the courses I took.
These were not intended to be more than placeholders, there until the appropriate information provider could take them over. By the time I left campus, all but six (not counting the syllabi) had been expanded and updated by the responsible group.
My goal was to provide a usable navigation system, one that allowed people to not only easily find information that would help people navigate through the campus but to easily link to pages that would show others how to get to the location of interest. Thus people would be encouraged to make links to maps on their home pages showing the location of their office, seminar announcements, meeting locations, and classroom locations.
Towards that end, I built a navigational system consisting of many tightly interlocking pieces:
People used to ask me why I included latitude and longitude information. I used to say, "I don't know, but if I put it there, someone might find a novel use for it. If I don't put it there, nobody will find a novel use for it." There is now some talk, however, of using that information to estimate travel time between points. This travel time could be used to advise registering students of overly aggressive transfers between classes.
Furthermore, occupancy information can be determined on a room-by-room basis by clicking on the appropriate room. For example, clicking on the floorplan at room 117 (on Figure 11A) will take you to the General Engineering Department's home page (Figure 13). (To get to different floors, the user can click on the stairs or the elevator.)
Once on the General Engineering Department's home page (Figure 13), clicking on the text 117 Transportation Building will take the user to a page showing the first floor of the Transportation Building with room 117 circled (Figure 14). This "zooming out" can continue for several more layers. Clicking on Where am I on campus? on this page will take the user to a map of the Engineering campus with the Transportation Building circled (Figure 15). Clicking on All-Campus Map at the bottom of this page will take the user to the all-campus map with the Engineering campus circled (Figure 16). Two more levels of "zooming out" are possible to show the location of the campus in relation to Champaign and Urbana, and the location of Champaign-Urbana in Champaign County.
"Zooming in" is also possible. From the all-campus map (Figure 16), clicking on the top rectangle will take the user to the Engineering campus map (Figure 15 but without the circle). From the Engineering campus map, clicking on the Transportation Building will take the user to the Transportation Building lobby (Figures 11A and 11B).
All 134 buildings with information can be "zoomed in" on in this manner, and all the buildings' locations can be found by "zooming out" from their respective lobbies, with circles surrounding the building of interest the appropriate map - one of four area maps, or on the all-campus map for those outside the main campus core.
The URLs for these maps and floorplans was very deliberately kept simple. It would have been relatively simple to write code that took the name of a GIF file and x-y coordinates from a URL and based all manipulations on that information. However, human beings don't think naturally in terms of pixels on an image. Humans think in terms of rooms numbers and buildings. Thus, extra work was done so that the information embedded in the URL would be the building and the room number instead of the location of the GIF file and the bounding box of that room.
Care was also taken to allow for appropriate fallbacks. If the location of a room in a building was requested, but no floorplans were ready for that building, the program would return instead the location of the building. This was done at the time of the access, so that people could make links to rooms that didn't have floorplans. Once the floorplans were made available for that building, the person's old link would suddenly show the room circled instead of the building. No intervention on the author's part would be required.
In all, there are 800 pages in the virtual tour - four compass directions at 200 geographical points. The points are, for the most part, a half a block apart, and cover the University property between University Ave on the north, Sixth Street on the west, Taft on the south, and Goodwin on the east.
The tour can be accessed in several ways. Aside from typing in a URL or selecting a link from the navigation index page, clicking near the entrance of a building on a floorplan can take the user into a tour. For example, clicking near the west door of the Transportation Building floorplan in Figure 11A will take the user to a view from the west door (Figure 25). (This is happens to be the same page that the user would come to by clicking on Turn Around in Figure 24.) Users can also click on a street in an area map, and for most locations on the Quad, Engineering campus, and Agriculture/Business maps, will be taken to the appropriate point in the virtual walkthrough.
The wheelchair pages were definitely an afterthought, something that turned out to be easy to do once all the other pieces were developed. They ended up yielding the most emotional appreciation and an award from the disabled students organization. The wheelchair access information also has a much broader utility than I had originally thought: information about ramps and elevators is very useful when moving equipment between buildings, or even for freshmen trying to figure out the vagaries of old, confusing buildings.
Occupancy information (needed for zooming in to rooms) was decentralized to the point of being inaccessible: I resorted to departmental phone lists and ambulatory inspections of the buildings.
The all-campus map was scanned in from a map developed by the Office of Facilities Planning and Management. The Engineering campus map was captured from a map developed by the College of Engineering's Office for Financial Programs. The other area maps were derived from blow-ups of the all-campus map.
It was necessary to do quite a bit more translation to obtain useful floorplans.
To ensure the accuracy of the floorplans, each building was subjected to an on-site inspection. While the accuracy of the floorplan was verified, the locations of bathrooms, department offices, conference rooms, classrooms, elevators, mechanical closets, janitorial closets, photocopiers, computer laboratories, and many other features were also noted.
URL x1,y1 x2,y2where URL is the URL of the page that should be returned if the user selects a point inside the box bounded by coordinates x1,y1 and x2,y2. It would clearly be convenient for the user to be able to click on the image of a floorplan and be given the home page of that room's occupant. It would also clearly be useful to have the room number associated with the coordinates, for use by where_is. The script who_is_in was developed to allow the room number to be attached to the coordinates while still returning the proper home page(s). A level of indirection is employed; instead of the map data file containing lines like
http://www.webfoot.com/ducky.home.html 123,456 321,654the file instead includes lines like
http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451 123,456 321,654A separate data file for each building connects the room number to the occupant's home page with additional information:
ccso 451 http://www.webfoot.com/ducky.home.html Sherwood, Ducky
Note that the image coordinates corresponding to the location of the rooms' walls, need only change when buildings are remodeled. This is usually an infrequent event. The occupancy information, which changes frequently, is arranged by room number. Segregating the rarely changing information from the frequently changing information simplifies maintenance; making the frequently changed information in well-understood terms eases maintenance even more.
The first field gives the "owner" of the room, so that buildings that are shared by more than one academic/administrative unit can be more easily updated. The second field gives the room number. The third field gives the URL of the occupant, and everything past that (a variable-length field) is the name of the occupant.
The script who_is_in determines which data file to use (based on the building name), then searches through it for the appropriate room number. Once that is found, it pulls out the URL and occupant. If there is more than one match for the room number, i.e. there is more than one occupant of a room, then an HTML page is generated with a list of all the occupants, with hyperlinks to each person's home page. If there is only one occupant, then the user is given that occupant's page directly.
If no room is specified, who_is_in notes all the lines and returns a listing of all the occupants in the building, as shown in Figure 12. The perl code for who_is_in is given in Appendix A.
http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451 123,456 321,654From the coordinates of the box bounding the active region, the center point of the room and the radius of a circle containing the room or building can be determined. That information is passed to another script, where_is.gd written by Carlos Pero, which creates a temporary GIF of the relevant image with the appropriate room circled, as in Figure 14.
Note that care must be taken when dealing with temporary GIF files. First, because most browsers cache images, the name must be distinct enough that users are not likely to encounter a second image with the same name before the cache is cleared out. Second, the temporary image must be deleted at some point, but not before the completion of the script. Because most browsers do not download images until the text of a page has been fully downloaded, removing the image too soon will result in the browser not finding the image at all.
If the pixel-to-room data for the requested floor does not exist, or if a room is not specified, the code returns an image of the building circled on the appropriate map, as in Figure 15. Thus authors can link to a room in a building, even if the floorplan information does not yet exist, and give visitors to their pages useful information. When the floorplan becomes available, that hyperlink will switch from showing the building circled to showing the room circled.
In addition to a textual description of the buildings' obstacles, links to the floorplans were used when possible. Thus, the precise location of e.g. elevators could be shown on a floorplan.
All of the course names in the Programs of Study are linked to further information about the course. For example, clicking on GE 221 takes the user to the course description, as seen in Figure 28. In addition to the brief summary of the course's content and hyperlinked prerequisites, there are links to schedule information.
Clicking on Fall '96, for example, gives the user a page with a list of all of the available sections, with the times, locations, and teachers of those sections, as seen in Figure 29. In addition to links back to the course description and to prerequisite classes, the class location and instructor are both linked. Clicking on the instructor pulls information about the instructor from the phonebook (ph) database, formats it nicely, and returns that information to the user. (Note that the ph database software predates my time at UIUC. Its discussion is outside the scope of this document.)
The class location is also linked. Clicking on 101 Transportation Building, for example, would bring the user to a page with the floorplan of the first floor of the Transportation Building, with room 101 circled. (See Figure 14, which differs only in the room that is circled.) This gives a complete entry into the navigational system described above.
The document needed to be broken into many pieces, with appropriate cross-links to other sections. This required human intervention. In a hypertext document, it is meaningless to leave the phrase, "For more information, see the Office of Minority Affairs on page 59." I know of no computer program intelligent enough to translate "page 59" into the appropriate URL, especially when there can be two sections on page 59.
The manual intervention was not necessarily a large enough problem to make it a job not worth doing. By the time that this project was undertaken, campus awareness of the World-Wide Web was high enough that all of the colleges had information available on the web. I felt that it was quite possible that future versions of the Programs of Study would derive from colleges' online information instead of the other way around. I developed this version of the Programs of Study for the colleges to build upon; whether or not this will actually happen might not be known until long after I have graduated.
There was a great deal, fortunately, that could be automated. All courses that were in a regular format (i.e. the department abbreviations and three-digit call number) were automatically hyperlinked to the course description. In addition, room numbers coupled with building names were recognized automatically and linked to be navigational system described above.
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, this does not look like machine-readable text. However, further examination showed that there was actually great regularity in the entries. The first four characters are the three-digit course number and a period. From there to the next period is the course title. Until "Prerequisite:" is the course description, and from "Prerequisite:" to the next period is the prerequisite list. After that is the credit received for successful completion.
The prerequisite list contains names of departments that are fully spelled out, not abbreviated. This meant that I had to create a translation table to generate the course abbreviations (used in the URLs for the class schedule pages, as seen below). Otherwise, it was straightforward to generate the HTML that presented the course description in a fully hypertext fashion.
I then went to the Office of Facilities Planning and Management (OFPM) to attempt to get an electronic version of all of the engineering and math course descriptions. After some resistance on their part towards giving a document with some legal weight to a complete unknown, they relented and gave me a plain-text section of the Courses Catalog for engineering and math courses. I turned those all into hypertext documents.
This turned out to be just a prototype. At the time that I did this, I had no official standing, which made it difficult to get access to good information. Thus, at the request of higher authorities, I turned over my scripts to the Computing and Communications Services Office, to Mike Grady.
As the paper version of the Courses Catalog is only published on a two-year schedule, OFPM did not have any internal mechanism for incremental changes. Working with Mike, they instituted changes in the way they compiled the information so that the online version of the Courses Catalog could be updated more often than once every two years.
Mike also made some changes to the layout of the course description. He found that there were certain combinations of browsers and operating systems that would crash when confronted with very long documents. While the engineering classes could all be printed in one file, the Music Department had so many classes that they could not be listed on one page. An example of the course descriptions as Mike rearranged them is in Figure 28.
----------------------------------------
name: music213 the history of music i
text: fall92
: prerequisite: music 110 or consent of instructor.
: required of all music students.
: 3 hours.
: 05929 lect 1 m w f 2100 music bld
: 05930 quiz a 1 tu th 1180 music bld
: 05931 quiz b 9 tu th 1144 music bld
: 05931 quiz b 9 tu th 1144 music bld
: 05932 quiz c 10 tu th 1148 music bld
: 05933 quiz d 9 w f 1184 music bld
: 05934 quiz e 11 w f 1148 music bld
: 05935 quiz f 4 tu th 1161 music bld
----------------------------------------
I was able to write a script that parsed the record, saving important
fields. The first word after "name:" is the department name and three-digit
course number. The rest of the line is the course title.
From "prerequisite:" to a period is a list of the prerequisites, with
all words that are followed by three digits being the department, and
the three-digit numbers being the associated course numbers.
After the period of the prerequisites, a
carriage return, and a colon is the credit given for the class.
The rest of the lines pertain to the class times and locations, and
are in a table based on column number.
Armed with this information, I could create am HTML document with the same information but formatted more nicely, and with a link to the course description.
At the same time that I turned the Courses Catalog script over to Mike Grady, I gave him the script to parse the Timetable. As he was a full-time, permanent employee of the Computing and Communications Services Office (CCSO), he could access to the up-to-date database maintained by the University's administrative computing department. Mike had to rewrite the scripts to deal with the different input format, but access to the database allowed him to create a new hypertext version every morning. For the first time, students and faculty had access to current information instead of a snapshot of the information as it stood on the day the Timetable went to press. One area that had been particularly wanting was the instructor. Most teaching assignments were made after the Timetable went to press, so never made it into print. Now the teaching assignments are reflected almost immediately in the on-line version.
In addition, enough information is in the database that Mike was able to link the instructor to his or her ph entry. And, when I finished the maps and floorplans segment of the navigational system, I suggested to Mike how the Timetable could link to the navigational system. An example of the final version of the on-line Timetable is in Figure 29.
The campus has the honor of having the second system to circle buildings on a map (after SUNY-Buffalo), the first to circle rooms on floorplans, the first to integrate floorplans and maps, the second to have a "virtual tour" (after Honolulu Community College), and the first to integrate maps/floorplans with a virtual tour.
The navigational system has been deemed useful enough that the Office of Facilities Planning and Maintenance has committed to furthering its development.
The navigation system was featured on Yahoo's What's Cool page, resulting in a large amount of virtual visitors to the campus.
The wheelchair access information, coupled with the maps, proved useful enough for the project to be recognized by the Disabled Student Organization with the Harold Scharper Service Award. Furthermore, DSO has committed to furthering its development.
The campus has the honor of having the second cross-linked courses catalog and timetable (after St. Olaf's College), being the first to integrate courses catalog, timetable, and graduation requirements, and being the first to integrate the timetable with floorplans.
The first version of the hypertext courses catalog and timetable was so appealing that the Communication and Computing Services Office specifically requested responsibility for it.
The Web version of the Timetable has been so successful and popular that the ph database is no longer maintained.
A paper on this project was accepted and presented at the 1994 Fall International World-Wide Web Conference. [1]
A chapter was devoted to this project in a best-selling computer book [2].
When file uploading capabilities are built into browsers, a mechanism for departments to be able to maintain their own information about room occupancy would be prudent. The Computing and Communications Services Office is currently investigating such a system.
The Programs of Study is updated every two years. Doing a wholesale translation from the paper version to a hypertext version can be hazardous to the health. It is hoped, both by the project author and by representatives of the Office of Publications, that at some point in the future, the paper version (if one continues to exist) will be derived from on-line information published by the appropriate functional units instead of vice-versa. It is doubtful that this will happen before the next version of the Programs of Study is published, but the opinion is that the version after that will originate on-line. The Office of Publications would be the natural organization to lead and coordinate such an effort.
Similar growth in the campus as a whole has been clear. An effort was made by Graham Lawlor in the summer of 1995 to quantify the size of the campus-wide web. The web's success unfortunately meant that he was unsuccessful. His tools broke after indexing 40,000 documents from 276 different servers. This is a far cry from the hundreds documents and tens of servers in existance on the UIUC campus at the beginning of the project.
As early examples of the capabilities of the World-Wide Web, the systems described in this project served to promote and publicize the use of the Web on campus. As innovative uses of Web technology, they provide publicity for the University. Most importantly, the information herein is useful in people's day-to-day life, as seen by the high number of accesses.
What is most valuable to me, however, is something that I happened to notice while walking across campus. I saw someone in a wheelchair stopped, examining a printout of Altgeld Hall with a room circled. On her lap was a printout of the map of the Quad. The accesses are nice, the awards are nice, but that student was the true verification for me that what I had done was being used as intended.
[2] Kaitlin Duck Sherwood, The University of Illinois College of Engineering Web, Proceedings of the Second International WWW Conference, October, 1994.