|
Developing interactive multimedia programs has similarities to normal software development, but the issues are more complex. While program design is important, the design of the educational material and the graphic design of the user interface are probably more important. A range of management issues are also relevant. This paper will present a development methodology for educational interactive multimedia. It dissects all aspects of the development process in the tertiary environment and gives guidelines on how to successfully develop interactive multimedia, based on procedures which have been developed at Curtin University since 1992. The key points to be raised in this paper are to:
- Aim for quality and innovation
- Separate design from production
- Use incremental prototyping
- Ensure effective communication
Several models have been developed for managing software development, and a summary of these is given in (Howell 1992). One currently popular method is the Incremental Prototyping model, where a program is designed and tested by the construction of a prototype. Essentially, this process is repeated as many times as required (given the constraints of the budget!). Once each prototype is tested it can be discarded and a new version is designed and built which incorporates the lessons learned from the previous prototype. In this way, the design can be continually refined and problems eliminated step by step.
The Incremental Prototyping model contrasts with the earlier Waterfall model, where development process is separated into phases which are performed sequentially.
Interactive multimedia is more problematical than standard software development, due to its novel nature and because it is not yet clear what the range of possibilities are with this medium. The emerging interactive multimedia technology has imposed a number of communication, navigation and graphic design issues on top of software development matters. These issues complicate design and development to such an extent that it is impossible to create an effective design at the first attempt. It is therefore important to design for change, while trying at the same time not to waste money and effort.
This paper discusses a particular incremental prototyping model which has been found useful in successfully producing interactive multimedia programs for tertiary education. IMM programs require considerable time and resources to create, and, therefore, the development process needs to be as efficient as possible. One approach to achieve efficiency is to separate the design and production phases of the development as much as possible, while at the same time clearly documenting any decisions made.
Figure 1: The incremental prototyping development process
Experience has shown that this incremental prototyping model is an appropriate model for the production of quality educational interactive multimedia. Under this model all aspects of the project should be formatively evaluated and revised until the project team is satisfied with their effectiveness.
An incremental prototyping model has the potential to be extremely wasteful of resources. There is a tendency to design and develop prototypes which include drafts of a substantial amount of content. This might include the entire navigational structure, and substantial amounts of content screens. The prototype is subsequently evaluated, and design deficiencies noted. Perhaps some topics in the hierarchy need to be moved and some navigation controls need to be altered. With a prototype of fifty or so screens, it can take significant time to make these modifications.
The Understanding Technical Drawings package (Phillips 1994) is a good example of this approach. Early designs identified the number and types of screens, and these were created, waiting for content to be prepared for them. The first prototype highlighted significant problems with the content structure and navigation, and substantial modifications were required. This process continued as more and more content was designed and prepared.
After three major revisions and countless minor ones, the project had grown to over 400 screens, and it was decided that some of the content had to be pruned. At this stage, however, it was very difficult to identify which parts to cut, because it was difficult to form an overview of the program as a whole. Most of the design process was being implemented in full on the computer before being finalised. In essence, it was not prototypes that were being produced, but a series of supposedly finished products. Over 400 hours were spent in this cycle, and many of these could have been saved by finalising the design before starting production.
The point of a prototype is that changing it requires little effort, unlike the full blown program that had been produced here. There is an important role for making prototypes of some of the ideas of the design team, but the prototypes should remain just that: prototypes. Having put too much effort into a prototype, the team may be reluctant to revise so much work, and the project can become locked in to a suboptimal design.
There is an understandable urge on the part of the development team, especially inexperienced members, to view what the finished product will look like. However, our experience is that this approach can be wasteful of resources. It is essential that the development team have a shared vision of the outlook of the finished product, but this should be achieved with as little production effort as possible. This is the key point of our development methodology: to separate the Design Process from the Production Process. Both of these processes follow the design, develop, evaluate model of Fig. 1, but the design process has a higher weighting of the design component, while the production process is mainly concerned with development. Evaluation is important in both cycles.
In the academic world, the requirements definition usually forms the basis of a funding proposal, without which development usually cannot proceed. As part of the grant proposal, the initial idea is discussed and refined. Discussions should be held with academic colleagues and other multimedia developers about the merits of the idea. The idea should be defined as clearly and comprehensively as possible. Not only can this save time and effort later, it will also increase the chances of being funded.
Any grant application should incorporate many aspects of a feasibility study. Funding agencies are unlikely to fund an 'idea', but will look more closely at a proposal which incorporates, say, 75% of a feasibility study. First of all, the educational effectiveness of the proposed project needs to be considered, including why it should be treated with interactive multimedia. Then, estimates of the technical merits of a project, and whether it can be implemented, should be made. Estimates also have to be made of the cost, the amount of labour involved, and a proposed timeline. However, in too many academic projects, few of these are considered in detail and the grant application process involves only a cursory analysis of a poorly defined problem.
It is difficult to perform a full feasibility study of an IMM project, because clear definition of the project often does not occur until late in the development cycle. Instead, the feasibility study is often used to broadly define possibilities, without being overly specific. The feasibility study can establish some development boundaries, eg. set guidelines for how long a user must wait for a response (the response time) from a system. In the creative phase of the design many ideas may be proposed, but can be rejected on subsequent testing against the responsiveness guidelines. It is very easy to forget implementation details when considering innovative educational ideas.
The following points outline various aspects of the feasibility study which are discussed in more detail in (Phillips 1995)
In the introduction we made the point that it was essential to separate the Design Processfrom the Production Process, as shown in Fig. 2. It cannot be emphasised enough how important it is to design the project as comprehensively as possible on paper, in order to produce a quality project within budget. After a comprehensive specification of the overall structure of the program has been produced, it is important to create a complete storyboard of all of the content of the program. Production should only commence after the storyboard has been agreed on by the development team. This milestone in the process is formalised by the signing of a contractual agreement that this stage has been reached. The signing off procedure is an important incentive to ensure that the design is complete, and that members of the team will not attempt to change some components of the design at a later stage.
Figure 2: The separation of design from production in the
incremental prototyping development model
After the initial design is produced, there is a focus on developing the requirements specification in finer and finer detail. Developments are reviewed by the team, and prototypes of the graphic design and of technically difficult programming areas may be developed.
As the requirements specification becomes more tightly defined, the group will start to develop a comprehensive description of the content of the project, called a storyboard. Inevitably, work on the storyboard will expose deficiencies in the requirements specification. For example, certain decisions about the way that content will be presented will cause modifications to the user interface.
With each pass through the design process, there should be fewer and fewer changes to the design, until it is eventually complete. It is then appropriate to sign off the design, after which the storyboard cannot be changed.
The development phase of the design process includes production of prototypes of technically difficult programming components and the creation of the graphic design, but it may also involve constructing physical models to visualise the structure of the project, or parts of it. For example, the project team may use index cards and string to map out the project on a wall or table.
Evaluation of the design usually consists of constructive criticism and reflection within the development team, and with other experts and end users.
The user testing starts another pass through the development cycle, because programming bugs need to be fixed. If the process as a whole has been successful, few problems with the educational content or user interface will arise at this stage, because these will have been resolved during the design process. Bitter experience has taught us that navigational problems exposed at the end of a project can be very costly. Any changes of this type may affect any number of different screens (potentially thousands), and any of these may have unforeseen side effects on other parts of the program.
At this stage, the program is installed on end user computers, and can be maintained as a working product. This is where the project is completed. Any design changes after this point usually do not result in re-entering the development cycle, but lead to a new product.
An often forgotten part of a project is maintenance. In an ideal project, maintenance takes up very little of the total time of the project. But, in many cases, maintenance can take up half or more of the total time spent on a project. In order to minimise this, it is important that the project is well designed and well managed. In particular, it should be designed to be easily modified. If a bug occurs or the project crashes, it is important to be able to locate the bug quickly and fix it.
A comparison of the development times of two projects is informative in assessing the importance of a careful design (Phillips 1995). The Dosage Calculation program was mostly developed before we had adopted the current design methodology. The development was informal with no clearly defined timelines. It was also grossly underfunded. Inexperience on the part of all members of the team led to some aspects of the design not being thought through in sufficient detail. In particular, the testing modules should have been designed at the same time as the rest of the program, instead of being added at a later date. Consequently, more than 50% of the total development time was spent on unfunded maintenance and debugging of the program. The Carbohydrates program, on the other hand, went through a comprehensive design process. In this case, debugging and maintenance comprised 5 hours out of approximately 300 hours total development time.
Many content experts resist such a rigorous design process. They are used to working on their own ideas, or at the least communicating them to like thinking colleagues or graduate students. Since they can communicate succinctly with colleagues in their own discipline, they may wonder: "What is the point of wasting so much time writing it all down in detail?".
A potential problem of IMM is its multidisciplinary nature, where different team members may well not think like the content expert. Other team members have different skills and different ways of communicating, and/or interpreting the same statements. As well as this, the details which the content expert has glossed over in her or his head can be extremely important for the programmer or graphic designer. Without those details the other team members have to make assumptions, which lead to problems later. In an IMM development, all team members need to fully understand what is required, because they all have an intellectual and creative contribution to make.
One of the most challenging aspects of IMM project management is maintaining communication between members of the project team. The diverse skills of team members can lead to a whole range of management problems. Each member has a considerable creative investment in the work, and tends to claim intellectual ownership of the project. However, because each team member has a different set of skills, some aspects of the development are more important to them than to others. Different team members also have differing world views. During the design process each of the team members have distinct and important responsibilities which they must remember in addition to their contribution to the overall project design.
A continuing dialogue between content experts, designers, programmers and project managers, and reflection and evaluation of the successes and failures of a project are important to improve the processes by which projects are developed. The most important thing is not to assume anything. In our experience, when problems have occurred in projects, very often it has been that one team member has assumed that he or she knew what was required. Unfortunately, usually that assumption was proved to be false. A very effective method of ensuring that all members of the team understand all facets of the design is to clearly document all of them.
However, it is not practical to produce such a rigorous and complete description for IMM, because it is so much more difficult to finalise the form of the content and interactions. Typically, the structure does not become clear until the design process is partially complete. In many cases, it is not possible to determine whether a particular design strategy will be effective until after it has been developed to an advanced stage, implemented and evaluated.
The purpose of the requirements specification in an IMM development is to clearly define the functionality and scope of the project. The requirements specification is interlinked with the feasibility study and evolves as the design cycle progresses. Evaluation of prototypes will expose problems in the design, which in turn will lead to changes in the requirements specification. While it is difficult to arrive at a finalised requirements specification, the process of creating the requirements specification is absolutely essential because it documents the design decisions made for all members of the team.
The requirements specification provides the project team with as clear as possible an understanding of the structure of the project, including an overview of the content. It is essential that all team members are involved in the design of the content from the earliest stages, because even though some team members do not always have content expertise, they generally have more experience in IMM, and can provide important insights into how the content may best be structured to suit the IMM medium.
We have adopted the procedure of brainstorming at the beginning of a project with a group of all interested parties, which may be as many as 10 to 15 people. The role of the brainstorming session is to give the team an idea of the scope of the project and to obtain a basic understanding of the content. The session starts with the Content Expert lecturing to the group and group members asking questions. When the group has basically understood the scope of the content, any and all ideas are advanced and discussed. After a general consensus has been reached about the basic structure of the project, the group contracts to form the project team and development proceeds.
It is important to write down what is agreed at team meetings about what is to be in the project. In many of our earlier projects, the requirements specification was mainly described orally at meetings. The danger of this approach is that different team members have a different understanding of what is agreed. This can lead to substantial content changes late in the project, or to complaints that the developers added features that were not agreed on. The written approach is especially important in IMM development, because team members come from different professional backgrounds with different world views, and it is common for what one has said to be interpreted very differently by another.
Ongoing team meetings investigate ways of structuring the content to meet educational and project goals. Essentially, they seek to develop navigational strategies for moving through the content. Inevitably, this leads to discussion of the user interface and graphic design. Typically, early meetings agree on navigational strategies at the highest level, with subsequent meetings examining how navigation may be achieved through specific content, while remaining consistent with the global navigational strategy.
The requirements specification also defines the scope of the project and how each aspect of the project will be treated. It describes details of the user interface, and it may contain some guidelines about the graphic design. It does not contain any content, other than perhaps the headings of the topics, or other details required to define the navigation. The requirements specification specifies the functionality required of the project. For example, if there is a 'glossary' function required, this functionality is fully described in the requirements specification. In an incremental prototyping model, the requirements specification will evolve from that originally agreed upon as its details are analysed and evaluated.
The Sarcomotion project, currently under development, is the first in which we have used a formal requirements specification. While it takes time to prepare such a detailed document, it is generally cost effective, because it saves considerable wasted development work later, when misunderstandings and oversights have to be overcome. It also keeps the team focussed on the task at hand.
In current development, we develop storyboards on a word processor. Text is then copied and pasted into the authoring package. The use of a word processor simplifies revision of the storyboard, and minimises spelling errors.
The development process requires that the storyboard be comprehensively reviewed several times by other team members. Production work should not start until the content is agreed to be final, and signed off so it cannot be changed. If a storyboard is accepted as complete, but requires subsequent revision, then the resultant changes to the programming can take hours to modify, and may even require redesign of much of the user interface.
The entire team should carefully read the storyboard from their point of view. It is very easy for inconsistencies and discrepancies to appear in the storyboard, and these may not be immediately obvious to the content expert who has written the material. Designers and programmers may discover things in the storyboard which don't match the requirements specification or which are simply not technically feasible. It is also difficult for all team members to appreciate all aspects of the project without thoroughly understanding the storyboard.
Whilst the requirements specification and prototypes of the screen design are essential for team members to visualise the project, as little content as possible should be entered into the project until the storyboard is complete. If possible, content experts should try to visualise the project from the prototypes when writing the storyboard. This is difficult, but can save considerable effort and money later.
Howell, G. T. (1992). Building Hypermedia Applications: A software development guide. McGraw Hill.
Phillips, R. A. (1994). Understanding technical drawings: Using interactive multimedia to enhance spatial reasoning skills. In C. McBeath and R. Atkinson (Eds), Proceedings of the Second International Interactive Multimedia Symposium, 409-416. Perth, Western Australia, 23-28 January. Promaco Conventions. http://www.aset.org.au/confs/iims/1994/np/phillips.html
Phillips, R. A. (1995). Developers guide to interactive multimedia - a methodology for educational applications. Computing Centre. Perth, Australia, Curtin University of Technology: 220.
Sommerville, I. (1989). Software Engineering, Addison-Wesley.
| Author: Dr Rob Phillips Computing Centre r.phillips@info.curtin.edu.au Curtin University of Technology GPO Box U1987, Perth WA 6001 Tel: +61 9 351 3101 Fax: +61 9 351 2673 Please cite as: Phillips, R. (1996). A methodology for developing educational applications of interactive multimedia. In C. McBeath and R. Atkinson (Eds), The Learning Superhighway: New world? New worries? Proceedings of the Third International Interactive Multimedia Symposium, 309-315. Perth, Western Australia, 21-25 January. Promaco Conventions. http://www.aset.org.au/confs/iims/1996/lp/phillips.html |