5.1.2.4 Event Driven
Despite the informal nature of the general processes associated with the courseware
projects, there were many cases were formal products resulted from various events
surrounding the creation of the courseware. Examples of the types of "events"
that provided the elaboration of formal products was the delivery of the courseware
to classes, the writing of professional papers, the development of grants,
and particularly presentations at formal professional meetings. The projects
were all clearly "event" driven.
The most common type of event that drove the creation and expansion of courseware
was its delivery in the contexts of courses. For example, ESCAPE was implemented
each semester since Fall of 1988 within the context of a small experimental course
in Engineering Career Planning (ENGR 195C). Engineering 195C has generally only
been offered to 10-25 first year undergraduate engineering students who are
undecided regarding a field of engineering or engineering as a career.
The students represent a wide range of academic backgrounds including honors
students as well as students in the regular program and high risk students.
Enrollment in this pilot course has been limited so that new developments and
methodologies can be tried out on a small scale. An example of the event driven
nature of the ESCAPE project is given below (M. Hopper, personal interview, July 20, 1992):
Hopper: When I started, I went into using HyperCard, and it was a
project that was not complete. The first thing I had to do was figure out a way
to make it work. It took me weeks to figure out what it was, how it was organized,
where all the data was, and how much of it there was. It was not clear at the time.
What pushed me was that we had to teach it.
After the first time the HyperCard stacks were used, it was obvious that there
were both interface problems with the stacks themselves, and a number of other
technical problems to overcome regarding their access, before future presentations
to students could be made. The teaching assistant needed to constantly master
new technical challenges and gain new knowledge to deal with these in order to
be prepared to present one or more times a semester. The overall nature of this
project since the first course has remained implementation driven. Before each
time the course has been offered major and or minor efforts have been required
to improve ESCAPE. The atmosphere within the project is reflected in Rehwinkel's
(personal interview, June 22, 1992) description of the project as it has grown:
Hopper: Do you see any benefit of the new materials we used the
last few semesters versus the materials we started with, at the beginning.
Rehwinkel: There is no comparison. When you have something you keep refining it,
until it's good. Sometimes you're too close to the system and that is when you ask
the students for input. I think it helped to ask other people to review the system
because sometimes we would miss something.
Context32 has always been treated as an open-ended work in progress.
During the first inception of Context32, there were approximately 300 text documents,
500 graphics, and 40 timelines, all created by Landow and his graduate students.
By the end of the first term in which English 32 used Intermedia materials,
Context32 consisted of approximately 1000 documents and 1300 links, and since
then the number of links and documents have continued to grow. Landow and his
students have added new materials each semester the course has been taught;
by October of 1990, the collection has grown to 1350 documents and 2600 links.
Landow's direct supervision of the students was limited to copy-editing their
essays and rejecting materials that did not meet basic standards.
Not only did course delivery play an obvious role in the growth of Context32,
it also played a key role in the growth of the Intermedia software as well.
The version of Intermedia that has been used for the classroom supports text,
graphics, timelines, and has a dictionary facility. (N. Yankelovich, personal
interview, March 6, 1992)
Yankelovich: Intermedia was enormous. We probably had 10 pages
of ideas and implemented about 2 of them. We began with a fairly narrow focus
about what we were going to do, and we based our priorities on who was willing
to fund what. Then as we started building it, our ideas about what we could do
increased dramatically. We did a lot of things that we never thought about when
we started. It was really evolution. Having George Landow on the design team
worked out really well for us, and helped us to prioritize a lot of the ideas
about what we were going to do, because we had so many ideas, and not that many
people to work on them,
We just couldn't do everything. A number of the features that were developed
were ones that George Landow thought would be useful for his class. It turned
out that a lot of those applied to other courses. We were also working with
Peter Heywood, a biology professor. It was a good balance. We made sure we
never implemented anything unless we confirmed that it was something that they
could both use.
Implementation or delivery of courseware was not the end of the process,
but an integral part of both courseware and software development. Thus type
of arrangement was also found in each of the courseware projects in the MIT environment.
Instructional software often evolves over several semesters.
The experience gained in using the software provides valuable insight into
how to do it better. Producing the "perfect" software package the first time
around is impossible and not necessary, but persistence and continuity can
lead to a final product that will relate well to lectures and problem sets.
(Champine, 1991, p.67)
The relationship between the state of the courseware and its delivery within
the context of courses is also demonstrated specifically in relation to the
TODOR project in this passage written my Earll Murman, the director of the TODOR project:
As modules reach the stage where they are to be released, a design
review is conducted to correct coding, informational display, and program flow
deficiencies. Usually in our enthusiasm to try out the module in a class,
the early version of the program has problems. But as experience is gained,
these are corrected. (Murman, 1987, p. 5)
The conditions which surrounded the preparation of the modules for delivery is
further described by LaVin (personal interview, October 2, 1992) below:
LaVin: Things would often get done right before the module was
going to be used as a problem set . We would wake up and go, "Oh, this
doesn't quite do what I intended, so we better fix it." The programmer
would probably work a 20 hour week instead of a 10 hour week to get
something finished. I also spent a lot of late evenings working on
modules before they were used.
Not only did courses play a role in the creation of courseware before the delivery,
they also played a key role after delivery. In the project for The Mechanics of
Solids 2.01, a subject required of all majors in Mechanical Engineering,
more formal evaluation in the context of course delivery helped improve the courseware.
This past semester I developed 10 modules for 2.01, The Mechanics of Solids,
to serve as problem set solutions. Another was developed as a tutorial on the
concept of stress as tensor. A survey intended to gather student response and
constructive criticism was carried out two weeks prior to the end of the semester.
Most students made use of the modules and claimed they were helpful preparing for
quizzes and in reviewing concepts. They also stressed certain deficiencies--
they wanted to take away printed material to study back home; they would like
to see more details of the analyses presented.
(Bucciarelli, 1992)
The key role of delivery as a form of motivation for continuing the creation
of both software and courseware is a well recognized fact at CECI. This has
been part of the basis for the mutually beneficial relationship between the
group who develops AthenaMuse and groups like the Physical Geology Tutor Project
which take advantage of the opportunity to work with forefront development tools:
The first phase of AthenaMuse development has proceeded in tandem
with the creation of applications. We have found that application requirements
play a key role in shaping multimedia design and in testing that both design and
implementation actually meet the needs of application writers.
(CECI, 1991, p. 6)
Delivery has traditionally been considered the end of creation, and the
beginning of courseware's existence. This study revealed that the delivery
of courseware and the creation of the courseware were simultaneous, and soon
after courseware ceased being "developed" the project ended delivery.
Courseware seldom continued to be used extensively if it was not also
simultaneously being modified. The projects active existence was
consistently marked by both processes going on at the same time,
and the end of projects were closely associated with the discontinuation
of either process. An accurate way to summarize the nature of these projects
is that they are clearly event driven, and they only thrive when both delivery
events and production processes are in operation together.