4.3.3.5 Adaptability for Networks
There are many issues involved in the future of courseware containing large
linked databases of content, multimedia, and microworlds accessible over networks.
One of the most important, and least discussed in general educational literature,
is the importance of particular standards, and their role in how to achieve
interoperability across different systems on a network. This is currently
the focus of much attention in computing circles, and there has been enough
progress to allow a large number of inter-platform communication and transfers
to work successfully. Tillotson (personal interview, June 23, 1992),
the key programmer in the portability effort in the ESCAPE project also
highlighted the importance of extensibility in authoring tools will play
in the project's further efforts to pursue the vision of "true hypermedia"
by also implementing more than just text and graphics in a system that
would be implemented on "wide area networks" like the Internet.
Tillotson: The ability to link to things outside the system
is also absolutely necessary. Even in a complex structure such as that
found on the Mac, it is important to have a way to link to applications
that aren't part of that structure. In any structure there will be some
things which are not possible, so there must be an easy way to add to the
structure later.
Hopper: In other words, having a way to use programs that may do something
that isn't even created yet? So you should at least have the capability of
opening something that didn't exist in the past.
Tillotson: Exactly. This is especially useful if you can run your existing
conventional applications even though they aren't part of the structure.
If your system can access conventional applications or languages, a programmer
who is not familiar with your structures will still be able to produce something
that interfaces with it.
Hopper: Eventually, would extensibility be important for a system that
could be used on the internet. How far away are we from that type of situation?
Tillotson: It's possible now. In our project, the HyperNews client I wrote
was independent of the format of the databases, because it dealt only with a
program I wrote to access the databases. I could have easily replaced that
with a program that obtained data from WAIS or Gopher, or by some other means.
If you already have a large database and a programmer who can write a program
to access it, or if you are using a commercial product with an interface library,
you can link it with your interface, provided your interface is properly extensible.
That is the essence of extensibility. For example, if someone were to write a
HyperCard XCMD that worked exactly like the database interface to HyperNews
does now, HyperCard could access the same database HyperNews can. If some
aspect of the database changed, both the XCMD and the HyperNews database client
would require changes, but your programs in HyperCard and HyperNews would remain
unaffected. Once you have separated the functions of user interface and
database access, you have set up a barrier between the developer of the user
interface and the programmer writing the database access library.
As long as the interface between the two remains the same, you need not
care where the data comes from. It could come from disk, through WAIS,
from some other source - it doesn't matter, since the interface is the same.
I think that any system that can't interact with outside programs,
at least on the same host, is too limited and has no future. (Tillotson & Hopper, 1992)
The importance of extensibility for adaptability are supported by experiences at Brown.
Intermedia began by emphasizing educational goals like collaboration, while also
incorporating the issues of usability. But in the end, despite Intermedia's
profound educational perspective, it was ultimately limited because of its lack
of technical adaptability including extensibility. While Intermedia's approach
resulted in the expected increases in usability, its lack of adaptability played
a role in its ultimate unusability.
We also assumed that the authors of educational materials would want to
concentrate entirely on content and not want to be concerned with "programming"
in any sense. This led to the creation of a set of authoring tools that are
easy to use for authors already familiar with a text editor, a graphics editor,
and the copy-and-paste features of the Macintosh or Microsoft Windows operating
environments. No other system has made student and faculty interaction so
simple a task. However, the lack of a programmer's interface has precluded
the kind of extensibility found in systems built with HyperCard or similar
"software erector sets" that include their own programming language.
(Launhardt & Kahn, 1991, pp. 13-14).