5.1.2.1 Function Oriented Team Roles and Tasks
The most visible issues associated with the creation courseware involved
the people involved, what they did, and important characteristics such as
what they needed to know. There was usually a team of people that revolved
around the courseware projects. The courseware team emerged between the
conceptualization of courseware and the first time it was delivered to students.
The reasons for the existence of a team, as well as the makeup of the team,
varied from project to project based on a number of factors.
One distinction that emerged was that some projects were involved in
developing their own software tools as well as courseware, while others
were creating courseware with the aid of authoring software created by
other professionals, outside their organization. It is important to note
the difference between software design teams, and courseware design teams.
The most important point to note is the size of the team that resulted from
the decision to make software. Larger teams were required for creating
software applications, while making a single courseware package resulted
in a smaller team. For example, the software design effort for Intermedia
required a team of twelve individuals which included one user liaison,
one graphics artist, and 10 software developers (Meyrowitz, 1986).
A similar situation was found at the AthenaMuse software development effort
where the VCG, that later developed into CECI.
Even in cases where software was acquired from another source, courseware
production was not a solitary activity. A reason that a team would form
would be to fill the various numbers and varieties of roles that were needed
to accomplish the required tasks.
The team approach to the development of instructional
software is often much more successful than for each individual to
develop on his or her own. The team can be organized around a
discipline or department and can more readily assemble the people
and skills needed to develop high-quality software. Comments by colleagues,
even about preliminary versions, can be very helpful in improving software.
(Champine, 1991, p. 67)
No matter how many people were on the team, distinctly different types of skills,
tasks and the roles were required. These changed relative to the main types of
software functionality that the courseware initiator chose for representing
their knowledge. For example, artists were likely to be associated with multimedia,
programmers with microworld oriented projects, and interface designers with the
projects which dealt with the linking of large amounts of information. In some cases,
a person was chosen to fill a role for which they had not been formally trained,
and then there was evidence of their learning the role as the need arose.
There was a general pattern that interface designers had previous instructional
design training, a background in the field of education, and limited exposure
to one or more programming languages. Beyond educational backgrounds, it appeared
that experience was critical, sometimes obtained over the course of the project.
This was emphasized by Landow who had personal experience working with large bodies
of content. Through his own experiences with building extensive bodies of hypertext
knowledge bases, and guiding his students to do the same, Landow formed conceptions
about the skills required of designers of hypermedia courseware. In the passage below,
Landow emphasizes the key role that experience plays in the preparation of designers
of these types of materials:
Now that hypermedia systems exist, designers must use those now
available to gain first-hand experience of various approaches before designing
new systems. Equally important, designers must gain experience not simply of
hypertext systems themselves but of working with substantial bodies of hypertext
materials, those with at least several thousand documents. These materials,
moreover, should not be fixed or static but continually changing.
(Landow, 1990, p. 58)
In contrast to the role of an interface designers for hypermedia,
when developers created dynamic simulations, extensive programming
experience in one or more languages was an important prerequisite
that was mastered before the project began. This will probably
remain true for projects which attempt to use the computational
ability of computers to model reality on anything more than a trivial level.
It appears that even in the AthenaMuse environment, which is designed to be
mastered with relative ease, there is likely to be a point at which
programming will still be required to achieve some ends:
(S. Lerman, personal interview, March 4, 1992)
Hopper: So are you aiming for a seamless environment
where you don't need any programming at all?
Lerman: In terms of the description of what things look like, yes.
In terms of behavior, AthenaMuse is like a very general application.
You can do a lot of different things with AthenaMuse. It doesn't
impose a look and feel. It allows you to describe very complicated behavior.
That sort of description will probably in the foreseeable future require
writing code or scripts. So there will always be some point at which,
we believe, you won't have a graphical way of expressing what you want.
So you will have to go in and actually write something.
This particular explanation may be come even more important in the future
as multimedia becomes more prevalent:
Software Functions Relative to Types of Roles and Tasks