5.2.3.1 Technical Expertise and Position
There was agreement among participants that, in addition to a well developed
vision about the goals prior to beginning the courseware project, a grasp of
the "limitations of the technology" was a valuable attribute in the faculty
who initiated courseware projects. The need for knowledge about "technical limits"
and how the knowledge should be incorporated within an educational computing project
was addressed in a conversation between Hopper and Putnam
(personal interview, July 30, 1992):
Hopper: When you have a faculty member come in and say
"I have this instructional need and I have found something that will meet
it in computers," do they need to understand computers? Does the technical
and subject matter expertise need to reside in the same person?
Putnam: That's an interesting question and we've talked about this and
I've seen a number of universities setting up services in their central
computing organizations to offer course preparation services to faculty
who come in and say, "I'd really like the computer to do this, can you
help me implement it?" There is a little bit of that going on. Not much.
And there are several things that stand in its way. Usually somebody doesn't
come along and do that who doesn't know a good deal about the computer in
the first place. If you get somebody who is not computer literate who goes
to a trade show, sees a computer doing something, and comes back and says,
"I want to do this," but they don't know anything about it, it's a very
difficult problem to interact with them because they don't know the
limitations of the technology or its capabilities.
Hopper: The limitations of the technology. I hear that a lot.
Could you elaborate about what that means?
Putnam: Well, for example it takes time to program a computer.
Full motion video, interacting with full motion video, and 20 objects on a full
motion video screen, is not practical. That is to say, it's not like you can
see an image go by and point at something and say, "What was that?"
That kind of interaction is not practical today, unless you have explicitly
programmed in the position on each object is on each frame. The other
problem is that I think people, who aren't accustomed to using computers,
aren't able to visualize the delivery of course materials in a systematic way.
Then the problem is that they develop grandiose ideas with extremely broad scope,
but don't have it pinned down enough in order to translate that into a systematic
set of steps, even if those systematic steps involve only simple text on a screen,
let alone if they happen to have integrated other media. You get that problem
when you talk to someone who is a rank amateur, although there are fewer and
fewer of those anymore.
Similar beliefs were echoed from MIT, where Lerman (personal interview, March 4, 1992)
describes the general nature of the projects that he has seen succeed within the
organization he leads:
Hopper: How would you characterize the successful efforts?
Lerman: Well, they tend to have someone who's primarily interested in the
implementation and someone who's interested in the pedagogy, and they often
are different people.
Hopper: Are there overlap in them?
Lerman: Somewhat. Certainly they work together. But the best results
seem to be when we find someone from our staff here who understands how to
build applications with someone in foreign languages, or in mechanical engineering,
or neuroanatomy, or some other area, that understands what they are trying to accomplish,
what they are trying to do educationally.
Hopper: Is there some need for overlap in that? Is anybody from that
area going to work, or is there some characteristics of the people in the
discipline that can work with AthenaMuse? Or could it be anybody who's
interested in it?
Lerman: They have to be interested in it, and they have to think through what
it is multimedia can do, what they want to present, and how they want to present it.
They have to have some sense of vision. They also have to have at least some sense
of both the strengths and weaknesses of technology. What's feasible and what's not
feasible. What's going to work and what's not.
In this example, there is less of an emphasis on the need for the entire set of
requirements to reside in a single faculty member. This may be because some of
the requirements for the successful projects can be found within the staff of
his own organization as needed. However, he does still show that even in cases
where support is available, it is still helpful for faculty to have a grasp of
the tools they will use.
The complex issues of communication, distribution of expertise, and development
team composition which are elaborated in a discussion between Lawler and Hopper
(personal interview, July 20, 1992):
Lawler: About those roles, there has to be someone who is in fact,
a person who is called a liaison between different areas of concerns, on the one
hand technical and other more content oriented. Now, what are the most important
issues between the different levels of competence in, on the one hand, the technical
area and on the other, the content area.
Hopper: Let me provide you with a metaphor from my literature experiences
that I find useful in conceptualizing these issues for myself.
There is one fairly common exercise of analysis which focuses upon the
relationships between Shakespeare's heroes and fools as they are manifest
in his different plays. He experimented with these two roles, such that
they range from being very different and distinct characters, to other cases
where they are presented as alter egos or foils, to finally where they are
incorporated into a single role, as when Hamlet play his own fool.
I use this analogy when I conceptualize the dilemma of technical expertise
in courseware development on the one hand, and content knowledge on the other.
You have the case of the content expert and the computer expert, the master of
content on one hand, and the master of media on the other.
In some cases, they can be the same person. But the more complex the system gets,
the less likely it is that someone will be both. At that point you have a divergence,
and question is how far apart they get. Do you have one person who will communicate
directly with the other person in a pair? Or do you have the case where you have
a whole string of people to communicate between the master of the computer medium
and the master of the content. The further apart they get, the more communication
and resources become issues, because when you develop a chain of people, more and
more people require more and more effort to communicate, and more and more
resources are needed to support the process.
I think it's a limit on the complexity of the environment that will actually
produce effective educational materials. You can produce materials with a big team,
and have content experts almost completely ignorant of the workings of the computing
environment. On the other hand, with a simple enough system, you can have one person
who can administer his own system, and be a content expert.
Lawler: He plays his own fool.
Hopper: Yes. But, now you've got the limitation of a low level environment.
So it's a trade off. In education at large, I fear we might be trapped into using
the low level systems due to barriers created by a lack of technical expertise.
Lawler: That's an interesting issue. I went up to Motorola University,
and it's very clear they are interested in exporting some of there expertise
to educational community, but they think their expertise is essentially in quality control.
But it may be the case, that what they could do, is engage people who are involved
in database application design, or other computer specialties as people who could
provide some knowledge to people who wish to develop educational computing projects
in various disciplines.
What roles the staff of computing organizations played in projects emerged as
projects moved from a relatively typical academic endeavors, to ones that required
more and more technical expertise. One key theme that was discussed by a number of
participants was the amount and sources of technical knowledge that should reside
within the team during the creation of courseware. It could be that technical
expertise is just a function of the skills required within projects which chose
to develop their own software as well as courseware. Yet even when teams did not
make their own software, there was a distinct need for close cooperation between
the computing environment support staff and the courseware development team.
One phrase that was frequently repeated was "technical limits". The significance
of this term was discussed by Ward (personal interview, June 22, 1992) who observed
the development of the ESCAPE project:
Ward: Somewhere within the team, knowledge must exist about where
your technical limits are. It is a requirement to know what the limits of the
technology are and to know how far you can push it before it breaks on you.
Hopper: How do you know if someone really knows the limits of the technology?
Ward: Then you run into a guessing game, and there is no simplistic method.
Talking with knowledgeable people is the best way. The other way is to spend
the time and money and learn the limits on your own.
Hopper: When you are talking to someone, how do you know if they know the
limits of the technology?
Ward: Just due to my knowledge of what the technology is. A lot of our
technology implementation is based on my knowledge of how far I can go
with it before the technology breaks, or we get caught with lack of resources.
Hopper: Do you mean like, ask them to digitize ten minutes of video and
see if they say, "Sure!"
Ward: "Yes, and put it on an 800K disk!" But no, a number of the
technology issues are subtle. It is not a simple question of
"yes you can do something", or "no you can not do it". It is not that overt.
The problem is that if you wait six months, it becomes maybe we can.
But if you wait a year, it becomes reasonable. It comes down to what
is readily done, rather than what is technically possible. A lot of things
are technically possible, but not readily done, so you just don't bother.
In the above discussion, it is established that "knowledge of technical limitations"
and other technical expertise needed to reside within the project team.
Across all projects, it appeared that it was helpful if the person with
the expertise had established credibility and active cooperation with the
main campus computing organization. This leads to the definition of a "Liaison" role.
Rob Tillotson served in the liaison role between the project and PUCC during the
ESCAPE restructuring and cross platform development activities. In this case,
the required amount of technical skills and knowledge expanded greatly as the
project's goals expanded to exploring multiple platforms and multiple forms
of digital media. Many challenges during the years 1990 to 1993 were due to
efforts to move to a different model of distribution using the Sun Spark Stations.
It was apparent that the issues were beyond the technical resources, knowledge
and skills available within the group associated with the project, and this
caused the nature of the project to change as Tillotson became a new member
of the team to accommodate the growing technical issues of cross platform development.
His involvement with ESCAPEbegan as a consequence of his employment as a
Purdue Computing Center Consultant. Out of his own curiosity, he informally
observed the class presentations, and then explored the HyperCard stacks.
As it became apparent that more technical expertise was needed on the project,
he became a candidate because of his existing knowledge and casual interest.
With hindsight it was obvious that it was an important advantage, if not
a necessity that he would serve both roles simultaneously. The importance of
this for his role is explored in the conversation below (R. Tillotson,
personal interview, June 23, 1992):
Hopper Now, in terms of PUCC, in this environment.
You're actually serving dual roles in this project. You have the advantage of being
a PUCC person, as well as a developer on our project. What do you do at PUCC?
Tillotson: Well, officially, I've been a general consultant for four years now.
Basically what it amounts to is that I've been around enough that I met practically
everybody, and most people around here know that I know what I am doing.
And I've done volunteer for UNIX group. Not much, but a little bit.
So I've had some contact with them as well.
Hopper: How important do you think that's been, in terms of your working on this project?
Would it have made a difference if you were a person outside PUCC?
Tillotson: I think it's kind of cut a lot of extra work for me out.
Whereas a person outside may have been able to do the same stuff I would,
but they may have had to take more effort trying to figure out what they
were able to do. Like I already knew the Sun systems were coming in,
and had the advantage that I knew what kind of stuff the Sun systems had,
where as somebody coming from outside would have had to find that out by
coming in and starting to use it. It's just a little bit of an extra.
Plus I know some of the people here. It's easier for me to get a hold of
some of the people here than it may be for somebody who didn't know any of them.
But, it's nothing that somebody from outside couldn't do, but it's just an
advantage because of the time it has saved.
The presence of an employee of the Purdue Computing organization,
and the special benefits that gave the project, raised the issue of
what degree this type of active support of development from "insiders"
was required for any educational computing project, and to what degree
the communication and advice functions that were afforded by this arrangement
should in fact be supported by the computing organization on a more formal basis.
The definition of the Integrator and Liaison roles involve issues of the degree
of coordination that was needed, as the interface designer would first work with
the director and content expert to establish the general content, organization,
and representation of information, and then work with the Liaison and programmer
to establish how this could be translated into a format that could be transferred
smoothly between platforms in an automated fashion.
These issues were addressed extensively over the history of the Athena project.
Besides LaVin, and Earll Murman, there was another critical member of the TODOR
courseware team. During the project's creation, Stephen C. Ellis served as the
Senior Applications Developer at Project Athena. Over time it became apparent
that he was critical to the success of project, because he would provide a
necessary tight coupling of environment factors with the requirements for
the development process. In this situation, Ellis served in the critical
role of communicating between the courseware project and the computing organization.
The importance of this role is described by LaVin (personal interview, October 2, 1992)
in the following passage.
LaVin: We were protected by the fact that we had an Athena staff
member on our team. Steve was our technical expert half of his time, and he
worked for Athena the other half of his time. Some of the other projects didn't
have as much of an applications programmer. Steve was also an excellent FORTRAN
programmer. That made a big difference in terms of support. When something was
coming down the road, Steve would know. BLOX would get updated, and we would
recompile everything. Steve acted as our ears at Athena by keeping an eye on
what was going on in Athena. He could buffer our projects from whatever happened
with the system release and things like that. It was very important.
Not only did LaVin recognize and participate in the critical "linkage" between
the academic courseware project and the computing organization for TODOR, but
in fact she eventually formally took on the role of faculty liaison at Athena.
This happened after it became apparent to many inside Athena that there were
important issues that needed to be addressed successful project and plan for
the stages that are going to happen anyway. In the early years of Athena,
there was some controversy and dissatisfaction with the amount and type of
support provided to meet the unexpected demands of supporting users in distributed
computing environments. As time went on, the project grew to appreciate the
importance of support from within their organization for courseware projects
utilizing their environment, and addressed those concerns successfully.
Daly (personal interview, March 4, 1992) describes the transition that
resulted in this transformation:
Daly: Yes. Well, we jumped, making the transition from experiment
to establishment. And that involves very real sets of changes. But things
have been going very well thus far.
Hopper: Actually, suppose we use a life cycle analogy. It sounds like you're still
functioning and growing then?
Daly: It's like going through an accelerated childhood, adolescents and now
we're young adults. I'd say we're young adults, and what we have to do is now,
as a young adult you have got responsibilities to your community. Instead of
putting things out and seeing how they work, and then taking grief afterwards,
we're doing it carefully. What does a DOS user need? What level of connectivity
does a Macintosh user want to Athena? And instead of giving them everything,
we just give them what they ask for, or do some projection based on more evaluation
of the customer's immediate and longer term needs. We work on developing a solution.
And then we put that solution out in the field for rigorous, vigorous testing.
And when it's working stably, it's finished.
The formality and importance of the faculty liaison role that evolved is
described below by Schmidt (personal interview, March 4, 1992) who now oversees
the cadre of Faculty Liaisons that have been hired, one of which is still LaVin.
Schmidt: My job right now is called Manager of Educational Planning
and Support in Academic Computing Services. I have two roles. One is managing
the faculty liaisons group, who are four people who provide direct internal support
for faculty developers. We try to do things to make it easier for them. For example,
one of my staff is writing some documentation on guidelines for software development,
and we are also putting together a locker with sample code. I also do some work
with faculty myself, and I serve as an intermediary between the technical staff in
the faculty meetings. I'm a broker, in a way, being able to speak both languages.
The success of the initiatives that originated in the early experiences of
courseware developers is apparent in the newer initiatives at Athena.
At present, relations between Athena staff and the faculty have
improved significantly. The project addressed most of the faculty's early
concerns once the initial crunch of system development was over. The initiatives
that addressed the concerns of the faculty included a much greater emphasis on
working with departments and improving developmental tools. Many of the earlier
problems, such as instability and unreliability, have now been solved, leading to
improved Athena-faculty relations. The faculty is also in a much better position
to understand what Athena can and cannot do and to set expectations and plan realistically.
Perhaps the best indicator of the new phase of Athena faculty relationships is that
many departments have installed departmental clusters or requested Athena workstations
for all interested faculty as a matter of policy.
(Champine, 1991, p. 75)
Not only has the issue of support for faculty courseware developers been addressed by Athena,
but they have even gone further to define the types of support that appear most successful
in their advanced academic computing environment.
The level and distribution of user-support staff across the Institute
should place them near the faculty members and students they will support,
and organize them to maximize their effectiveness. This suggests clumped
decentralization of user support: groups of three to ten user-support staff
associated with Schools, Departments, or groups of Departments, with a central
group providing backup and oversight. Such clumping will ensure that user-support
groups serving Schools or Departments each reach a critical mass, which will enhance
their service to students and faculty members by providing peer support, opportunities
for advancement, and other incentives to work effectively....Arguments for a 1:10 ratio
of support staff to faculty--a high ratio, about twice the current ratio MIT wide--
emerges with surprising consistency from observations of effective user support in
departments at MIT and elsewhere.
(Committee on Academic Computation for the 1990'S and Beyond, 1990, p. 31)
An interesting example that illustrates the new spirit of Athena is Bucciarelli's
initiative that incorporates cT into interactive problem sets that have been
implemented on a regular basis in the course he teaches. While the project
was founded upon discipline and learner oriented goals similar to the older
TODOR project, the choices concerning the development of the solution were
distinctly and intentionally different. The differences were responses to
the issues that emerged during projects like TODOR, and were based on solutions
to both technical and organizational problems in the early Athena projects.