|
Phase 1 - 1980s (Doctoral Thesis, 1990-93)
Courseware Projects in Advanced
Educational Computing Environments
Organizational Contexts
Factors in the organizational contexts were unexpectedly critical.
Indicated by placing at base of model, and representing as largest area.
Complex learning environments required regular use to survive.
The project director's challenge was to manage the relationships between
key factors within the substantive, technical and organizational contexts,
while also maintaining balance among them.
Survival depended upon establishing a viable model to sustain the
resources required to support continuous maintenance and delivery.
Organizational Contexts
Roles, Tasks & Timing
Resources
Organizational Conclusion & Recommendation
Roles, Tasks & Timing
Research Question
What were the relationships between the roles, tasks, and the timing of tasks for development?
Finding
The roles and tasks varied systematically according to three phases of courseware identified as:
- "Conceptualization"
- "Creation"
- "Continuation"
"Conceptualization" Roles and Tasks
Faculty Conceptualized Courseware
They began with a problem and found a way for computers to meet a previously existing need, rather than the other way around.
The Source of Courseware
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.
(Interview Between Ben Davis & Mary Hopper, 1992)
"Creation" Roles and Tasks
Courseware creation involved teams. Team roles and tasks varied by:
(1) type of software functions emphasized (e.g. modeling required programming performed by programmers)
Types of Roles Relative to "Functionality"
(2) relationships to the academic and computing organizations on campus.
Courseware creation was "event" driven.
"Continuation" Roles and Tasks
Continuation of courseware depended upon the successful establishment of a system to provide for continuous maintenance, delivery and resources.
Creator - fairly traditional course structure
Integrator - departmental resource "lab" structure
Orchestration - research organization developing courseware as well as software
Resources
Research Question
What were implicit or explicit educational, technical, financial and personnel support policies within the organization(s) which had an impact on courseware projects?
Finding
Different models for the provision of human, technical, and financial resources evolved based upon the types of organizational structures surrounding courseware projects.
Organizational Conclusion & Recommendation
Make provisions for faculty who wish to create and provide funding for departmental "facilities" to support local courseware development and delivery. These can be staffed by "integrators" and supported by university wide "orchestration" groups with "linkage" to traditional academic and computing organizations.
CPIAECE: Organizational
AERA Article: Role of Learners
AERA Article Better Graphic
Don't include public vita, portfolio etc.
Computers on Campus
Spenser
Organizational Contexts of Advanced Courseware Projects
It was examining the organizational or "human" contexts of projects that revealed how they grew from an initial vision to a reality for students in classrooms. The examination included the types of roles that were needed, the characteristics of the team members who filled those roles, and the tasks or processes carried out. There were distinctly different roles required as projects moved from conceptualization to creation. Conceptualization was done by faculty, while courseware creation was carried out by a team. Two distinct ways of characterizing team roles emerged. The first type of distinction was based on the types of tasks that were performed relative to the courseware, and corresponded closely to the software functions the project chose to employ. The second way in which roles were distinguished was independent of the types of activities performed during development, and was instead based on the relationships
of the team members to the academic and computing organizations. A consistent theme was the limitations and opportunities that were associated with the availability or scarcity of various forms of resources.
Timing, Tasks and Roles
This discussion will begin with a description of how courseware came into being at MIT during Project Athena. In the following passage, a critical observer from inside Athena provides a brief overview of the general stages surrounding courseware projects:
The development of software to be used in the curriculum involves:
o Conceptualization of the mapping of a problem in learning to a solution using the computer in a particular role. This includes a definition of what it is you want the software to do and how you envision the student using it.
o Finding something that already exists that could satisfy these requirements, such as a commercial package or software developed by colleague or student, or designing and implementing the software yourself or with the aid of others.
o Delivering the software in a subject to students.(Stewart, 1989, p. 291).
Conceptualization. Courseware projects began with conceptualization and then moved to either acquisition or creation (Stewart, 1989, p. 291). Conceptualization was done by faculty members and included decisions about the function and usability of software. It was not a formal process oriented around developing a solution related to the computer, but instead emerged from a rich set of preexisting conditions. This was a consistent observation about the initiation conditions which surrounded successful courseware projects. Putnam (personal interview, July 30, 1992), the assistant director of Purdue University Computing Center, made the following observation:
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) emphasized the importance of an educational problem to solve as a prerequisite to conceptualizing successful courseware. In addition, he points out the importance of then finding an appropriate match between educational goals and the chosen tools:
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.
A similar description of the conceptualization process emerged during a conversation with Schmidt (personal interview, March 4, 1992) concerning courseware development processes at Athena:
Schmidt: 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.
In a discussion with Davis (personal interview, December 8, 1992), Manager of CECI, a more elaborate explanation developed about why it is important for faculty to begin with an educational problem, before they use advanced computing technology. Successful courseware was not finding something to express as much as finding a new and exciting way to express things that were already there:
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.
The conceptualization of courseware was a process through which faculty members perceived ways to solve their existing educational problems through opportunities presented by particular computing resources. The background of project directors demonstrated long term commitment to the educational goals addressed in their courseware.
Creation. Once conceptualization took place, a team was formed to create the courseware. The makeup of the team varied from project to project. The processes used by the team members during courseware creation were informal. When formal products like assignments, manuals, or written documentation did exist, they tended to evolve from the requirements implicit in events. The implementation driven nature of the projects caused delivery and evaluation to become intertwined with the creation of courseware so that they were inseparable processes that occurred on a cyclic basis.
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 tools created outside of their organization. Larger teams were required for creating software applications, while a single courseware package resulted in a smaller team. The creation of 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. Even in cases where software was acquired from another source, courseware production was not a solitary activity. A team would form to fill the various roles needed to accomplish the required tasks (Champine, 1991, p. 67).
No matter how many people were on the team, there were different types of skills, tasks and the roles that were required. These changed relative to the main types of software functionality that the courseware initiator chose for representing their knowledge. The relationships between the chosen software functions and the resulting roles and tasks are shown in Table 6 (see Table 6).
Table 6 Software Functions with Corresponding Types of Roles and Tasks
Software Functions Role(Tasks)
Linking for Hypertext and Hypermedia Interface Designer(Structure, Link, Edit, Integrate)
Database Storage and Access Database Manager(Store, Manage, Maintain)
Multimedia Capture, Creation and Manipulation Multimedia Artist(Digitize, Edit, Orchestrate)
Microworld Construction with Interface to Models built by Language or Toolkit Programmer or Designer(Program or Design)
Network for Connectivity To Distributed Communities of Users Network Specialist(Administer Server, Provide Client)
Artists were likely to be associated with multimedia, programmers with microworld projects, and interface designers with the projects which dealt with the linking of large amounts of information . When people filled roles for which they had not been formally trained, there was evidence they learned skills as the need arose. However, the general pattern was that interface designers had instructional design training, a background in the field of education, and limited degrees of exposure to one or more programming languages. Previous experience was also valuable for constructing large hypertexts (Landow, 1990). When developers created dynamic simulations, extensive programming experience in one or more languages was a prerequisite that was mastered before the project began. This will remain true for projects which use computers to model reality on anything more than a trivial level. Even in the case of AthenaMuse, which is designed to be mastered with relative ease, there is likely to be a point at w
hich programming will still be required to achieve some ends (S. Lerman, personal interview, March 4, 1992).
Experiments in Epistemology. A more subtle type of task performed by developers emerged. In pragmatic efforts to generalize structures created from particular courseware, the tasks began to resemble exercises in "epistemology". For example, hypermedia interface designers created generalized structures to represent the relationships among knowledge that could be used across disciplines. This is illustrated in the following description (E. Schlusselberg, personal interview, October 1, 1992):
Schlusselberg: Initially, I just wanted to finish a project. Then I began to realize that there were structures that repeated. And as I did more projects, it became really important to get something that I could just plug into an environment. For one project it took me two months to just build the templates. Then another project came in and in about a week's time students were using the application. The quick turn around for this second project was possible because I reused the structures I had created for the first project, so all of a sudden production became much, much quicker. Sometimes you create a structure, which you think incorporates everything that you would ever want to do, and then all of a sudden, you want to add one little element, which you think is going to be absolutely trivial. Instead, it disrupts your whole organization. But it brings insight into how your old structure was wrong, and suggests ways for improving or making a more flexible structure. I think the development process
is a spiral one, because you continue to go back to redefine and re-implement.
When programmers of "microworlds" developed projects based on structures from other projects, the structures also become abstracted to more generic structures. This phenomena was elaborated in a conversation with Jackson, the current Director of Academic Computing at MIT (personal interview, March 4, 1992):
Jackson: Someone realized that finite element analysis programs helped you understand all sorts of energy transfer problems. All of the sudden there were 20 finite element programs. And then the next year, there would be one for civil engineering, one in thermodynamics, and the next year there would be a generic finite element program with front ends for all these different disciplines.
The processes of courseware designers produced courseware that increasingly reflected common knowledge structures across disciplines. Courseware may have thus provided the laboratories of "epistemology" where designers performed experiments through their pragmatic quests for generality.
"Event" Driven and Cyclic Processes. The production processes associated with courseware projects were generally informal, but many formal products resulted from events surrounding the creation of the courseware. The most common type of event that drove the creation and expansion of courseware was its delivery in the contexts of courses. Examples of other "events" that provided the elaboration of formal products was the writing of professional papers, the development of grant proposals, and presentations at formal professional meetings.
ESCAPE was implemented each semester since 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. 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 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. This aspect of the project was reflected by Rehwinkel (personal interview, June 22, 1992):
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, timelin
es, 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. 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 a process, but an integral part of both courseware and software development. This was also true of courseware projects in the MIT environment (Murman, 1987, p. 5). 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 the Physical Geology Tutor Project:
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. (Center for Educational Computing Initiatives, 1991, p. 6).
Continuation. Delivery of courseware has traditionally marked end of creation, and the beginning of existence. This study revealed that delivery and creation of the courseware were interdependent in advanced computing environments. A project's active existence was marked by delivery and modification going on at the same time, and the end of projects were associated with discontinuation of either process. When projects were considered "finished", their maintenance was more likely to be neglected. Projects quickly fell from disuse to "unusability." Faculty who conceptualized courseware may have had a predisposition for viewing courseware within the framework of publications like textbooks. These beliefs were counter productive to projects in changing environments. Even when courseware was adaptable, it still needed to be maintained.
The interest of the faculty is in the initial development of the educational software, not in its ongoing maintenance. The expectation is that once the software is written it should continue to run indefinitely. The computational model of networked workstations with its tendency to change has far different implications than a personal computer where the operating system can be frozen forever. (Stewart, 1989, p. 302)
The continuation of courseware depended upon recognizing and addressing the technical issue of adaptability. The degree to which adaptability of software played a role in the continuation of courseware was demonstrated by the fact that the majority of successful projects in this study chose to use different software packages years after the projects began. Successful courseware evolved towards a state where the courseware's content, structure and function were abstracted from a particular implementation, and where software packages only functioned as a particular means to embody the project.
Another factor that appeared to protect projects from deterioration was the degree to which computing organizations chose to actively maintain local courseware. One place where this role was recognized and filled was the Athena computing organization. Staff were hired to help faculty to produce maintainable software and watch over the software once it created. If the computing organization did not provide support for software maintenance, then the project had to provide for its own continuation. A factor that contributed to continuity from within the project was a high degree of orientation or socialization processes that took place during transitions in the team.
Resources as Limitations and Opportunities
In descriptions of successful projects the issues of resources occurred periodically. Different types of resources presented different limitations during each phase of courseware life cycles (conceptualization, creation and continuation). Four types of resources corresponded to the major contexts of educational computing projects:
o information or content (academic);
o hardware, software, and classroom facilities (technical);
o human (organizational)
o financial (organizational).
The essence of the initiation of courseware was that circumstances converged so that a faculty member with an appropriate "vision" happened upon an opportunity to express it when financial, technical or human resources became available. The "concept" existed prior to the conceptualization. The role of resources during conceptualization was not as much "that which was acquired" as much as "that which ignited". Opportunities for resource acquisition presented faculty with a chance to pursue the expression of their previously existing educational goals, and caused transition from conceptualization to creation of projects. After conceptualization, resources influenced the likelihood of courseware developing enough to be used by students on a regular basis, as well as how long the courseware project continued to be used.
Informational Resources. A subtle but powerful form of resource that played a role during courseware conceptualization was the availability of "information" or content. The faculty member who conceptualized courseware determined how the content would be obtained. The subtle aspect of this resource is intellectual property rights. Even in cases where the copyright could be obtained, there were subtle "hassles" in securing it. Copyright issues were among the most frequently cited issues in both spoken and printed form (noted as frequently as funding), while in no case were copyright constraints ever cited in reference to a particular example. It appeared to be overcome in each particular instance, while remaining a problem that was generally recognized and mentioned. One explanation may be that faculty knew what materials were copyrighted and which were not, and they screened their ideas based on this reality during conceptualization. They didn't consider dealing with materials for which they didn't
know they could obtain copyrights. The limitation then was a result of what was considered, rather than what happened after courseware was a product to be copyrighted. It was a general problem because of a preemptive sense that faculty had for what they did not consider. If this is correct, then copyright was a silent barrier to producing generalizable courseware. There were no examples to demonstrate how it acted as a direct hindrance because faculty were attuned to avoiding the problem in direct ways, such as copyright disputes. This could also help explain why academic software is characterized by such a "local bent."
Technical Resources. At the beginning of projects it was important that there was an appropriate match between the goals of the faculty, and the goals supported by the available technology. The functionality that the courseware most required was based upon the discipline and learner oriented goals the faculty member wished to support, and was determined before the particular software was selected. If there were no available tools, then conceptualization included determining characteristics of the needed tools. When appropriate tools to support the desired goals were not available, then less appropriate tools were used or greater resources were acquired to develop the needed tools. While projects needed appropriate development equipment and software to begin with, their implementation driven structure also soon required appropriate facilities such as electronic classrooms. Over the course of this research it was clear that appropriate delivery facilities were key technical resources that contributed to t
he success of projects.
The ESCAPE project had access to a number of different PUCC PC Instructional Labs with public Macintosh and DOS computers on a semester by semester basis. During administration of the materials, the atmosphere within the computing labs emerged as a factor in the success of the overall implementation. A number of participants from the ESCAPE project remarked about the impact of conditions during the first semester, and the variability in success that appeared to be the result of different conditions in different labs during different implementations (J. Rehwinkel, personal interview, June 22, 1992). At Brown, students made use of Context32 in the Electronic Classroom in the Rhode Island Hall. Athena also supported special electronic classrooms with Athena workstations that allowed small classes or recitation sections to use the computer during class hours by reservation. Several lecture halls (35-225 and 34-101) each had an Athena workstation attached to a projection display for lecture demonstrations.
Human Resources. The issue of human resources was a matter of finding people to work on projects that had appropriate skills and time to carry out required tasks. This was a great deal more complex than just a fiscal ability to hire capable people. A central dilemma of courseware design in academia was the nature of the organizations involved and the constraints on human resources that were caused by existing organizational structures. Explanations which include motivation and working conditions must be used to accurately portray the projects examined during this research. Many of the distinct challenges related to human resources resulted from the nature of the academic communities in which the projects took place. The following statement from a past staff member of Athena captures the dilemmas of developing courseware in academic settings:
Understanding the business we are in is essential. The faculty are in the business of research and education, not programming per se. Students are in the business of getting an education through formal instruction and exposure to research, not programming per se. Software professionals are in the business of creating programs to accomplish a desired set of functions which are maintainable. Linking the right skills together results in a usable product. Less than that is amateurism... Writing innovative educational software is hard work, not a task to be undertaken as a side activity. Assuring the results will have a future is even more difficult, requiring programming practices that permit the generation of maintainable code, a consistent eye to products in the pipeline and those that are slated for replacement. (Stewart, 1989, p. 301)
No matter which type of development was done, there were consistent conditions that surrounded the activity. There was evidence that elements inherent in the nature of the development led to a set of related and frequently noted patterns. The pervasive "developer's" patterns may have reflected efficient strategies for coping with complex, time consuming and unpredictable tasks. (P. Kinnicutt, personal interview, October 1, 1992).
Kinnicutt: Work on this project was cyclic. I was a Teaching Assistant for a C programming course, and that involved times in the office to help students.
Hopper: Do you find any particular pattern in how long you work on development at a time?
Kinnicutt: For me, the task drives how much time I spend on a particular day. I set aside some agenda I wanted to accomplish, and then did it from beginning to end. I would work until I got it done. It could be 5 p.m., or it could be midnight.
Developers may have worked long hours because every time they left a task, they would have to spend time reconstructing a representation of the task before they could move forward. Developers also reported underestimating the time it would take them to complete a task, loosing track of time while they developed, and forgetting how long a task took. When they estimated how long a task would take, they based their estimate upon the short period of time it seemed to take, rather than upon the time it actually took. Developers also forgot the details of the complex processes they would go through. They remembered an overview, rather than all the little things they forgot they had to do to accomplish larger tasks. (A. LaVin, personal interview, October 2, 1992)
LaVin: I shared an office during most of the project. During the day, I also had many interruptions. It was my job to deal with the students and help them with problems. They would drop by a couple of times a day during the semester. If I had to sit down and do some coding or write some documentation, it was often very difficult to do during the day. If I've got to sit down and put my blinders on to do something, I need some time to get into it. Once I'm there, then I'm going to do it until it is done. Sometimes I would come in on weekends and spend a whole afternoon working. We also wouldn't realize how hard it would be to do a particular task. We would underestimate the time it would take. I would think I could get a module description done in 2 hours, and ten hours later I would have had to dig through 8 books to figure out why a theory said something. Or I would think, "I got it done in a week last time." I would forget that I got it done in a week because I stayed awake the whole time. It jus
t doesn't sink in that it was a really horrible week!
These development patterns are also characteristic of task involved motivational states. This task involved character of developers during the development may have been due to intrinsic motivation they felt towards the project. There are widespread implications if the developer's work patterns were a result of internal motivation as well as the cognitive demands of the tasks. One set of significant implications involved the amount of ownership for courseware felt by developers. Credit giving and respect factors come into play, and the effects of appropriation and ownership were important for both learners and developers. In the following passage, Schlusselberg (personal interview, October 1, 1992) confirms the importance of motivational issues, and elaborates on the ways they can impact projects.
Schlusselberg: There are many things which affect the end product. People are the most important thing. It really depends with whom your working, and sometimes it boils down to personalities. If people are not happy working together, it effects the project. It's important that people working together respect each other's interests and see each other as professionals. Some people think that because they were able to secure the funding that their ideas are worth more. In the Center, although there are organizational hierarchies, we try not to have them influence the way we work. So ideas are discussed. I also think that implementation people are very important. If they are not there, the project does not move. However, their contribution and influence is sometimes overlooked. You must give credit to the person with the idea, particularly in a research environment. I think that what sometimes happens in an academic setting where the hierarchy is made up of faculty members, doctoral students, master deg
ree students and undergraduates, the top levels absorb a lot of the credit from the lower levels. So when I work with students, I make sure that their work gets acknowledged. I let them present their own work, which lets them take pride in what they do. Some people can use the analogy of a book where the author and the publisher get the credit. But I think movies are a better comparison where everybody who had anything to do with the movie get their name listed in the credits
Financial Resources. Financial resources provided an opportunity for the initiation of courseware projects. Even a few resources could ignite well conceptualized projects that were founded in both the broader experience of a discipline and ways the advanced computing technology could uniquely address existing needs. Initial financial resources provided for development equipment and graduate support. At that point, well conceived projects "took root."
The initiating source of funding for the ESCAPE project was a Creative Undergraduate Instructional Grant from the Purdue Dean's Club and Engineering Student Council. The following is a description of the late phases of conceptualization of the ESCAPE project. What is key to note is the way in which resources influenced the nature of the project that was finally created, compared to what would have been created if much resources were available (S. Ward, personal interview, June 22, 1992):
Ward: We started out in 1988. At that point in time, HyperCard was new, and Macintoshes had only been available for a short 6 months. When Bill LeBold realized he had something that was not a traditional programming tool, he saw extensive possibilities. He had the idea of developing an Engineering Information System similar to Discover. But he wanted to go beyond an Information System. He wanted to incorporate a scheduling system. He was also hoping to incorporate our Purdue Interest Questionnaire, and a multitude of other things that were available across ten different systems at that point. So, we started out on a chalk board, and I used my knowledge of systems development to diagram what parts the project would encompass. We started calculating the storage and some of the physical requirements to incorporate the master plan. Then we saw that in order to incorporate the things that we could do, like the PIQ and the Academic record query, we were talking Gigabytes of data. Back in 1988, twenty meg
abytes was a lot of space. After doing that, we came back through a process of elimination, to what was technically possible, and financially doable. At that time, much of it was technically possible, but too extensive in terms of the amount of money, number of man hours, and equipment. So we pulled in our horns and looked at the unique properties of HyperCard and what we could do with that. In essence, we ended up with an information system. Then we asked, "What bits and pieces should we have?"
ESCAPE always functioned in a shoestring fashion with only periodic support from funds directly provided for development activities. At the Context32 project, development was supported by contracts from the IBM corporation and the Annenberg/ CPB Project. Additional development was funded by Apple Computer. Software as well as courseware was developed, so "making" Intermedia required the majority of the funds, while Context32 courseware development accounted for a percentage of the total funding. The degree to which this is the common reality on courseware projects associated with experimental hypermedia systems is reflected by Landow in the following passage:
The most significant literary hypermedia projects have been funded on an experimental basis by foundations and corporate sponsors, such as Annenberg/CPB Project, Apple Computers, and IBM for Intermedia and Context32 and the Annenberg /CPB Project for Perseus. Much of this support has gone into developing basic hypermedia programs: Intermedia required about 45 person years of programming to bring to its current stage of development. (Landow & Delany, 1991, p. 40)
In the early days of Athena, the issue of resources was resolved early in courseware projects, before production began. While it appears that the MIT and Brown projects received a large amount of support, it is important to remember that there was both software and courseware development taking place. Only a percentage of the funding was for actual courseware. The majority of funds were used to create the software that supported the courseware. The distinction is apparent in this description:
MIT enlisted International Business Machines (IBM) and Digital Equipment Corporation (DEC) as partners for a five year project. The two partners pledged to contribute a total of $50 million in equipment and maintenance, along with five staff members each. MIT pledged to raise $20 million to support the design and installation of the distributed computing system and curriculum development projects. Funding as made available for the first five years of Athena (1983-1988). Project grants ranged form $5000 to about $1 million, and overall, 125 projects were funded. The faculty were encouraged to be bold and creative, and $8 million was earmarked for salaries for faculty, students, and staff to develop courseware and new curricula. (Murman, 1989, p. 1-1)
Faculty members who wanted to use Athena as an integral part of their courses obtained funding and hardware from the Athena resource allocation committees. The faculty member would develop the pedagogical concept and lay out the general functionality of the software (Champine, 1991). After conceptualization and initial creation were successful, funds were needed to cultivate the project on a long term basis. Seed funds without provision for cultivation later resulted in the discontinuation of projects in a majority of cases. When the initial funding that provided the impetus for the creation of the courseware ran out, projects often ended, and courseware fell into disuse. To continue being viable, courseware needed to be used and updated. To obtain funding to continue the project on a continuing basis, the project managers needed to address efficiency and effectiveness considerations. This will need to continue to be the predominant concern of educators in the future, if the projects are to attain fu
nds through the decisions of administrators with an eye to the issues of cost (T. Putnam, personal interview, July 30, 1992):
Putnam: We get fascinated with the medium, and the whole problem is the means become the end. Then you end up with lots of technologically knowledgeable people, who are proselytizing their particular religion which is, "hey, we can do this on computers and it's interactive and individualized and multimedia, and" Wait a minute, did we ask the important questions? "Did this in fact substantially improve the delivery of education. "Did the student learn more as a result of this enormous expense we went to?" Did we, in fact, do a better job?" And in fact, it is possible to do a better job, and in theory it is possible to do some things that you couldn't do with a textbook or standing in a classroom or a lecture environment. But, I think what ends up happening all to often, is that we get fascinated with technology, and nobody asks the question, "Was this worth it in the first place?" For example, there are a lot of good things we can do given time, and money, and people, and intellect, and things like tha
t. The problem is we never have enough time, money, people, or intellect to do all of these things which can be done. So at some point, if somebody is in a position where they are trying to make decisions about what's strategically important, they don't try to do everything. They pick those things which have a big payoff for the investment dollars, and they invest in those.
While obtaining initial funding to move from conceptualization to creation was relatively common, gaining resources for continuation of courseware projects was the challenge. This may be an important reality behind successful projects. Faculty who conceptualized successful courseware projects emphasized ways in which the computer could simultaneously serve multiple goals that were unattainable or less cost effective with more traditional methods. Their rationales helped them to receive resources that were critical to sustain courseware. They obtained funding through demonstrations that courseware provided opportunities that were indispensable and not able to be provided in any other more cost effective way.
The Impact of the Organizational Contexts
Successful courseware initiatives found ways to balance their educational and technical requirements with their organizational considerations. Attempts to reach unique discipline and learner oriented goals afforded by new computing capabilities led to unforeseen technical challenges and became intertwined with issues related to traditional organizational structures for distributing and managing human, technological, and financial resources. When educational decisions presented technical challenges, successful projects developed organizational structures to address the challenges. It was particularly essential that project directors developed organizational structures to provide for the continuation of resources so that the project could be delivered and maintained on a regular basis. The types of organizational structures which evolved to provide for the continuation of resources depended upon the cultivation of linkages between traditional organizational structures. There were three structures of cour
seware teams that were identified that successfully provided for this linkage and the resulting continuation of projects. An overview of the types of organizational structures and the relationships among them are shown in Table 7 (see Table 7). Tasks that originated from the academic nature of the projects were performed by people closely associated with academic organizations. Tasks that originated from the technical nature of projects were done by people who had relationships with the computing organization. The implication is that people who serve on courseware teams were defined in terms of their relationship to organizations.
When a faculty member took the majority of the responsibility for the creation of courseware, he or she was classified as an author or a creator. When a person like a graduate student, who was neither faculty or a member of the computing organization, took major responsibility for watching over and organizing the creation of software after the initiation, conceptualization and acquisition of resources have taken place, the role was described as an integrator. Finally, sometimes independent organizations emerged which were neither an academic departments, nor a part of the main computing organizations. When a person from such an organization took responsibility for more than one courseware creation, this was referred to as orchestration. This structure emerged when the organization was also engaged in the creation of the software tools as well as courseware support. The following analysis will provide explorations of how these less traditional approaches to describing team roles developed out o
f distinct
patterns of time and motivation constraints.
Table 7 Types of Organizational Structures and Their Relationships
The Creator Structure. The first type of organization structure centered around a key faculty member who managed the project themselves. This organizational structure was similar to traditional classroom support structures in academic environments. It was relatively inexpensive to support courseware financially within this structure, and it also implicitly most likely to obtain the needed informational resources. The source of technical resources and knowledge was a recognized obstacle frequently associated with this type of structure. In addition to the possession of a well developed vision about the goals prior to beginning the courseware project, there was agreement among participants that a grasp of the "limitations of the technology" was a valuable attribute in the faculty who initiated courseware projects themselves. It was often necessary for faculty members in these projects to personally establish a tight linkage between themselves and the local computing organizations. This need for close c
ooperation of the faculty member with the computing organization was particularly prevalent as projects moved further away from typical academic endeavors, to ones that required more technical expertise. The sources of technical expertise, communication about technical issues, and development team composition were elaborated in a discussion with Lawler (personal interview, July 20, 1992):
Lawler: About those roles: There has to be someone who is called a liaison between different areas of concerns, on the one hand technical and other more content oriented. What are the most important issues between the different levels of competence in the technical area and the content area.
Hopper: Let me provide a metaphor from my literature experiences that I use to conceptualize these issues for myself. There is a 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 cases where they are presented as alter egos or foils, to finally where they are incorporated into a single role 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. 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 a problem. When there is a chain of people, it requires more effort to communicate, and more resources to support. I think it's a possible 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 too.
The technical issues and the time consuming nature of development required faculty who managed courseware projects to devote a large percentage of time to the endeavor. They implicitly adopted educational computing among their areas of professional concern. One project that represented this structure was Context32, in which Landow was the lead person responsible for the overall development. In the following description, Kahn (personal interview, March 2, 1992) remarked about the structure of the courseware team, and the fact that this structure was exceptional:
Kahn: The system always lended itself to working in small teams, from say two to five people on a course. George Landow initially had three graduate students, as well as himself, and generally ended up with a couple of kind of lead undergraduates each semester. In some cases he managed with one graduate student, or in some cases no graduate students, but he is extraordinary in the sense of the amount of time and interest he has for devoting to the system.
There were other members of the team, but the key person was the faculty member. He was the only one who retained continuous involvement. This structure is as rare in academic institutions as the faculty who are willing to participate. The inherently limited nature of this organizational structure is simple to explain relative to the organizational contexts of academic institutions given the consuming nature of courseware development . Most faculty in universities and colleges are in one of two situations. They are either tenured faculty like Landow, or they are non-tenured faculty who are trying to obtain tenure. Senior faculty often have a high degree of responsibility that resulted from their efforts to attain tenure. Non-tenured faculty must try to take on more responsibility to obtain tenure, or they will not remain at their institutions for long (Landow and Delany, 1991, Champine, 1991). Landow has pointed out in publications a number of additional issues that hinder faculty from personally c
reating courseware. He has been especially sensitive to the limitations inherent in creating courseware for a single course:
For a hypertext system such as Context32 to achieve anything approaching its full potential, it cannot remain course-specific. In fact, although IRIS and the English Department received support from the Annenberg/CPB Project specifically to create materials for English 32, during the Autumn, 1987, I already used it for English 61, Victorian Poetry, and (to a lesser degree) for English 137, Anglo-American Non-Fiction, a course covering writers from Swift and Johnson to Didion and Chatwin. The next term, when I again used Context32 to support the survey course for which it was originally designed, I also used it for a graduate seminar in Victorian poetry, and (moving from freshman students of English to advanced graduate students of the same field) several have used it to prepare for the examinations that precede the doctoral dissertation. Context32 now needs to extend beyond my courses and indeed beyond those taught by the Department of English to History, Classics, Art History, and other disciplines, all o
f whose materials could support one another. (Landow, 1989a, p. 193)
Landow has thus suggested a way that faculty created courseware can evolve to serve the needs of multiple courses across departments in different situations. Bucciarelli (personal interview, June 23, 1992) expressed additional insights about sustaining the "creator" structure of courseware production within the constraints of academic organizations:
Bucciarelli: I found it interesting to do. I was trying to do it in real time, I didn't have any student support. I spent roughly 25 hours a week on this. It was an experiment about whether it's possible to do this in real time. I think the classic notion of the production of computer aided instructional software is that somebody develops it over here, like a textbook, and then someone else adopts that package and uses it in their course. Well, I think that's the wrong model for this. That's not going to work. What ought to be available are the tools for faculty to develop their own lecture notes, problem set solutions, quizzes, review, interactive sections, interfaces with laboratory experiments, overhead projections, and dynamic demonstrations for lecture. What the resources should be are the programming tools and programming environment, and that those are to be portable across all systems, and the level of platform you need ought not to be more than a 386 or its equivalent. These are the tools th
at ought to be available to faculty and teaching assistants, so that they can develop in real time. And then they can develop a body of materials like lecture notes that are stored electronically and are easily adapted to different circumstances. That's different than producing a package and marketing it. Another point I make is that if your model is the textbook, then you need expert programmers that can produce the equivalent of a text, which is well tested and has all the bugs out. If that's your model, then you need a lot of resources. On the other hand, if you accept my model for what you should be doing, then resources don't become a problem. What are the resources you need? It's your own time, or it's a teaching assistant's time. If you don't take that route, it's not going to make it, because the resources aren't there. If the resources become the question, then it's not going to happen.
The Integrator Structure. The limitations of the "creator" structure lead to the next organizational structure of courseware teams. This structure was characterized by a role that was consistently referred to by the term "integrator" during interviews. The role of "integrator" was defined by what it was not as much as by what it was. "Integrators" were team members who took a large part of the responsibility for the development of courseware, but were neither faculty, nor members of the main computing organization in the university. The general relationship between the "integrators" and the faculty who began the projects can be described as "partnerships." Integrators were often graduate students with expertise in both the discipline and computing. This model was similar to the organizational structures traditionally used to support lab courses, and was the most commonly used across the institutions and projects studied during this research. Just like lab courses, this model was financially challeng
ing and thus was limited in the same ways as lab structures in traditional academic settings.
The first example of a project which employed this organizational structure is the ESCAPE project. The faculty member who initiated and managed this project is a senior tenured faculty member who plays a major role in a number of activities in the department and university of which he is a part. This brings with it a great deal of responsibility which functioned as a limitation of human resources that led to the "integrator" structure (W. LeBold, personal interview, July 2, 1992. During an interview with LeBold (personal interview, July 2, 1992), the term "integrator" was used to refer to the type of role that developed:
LeBold: We recognized that a need to develop an Engineering Career System for Engineering students and graduates. We also recognized the potential of interactive computerized systems to provide the types of career information needed. We also recognized that existing computerized career information systems did not provide the detailed information that engineers need. We also felt that the linking and indexing systems available in HyperCard and the User-Friendly nature of the Macintosh provided a fertile area for experimentation. In addition, there is a real need for what I call integrators, and there aren't very many people who do that job. You've got a lot of people who are specialists in developing detailed technologies and are doing their own thing, but there are not too many integrating people, with fingers in lots of pies, and who are able to tap into all kinds of things. But that's the solution. We need to be able to have more integrators. Whether that will be the future instructiona
l designer
, or whatever they are going to be called. But, I also think it's going to have to include people with significant knowledge in subject matter areas, as well as people who are knowledgeable about the emerging computer information technologies. And they're going to have to have resources available to them. Resources include personnel, equipment, space and adequate funding. We managed to do quite a bit with rather minimal resources, but it required a longer period of time, as well as personal sacrifice and commitment. In retrospect the time was a plus because newer, more accessible and less expensive hardware, software, and networking became available and made our aspirations more feasible and less frustrating.
As technical issues increased, the "integrator's" role expanded to require not only the traditional academic tasks of information organization, presentation, writing and publication, but also technical skills in interface design and elementary programming. Eventually even more technical expertise and "Knowledge of technical limitations" needed to reside within the project team. It was also helpful if the person with the expertise had established credibility and active cooperation with the main campus computing organization. This lead to the need to develop an informal "Liaison" role within the integrator structure. Tillotson served in this role during the ESCAPE restructuring and cross platform development activities. His involvement with ESCAPE actually began as a consequence of his employment as a Purdue Computing Center Consultant. Out of his own curiosity, he would informally observe the class during presentations, and then explore the HyperCard stacks after the class had met. As it became apparen
t that more technical expertise was needed on the project, he became a candidate because of the knowledge and interest he had casually displayed during informal conversations. After his employment, and with hindsight it is obvious 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. 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 definition of the Integrator and Liaison roles also involved 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 to establish how this could be translated into a format that would transfer smoothly between platforms. Similar organizational structures were commonly found supporting courseware projects at Athena. The following describes the most common situation during the Athena project:
The faculty member would develop the pedagogical concept and lay out the general functionality of the software. Students or professional staff hired for the task usually did the actual programming, although in some instances the programming was part of a thesis project. (Champine, 1991, p. 73)
These issues were addressed over the history of the TODOR project. Besides LaVin, and Murman, there was another critical member of the 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, she eventually took on the formal role of faculty liaison at Athena. This happened after it became apparent to many inside Athena that there were special user support issues that needed to be addressed in distributed computing environments. 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. The 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 whom 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.
In projects with an integrator oriented organizational structure, also evolved methods of continuation that resembled traditional lab situations. The universities in which the projects developed recognized and supported them in similar ways as well. The following passage shows how Athena grew to define user support in their advanced academic computing environment. This description represents an organizational structure where "integrator" oriented teams will probably predominate:
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)
While a university might provide initial funding for courseware within this structure, it was more likely to provide the raw computing resources. Unfortunately, just as departments differ in the degree to which they can support lab courses, so they differ in the degree to which they can technically and financially support courseware projects that serve as a resource for departments.
The Orchestrator Structure. It was through the limited financial and technical nature of the organizational structures surrounding integrators that the orchestrator structure evolved. This structure involved the formation of a third organization specifically designed to support courseware creation and delivery. This was the least like traditional academic structures and was a symptom that courseware development was outside of the traditional mission of existing organizations within educational institutions. The orchestration structure successfully obtained resources outside of traditional mechanisms, but faced the challenge of trying to achieve linkages back to the more traditional academic and computing organizations.
Two organizations were characterized by this structure within this study. The first was the Information and Research in Information Scholarship (IRIS) organization at Brown which developed Intermedia. The second was the Center for Educational Computing Initiatives (CECI) which created AthenaMuse and worked with the Geology Tutor Project. The orchestration team structure was designed to provide support for many courseware projects instead of just one. In the following passages, Davis (personal interview, December 8, 1992), Manager of CECI describes the conditions that surround this structure and his own role within the structure:
Davis: The traditional way to build projects in industry was to write a brief abstract of what the goals and objectives are, build a flow chart of your imagined path through the materials, build story boards for the interface design, and then have a meeting and say, "the deadline for this is one year from now, so you do this and you do this." That's the industry model. But that process falls apart in academia. An important variable in an academic model is local culture. How does your academic organization actually operate, and what are the dynamics of the politics, the funding, the rivalries, the resources and the personalities? There are things that you cannot control as you can in industry, where you can fire somebody if they're not producing the story board. In academia, it's more of a collaborative effort, which requires a lot of latitude. You have to focus on what people are really good at, and what people have time to do. Because in academia, you are doing something that is not in the charter o
f the institution. Nothing is budgeted to do this, and the technology itself has effects, as Athena proved. No one said that it was going to cause a convulsion in the way the institute does it's educational business. But it does, and the repercussions of that are just beginning to be understood.
My function was coordinating among the faculty, the software design people, and the people who wanted to work on interfaces. I would go around, between them, constantly. My training for it was having taught in an Art school, where the process of teaching visual thinking is to work with people, give them skills, have them use the skills on actual things like video tapes or photographs, evaluate those things, and then have them make other things. Also it was important to have the ability to work with creative people's personalities.
Hopper: You've been involved in projects that incorporate the digital media that you're going to see in the near future on a common basis. Will a team be important for these projects?
Davis: So far I haven't met anybody who knows how to do it all. It's almost too much. To know about text, graphics, animation, video, color composition, interactivity, and all the other things too.
Hopper: Why is it too much?
Davis: I think it's just too big of an integration. Ultimately, it is also not as interesting as working with a group. It's as if the Beatles was all John Lennon. He wasn't the Beatles. It's more than the sum of its parts. That's what orchestration is about.
Hopper: Part of orchestration then is not just the media, but the people involved, and how to orchestrate their particular skills, talents, and abilities into something that is complimentary.
Davis: Absolutely. The team has to be people who are interested in everything. The core people have to be interested in how the video works, how the interface works, how the software works, what the content is. They're interested in the connections between things as much as they are the things.
In the orchestrator organizational structure, there were still people who held the roles of "creators" and "integrators" for specific courseware projects. These were the points at which the academic, technical, and "orchestration" organizations met. In the Geology Tutor Project, Schlusselberg filled the role of integrator at the beginning of the project. A particularly dynamic aspect of the "orchestration" structure was the way in which roles evolved and shifted. The aspect that contributed to this was the socialization which took place with new members of the structure. In the beginning Schlusselberg began as an integrator, who received a part of her preparation for the role through socialization and sharing among the community in her organization (E. Schlusselberg, personal interview, October 1, 1992):
Schlusselberg: I learned how to use the authoring system by looking at what other people had done with it. And there were many times when I would go to people and say, "Hey, I've got a quick question." When I first came I saw all the cables and thought, "What are all these cables for?" But, as I saw people trouble-shooting and putting things together I would think, "Oh, I see." Then I would try and do it myself. You get to the point where you need to know things, like how things are connected to each other. You want to learn because you feel bad asking someone how to do the same thing 29 times. The other reason is that we have a demonstration room where we do presentations. People always switch the cables, and when you're planning on a doing a presentation you better know how to get the machines to work again. It's something that you need to know. You pick it up, because you need it.
The role of integrator and the skills required for the role were passed from Schlusselberg to Kinnicutt who now serves as the integrator for the Geology Tutor courseware project. His role evolved gradually. Before he worked on the project, there was another graduate student who worked on the Geology Tutor project. Kinnicutt was an undergraduate, when he first began working on the project, and he worked with the previous graduate student. When he graduated, he became first a M.S., and then eventually a Ph.D. student. As he went from undergraduate to graduate school and took on the role of integrator, he maintained close contact with CECI. Initially he worked with Schlusselberg to learn the about the software. When he became more experienced, he took on increasing responsibility for the Geology Tutor project.
The "orchestration" support structure for courseware projects also contained more provisions for providing technical support. This alleviated some of the need for forming tight linkages between the courseware team and the campus computing organization. The director of CECI, Lerman (personal interview, March 4, 1992) described the 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 description, it was clear that CECI provided extensive technical support for courseware projects. This resulted in less of an emphasis on the need for extensive technical knowledge to reside in the faculty member because some of the requirements for successful projects can be found within the staff of his own organization. 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.
In organizations where a separate organizational structure formed and was supported by an "orchestration" approach to team construction, a different structure evolved to provide continuation. The organizational structure which evolved to provide for the continuation of this courseware appears to be designed to provide for its own renewal of resources, without relying upon university or external funding. This model is represented by the structure which evolved within CECI which is currently in the process of creating AthenaMuse 2, as well as cooperating in the production of the evolving Geology Tutor project. The general model of continuation for the orchestration model of courseware team structure is described below by Davis (personal interview, December 8, 1992), Manager of CECI:
Davis: We're only beginning to understand the process, having done it by falling down and getting up, and trying to step back occasionally to see what's worked and what hasn't. We've come out of the project Athena model, where everything was basically paid for by two sponsors, into a new thing, called CECI, where we actually do fund raising. One aspect of fund raising is to show people new things.
I've divided time here between four areas, problem solving, tactical behavior, creative behavior, and miscellaneous activities, and it's a loop. Basically problem solving is the research we get paid to do. The tactical part of it is how do you do demos, and generate new projects.
Then the creative part is the part that absolutely has to be there, in order to get back to the beginning of the process. You have to have new ideas to get new income. It's been our experience here, that when we begin having ideas, our loop is closed, and we're creating again. We take new ideas, and we incorporate them somewhere else. So that's how the wheel turns. You have to be doing something. The big frustration here is when we don't have any new demos. So we encourage people here to make things themselves, that may not be for any course, or teacher, but just some little thing that they have played with, that we can all look at, or show. Prototyping is really key. We've been talking lately about a prototyping fund, where people in the group can come and say, "Look, I have an idea about plants. I would like to do a little thing." Everybody has to be an artist of some kind. They have to have the confidence in their creative abilities, they have to come up with new ideas, and defend tho
se ideas,
and prove those ideas while having them criticized, and so forth. It's confidence in your own inventiveness. You don't have to know how to draw, or be the traditional artist activities, but you have to have the confidence to say, "This idea goes with this idea, and this is why."
Miscellaneous activities means that you're willing to help move the video recorder where it needs to go, you're willing to do anything that precipitates the other three things. It's essential that nobody in the group says, "Gee, I don't move furniture." Another thing that makes the wheel turn is a sense of mission about the product. That people really are interested in improving education, or making learning exciting. So they do whatever it takes to get that condition.
Then what is interesting about this technology is, once you show a teacher that doesn't do this, models all in one place on a screen, you are immediately teaching them what needs to be done. It's an incredible sales tool. They go, "Oh, I know what I should do now, because this is more interesting than what I've been doing." Sometimes we get people in who think they just ought to keep up with what's going on in education. But then, within 15 minutes, they are going, "you know what else you could put in there." And once you've done that, you' have triggered their imagination. The demonstration has done its job, and they are different teachers. So it works. That's the interesting thing about us doing demonstrations for people. The minute the client or the teacher you're doing the demonstration for begins designing, by going, "Oh, I could use this for my project I'm doing." You've done it. That is how it goes. It's been our experience here, that when they begin having ideas, that our loop is closed, an
d we are creating again. We take these ideas, that's a good idea, we'll incorporate that somewhere else. So that's how the wheel turns.
The orchestration structure described above obtained new resources and projects within a cyclic process. The organization was not built around just one project. It was based on a continual re-invigorating of the environment with new ideas and new projects and new people. The Geology Tutor project is to be a part of this cycle. The CECI Athena Muse 2 team is working with the courseware team to their mutual benefit. Part of the strength of the orchestration team structure is that it relies upon the departmentally based courseware project to provide the content and some human resources, while the presence of the independent support organization for the endeavor helps insure help in obtaining technical and financial resources and support from time to time. The mutually beneficial relationships residing in this division of labor are the strongest foundations of the orchestration organizational structure.
The Learner Construction Structure. It is essential to note the ironic role that students can play in the growth of courseware in each of the previously described courseware team organizational structures. The same motivation and work patterns that were a problem for faculty, became a strength when viewed in the context of learner's construction of their own courseware. When materials were constructed by students within the context of a course, or outside the context of the course and within the bounds of the team, it was both beneficial for the students and good for the project.
For example, Context32 grew during the use of the system because of a learner constructed approach. A large part of the current materials (perhaps 90% of 500 documents) were written by students. Landow's direct supervision of the students was limited to copy-editing their essays and rejecting materials that did not meet basic standards. The assignments Landow used were specifically designed to achieve learner and discipline oriented outcomes, while contributing to the growth of the project as well:
The assignments Landow gives his students are carefully designed to produce short essays that will be valuable additions to the web. For instance, an assignment given very early in the semester asks that the students choose a short passage from two of the novels read in the course, and use these passages to compare some aspect of literary technique. The second part of the assignment is to choose a different passage from a different novel and use it to write an essay on contextual information. (Kahn and Launhardt, 1991, p. 7)
The assignment was designed to inspire insight into how the books read related to one another. While these were the discipline oriented goals of the assignment, it was also through the same assignment that deeper learner oriented goals were achieved. The assignment increased learner involvement, and through that involvement, cognitive skills and motivation were also improved (Landow, 1989b). The degree to which Landow (personal interview, March 2, 1992) believes that it is important for students to use the system within a self-constructive framework, is reflected in the following passage:
Hopper: You use a collaborative approach in which students build Context32. How different do you think the future of these kinds of systems in education will be, if you have professionals develop this for students, rather than having the students develop it themselves?
Landow: That depends upon what you want. If you want to convey information, that is essentially conceived of and perceived as, "Known by big people," then you have professionals do it. In contrast, if you wish to have students learn both the information and the philosophical goals, then you have the students do it. It's a very large difference.
Similar benefits may have resulted from student involvement in the construction of TODOR, which was staffed by students in the Undergraduate Research Opportunity Program at MIT (UROPs). Learners constructing their own materials was a trend that was supported and encouraged through the selection of particular characteristics of software. CECI designed AthenaMuse 2 to be easy enough to use that learners could construct their own material (B. Davis, personal interview, December 8, 1992):
Davis: The professor is going to do this with his students. There's the complete team. That's what we're interested in. We help the teacher create something, then the students use it, and they change it. They teach the teacher something. This is my model of a good teacher. You learn from your students, and if the students are engaged enough to change the textbook, they're really learning.
Hopper: But will that change your role then, if it moves to where the instructor's having the students use it?
Davis: Hopefully. We don't want to do the same thing forever.
Hopper: So you prepare it for the teachers, and then you start new projects. So you make seed projects then?
Davis: Well, in a sense, yes. We can't make everything for everybody. The intention is to get that mechanism moving.
Hopper: Will your authoring tools then have a gentle enough slope to help support that kind of activity?
Davis: Yes. That's the intention. We try to use that model as a way to construct the authoring language, so it would be easy enough for anybody to use at whatever level. We've designed it so you can use the top level graphical tools, the middle level text, or code C++ , or you can move all the way into UNIX.
The activities that learners performed and their relationship to the organizations involved tended to vary according to the type of software function emphasized. When microworlds were constructed, students tended to serve in roles of programming. These tasks tended to bring them in fairly close association with the computing organization that supported the courseware project. On the other hand, when courseware emphasized databases of linked text, graphics, or multimedia, learners tended to fill the role of developers and were more closely associated with the academic organization which supported the courseware project.
------
Organizational Contexts of Future Courseware Projects
The descriptions of organizational issues developed during this research provides a foundation upon which to base future investigations. Much work remains to be done to gain more detailed descriptions of the operations, strengths and limitations of different organizational structures which evolve to support courseware. This will be particularly important as computing technology and software evolve to allow for richer and more complex representations. The increasing integration and expansion of software functionality makes it necessary for the role of authors to undergo a significant shift because they are called upon to provide for the maintenance of the complex learning environments or "virtual worlds" they construct. Authors are now charged with building virtual worlds, creating tools for the worlds they create, and then finding ways to get their friends or learners into the world they have constructed (Hodges, 1991). In complex distributed computing environments, the "virtual worlds" created by cour
seware authors need to continue to evolve in order to be maintained over a significant period of time. Courseware developers in rich learning environments must recast their endeavors as both managers of the rich computational virtual worlds they construct, and the external resources upon which the continued existence of the worlds depend. This represents a significant redefinition of the roles of authors relative to traditional definitions.
Timing, Tasks and Role of Future Courseware Projects
Over the history of educational computing, there has been an emphasis on the importance of formal procedures to coordinate, communicate and plan the educational and technical nature of projects. Processes are generally described as a series of stages, which begin with steps that revolve around planning. The actual development takes place rather late in the process, and the fate of the project after development is dealt with through cursory statements about planning for maintenance, evaluation and revision. Even in cases were a cycle is implied, the stages are still represented in a linear format with some provisions for feedback. Perhaps these processes do produce courseware, but they do not describe the organizational contexts of successful courseware projects that were the subject of this research. There were only three stages or states that could be identified during courseware projects.
The first state was conceptualization, which occurred before any type of software existed. The prerequisite conditions for courseware creation was the presence of a faculty member with a well developed vision of education based upon strong discipline and learner oriented goals. It appeared helpful that the faculty member also had a grasp of the limitations of the technology and the wish to express their vision through computer courseware. Resources provided an opportunity to make projects which had been conceptualized beforehand. The two most important resources for the initial creation of courseware appeared to be human and technical resources. Equipment was also needed to develop the courseware, and staff were required to begin the project.
When resources became available, courseware projects entered an active second state in which they were developed through an event driven cycle. Courseware creation was done by teams. The most obvious and traditional way to characterize the teams was with function oriented types of descriptions based on the tasks they performed with different types of software. It will be important to devote more resources to exploring the complex dynamics of courseware teams. This could be a subtle factor which can make or break successful creation and continuation of projects. An important way to define roles is by the way they relate to the organizations involved. Needed skills and the less obvious time, motivation, and "linkage" factors should be considered when choosing team members for courseware projects. In the organizations in this study, courseware developers did not feel the need for formal instructional design methods, nor did they tend to use them. The majority of processes were very informal.
When for
mal products like assignments, manuals, or written documentation were created, they evolved from the requirements implicit in events, rather than by a general need for them during design.
Courseware creation involved creating the conditions through which courseware could be implemented on a regular basis. The task was to set up the organizational conditions to maintain the continuation of needed resources. This then lead to continuation, which was a third phase of courseware projects. Projects in this state were very similar to projects during creation. They were characterized by stable and ongoing event driven efforts to continue the delivery and maintenance of successful courseware through the continual provision of resources of various types.
Resources as Limitations and Opportunities for Future Courseware Projects
The acquisition of resources has often been treated as a prerequisite to courseware creation, rather than a continuous need. This research revealed that resources were directly related to limitations experienced early in a project and continued to play a major role for as long as the courseware continued to be delivered. Educational computing initiatives can only thrive on a long term basis in communities marked by the cohesion and cooperation required to support such complex, interdisciplinary, and long term endeavors. The dilemma is to find ways both inside and outside of traditional structures to overcome the inherent lack of existing support structures for courseware development.
The Impact of the Organizational Contexts on Future Courseware Projects
The continuation and expansion of courseware beyond its initial funding depended upon a structure evolving to obtain resources, while overcoming the limitations inherent in the organizational structures surrounding the project. This leads to a reinterpretation of courseware authoring as a process of establishing an ongoing system for obtaining and managing informational, technical, human and financial resources. Three organizational models developed to support these processes, and their nature was dependent upon the organizational structure that existed during the software's creation.
In cases where resources and motivation are present, courseware may be supported within traditional academic structures by making provisions for departmental facilities to support local courseware development and delivery. These can be staffed by "integrators" and groups with "linkage" to traditional academic and computing organizations. When academic departments and computing organizations do not have sufficient informational, technical, financial and human resources available to support long term continuation of large scale courseware efforts, it may also be beneficial to consider a third independent organization closely integrated into the campus involved in both software design and courseware creation. Support from multiple computing companies might be feasible as a mutual service to the companies who gain a good setting to experiment with software, while educational institutions get both the immediate benefit of their presence, and the long term benefit of more appropriate software.
Projects in this study sometimes included provisions which changed both the roles of learner and author relative to the courseware. Learners became authors, while the roles of the key members of courseware teams changed from authors to learning environment managers, or "knowledge ecologists". In the future, it will be valuable to consider the mutually beneficial roles which learners can play within learning environment or "virtual world" production.
Organizational Contexts of Future Courseware Projects
The descriptions of organizational issues developed during this research provides a foundation upon which to base future investigations. Much work remains to be done to gain more detailed descriptions of the operations, strengths and limitations of different organizational structures which evolve to support courseware. This will be particularly important as computing technology and software evolve to allow for richer and more complex representations. The increasing integration and expansion of software functionality makes it necessary for the role of authors to undergo a significant shift because they are called upon to provide for the maintenance of the complex learning environments or "virtual worlds" they construct. Authors are now charged with building virtual worlds, creating tools for the worlds they create, and then finding ways to get their friends or learners into the world they have constructed (Hodges, 1991). In complex distributed computing environments, the "virtual worlds" creat
ed by cour
seware authors need to continue to evolve in order to be maintained over a significant period of time. Courseware developers in rich learning environments must recast their endeavors as both managers of the rich computational virtual worlds they construct, and the external resources upon which the continued existence of the worlds depend. This represents a significant redefinition of the roles of authors relative to traditional definitions.
Timing, Tasks and Role of Future Courseware Projects
Over the history of educational computing, there has been an emphasis on the importance of formal procedures to coordinate, communicate and plan the educational and technical nature of projects. Processes are generally described as a series of stages, which begin with steps that revolve around planning. The actual development takes place rather late in the process, and the fate of the project after development is dealt with through cursory statements about planning for maintenance, evaluation and revision. Even in cases were a cycle is implied, the stages are still represented in a linear format with some provisions for feedback. Perhaps these processes do produce courseware, but they do not describe the organizational contexts of successful courseware projects that were the subject of this research. There were only three stages or states that could be identified during courseware projects.
The first state was conceptualization, which occurred before any type of software existed. The prerequisite conditions for courseware creation was the presence of a faculty member with a well developed vision of education based upon strong discipline and learner oriented goals. It appeared helpful that the faculty member also had a grasp of the limitations of the technology and the wish to express their vision through computer courseware. Resources provided an opportunity to make projects which had been conceptualized beforehand. The two most important resources for the initial creation of courseware appeared to be human and technical resources. Equipment was also needed to develop the courseware, and staff were required to begin the project.
When resources became available, courseware projects entered an active second state in which they were developed through an event driven cycle. Courseware creation was done by teams. The most obvious and traditional way to characterize the teams was with function oriented types of descriptions based on the tasks they performed with different types of software. It will be important to devote more resources to exploring the complex dynamics of courseware teams. This could be a subtle factor which can make or break successful creation and continuation of projects. An important way to define roles is by the way they relate to the organizations involved. Needed skills and the less obvious time, motivation, and "linkage" factors should be considered when choosing team members for courseware projects. In the organizations in this study, courseware developers did not feel the need for formal instructional design methods, nor did they tend to use them. The majority of processes were very informal.
When formal products like assignments, manuals, or written documentation were created, they evolved from the requirements implicit in events, rather than by a general need for them during design.
Courseware creation involved creating the conditions through which courseware could be implemented on a regular basis. The task was to set up the organizational conditions to maintain the continuation of needed resources. This then lead to continuation, which was a third phase of courseware projects. Projects in this state were very similar to projects during creation. They were characterized by stable and ongoing event driven efforts to continue the delivery and maintenance of successful courseware through the continual provision of resources of various types.
Resources as Limitations and Opportunities for Future Courseware Projects
The acquisition of resources has often been treated as a prerequisite to courseware creation, rather than a continuous need. This research revealed that resources were directly related to limitations experienced early in a project and continued to play a major role for as long as the courseware continued to be delivered. Educational computing initiatives can only thrive on a long term basis in communities marked by the cohesion and cooperation required to support such complex, interdisciplinary, and long term endeavors. The dilemma is to find ways both inside and outside of traditional structures to overcome the inherent lack of existing support structures for courseware development.
The Impact of the Organizational Contexts on Future Courseware Projects
The continuation and expansion of courseware beyond its initial funding depended upon a structure evolving to obtain resources, while overcoming the limitations inherent in the organizational structures surrounding the project. This leads to a reinterpretation of courseware authoring as a process of establishing an ongoing system for obtaining and managing informational, technical, human and financial resources. Three organizational models developed to support these processes, and their nature was dependent upon the organizational structure that existed during the software's creation.
In cases where resources and motivation are present, courseware may be supported within traditional academic structures by making provisions for departmental facilities to support local courseware development and delivery. These can be staffed by "integrators" and groups with "linkage" to traditional academic and computing organizations. When academic departments and computing organizations do not have sufficient informational, technical, financial and human resources available to support long term continuation of large scale courseware efforts, it may also be beneficial to consider a third independent organization closely integrated into the campus involved in both software design and courseware creation. Support from multiple computing companies might be feasible as a mutual service to the companies who gain a good setting to experiment with software, while educational institutions get both the immediate benefit of their presence, and the long term benefit of more appropriate software.
Projects in this study sometimes included provisions which changed both the roles of learner and author relative to the courseware. Learners became authors, while the roles of the key members of courseware teams changed from authors to learning environment managers, or "knowledge ecologists". In the future, it will be valuable to consider the mutually beneficial roles which learners can play within learning environment or "virtual world" production.
|
AERA, 97
|
