[Home Page]


Mr Jon M Pearce
Mr Matthew D Riddle
and Dr Michael W Nott
Science Multimedia Teaching Unit
The University of Melbourne
Parkville, Victoria, Australia


This paper explores requirements for interactive multimedia development, and illustrates possibilities and pitfalls through some production examples. The development of computer software involving the use of interactive multimedia is following the same path as many other computer-based productions: what was once the sacred possession of a team of professionals can now be done by an individual with a modest computer on his or her desktop. We have witnessed such an evolution with word processing, desktop publishing and desktop design. Is the same really true of multimedia productions?

This paper confronts the issues arising at both ends of the budget spectrum, recognising that many developers will not have access to full professional resources in the field. For a more detailed look at designing and developing multimedia teaching resources, refer to the relevant sections of the book by Laurillard (1993) Rethinking University Thinking.

Preparing the way

More and more frequently, academics are turning to the computer to find ways to solve some of the problems associated with teaching tertiary courses. There are many perceived attractions of using this technology: individualised learning; course delivery away from the traditional classroom; highly motivating and interactive presentations; and even simply the attraction of being "high tech" in one's learning.

However, before embarking on the extensive work required to employ computers, we should examine our motives closely and ensure that a computer-based package is the best way to proceed. Several questions need to be answered.

Why use a computer?

Most of us recognise that the computer per se will not enhance learning. The software presented by it, the students' interaction with the software and their activities after using the software, are what might constitute effective computer-based learning. Hence we should examine carefully why the computer might be appropriate for a particular task. Development costs never come cheaply--even with the blood, sweat and tears of a dedicated academic--and they are rarely refunded by the sales of a product in the educational marketplace. If the development of a computer program cannot offer clear and distinct advantages over other available methods, then it should be dropped.

Will there be adequate interaction between computer and student?

Although we may strive hard to provide our students with active learning environments, it is easy to overlook that the computer too needs to present text and images that students can interact with. It is the student who is to be taught, not the computer! Hence the student must be led to a "brains on" engagement with the machine in order to benefit from it.

Do we have sufficient and powerful enough facilities on which to run the final product?

Development computers are often more powerful than the particular models found in the classroom. This can lead to a false sense of security when developing and testing software. For example, QuickTime movies that run smoothly on a Macintosh Quadra might have a markedly reduced frame rate on a humble LC and not perform to a satisfactory standard. For reasons like this, it is important to know what computers are available on which to run the final product. This means a knowledge of speed, screen colour depth and resolution, RAM and disc capacities, as well as the likelihood and effects of any imminent upgrades.

Do we have adequate funds for the production?

Estimating the cost of a production is fraught with difficulties. Although broad estimations can be made on the basis of so many hours programming per screen, or so many hours of development per hour of students' interaction time, such estimates will be extremely inaccurate when it comes to predicting the times and expenses for a team of people required for a multimedia production. No rule of thumb can be offered. A starting point is to list the various expertises required and to try to write down a budget for each. This will at least provide a starting point from which you can keep track of how the budget is spent, even if the actual amounts are vague estimates.

Having addressed these questions, a team can be formed and the process of designing the project commenced.

Establishing a team

The establishment of the team for a project is a crucial starting point for any multimedia project, whether small or large scale. Perceived or real budgetary or bureaucratic realities can mean that team members are chosen by default. However this does not alleviate the need for defined roles of members within the team. Very often, for example, some members take on more than one role, particularly in projects involving only a few people.

The first step in team establishment will usually be the nomination of a project manager, whose most important task will be to coordinate the roles of other team members. The project manager might be someone with expertise in multimedia production, but will often also be the content expert for the project. Our optimal experience is to select a project manager from "outside" the project. Decisions on the inclusion of other team members will usually be guided by the budget, which needs to be drafted while the concept is being developed.

Experts in production of each media type to be used in the project, such as video, illustration, and animation, should at the very least be consulted in the stages of concept formation and planning. At most educational institutions there are experts in video production and graphic design, for example, and often consultation is at no charge. Not only will this assist in drawing up the budget, but the creative and technical expertise these people can contribute to a project while it is still in a formative stage will often be invaluable.

As the project starts to take shape, a firmer idea of the roles of each team member starts to become clear. A typical multimedia project will include a project manager, a content expert/academic, an educational designer, an evaluation specialist, video production personnel, a graphic artist/animator, and a programmer/software engineer. It is important that each member is included in the process of concept formation and planning at the early stages of the project, even if their role during production is fairly minor. Ideally the project will evolve within the group drawing on expertise from each area as required. A good example is the capacity of graphic designers at this early stage to visualise concepts as they are developed, and to produce a storyboard. The storyboard can become a working document for the whole group, and allows fairly vague ideas to become more concrete. Later, it can become the basis for a specification of the software, which is critical for the programmer.

If copyright material is to be used then a person must be allocated the task of determining copyright release. Similarly, if the project is to be marketed, then legal and marketing representatives must be engaged; documentation must be planned.

The process of role definition has a number of beneficial effects in multimedia production. Even though roles typically, even desirably, overlap and coincide, each team member maintains an identity within the team. Members know what is expected of them, and who is dependent on the results of their contribution to the project. They know also what to expect of others. For example, if the graphic designer is in charge of finalising the screen designs, it is clear to the software engineer whose responsibility it is to supply them. It also assists the project manager in deciding on a production schedule so that each stage of the project can be planned effectively.

Structure of a project

The process of developing a multimedia project can usually be regarded as comprising a number of important stages which define a general chronology but typically overlap: concept formation; planning; production; review and post-production.

Figure 1. Involvement of team members during a typical multimedia project.

Figure 1 is an attempt to show the involvement that various members of the team have during different stages of the project. The figure is not meant to be prescriptive, but it illustrates the interaction of a team during a typical project undertaken at The University of Melbourne. (Further examples of such projects can be found in Pearce et al (1993)).

The whole team is involved right at the start of the project, at the formative stage. This is important for several reasons: it helps avoid setting off down a track that later may prove to be undesirable from the point of view of a particular team member; it gives the whole team an overview of, and an input to, the general direction in which the project is heading; and, importantly, it helps to give the whole team a sense of identity with, and ownership of, the project. This last point becomes significant further down the track when time is getting tight and the pressure is on for people to meet closing deadlines.

Concept Formation

It is likely that the original concept for a computer production is the product of one or two "content experts" or academics. They will most likely develop some visual meaning for the concept and produce a document defining the task. The idea needs to be defined well enough at this stage so that it can be communicated to others in the planning stage.


The planning stage will require the coordinator of the project to work out, with others involved, a time-line for production. For a large team effort this is crucial: video production takes advance planning, graphics artists need time to mock-up ideas, base-line data for later evaluation might need to be obtained, and so on.

It is important that all parts of the team are represented at the planning stage as each will make valuable contributions to the feasibility of ideas put forward. The result of this process might be the production of a booklet that story-boards the program, the graphic artist having produced some rough sketches of possible screen designs and a tentative navigational map of the program overall.

The choice of computer platform and programming environment are issues raised here that might not be straightforward. The computer platform will probably be dictated by the facilities available. However the choice of programming environment, whilst often determined by the expertise of those involved, might be more open if a programmer is to be contracted. This might well offer the possibility of programming for more than one computer platform and hence making the product more widely distributable.

Considerable effort might need to be put into exploring the suitability of different programming environments for the particular program to be developed. If the nature of the product is largely to present a variety of media objects such as text, pictures, videos, animations and sound, then a high level programming environment such as HyperCard, ToolBook, Authorware or MacroMind Director might be suitable. However, if extensive numerical calculations are required to be executed rapidly, then perhaps a lower level language such as C++, Visual Basic or Pascal will have to considered.

Software developed on most of the above packages can be translated to run on both PCs and Macintoshes, but the conversion is not straightforward and requires considerable advanced planning. An exception to this is Authorware, which runs on both platforms, but has other limitations in terms of programmability and speed.

Production and Review

These two stages form a cyclic pair, each feeding to the other. The process involves meeting regularly, reviewing progress and refining approaches. During this time, resources are created: video segments are shot; animations are produced; sound and picture resources are recorded; programming code is written. All members of the team will, of course, be heavily involved as changes in one aspect of the project will almost certainly affect other areas.

Is it likely that some evaluation of aspects of the project will take place here: user interfaces might be trialed with students; learning strategies might be evaluated; screen layouts might be appraised. (For approaches to evaluating multimedia projects, see McNaught & Wills (1993).)


Once a working version of the project is available, it is time to implement the planned evaluation and review procedures. This might involve monitoring the use of the package, interviewing or surveying users, analysing log files created during use of the package. A debriefing with the team at this stage presents valuable learning opportunities for future projects.

Lessons learned from experience

A number of development projects at The University of Melbourne have given us valuable experience relating to the topics outlined above. Space forbids a very detailed description of these projects, however it is hoped that several can be illustrated during the presentation of this paper.

Howard Florey Project

The necessity of strong project management, with good continuity, was realised during this project. The Howard Florey Project involved the production of a `kiosk' style information system to run continuously in the front entrance of the Howard Florey Institute giving visitors an idea of the sort of work that the Institute is involved in. The project exploited extensively several media types: video, animations, sound and graphics. The project was carefully story-boarded during the planning stage and an extensive number of video shoots were scheduled.

During the production stage, however, the project management was disrupted due to illness. One result of this lack of continuity of project management was that during that time decisions were made about adding additional video material that was not in the original plan. This had an unforseen impact on the latter stages of production, when the video segments had to be processed into QuickTime movies. This time commitment shows up in Figure 1 in the Programmer/Software Engineer line under Production.

The delay during production caused problems with the schedule, which was critical because several key members of the team, including the software engineer, were due to leave the country. Additional software engineers were brought in to meet the deadline. The end result was a product of excellent quality, however the production process drew more heavily on the team's time than was originally budgeted for. This emphasises the need for backup planning, including allowing for the unexpected absence of some team members.

University Interactive Handbook

This is another large project that requiring the expertise of a large team, and many weeks of work for planning and production. The project aim was to put Volume 1 of The University of Melbourne's Handbook (which covers undergraduate studies and an introduction to the university) into an interactive environment on CD-ROM to be distributed to schools in addition to the paper version. Using interactive multimedia, the concept was to convey an impression of life at The University of Melbourne. Pictures and voices of undergraduates and graduates were used to guide the user through the information.

The method chosen for reviewing this project was to videotape the computer screen while recording the voices of students talking about what they are thinking. The video was then analysed in order to ascertain problems with screen design and navigation and to give some idea of the ways in which students chose to use the program. This `thinking aloud' technique is very useful in assessing interface design, and many changes were made to the design of the final product as a result of this analysis.

Software and hardware requirements


Interactive multimedia software requires the integration of different media types, including text, graphics, animation, audio and video. For the multimedia development team, this means that the software environment chosen must be able to cope with integration of data from each media type, as well as provide a means for interaction between the user and the software. For development, it will be necessary also to have access to programs that are capable of editing each of the media types chosen, so that a typical project may involve the use of a wide variety of software tools, such as the following:

* Adobe Photoshop (photo manipulation and colour paint package)

* MacroMind Director (animation editor and authoring package)

* Adobe Premiere (QuickTime video and audio editor)

* SoundEdit Pro (audio manipulation package)

* HyperCard (programming/authoring environment)

Hardware--development versus delivery requirements

There are many trade-offs between facility and dollars when it comes to considering what hardware is necessary to implement multimedia programs. So called `multimedia capable' computers are commonplace today, however it is necessary to have a computer that is more powerful for development, particularly when the project requires the use of media such as audio, animation, and video. For digital video production, for example, a fast computer is required to process the information quickly enough, and vast amounts of memory (both RAM and hard disk space) will be necessary. Additionally, expansion cards provide the means for conversion of analogue to digital video information, as well as compression and decompression of data.

In projects requiring the use of video and audio, it is not unusual for many gigabytes (thousands of megabytes) of information to be manipulated during development. However, the final project may be delivered at a size of only a few megabytes, and often may be required to run on quite low-end machines. One role of the programmer or software engineer in the early stages should be to help determine the hardware and software requirements at both development and delivery stages. Ideally, the team will finalise these specifications before commencement of production.


As with any computer production, a huge amount of time is invested to produce the final product. It is a valuable decision to engage the help of professionals in the various fields where possible, or at least to recognise the skills one might need to develop in oneself if outside help is not an option. This paper has aimed to raise awareness of the skills and knowledge required for this task.


Laurillard, D. (1993). Rethinking University Thinking--A Framework for the Effective Use of Educational Technology, London: Routledge.

Pearce, J. M., Riddle, M. D. and Nott, M. W. (1993). Science Laboratories, Computers and Multimedia: Opportunity for Change, in Reaching Out with I. T. ASCILITE 1993, Proceedings, Tenth Annual Conference of the Australian Society for Computers in Learning in Tertiary Education, Lismore.

Wills, S. and McNaught, C. (1993). Evaluation of Computers in Learning in Tertiary Education, in Reaching Out with I. T. ASCILITE 1993, Proceedings, Tenth Annual Conference of the Australian Society for Computers in Learning in Tertiary Education, Lismore.

[Back to J Pearce Home Page]

These pages are maintained by Jon Pearce ( jonmp@unimelb.edu.au), Department of Information Systems. The opinoins on them do not necessarily reflect those of the University of Melbourne. Tel: (613) 8344 1495 Fax: (613) 9349 4596. Last update: September 16, 2003 .