Development of the University of Illinois Web

Navigation System Implementation

The navigation system, with its maps, floorplans, wheelchair access information, and virtual tour, required a substantial amount of code development, image translation, and information gathering. This section explains how the major subsystems of the navigational aids were implemented, broken out by subsystem.

Maps and Floorplans

The most complicated subsystem was definitely the maps and floorplans segment. Not only did maps and floorplans need to be found, but some translation had to be done to make them useful. Code then had to be developed to do inward and outward zooming, and occupancy data ferreted out.

Acquisition of Information

The length of time it took to find the source of floorplans was perhaps indicative of how inaccessible good navigational information is. It took four months of casual but steady investigation to find a set of floorplans at the Operations and Maintenance ftp site.

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.

Image Translation

Some manipulation was required for the maps, which were all originally in black and white. The buildings that had lobbies were colored blue, and the regions that had area maps were given blue boundaries on the all-campus map. Touchups were done on all the area maps, with labeling or relabeling of most buildings, coloring streets and sidewalks grey, and coloring grassy areas green. Various paint programs, such as xpaint and Photoshop were used for the map manipulations.

It was necessary to do quite a bit more translation to obtain useful floorplans.

The original drawings were in AutoCAD format, which is not recognized by any browsers. They had to be converted to GIF format.
The original drawings frequently did not have north facing the top of the page. Because the floorplans were tightly integrated with maps that show north facing up, leaving the floorplans at an arbitrary orientation would have been confusing.
The room numbers were invariably too small to be legible when the floorplan was a size that was reasonable for a browser to display.
The AutoCAD drawings were red on a black background. This looks good on a computer monitor, but does not print well.

AutoCAD was used to remove the drawing layer corresponding to the room numbers, resize, and rotate the drawing. The shareware program xpaint by David Koblas was used to put larger room numbers on the drawings. The color manipulation facilities of the shareware program xv by John Bradley were used to convert the image format and to change the colors of the drawing.

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.

Programming Implementation

The maps/floorplans system is glued together by two perl scripts: who_is_in and where_is. The former script takes the user to the home page(s) of the occupant(s) of the room or building requested. The latter script creates an HTML page and GIF-format image that show the user the location of the room or building requested. In other words, where_is is for zooming out; who_is_in is for zooming in to rooms.

who_is_in

There is a standard way of making "clickable maps" on the Web: images, that when clicked on in different coordinates, will take you to different pages. This "ismap" format is

URL	x1,y1	x2,y2

where 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,654

the file instead includes lines like

http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451	123,456	321,654

A 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.

where_is

The where_is script creates a page by looking in the ismap file for the coordinates of the room. This can be determined by doing a text search for the building and room, e.g. grainger&room=451, which would find the following line.

http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451	123,456	321,654

From 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.

Wheelchair Access Information

As an inspection of the buildings was done to check the floorplans for accuracy and to note locations of important rooms, it was a simple matter to also note the locations of wheelchair bathrooms, elevators, chairlifts, ramps, and automatic doors. This information was used to develop access information pages (see Figure 26). Additional information was gleaned from interviews with students with mobility restrictions.

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.

Virtual Tour

A digital camera was used to take the photos for the virtual tour because of the speed of acquisition and low cost. Photographs were taken in all four compass directions at half-block intervals. Because the University of Illinois is located on topographically uninteresting terrain, the streets are in a near-perfect grid. By imparting some information about the order of the streets to a script, the locations of buildings, and the relationship of forward, left, right, backwards, north, south, east, and west to each other, it was relatively straightforward to write code that generated hypertext to frame the photos.

Go on to Registration Information
Go back to Navigation System Features

Go up to Table of Contents

Kaitlin Duck Sherwood