5.1.1 Conceptualization
Conceptualization was done by faculty members, and appeared to take place
before a project exists as an identifiable entity. But the passage does not
elaborate about the processes that occur during the "conceptualization"
of courseware. A richer description of the conceptualization process emerged
during a conversation with Schmidt (personal interview, March 4, 1992)
concerning courseware development processes:
I think what faculty do is take how they teach a course and they
think about how they can teach better, how can they do what they are already doing,
but better. I think it stems from what they're specifically trying to teach.
I don't think they think in terms of pedagogical theory. I think they think
more from their own experience in the classroom and their own experience with
the assignments they give students. They might think, "if a student could do
one pass or two passes of something by hand, if I let them do it on a computer
where they can put in parameters and see how things change they could do 10,
and that will give them so much more of an intuitive feeling." That's the
reason a lot of the engineering software has been to give students this
intuition and let them change parameters and see what if, to do simulations.
This type of activity surrounded Bucciarelli's (personal interview, June 23, 1992)
decision to prepare problem sets for Mechanics 2.01:
Bucciarelli: I got this idea to see what we can do with this cT language.
So I got a student to do just a few things on linear regression with it in the fall.
And I decided we should try the problem set solutions for the mechanics course I
was teaching in the Spring. The idea was that instead of cryptic or opaque solutions
that you give the students, let's give them something on Athena that allows them to
play with it, and interact with it, simulations. The students still had to do the
problem sets. These function as the problem set solutions. I would put these
solutions up after they handed in their problems.
The "conceptualization" of successful courseware did not appear to be a formal
process oriented around developing a solution related to the computer, but instead
emerged from a rich set of preexisting conditions, such as the faculty member's wish
to improve their existing educational methods. Faculty members used their existing
beliefs about learning processes in their discipline. If educational processes
changed through the use of the computer, it was probably the result of thought
during the later authoring and implementation process, rather than as a outgrowth
of the conceptualization of the project. This is consistent with a general
observation about the initiation conditions which usually surround successful
projects at Purdue, provided by Tom Putnam (personal interview, July 30, 1992),
the assistant director of PUCC:
Putnam: The places where it has really succeeded is where a person
came in with an education problem to solve and found that the medium could be
used to solve the problem, not the other way around. They didn't start with
a computer and say let's see if we can go out and apply this to education somewhere.
The medium is here. It's not the problem. The problem is that doing something
with it takes an enormous amount of effort. The hard part of this is still the
intellectual effort of the teacher to build the material into something that
can be delivered as instruction. That's the thing that takes the time.
It still takes the time to say what is it that I want to do, which materials
am I going to put together, how am I going to have them interrelate, and how
am I going to have it interface with the student.
At Brown, where Landow created his Context32 courseware, Kahn
(personal interview, March 2, 1992) echoed the same beliefs about
the importance of faculty having an educational problem to solve
as an important prerequisite, then also points out the importance
of that problem or goal, and then finding an appropriate match between
those goals, and the tools they chose to use:
Kahn: For the tools that we developed in Intermedia,
there were some points that seemed to be critical for success.
The first point is that it only works for faculty who think they
have a problem. That may sound obvious, but unfortunately it is
not quite as obvious as it seems. If a faculty person comes to
us and says, "I've been trying to get across these kinds of points
for the last ten years, and I know that I am having trouble getting
them across," and if the points they are trying to get across match
the strengths of the system, then you generally have a success.
For the Intermedia system, the problem that seemed to be the best
was the need to get your students to understand the interrelationship
between many pieces of information. Now, if you have a case where
the faculty member says, "I've been teaching second year Latin for
the last 20 years, and everybody learns second year Latin, what's
the problem? I don't need it," then it does not work out well.
Davis (personal interview, December 8, 1992), Manager of CECI, provided
an explanation about why it is so important for faculty to begin with
the problem, before they decide to use the technology. It appears that
the most successful courseware is not the process of finding something
to express as much as finding a better way to express the things that
are already there in a new and exciting way:
Davis: We're interested in trigger materials, which are
things like videos or images that will trigger student's curiosity.
It is like what an artist does when they do an exhibition. He or she
takes their personal vision and goes public.
They basically have to teach the public what they think about,
and what's important to them when they lay out the exhibition.
The way to lay out an art exhibition is to try and lead somebody
through a thought progression of
some kind, and that same process is the way you design courseware.
You lay out the path, both consciously and unconsciously, through
the materials. What would be the trigger to get you to look at this point,
to get you to read this, or listen to this, and then it's time for the
graphic. A lot of it is the orchestration of media. These materials
are a lot like operas, because they are about visually creating moments
for the viewer, where somebody goes, "Ah ha! I got it!"
There are a few teachers in education who know how to create these moments
for students. It begins with teachers who are interested in "ways of learning".
They are the ones who intuitively understand our work. All they are doing is
using the computer to model something they already know how to do. They have
to have that knowledge of how to create that moment, and then be able to
translate that into the media. They usually want to create that moment
with anything can get their hands on. I think the interesting teachers
are the ones who are interested in learning. They're interested in the
science of learning. So we try or find those people that are inspired
to be teachers, because of their own interest in the subject.
The technology does not come first. It is an interesting dimension.
It's a tool for their pursuit.
Conceptualization of courseware is a process through which faculty
members perceive ways in which they can further improve existing
solutions to educational problems through opportunities that are
presented to use particular types of computing resources.
Further exploration into the background of each of the directors
supports long term commitment to their goals, sometimes also through
the application of technology. It may be that for projects to be
sustained over time, they need to grow from a long term vision,
based upon ways to create appropriate instruction oriented around
both the discipline and the learner. There was an incubation of
the ideas in which faculty formed their own personal visions of
what their educational goals will be throughout their careers,
before conceptualization of the particular project, and the faculty
only used the project as opportunity to express their existing visions.
One consequence of the faculty conceptualizing projects was that they
wanted to create their own content, if not their own educational tools
as well. Not only were they willing to create the courseware when
opportunities were presented to do so, but there was a general preference
for producing their own, as an expression of their personal vision of the
knowledge base to which they were committed. This closely follows the
pattern that faculty are often not satisfied with textbooks that are
available, and go to great lengths to customize the knowledge they
present from their own well informed perspectives. While some people
consider it a problem that so few faculty adopt courseware created
somewhere else, it is not surprising in the context of the discussion
above. A large part of the prerequisite conditions of faculty using
computers in their teaching is that they find a way to use them to
express their own personal visions of the content as they already exist.
They prefer to express their own vision, rather than to adopt another's.
This phenomena was even illustrated to some extent within the successful
TODOR project. LaVin (personal interview, October 2, 1992) describes in
the passage below the degree to which this software was customized for
the MIT faculty:
LaVin: When I demonstrate TODOR, people expect it to be complete.
They expect to know a topic when they are done running a module, although
the modules were designed to be used as part of our curriculum. They are
generally a tool for doing a particular calculation task, or some piece
of a theory. To most people who are not aerodynamisists, they are completely
incomprehensible taken all by themselves. They are also slanted to the way
the topics are taught here, because they were to be used in this curriculum.
Some of the theories are different from the way they're described in the book,
and some of them are from the individual faculty members. They are completely
tailored.
Courseware became more of a division wide resource for the faculty to rely
on to help them create software to deliver the topics for which they were
generally responsible for teaching. In the future, it may be valuable for
initiatives to recognize that courseware endeavors that emanate from within
academic organizations are going to be characterized by fairly idiosyncratic,
although correct, characterizations of the content. This courseware will be
less likely to be adopted by other institutions, in much the same way as
locally prepared lab manuals and exercises are often limited in their generality.
The following quote accurately characterizes the self-expressive and creative
motives of those intelligent and discpline oriented faculty who conceptualized
and initiated courseware projects:
I must create a System, or
be enslaved by another Man's
I will not Reason and Compare:
my business is to create. - William Blake
This explains the low probability of faculty members producing generalizable courseware.
Administrators funding courseware development in academic contexts should expect this
to be the case, and take it into consideration when administering large courseware efforts.
It is unlikely that any courseware project will be successful if it does not begin with
dedication to the discipline and the learner. Anything less will probably not be able
to sustain the types of endeavors observed during this research. The courseware
construction process is demanding, and not only requires dedication, but inspires it.
Unfortunately, the same motivation that drives the creation of courseware also makes
it less generalizable.