Develop a Highly Usable VR System - and Do It Yesterday!" Continue...

Phase 2: Hello, I'm Your Avatar

A prototype system was created and demonstrated to trainers and prospective trainees at all three maritime training sites. In use each trainee begins by adopting a role - captain, chief engineer, first mate and so forth. They then put on a lightweight set of combined headphones and microphone to afford communication with other avatars and the trainer. Once a minimum of two trainees have entered the system, the trainer, who has been overseeing this process, starts the training scenario (Fig. 6.1). Avatars are able to communicate with one another by way of (virtual) radio and (virtual) telephone and are able to walk and run, open doors and pick up and operate fire extinguishers.

The trainer (or trainers) have all these facilities but have the God-like powers of being able to watch all trainees simultaneously, set fires and so forth as can be seen in Fig. 3.2. The training itself consists of working through a detailed scenario, usually drawn from a real world incident, which requires the trainees to role play and collectively deal with the problems which arise during the course of playing it out. At the end of the training, the trainer will debrief those involved and may use the play-back facilities of the DISCOVER CVE to illustrate particular points.

Demonstrations of the software and simple hands-on tasks were followed by interviews and questionnaires. Our intention was to give potential end users a clearer impression of what a CVE is, how it could be used, to elicit feedback which could be used to refine requirements. We had also evidently managed to convince our developers of the importance of usability issues, since they were particularly keen to have any problems of this sort identified. However, our intentions were confounded by the very prominence which usability assumed in these initial trials. Eager for early feedback, and understandably reluctant to undertake development which might be misdirected, our technologists delivered a prototype just as soon as the software could be run independently of its development environment. This meant that although a reasonable impression could be gained of the functionality which could be offered, user interaction was in a very immature state. As a consequence, finer grain usability issues, for example the ability to identify the focus of an avatar's gaze, were obscured by larger difficulties such as moving through the environment. Equally users could not be induced to speculate in depth about how the system might be used, or how training delivered through such a medium might relate to existing practice. For example, it is difficult to convince the captain of one of the world's largest passenger vessels of the possibilities of the new medium after difficulty with movement control has "trapped" him for some minutes in a corner of the virtual bridge. However, some indications did emerge of the type of usage envisaged in each training context, and much debate was triggered about the detailed design features which would be necessary to support these.

The developers now urgently required a unified, detailed, concrete design specification which would nonetheless support each intended context of use. This was to be achieved by means of a workshop involving each of the three maritime organizations. (There was only one offshore organization in the project, whose requirements were relatively unified and straightforward.)

Phase 3: Virtual Reality Meets Paper and Pen

At this two-day event, trainers from the three organizations met with the representatives from one of the software developer organizations and two facilitators from the requirements team.

The agenda was very simple: to agree the detailed functionality of the maritime simulator and how it was expected to be used. We adapted elements of Contextual Design (Holtzblatt and Beyer, 1998) to facilitate these processes, principally a variant of the affinity diagram technique, which supports the identification of common themes from a mass of contextual data. We began by asking each training organization to revisit what they wanted of DISCOVER in terms of the "w" words (familiar to user-centred design practitioners), i.e. why, when, who, where and of course, how. As each organization described their needs we recorded each issue or explicit requirement on a Post-IT® note. At the end of the process we had gathered over 400 Post-ITs of which approximately 10 per cent were subsequently discarded as duplicates or irrelevant on closer inspection.

The trainers were then invited to create an affinity model which required them to sort the requirements/issues into logical groups: emerging groupings included the layout and configuration of the virtual ship, the appearance and functionality of the avatars and the context of use of the completed system. Throughout this process the software designer helped ground the requirements in reality. Informal discussion with the three trainers afterwards revealed that they thought that the day had gone well. The use of the Post-Its and their grouping was a familiar technique from other contexts, and had fostered engagement and apparent consensus. At the end of the first day we had succeeded in co-constructing an affinity model and subsequently a communications model and an artefact/physical model (ibid.) of the environment to be created.

Develop a Highly Usable VR System - and Do It Yesterday!"

The project had identified a number of key areas which needed specialist attention. These were to:

• Produce a definitive statement of requirements on the DISCOVER system from the training organization. This involved understanding the methods used in current training, which ranged from state-of-the-art physical simulators costing tens of millions of pounds, to simple role playing, and their methods of assessment.
• Adopt a suitable pedagogic model for the training environment.
• Understand how we were to validate the DISCOVER system with the appropriate validating bodies. The project had ambitions to sell the system across the world to a number of shipping and oil companies and thus required a suitable seal of approval.
• Produce for the software designers a detailed description of the virtual environments to be modelled and a list of the objects and their behaviours therein.
• Specify a collaborative virtual environment with a strong emphasis on fidelity and usability.

Match the system to current and proposed training scenarios. And we had three months to complete this in the first instance!

Phase 1: Just What Should a VirtualTraining System Do?

Some requirements work had been carried out before our entry to the project, but this had simply taken the form of the collection of high level statements of intent from the training companies and lists of competencies (or skills) to be trained. This provided our first political advantage: working closely with managers and training personnel in the user companies in itself convinced these project partners that their needs were being seriously considered. Thus our activities tended to be viewed in a constructive and receptive way. We will not provide a detailed description of the techniques we used, since they are familiar ones, but we employed a combination of interviews with trainees, trainers, their managers, observation and video- recording of training sessions and the collection of relevant documentation. All this took place at user sites. Again, goodwill was generated simply by the amount of effort very clearly being devoted to the user-centred work.

The results of this fieldwork fed into a large group of requirements relating to the way in which CVE based training could best be used in its particular intended context. Fortunately, although CVE design is a young field, there isan emerging body of literature which addresses generic usability issues for single users (e.g. Stanney et al., 1998; Sutcliffe et al., 2000) and in the collaborative context, the guidelines provided by the COVEN project (Normand et al., 1999). Thus we were able to supplement our own primary findings with secondary material from the literature and produce a large body of user-related requirements material in a relatively short time.

The Use of the MoSCoW Method

At this stage we had a large set of requirements in clear need of prioritization. In keeping with the user-centred philosophy which we had started to foster, this would be done in conjunction with the user companies. The MoSCoW technique from the Dynamic Systems Development Method - DSDM, (Stapleton, 1997) afforded a means of doing this which would be readily understandable to users and familiar to the developer partners in the project. DSDM prioritizes requirements using the MoSCoW rules.

The uppercase letters of the acronym (the o's are only there to make for a memorable acronym) stand for: Must have for requirements that are fundamental o the system. Without them the system will be unworkable and useless. The Must have category defines the minimum usable subset. Should have for important requirements for which there is a work-around in the short term but the system will be useful and usable without them. Could have for requirements that can more easily be left out of the current development. Want to have but won't have this time round for those valuable requirements that can wait till later development takes place. A small sample of the prioritised requirements follows below A substantial subset of the higher priority lists related to usability and other non-functional concerns.

• lMust: The ability for trainers to increase stress in a safe, controlled manner for the trainees.
• Should: Provide a more satisfying professional role for trainers than classroom teaching.
• Could:Courses formally validated by the appropriate standards bodies.
• Want：Measures of trainingtransfer.

By now, therefore, we had an substantial body of organized and prioritized requirements which formed the main body of the requirements and evaluation deliverables to the funding body. These reports passed their review, user-related concerns were accepted as the main force driving the design of the software and the project moved forward.