4.2.2.4 Ease of Creation and Interaction for Modeling and Microworlds
Projects which incorporated simulations faced challenges to providing for efficient
and effective interaction and creation. Originally, the ESCAPE team believed HyperCard
would be an efficient tool to use to create functional representations or models of
engineering disciplines, because it incorporated both internal "scripting" capabilities,
and the ability to also link to external programs.
This ability to extend the environment appeared promising for implementing the
"intelligent microworlds" concept. Unfortunately, models that would have been
the core of serious interactive "microworlds" proved to be a problem.
If they were to be more than trivial attention getting mechanisms that could
be created in the internal scripting language (HyperTalk), then significant
expertise was needed to create them in external commands (XCmds).
Because of the limitations of the HyperCard environment to easily
support powerful programming within it, or easily accessible programming
from without, the ESCAPE courseware remained primarily text based.
At this point, the long range objective of "hypermedia" learning environments,
integrated with interactive "microworlds" remains to be achieved.
In contrast to the ESCAPE project experience, the TODOR project successfully dealt
with "usability" issues for creating interactive microworlds quite early in the
project's existence. The following passage provides a description of the reasons
why "usability" of simulations from the students perspective were considered critical,
and the way in which this issue was addressed in the first year of the project:
During the first year of the project, a great deal of diversity
was exhibited as each faculty member approached the experiment from his or her
point of view. Also, the hardware (terminals, hard copy, etc.) and software tools
(window managers, graphics libraries, etc.) available under Athena were not well defined.
Several faculty found it much simpler to work on their PC's rather than wait for tools
to be available under Athena. A module could be developed by a faculty member in a
week or less on a PC while it took a semester or more working with a UROP programmer
on the Athena system. As our experiment progressed and experience grew, it became
apparent that we needed some common user interface and format to our modules.
Without this, students would be faced with many different conventions to learn
for I/O and program flow. Development and maintenance of the software would be
difficult to manage. We needed an interface which made multiple work areas,
menu driven choices, and both static and dynamic graphics possible. The Athena
supported, commercially available, interface BLOX was selected since it satisfied
these needs and was compatible with FORTRAN, which most of the programs were written in.
(Murman, 1987, p. 5)
This choice of BLOX turned out to be very helpful to the TODOR project for a
variety of reasons including the common interface it provided for the project.
It provided a productive way for students to interact that did not involve
entering text into the machine. The experiences of the TODOR courseware project
provided powerful insights into design decisions for "microworlds" that made
learner interaction easier and more productive. TODOR modules operated with
an interactive interface which required little computer expertise to use.
Input was generally via mouse activated menus and scales. Experience
showed the developers that mouse input is preferable to keyboard input.
It was not only easier, but less prone to inadvertent crashing of the program.
For example, when numerical input was required, it was done from a scale,
an integer menu, or a calculator icon. A top level library was created from
which to access all the released modules. A user need only enter a few user
commands to start, and thereafter TODOR modules were completely menu driven.
(Murman, 1987) The overall effectiveness of
the above approach is supported by a observation made later in a publication
summarizing the TODOR experiences:
Since the overall limit in the use of modules is the time
available for students and faculty to spend on a topic, increasing the
productivity of the user interface translates directly into increased
use of modules. Little effort is required to use the software, and the
objective of teaching fluid mechanics, not computing has been achieved.
(Murman, LaVin & Ellis, 1988, p.10)
This is one example where a distinction between the user and author interface is critical.
Unlike Intermedia, in which the author and user interface were the same, the author
and user interfaces were separate in TODOR. Unfortunately, there was a discrepancy
between the degree of "usability" that was able to be provided by the author for
the user, and the "usability" of the interface which the author needed to use.
The productivity of the user interface was lower than the "usability" of the
BLOX authoring interface. It was not as productive as the project director,
Earll Murman felt was needed, although BLOX was a good example of what was
available at that time:
In addition to the effectiveness, an important concern is the effort required
to develop and use the software. The development of a module has required
substantial time and cost. Although a productive user interface has been achieved,
a more productive developer interface is needed. An example of such an interface
is CMU Tutor, which provides an easy to use authoring environment for workstation
level software. (Murman, LaVin & Ellis, 1988, p. 10)
The advice suggested by Murman, who also directed Athena for a time,
was eventually incorporated as a major facility for developers in the
Athena environment. The problem - set solutions that were developed by
Bucciarelli for Mechanics 2.01 were developed in cT which is the most
recent version of Carnegie Mellon University (CMU) Tutor that was referred
to by Murman in the passage above. While in many ways, this newer project
shared many of the same academic goals and objectives as the older TODOR project,
there were key ways in which it differed at the technical and organizational levels.
One of these grew out of Bucciarelli's belief in the importance of implementing
his project with a very different type of tool than was available at the time
that the TODOR project was initiated.
Bucciarelli (personal interview, June 23, 1992) reflects the new "tool"
oriented spirit of more recent goals of Athena in the passage below:
Bucciarelli: Forget a textbook type of application.
We should think more in terms of providing faculty and staff with
programming languages and tools to develop their own materials.
The good thing about cT is that it has an easy to learn interface.
I found it quite easy to get into and I found students have taken
to it without much difficulty.
While cT is highly regarded by Bucciarelli for its easy to use
interface, it still required a certain amount of programming skill to use.
This brings up a central issue in the construction of simulations in regards
to the issue of "usability." When languages are used, they should be easy
enough to learn to provide for reasonable interaction, yet powerful enough
to allow for reasonable creation capabilities. If the creation of
simulations rely on the ability to program, this will prove to be a
limitation to their creation, because of the scarcity of the technical
expertise needed to create them in most typical educational settings.
So one possibility is to create tool kits that require a minimal amount
of programming to create reasonable simulations.
The AthenaMuse software is an example of such a toolkit.
One design principle of AthenaMuse was to minimize the use
of procedural code, because data specification tends to be quicker
to create and to require less-specialized skill, and it is possible
to edit it with point-and-click interfaces, thus diminishing the
large learning curve associated with teaching programming languages.
The team that created AthenaMuse also experimented with using the same
"directed graph" structure for both simulation and linking, so that
some simulations were created without resorting to coding in a
traditional programming language. A creative approach which has
not yet been fully implemented or tested beyond a few prototypes
involved using a spreadsheet like environment to describe the positions,
relationships and other values of elements on the screen:
As an editing environment for such constraints,
they experimented with a modified spreadsheet calculator.
They embed small spreadsheets in the AthenaMuse environment
as editing utilities for defining and managing constraints.
A cell can directly reference a dimension in any package as
its input value. Values can be picked up from one or more dimensions,
processed through a series of mathematical functions on the spreadsheet
and output to other dimensions or display objects. In a simple case,
the spreadsheet can act as a patch panel or routing switch, directing
the propagation of data values to different components of the system.
In a more complex case, the spreadsheet can maintain the constraint
relations that form the core of a simulation.
(Hodges, Sasnett & Ackerman, 1989, p. 41)