getting the story straight

Getting the story straight


Phil Turner, Susan Turner and Rod MCCall

HCI Research Group, School of Computing, Napier University,Edinburgh, EH14 1DJ, UK.

EMail: [email protected]@[email protected]

We argue that the use of a user-centred design approach necessarilyinvolves some form of storytelling or narrative. Given that both thepotential end-users and the designers themselves often (perhapsusually) have different interests and points-of-view to present, theresultant co-constructed narrative describing the desired interactivesystem is inevitably the product of compromise. We describe how suchan unwanted compromise can arise and how the process by which itarose can be unpicked using Bakhtin's approach to the analysis ofnarrative.

Keywords: narrative, user-centred design, collaborative virtual environments,requirements.

1 Introduction

Anyone who has used the techniques of user centred design will agree that theprocess is far from fool-proof. It is not unusual to be surprised by the ficklenessand wilfulness of users. Here we describe not so much a surprise but a volte face inan account of the use of a user-centred design approach to the design of acollaborative virtual environment (CVE). In an attempt to understand why this hadoccurred that we have investigated the usefulness of narrative as an explanatoryframework. This paper, then, is a story about stories: a narrative about narrative.The focus of this narrative is the relationship between narrative itself (e.g.Pentland, 1999) and the use of user-centred design (e.g. Bødker and Grønbæk,1998; Holtzblatt and Beyer, 1998). We show how the co-construction of a narrativeabout the requirements on the CVE created a myth of homogeneity andconsistency. In particular, we are interested in how the multiple 'voices' of the end-users were apparently harmonised.

Our starting point is the recognition that user-centred design has some form ofstorytelling at the heart of the process. A typical user-centred design interventioncomprises a series of “design episodes” which may take a variety of forms rangingfrom workshops to individual and group interviews. These design episodes are

Phil Turner, Susan Turner and Rod McCall

frequently characterised by the planned and spontaneous use of scenarios byanalysts and end-users respectively, each contributing to the co-constructed overallstory of what artefacts will be created and how they will be used. To understandthe structure and dynamics of these design episodes we need an appropriatescheme of analysis (or at the very least, a means of expression) which allowsimportant points of detail to be captured while preserving their context and thustheir essentially situated nature. We propose an overall narrative structure for theprocess (c.f. Lloyd (2000) who analyses an engineering design case study as asocially constructed narrative).Within this overall structure can be found individualnarrative episodes which in turn comprise a series of utterances (the use of thisterm is described in section 1.2).

We believe that this framework offers us a means of understanding both thestructure and dynamics of this particular user-centred design process, and byextension, other ventures of this nature. Accordingly, this paper begins with a briefreview of narrative methods in user-centred design and the contribution of MikhailBakhtin, as applied to the current context. We then introduce the DISCOVERproject, its aims and participants. We continue with a discussion of the intendedand unintended aspects of the design process in DISCOVER, highlighting aspectsof story and myth within a multi-voiced narrative framework. The paper concludeswith a discussion of the moral of our cautionary tale and some tentativerecommendations arising from it. (Note: we use the terms ‘user-centred design’and ‘the design process’ as a general label for the set of activities fromrequirements to design via iterative early evaluation.)

1.1 A brief account of narrative applied to user-centred design

Aspects of narrative in user-centred design are primarily evident in the well-knownbody of work which has developed and promoted the use of scenarios andassociated stories as a means of communication between users and designers.These stories typically involve enabling exploration of design options anddocumenting of intended usage (e.g. Bødker, Grønbæk and Kyng, 1993; thePICTIVE method, Muller, 1993; Carroll, 1995; prompted reflection, Kensing,1998); contextual design, Holtzblatt and Beyer, 1998; Imaz and Benyon, 1999among very many others.) As will be seen, scenarios and stories of varying degreesof structure have been central to the design process in the current study.Secondly, analysis informed by narrative methods has been brought to bear as ameans of understanding everyday activities. Recent instances include Davenport,Higgins and Somerville (2000) who employ narrative as a framing device for theirenquiry into domestic use of new media devices. More directly relevant for ourcurrent case, however are Lloyd’s ethnographically-based study of engineeringdesigners (Lloyd, 2000) and the argument presented in Pentland (1999) for theexploitation of the components of narrative as a basis for generalisation beyondindividual case studies while preserving “the details and the drama”.

Lloyd makes four main points about the role of narrative in the designprocess: in the explanation of the design process to others; in the construction andtelling of stories by individual designers; as competing accounts of the sameobject, so a specification may be regarded as a flexible resource for efficient selling


in the salesman’s discourse, but a defined starting point for the designers (c.f.Bakhtin’s multi-voicedness, next section); and as the socially constructed meta-story of the process itself. All these can be found in the project case study underdiscussion here.

Pentland’s paper advances a more generic argument for narrative as aframework for research in collaborative systems. It is contended that much existingresearch in this domain measures and compares individual variables at the expenseof context, or removes narrative fragments from their original setting, oftenreorganising such fragments thematically, or produces descriptive accounts ofindividual cases from which it is almost impossible to generalise. Pentland’sargument draws inter alia on Bruner (1986), who suggests that narrative is centralto an individual’s understanding of the world, and Heritage (1984) and Goguen(1997) who emphasise the importance of the way narrative accounts of one’sactions embody the values of the relevant social context. It is thus proposed thatsince narrative is central to social life, narrative analysis should similarly be centralto research in collaborative systems, affording a medium between theidiosyncrasies of individual cases and the de-contextualised comparison ofvariables. As a practical means of incorporating narrative methods into the analysisof a collaborative system, Pentland advocates an adaptation of Burke’s (1969)framework for the dramaturgical analysis of narrative. This comprises the actor,the act undertaken, the scene (or context), the agency (or tool) and the purpose. It issuggested that the framework can be used to highlight, for example, between twoapparently similar systems for computer-related problem reporting. Differences inusage of the systems could be accounted for in terms of purpose.

Our approach to the collaborative activity of the DISCOVER design processhas much in common with Pentland, although, for reasons to be discussed below,we have used Bakhtins’s approach to narrative.

1.2 Bakhtin's approach to narrative

The Russian academic, Mikhail Bakhtin (1895-1975) has written widely onnarrative, though for reasons of space, this brief introduction cannot do him justice.We have restricted our introduction to Bakhtin's work to those areas we believe arerelevant to user centred design, namely, the role of utterance, voice and, indirectly,dialogicality. While the majority of the commentaries and applications of Bakhtin'swork have been literary, Moro (1999) and Wertsch (e.g. 1991, 1998) have un-picked many interesting aspects which have particular relevance to both situatedand mediated action and, as we hope to demonstrate, to user centred design.

Wertsch (1998) introduces Bakhtin's work in the context of his own socio-cultural research. Wertsch argues that "language is a cultural tool" and "speech is aform of mediated action", (ibid, p.73). According to Bakhtin, speech comprisesutterances. An utterance is "oriented towards an addressee, towards who thataddressee might be: a fellow-member or not, of the same social group, someoneconnected with the speaker by close social ties or not" - Bakhtin et al., quoted inMoro (1999), p.168. Thus in the context of user centred design, language mediatesthe interplay between designer and user with the utterance being the appropriateunit of analysis.


1.2.1 The role of utterance

An utterance is speech terminated by a change of speaker. Utterances exchangedbetween speaker and listener are the "links in the chain of speech communication".Bakhtin observed that each speaker [or, author of an utterance as he phrased it]constructs each utterance as a response to "other viewpoints, world views, trends,theories, and so forth" embodied in the utterance to which he or she is replying.This turn taking between speaker and listener is active on both sides: "the person orpersons from whom the author [speaker] expects a response—"the addressee"—isan active participant in the chain of speech communication, for whom the entireutterance is constructed in anticipation of the response" (this introduces the conceptof addressivity). Thus utterances are "determined by whose word (utterance) it isand for whom it is meant" (ibid, p.86)

Utterances also comprise repeatable and unrepeatable components. Therepeatable elements of the utterance, are for example, the words while theunrepeatable components include the context in which the utterance was spoken,its stress and intonation and its " honesty, truth, goodness, beauty and history",(Bakhtin, 1986). However most importantly to attend to one at the expense of theother is fundamentally misleading.

1.2.2 Voices

The notion of an utterance is closely linked to that of a voice. A voice is "thespeaking personality, the speaking consciousness". An utterance reflects a point-of-view which is Bakhtin's definition of a voice. A voice is similar to the English useof the word 'hat' to indicate a temporarily adopted role or point-of-view - as in"speaking with my research hat on I think x, but with my teaching hat on I believey".) Voices exist in a social milieu and cannot exist outwith a social context.Meaning can only come into existence when two or more voices interact - thevoice of the speaker and the voice of the listener. Thus he insisted that both voicesshould be taken into account (again a reference to the addressivity of an utterance).

1.2.3 Bakhtin in summary

We have established:− that an utterance requires an active listener. An utterance is unrepeatable and

highly contextual and that an utterance depends upon a voice which reflectsthe point-of-view of a speaker. The chain of speech communication, in thecase of user centred design, is the effectively the current state of the design orstatement of requirements.

− Casting ourselves in the role of 'honest broker' or 'facilitator' in a user centreddesign intervention is necessarily disingenuous as we are active participantspursuing our own agenda; inevitably participating and directly influencing thedesign process rather than simply neutral collators and sorts of information asit is so often portrayed.


So, given a user-centred design approach, we may have a potential framework forunderstanding the structure of design episodes (narrative) and their dynamics(Bakhtinian utterances and voices).

2 The DISCOVER project – background and methods

Our case study draws upon the DISCOVER project. DISCOVER intendsdeveloping a collaborative virtual environment to support training in safety criticalskills for the offshore and maritime industries. Effective safety-critical training inthese domains is crucially important. The undertaking is almost prohibitivelyexpensive, since trainees are co-located at a specialist training site for several daysat a time, or in the case of the offshore industry, hugely complex disastersimulations which are created in situ involving the coordination of large numbersof personnel and multiple agencies. DISCOVER will provide a series ofcollaborative simulations which could dramatically reduce the need for seniormariners and oil rig workers to have to attend courses or run quite so manyexpensive exercises. It is envisaged that while the system will be made available atexisting training centres, it will also be used offshore or on board ships morefrequently and in, perhaps, an ad hoc manner. The CVE will enable trainees topractice dealing with emergencies within a safe virtual world. For example,practising the management of extinguishing a fire while at sea and evacuatingpassengers.

The immediate intended end-users of the DISCOVER CVE are four trainingorganisations. One of these organisations is concerned exclusively with theoffshore domain (i.e. oil platforms) while the other three DMI, ISSUS and WMCtrain senior mariners. For the sake of simplicity we confine our discussion to themaritime domain only.

Using a perspective which is itself informed by narrative methods, we nowconsider the effect of storytelling techniques as part of the user-centred design inour case study, and speculate on the reasons for some unintended effects.

2.1 First phase requirements elicitation – a story is constructedThis first phase of the requirements elicitation employed a number ofuncontroversial approaches primarily drawn from established user-centredmethods. A first phase of requirements elicitation was followed by a seconditeration using an early prototype of the DISCOVER collaborative virtualenvironment and techniques drawn from the Contextual Design method. The firstiteration of the requirements work comprised:

Six periods of observation of trainingsessions.

Two periods of observation oftraining sessions at DMI.

Interviews with officials fromtraining validation bodies.

Interviews and use of what-ifscenarios with trainees and trainers atWMC, DMI and ISSUS.


This yielded a set of high level requirements which were subsequentlyprioritised by stakeholders using the MoSCoW technique from Dynamic SystemsDevelopment Method (e.g. Stapleton, 1997). A sample of these requirements is asfollows (headings are those stipulated by DSDM, numbers were added forconvenient identification):

Must have Should have Could have Want to have butwon’t have …

1. Robustnessand reliabilityofsimulations.

2. Support forrole-playing,and switchingof roles.

3. …

67. Validation oftraineeidentitythroughouttraining.

68. A familiaruser-interface.

69. …

82. Ability tosimulate fullydetailedinstances ofindividualships and off-shoreinstallations.

83. …

102. Measures oftrainingtransfer.

103. Integration ofpre-trainingpsychologicalor aptitudetesting.

104. …

The requirements were agreed by all parties to the project, and subsequentlyembodied, together with sample usage scenarios, in a document supplied to oursponsors, the European Commission. And here was the first instance in which thedemands of constructing a common set of requirements and thus a cogent story foran outside audience (an activity which in itself helped the project to cohere) mayhave obscured rather than resolved underlying multi-perspectives of the users (i.e.their multi-voicedness). As can be seen, the requirements are both high level anduncontroversial, although many of the full set could not have been predicted beforethe fieldwork had been undertaken. Few would gainsay, for example, thatsimulations must be reliable, or that it should be possible to confirm the identity oftrainees undergoing training. However, it was possible to sign up to this version ofevents in good faith, and still hold quite radically different assumptions andintentions in mind, as will be evident later.

2.2 Losing the plot in exploring the prototype

Using an early prototype is, of course, a well proven technique for eliciting furtherrequirements on the complete system. A working prototype system was created anddemonstrated to trainers and prospective trainees at all three maritime trainingsites. Our intention was to give the end users a clear impression of what a CVE is,how it could be used and to elicit feedback.

Demonstrations and simple hands-on tasks were followed by interviews andquestionnaires. What happened in practice is that, because of the early stage ofdevelopment of the software, usability issues assumed such a degree of prominencethat users could not be induced to speculate in depth about how the system mightbe used, or how training delivered through such a medium might relate to existingpractice. For example, it is difficult to convince the captain of one of the world’slargest passenger vessels of the possibilities of the new medium after difficultywith movement control has ‘trapped’ him for some minutes in a corner of the


virtual bridge. However, some indications emerged of divergent usage intentionsand underlying purposes, and triggered much debate about the detailed designfeatures which would be necessary to support these.

The developers in the project now urgently required a unified, detailed,concrete design specification which would nonetheless support each intendedcontext of use. This was to be achieved by means of a workshop involving each ofthe three maritime organisations.

2.3 Mythmaking: The requirements-to-design workshop, day 1

At this two day event, trainers from the three organisations met with therepresentatives from one of the software developer organisations and twofacilitators from the user-centred design team (the first and third authors).

The agenda was very simple: to agree the detailed features of the maritimesimulator in the light of how it was expected to be used in practice. We adaptedelements of Contextual Design (Holtzblatt and Beyer, 1998) to facilitate theprocess, principally a variant of the affinity diagram technique, which supports theidentification of common themes from a mass of contextual data. We began byasking each training organisation to revisit what they wanted of DISCOVER interms of the ‘w’ words (familiar to user-centred design practitioners), i.e. why,when, who, where and, of course, how. It should be said that we did not hearanything we had not heard before but we used this restatement as both a startingpoint and trigger for exploring the design features of the DISCOVER collaborativevirtual environment. As the representatives from the training organisation spokewe noted each issue or explicit design feature on a Post-IT™ note. These were

Figure 1: end-users creating an affinity diagram


summarised as a word or two and in some cases a short phrase. At the end of theprocess we had gathered over 400 Post-ITs of which approximately 10% weresubsequently discarded as duplicates or irrelevant.

The trainers (rather than the analysts in the canonical use of ContextualDesign) were then invited to create an affinity model which required them to sortthe issues into logical groups as illustrated in figure 1. Emerging groupingsincluded the layout and configuration of the virtual ship, the appearance andfunctionality of the avatars and the context of use of the completed system.Throughout this process the software designer helped ground the design details, i.e.he commented upon whether or not the desired functionality could be achieved. Atthe end of the first day we had co-constructed an affinity model and subsequently acommunications model and an artefact / physical model (ibid) and of theenvironment to be recreated.

Informal discussion with the three trainers afterwards revealed that theythought that the day had gone well. All three agreed that they felt that we (theproject) were all closer to agreeing on the final form of the CVE.

2.4 A myth unmasked: what happened next, day 2

He went like one that hath been stunned,And is of sense forlorn:A sadder and a wiser man,He rose the morrow morn.

Coleridge (1798) The rime of the ancient mariner

Day 2 of the workshop found us together again, this time with the object of gettingthe representatives from the three training organisations to agree the details of howthe CVE was to be used in training practice. (The high level features of this hadbeen agreed early in the requirements phase.) As a starting point for this, personnelfrom the WMC training organisation had previously created a detailed trainingscenario for a typical exercise to be conducted in the DISCOVER collaborativevirtual environment. The scenario was a refinement, but not a significant rewrite,of an earlier version used in the project. It now emerged that the training scenariodid not reflect some aspects of practice at DMI and ISSUS but after discussion theyagreed to adopt it. We then used the training scenario to create a series of extended,annotated storyboards. The annotations held low level design details andsequencing information which the designers and implementers required.

Approximately an hour into this process one of the trainers identified afundamental problem with the design which was so great that he said that hisorganisation would not and could not use it. (While this was pivotally important tothe DISCOVER project the details are less relevant to this narrative andconsequently are consigned to an extended endnote§). So, after spending 12 personmonths of carefully co-constructing an agreed story among the intended end-usersas to the specification and early design of the CVE we found to our horror in thespace of two minutes on the final day of the final workshop that no such consensushad ever existed.


So, how can we account for the events of the second day of the workshop? Inthe preceding months we had collectively agreed and consolidated therequirements and initial design of the CVE. We recognise, of course, that theseprocesses of compromise and consolidation involve the systematic rejection ofsome requirements in favour of others and the integration of multiple perspectives.Indeed we had experienced a not untypical range of technical, inter- and intra-organisational compromises. However we remained puzzled. We had elicitedrequirements from the key stakeholders, namely, trainers, trainees and seniortraining managers and we also recognised that these individuals hold multipleroles. We had checked, validated and prioritised these requirements regularly. Wehad used the well proven techniques of observation, interviewing, artefactcollection (e.g. sample training scenarios), scenarios and use of a prototype. Wehad explored both training and usage scenarios with all concerned from an earlystage, but apparently to little avail.

3 A missing voice?

In eliciting requirements on the DISCOVER CVE we had focused on thestakeholders and their roles we had identified. When interviewing these individualsthey spoke with a particular voice. People with the job title of 'trainer' spoke asmaritime trainers, prospective end-users and project members. We as analystslistened as analysts. We together co-constructed a narrative which embodied thedesign, functionality and behaviour of the DISCOVER system. However what wehad failed to appreciate fully that we as listeners necessarily shape what is said.This is a multi-layered process: as well as Bahktin’s concept of the active listener,narratologists argue that a narrator assumes a narratee or narratees with a particularset of taken-for-granted knowledge and values.

On reflection, it is apparent that the trainers spoke with multiple voices and itis almost certain that we all failed to differentiate among them. The voices of themaritime trainer (expressing concerns about training effectiveness), project teammember (displaying willingness to cooperate) and prospective end-user (concernedabout the ease of use of the system) had been seamlessly woven together. Wesuspect that much of the time these narrators were tailoring their text to anaudience of ‘fellow project members’. As listeners, we had very likely amplified achorus of consensus. And it was only when the fine details of usage were discussedthat the specific voices of the maritime trainer talking to fellow trainers werebrought to the fore. This revealed a competing narrative thread was revealedembodying the belief that a collaborative virtual environment was not an optimalsolution. To go down this route would require a substantial revision of trainingmaterials and mode of working which may only have become apparent once thedetail was closely considered. So rather than the maritime trainer's voice perhapswe had witnessed a "reluctant or resistant to change maritime trainer's voice" or"concerned about his / her job voice"). This occurred on the second day of the finalworkshop, when the trainers spoke solely as trainers, with inevitable conflictsbetween what they were saying and the voices they had used in the past.


4 Revisiting User Centred Design

We conclude by proposing a number of modifications (or, at least, caveats) to theuser-centred design approach.

Firstly, there is a strong case for refining the idea of a largely static andclearly defined stakeholder with that of multiple voices each reflecting a point ofview or facet of their stake in the design process. This would not be a trivialendeavour as we have described above. Voices may be ephemeral andconsequently easily missed. Voices may well overlap and be mistaken for eachother. Voices may also come into existence as a consequence of changes of thedesign process as we witnessed in the case study described above.

Secondly, there is a need for a reference point which can be used to focus orrefocus the individual design episodes. This could take the form of a statement ofpurpose for the system as a whole (as in various structured design methods, e.g.Yourden) or some kind of statement of the relevant system (as in Checkland's SoftSystems Methodology) or objectified motive as in Leontev's theory of activity.

Thirdly, we would caution against inadvertently de-contextualisingrequirements and design details. Examining a sample of the Post-Its generated atthe workshop reveals such items as "E3: standard graphic signs", "A11: ash tray incabin" and "E22: Panel for electrical power" which are snippets and snapshots ofthe utterances of the trainers (E refers to environmental requirements; A refers tothe design of the accommodation on board). Instead a practical means of capturingthe utterances, which necessarily capture mood, context and a whole host of otherpotentially relevant factors, is needed. As Pentland (1999) advocates, narrativemay afford a structure for this.

Finally, story telling is a universal characteristic of humans. Ask a group ofintelligent, articulate people to tell a story about a speculative piece of softwarewhich might embody something they know well and it is very likely that they will.Support the process with the tricks and trappings of user-centred design and thelikelihood rises. And there is all too strong a tendency to co-construct coherent,simple stories with a beginning, a middle and an end. We believe that is whathappened in the case study we have presented here. Perhaps user-centred design isa little too good at eliciting stories, at constructing narrative. Perhaps peoplebecome too cooperative and compliant when they are encourage to talk aboutsubjects they know and care about. Perhaps established requirements methods aretoo effective in harmonising multiple voices. And perhaps the occasional excursioninto reality, through the reiteration of underlying purpose, a measure of scepticismtowards apparently consolidated requirements and the more explicit documentationof multiple narratives is needed to balance the account.

Acknowledgements

We gratefully acknowledge the contributions of our colleagues on the DISCOVERproject in providing the sites and subjects for the fieldwork herein described and indeveloping the DISCOVER software. The project is financially supported by theEU ESPRIT programme.


5 References

Bakhtin, M. M. (1981) The dialogic imagination: Four essays by M. M. Bakhtin,Michael Holquist (Ed.) trans. C. Emerson and M. Holquist, Austin: Univ. ofTexas Press.

Bakhtin, M. M. (1986) Speech genres and other late essays, C. Emerson and M.Holquist (Eds.), trans V.W. McGee, Austin: Univ. of Texas Press.

Bødker, S. and Grønbæk, K. (1998) Users and designers in mutual activity, In Y.Engeström and D. Middleton (Eds.) Cognition and Communication at work,Cambridge University Press, 130-158.

Bødker, S., Grønbæk, K., and Kyng, M. (1993). Cooperative design: Techniquesand experiences from the Scandinavian scene. In D. Schuler and A. Namioka(Eds.), Participatory Design: Perspectives on Systems Design. Hillsdale, NewJersey: Lawrence Erlbaum Associates, 157-175.

Bruner, J. (1986) Actual Minds, Possible Worlds. Cambridge: Harvard UniversityPress

Burke, K. (1969) A Grammar of Motives, Berkeley, CA: University of CaliforniaPress.

Carroll, J. M. (1995) The scenario perspective on system development. In J. M.Carroll (Ed.) Scenario-Based Design: Envisioning Work and Technology inSystems Development, John Wiley, New York.

Coleridge, S. T. (1798) The rime of the ancient mariner. London: Longmans.COVEN deliverable D3.5 (ACTS Project COVEN, N. AC040, Usage Evaluation

of the Online Applications Part B: Collaborative Actions in CVEs 2)Davenport, E. Higgins, M. and Somerville, I. (2000) Narrative of new media in

Scottish households: the evolution of a framework of inquiry, Journal of theAmerican Society for Information Science, 51(10), 900-912.

Goguen, J. A. (1997) Toward a Social, Ethical Theory of Information. In G. C.Bowker et al. (Eds). Social Science, Technical Systems and CooperativeWork: Beyond the Great Divide. Mahwah, NJ: Lawrence Erlbaum Associates,27-56

Greenbaum, J., and Kyng, M. (Eds.) (1991) Design at Work: Cooperative Designof Computer Systems, Hillsdale, NJ: Lawrence Erlbaum Associates.

Heritage, J. (1984) Garfinkel and Ethnomethodology. Cambridge, UK: PolityPress.

Holtzblatt, K. and Beyer, H. (1998) Contextual Design: defining customer-centredsystems, Morgan Kaufman, New York.

Imaz, M. and Benyon, D. How Stories Capure Interactions, in M. A. Sasse and C.Johnson (Eds.) Proceedings of INTERACT’99, 321-328

Kensing, F. (1998) Prompted reflection: a technique for understanding complexwork, interactions, v.1, 7-15.

Lave, J. and Wenger, E. (1991) Situated learning - legitimate peripheralparticipation, CUP, Cambridge.

Lloyd, P. (2000) Storytelling and the development of discourse in the engineeringdesign process, Design Studies, 21(4), 357-373


Muller, M. (1993) PICTIVE: Democratizing the Dynamics of the Design Session,in D. Schuler and A. Namioka (eds.), Participatory Design: Principles andPractices, Lawrence Erlbaum Associates, Hillsdale, NJ, 211-237.

Moro, Y. (1999) The expanded dialogical sphere: Writing activity and authoring ofself in Japanese classrooms. In Y. Engeström, R. Miettinen and R.-L.Punämaki Perspectives in Activity Theory, Cambridge University Press.

Pentland, B. T. (1999) Narrative Methods in Collaborative Systems Research. InProceedings of the 32nd Hawaii International Conference on SystemsSciences- 1999

Stapleton, J. (1997) DSDM: Dynamic Systems Development Method, Addison-Wesley.

Wertsch, J. V. (1991) Voices of the Mind, Harvard University Press., Cambridge,MA.

Wertsch, J. V. (1998) Mind as Action, Oxford, Oxford University Press.

§ The difficulty hinged on in the nature of the training itself. The DISCOVERcollaborative virtual environment was intended to support the command andcontrol training of senior mariners. This does not directly involve fire fighting orthrowing a rope to a man overboard. Instead it is about organising and collectinginformation from the men fighting the fire or pulling a man out of the water andthen acting on that information.As one of the trainers from the dissenting organisations explained, a mariner in a(real) room with 4 telephones receiving information from the outside world wouldbe more effective than the proposed system. All the visual trappings andinteraction of a collaborative virtual environment were largely irrelevant.In contrast the other two training organisations specifically wanted a collaborativevirtual environment to enrich the experience of their trainees.

getting the story straight

Documents