IIMS 94 contents
[ IIMS 94 contents ]

The development of an interactive multimedia package to introduce computer communications

Paul Newhouse
Edith Cowan University, Western Australia
This paper outlines the development of an interactive multimedia package designed to introduce both internal and external university students to the basics of computer communications. It considers the use of a low budget, specialist team model for the production of such a package. The choice of authoring environments and development hardware platform permitted a minimum of initial planning and the need for minimal briefings between development team members. The use of a specialist graphic designer and a programmer were crucial to the success of the project as was the instructional design experience and knowledge of the main author.

Academics at our university were asked to submit proposals for multimedia (not necessarily interactive) packages which could be used within existing external courses. Those projects selected were to be offered the assistance of an instructional designer, a programmer, a computer based graphics designer and the media services section at the University. I proposed the development of an interactive multimedia package to introduce both internal and external students to the basics of computer communications.

Initially the need for such a package resulted from both the "externalising" of a postgraduate unit and the development of the Edith Cowan University Virtual Campus. The latter involves the use of computer communications facilities for the tuition of external students. At the same time the University decided to trial the development of interactive multimedia packages through its external studies department. This involved hiring a number of specialists to work with academics.

The package

The development model

From the beginning the project had placed upon it the necessity for a prototyping development model. To make use of the resources of a graphic artist and a programmer the production of the package had to be started quickly with little time for an initial design phases. However, even without these constraints I still would have employed some form of a prototyping development model for the package.

The use of a prototyping model of development is well supported by recent literature such as by Henson and Knezek (1991). They argue well the economic imperative for the use of prototyping for the development of educational software. The traditional design and then code model is far too expensive for most of the education markets. This traditional approach which they variously call, 'software engineering' and 'systems analysis and design' requires a sequential approach with teams of experts in communication. It does not allow for easy changing of the design and relies on communication between the different types of experts involved. Phillips (1990) points out the difficulty in communication between curriculum experts and computer experts.

Phillips (1990) describes the traditional approach as a team approach which tends to indicate that the alternative is an individual approach. While his prototyping approach may be individual this does not mean that prototyping has to be individual, in fact many would say it needs to still be a team approach. Faiola (1989) suggests that courseware teams may consist of a Project Manager, Content Expert, Instructional Designer, Editorial Specialist, Computer Programmer and Graphic Specialist.

Prototyping is the process of creating and repeatedly enhancing a model of the desired software. It is an iterative process that has been used in other fields, such as engineering, for some time (Janson & Smith, 1985; Henson & Knezek, 1991, 232).

Henson and Knezek (1991, 232) define the steps of prototyping as

  1. identifying courseware objectives
  2. creating an initial model of courseware
  3. evaluating the prototype
  4. modifying the prototype
  5. repeat (c) and (d) until the model is satisfactory
Prototyping has a number of advantages outlined by Henson and Knezek (1991, 233) such as promoting user involvement, enhancing communication, adapting in a dynamic setting, and less overall resource requirements. They suggest a potential for 25% reduction in costs of production.

Problems with prototyping revolve about the tendency to hurry on with development without regard for flexibility and good design features (Janson & Smith, 1985). Documentation is also usually lacking and boredom may discourage its completion at the end. Management is also difficult - when has enough been done - it is easy for development costs to blow out.

The evolution of the package

In some senses the prototyping development process led to the package evolving. I will represent this process in five evolutionary stages.

Initial graphics created

Initially my proposal was not accepted by the organising committee. However, the people associated with the proposals that were selected took a long time to get started probably because they had little or no experience with the development of software and their ideas had not been sufficiently refined. As a result the university found that they had employed a graphics designer and had nothing for him to do. They asked if I could get going straight away, but I received no time allocation. Within a day I had sketched out the main concepts and started communicating with the graphics designer.

The graphics designer had been trained at TAFE and had experience using Authorware. I was able to provide him with rough paper sketches of main screens which he started to produce. I had a general sequence outlined but only provided him with those screens requiring a lot of graphics. I knew that later we would be employing a programmer who could add the non-graphic screens, interaction and the structure. I wanted the graphics imported into Authorware to see how well they worked and to allow me to work around them.

I did not use the support of the instructional designer as this person did not have a background in the development of computer software. My own background and experience in both education and computer software development were important for the initially quick development at this stage. I knew what I wanted to do, how it would look, what needed to be done and what was possible and what was impractical. At this early stage the main concepts were well conceived. I knew the order in which the information needed to be presented, the main type of graphics required, the types of interactivity which could be included and I had even envisaged the simulation to be placed at the end of the package.

A linear format with an iconbar

The package still had a linear format with most of the key graphics screens completed. This was considered adequate since most people would need to look at all the information in the sequence presented. However, to allow users to develop a framework and review particular sequences I had always intended that the format should be broken into modules. Also the package still required a number of linking screens basically filled with text material.

Since I knew that eventually the package would have a modular structure and asked the graphics designer to design an iconbar with the key features represented: move to the next screen or action, go to a menu, go to a glossary, go to the quiz and quit. While I know that I wanted for a glossary and a quiz I hadn't started work on what form they would take. Therefore provision was made for them in the iconbar without activating the icons.

Modularity incorporated

After about a month a programmer joined the team and once again since none of the other 'selected' projects were sufficiently advanced my project was used to provide the programmer with work and a focus to learn how to program in Authorware (he had no previous experience in this environment). He was important in the development of the structure of the package, the main menu, the glossary function and a few of my example questions for the quiz.

The first task I set the programmer was to tidy up the structure of the package and create a number of modules which I outlined. I believe that he did a good job on setting up the structure and most people are surprised at the clean look of the flowline. From a programming perspective it is now easy to locate screens and actions. It took him very little time, even as a newcomer to Authorware, to accomplish this task which underlines the importance of such authoring environments to the viability of my prototyping development approach.

The programmer and graphics designer worked in tandem with the graphics designer tidying up the graphics for the programmer. For example, for the main menu buttons the programmer placed the buttons as simple boxes and programmed the action. The graphics designer then replaced the boxes by graphic images which blended in with the graphics theme in the package. I would take away prototypes and write notes and draw diagrams, on paper, for both the programmer and graphics designer.

Insert joining text screens and complete quizzes

While the programmer worked on the structure and quiz I was able to think about the introductory and joining text screens for each module in the tutorial. Some of these screens already had graphics on them and simply required some text explanations. Others were new screens which were built largely of text to connect the main ideas already present in the graphic screens. In particular good instructional theory had to be considers such as screens to present the initial objectives and framework for each module and screens to summarise the main points. In places text screens had to be inserted between graphic screens to reinforce what had been seen and introduce the next piece of action.

Evaluation and improvements

When the tutorial had been modularised and most text screens completed it was important to get other content experts to evaluate the presentation of the content and suggest improvements. Since the Edith Cowan Virtual Campus was to be a focus of the use of the package it was appropriate to start with the manager of the system. She viewed the package and made a number of suggestions which were acted upon. In addition a number of colleagues from my department viewed the package.

In particular the introductory sequence, the IBM compatibles information and parts of the simulation module were modified after this initial evaluation. For example, it was clear that the introduction was too long and did not need the 'teaching' element of the revision screen on medium and networking.

Once content experts had evaluated the package potential users completed a more formal evaluation. A number of groups of postgraduate education students at our university who had little experience with using computers completed the tutorial and one module of the quiz. A major change implemented after this use with novice students was to include a move back arrow, initially I had thought they would just replay the module.

The overall process

The processes involved in developing the package were not textbook correct and yet they allowed the package to be developed initially very quickly and relatively inexpensively. The choice of authoring environments and development hardware platform permitted a minimum of initial planning and the need for minimal briefings between development team members. The structure of the package was able to evolve gradually without incurring large costs to the project. The use of a specialist graphic designer and a programmer were crucial to the success of the project as was the instructional design experience and knowledge of the main author.

Key design features

Use of graphics and animations

It is important that the graphic and dynamic capabilities of the computer medium be used effectively. It may be both an advantage and disadvantage of the medium (Surber & Leeder, 1988). It is easy to overuse graphics and yet graphics allow information to be presented in a motivating and concrete manner. Therefore I set out to use graphics and animations to highlight instructional points. They were important for the content since many remote students may not have seen any of the equipment which was discussed in the tutorial.

Interactivity

Interactivity is also an important advantage offered by the computer as a medium for instruction. Educators have considered learning as being an active process for many years (Ausubel, 1960). Therefore I set out to make the package as interactive as possible. Very early in the development I included the piece on connecting up the modem. However, lack of my time reduced the level of interactivity in the package as this takes thought and experience. It was difficult getting enough length of my time to build in the interactivity in the tutorial and the programmer's time to trial the ideas. Therefore most of the interactivity of the package ended up in the quiz. In many ways this is disappointing.

Learning theory

The package was aimed at novice users of and education students and therefore it was important to adhere to well supported learning theory. My own educational philosophy leans towards the constructivist, neo-Vygotskian approach to learning (Mercer & Fisher, 1992). Some of the main concepts I attempted to adhere to were
  1. the use of advance organisers
  2. the provision of action and user action to enhance learning
  3. the use of a variety of presentation formats and mediums
  4. the provision of reinforcement and review
Advance organisers allow the learner to assimilate new information with previously acquired information and understandings. The concept is well established in educational research and has been discussed for many years (Ausubel, 1960). Each module begins by stating what the module will address, often in terms of questions. In some situations diagrams are used to show the whole concept before looking at different components.

Most instructional/learning models include components of review and reinforcement. For example, Gagne (Gagne, Wager & Rojas, 1984) developed a sequence of nine events of instruction which are well regarded. The last three events all relate to review and reinforcement. I ensured that each module finished with a review of the information presented in the module and often a module reinforced or reviewed information presented in earlier modules.

Learning styles

Most educators today believe that there is a range of learning styles, different learners respond better to some than others (Carlson, 1992). Therefore it is important that instructional software offers information to suit a range of learning styles. Obviously this is time consuming and thus expensive to do but even so some measure can be taken to accommodate this aim. In this package I have attempted to present information in a range of formats to suit different learning styles. For example, in the simulation 'Making the Connection', information is presented as text, a graphic of the concept and an animated simulation. The user can replay segments and concentrate on one of the three sources of parallel information. In theory this should enhance concept development and retention.

Generalisability

Since this was intended to be an introductory piece of instruction to computer communications it was important to focus on generalisable concepts. It was not important to learn how to use a specific modem, communications package or online service, follow up instruction can focus on these. An example of a section which tries to accommodate the aim of generalisability is in the module on 'Modems and Cabling'. This module shows a variety of types of modems but tries to focus on the common elements. In the module 'Online Services' I tried not to get too specific on the services but rather presented a framework of what online services can offer .

Problems encountered

Generally, the development of the package progressed smoothly, if not a little slowly in the later stages due to lack of time from both myself and the support personnel.

Management of the team

Since the development team was small, consisting of myself, the programmer and the graphics designer there were no major management problems. The high level of computer literacy possessed by the team members matched to the computer based content of the package certainly helped in communication within the team. The other two team members shared an office and my office was in the same building so face to face contact could occur readily and informally. Even so, it was difficult to maintain a balance between control of the design and allowing the other team members to be creative. This was particularly difficult with the graphics designer who was both very skilled and creative but not an educator.

On a number of occasions I felt that the graphics designer was over zealous in making substantial changes to graphics and program control in early prototypes. For example, there was I believe a measure of overkill on some of the graphics such as the satellite. On other screens the graphic was physically bigger than I had originally asked for and overshadowed the overall information or purpose of the screen. On one occasion he replaced a graphic of a PC because he felt it looked better, I disagreed. He chose the colour scheme and in particular the yellow italic text which a few reviewers have criticised.

However, I have found that such people need to be given plenty of independence provided that we can live with the potential problems. The graphic designer came up with a number of creative ideas to enhance the program which I had not thought about. For example the marbled look, the iconbar and some of the animations were his ideas built on or replacing my original ideas.

The authoring environment

Most of the problems in the development of the package resulted from instabilities and short comings in the authoring environment chosen, Authorware Professional. On at least two occasions the software completely crashed and the whole package had to be reconstructed from its pieces. On one such occasion the Sydney office was contacted but could not help. They and we had no idea what the problem was, and we still don't. However I should point out that at times we used beta copies of the software, which way have contributed to the problems. Even so one of the crashes occurred when we had the true copy of the software.

There are also the inherent problems associated with the limitations of Authorware, this would happen no matter which authoring environment me chose. The main animations had to be created in Macromind Director and imported. Fortunately very little data needed to be stored and therefore this was not a major limitation. A number of initial problems such as with sound synchronisation, multiple erases and access to the glossary were overcome when we started using version two of the software. There were a number of things I would have liked to include that would take too much programming time in Authorware to do, such as putting a simple go back navigation button on the iconbar. The programmer felt that this would be too time consuming because so many of the screens were composite screens. Despite these shortcomings I am still happy with our original choice of Authorware as the authoring environment.

Evaluation of the package

Formative evaluation

As previously mentioned the formative evaluation consisted of content evaluation by peers and an evaluation of the useability by novice users enrolled in a number of our Bachelor of Education units. While the package was developed on Macintosh Quadra 700s equipped with 20 MB of RAM, 240 MB of hard disk and removable hard disk drive attached, it was tested on lower end Macintoshes with the novice users. They used either Macintosh LC or IIvx machines with 10 MB of RAM, on Appletalk or Ethernet networks. The package requires at least 8 MB of RAM allocated to RUNAPW file which meant that them machines were adequate. The package ran too slowly over a network, as expected, so it was downloaded to each machine's hard disk. The package then ran a little slowly but not sufficiently to bother the users. The synchronisation of sound and display at the beginning of the package was a problem but not very important.

Summative evaluation

The package has now been completed and is currently undergoing some summative evaluation with individual novice users and experts. It will be fully tested early in 1994 with undergraduate and graduate student groups and external users. In particular this will allow a full testing of the quiz modules.

Currently the quiz scores are not used for any purpose other than to give the user feedback. The scores are displayed at the end of each module and recorded in a user folder and file. It was never intended that the quiz be anything more than a tool to assist students in their own learning and I do not have the motivation to make it anything more than that now.

Estimated design and production cost

A rough estimate of the cost of the development and production of the package is presented below. The university did not give me time to work on the project and thus the cost to the university is simply for the graphics and programming support. All of the software and hardware already existed within the university. I have included an estimate of the cost of my time to give a more realistic costing figure.

  • My time: design, some production, review and   
    evaluation: 40 hours @ $75 per hour
=
$3,000
  • Graphics: 20 weeks @ $24,000 per year,
    20 + 48 * $24,000
=
$10,000
  • Programming: 10 weeks @ $24,000 per year:
    10/48 * $24,000
=
$5,000
Total

 =$18,000
Cost to the University

 =$15,000

If it is considered that the package provides a little over 1 hour's instruction then the development cost to the University of $15,000 seems quite reasonable. However, since this does not include all the real costs and it is still to be determined how many students will use the package the real cost may be argued to be quite prohibitive. If the university considered this to be a learning stage in its move toward the development of interactive multimedia instructional, packages then the costs can be justified. Otherwise I am not sure that the costs can be justified.

The future for the package

There are still three tasks left to complete at the of writing this paper:
  1. produce a videotape
  2. separate the quiz from the tutorial
  3. convert to Windows format

Produce a videotape

I knew at the commencement of the development of the package that many potential users would not initially have a computer configuration capable of running the package. It would need a Macintosh or Windows operating system on a 486 or equivalent platform equipped with about 8MB of RAM and either a removable hard drive or a CD-ROM drive. Since the University has recently purchased a CD mastering system it is conceivable that the University would make such software available to external students on CD-ROM.

Many of our external students for whom the package is designed either do not have a computer or have an old or underpowered machine. Therefore I determined very early in the development that we would produce a videotape run through of the package using a video encoder we had purchased. This then allowed me to progress on the package without consideration to platform limitations. Since then the Macintosh AV series has arrived and may be better suited to this task.

Separate the quiz from the tutorial

A second stage to producing a videotape is to produce a standalone of the quiz component. This component requires much less disk space and RAM to run and therefore may be able to be distributed with the videotape on a high density disk or disks. Since a large amount of the interactivity is contained within the quiz this will not be on the videotape and is therefore appropriate for students to access via computer.

Convert to Windows format

Finally, we will need to convert the Authorware file to the Windows format and package it for use. This has been done easily on smaller packages and should present few problems. This step is necessary since the majority of our external students will have Windows capable machines.

Conclusions

The processes involved in developing the package were not textbook correct and yet they allowed the package to be developed quickly, initially, and inexpensively. The choice of authoring environments and development hardware platform permitted a minimum of initial planning and the need for minimal briefings between development team members. The structure of the package was able to evolve gradually without incurring large costs to the project. The use of a specialist graphic designer and a programmer were crucial to the success of the project as was the instructional design experience and knowledge of the main author. Most of the problems in the development of the package resulted from instabilities and shortcomings in the authoring environment chosen. Despite this I still maintain that Authorware was the appropriate environment for the development of this package.

References

Ausubel, D. P. (1960). The use of advance organisers in the learning and retention of meaningful verbal materials. Journal of Educational Psychology, 51, 267-272.

Carlson, H. L. (1991). Learning style and program design in interactive multimedia. Educational Technology Research and Development, 39(3), 41-47.

Faiola, T. (1989). Improving courseware development efficiency: The effects of authoring systems on team roles and communications. Educational Technology, August 1989, 16-19.

Janson, M. A. & Smith, L. D. (1985). Prototyping for system development: A critical appraisal. MIS Quarterly, 9(4), 305-316.

Gagne, R. M., Wager, W. & Rojas, A. (1984). Planning and authoring computer assisted instruction lessons. In Walker, D. F. & How, R. D. (Eds), Instructional Software: Principles and perspectives for design and use. California: Wadsworth Publishing Company.

Henson, K. L. & Knezek, G. A. (1991). The use of prototyping for educational software development. Journal of Research on Computing in Education, 24(2), 230-239.

Mercer, N. & Fisher, E. (1992). How do teachers help children to learn? An analysis of teachers' interventions in computer based activities. Learning and Instruction, 2, 339-355.

Phillips, W. A. (1990). Individual author prototyping: Desktop development of courseware. Computers in Education, 14(1), 9-15.

Surber, J. R. & Leeder, J. A. (1988). The effect of graphic feedback on student motivation. Journal of Computer Based Instruction, 15(1), 14-17.

Author: Paul Newhouse, Lecturer in Computer Education, Edith Cowan University, 2 Bradford St, Mt Lawley WA 6050. Tel. 370 6469 Fax. 370 2910

Please cite as: Newhouse, P. (1994). The development of an interactive multimedia package to introduce computer communications. In C. McBeath and R. Atkinson (Eds), Proceedings of the Second International Interactive Multimedia Symposium, 371-376. Perth, Western Australia, 23-28 January. Promaco Conventions. http://www.aset.org.au/confs/iims/1994/np/newhouse.html

[ IIMS 94 contents ] [ IIMS Main ] [ ASET home ]
This URL: http://www.aset.org.au/confs/iims/1994/np/newhouse.html
© 1994 Promaco Conventions. Reproduced by permission. Last revision: 12 Feb 2004. Editor: Roger Atkinson
Previous URL 29 July 2000 to 30 Sep 2002: http://cleo.murdoch.edu.au/gen/aset/confs/iims/94/np/newhouse.html