• Assembling a development team with the technical, academic and pedagogical knowledge required
  
• Identifying the roles, both formal and informal, required in the team and the relationship between those roles in determining the design requirements and the setting of appropriate goals; and
  
• The involvement of students in the team during the early stages of the project.

Introduction

Chemical reactor engineering is a well-established subject that is treated comprehensively in standard texts, yet students often struggle with the topic. After teaching the subject for a number of years using various approaches the idea of teaching the subject using a multimedia approach arose.
A multimedia package, named ReactEd has been developed, which consists of:

• A series of computer-based tutorials
  
• A reactor simulator with which users can test reactor performance, and
  
• A workbook containing summarised notes, exercises and utilities
  

This package takes a dual approach to reactor performance, utilising mathematical and graphical analysis techniques.
In this paper we present the process of development of ReactEd, in terms of three distinct project phases (figure 1) - the Individual Development (ID) phase, the Serial Group Production (SGP) phase and the Iterative Team Development (ITD) phase. The working paradigm in each phase places specific constraints on both the roles of individuals and on the product development, such that a transition to a new working paradigm (phase) is necessary to make progress.
The transition processes between development phases are themselves critical to the project as they represent periods of significant shifts in focus, team development and roles.
The ID phase was typical of a new project in that an individual academic envisioned an end product that would comprehensively encapsulate his knowledge and aid (if not replace) face-to-face teaching. It was characterised by an underestimation of the size of the development task and unrealistic expectations regarding the size and breadth of the final product.
The SGP phase represented a shift to a joint effort with the academic directing multi-media specialists in graphic design and interface programming. This phase was characterised by a serial production mentality in which the academic, acting as both subject expert and instructional designer, passed on subject material to the graphic designer who, in turn, passed on screen designs to the programmer for implementation.
Transition to the ITD phase occurred only after sufficient funding was obtained to allow an instructional design expert and further multi-media specialists to be brought into the group. This latter phase was by far the most productive and was characterised by comprehensive communication between all members of the team, where constant feedback was used to design and construct the end product in an iterative fashion.



Figure 1: Emergent development phases of the ReactEd project


The Independent Developer Phase
In this phase the individual academic had identified a need and matched it with a conceived solution - ReactEd. This phase might equally well be termed the "hobby" phase, as the initial plan was for the academic to develop the package independently during "spare time" - in addition to all other work (figure 1). The package as originally envisioned was extremely comprehensive - virtually a full textbook on-line, complete with:

• Animated graphics
  
• Full instructor control over the students' navigation through the package
  
• Class lists and automated progress tracking of individual students
  
• On-line submission of work for assessment
  
• Automatic assessment and return of submitted work; and
  
• A reactor simulator

The original vision did not stop there - after ReactEd, other packages were to quickly follow ("HeatEd", "ControllEd", "DistillEd", "SeparatEd"), based on the same format, interface and underlying architecture, simply with different content.
A key component of ReactEd was to be a reactor simulator - "The Reactor Factory". Given the difficulty in providing students with hands-on experience of real reactors, it was considered essential to take advantage of the very real capability of the computer to offer this advantage over conventional lectures.
Not only would this be the key to making the package different from existing tutorial-only packages but it would provide an opportunity for students to cement their learning of the theory to the practice.
The reality, of course, did not match this original vision. Too little "spare time" time was available for one person to generate adequate forward momentum. The academic's department was therefore persuaded to sponsor a part-time student over a 3-month summer period to work on ReactEd in collaboration with a graphic designer from The University's Information and Technology Services division.
At this stage the academic had not given up on the original vision, either in terms of scope or development method. It was thought that the outcome of this limited work would be a set of templates that could merely be linked together as needed, with the content filled in at a later date. However, as work progressed it became clear that considerable investment was required, and that the project required a group, rather than a solo effort. This recognition marked the beginning of the transition to the Serial Group Production phase.


The serial group production phase

Generally speaking, in production projects the methods and processes undertaken to construct a product exist already and the parameters and scope of such projects may already be known and understood. The group started work from this perspective, with the assumptions that the academic knew in advance how the subject content should be presented, and that the other members of the group knew how to implement it.
The transfer of material and tasks was seen in serial fashion, beginning with academic content, moving through graphic design to the implementation (programming) of navigation, control and transition features (figure 1). However, over time it became clear that ReactEd contained a number of areas for which existing tools and methods did not exist - in particular the reactor simulator, which required extensive modelling and interface design.
Towards the end of the summer project, consultations with an expert in instructional design brought the first touches of reality to the vision. For example, up to this point the needs of the students had been considered only in vague terms. What had not been considered were the practical aspects of computer-aided instruction. How long could a user be expected to sit in front of a screen at one sitting? Who were the students and what was their background knowledge?
How many screens would be needed to encapsulate each quantum of instructional content. How long would it take and how much would it cost to produce these screens?
Once the above aspects had been recognised, the focus changed toward constructing a demonstration of concept product to be used to gain sufficient funding for a full package to be developed.
The serial method of working was actually well suited to the development of a demonstration of concept product. Teaching functionality was no longer required, so that the graphic designer could merely request information from the academic and design the graphics mainly for visual appeal. No modelling was required for demonstrating the reactor simulator, only animated graphics.
The programmers could use placeholders for graphics when implementing navigation elements. The flow of information and material therefore was largely serial. The main interaction between the academic and the instructional designer now consisted of trying to estimate the scope of the project and therefore the time and costs involved, rather than trying to refine the instructional design. Even this interaction was somewhat serial in nature - the instructional designer using typical project management tools such as Gantt charts, with the academic responding to requests for estimates regarding issues of content.
The paradigm during this phase was one of a group of experts each coping relatively independently with their aspects of the project, with interactions mainly consisting of handing on material from one expert to the next or passing requests for information one way or the other. As illustrated in figure 1, there was little need for interaction between the academic and the programmers.
The role of the evaluators was very definitely serial in that they were not to be included in the group until the product was virtually complete and ready for testing. Students were included only implicitly through the combined experiences of the graphics and instructional designers.
Two major outcomes resulted at the end of the summer project. First, a demonstration of concept model was completed. Second, the intended user group had been defined, and the scope of the proposed package trimmed down to introductory chemical reactor engineering, although still containing the Reactor Factory as the "flagship" component. This meant concentrating on producing a high quality product which, if successful, could be followed by more comprehensive updates, version by version.


The iterative team development phase

The need to obtain funding to take ReactEd to full development required a budget and a detailed project proposal. However, because previous work involved mainly a serial process, the proposal and the corresponding budget did not incorporate the element of team work. This is not an insignificant overhead in a project. After gaining funding, the team comprised a project manager, an academic, a graphic designer, an instructional designer, two programmers and an evaluator. This group was funded on a partial cost-recovery basis so the arrangement for purchasing - staff time was very similar to that in a commercial one, although at much lower rates. This has both negative and positive side effects as shown in Table 1.
Once funding was obtained and there was a need to develop a functional simulator the project became more complex (figure 1c) and relationships between project members changed. For example, the designers' (graphical and instructional) roles and academic's role now conflicted as follows:

• The designers' view
  
• Content is King Do not force the expert to present the content in any set way, because the design of the package must work for the academic content. Therefore the content should come first
  
• The academic's view
  
• Design is King The academic knows the subject very well but needs a framework within which to present the subject matter. Therefore the design must come first
  

Table 1. Effects of Cost Recovery Basis for Funding Project Team

Negative	Positive
Time and resources become limited to those in the budget, and cannot be added to by anyone's spare time.	Project moves away from hobby to a more formal or business-like one.
Decisions about which aspects of the project are essential and which are luxuries have to be made early.	This helps keep out the creeping feature problem (i.e. adding features because there is time to do so).
Flexibility to look at alternative solutions to problems is reduced.	The project becomes limited to achievable goals.
Time limits are imposed on tasks early in the project without knowing the feasibility.	There now is an allocated workload for the development group staff, which helps in planning when effort is required.
Overspending on one part of the project curtails other aspects.	Reduction in the risk of excessive tweaking, people start to understand the risk of spending time on one part of the project at the expense of another.
Formalising the workload imposes obligations on all members of the team to provide input/output as specified.	The academic now takes a continuous role.
The person who had the idea for the project has to give up some control in the project.	Responsibility for the success or failure of the project becomes more evenly distributed.

Defining the content material for the two main components of ReactEd was not a simple task. Software developers often have no understanding of what it is like to be a novice computer user, so they design systems and interfaces which novices cannot use. This is also the case in instructional design where the academics have lost any understanding about what it is like to be a novice in this area. The end users of ReactEd are likely to be novices both in reactor engineering and in using computers.
This highlights another potential problem area, namely, how much the members of the team should know about the subject matter. If the team members are familiar with the subject matter then communication is enhanced through a shared understanding of terms, but there is likely to be less questioning of the material (less ambiguity, less cause to question), and the academic has no need to keep explanations simple. If the team is not familiar with the subject matter then communication may be adversely affected by the repeated need to explain and the team members have little ability to judge the accuracy or effectiveness of their implementations.


Students as part of the team

The team needed some way of identifying elements that were appropriate for reactor engineering novices and so carried out interviews with students. The project manager, the instructional designer and the graphic designer carried out the interviews. At all times the academic, who had previously taught the students, was separated from this process to ensure students felt comfortable and that their responses would be treated in confidence and would have no effect on their educational program. This ‘distance’ was also kept in the evaluation later in the project. The students had undertaken the course in a previous semester so were familiar enough with the course to explain their understanding of the material and identify elements they had found hard to learn. Their involvement played a decisive role in the development of the Reactor Factory and the tutorials.
The students identified a number of areas of difficulty, including:

• Identifying the context in which reactor engineering problems occurred
  
• Linking the theory to the practical consequences
  
• Defining reactor engineering problems adequately; and
  
• Judging the adequacy of their solutions

These were not trivial issues and their difficulties were exacerbated by a short time frame within which to learn the material. Following their comments the design adopted reflected a more structured approach to both Reactor Factory and the tutorial package than originally anticipated. For example, the Reactor Factory was subsequently divided into sections according to the considerations usually required for analysing or defining reactors:

• Choosing the reactor type or system
  
• Defining the chemical kinetics
  
• Setting up temperature and heating effects; and
  
• Setting the values of operating variables, such as input flow rates, feed reactant concentrations, etc

The main screen of Reactor Factory (figure 2) indicates not only the reactor performance but also summarises the system under study and important features of the reaction stoichiometry and rate constants. A slider allows users to alter appropriate variables during a simulation so they can explore the effects of operating variables on performance. Links to the set up screens are always available.


Figure 2: The main screen of Reactor Factory


Defining the chemical kinetics is potentially a complex process, so the setup screen (figure 3) is divided into sections that guide the novice user through the process while maintaining as much flexibility as possible for the advanced user.
The building of the Reactor Factory simulator was undoubtedly the most challenging aspect of the project, as it required modelling capabilities and extensive fault checking during development.
In retrospect, the development of the simulator should have involved a closer collaboration between the programmers and the academic. Some training of the programmers by the academic in the subject area would have reduced the load on the academic for fault-checking and would have made communication regarding where the model was malfunctioning much easier.
For instance, at one point a calculated reactor performance parameter took on negative values under some circumstances when in fact the parameter could not do so if calculated properly. Recognition of such facts would have sped development. On the other hand, the academic did not have time to learn the programming language independently. Therefore upon detecting a fault, even simple fixes by the academic were not easily implemented, even if the cause of a bug was relatively apparent. Regular meetings in which the underlying architecture of the simulator could be explained as it was developed and then discussed in relation to the reactor modelling would have been of immense value.
The project would have benefited as faults in logic would have become evident early, minimising time spent checking for modelling accuracy and identifying sources of bugs, while the academic would have benefited additionally from learning the structure and language of "Lingo", the programming language used. Further benefits would have then accrued as the academic could not only identify malfunctions in the simulator but also identify and in some cases fix the appropriate sections of computer code independently.



Figure 3: The chemical kinetics set up screen


The tutorial component of ReactEd now includes:

• An introduction section on the different problems to be solved in reactor engineering;
• A consistent pattern of navigation and presentation of material for each reactor (figure 4);
• Facts about each reactor type and its conditions of use;
• Mathematical derivations of performance equations shown with examples and exercises, the answers of which are tested using Reactor Factory; and
• Exercises for the determination of reactor performance and reaction kinetics that also utilise Reactor Factory.

Figure 4: A typical tutorial screen, showing consistent navigation and content areas


The modules not only contain explicit learning objectives but also reviews of previously presented and material to be presented in following modules, providing the context sought by students (figure 5).



Figure 5: A milestones screen, used at the end of each tutorial module, indicates where the material sits in the problem-solving chart


Conclusions

The product is nearing completion but development of ReactEd has taken much longer than originally anticipated. It is conceivable that a serial approach might have kept the project within budget and on time. However, the likelihood is that the quality of the overall product would not have been as high. In particular, without the successful completion of Reactor Factory, the ReactEd package would have been restricted to a tutorial-only release.
Unlike tutorial content, which can be trimmed as necessary to reduce time and cost, the simulator had to be either fully operational or excluded. We believe that the successful completion of Reactor Factory in particular required the ITD phase of development, in which all members of the team, including students, worked in an iterative fashion to design and produce the package.
New projects of this kind usually arise from an individual recognising an opportunity to apply computing technology to their teaching. Our advice to those who might be contemplating the development of a new multimedia teaching package is to shorten the transition time from the ID to the ITD phases of the project, by recognising that

• The project initiator (usually an academic) is unlikely to produce a comprehensive package in isolation and in addition to their normal duties
  
• A serial production method, while perhaps minimising risk, is unlikely to create a novel, optimal product
  
• A project team containing an appropriate mix of skills, working closely together under a flat management structure, can develop a synergy that significantly improves the project outcome
  
• The team should involve students at a very early stage in the project.

Acknowledgements
The members of the ReactEd development team are Conan Fee, Chris Knowles, Sheree Bennett, Shaun Nicholson, David Hunt, Paul Kennett and Karleen Kopa. This project was generously funded by the Vice Chancellor of the University of Waikato. The authors gratefully acknowledge the support of the School of Science and Technology, the Department of Technology, and the Information and Technology Services of the University of Waikato.


Contact details

Conan Fee Senior Lecturer Department of Technology University of Waikato, Private Bag 3105, Hamilton, New Zealand Phone +64 (7) 838 4206 Fax. +64 (7) 838 4835 Email: c.fee@waikato.ac.nz Website: http://www.tech.waikato. ac.nz/staffpages/conan.html

Chris Knowles Education Projects Consultant Information Technology Service University of Waikato, Private Bag 3105, Hamilton, New Zealand Phone +64 (7) 838 4466 x7714 Fax +64 (7) 838 4066 Email: chrisk@waikato.ac.nz Website: http://campus- media.its.waikato.ac. nz/people/chris.html