Chapter 32 -- A Campus-Wide Information System
Chapter 32
A Campus-Wide Information System
CONTENTS
Course Information
Navigational Aids
A Virtual Walkthrough
Unsolved Problems
Campus-Wide Information System Check
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.
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.
Navigational
Aids
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.
Finding the Data
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.
Adjusting and Translating the Images
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.
Tidying Up
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.
Walking Through the Building
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.
Correcting 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.
Making Imagemaps
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:
The graphical information is separated from the occupancy
information.
People think in terms of room numbers, not in pixels. It is
easier to move Bob Jones from Room 401 to 203 than to move him
from 62,147 92,473 on the fourth floor to 701,462 197,26 on the
second floor.
Multiple occupants can be handled. The script returns a page
asking you to select between the different occupants.
A listing of all the occupants in a building is easy to create
(and is what who_is_in returns
if the room isn't specified).
The coordinates for a room are easy to pick out of the imagemap.
(Coordinates are discussed later in this chapter.)
The information that changes frequently (occupancy) is separated
from the information that rarely changes (location of walls).
Note
The code for who_is_in and its related programs are available at http://www.uiuc.edu/navigation/tools/.
Entering Occupancy Data
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?"
where_is
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).
Figure 32.1: Circling a room.
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.
A
Virtual Walkthrough
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:
I started out by taking pictures in all four compass directions
(north, south, east, and west) at every street intersection block.
This turned out to be too far apart; there wasn't a good sense
of continuity. Taking pictures every half-block worked much better.
I liked to take pictures from the center of the road. However,
one road had a median with light poles down the center-hardly
a good view. Because I was dodging cars and in a hurry, I took
all my pictures from whichever lane was open at that moment. Unfortunately,
when all the pictures were stitched together, the effect was that
of weaving all over the road. First the viewer would be in the
right lane, then the left, and then the right. It was terribly
disconcerting.
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.
At intersections, I started by shooting away from the intersection.
For north-facing pictures, for example, I stood in the northern
crosswalk and shot facing north. I found that without the visual
cue of the opposite curb, however, it was difficult for the viewers
to recognize that they were at a street, where turning would allow
another long run of Go Forward.
I now shoot all intersection pictures into the intersection.
For example, I stand in the south crosswalk to shoot north.
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!
Unsolved
Problems
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.
Speed versus Beauty
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.
Terse versus Verbose
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.
More Shorter Pages versus Fewer Longer Pages
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.
Netscapisms versus Standard
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.
Official versus Unofficial
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.
Campus-Wide
Information System Check
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.
When setting up a site for people who are not always connected
to the Net, try to make your web information as comprehensive
and cross-linked as possible.
As much as possible, leverage your efforts by translating
existing documents into HTML instead of starting from scratch.
Give your translators enough intelligence to automatically cross-link
to relevant documents.
Bear in mind that other people will incorporate links to your
documents from theirs, possibly with automatic translators. Make
the URLs as simple and consistent as possible for others.
If you set up a mapping system, putting one level of indirection
into the imagemaps simplifies the development enormously.
Provide adequate visual context for photos and a consistent
orientation for maps and floor plans.
People asked me why I bothered
to put in the latitude and longitude. For a long time, I had to
answer, "I don't know, but if the information isn't there,
nobody will ever use it. If the information is there, someone
might find a novel use for it." There now are tentative plans
to use that information at registration to estimate how long it
takes to get from one classroom to another.
Wyszukiwarka
Podobne podstrony:
CH32 (5)ch32ch32ch32ch32CH32ch32ch32ch32ch32ch32 (3)więcej podobnych podstron