[An expanded version of this document can be found in the following document upon which this article was based: Courseware Projects in Advanced Educational Computing Environments (CPIAECE): Chapter 4 Technical Contexts.]
|
The following projects, organizations and participants were the focus of this study:
Project: ESCAPE (HyperCard and HyperNews) Organizations: Educational Research and Information Systems (ERIS, Purdue) Participants: Hopper, Lawler, LeBold, Putnam, Rehwinkel, Tillotson, Ward Project: TODOR (BLOX) & Mechanics 2.01 (cT, Athena) Organizations: Athena and Academic Computing (AC, MIT) Participants: Bucciarelli, Daly, Jackson, Lavin, Schmidt Project: Physical Geology Tutor (AthenaMuse) Organizations: Center for Educational Computing Initiatives (CECI, MIT) Participants: Davis, Kinnicutt, Lerman, Schlusselberg Project: Context32 (Intermedia, StorySpace) Organizations: Institute for Research and Information Scholarship (IRIS, Brown) Participants: Kahn, Landow, Yankelovich [See the Switchboard for further information.] |
Interviews with 19 key participants and information from major documents were used to construct a description of the relationships between educational goals and important technical characteristics. In each project, the predominant reason for the choice of software was based on the need to access the particular set of functions perceived to be most congenial to representing a specific academic body of knowledge. The following are the main functions of computers which relate to improved representations of particular aspects of disciplines during this study:
While each project began with a primary emphasis upon the particular type of software function they needed for the type of data to be represented, each project was eventually also constrained by a set of convergences and circumstances related to the question, "How can the software be more usable?" Some courseware projects in this study arrived at their answer to this question for practical reasons, while others arrived at it for educational reasons, but they all ended up appreciating the importance of usable educational software from both the learner's and author's perspective.
Table 1: Functionality and "Usability"
In applications in which large databases of content were a concern, factors such as a consistent interface, or the availability of traditional database tools like search and query were sometimes emphasized. A particularly important attribute of Intermedia's design was its integration of applications for creating both documents and links at a very low system level. "Intermedia is not a separate application, but rather a framework for a collection of tools that allow authors to make links between standard types of documents created with heterogeneous applications" (Yankelovich, Meyrowitz & VanDam, 1985, p. 26). This decision greatly contributed to the usability of Intermedia, as evidenced by the large number of documents that were created by both the instructor and his students.
When project goals called for the inclusion of multi-media in the knowledge base, a number of unique usability issues emerged. These special needs combined with the need for improved authoring interfaces for high end workstations in distributed computing environments to serve as the main reasons for first the Visual Computing Group (VCG), and later the Center for Educational Computing Initiatives (CECI) to create the AthenaMuse authoring package. They identified a number of critical issues that pose challenges to those who wish to work with multimedia, that have not been a problem with more traditional formats:
Motion video and audio data are fundamentally different from text documents due to their temporal structure. Establishing cross-references that incorporate such data in a hypermedia system poses a number of challenges. It is possible to model video as a stream of individual frames, just as text can be modeled as a stream of individual characters. When video stops, a fixed image must be considered. Audio is different, however, for when it stops there is only silence; its meaning inheres in its change over time. (Hodges, Sasnett, & Ackerman, 1989, p. 38)
These differences in the nature of working with different forms of digital data were recognized before the creation of the AthenaMuse software, and were some of the major factors that drove the design of their multimedia control package. The creation of the "dimensions" as a critical component of their data model emerged because of the need to meet the challenge of manipulating and controlling various different multimedia formats within the same paradigm. In the passage below they summarize why their multi-dimensional data model was most apt for manipulating audio, video and text:
This turned out to be a "spatial model" that describes the dimensions of information space, and placement of items or documents within that framework. Under this approach, a document is constructed around an abstract dimension of time that can be displayed and manipulated as a time-line on screen. Each piece of video and each text subtitle can be mapped into this framework according to onset and offset times. (Hodges, Sasnett & Ackerman, 1989, p. 42)
Beyond their selection of a powerful data model to control multimedia, the AthenaMuse team also emphasized other attributes within the AthenaMuse software which should make it much more powerful and usable for multimedia and hypermedia production in the future. One attribute was the inclusion of "plastic editors" (Davis, Sasnett, & Hodges, 1989). This term refers to the ability to edit the editors themselves. This allows the editors to be customized and combined at need or used as part of the on-line documentation.
Projects which incorporated simulations to provide active illustrations of physcial phenomena faced somewhat different challenges to providing for efficient and effective interaction and creation by authors and students. The TODOR project successfully dealt with "usability" issues for creating interactive simulations quite early in the project's existence. The following passage provides a description of the reasons why "usability" of simulations from the students perspective were considered critical, and the way in which this issue was addressed in the first year of the project:
As our experiment progressed and experience grew, it became apparent that we needed some common user interface and format to our modules. Without this, students would be faced with many different conventions to learn for I/O and program flow. Development and maintenance of the software would be difficult to manage. We needed an interface which made multiple work areas, menu driven choices, and both static and dynamic graphics possible. The Athena supported, commercially available, interface BLOX was selected since it satisfied these needs and was compatible with FORTRAN, which most of the programs were written in. (Murman, 1987, p. 5)
The choice of BLOX turned out to be very helpful to the TODOR project for a wide variety of reasons including the common interface it provided for the project. It provided a productive way for students to interact that did not involve entering text into the machine. The experiences of the TODOR courseware project provided powerful insights into particular design decisions for simulations that tend to make learner interaction both easier and more productive. TODOR modules operated with an interactive interface which required little computer expertise to use. Input was generally via mouse activated menus and scales. Experience showed the developers that mouse input was preferable to keyboard input. It was not only easier, but less prone to inadvertent crashing of the program. For example, when numerical input was required, it was done from a scale, an integer menu, or a calculator icon. The overall effectiveness of the above approach is supported by a observation made later in a publication summarizing the TODOR experiences:
Since the overall limit in the use of modules is the time available for students and faculty to spend on a topic, increasing the productivity of the user interface translates directly into increased use of modules. Little effort is required to use the software, and the objective of teaching fluid mechanics, not computing has been achieved. (Murman, LaVin & Ellis, 1988, p.10)This is one example in which a distinction between user and author interface is clearly important. The author and user interfaces were separate in TODOR. Unfortunately, there was a discrepancy between the degree of "usability" that was able to be provided by the author for the user, and the "usability" of the interface which the author needed to use. The productivity of the user interface was lower than the "usability" of the BLOX authoring interface. It was not as productive as the project director, Earll Murman felt was needed, although BLOX was a good example of what was available at that time:
In addition to the effectiveness, an important concern is the effort required to develop and use the software. The development of a module has required substantial time and cost. Although a productive user interface has been achieved, a more productive developer interface is needed. An example of such an interface is CMU Tutor, which provides an easy to use authoring environment for workstation level software. (Murman, LaVin & Ellis, 1988, p. 10)
The advice suggested by Murman, who also directed Athena for a time, was eventually incorporated as a major facility for developers in the Athena environment. The problem - set solutions that were developed by Bucciarelli for Mechanics 2.01 were developed in cT which is the most recent version of Carnegie Mellon University (CMU) Tutor that was referred to by Murman in the passage above. While in many ways, this newer project shared many of the same academic goals and objectives as the older TODOR project, there were key ways in which it differed at the technical and organizational levels. One of these grew out of Bucciarelli's belief in the importance of implementing his project with a very different type of tool than was available at the time that the TODOR project was initiated. Bucciarelli reflects the new "tool" oriented spirit of more recent goals of Athena at MIT in the passage below:
Bucciarelli: Forget a textbook type of application. We should think more in terms of providing faculty and staff with programming languages and tools to develop their own materials. The good thing about cT is that it has an easy to learn interface. I found it quite easy to get into and I found students have taken to it without much difficulty. (Bucciarelli & Hopper, 1992)
While cT is highly regarded by Bucciarelli for its easy to use interface, it requires a certain amount of programming skill to use. This brings up a central issue in the construction of simulations in regards to the issue of "usability." When languages are used, they should be easy enough to learn to provide for reasonable interaction, yet powerful enough to allow for reasonable creation capabilities. If the creation of simulations rely on the ability to program, this will prove to be a limitation to their creation, because of the scarcity of the technical expertise needed to create them in most typical educational settings. So one possibility is to create tool kits that require a minimal amount of programming to create reasonable simulations.
The AthenaMuse software is an example of such a toolkit. One design principle of AthenaMuse was to minimize the use of procedural code, because data specification tends to be quicker to create and to require less-specialized skill, and it is possible to edit it with point-and-click interfaces, thus diminishing the large learning curve associated with teaching programming languages. The team that created AthenaMuse experimented with using the same "directed graph" structure for both simulation and linking, so that some simulations were created without resorting to coding in a traditional programming language. This creative approach has not yet been fully implemented or tested beyond a few prototypes which used a spreadsheet like environment to describe the positions, relationships and other values of elements on the screen. In a simple case, the spreadsheet acted as a patch panel or routing switch, directing the propagation of data values to different components of the system. In a more complex case, the spreadsheet can maintain the constraint relations that formed the core of a simulation. (Hodges, Sasnett & Ackerman, 1989, p. 41)
The major relationships between various aspects of the educational computing environment are illustrated in Figure 1 below (see Figure 1). Regardless of the types of software that projects used, how well software supported both the creation of courseware, and the interaction of users became a major consideration for each of the projects in this study. Balancing these issues with the educational goals at hand took a great deal of effort and forethought by those most closely associated with projects. On the one hand, to forget about the need for usable software was to ensure the limited success of a project. However, to become so concerned about solving this problem that sight was lost of the educational vision was another danger. Across each successful site, there was an awareness that the complexity of the computing environments caused a need to deal with technical issue of usability, while not forgetting to maintain a focus on the educational issues.
Figure 1: The Influence and Influences Upon Usability"