4.2.2.1 Ease of Creation and Interaction for Linking
In courseware projects where "linking" functions were used, navigation issues
were an important aspect of "usability" from both the user and authors perspective.
For the ESCAPE courseware project, the absence of powerful contextualization
tools in HyperCard, such as graphical browsers, necessitated extensive work
on interface design. Early in the project, consistent interaction for
learners was achieved with a navigation system relied heavily upon HyperCard's
scripting ability within buttons. The basic solution was constraining HyperCard's
ability to support infinite "GOTO" with a structure that narrowed the possiblities
to a simple tree structure where "GOTO" was used to descend the tree, and "RETURN"
structures were used to reascend the structure. While the simplicity of this
structure was part of its power, the greater part of its utility was the consistency
it provided for users. After they used the system for a while, they knew where
to expect to click to descend the tree (bold faced menu items), and where to click
to reascend the tree (a single button at the bottom of the screen labeled with the
name of the menu it would return to). While this structure was effective from the
point of view of the learner, it was extremely inefficient for the author.
Each individual menu button was individually scripted, because the early version
of HyperCard in use at that time did not support "hot text". Systematic additions
or modifications to the system were not possible, because impractical amounts of
effort and the time were required to implement changes on an item by item basis.
The issues above emerged as a problem due to the size of the database. If the
database had been small, the amount of effort required to change it would have
been insignificant. But the database contained thousands of separate cards so
scale up was an issue for its author.
Scale up also emerged as a critical factor in the degree to which navigation
issues in hypertext were recognized as a problem for learners during courseware
projects. In a publication reviewing his experiences with Intermedia,
Landow points out that there are issues of "scale up" to be considered when
dealing with linked bodies of text and graphics. He refers to the creation of
very large bodies of materials as "metatexts", and suggest that there are issues
associated with their "usability" that do not appear unless one encounters large
enough bodies of material:
To determine if the education potential claimed for hypertext can ever
be realized, one must work with large enough hypermedia metatexts. One frequently
encounters the notion that the nature and effect of hypertext can be studied with
small document sets despite the fact that in any university level course students
encounter the equivalent of thousands of documents per set. Many problems
concerning both system design and principles of author-generated rhetoric do not
appear until the hypermedia corpus (or metatext) reaches a particular size.
For example, although I conceived of using intellectual mapping to create
overview documents before Intermedia was designed and implemented, I did not
encounter the need to formulate working rules about number and variety of
materials linked to each block within an overview until several iterations
of the course produced substantially more documents than had originally linked
to these directory documents.
(Landow, 1990, p. 47)
Landow's experience and input had a substantial effect on the redesign of
Intermedia which took place between version 1.0 and 3.0. The web view was
completely redesigned: the local map was changed from a star to a tree diagram
and a path recording the documents viewed by each user was added
(Utting & Yankelovich, 1989). Yankelovich
(personal interview, March 6, 1992), one of the lead designers of Intermedia,
explained the way in which the problems of scale-up Landow encountered impacted
the redesign of the system:
Yankelovich: There were some things that we developed for the students
and professors who were using Intermedia, based upon what was really missing for them.
For example, we spent a lot more time than we ever anticipated working on the web view.
That was just a problem that people had using the system. They had navigation problems,
and we felt that was an area we needed to focus on.
Hopper: Do you believe you solved the problem?
Yankelovich: Definitely, yes. I think we spent more cycles on that one design
problem than probably any other piece of the system.
The issue of scale up and its impact on usability was a critical issue that the
Intermedia design team successfully conquered. Educational literature has been
strongly influenced by these and similar reports, and so the issues of "navigation
in hyper-space" have became fairly well known. To many this seems to remain an
unresolved issue, but at Intermedia, one of the most well known projects that
dealt with the issue, it is clearly no longer unresolved. In the following passage,
Landow elaborates not only about the fact the Intermedia team did develop a
satisfactory set of solutions and exactly what those solutions were:
Many authors who take the position that navigation remains an
unresolved problem follow that assertion by suggesting two solutions,
global maps and artificial intelligence. The first, however, does not
work as a navigation tool with any but the smallest hypermedia corpora,
and the second does not exist at the moment in any usable form.
My experience with Intermedia suggests that navigation and orientation
are not in fact a major problem: Using system features, the reader can
locate something or travel to it by means of full text searches, folders,
links, web views, and menus of link choices from a particular marker.
One always knows that documents "surround" the document one is reading,
and one can always travel to an overview document, which in most cases
gets one off in the direction one wishes to head.
(Landow, 1990, p. 48)
This approach to the construction of Intermedia is further explained by Meyrowitz,
one of its key designers:
Intermedia is distinct from many other hypermedia systems in that
it is intended to model a multi-user hypermedia framework rather than a single
hypermedia program. We did not want to create an isolated hypermedia "island"
where linking functionality was limited to connections between homogeneous data
managed by a single program. Our intention was to create a model for how hypermedia
functionality should be handled at the system level, where linking would be available
for all participating applications in much the same way that copying to and pasting
from the clipboard facility is supported in the Macintosh and Microsoft
Windows environments. (Meyrowitz, 1991, p. 290)