You asked for it, you got it.   
The information superhighway as manifested in VRML.


By:
Matthew F. Ringel			ringel@pipeline.com
Adam R. Fields				arf11@columbia.edu

Written for:
CS6998-41 Advanced Scripting Languages
Professor Aho
December 6th, 1995


Objective
This project has three goals:

1. Implement a specific area of the "Information Superhighway", as
outlined in popular media, using VRML. In this case the area we will
model is the Computer Science Department Web Page at Columbia
University.

2. Analysis of the "Information Superhighway" metaphor, as implemented
in the "Virtual Reality Modeling Language" (VRML) as defined in the
version 1.0 specification. Specifically, we will examine the
usefulness of the "IS" metaphor in general, using VRML as the
visualization medium.

3. Analysis of VRML, using the "IS" as a testbench. It is our belief
that modeling a small part of the "IS" will use enough features of
VRML, as well as being a large enough project, that we will be able to
determine VRML's usefulness as a language/data format for a project
for which it would be uniquely suited in the future.

The reason for having three interrelated goals, as opposed to one
goal, is because of the nature of the language.  Since VRML is not a
general-purpose programming language, but rather a modeling language,
with very specific design restrictions, there are not many avenues for
one to be creative and put things together in a way that would emulate
something more advanced.  For example, interactivity is not built in
to the VRML 1.0 specification. One can not really "kludge" something
together in the language in order to make the functionality exist.
However, the C++ programming language can be emulated using (and often
is translated into) the C programming language, by doing some
particularly tedious pointer arithmetic.

During the initial planning of this project, it was apparent that it
would be interesting to try to implement a small part of the "IS",
while understanding the necessary limitations of the language. Not
only would this give us a better feel for the language as a whole, but
it would also give us a handle on the "IS" metaphor and its
suitability for the representation of the Internet as a whole.  In
addition, by doing something that would exercise a major subset of
VRML's capabilities, it would be easier to spot the strengths and
weaknesses that would not be immediately obvious.

Project Specification

The specification of the project itself is very simple: Using VRML,
translate the Columbia University Computer Science Dept. web page into
the "IS" metaphor.  As stated before, since VRML is a modeling
language, one can't "do" anything with the language.  It is a
specification language. Therefore it seemed reasonable to specify
something that was interesting from a modeling standpoint, as well as
a social standpoint.  In addition, since we are both familiar with the
U.S. Highway System, there exists an intuitive understanding of how to
implement a "IS" VRML scene that "looks right".

The Information Superhighway Metaphor

The "IS" is a concept that was initially used by Bill Clinton and Al
Gore to define a National Information Infrastructure in a way that
would be easily grasped by the citizens of the Unites States of
America.  This "S" had on-ramp, off-ramps, and various other vaguely
defined highway-like objects.  Over time, however, the vision of an
"IS" moved from the political soapbox into the mainstream, with
various representatives from the mass media and technical worlds
actually trying to find parity between the present state of the
Internet, and the metaphor of some type of roadway.

Neither of us believe that, at the time of this writing, anyone has
actually tried to build a concrete or virtual visualization of the
"IS".  Therefore, having very little to work with besides various
political speeches, and several content-poor articles in trade
magazines, we came up with a set of metaphors that we believed would
maintain some kind of correspondence between an actual U.S.A. highway,
and a reasonable conception of the Internet, as well as providing the
functionality that the original model (the Comp. Sci. Dept. Web page)
provides.

The shoehorn effect

While specifying the project, we acknowledged that the "IS" is not a
truly useful metaphor for the Internet, and that using VRML to
implement such a vision would be a "best effort" attempt on two
fronts:

1. To implement something resembling a highway using a modeling
language that is only vaguely suited to the project, with tools that
are still in beta testing, and with rendering hardware that was only
barely adequate.

2. To model the CS Dept. web page using a metaphor which we believed
to be a less-than-perfect fit. We will go into further detail as to
the exact reasons for the unsuitability of the "IS" metaphor later in
this paper.

Quality Plan

The user-centered criteria used in the continuous examination of this
project had an accent on functionality and usability, mainly because,
in VRML, reliability and performance are largely beyond the control of
the authors.  If the VRML is valid and adheres to the specification, a
browser that adheres to the same specification should parse it
"cleanly" every time it loads. Hence, reliability is something that is
absolute (and slightly irrelevant) in a modeling language such as
VRML.  There is a small number of performance issues that are the
responsibility of the authors (e.g. using the minimum number of
polygons, using texture maps only when necessary, etc.), but most
performance issues are directly related to the hardware and browser
software that the end-user will be using.  As of this writing, good
specialized 3D rendering hardware is still relatively expensive,
although there is some price-cutting competition expected within the
next few months.

The functionality requirement was evaluated by answering the following
question: "Is the current implementation intuitive to someone who is
unfamiliar with the Internet?"  It is assumed that the audience that
would use a metaphor such as the "IS" would be people who were novices
to the Internet, and did not want to grasp the concepts of the
physical structure of the Internet.  However, as with any user
interface, it was necessary to compare its ease of use with
alternative ways of accessing the same information.  The tradeoff is
speed for ease of understanding, as opposed to ease of use.

The usability requirement was evaluated by answering the following
question: "Does the ease of understanding of the "IS" metaphor
adequately compensate for the slower access time inherent in the
access methods for the interface?"  Although the concept of an "IS" is
easy to grasp, the topology of a conventional highway is not obviously
mappable to the topology of the Internet.  In general, on a highway,
there exists a very specific concept of routing. That is, you have a
single main backbone that is the highway, and several exits off the
highway, each going to either a specific destination or off to feeder
roads (or possibly, other highways). In general the concept is "You go
one way, and everyone else continues on the road".  This forces one to
impose a hierarchy and routing on the topology of the Internet that
isn't a very tight fit, so to speak.  It is true that one does not
lack for hierarchies when visualizing the Internet, but there is none
that is universally useful, which the "IS" metaphor would
necessitate. There also is the primary problem of travel time.  Within
the current spec, it takes time to get from point A to point B.  Using
a conventional World Wide Web browser, the amount of preparation for
setting up a connection between a local host and an overseas host are
roughly equal.  That is not so when one has to travel somewhere, and
using "teleport" systems violates the metaphor. The highway concept of
routing (which will be covered later) will slow down a user's access
to specific information, and it is not immediately obvious whether
that compensates for ease-of-use.

Requirements

At the time of this writing, the capability exists to download images
through a modem at the rate of approximately 3 Kilobytes/sec. In
addition, computer hardware that can render 3D scenes quickly, as well
as being able to move large amounts of 3D graphics around the screen,
is just becoming affordable to a large portion of the population,
although there is reason to believe that it will be another year or
two before such hardware is widely affordable and adopted.  In
deference to this problem, the load time for any particular scene must
be low, and the amount of rendering time spent must be tolerable for
moving through a scene.  The exact definitions of "low" and
"tolerable" are beyond the scope of the paper. The heuristic that was
used during the construction of this project was whether the scene
took more than 2 minutes to render initially. Even allowing for
hardware struggling to keep up with the load, any more than a 2 minute
wait will result in a very bored user.  The heuristic used for
movement was a rate of 2-3 frames per second, for the same reasons as
the rendering heuristic.

Look and Feel

One primary requirement of this project is reasonable support for the
illusion of driving down a highway.  Given the present state of the
VRML 1.0 specification, as well as the present capabilities of
available hardware, fulfilling this requirement was impossible.  The
attention of the project was turned towards making a reasonable
illusion of a highway, which would be used by a (very) understanding
user.  This project was used to test a hypothesis, as opposed to
creating an end-user application.  However, with the exception of two
major weaknesses of VRML in its current state, powerful hardware (that
exists and is available to wealthy individuals or institutions) would
have enough processing power to make the illusion of driving along
such a VRML-generated highway at least reasonably useful to a more
demanding end-user.

Architecture and Design

Before going into a discussion of the design of the project, it's
necessary to define some of the fundamental differences between a
markup/modeling language like VRML and general-purpose programming
languages such as C, C++, or PASCAL.

Written Languages

General-purpose languages, such as C, C++, and PASCAL are used in any
number of situations, where versatility of the language is necessary,
and the authors of the language had no specific purpose in mind for
the language when it was written, with the possible exception of
teaching how to use a general-purpose language.  In addition, there is
usually more than one "right" way to accomplish a specific
programmatic goal.  There is usually a set of "idioms", or generally
accepted ways of dealing with specific programmatic problems.  In
general, however, most of what is written is written by humans, or at
least with a great deal of human intervention.

Generated Languages

There is a set of languages, some of which might be full-fledged
modeling/programming languages, which straddle the line between
programming/modeling language and data format.  Good examples are
PostScript (PS), and Adobe's Portable Document Format (PDF) . It is
entirely possible to actually write programs in these languages, but
their purpose is usually highly optimized for some domain of
problems. In the case of PS and PDF, it is the problem of how to
describe a page of output to a printer, either physical or
virtual. Another trait that is typical of these languages is that
there usually is just one correct way to represent a specific object,
whatever it may be.  Since there is a set of "right ways" to represent
objects, it seems reasonable to automate a great deal of the process,
add a layer of abstraction, and make it easier for a user to generate
code in the language.  In this class of languages, most of the code
written is actually ejected by tools, instead of being directly
written by humans.  VRML falls perfectly into this class of
programming/modeling languages.

Why VRML is a "generated" language

We initially planned to use the 3D Studio program, by Autodesk, to do
most of the large-scale design, and use a filter to translate those
files to VRML. However, as detailed later, we ran into problems and
ended up using our filter - Fountain - for the actual creation of the
pages. Additionally, after each file was saved in VRML format, we went
back through the generated VRML code, and altered things manually as
was necessary.  One of the main reasons for VRML's being a "generated"
language is that while some things are easier to do by hand (for
example, editing URL's), it is a very tedious and error-prone process
to calculate the points for various polygons and other shapes,
especially when the shapes get more complex and go beyond 3-4 faces.
There is very little that can be done that is interesting without
resorting to a kind of tool for the calculation of the points and
structuring the VRML correctly.  Using a good tool for VRML generation
also eliminates the worry of writing conformant VRML, so that one can
worry about the design.  In addition, a casual (and very unscientific)
perusal of various VRML sites on the Internet showed that a great deal
of them were generated using 3D studio or other similar programs.

Overall design

Since most of the code for the project was generated using graphical
design tools, code architecture is irrelevant within the scope of this
paper.  Most of the time was spent in figuring out what shape the
actual highway was going to take. In deciding the eventual shape of
the highway, there were a couple of schemes that were even slightly
feasible. These were:

1. The Domain Name System (using a geographical hierarchy)
2. Topical (Using an information hierarchy)

We ended up using choice 2, mainly because we were only recreating the
Computer Science Department Web Page, and thus got a catalog of
topics, and a content hierarchy, ready-made with little additional
work.  There were also compelling reasons not to use choice 1.  The
primary reason was because it didn't seem reasonable within the
context of an information navigator, such as the prototype that was
designed for this project.  This is also one of the reasons that the
"IS" metaphor falls apart.  The concept of a highway includes the
assumption that the user is "going someplace" (i.e. changing
geographical locations).  However, when a user is navigating an
information space, the actual geographical locations of the
repositories of that information are of very limited utility at best,
and extraneous and confusing at worst.  Navigating an information
space, like the World Wide Web, requires either a mental picture of
what interesting web sites exist, or some kind of search engine.  A
highway that's carrying people through different kinds of information
is a mixed metaphor, and one that, as we found out, does not lend
itself readily to the large interrelated information space that
currently exists.

Testing Plan

Because VRML is a markup/modeling language, and not a general-purpose
programming language, testing procedures were considerably different
than they would have been for, say, a C program.  In addition, because
the majority of the VRML was generated by tools, as opposed to written
by hand, the qualifications for passing "quality control" are also
different.  For example, if we know that a tool is generating
compliant, error-free VRML, then we can almost assume that the tool we
are using is a "black box", and not worry about the code at all.  That
doesn't imply that one can be completely ignorant of the code that is
generated by such a tool, however. If modifications are to be made (as
we had both done on a few occasions) one must be able to understand
the coding style of the tool, and be able to add or remove lines as
necessary.  When all is said and done, though, the primary (and most
meaningful) test of VRML code, programmatically generated or not, is
"does the browser like it?"  Similarly, the actual testing of the
program primarily relies on whether the browser believes that the VRML
code is compliant.  Unlike most general-purpose programming languages,
a markup/modeling language depends primarily on the functionality of
the viewer that's being used to display the code. In our testing
procedures, we noted that there were numerous incompatibilities
between browsers.  Browser incompatibilities are nothing new to the
Internet community (the proliferation of pages saying "Netscape 1.1
enhanced" not so long ago), and that will the situation with VRML for
a while, as well.

Testing is especially subjective; however, the primary questions to
ask at a user level do not change, though.  Much like in applications
user testing, the questions are:

1) Is the user satisfied?
2) Does it appear to solve the problem?
2a) Is it useful in its present form?
3) Is the tool intuitive to use?

The "problem", so to speak, is that of Internet navigation. Does the
highway metaphor make it any easier to understand how to navigate the
massive information space embodied by the Internet? In addition, since
VRML is being updated to version 1.1 even as we speak, it is necessary
to continually ask if the language has enough new functionality to
properly support what we're trying to do.

Implementation Considerations & Details

There were several problems that we had to deal with, when actually
sitting down to craft the VRML pages for the project, and the final
product reflects our overall inability to overcome these problems. One
limitation that contributed to this inability was our self-imposed
restriction of only using software that was a) freely available and b)
written for some strain of Microsoft Windows. We imposed this
restriction in an attempt to try to evaluate VRML as a tool for the
everyday end-user, who does not normally have access to SGI
workstations. The main problems we encountered were:

1. Incompatibilities
2. Beta versions
3. Hardware limitations

Incompatibilities

As noted earlier, we originally began construction of our highway
pages in AutoDesk 3dStudio, with plans to convert the drawings created
to VRML using Caligari Fountain .91b, a beta version
Internet-available VRML authoring tool. We continued along this path
for a while, until it became painfully apparent that the drawings we'd
made in 3dStudio would not be convertible to VRML format without
several hundred dollars of additional software, and even then, much
more editing would be required to get the pages to look the way they
did in 3dStudio. After much lamentation, we switched to using Fountain
as the primary authoring tool (rather than as a converter), and
started again. Using Fountain was rife with problems. The interface is
extremely slow (barely usable on a 486DX/50 with 32 megs RAM) compared
to 3dStudio, it crashed frequently, sometimes bringing the entire
system down and trashing various files, and the files it exports to
VRML don't seem to be compatible with any other VRML browser (WebSpace
running under Windows NT, a relatively stable platform, was brought to
a screeching halt when faced with these VRML files). However, the
files do load correctly when using Fountain itself as a browser, even
when accessed remotely via URL's instead of loading them directly from
the hard drive.

Beta Versions

Fountain is currently in beta version, which made it difficult to
use. This alone increased the time it took to create pages at least
fivefold. Many functions are either poorly documented or well
documented but not implemented. One particular feature that was
missing was the ability to list all of the objects in the space and
their properties. It was documented in the help file, but the icon to
bring up the list didn't ever seem to appear. The lack of this ability
wasted a lot of time in page creation as we struggled to figure out
which objects were where. It was particularly frustrating when objects
were behind other objects, which is why our final pages are somewhat
flatter than we would have liked. Fountain's handling of texture maps
is limited at best, so they were left out. However, most of the VRML
pages we browsed in doing research for the project did not seem to
incorporate texture maps, probably because of bandwidth/processing
time considerations. Several aspects of the specification were
compromised in the final output, due to these restrictions. To keep
the polygon representation simple, objects that were originally going
to be complex polygons were implemented as primitives from the
Fountain primitives set. Billboards, to represent HTML links, were
replaced by cubes. Files to download are represented by
tori. Important links (in our case, the disclaimer link from the CS
main page) are shown as cones. Texture mapping on the road itself
(lane markers) was left out.

Hardware Limitations

As previously mentioned, in order to simulate a real end-user
experience, we limited ourselves to PC's running Microsoft Windows of
some flavor or another. This is not the ideal platform for rendering
space descriptions, though it is often all that is available. In
actuality, the hardware limitations that we had to deal with were not
as troublesome as the software itself. The main problem here is that,
due to network speed restrictions (because the entire world isn't
hooked up with fiber-optic or even coaxial cable), VRML file sizes
have to be small, in keeping with the "a bored user is a user of
another product" guideline. The largest VRML file we saw while
browsing was roughly 460k, and it was self-described as "really big!"
Our files, minimal as we tried to keep them, still ended up being in
the range of 140-160k. Incorporating the kinds of embellishments we
initially planned to have (texture mapping, large worlds, many
structures with a lot of text, etc...) seems infeasible at this time.

Evaluation & Conclusion

In attempting to model the Internet as the Information Superhighway
using VRML, we have come to the conclusion that is cannot be done for
widespread use, with current technology. Part of the blame lies with
the fact that not everyone has a high-end workstation with a T3
connection, and part lies with failures in VRML itself. This is not to
say that VRML is not an exceptionally good start, but it is still
lacking many of the features that would make it a good language for
interactive space modeling and information retrieval. Our testing
process, which began even before the we started coding the project,
yielded the following observations:

Major Weaknesses

1. Non-interactivity: The current version of VRML doesn't allow for
any interactivity. A user can bring a space definition up on the
screen and move around in it, but cannot manipulate any of the
objects. The biggest problem with this non-interactivity is that all
objects in the space are composed of faces, rather than being
solid. If the user were prohibited from entering "solid" objects,
navigating the space would feel much more "real".

2. Free navigation: Corollary to the previous point. Navigation in
VRML is completely free. Not only can users go inside supposedly solid
objects, but they can move anywhere. The ability to constrain user
motion to a path or set of paths would allow for better implementation
of metaphors such as the IS (this is really the biggest weakness of
VRML in terms of the IS metaphor), and would help prevent the user
from getting "lost".

3. No objects relative to the user: VRML proposes to be a user-based
format, yet there are no provisions for locking objects to the user's
viewpoint. WebSpace does have its navigation console, but this
property should be built into the language and not dependent on the
browser. It should also be customizable for each page, or possibly for
each user (there is the possibility of user-defined objects that are
always present, providing an interactive hotlist of sorts). This would
facilitate navigation, as well as allowing the user to interact with
the page. An example of a good use of this feature would be a mini-map
of the whole page (from some chosen viewpoint) with jump points that
the user could click on to instantly go anywhere in the space.

4. Poor interface: This is more a problem with the current browsers
than it is a problem with the language itself. Using a two-dimensional
mouse to navigate a three-dimenisional space is clumsy at best, and
even worse when the update is not fast enough to allow real
interactive movement. As an alternate interface, we suggest using the
6-key block (consisting of Insert, Delete, Home, End, PageUp, and
PageDown) on 101 (or more) key keyboards for linear navigation
(mapping the six keys to X-Forward, X-Back, Y-Forward, Y-Back,
Z-Forward, and Z-Back, respectively), the arrow keys for up/down and
side-to-side rotation, some other two-key combination (perhaps
PrintScreen and Scroll Lock - no one really uses those anyway) for
z-rotation, and the number keys to control the speed of movement. This
alternate interface would allow fairly easy and precise movement in a
particular direction, without the added expense of a six-degree
spaceball.

Major Strengths

1. Tool-friendly: With the caveat of browser differences, VRML
naturally lends itself to being generated by interactive authoring
tools.

2. Good start: VRML as it is is very limited, but it's a promising
version 1.0. As noted in the previous section, the problems with VRML
— and the solutions to those problems — are very well
defined. In some ways, VRML, like most graphics applications, is ahead
of its time in that the hardware has not yet caught up to what is
possible in software.

As mentioned in the specification for VRML, its intent is to create a
user-based visual interpretation of the Internet. If the modifications
we mentioned in the weaknesses section, or similar modifications, are
implemented in the next version, VRML could very well succeed at its
stated goal. The Information Superhighway is still a poor model for
the Internet, but with increased interactivity and better navigational
controls, VRML could very well be the language that presents the
"better alternative model" that President Clinton and Vice-President
Gore were looking for when they coined the concept. Hardware will get
faster and cheaper, software will work out the bugs, interfaces will
continue to streamline. And when they all finally come together,
Cyberspace, the Matrix, the Metaverse, the Net, and VRML will be
waiting.