Full Paper

Chris Browne

chris.browne@med.monash.edu.au

Department of Physiology

Monash University

Ainslie Ellis

aellis@fcit.monash.edu.au

Peninsula School of Computing and Information Technology

Monash University

Over the past two and a half years a collaborative multimedia project has been running to convert a series of seven morphometry practical exercises from their current pencil and paper chart format to an interactive multimedia format using the authoring language Asymetrix Toolbook (Ellis, A.E. and Browne, C. A. 1996). These morphometry modules have been developed for Dr. Chris Browne of the Physiology Department of Monash University by student groups from the School of Computing and Information Technology, supervised by Ms. Ainslie Ellis. Each module was developed by a separate group of students, who were allowed considerable design latitude within a set of basic guidelines. A final group of students has completed the process of bringing together the work of the seven parts into one coherent package.

This paper discusses this final stage in terms of ensuring correct functionality, consistency of coding, consistency of interface design and the appropriate integration of the note taking mechanism and the extensive help system. It also describes new work developed to allow for student login together with the development of appropriate user documentation for the entire system. It discusses issues relating to documentation, testing, software changes, modifications to existing work and standards development that have assisted in making this a potentially successful project. Some discussion of current and proposed evaluation is also included, as well as the issue of distribution.

Prior to the final stage, each of the seven exercises had been converted from charts to computer based learning modules using the Asymetrix Toolbook 3.0 authoring software. Each module consisted of three sections - a tutorial section, an exercise section and a question section. The tutorial section was essentially text based material with appropriate physiology terminology having hotword properties. The second section of each module consisted of a number of measurement exercises. Some also had ědrag and dropî exercises together with animations and expansion diagrams. The third section for each module comprised a series of multiple choice questions.

Each chartís conversion had been treated as a separate project. The first project produced a consistent navigation system, and a main menu and map, which were used as templates for each of the subsequent modules, each one duplicating these features to which the sections for that particular module were added. A context-sensitive help and notebook feature were also included, but each module had used differing mechanisms (ie. Toolbook, Microsoft Windows) to implement these.

Documentation for each project consisted of a project brief (indicating the scope and limitations of the project), a design document (storyboards and object hierarchy diagrams), script printouts for the more extensive and complex handlers, a testing strategy and a user manual, both in printed and electronic form.

The Asymetrix Toolbook authoring system uses the book metaphor for its design, providing a consistent look on a background, over which a number of pages can be laid when variations are required. Due to the total size of the combined seven modules (approximately 150 pages), it was decided to keep each module as a separate book, and to develop a controlling book that contained the main menu and hence entry into each of the modules. The alternative approach was to combine them all into one book. This would have had the effect of reducing the overall size of the product, but would have made it an unwieldy size for transfer from medium to medium. It would also have reduced the modularity of the overall product, and hence made maintenance, future upgrades and the addition of extra modules more difficult.

The nature of the morphometry exercises meant that each module was an independent entity and would normally be completed linearly, thus navigation within the tutorial was contained in the book for that chart. While each was independent, a consistent positioning and labelling of navigation buttons was used, so that each tutorial had a similar look and feel to avoid confusion. This was considered important as the users were unlikely to be experienced computer users. Hyperlinking between the modules was considered, but the small benefit of this option was outweighed by the disadvantages for novice users in presenting them with a complex layered navigation scheme. For the few situations where reference was required (currently only two) the appropriate material was copied and pasted into the relevant book.

Each project group had been encouraged to experiment with a range of interface designs, and these were evaluated by a number of students and demonstrators to determine which interfaces, screen formats, colour schemes, etc. were most acceptable. Once selected, each module was converted to show, where possible, the same colour scheme. A consistent look was used where the modules provided a similar function (ie. for the tutorial and question sections), and for similar operations (ie. drag and drop), but some licence was allowed where activities were quite different (usually in the exercise section) (see Figure 1).

One of the major activities for the final group was to develop a set of standards that would indicate a consistent approach for the overall project and would also dictate the design of future changes and subsequent modules.

The first stage of ensuring appropriate standards for the scripts was to develop a naming standard for all objects (eg. buttons, fields, pages, backgrounds) used in the various modules. While Toolbook has the ability to provide an identity number for objects, this is generated according to the objectís creation time in relation to the page or background it resides on. If objects are deleted or altered, this identity number may change, therefore it was essential that all objects, including pages and backgrounds, be named. The name had to reflect the module the object was associated with (eg. Cn - C for ěchartî and n for the module number), the section and page (screen) of the module (eg. Tn - for ětutorialî and n for the relative page number), type of object (eg. button, hotword), its function (eg. help) and its possible relationship to other objects (eg. group names) (see Figure 2). Once this was established, each module was checked to ensure all objects were uniquely named and each script checked to ensure all objects were referenced according to this new standard.

Backgrounds, pages and objects were set up to provide as much consistency as possible, in terms of attributes and placement, between screens and also between modules. A series of standards were established regarding such items as colour combinations, text font and size, field sizes, and button sizes and types (see Figure 3). Where variations occurred, a default setting was indicated with a range of allowable variations where the default was inappropriate.

During the development of the separate computer based learning projects, the students were encouraged to experiment with differing types and formats of help systems. While packages are available to create a Microsoft Windows style help system, this added an extra cost to the client, and so it was finally agreed for the final project, that a help system with a Windows style interface would be established, but that it would be created as a separate book using Toolbook. This allowed easy integration with the main menu structure book and the individual module books, yet provided a familiar style of help interface without any additional software costs.

The new book for the help system was created, and then the individual content of the various help systems for each of the modules was copied to the book. An extensive check was done to ensure the wording of help was consistent both within and between modules and all necessary elements had been included. All pages within each module has access to the help system via a button residing on the backgrounds within each book.

1. Title object is a transparent label button, caption position auto.

2. Title object is located above the top right corner of the text field.

3. Default Text style is MS Sans Serif font, bold, 18 (minimum size 12).

4. Text is white with grey shadow.

A note taking facility was considered to be an essential element of the overall project. As for the help system, the groups were encouraged to explore a variety of options to implement this feature. These included a Toolbook pop-up field which was written to a text file on close of the application; the use of the Microsoft Windows Notepad feature; and a separate Toolbook book accessed through the viewer system. Of these options, the Microsoft Windows Notepad feature was considered to be the best alternative because it was independent of the modules, and already had file handling facilities built in. This also meant that there was no extra size overhead for this feature and was likely to be familiar to some of the users, thus improving the user friendliness of the system.

At the clientís request, a login process and course management system were built into the final stage. The application has been designed so that it can be ěownedî by a single user, or can be made available in a laboratory situation to a group of users. Most students will access the application in the laboratory first, taking the package home to complete any unfinished portions, and using it for revision purposes.

This login process records the studentís name and unique identity number. This is used to label the Notepad file so that it can be retrieved later by the student. It is also stored in a text file independent of the application, so that the subject supervisor can identify who has used the application.

When a student is using the application, it is appropriate for him / her to be able to record their current progress point in the application and to be able to restart the application from this point. Toolbook has a history mechanism that was used to provide this feature. This was linked to the login information, a facility that is particularly important in the laboratory setting where multi-user, multi-session use is likely.

Each module had its own extensive set of documentation (ref to previous paper). All documents were reviewed for possible changes. Design documents (storyboard and object hierarchy diagrams) were reviewed and altered to reflect the separate book structure for the main menu process and to incorporate the login and history features, and the consistent approach for the help and note taking systems. The scripts were reprinted where changes had occurred to naming of objects and corrections to minor errors found during retesting. The user manual was reconstructed from the individual document files as a single document that displayed a consistent style. Having requested the original user manual documentation to be held in electronic form as well as hard copy, facilitated this operation. The new login and history were also described in the user manual, but the installation process will need to be added later as the delivery medium of the package and the appropriate installation process is not yet complete. New testing strategy documents were required to reflect the integration of the modules and the addition of the new features.

All modules had to be retested prior to integration using the original testing strategies to ensure their correct working. Once this had been done, the modules were converted to reflect the new interface and object naming standards, the new help and note taking systems, and the new login and history features. The testing strategies were then updated to accommodate these changes and the formal process of testing was repeated using the updated strategies. Having comprehensive testing documentation for each stage of the project proved invaluable, in fact, one would say, critical, to the success of this part of the integration process.

As this project commenced nearly three years ago, the authoring software has undergone several major revisions. As part of the final stage, it was agreed that the project would also be updated to the latest version (Asymetrix Toolbook II Instructor) of the software. This was achieved by ěscriptwalkingî (running the application through a provided piece of software that converts all references to files such as system books and dynamic link libraries) the old version to produce an updated version of the application, then copying the relevant pages to a newly constructed book that had the appropriate backgrounds already constructed. When a project may take a number of years to develop, or which may have a reasonable shelf life yet require ongoing modifications, one should consider carefully the choice of software. There are two major aspects to consider. First, how frequently does the manufacturer of the software produce new versions, and second, how are applications written using earlier versions of the software handled by later versions?

At this stage, only some informal formative evaluation has been completed to gain some comments on interface design, user friendliness, general appeal and comprehensibility. Now that the application is one integrated package, extensive formative evaluation will be carried out over summer by those staff who will supervise the use of the application at the practical sessions, and also with the target user group during classes in March of 1998. The purpose of these evaluations will be to make minor aesthetic changes and not major revisions. Issues relating to the forced sequencing of access to modules (ie. where some elements must be attempted before the user is able to access other parts of the application), and the possible need for hyperlinking between modules will also be explored in relation to their effect on the learning outcomes. Summative evaluation will be carried out after any changes have been made as a result of the formative stage. It is intended that a separate body (ie. the Centre for Higher Education Development) would be involved in this process.

Because of the size of the application (approximately 40 megabytes), it is most likely that the application will be distributed on CD-ROM as a stand-alone application in the first instance. For later distance education mode and distribution for overseas students, World Wide Web (WWW) delivery is being considered. As the content is fairly stable, the most likely mode in relation to WWW delivery would be to provide a CD-ROM that linked into other more volatile Web based material. The intention is to make this an ěat reproductionî cost (ie. the price of the blank CD-ROM) for distribution to Monash Physiology students as it is an integral part of their course. Strategies for marketing and licensing of the package outside Monash are currently under consideration.

Part of the purpose of this project was to determine the feasibility of an inter-faculty cross-campus staff-student collaboration to develop successful computer based learning materials. The success of this project has relied on a number of factors:

1. An appropriate aggregation of skills and a willingness of staff in separate faculties to collaborate in the development of computer based materials.
1. A commitment from the supervising staff member to provide the appropriate level of guidance and advice to the student developers.
1. A client who is willing to be an active participant in the stages of the development process.
1. The use of the untapped resource of undergraduate computing studentís skills to develop such projects.
1. The development of appropriate quality assurance processes and documentation guidelines (Ellis, 1996) to ensure that the separate stages of project development can be integrated into a cohesive and coherent product.

The experience gained through this project has empowered us to continue with further computer based education material development, and enabled us to promulgate this process to other academics across the university.

We wish to acknowledge the work of the three students - David Woon, Marty Lau and Frankie Chan - who formed the Industrial Experience group for this final stage of the project.

(c) Chris Browne, Ainslie Ellis

The author(s) assign to ASCILITE and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author(s) also grant a non-exclusive licence to ASCILITE to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the ASCILITE 97 conference papers, and for the documents to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.