http://research.idi.ntnu.no/ami4cm/ Table of Contents • Preface: Applying AmI technologies to crisis management • Response to Emergence in Emergency Response Lisa A. Wood, Monika Buscher, Leonardo Ramirez • An Analysis of the use of Cognitive Surplus in Disaster Relief Scenarios Mark Roddy • Disaster Management Tool (DMT) - Usability Engineering, System Architec- ture and Field Experiments Martin Frassl, Michael Lichtenstern, Michael Angermann • Smart Jacket as a Collaborative Tangible User Interface in Crisis Manage- ment Monica Divitini, Babak A. Farshchian, Jacqueline Floch, Bjørn Magnus Ma- thisen, Simone Mora, Thomas Vilarinho • Key challenges in multi-agency collaboration during large-scale emergency management Aslak Wegner Eide, Ida Maria Haugstveit, Ragnhild Halvorsrud, Jan Håvard Skjetne, Michael Stiso • The MIRROR AppSphere: the case of crisis management Simone Mora, Simon Schwantzer, Monica Divitini • BRIDGE Risk Analyzer: A Collaborative Tool for Enhanced Risk Analysis in Crisis Situations Mass Soldal Lund, Atle Refsdal • Tactical Information Visualization for Operation Managers in Mass Casual- ty Incidents Mathias Wilhelm, Eva Burneleit, Sahin Albayrak • Conclusions and summary of discussions Monica Divitini, Babak A. Farshchian, Jacqueline Floch, Ragnhild Halvors- rud, Simone Mora, Michael Stiso Preface: Applying AmI technologies to crisis management Workshop at AmI2012 Monica Divitini1, Babak Farshchian2, Jacqueline Floch2, Ragnhild Halvorsrud2, Simone Mora1, Michael Stiso2 1 Dept. of Information and Computer Science, NTNU, Trondheim, Norway {divitini, simonem}@idi.ntnu.no 2 SINTEF ICT, Oslo| Trondheim, Norway {Babak.Farshchian, Jacqueline.Floch, Ragnhild. Halvorsrud, Michael.Stiso}@sintef.no 1 Introduction Natural and man-made disasters are on the rise, with sources reporting on a five-fold increase of natural disasters in the last 35 years 1. In 2010, DG ECHO (the EU Direc- torate for Humanitarian Aid and Civil Protection) reported a EU expenditure of €1115 million to respond to new or protracted crises, and 373 natural disasters killing around 300000 people 2. ICT solutions proposed for supporting crisis management vary considerably in scope and complexity, ranging from organizational workflow systems up to platforms like Ushahidi (http://ushahidi.com/) for crowd sourcing and the usage of Twitter (twit- ter.com) to share information among the population. Because of their pervasiveness and ease of use, Ambient Intelligence (AmI) solutions hold a great potential to support crisis management in an efficient and effective way, thereby contributing to saving lives, reducing risks for rescue teams and lowering costs. Several example solutions are described in the research literature, such as moni- toring of environmental data under hard conditions, impact of information presenta- tion on decision-making, rescuer teams management supported with physiological data monitoring, situational awareness support for rapid crowd evacuation. This workshop has been organized to better understand the strengths of the AmI para- digm and challenges to its application. It offered to researchers and practitioners a 1 http://www.euractiv.com/foreign-affairs/europe-beef-response-natural-disasters-news-499193 2 EU DG ECHO, Annual Report 2010, available at http://ec.europa.eu/echo/files/media/publications/annual_report/annual_report_2010.pdf space to reflect on where these increasingly pervasive and ambient technologies are going, what they will make possible, and how they will be used. Focus was on chal- lenges connected to the use of AmI in crisis management as well as the opportunities to use AmI to conceive innovative solutions, e.g. empowering not only traditional actors, but also the population at large; supporting not only management, but also promoting continuous learning and training. Relevant topics included platforms is- sues, user interaction in challenging environments, methodologies and applications. This volume collects the 8 papers that were presented at the workshop, addressing these topics from different angles. Together they provide an up to date overview of the state of the art in the field. 2 Organization The workshop was jointly organized by three EU IST research projects that investi- gate from different perspectives ICT support for crisis management: • (http://www.bridgeproject.eu) aims at building a system to support technical and social interoperability in large-scale emergency manage- ment. • (http://www.mirror-project.eu/) aims at developing ICT tools for supporting workplace reflection and learning. Training of crisis workers is a core application domain of the project. • (http://www.ict-societies.eu/) aims at extending the appli- cation of pervasive computing beyond the individual to communities of users. Disaster management is chosen as one area for the evaluation of the proposed so- lutions. More information about the workshop is available at the workshop website: http://ami4cm.wordpress.com/ Response to Emergence in Emergency Response Lisa Anne Wood*, Monika Büscher*, Leonardo Ramirez† *Mobilities.Lab, Lancaster University, UK; †Fraunhofer FIT, Germany Abstract. This paper develops a (constructive) critique of the potential of ambient intelligence technologies in emergency response. We explore some difficulties in, and successful practices of, inter-agency collaboration in emergency response, revealed in ethnographic field studies and collaborative design workshops with first responders undertaken in the frame of the Bridge project. We describe four challenges with refer- ence to literature and our own fieldwork in Emergency Management Information Systems (EMIS) design: data transparency, interpretation/intuition, flexible working and information overload. We posit that ambient intelligence has a great deal to offer in the creation of emergency management information systems but that these offer- ings should be guided by ‘modesty’ and an ongoing entanglement with emergency practitioners. Keywords: Emergency response, coordination, collaboration, emergence 1 Introduction … the development of networking technologies must also take account of the social processes that form an important component of command and control and inter- agency cooperation. [1: 79] Almost without exception, reports and reflections after disasters express concerns over the different emergency agencies’ abilities to work together (whilst also high- lighting exemplary successes). These concerns often inspire innovation, investment and research. Recent research in Ambient Intelligence (AmI), for example, develops new support for coordination in emergency response through ad-hoc networking [2], agent-based workflow support [3], self-management and self-healing of emergent systems of systems [4], activity recognition [5], and risk analysis [6]. These technolo- gies have great potential, yet there is often a lack of attention to the complex causes of the difficulties that emergency responders experience and to the often sophisticated practices that enable successful coordination. A deeper understanding of such factors and practices is needed to design useful support for real world practice. In this paper we focus on aspects of collaboration and coordination between differ- ent emergency agencies during large-scale incidents to present a constructive critique of ambient intelligence systems. We explore how AmI tools may feature in a soci- otechnical arrangement or ‘system of systems’ which supports inter-agency collabora- tion during emergency response. 2 Background The EU funded Bridge project develops architectural support for the assembly of systems of systems for emergency response. Emergency management encompasses a variety of activities such as planning, training, risk assessment, and organizational change. Emergency response involves an exchange of data between different agencies and institutions, movement of people from service to service and cooperation from other actors (such as utilities companies, insurance providers, and telecoms opera- tors). The emergence of appropriate assemblies of responders and resources depends on coordinated improvisation in a time critical, often dangerous and unpredictable environment. Collaboration is paramount and ‘effective’ collaboration may save lives. Ambient Intelligence or AmI has great potential in this context, as it can contribute in coordinating and orchestrating emergent interoperability, and help people identify actors and services relevant for the situation at hand. Innovation in this area, however, must be grounded in an understanding of the difficulties emergency responders expe- rience, and their often multi-dimensional causes, as well as an appreciation of the often highly sophisticated and delicate practices of collaboration that make coordina- tion possible. Undermining and failing to appreciate the local, lived and often suc- cessful collaboration efforts of those operating ‘on the ground’ can lead to costly fail- ures with the potential to damage relations between organizations [7]. It is important for emergency management information systems design [8] to focus its efforts on supporting collaboration where it is needed without disrupting the social practices which enable these disparate yet cooperating entities to work together. To understand the complex practices of intra- and inter–agency collaboration in large scale emergency response, we use in BRIDGE a range of methods that ‘entan- gle’ use and design. We have chosen to involve users deeply and equally as co- designers in long-term processes of socio-technical innovation. Our experience with participatory design shows that in-depth, long-term engagement with users and con- texts of use can be a powerful source of constructive critique of technocentric visions and a breeding ground for new ideas that are grounded in and more appropriable for real world practices [9, 10]. This can make emergence of viable (and desirable) socio- technical futures possible, and inform the design of technologies for such futures. In the frame of BRIDGE, we have carried out over 80 hours of interviews, domain analysis workshops and ethnographic observations with professional partners in po- lice, fire and medical emergency services in the UK, Belgium, Norway, Germany and the Netherlands since April 2011. This work includes observations, go-along or walk- along [11, 12] and sit-down interviews, as well as ‘sandbox’ discussions, where emergency responders use props to describe real emergency response efforts from their own experience. Reflecting the nature of emergency response, the methods cho- sen in BRIDGE are often mobile and multi-sited. Since it is the detailed organisation of social and material practice what matters to system design, we follow an ethno- graphic approach based on the use of recordings of interviews and of naturally occur- ring activities. In the next section we explore some difficulties in, and successful practices of, in- ter-agency collaboration in emergency response, revealed in ethnographic field stud- ies and collaborative design workshops with first responders undertaken in the frame of the Bridge project. 3 Collaboration in emergency response 3.1 Emergent Collaboration Some of the concerns expressed in official reports over a lack of collaboration fol- lowing emergency response efforts sit uncomfortably with empirical studies of emer- gency responders’ work practices. Such studies show, for the most part, first respond- ers work well together, their practices fold into each other’s and they address inci- dents effectively through collaborative working and engagement on a day on day, week on week basis. Empirical accounts of practices highlight an economical yet sophisticated process of configuring awareness [13, 14], the emergence of ‘adhocra- cies’ of emergency response actors (e.g. in the aftermath of the 9/11 attacks, [15, 16]), and the ability to ‘stretch’ communicative capabilities with new technologies [10], creatively avoiding a ‘fracturing’ of perceptual ecologies [17]. Following an inquiry into the London bombings in July 2005, for example, the coroner highlighted how when multi-agency responders were presented with uncer- tain, complex and traumatic circumstances they “did all that they could to ensure that lives were saved” [18]. This sentiment is echoed in the results of BRIDGE project. In our observations of and conversations about work practices with emergency respond- ers, collaboration on a human-to-human level is rarely criticized and is not regarded as a problem but rather as routine. In a discussion with fire fighters they explained how ‘the men’ (sic) on the ground from fire, health and police agencies, work well together. Responders stated that multi-agency front line officers can collaborate effec- tively, because they work with each other regularly. This reflects a close community of individuals and agencies working together on small and large scale incidents, where plans, standardized procedures, and official terminologies represent resources (not blueprints) for situated action [19]. Reports from disasters often gloss over the difficulties of conceiving and imple- menting collaboration support in emergency response both at a human and at a tech- nical level. This usually motivates attempts to eliminate differences among participat- ing agencies, for example through centralization, which has not proven to be effec- tive. ‘Environmental’ constraints, such as overeager centralization, cumbersome legis- lation, and conflicting business rationales impact on the responders’ capabilities to coordinate their contributions and collaborate. Moreover, when that work is augment- ed by technologies, important, but often taken for granted aspects of emergent collab- orative practices can become undermined. In these situations, problems between agencies working together can emerge – they may, for example, be unable to share information embedded within technologies or act on information obtained through communication or observation. What works on a person to person level, for example in ‘motorhood’ collaboration around physical surfaces in co-present situations, should not be disrupted by radio systems which cannot interoperate or logging systems which can only be viewed by one agency. As a consequence, new systems need to be de- signed and integrate existing components with greater sensitivity to such collaborative work practices between agencies, moving between perspectives gracefully, without interfering with the work of responders. Technological futures must focus not only on overcoming breakdowns in collaboration, but also on ‘stretching’ existing, effective ways of working together. 3.2 Role and challenges for AmI in emergency response Many authors have written about imagined futures for emergency response where AmI environments could improve collaboration and coordination of response efforts. The AmI environment is envisioned or designed to recognize the needs of people through analysis of abstractions of behaviour, predicting needs and reacting accord- ingly [20]. In a scenario proposed by [2], for instance, a world is imagined where, as off duty paramedics approach a scene of an incident “…body-worn AmI devices regis- ter them with the ambulance control centre and they are directed to the place they can be of most use” [2: 119]. The benefits of such interactions are highly valued and regarded by practitioners when discussing the potential of AmI systems in the context of emergency response. Such use of AmI raises, however, a number of concerns about the way in which the ‘social’ is removed or made invisible from these envisaged interactions. Critiques of AmI in health care and telemedicine, for example, highlight the ways in which creat- ing intelligent environments disrupt social connectedness – remote monitoring re- moves the personal connections and the benefits of being cared for [21]. Indeed, co- operation and interagency collaboration is an effect emerging of the sociotechnical system working as a whole. In this sense, AmI tools are just one further element of the assembly. If they undermine the practices of inter-agency collaboration by remov- ing negotiations or the space for interaction between participants, they can seriously disrupt sophisticated collaborative practices. Against this background, it is a deep challenge for AmI to balance engagement and automation. Dealing with this challenge is possible through appropriation and flexible assembly, rather than designing systems for an imagined future and created by de- tachment from the realities of human practices. This is not a new endeavor. [10] have suggested that ambient intelligence systems need to be made ‘palpable’, enabling visibility, de-construction, understandability, coherence, stability, user control and deference. [22] has stated that promoting ‘engaged’ living, where it is possible to control interactions with the world as an alternate possibility for steering the field. Aiming at these qualities presents a plethora of opportunities for technological inno- vation yet also raises a number of serious challenges at different levels in the design of AmI systems. In our work, we identified several of these challenges. In the follow- ing we describe four of them with reference to literature and our own fieldwork in EMIS design. Data Transparency. Ambient intelligent environments often make extensive use of instrumented environments via omnipresent sensors and actuators such as CCTV, RFIDs tags, etc [23], which imply a growing potential for increased surveillance pos- sibilities. In a co-design workshop, we discussed anxieties about breaching the data protection act when sharing data in multi-agency collaboration. A dilemma was pre- sented where a policeman needs to do something with a person and that person is known to have a blood infection. The ambulance representative stated, “We tell them discreetly ‘use your gloves’”. Jim, a Norwegian police officer, described inter- organizational collaboration on the scene of an incident during the workshop, “If there’s a known violent criminal who might be armed injured on the sce- ne, you’d tell the medics ‘be careful with him’” This is not in breach of data protection regulations and highly effective for the safety of emergency response personnel. It is an ethical requirement for information systems to (at least) respect existing health and safety practices. The above exchanges are likely to happen in ‘fleeting moments’, in direct face-to-face interaction or, less likely, via the radio system. The information would be ephemeral and it is relatively easy to understand who is within reach of this information spatially, organizationally, and temporally. However, in future, such communications may be logged automati- cally, opening them up for retrospective scrutiny. Moreover, it may be possible to triangulate the personal information implied in the communication with ID infor- mation and location. This change of context might make professionals less inclined to divulge what they know to protect their colleagues, for fear of breaching data protec- tion regulations. This raises the question of balancing between the benefits of seam- lessly connected system with the privacy concerns that the profiling and monitoring capabilities of AmI systems create. Information Overload. [24] argue that a ‘common operational picture’ does not lead to ‘situation awareness’. The assumption ‘that data is the only barrier to appro- priate [understanding and] action’ is deeply flawed. This was elaborated on in our fieldwork where it was felt that information should be appropriately available at the different levels of an emergency command structure, that a common operational pic- ture was not reliant on data intensive practices, and that providing excess information would “blur the lines of command” (Peter, Advanced Paramedic). “As a commander remote, I don’t think you would be interested in that par- ticular information [the status of individual victims]. I think you’d want the headline; the numbers.” (John, Senior Fire Fighter) Yet increasingly, systems are developed that aim to generate more and more ‘data’ for emergency responders in order to ‘improve’ situation awareness, creating the po- tential to mask what is of importance. There is a delicate balance to be made between information overload and information simplification where digitally extended and augmented environments change interaction and involvement possibilities and threat- en the ability to ‘dig deep’ enough into the system to see modes of information gener- ation or aggregation. Interpretation/Intuition. It is not possible for an intelligent environment to be in- telligent enough for situated sense-making. In human communication and collabora- tion, there is interpretation and intuition used to understand intent. It is therefore diffi- cult (if not impossible) to design a system that would produce an appropriate response due to its incapacity to fully ‘appreciate’ context and intentions. During a co-design workshop, in a discussion regarding the allocation of resources, responders talked about how the allocation or movement of personnel from one location to another is not simply the movement of people from one place to another. Ex-police officer and resilience manager, David, states: “One little thing that we questioned slightly is… automatic deployment… We felt that wasn’t really taking account of the dialogue that goes on between control rooms and the units that they are deploying: officers or paramedics are feeding back local knowledge and things like this and we felt that that’s something, an area that really needs looking at. It’s never a one way process, deploying resources.” Resource allocation implies a process of negotiation that define the task itself, its parameters and how it should be accomplished. The work that is ‘done’ during the allocation of resources cannot necessarily be broken down into matching an individu- al’s skills with an area requiring assistance. As the example shows, asking someone to do something may involve trust in their professional capabilities, and delegation of responsibility or collaboration and negotiation: to determine whether the person being moved is fit for duty and indeed the best resource to move in the circumstances. Further to this, the accuracy to which such systems can ‘abstract’ human conduct underlying collaborative practices is restricted. A police officer might move from one side of the building to another, for example. What does such movement represent? Does it mean that one area is now safe? That the area where they were standing is now dangerous? That there is more need for them in the new location or that they are due to go home? AmI has no capacity to ‘read’ scenes in a way that could answer such questions. It can, however, make them, or digital representations of them, avail- able to support the construction of awareness and the situated sense-making of its users. Flexible Working. The above examples go some way in showing how coordina- tion between different agencies in emergency response is an emergent phenomenon that depends on people’s ability to flexibly assemble technologies, people, and re- sources. It must allow for role improvisation. Our empirical studies and design col- laborations with professionals provide insights into experiences of camaraderie and trust, and effective practices of improvisation and ‘motorhood’ coordination, that is, gatherings where knowledge and different perspectives are brought together, often around a shared physical surface, but increasingly also utilizing digital technologies. After it had been determined that there were no further bombs in the government buildings in Oslo after the attack on 22/7/2011, ambulance doctors went inside the buildings, doing triage with fire fighters. This was in response to a perceived danger of fire fighters evacuating the wrong victims. Medical staff could do triage inside the buildings and allocate scarce transport resources more efficiently. 4 Conclusion The Bridge project’s aim is to “augment human intellect …, extending their ability to learn, make decisions, reason, create, solve complex problems and generate inno- vative ideas”, based on Rogers ‘New Agenda’ for ubiquitous computing [22: 411]. Rogers states that UbiComp should move to “a mindset that wants to make the envi- ronment smart and proactive to one that enables people, themselves, to be smarter and proactive in their everyday and working practices.” [22: 418]. In this paper we have presented a constructive critique of AmI environments for emergency response based on longitudinal socio-technical design entanglements with emergency service responders. We posit that ambient intelligence has a great deal to offer in the creation of emergency management information systems but that these offerings should be guided by ‘modesty’ and an ongoing entanglement with emergency practitioners. We argue that collaboration practices are habitually successful and that AmI systems de- sign should attempt to build on what makes possible this success. 5 Acknowledgements We would like to thank the professional responders and our Bridge project col- leagues for their insightful contributions and comments to this paper, in particular Aslak Wegner Eide and Ragnhild Halvorsrud. 6 References 1. McMaster, R. and C. Baber, Multi-Agency Operations: Cooperation During Flooding, 2008, BAE Systems. 2. Jones, V., G. Karagiannis, and S. Heemstra de Groot. Ad hoc networking and ambient intelligence to support future disaster response. in ASWN 2005, 5th Workshop on Applications and Services in Wireless Networks. 2005. Paris, France: IEEE. 3. Van Veelen, B., P. Storms, and C. van Aart. Effective and efficient coordination strategies for agile crisis response organizations. in ISCRAM 2006. 2006. New Jersey. 4. Ayala, I., M. Amor, and L. Fuentes. Self-management of ambient intelligence systems: A pure agent-based approach. in AAMAS. IFAAMAS, 2012. 2012. 5. Choudhury, T., et al., An embedded Activity Recognition system. IEEE Pervasive Computing, 2008. 7(2): p. 32-41. 6. Aziz, Z., et al., Supporting urban emergency response and recovery using RFID-based building assessment. Disaster Prevention and Management, 2009. 18(1): p. 35-48. 7. Shapiro, D. Participatory design: the will to succeed. in CC '05 Proceedings of the 4th decennial conference on Critical computing: between sense and sensibility 2005. Arhus, Denmark. 8. Van De Walle, B., M. Turoff, and S.R. Hiltz, Information Systems for Emergency Management. Advances in management information systems, v. 162010, Armonk, NY: M.E. Sharpe. 9. Ramirez, L., Practice-Centered Support for Indoor Navigation: Design of a Ubicomp Platform for Firefighters. Fraunhofer Series in Information and Communication2012, Aachen: Shaker Verlag. 10. Büscher, M., et al., Bottom-up, top-down? Connecting software architecture design with use. Configuring UserDesigner Relations Interdisciplinary Perspectives, 2008: p. 157. 11. Kusenbach, M., Street Phenomenology: The Go-Along as Ethnographic Research Tool. Ethnography, 2003. 4(3): p. 455-485. 12. Buscher, M. and J. Urry, Mobile Methods and the Empirical. European Journal of Social Theory, 2009. 12(1): p. 99-116. 13. Pettersson, M., D. Randall, and B. Helgeson, Ambiguities, awareness and economy: a study of emergency service work. Computer Supported Cooperative Work (CSCW), 2007. 13(2): p. 125-154. 14. Heath, C. and P. Luff, Collaboration and Control: Crisis management and multimedia technology in London Underground Line Control Rooms. Computer Supported Cooperative Work (CSCW), 1992. 1(1-2): p. 69-94. 15. Mendonça, D., T. Jefferson, and J. Harrald, Collaborative adhocracies and mix-and-match technologies in emergency management. Communications of the ACM, 2007. 50(3): p. 44. 16. Kendra, J. and T. Wachtendorf, The waterborne evacuation of Lower Manhattan on September 11: A case of distributed sensemaking, 2006, University of Delaware Disaster Research Centre. 17. Luff, P., et al., Fractured Ecologies: Creating Environments for Collaboration. Human-Computer Interaction, 2003. 18: p. 51-84. 18. Hallett, H., Coroner's Inquest into the London Bombings of 7 July 2005, 2011, HM Coroner: London, UK. 19. Suchman, L., Human-Machine Reconfigurations: Plans and Situated Actions. Second ed2007, New York: Cambridge University Press. 20. Ingold, T., Bringing Things to Life: creative entanglements in a world of materials, in Realities2010, University of Manchester. 21. Milligan, C., C. Roberts, and M. Mort, Telecare and older people: who cares where? Soc Sci Med, 2011. 72(3): p. 347-54. 22. Rogers, Y. Moving on from Weiser's vision of calm computing: Engaging UbiComp Experiences. in Ubicomp 2006. 2006. Berlin: Springer-Verlag. 23. Hert, P., et al., Legal safeguards for privacy and data protection in ambient intelligence. Personal and Ubiquitous Computing, 2008. 13(6): p. 435-444. 24. Harrald, J. and T. Jefferson. Shared situational awareness in emergency management mitigation and response. in 40th Annual Hawaii International Conference on System Sciences HICS07. 2007. Hawaii: IEEE. An Analysis of the use of Cognitive Surplus in Disaster Relief Scenarios Mark Roddy1 1 Telecommunications Software and Systems Group (TSSG), Waterford Institute of Technology, Waterford, Ireland, mroddy@tssg.org Abstract. In an increasingly connected world, can the cognitive surplus of the online community be effectively harnessed to help in the assistance of managing global disasters? Does this community even want to assist with disaster relief? The relief experts on the ground are continually being confronted with life and death scenarios, so how can they trust the veracity of any assistance provided by the online community? By providing examples of existing disaster management systems that have successfully leveraged the online community to assist in disaster relief, this paper suggests that online philanthropy exists, albeit this assistance does need to be manually verified. The paper goes on to use the results from an online survey to hypothesize a collective intelligence model for trusting this assistance. The potential impact of this could be to reduce the burden that the disaster relief teams have to exert in order to verify and validate this assistance. 1 Introduction On the 26th December 2004 an earthquake in the Indian Ocean resulted in one of the most destructive tsunamis ever to hit the islands of Indonesia. Within the first hours of this tragic event some 150,000 people had died or were declared missing, and millions were left homeless. Emergency services were fully stretched in trying to come to the aid of the victims. 1.1 Objectives The objective of this paper is to suggest to the reader a model for a next generation disaster management system, which would be used to help alleviate the suffering of future disaster victims. The key objectives are to provide: - Examples of the state of the art for disaster management systems - Recommendations for the design of future disaster management systems 2 Cognitive Surplus and the Wisdom of Crowds Shirky (2010) describes cognitive surplus as people’s free time and offers insights into how this might be leveraged to impact changes around the globe. This free time is separate from people’s work time, where the expectation from the former is not necessarily market driven - people do not expect to be paid for any activity they are engaged in during their free time. The social scientist Dan Ariely (2008) explores this further - he discusses a scenario of a Thanksgiving dinner where the son-in-law stands up at the end of the meal and offers his mother-in-law payment for the services rendered, it was an artificial scenario but served to highlight the dichotomy between free time and work time - people in their free time do things for free, while people in their work time do things for payment. But the question still exists - how to harness this cognitive surplus and in particular how can it be leveraged in disaster relief scenarios? Watching television is an activity usually carried out in our free time, and Shirky (2010, pp.9-10) writes, “imagine treating the free time of the world’s educated citizenry as an aggregate, a kind of ‘cognitive surplus’”. Shirky uses the creation of Wikipedia as a model to measure how big this surplus might be and estimates that the creation of Wikipedia represents “something like one hundred million hours of human thought”. He compares this to watching television, which in the US alone is about two hundred billion hours every year, which is roughly equivalent to two thousand Wikipedia projects every year from cognitive surplus. Through the introduction of innovative online networking technologies it could be possible to transition the passive usage of our cognitive surplus (e.g. watching television) to more active engagement to help and support those in need. The hit television game-show “Who Wants To Be A Millionaire?” asks contestants to answer a question from four possible answers. If the contestant is unable to answer the question they are able to rely on three lifelines: ‘Fifty-Fifty’, ‘Phone a Friend’, or ‘Ask the Audience’. An interesting statistic1 is that the ‘Ask the Audience’ lifeline has a 95% success rate. Why is this? It is an example of a phenomenon known as wisdom of the crowd. Surowiecki (2004, p.70) cites, “The idea of wisdom of crowds also takes decentralisation as a given and a good, since it implies that if you set a crowd of self interested, independent people to work in a decentralised way on the same problem, instead of trying to direct their efforts from the top down, their collective solution is likely to be better than any other solution you could come up with”. 1 http://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire%3F “Who Wants To Be A Millionaire?” Wisdom of crowds resonates with the cognitive surplus ideas. On the one hand there is the potential to leverage the online communities’ cognitive surplus to assist in disaster relief and on the other hand there is the ability to aggregate the crowd’s (taken here to mean the online community) responses to arrive at the correct result. Combining these concepts strongly suggests that a collective intelligence model might exist that further increases trustworthiness and information veracity, which will be discussed later in this paper. 3 Disaster Management Systems This section provides some best in class examples of organisations (all voluntary) that are using online tools to assist in the relief of disaster management scenarios. Some of these organisations use collaborative cognitive surplus to provide online support back into the disaster zone. 3.1 Ushahidi Ushahidi2 is a not for profit organisation “that specializes in developing free and open source software for information collection, visualisation and interactive mapping”. Ushahidi was a response to the violence in the aftermath of the controversial Kenyan elections of 2008. Ushahidi started as a collaborative website set up by a group of Kenyan journalists and was used to aggregate and map the reports of these violent events. It was seen as an extremely powerful communication tool, and with over 45,000 users was the catalyst for the design and development of today’s platform. The platform was successfully used in many recent disasters, including as a relief response tool for the Haiti earthquake, when it was used by online volunteers to create a visual crisis map of the disaster zone, by clustering data mined tweets emanating from the disaster site.3 The volunteers then used Skype to relay the cluster details of their map back to relief teams. 3.2 The Sahana Software Foundation The Sahana Software Foundation, established in 2009, is another not for profit organisation whose mission “is to help alleviate human suffering by giving emergency managers, disaster response professionals and communities access to the information that they need to better prepare for and respond to disasters through the development and promotion of free and open source software and open standards”. 2 http://ushahidi.com/about-us “The Ushahidi Project” 3 http://usatoday30.usatoday.com/tech/news/2011-04-11-japan-social-media_N.htm “USA Today” Sahana originated in Sri Lanka as a response to the Indian Ocean tsunami disaster in 2005.4 The platform has had numerous deployments, including the 2011 earthquake in New Zealand where it was used to help as a people locator.5 3.3 Crisis Commons CrisisCommons6 is another example of a voluntary collaborative online community, whose aim is to support the management of disaster and crisis relief. The community emerged from so-called CrisisCamps, which are modelled on the BarCamp/CodeCamp7 concept, to “connect a global network of volunteers who use creative problem solving and open technologies to help people and communities in times and places of crisis”. They provide an example of a Voluntary Technical Community (VTC)8 and are supported directly by the US Federal Emergency Management Agency (FEMA). This community has also been very active in supporting disaster relief efforts, a typical example being the collective support of the volunteers during the 2011 earthquake in Turkey where they successfully helped the relief agencies with support response and recovery efforts. 4 Design Recommendations The European Union Seventh Framework project, SOCIETIES9 has conducted some initial evaluations with the European Union’s Civil Protection Mechanism (CPM), using paper prototyping techniques. The objective of SOCIETIES is to design and evaluate a next generation mobile platform that integrates existing Social Networking sites with emerging Pervasive Computing frameworks, so as to create likeminded, purpose driven communities. The paper prototypes were designed to receive feedback from the CPM’s disaster experts on their views about using the cognitive surplus of the online community to aid in the disaster relief. The experts were presented with sample scenarios that attempted to describe how this online community might be leveraged in a disaster. For example, one scenario described the disaster team being 4 http://wiki.sahanafoundation.org/doku.php “The Sahana Foundation” 5 https://pl.nlm.nih.gov/christchurch/index.php?mod=inw&act=default “People Locator for the ChristChurch Earthquake” 6 http://wiki.crisiscommons.org/wiki/Main_Page “Crisis Commons” 7 http://en.wikipedia.org/wiki/BarCamp “Crisis Commons Bar Camp” 8 http://www.emergencymgmt.com/emergency-blogs/campus/Crisis-Commons-Monitors- Turkey-Earthquake-102311.html “Voluntary Technical Community” 9 http://www.ict-societies.eu/ “FP7 SOCIETIES Project” confronted by some street signage that they were unable to translate. A digital photograph of the signage was taken and uploaded to the online community for translation. Another example asked the volunteers to spot the difference between satellite images of the disaster zone taken before and after the catastrophe, so roads or bridges that were destroyed could be identified in advance and alternative routes coursed. Two key findings10 resulted from this research: • Trust: how could the experts in the field trust the veracity of the results that they were receiving back from the online community? • Automated decision-making: the experts said they would have to be very wary about handing over life or death decision making to machines, but were open to experimentation through simulation. They saw the benefit of automating some of their processes but were sceptical about where the veracity line would be drawn between automated services and the traditional manual verification process, particularly where lives are at stake. In addition to this an online survey was undertaken in March 2012 (Roddy, 2012) and the results showed that a strong willingness does exist for a community of online volunteers to assist with disaster relief, and that this community would be willing to offer significant amounts of their cognitive surplus to this philanthropic activity. The survey also showed that this online community would be willing to provide personal profile information and that they would also be prepared to operate as part of a community of volunteers. This is important because it indicates a potential model for establishing diversity. An assumption can be made here that a diverse community of online volunteers exists, which is at the heart of Surowiecki’s (2004) premise that diversity in the crowd will provide more accurate results than an expert. The next steps would be to prove the above through future experimentation. That experiment would involve establishing an online user community of volunteers. These volunteers would provide their profile information at a granularity level that correlates to diversity; call this a ‘diversity factor’. In total there are three components to be designed into this platform: i. Firstly the platform will need to have some process for deciding whether to send the data to an expert group or a diverse group. This could be done using a ‘task tagging profile’ and an ontology or semantic algorithm. ii. Secondly the platform needs a process that discovers the appropriate list of diverse volunteers; labelled as a ‘diversity factor’. Again, this could be done using ontology assessment of the volunteer’s profile tags. 10 http://www.ict-societies.eu/files/2011/11/D8.1_public.pdf “SOCIETIES Paper Trial Evaluation Report” iii. Thirdly the platform needs to be able to predict the ‘certainty or veracity level’ of the results, which is at the heart of Surowiecki’s ‘Wisdom of Crowds’ model. The problem here is to work out how many volunteer responses are needed to solve just one problem. The platform is trying to avoid: a) any mistakes being made, and b) volunteers deliberately providing false responses. By asking ‘x’ amount of volunteers to work on a problem and aggregating their responses, increases the veracity of the feedback. An example is summarised in the message sequence chart below: Figure 1: Message sequence chart showing the three design components The chart starts with a help request from the relief team working in the disaster zone. This could be something like help with parsing through satellite images of the disaster zone before and after the disaster, and reporting back on the amount of damage that has been done. So these images are uploaded to the Disaster Management Platform with a “Help Requested” tag, and a brief description of the profile of the task that they need help with. In this particular example help is needed parsing the satellite images for damage. Using the “Task Profiler” component the platform now needs to figure out whether this particular help request requires the attention of an expert group or a diverse group and so sends the task profile to the Recommender System. The Recommender System parses through the task profile information and because this particular task does not require any particular skill advises back to the platform that a diverse group rather than an expert group is required to solve this task. The platform now sends a request to the Diversity System to supply a diverse list of volunteers. So what does diverse mean here? The precise design of this component will be a next step but at a high-level the “Diversity Factor” algorithm will data mine the profiles of the complete list of volunteers (could be from their online social media profiles) and present back a subset list that is diverse. Diversity here could include: • 50% of the list could be women • The age profiles could be evenly spread • Their ethnicity could be evenly spread • The educational profile could be evenly spread The platform will now send the task to this volunteer list and collate back their responses. Having aggregated the collated responses, which forms the “Veracity Level” of the task, the platform forwards the task solution back to the disaster team. 5 Conclusions This paper has made some recommendations that could aid the design of a collective intelligence emergency responder tool (this could also be a plug-in to existing systems, such as the Ushahidi platform). Use cases now need to be defined that list typical problems encountered in disaster relief, and these use cases would be used as input to the system design requirements. The implemented design could be tested in a simulated environment, by setting up an experiment with actual relief workers and asking them to send their simulated help requests into the platform. The experiment would continue by engaging on a real user (the online community) evaluation that compared the results that used the ‘diversity factor’ with those using the existing system (i.e. the manual verification process). Another important test will be to prove whether or not diversity is actually needed at all. This could be tested by setting up a controlled experiment that tests the use cases with the Recommender System turned ‘off’ and then repeating this again with it turned ‘on’. The overall objective here is to conclude that the system provides accurate enough results for the onsite disaster experts to be able to trust the feedback given, and as such remove the labour intensive manual verification process, thereby freeing up the valuable resources of the relief teams in the disaster zones. References 1. Ariely, D., (2008) “Predictably Irrational: The Hidden Forces that Shape Our Decisions”, London, HarperCollins Publishers 2. Chesbrough, H.W., (2003) “Open Innovation: The New Imperative for Creating and Profiting from Technology”, United States, Harvard Business Publishing Corporation 3. Crisis Commons (2012) ‘Crisis Commons’ [WWW]. Available from: http://wiki.crisiscommons.org/wiki/Main_Page [Accessed 08/08/2012] 4. Lucus-McEwen, V., (2011) ‘If You Haven’t Heard About Crisis Commons Yet…’ Weblog [Online] 23rd October. Emergency Management. Available from: http://www.emergencymgmt.com/emergency-blogs/campus/Crisis-Commons-Monitors- Turkey-Earthquake-102311.html [Accessed 05/06/2012] 5. People Locator for the ChristChurch Earthquake (2011) ‘Sahana deployment example’ [WWW]. Available from: https://pl.nlm.nih.gov/christchurch/index.php?mod=inw&act=default [Accessed 25/10/2012] 6. Roddy, M., (2012) ‘An Analysis of the use of Cognitive Surplus in Disaster Relief Scenarios’ submitted to the Atlantic University Alliance as part of the Diploma programme in Innovation Management 7. Shirky, C., (2010) “Cognitive Surplus: Creativity and Generosity in a Connected Age”, London, Penguin Books 8. Sahana Software Foundation (2012) ‘Sahana Software Foundation Wiki’ [Online]. Available from: http://wiki.sahanafoundation.org/doku.php [Accessed 14/02/2012] 9. Sternberg, S., (2011) “Japan crisis showcases social media’s muscle” [WWW]. Available from: http://usatoday30.usatoday.com/tech/news/2011-04-11-japan-social-media_N.htm [Accessed 25/10/2012] 10. Suroweicki, J., (2004) “The Wisdom of Crowds: Why the Many Are Smarter Than the Few”, London, Abacus 11. Ushahidi (2008-2012) ‘The Ushahidi Platform’ [WWW]. Available from: http://ushahidi.com/products/ushahidi-platform [Accessed 27/02/2012] 12. Wikipedia (2012) ‘Bar Camp’. [Online]. Available from: http://en.wikipedia.org/wiki/BarCamp [Accessed 05/06/2012] 13. Wikipedia (2012) ‘Who Wants To Be A Millionaire?’ [WWW] Wikipedia. Available from: http://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire%3F [Accessed 16/08/2012] Disaster Management Tool (DMT) – Usability Engineering, System Architecture and Field Experiments Martin Frassl, Michael Lichtenstern, and Michael Angermann Institute of Communications and Navigation, German Aerospace Center (DLR) 82234 Wessling, Germany {martin.frassl,m.lichtenstern,michael.angermann}@dlr.de Abstract. The Disaster Management Tool (DMT) supports informa- tion management during crises. It has been designed to support field workers, on-site coordination centers and headquarters by facilitating an efficient flow of information between them. In this paper we describe the functionality and architecture of the DMT and give insight into our development process over the last four years. The DMT has undergone extensive field experiments during a series of Assessment Mission Courses (AMCs) for experts in coordination and assessment within the European Civil Protection Mechanism. Results and lessons learned from these ex- periments are presented. 1 Introduction Today’s international response to large scale crises is amazingly rapid and effec- tive. To a large extend this is owed to institutions such as the European Com- mission’s Monitoring and Information Center (MIC) based in Brussels or the United Nations’ Office for the Coordination of Humanitarian Affairs (OCHA) based in Geneva, which are important information hubs and help to coordinate the international response of many governmental and non-governmental relief organizations. International cooperation does not only increase the amount of available resources, but also requires a significant amount of coordination and communication by relief experts in the field. These experts have a proven track record that they are able to cope with complex and uncertain information, even with basic communication means, such as voice communication and basic of- fice computing software or even pen and paper. Nevertheless, several research strands, such as ad hoc and sensor networks, social computing, pervasive com- puting or combinations as in ambient intelligence are motivated to investigate the disaster management domain by the hope that their particular contributions could improve relief efforts. We are inspired by the skills of today’s disaster man- agement experts and the potential of the aforementioned technologies to combine them in a holistic fashion that builds on existing workflows and organizational structures. While we embrace the capabilities we may gain from mobile and em- bedded sensors and computational power, ubiquitous internet connectivity and 2 Frassl et al. Fig. 1. DMT hardware and user interface. vast amounts of information and cognitive resources from crowdsourcing and social networks, we are also concerned that exactly these assets are likely to be affected and potentially unavailable in disaster situations. Hence, our research focusses on how to use these technologies without critically relying on them. In previous work we have investigated the specific requirements for a tool to assist disaster management [5]. In the following paper we report on our work towards a software prototype that helps to study how experts use such a tool under field conditions. We briefly describe the application domain the system is intended to be used in. We describe the functionality and the system architecture of the DMT. Finally, we present and discuss evaluation feedback of users who worked with the DMT during several training missions. 1.1 Application Domain Background Europe has established the European Civil Protection Mechanism (EUCP mech- anism), a process of cooperation during emergencies. This mechanism can be activated by participating states for missions inside and outside of Europe. In such a case the participating countries join their efforts to share resources and increase efficiency [1]. Cooperation between organizations from several countries and a central information and coordination center in Brussels requires a common picture of the situation and thus information sharing across organizational and geographical borders. Prerequisite for a successful mission is a rapid assessment of the specific needs for the disaster response. Typically, several partners, both from the local emergency management agencies as well as international assess- ment and coordination experts, perform the assessment of a situation. Fast and reliable collection and exchange of findings are important to select the best- suited assets for relief. Assessment experts have already a variety of technical tools available: GPS navigation devices, satellite communication terminals, elec- tronic maps or web sites filled with information about the situation before the disaster. Working with these tools requires experience and time, with especially the latter being a scarce resource during a mission. Time pressure and other stressors tend to lower the frustration thresholds of users. To support disaster Disaster Management Tool (DMT) 3 management experts in the field, the UN system and the EUCP system have introduced dedicated support units, which cover information and communica- tion technology and a portfolio of additional tasks such as transportation, camp building, subsistence and administration. In UNDAC (United Nations Disaster Assessment and Coordination) missions, this role is frequently assigned to the International Humanitarian Partnership (IHP), an association of organizations from mainly Scandinavian countries. In EUCP missions TAST teams (Technical Assistance and Support) are available in the form of EUCP modules. Further- more, several non-governmental organizations (NGOs) provide assistance for a specific field, like Mapaction for the in situ production of maps or Ericsson Re- sponse for communication services. Nevertheless, basic knowledge like navigation with a GPS device or setting up a BGAN satellite terminal is expected from a coordination and assessment expert. 1.2 Related Work The difficulty of the challenges in the disaster management domain have at- tracted a growing number of researchers that contribute towards several of the involved problems. Meissner et al. have investigated a range of requirements and design challenges for an integrated disaster management communication and information system [7]. Furthermore, Meissner et al. drafted high-level archi- tectures for the communications and personal task scheduling subsystems. The need for rapid configuration of deployed network components has been recog- nized early and several groups have proposed to use rapidly deployable wire- less networks for disaster response to fill the gap of potentially disaster-affected communication infrastructures. Based on basic connectivity, autonomous peer- to-peer data exchange is an important step towards decentralization and robust- ness [3]. Some research groups work on transferring today’s workflows in disaster management to the digital domain [6]. Others strive to use new technologies and adapt them to the use in disaster management. A prominent example is the Ushahidi project, which aims at employing Web 2.0 technologies [9]. The work of the Sahana foundation on the application layer has achieved significant im- pact by applying and customizing available software components to the specific needs during a disaster [4]. 2 Development Process As described in a previous work-in-progress paper [5], we followed a primarily user oriented development paradigm. During the entire development process, prospective users have been involved at several stages to increase the usefulness and acceptance of the system, and to provide us with feedback and their wishes for features. User-centered development does not mean to only translate the user’s exiting processes identically to a digital version. Additionally, we strive to introduce new ideas and to adapt these to the user’s needs. During the last four years, the evolving prototypes of the system have been tested and evaluated 4 Frassl et al. by users, and their feedback has been reviewed and directly included into new developments. Details about our requirement analysis and development process, i.e. the Adaptive Frequency Spiral Model (AFSM), a modified version of Boehm’s well-known spiral model, specifically tailored to the disaster management domain can be found in [5]. During the last years, we had the chance to work with different groups of end users, mainly assessment experts and TAST members. Up to now the DMT has been presented to and used by 89 participants of the Assessment Mission Course (AMC) and 13 participants of the Staff Management Course (SMC) - both courses are part of the European Civil Protection Training Program - plus approximately 40 participants of the TAST training courses of the German Federal Agency for Technical Relief (THW), and 18 participants of an international training in the context of the EU LIMES project. 2.1 Timeline In the early phase of the DMT’s development, we emphasized the collection of requirements and the analysis of the processes in disaster management opera- tions. The temporal evolution of the added functionality can be seen in Fig. 2. The participation at the operations on the G8 Summit in Heiligendamm in June 2007 and the INSARAG certification of a THW Heavy Urban Search and Res- cue (USAR) team in August 2007 in Hoya were important steps to get a basic understanding of tasks and operational procedures. We observed workflows and conducted many informal interviews about information management in disaster relief operations. At the end of a first cycle of requirements analysis, we par- ticipated at the second AMC in the 5th training cycle in November 2007 (i.e. 5AMC2), where an initial set of functional and non-functional requirements for a Disaster Management Tool evolved [5]. Based on these requirements a first G8 Hoya 5AMC2 6AMC1 7AMC1 7AMC2 7AMC3 8AMC1 8AMC2 8AMC3 9AMC1 2007 2008 2009 2010 2011 Point Of Interest (POI) form factor software architecture usability engineering multi mission coordinate converter map management 3D graphics UI redesign shape mangement remodel gateway remodel network distributed network bookmarks (views) stability review architecture Fig. 2. Timeline of the DMT development prototype had been developed and implemented by the time of 6AMC1 in June 2008. Most of the basic concepts which are still valid in the current DMT ver- sion, such as the distributed network synchronization of the data or the spatial data aggregation in a Point Of Interest (POI) have been used here for the first time. In this early stage of development, the hardware composition, i.e., a box containing a small computer, a touch screen, several sensors, satellite terminal, rechargeable batteries, chargers etc. added up to 25 kilograms – too heavy for Disaster Management Tool (DMT) 5 mobile operations. In addition, a proprietary development of a 3D globe visual- ization turned out to be slow and unstable. Nevertheless we received generally good user feedback which motivated us to develop a completely new system, including a redesigned user interface in which we replaced the initial 3D globe visualization with NASA World Wind Technology [2]. We reduced the form fac- tor by using smaller boxes and replacing the computer and the separate touch screen with an off-the-shelf laptop. Additionally, the functionality was extended by adding several new features like placemarks, for the next system iteration in June 2009, at the 7AMC1. Beginning from this stage, the user experience was satisfactory, but the underlying software architecture became more and more cluttered. For the next AFSM cycle we concentrated on a review of the over- all system architecture. Furthermore, we modified the user interface (UI) for increased usability and redesigned the underlying distributed network for data synchronization. This version has been presented and tested by the course par- ticipants at the subsequent AMC (7AMC2) in November 2009. More features have been included and evaluated in every iteration. To obtain quantitative user feedback we deployed a usability engineering process based on questionnaires for the 7AMC3. Initial results revealed a lack of stability. Due to the fact that there were only two months to the 8AMC1 in June 2010, we concentrated on this issue. For the AMC in November 2010, we again extended the function- ality by implementing a multi-mission capability, which enables the system to concurrently handle multiple missions in parallel. 2.2 Usability Engineering Our usability engineering process is based on the following methods: participat- ing user observation, informal interviews and questionnaire based evaluation [8] [11]. We use the method of participating user observation, i.e. to join in perform- ing the users’ tasks. In the beginning we used this method to gather initial system requirements. Now it serves as a feedback channel to study the acceptance of im- plemented functionality, and to obtain novel ideas and demands for the DMT. Observing the user in the field (at least during exercises and trainings) gives insights that are difficult to obtain in simulated environments (e.g. a usability laboratory). Informal interviews help to constantly improve our understanding of the users and their experiences with the DMT. This informal feedback chan- nel revealed many subconscious requirements and weaknesses of the system. To obtain quantitative user feedback we developed a questionnaire-based evaluation process to identify strong and weak points of the system and to revise require- ments. Revising requirements includes the derivation of new requirements and points out functionality which has not been proven to be particularly useful, and therefore needs to be redesigned or even removed from the system. The questionnaire is divided into three parts. The first part is about the background of the user, including gender, age, expertise as well as computer and mission experiences. In the second part the user has the possibility to rate experiences with the DMT on a 5-step scale (strongly disagree, disagree, neutral, agree and strongly agree). The nine questions presented to the user are: 6 Frassl et al. 1. In my opinion the Disaster Management Tool (DMT) is easy to use. 2. I think the provided services (e.g. Points Of Interest, Map handling, etc.) fit the requirements for disaster management. 3. The way data is entered into the system is appropriate and efficient. 4. The software provides me with valuable information to fulfill my tasks. 5. I can find the needed functionality, and do not have to consult the trainer. 6. The system performance is adequate and does not slow my work. 7. The system is supporting the relief work and does not distract or limit me doing my work during relief operations. 8. The Disaster Management Tool increases the situation awareness and there- fore supports better coordination of relief operations. 9. I would use the DMT-System for my work. In the third section the user writes free text to suggest missing or unnecessary functionality and what he or she likes or dislikes about the DMT. Results of the usability engineering process are included in Section 4. 3 Technical Prototype and Core Functionality Functional and non-functional requirements for an information management sys- tem in disaster management have been reported in [5] and have driven the def- inition of the DMT’s core functionality. The purpose of the DMT is to assist information management during disaster relief operations. The system’s visual core component is a dynamic situation map, based on a 3D globe on which geospatial information of various types are displayed. Examples are vector data like points of interest, augmented with specific text or imagery information, polygons to mark a certain area, or rasterized information such as satellite maps based on images taken before or after the mission or digital elevation models. Tools to handle the input, output and management of the data are offered. Sev- eral sensors, such as position and attitude sensors, can be attached and processed for different purposes such as showing the own position on the map or sending it to other users. Additionally all other relevant data items in the system are shared among all connected instances of the DMT, resulting in a distributed, de- centralized and disruption-tolerant system. Depending on the available network infrastructure, the best connections are chosen to transmit the information, be it an ad hoc, infrastructure or satellite connection. 3.1 Modular Architecture In order to maintain a stable and extendable software architecture the function- ality of the DMT is partitioned into five modules: – User Interface for visualization and user input – Data Hub / Synchronization for managing data objects – Persistence for storing of data objects – Network for providing transparent communication – Sensors (and the affiliated sensor fusion) to manage external hardware Disaster Management Tool (DMT) 7 The cornerstone of the DMT software architecture is the Data Hub. All informa- tion, independent from its origin (data storage, network, user input), is passed through this component. When the user enters information via the UI, data is received via the network module, or a sensor transmits a new measurement, the Data Hub decides what to do with it. The data is analyzed and accordingly for- warded to other modules. The Data Hub module is responsible for ensuring that new information is synchronized with other DMT instances via the distributed network. If the user enters new data via the UI, the Data Hub informs the Per- sistence component and sends a notification via the Network component. If the network component receives a notification about new data on the other side, the data is requested and upon reception forwarded to the Persistence and the UI component. The User Interface is designed under the paradigm of keeping its complexity to a minimum, offering necessary, but avoiding all nonessential “ex- pert” functionality. There are mainly two reasons for this approach. Firstly, the DMT system is generally used by users, who are not working with the system in their daily work. Secondly, the users use the system in a stressful environment. Therefore the main interface is condensed to a minimalistic on-screen menu with the possibility to manage the most important data types and system settings (Points Of Interest, Shapes, Maps, Bookmarks, Units, System Settings). Beside the menu, the NASA World Wind globe is the central visualization element, where all spatial data is shown (see Fig. 1). In the Persistence component, two main tasks are encapsulated, the reliable storage of all data and the guarantee of data integrity. After a restart of the DMT system, the stored information is read from a persistent storage and loaded into the system. The current imple- mentation is based on the operating system’s file system, which is reliable and has no further installation requirements. Through the modularized architecture, encapsulation of the functionality to other modules and clear interfaces, a re- placement of the underlying information storage technology by other solutions like a database can be carried out with minimal effort. The Network module offers an interface for a reliable and efficient data exchange. This module is re- sponsible to handle network-related tasks, such as finding neighboring hosts and starting the initial connection procedure, or selecting the appropriate commu- nication channel (TCP, UDP via Wi-Fi, satellite network, etc.) to an already known host. Network connections are chosen based on their availability and a cost function, depending on the data characteristics and the current status of the system. The Sensors component represents a layer of abstraction for binding external sensors, such as GPS receivers or a 3D compass to the system. Sensor input is preprocessed and fused within the Sensors module. Sensor fusion offers the possibility to combine several sensor inputs to improve the quality of the output, such as a more precise position by combining several Global Navigation Satellite Systems (GNSS) and/or acceleration sensors [10]. In order to provide access to a sensor’s status and measurements or to set parameters for a sensor, this module has a direct interface with the UI. 8 Frassl et al. 4 Field Experiments and Results It was very insightful to observe the users using the DMT in the field. Several problems and gaps have been discovered. Main issues were hardware and stability problems, environment specific problems, such as direct sunlight exposure and reduced interaction possibilities (e.g. no mouse) in the field. Some new features have been implemented after observing the users having problems or wasting time, for example the need for extended export functionalities, as users still use their well known software tools and have to follow the predefined reporting chain, or a coordinate conversion tool to rapidly access different formats of a coordinate. In general, the users were very motivated to give direct feedback to the observing developers and many new ideas have been collected this way. 4.1 User Feedback and Empirical Findings In this paper we analyze the rated second part of our questionnaire (see Section 2.2), which provides quantitative measures of user experiences with the DMT. We collected data during five AMCs: 7AMC3, 8AMC1, 8AMC2, 8AMC3 and 9AMC1. Each AMC has room for up to 20 participants, who are grouped into four teams. Thus, each team consists of up to five team members. On each AMC 5 4 3 7AMC3 8AMC1 8AMC2 2 8AMC3 9AMC1 1 0 DMT is easy to use DMT fits the data entering is soŌware provides info trainer needs to be performance adequate increases awarness -> DMT is supporƟng not would use DMT for requirements appropriate to fulfill task consulted not slowing beƩer coordinaƟon distracƟng work Fig. 3. Evaluation results: mean values of the user experiences with the DMT we took part in, we started by giving a general briefing on the DMT to all participants. Subsequently, we gave a more detailed training to a subset of these participants (initially one team, in later AMCs up to three teams) on the software and supported them in using it for the assessments during the three course days. While we usually gave close support in the first day of the course, we reduced the support over the following days. The teams typically used the system on their own on the third day. Within the 7AMC3 the Disaster Management Tool was used by one team of five participants and by a team of four participants on 8AMC1. In the 8AMC2 three assessments teams used the DMT software during the training course, which resulted in 13 valid questionnaires. As a result of the difficulties of monitoring more than one team in the field we evaluated again one team at the 8AMC3 with five participants and four participants during Disaster Management Tool (DMT) 9 the 9AMC3. The overall result from the questionnaires indicate encouraging acceptance by our users. Only two aspects score below 4 for all surveys. These are question 3, ”The way data is entered into the system is appropriate and efficient.” and question 5, ”I can find the needed functionality, and do not have to consult the trainer”. To analyze the reason for the relatively low score on data entering, we asked the users in informal interviews why they think that this issue is not ideally solved in the DMT. The result was, that the users are used to enter text with standard office software (Microsoft Word) and therefore miss functionality like tagging text by putting bold, italic or underline in the DMT. Also the possibility of structuring lists with bullet points or indenting paragraphs is an important feature for them. Currently, the data entering box is a textfield which does not offer formatting possibilities of text and therefore does not sufficiently meet this requirement. The score for question 5 can be ascribed to the fact that the users on the AMC get only 30 minutes of training on the system and afterwards they have two DMT trainers joining and supporting them during the assessments. Directly supporting the user in the field increases the users’ awareness of the DMT’s features, but on the other hand reduces their self- confidence of using the system without instructions, resulting in the consistently suboptimal score. At the moment we assume that a change in the training and support balance as well as compact documentation (”cheat sheets”) on how to perform specific tasks with the DMT should have a positive effect on this issue. 5 Conclusions and Outlook The DMT has reached a level of stability that allows its operation by users other than its developers. Its current set of functionality supports coordination and assessment experts in their mission-related tasks. This encompasses the efficient collection, comprehensive displaying and automatic sharing of information. A range of additional helping functionalities, such as automatic conversion between coordinate systems or exporting of its data to feed into reports. Our observations of users working with the tool, informal feedback, as well as formalized feedback in the form of questionnaires have driven the addition and sometimes removal of functionalities. While robustness and consolidation of its functionality remain our foremost priority, we will continue to integrate novel concepts into the DMT. Many new ideas have been proposed by our users and have been captured in our usability engineering process. A particularly interesting concept is to leverage social networks by motivating their users to offer their “cognitive surplus”, to remotely assist in missions. Experts in specific fields, such as structural engi- neering, language and cultural expertise could contribute without actually being present in the field. Organized online communities could accomplish time con- suming tasks, such as spotting specific features in aerial images or tracing road networks in a parallel and rapid fashion, literally from their living rooms. This would take off workload from relief workers and empower the general public to contribute to disaster relief. When these concepts will mature they will find their way into the mission-approved version of the DMT. 10 Frassl et al. 6 Acknowledgements This work is partially funded by the Helmholtz Foundation and the SOCI- ETIES (Self Orchestrating CommunIty ambiEnT IntelligEnce Spaces) project, co-funded by the European Commission within FP7. We thank the NASA World Wind Project, in particular Patrick Hogan and Tom Gaskins for providing the outstanding World Wind technology. We thank Dr. Susanne Wacht (THW) for the chance to regularly teach at the THW’s TAST courses and are deeply in- debted to Claus Höllein (THW), Harm Bastian Harms (Johanniter International Assistance) and Wolfgang Krajic (synergies) and all participants and trainers for their feedback, support and the possibility to join the Assessment Mission Course (AMC), which was and is essential for the development of the DMT. References 1. 2010/481/EC, Euratom. Commission decision of 29 july 2010 amending decision 2004/277/ec, euratom as regards rules for the implementation of council decision 2007/779/ec, euratom establishing a community civil protection mechanism. Brus- sels, Belgium, 2008. 2. D. Bell, F. Kuehnel, C. Maxwell, R. Kim, K. Kasraie, T. Gaskins, P. Hogan, and J. Coughlan. NASA World Wind: Opensource GIS for mission operations. In Aerospace Conference, 2007 IEEE, pages 1–9, march 2007. 3. A. Capata, A. Marrella, R. Russo, M. Bortenschlager, and H. Rieser. A geo- based application for the management of mobile actors during crisis situations. In Proceedings of the 5th ISCRAM, Washington, DC, USA, 2008. 4. M. Careem, C. De Silva, R. De Silva, Raschid, and Weerawarana. Sahana: Overview of a disaster management system. In Information and Automation, 2006. ICIA 2006. International Conference on, pages 361–366, 2006. 5. M. Frassl, M. Lichtenstern, M. Khider, and M. Angermann. Developing a system for information management in disaster relief - methodology and requirements. In Proceedings of the International Community on information systems for crisis response and management (ISCRAM 2010), Seattle, Washington, USA, 2010. 6. M. Khalilbeigi, D. Bradler, I. Schweizer, F. Probst, and J. Steimle. Towards com- puter support of paper workflows in emergency management. Proceedings of the 7th International ISCRAM Conference–Seattle, USA, 2010. 7. A. Meissner, T. Luckenbach, T. Risse, T. Kirste, and H. Kirchner. Design chal- lenges for an integrated disaster management communication and information sys- tem. In Information System, DIREN 2002 (co-located with IEEE INFOCOM 2002, 2002. 8. J. Nielsen. Usability Engineering. Morgan Kaufmann, 1st edition, Sept. 1994. 9. O. Okolloh. Ushahidi, or ’testimony’: Web 2.0 tools for crowdsourcing crisis infor- mation. Participatory Learning and Action, 59(1):65–70, 2009. 10. P. Robertson, M. Angermann, and B. Krach. Simultaneous localization and map- ping for pedestrians using only foot-mounted inertial sensors. In Proceedings of the 11th international conference on Ubiquitous computing, Ubicomp ’09, pages 93–96, New York, NY, USA, 2009. ACM. 11. B. Shneiderman and C. Plaisant. Designing the user interface : strategies for effective human-computer interaction. Addison-Wesley, 2010. Smart Jacket as a Collaborative Tangible User Interface in Crisis Management Monica Divitini1, Babak A. Farshchian2, Jacqueline Floch2, Bjørn Magnus Mathisen2, Simone Mora and Thomas Vilarinho2 1 1 NTNU, N-7491 Trondheim, Norway {monica.divitini, simone.mora}@idi.ntnu.no 2 SINTEF ICT, N-7465 Trondheim, Norway {babak.farshchian, jacqueline.floch, bjornmagnus.mathisen, thomas.vilarinho }@sintef.no Abstract. Collaborative AmI technologies have the potential to increase the efficiency and effectiveness of rescuers during crisis response work. However, few AmI technologies are designed specifically for such scenarios. Our findings from a number of case studies have resulted in a set of requirements. In this paper we present some of these findings. We then present a second generation AmI tool that was developed to support our users. The tool is a jacket equipped with a number of sensors/actuators allowing coordinators to draw the attention of rescuers in the field and to provide them information and commands. The tool is currently undergoing evaluation in collaboration with our users. 1 Introduction The ability to get accurate and on-time situation awareness and to coordinate rescuer teams effectively is essential for crisis management. The efficiency of response actions impacts directly on the extent of damages, the number of saved lives and the reduction of risks for rescuers. A major challenge for rescuers on the fields is to combine tasks that require full concentration and physical effort with the use of communication and collaboration tools. Today, a number of technical tools, such as computers, sensors, cameras and ad-hoc networking equipment, are regularly operated by rescuers in disaster areas. Pervasive and ambient computing technology can be applied to support the rapid and accurate collection of data, and efficient decision-making, and situational awareness [1]. Moreover, a variety of collaborative software tools are used to manage and coordinate rescuer teams [2]. Research shows that traditional desktop-based computer interfaces are not suited for supporting all the collaboration needs in the field. Social and cognitive aspects should be considered strongly when designing future systems. For instance, Kwon et al. [3] report that that the use of synchronous audio communication can create overload and sometimes confuse the rescuers. 2 Babak Farshchian et al. This paper focuses on the user interface with the system. We explore tangible user interfaces that can be integrated in a smooth and non-intrusive manner in the rescuer environment, and plugged in and shared in a collaborative software tool. An example of such tangible interfaces, a smart jacket, is presented. In addition, related to cognitive aspects, we explain how the capabilities of the presented tool can be exploited to reduce abruptions when sharing information during a rescue. This paper is structured as follows: Section 2 shortly introduces the research approach. Section 3 describes our findings from a number of case studies and observations of users. Section 4 and 5 describe our scenario and how our implementation can potentially solve some coordination problems for the rescuers. Section 6 presents the system implementation. Finally Section 7 concludes this paper and presents our future research plan. 2 Research approach Our research follows the design science paradigm [4]. While behavioural-science approaches focus mainly on the use and benefits of a system implemented in an organization, design science approaches develop and evaluate IT artefacts intended to solve identified organizational problems. Developing such artefacts requires domain knowledge and justification in form of proper evaluations. The design science recursive process was used to develop our system. Our research started with two sets of domain-related data from two European R&D projects, Mirror1 and SOCIETIES2. As part of the Mirror project, a set of case studies and observations involved rescuers from the Italian civil defence during a simulation of a massive disaster held in 2011 in Italy [5]. Another set of data came from focus groups and interviews with the European Urban Search And Rescue (USAR) as part of the SOCIETIES project [6]. The analysis of these data gave us a set of overall requirements that will be discussed in the next section. Based on this set of requirements we developed a first generation tool: a wristband developed using the Arduino platform3 for the rescuer (see Figure 1), and a table-top interface for the coordinator[5]. Informal demonstrations of the tool for our users revealed several shortcomings in the tool. Based on this feedback we developed the second generation of the tool which is documented in the following sections in this paper. The second generation is also integrated with the collaboration-support platform being developed in the EU project SOCIETES, and in this way is also used as a proof-of-concept for that platform. 1 http://www.mirror-project.eu/ 2 http://www.ict-societies.eu/ 3 http://www.arduino.cc/ Smart Jacket as a Collaborative Tangible User Interface in Crisis Management 3 Figure 1: The first prototype of a tangible interface to support cooperation during a crisis 3 User observations and requirements User studies carried out during a simulation of a massive disaster held in 2011 in Italy have shown that rescuers still rely largely on handheld transceivers (e.g. walkie- talkies) to communicate and coordinate the work. During rescue operations, the rescuers are given instructions by a coordinator through radio broadcasts. At the same time, they have to communicate back information, such as their position, environmental data (temperature, humidity, air quality) in a half-duplex communication channel. Rescuers need to remember and execute the tasks they are assigned to (by the coordinator) without any technological aid. In the meantime personnel in the coordinator side transcribe radio communication and update the positions of the teams and data they have collected using annotations on a map. We divided our analysis based on the two main users in our scenarios: the rescuers (in the disaster field) and the coordinators (in a back office or in a tent coordinating the rescue). From an AmI perspective, the rescuer role is the most interesting one. Our observations showed that the usage of consumer hardware, like touch-screen smartphones or tablets, is not a good design choice for the rescuers. Indeed rescuers wear touchscreen-unfriendly gloves, require high screen readably, and depend on high battery capacity. Also, they often wear blouses without additional pockets for such devices. Furthermore the design should avoid requiring the rescuer to interrupt her task in order to interact with the tool. The first prototype of a tangible and wearable device to support data capturing and inter-role coordination was developed in the shape of a wristband (Figure 1). It supports automatic capture of the rescuer’s location, environmental temperature and noise, and it is able to display text messages broadcasted by the coordinators. The rescuer can send a digital acknowledgement to the coordinators, for example when a task has been accomplished, without interrupting the work (using gestures and proximity-activated buttons). An early evaluation of the prototype with users has revealed a good acceptance of the system. However, the size of the tool and its wearability weren’t considered satisfactory. The users called for a smaller device and asked for a user interface able to be operated leaving hand and lower arms totally free to operate in the rescue scene. 4 Babak Farshchian et al. 4 Scenario and tool functionality Based on our observations the following application scenario (see Figure 2) is set up and implemented. The scenario will be evaluated by the USAR team in SOCIETIES. Figure 2: Coordinator and rescuers each have their own user interface. Background. An earthquake of magnitude 7.8 with epicentre about 32 km South- West of the island of Cyprus has caused severe damage and casualties. The local response capacity is exceeded and the government of Cyprus has requested international assistance. Several international rescue experts, like USAR and medical support have been sent to Cyprus to support the local emergency management. Initial technical setup. All team members are equipped with Android devices running the collaboration tool iDisaster. Knut the coordinator uses an Android tablet (simulating a laptop), while Tor the rescuer uses an Android touch-based phone (see Figure 2). As part of the initial setup (prior to the operational phase in the field) the following actions are performed by the coordinator and each rescuer: Knut (Coordinator): 1. Creates teams: Knut uses iDisaster GUI to create a new team called "Larnaca" with information about the mission, location of the mission, and other relevant information about the disaster. 2. Adds rescuers to the team: Knut browses a directory of rescuers and adds the ones needed for this mission, including Tor. After the rescuers are added, they get access to the "Larnaca" shared space provided by iDisaster, created in step 1 above. Smart Jacket as a Collaborative Tangible User Interface in Crisis Management 5 3. Recommends services: Each mission will have specific needs regarding what tools will be used. Knut browses a directory of services and adds them as recommended services to the shared area for the team to use. One of these services is iJacket. Services give access to external physical tools such as sensors and actuators. Tor (Rescuer): 1. Installs recommended services: After Tor is added to the "Larnaca" team he receives a notification and is asked whether he wants to add the recommended services (apps) to his phone. He answers yes and some software is downloaded and installed automatically on the smart phone. 2. Sets up services and tools: One of the services that were recommended by Knut was the iJacket service. This is a service that supports communication with the smart jacket that all rescuers wear (see Figure 3). Tor scans the jacket QR-code to establish connection between his Android smartphone and the smart jacket (Figure 3.B). The service displays the set of actuators and sensors available on the jacket. Tor can test that they all work properly: display, loudspeaker, LED lamp and vibrator are all operative. Operation in the field. Following the preliminary set up, all rescuers have now joined their teams. Knut coordinates individuals and teams using the iDisaster GUI and the services. Using the iJacket client, he commands Tor to examine the structure of a building in the Athenon street. Tor’s jacket immediately vibrates and displays the command. Later, as the weather forecast indicates shifting winds, he sends a warning to all team members in Larnaca. The LED lamps on their jackets are switched on. At any moment, the team members can, using iDisaster, retrieve the messages sent to the teams or to themselves. Figure 3: The smart jacket 6 Babak Farshchian et al. 5. Analysis of the scenario Rapid and undisruptive coordination of actions and situation awareness are the main goals of the system. This is done through a) A light-weight mechanism for sharing of information: The system supports real-time sharing of information that is posted in a shared space called a CIS (Collaborative Interaction Space). "Larnaca" in the example above is a CIS. b) Undisruptive interaction mechanism, in particular for the rescuers: Rescuers should be able to concentrate on their tasks. Physical user interfaces support peripheral awareness of situations without the need for complicated operations. The system interface, in form of the smart jacket, tries not to compete for their attention. In this phase of our research we have focused mainly on the "Operation in the field" part of the scenario. We have tried to apply points a) and b) to the field operation phase. The "Initial technical setup" might seem too complicated in its current form. There are a number of opportunities to improve the setup phase such as using templates and recommendations. One particular example is the use of QR codes and NFC tags to facilitate the setting up of tools such as the smart jacket and other sensors/actuators. This is already part of our implementation. In the near future we will do more experiments in order to improve the initial setup phase. 6 Implementation We are using a number of exiting platforms to realize our scenario.  Arduino4 boards and sensors/actuators are used inside the jacket in order to implement the physical prototype. Figure 3.C and D show how the physical prototype looks like. Figure 4 below shows how this is done in the overall architecture.  Android OS5 and devices are used to implement the remaining parts of the user interaction (the middle box of Figure 4).  Virgo and OSGi6 are used for implementing a back-end where shared data from a CIS is stored and accessed by the various Android devices (left-most box in Figure 4). On top of the above platform we have built a number of components (shown as grey boxes in Figure 4):  CIS Manager: This is a back-end component that stores data about shared spaces (CISs). It provides interfaces for creating, managing and notifying about changes. 4 http://www.arduino.cc/ 5 http://android.com/ 6 http://www.eclipse.org/virgo/ Smart Jacket as a Collaborative Tangible User Interface in Crisis Management 7  CIS Manager client: This is an Android-based client for CIS Manager. It is implemented in form of an Android Content Provider7. It communicates with CIS Manager using XMPP messaging technology8.  iDisaster and iJacket: These are Android applications that allow coordinator and rescuer to interact with and configure the functionalities provided by CIS Manager and the smart jacket.  Bluetooth library (BT lib) and Jacket app are Arduino-based applications that facilitate communication between iJacket and the real jacket. Figure 4: Overall architecture. Grey boxes are implemented for the realization of the scenario. 7 Conclusion and further work Our near future work is to evaluate the current prototype with our users. Our focus will be on the user interaction mechanism, which metaphors are suited for crisis management work and which hare not, and get feedback on what sensors and actuators will be necessary for a real field deployment of such a physical tool. In the long run we want to collect and systematise knowledge about what interaction metaphors are empirically proven to work in the similar scenarios where physical work is in focus. From a technical point of view, our goal is to develop a library or toolkit of primitives that will make it easier for application developers to develop similar physical applications on top of Arduino and Android. Acknowledgments. Our research is supported by EU IST 7th framework programme. This paper results from the collaboration between the projects SOCIETIES (contract 257493) and Mirror (contract 257617). 7 Content providers are a standard way of providing access to shared data in an Android device. 8 http://xmpp.org 8 Babak Farshchian et al. References 1. Lukowicz, P., Baker, M.G., Paradiso, J.: Guest Editors’ Introduction: Hostile Environments. IEEE Pervasive Computing. 9, 13–15 (2010). 2. Hiltz, S.R., Diaz, P., Mark, G.: Introduction: Social media and collaborative systems for crisis management. ACM Transactions on Computer-Human Interaction. 18, 1–6 (2011). 3. Kwon, G.H., Smith-Jackson, T.L., Bostian, C.W.: Socio-cognitive aspects of interoperability: : Understanding communication task environments among different organizations. ACM Transactions on Computer-Human Interaction. 18, 1–21 (2011). 4. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design Science in Information Systems Research. MIS Quarterly. 28, (2004). 5. Cernea, D., Mora, S., Perez, A., Ebert, A., Kerren, A., Divitini, M., Gil de La Iglesia, D., Otero, N.: Tangible and Wearable User Interfaces for Supporting Collaboration among Emergency Workers. In: Herskovic, V., Hoppe, H.U., Jansen, M., and Ziegler, J. (eds.) Collaboration and Technology. pp. 192–199. Springer Berlin Heidelberg, Berlin, Heidelberg (2012). 6. Jacqueline Floch, Michael Angermann, Edel Jennings, Mark Roddy: Exploring Cooperating Smart Spaces for Efficient Collaboration in Disaster Management. Proceedings of the 9th International ISCRAM Conference. , Vancouver, Canada (2012). Key challenges in multi-agency collaboration during large-scale emergency management Aslak Wegner Eide, Ida Maria Haugstveit, Ragnhild Halvorsrud, Jan Håvard Skjetne, and Michael Stiso SINTEF ICT, Oslo, Norway {aslak.eide, ida.maria.haugstveit, ragnhild.halvorsrud, jan.h.skjetne, michael.stiso}@sintef.no Abstract. This paper reports the results of a workshop studying the challenges of collaboration during emergency response in Norway. The findings from the workshop reveal three categories of challenges linked to collaboration both within and across emergency agencies: (1) communicating within and across emergency agencies, (2) establishing and maintaining shared situation aware- ness, and (3) inter-organizational understanding. Underlying barriers hindering efficient collaboration are identified for each of the three categories. Against this backdrop, the paper discuss opportunities for ambient intelligence technol- ogy that can help mitigate the identified challenges. Keywords. Emergency management, collaboration, ambient intelligence 1 Introduction In large-scale emergency management, an activity characterized by constantly changing task demands [6, 9], collaboration within and between emergency response agencies is essential. Unfortunately, such collaboration is difficult because of not only the complexity of the incident, but the diverse composition of people and agencies working together, all of whom possess different skills, procedures, knowledge, and competencies. As a result, almost without exception, reports and reflections after disasters express concerns over the emergency agencies’ abilities to collaborate. A recent example of this can be found in the concluding report on the terror attack in Norway on June 22, 2011, stating that the various emergency agencies (fire, police, health) were unable to effectively communicate and coordinate their effort [8]. In this paper, we report on a workshop that focused on the challenges of collabora- tion between and within emergency agencies during incidents in Norway. The work- shop was attended by first responders in Norwegian emergency agencies, giving them a chance to provide a bottom-up perspective and practitioner's viewpoint on collabo- rative challenges. The workshop was conducted as part of the FP7 BRIDGE research project, a 4-year project aiming to develop technology that improves collaboration during emergency response [2]. 2 Method The workshop was one step in the human-centered design approach we are follow- ing, the goal of which is to ensure that the design and development of an interactive system takes the needs of its users into account [7]. It was intended to address the common difficulty in that approach of involving domain experts in the innovation process, whether the early phases of context research and idea generation or the later phases of development, refinement, and implementation [4]. In this study, domain experts from emergency agencies were recruited from the Norwegian fire, police, and health services. In total, 10 such experts participated, each having several years of experience in on-site emergency response. Those 10 were divided into 3 groups consisting of at least one member of each agency. Each group was coordinated by a ‘facilitator’, whose main responsibility was to assign exercises, clarify any methodological issues, and keep on schedule. During the workshop, the groups were asked several trigger questions about cur- rent work practices during emergencies. Two questions were considered to be the most important and were therefore posed to all three groups: (1) How do you set up the emergency organizations on-site, and which roles and responsibilities can be iden- tified? (2) How do you obtain an understanding of the unfolding emergency situation, and how do you maintain such an understanding? The remaining questions were dis- tributed among the groups and addressed communication issues, the decision making process, resource management, risk analysis, and interaction with bystanders, media, and experts. We used affinity diagramming [5] to form the experts' discussion points into ad- hoc hierarchical groupings of structures and themes, the goal being to highlight rela- tionships between various issues that fell under the topics discussed [1]. The method was enhanced by letting each participant use colored sticky notes indicating their agency (police, fire, and health), as well as two colors to indicate specific information needs and specific challenges. Fig. 1 shows an example of the arrangement of sticky notes. Colour scheme: red = fire, green = health, blue = police, yellow = information need, orange = challenge. Fig. 1. Domain analysis using sticky notes and affinity diagramming The workshop followed a common procedure in each group: (1) Facilitator pre- sents trigger question; (2) participants write their responses on sticky notes; (3) itera- tive posting/diagramming of individual contributions in a shared physical space; and (4) continuous discussion and consolidation of content in relation to other contribu- tions. Group discussions were documented using audio and video recording, and a ‘secretary’ supported the data collection process by taking notes and pictures. Each group thus produced data in the form of (1) a set of affinity diagrams (one for each trigger question asked within each group) made up of sticky notes describing tasks, challenges, and information needs connected to each given trigger question, and (2) audiovisual recordings of the discussions that took place during the diagramming process. The collected data was analyzed in four steps. In the first step, the sticky notes were counted, translated, and cataloged using an Excel spreadsheet. Sticky notes that were difficult to decipher were either rejected or (when possible) verified through audio and/or video recordings. Second, any listed tasks and challenges in the dia- grams were categorized into respective groups. Third, tasks were further categorized according to which agency they belonged to, and each challenge note was supple- mented with an interpretation of it. When necessary, those interpretations were de- rived from audio and/or video recordings from the diagramming process. Finally, we subjectively categorized the resulting set of challenges, extracting those important to collaboration during emergency response and, within that subset, deriving groups of challenges based on shared themes. 3 Findings The workshop revealed a wide variety of tasks and challenges that emergency re- sponders face during crisis incidents. It also shed light on challenges related to other aspects of emergency response, such as lack of resources, time-criticality, and hazardous environments. However, in this paper, we have chosen to disregard the latter types of challenges and focus solely on those related to collaboration within and across emergency agencies. In sum, over 200 sticky notes describing tasks and challenges in emergency re- sponse were collected. Of those notes, 87 described challenges linked to emergency response, and of those, 33 described challenges related to collaboration. Additional details can be found in Table 1. The analysis of the material revealed three overall categories of collaboration chal- lenges: (1) communicating within and across agencies, (2) establishing and maintain- ing shared situation awareness, and (3) understanding organizational structures. In the remainder of this section, we describe each of these categories in detail, and the barri- ers in each category that hinder efficient collaboration during emergency response. Note type Group 1 Group 2 Group 3 Total (relevant) Police 35 12 20 67 tasks Fire service 35 8 18 61 tasks Health service 19 5 19 43 tasks Challenges 29 20 38 87(33) Table 1. Overview of collected sticky notes 3.1 Communicating within and across agencies Based on the results from the workshop, it is often a great challenge for emergency responders to achieve efficient communication both within and across agencies. Out of the 33 relevant sticky notes, 15 notes described challenges linked to communica- tion. Participants reported that it is generally difficult to exchange information be- tween emergency agencies (particularly with agency representatives at the operative level), and to establish an efficient flow of communication between field personnel. According to the participants, one main barrier hindering efficient communication is the radio network, because of a lack of radio capacity and other technical problems. During large-scale incidents, emergency agencies make use of a shared radio channel (called the rescue channel) for interagency communication. However, due to the sub- stantial amount of coordination that is required during such incidents (particularly in the initial phase), and the fact that only one user may use the channel at a time, it is often difficult for users to get through with their message. A second barrier for achieving efficient communication is the common lack of knowledge in how the rescue channel should be used. For example, as explained by one participant, some agencies use the rescue channel for communicating within the agency, even though all agencies have their own dedicated channels for such purpos- es. The resulting increase in radio traffic can hinder actual interagency messages from getting through A third barrier for achieving efficient communication is the lack of a common lan- guage and terminology across emergency agencies. The Norwegian emergency agen- cies not only use different terms, they also assign different meanings to the same terms. For example, one participant described a situation where the police requested an ambulance to pick up a patient with life-threatening injuries, describing the situa- tion as urgent. In the terminology of the ambulance personnel, however, urgent is not considered to be life-threatening (they use the term acute for this purpose), causing them to misunderstand the severity of the situation. 3.2 Establishing and maintaining shared situational awareness The workshop participants revealed that it is challenging to establish and maintain shared situation awareness among the agencies and actors participating in an emer- gency effort. Out of the 33 sticky notes analyzed, seven highlighted general difficul- ties in establishing situation awareness across involved actors, particularly between the three emergency services (police, fire, and health). Seemingly, the main barrier hindering shared situation awareness is the lack of a common platform for sharing information across agencies. As expressed by one par- ticipant, emergency agencies do not have any audiovisual support tools available, and the only means for sharing information across agencies in current practice is through verbal communication, preferably face to face. In addition, there is a lack of resource overview and management (an important component of situation awareness), because devices for sharing information about the position and status of resources are not used in the field. Other barriers highlighted by participants include information overload, prioritiza- tion of information, and obtaining the right information at the right time. Emergency situations develop and change over time, demanding continuous monitoring from emergency response personnel to maintain an up-to-date overview of the situation. One participant explained that getting the right information is an ongoing challenge throughout all phases of an incident, because that information will generally not be available immediately. 3.3 Organizational understanding The results from the workshop also indicate that emergency agencies sometimes lack a sufficient understanding of the responsibilities, needs, plans, and tactics of their own and other participating agencies, which can have a negative impact on collabora- tion. Out of 33 sticky notes describing challenges related to collaboration, 11 con- cerned organizational understanding. One of the barriers to organizational understanding is the lack of knowledge about one's own as well as others' responsibilities during an emergency situation, which can complicate the coordination of an incident. As an example, one participant stated that the Incident Commander often functions more as a police officer than as a command- er for all agencies (which he/she is supposed to be), leading to an inefficient coordina- tion effort focused on police operations. Another relevant barrier is the lack of understanding of other agencies' needs dur- ing an emergency effort. Each of the three emergency agency functions as a separate organization with specific tasks and responsibilities, and participants expressed that the three often have different opinions regarding how a situation should be resolved. Despite that, efficient emergency management and collaboration requires the leaders of those agencies to have a shared understanding of what the other agencies need in order to do their job. A third barrier related to organizational understanding is the lack of congruent planning and common tactics across agencies. In today's practice, emergency agencies have different sets of plans for how to manage a given incident scenario, and unfortu- nately, those plans do not match each other. That can negatively affect the develop- ment of strategies and tactics, resulting in time loss and misunderstandings during an emergency situation. 4 Discussion Efficient collaboration during emergency response in large-scale incidents requires a clear understanding of roles, responsibilities, and tasks among the involved actors; simple sharing of relevant information; and a common and shared understanding of the situation at hand. In this section, we discuss opportunities for technology that can help mitigate the challenges of collaboration during emergency response. 4.1 Mitigating communication challenges between and within agencies The challenges described in Section 3 indicate a clear need for better technology to support intra- and inter-agency communication during emergency response. One ap- proach could be to supplement verbal communication with electronic messaging tools. Those would have the potential to reduce not only the need for verbal commu- nication, but also the risk of information overload, because a message would be di- rected only to the person or persons the user specifies rather than blasted to everyone. Another, more advanced option is to use artificially intelligent tools (e.g., software agents) to automatically handle parts of the coordination required during an emergen- cy situation. For example, wearable sensors and smart devices could collect infor- mation about the status and environmental conditions of field responders and then send that information on to software agents. The agents could then compare that in- formation to the parameters of different tasks that agency leaders are trying to coordi- nate, highlighting those personnel and teams best-suited to a given task. Along the lines of the latter option, the Resource Manager, currently under devel- opment in the BRIDGE project, aims to support automatic allocation of personnel and equipment during large-scale incidents. Based on the position, capabilities, environ- ment, and status of available resources, the Resource Manager will be capable of de- termining which resources are best-suited to handle a given task. The selected re- sources (or the personnel in charge of them) will then be notified of the assignment automatically on a handheld device, which they must confirm or decline. Notifica- tions of confirmation or decline are sent back to the commander who issued the re- quest. Finally, one of the key challenges in communicating during emergency manage- ment is that the network capacity is limited and easily overwhelmed. That is a crucial resource for sharing information between emergency personnel. To reduce the need for high-bandwidth networks, the amount of information that responders must trans- mit should be reduced. That could be done by moving processing power out to the sensors, letting them do the main analyses and transmitting just the results. That will also reduce the need for bandwidth so that potentially also the TETRA-based com- munication infrastructure used in several European countries could be used to ex- change the most critical information when necessary 4.2 Mitigating the challenges of shared situation awareness The lack of a shared situation awareness is inherently linked with the lack of effi- cient communication during emergency response, and hence could also benefit from the technical solutions described in Section 4.1. Still, there is always a limitation with respect to how much information one person has time to communicate to another. To bridge that problem, we see an opportunity for the use of sensors, smart devices, and intelligent agents that unobtrusively collect relevant data and broadcast it to a central repository, where it is accessible by those in need of that information. A concept cur- rently under development in the BRIDGE project, called the Master, aims to realize that idea by providing a common operational picture that supports the three levels of situational awareness proposed by Endsley [3]: (1) “Perception of the elements in the environment”; (2) “comprehension of the current situation”; and (3) “projection of future status”. To achieve an up-to-date operational picture, the Master draws infor- mation from sensors and smart devices that track the position and status of resources, victims, and triaged patients. The operational picture can be accessed on any kind of device (e.g. pc, surface tables, tablets, mobile phones), and allows each user to filter out the information he/she needs. Unlike other available software with similar capa- bilities, the Master enables sharing of information across all involved parties, making heavy use of sensors that are deployed directly in the field or attached to the equip- ment and clothing of emergency response personnel and victims. 4.3 Mitigating the challenges of organizational understanding In contrast to the challenges addressed in Section 4.1 and 4.2, the challenges of organizational understanding are not necessarily solvable by new and better technolo- gy. Instead, we see a clear need for better training and education, giving the first re- sponders a clear understanding of the responsibilities, tasks, and roles of not only their own agency, but of all the three main emergency agencies. 5 Conclusion The results of this workshop revealed three key challenges in emergency response that, at least in Norway, create problems for multi-agency collaboration: (1) efficient communication between participating actors, (2) establishing and maintaining a shared situation awareness, and (3) achieving organizational understanding. The first and second challenges both deal with information exchange in different ways, raising the likelihood that advancements in ambient intelligence can mitigate them – in par- ticular, the interplay between wearable sensors and smart devices and intelligent software agents. The third is more of an educational issue, however, and not easily addressed through ambient intelligence technologies. Acknowledgements. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n°261817, the BRIDGE project (www.bridgeproject.eu) within the Securi- ty Programme SEC-2010.4.2-1: Interoperability of data, systems, tools and equip- ment. We also owe our gratitude to the participants that took part in the workshop. Without them, the research reported in this paper would have been impossible. References 1. Beyer, H., & Holtzblatt, K. (1997). Contextual design: defining customer- centered systems. Morgan Kaufmann. 2. BRIDGE, FP7-SEC-2010-1 261817, SEC-2010.4.2-1: Interoperability of data, systems, tools and equipment. Online: http://www.bridgeproject.eu/en/about-bridge, Accessed 25/10/2012. 3. Endsley, M. R. "Designing for situation awareness in complex systems."Proceedings of the Second International Workshop on symbiosis of humans, artifacts and environment. 2001. 4. Følstad, A., & Hornbæk, K. (2010). Work-domain knowledge in usability evalua- tion: Experiences with Cooperative Usability Testing. Journal of Systems and Software, 83(11), 2019-2030. 5. Lazar, J., Feng, J. H., & Hochheiser, H. (2010). Research methods in human- computer interaction. Wiley. 6. Mendonça, D., Jefferson, T., & Harrald, J. (2007). Collaborative adhocracies and mix-and-match technologies in emergency management. Communications of the ACM, 50(3), 44-49. 7. Mulder, I., & Stappers, P. J. (2009). Co-creating in practice: results and challeng- es. In Collaborative Innovation: Emerging Technologies, Environments and Communities (Proceedings of the 15th International Conference on Concurrent Enterprising: ICE 2009, Leiden, The Netherlands, 22–24 June 2009). Centre for Concurrent Enterprise: Nottingham, UK. 8. Norges offentlige utredninger (2012) NOU 2012: 14: Rapport fra 22. juli-kommisjonen online: http://www.regjeringen.no/nb/dep/smk/dok/nou-er/2012/nou-2012- 14.html?id=697260, Accessed 25/10/2012. 9. Salas, E., Cooke, N. J., & Rosen, M. A. (2008). On teams, teamwork, and team performance: Discoveries and developments. Human Factors: The Journal of the Human Factors and Ergonomics Society, 50(3), 540-547. The MIRROR AppSphere: the case of crisis management Simone Mora1, Simon Schwantzer2, Monica Divitini1 1 Dept. of Information and Computer Science, NTNU, Trondheim, Norway {divitini, simonem}@idi.ntnu.no 2 IMC information multimedia communication AG, Germany Simon Schwantzer Abstract. In this paper we focus on learning from experience in crisis manage- ment and how it can be supported with mobile applications. The proposed ap- proach focuses on the adoption of multiple lightweight applications (1) to collect data during an event, and (2) revisit the data to reconstruct the event and reflect on it, enriching current practices of debriefing. The paper briefly presents three applications that we have developed, a demonstration scenario, and the technical infrastructure that supports data exchange. With the paper we aim at opening a discussion about the role of simple dedicated Apps in crisis management, the re- quirements that they pose in terms of interoperability, and the challenges con- nected to an approach to crisis management that is holistic in perspective, but based on a necessarily fragmented support. 1 Introduction Training in crisis management is challenging and has to take into account the need to learn specific skills, e.g. how to operate specific tools, as well as soft skills, e.g. ap- propriate communication styles and coping strategies (Sagun et al 2008). Challenges are connected not only to the complexity of the work to be performed, but also to its sporadic and discontinuous nature. Approaches to promote learning for crisis workers and volunteers include traditional training, coaching, simulated emergencies (Roberts and Lajtha 2002), serious games (Di Loreto et al 2012), and structured debriefings to reflect on and learn from specific work experiences. Learning from experience is critical because crises are rare events and it is important to learn from each single occurrence. Despite protocols are carefully designed each event is highly situated and might lead to unexpected situations. Learning from expe- rience can help workers, and their organizations, to improve their crisis preparedness and learn how to perform better in the future. In our research we focus on how mobile and ambient technology can be used to sup- port learning from experience, with focus on reflection on action. Reflection can be seen as a re-visiting and re-evaluation of experience, involving a return to previous experience with explicit attention to ideas, behaviour, and emotions (Boud et al. 1985). Debriefing sessions, with workers gathering together after real or simulated events, are an example of reflection on action. To be useful, they need to be fed with information useful to trigger learning. This is challenging because crisis work is high- ly distributed (in time, space, competencies, roles, ...) and it is therefore difficult to capture the relevant data, accounting for multiple perspectives, and making sense of it. Also, focus is often on organizational level, neglecting citizens and workers on the field, while giving them voice might lead to important lessons learned. Technologies can support reflection on action in different ways (Krogstie et al. 2012). In this paper, we present three applications: WATCHiT, CroMAR, and TimeLine. Together they can be used (1) to collect data during an event, and (2) to revisit the data to reconstruct the event and reflect on it, enriching current practices of debrief- ing. In the paper, after the presentation of the application, we outline a demonstration sce- nario showing how these applications can be used to support different levels of reflec- tion and promote integration between different steps of crisis management. The tech- nical infrastructure supporting data exchange is also introduced. 2 Apps for supporting reflection The scenario includes three main applications: WATCHiT, CroMAR, and TimeLine. WATCHiT (Cernea, Mora et al 2012) is a wearable computer (Figure 1a) sewn in a wristband to be worn under the work uniform (Figure 1b). WATCHiT allows emer- gency workers to capture information while being on the field and without interrupt- ing the rescue work. Data captured can include information from the individual, for example stress levels, moods and personal notes; and information sensed from the environment like temperature, gas or radioactive exhalations. WATCHiT has a strong focus on a modular design therefore the set of information captured can be defined beforehand by plugging-in specific sensor modules to the main board (Figure 1c). Moreover each piece of information captured embeds its own GPS coordinates and timestamp of creation to allow locating the information in time and space. The user interaction exploits gestures and haptic feedbacks to allow the worker to send infor- mation without interrupting the rescue operation, as well as getting notifications from the system using distraction-free tactile feedbacks on the user’s wrist. The hardware is based on Arduino1 and open-source hardware. 1 www.arduino.cc 2 http://www.apple.com/ios/facetime/ 3 http://www.dopanic.com/solutions/panic_ar.html a b c Figure 1: Prototype of W. (a), W. worn on the worker’s wrist (b), a W. module for location sensing (c) CroMAR (Mora et al. 2012) is a mobile augmented reality iPad App to support viewing and navigating across information (e.g. social media, radio communication, WATCHiT data, photo and video feeds) generated during a crisis, directly on site. The information is intended to support debriefing and reflection for civil protection workers who are deployed on the field. CroMAR allows for navigating information along the space, time and keyword dimensions using both augmented reality and map- based visualizations (Figure 2). In this way we can expect the reflection process to be grounded in a context that helps to make sense of the information and reflect on alter- native path of actions. Because debriefings and reflection are a collaborative activities CroMAR allows synchronous collaboration via FaceTime 2 videoconferencing and asynchronous collaboration via an recommendations text editor and a email sharing of the set of information the user is looking at. CroMAR is implemented in a prototype for iOS tablet devices and powered by the PanicAR framework3. The source code is available open source (https://github.com/ubiAle/CroMAR ). a b Figure 2: Augmented Reality (a) and Map (b) visualizations in CroMAR 2 http://www.apple.com/ios/facetime/ 3 http://www.dopanic.com/solutions/panic_ar.html TimeLine (Kristiansen et al. 2012) is a mobile application to support reflective learning through timelines. The application, running on Android devices, allows users to capture traces of working and learning experiences in a timeline with the aim to provide data that can be used to promote reflection. The application supports captur- ing of different types of information, ideas, behavior, and emotions (Figure 3). By using the notion of timelines, the application provides a way to organize and visualize the information. The visualization on a timeline provides a temporal contextualiza- tion, and any piece of information is presented together with other relevant infor- mation that users might have decided to collect, shedding light on different aspects of an event. Furthermore the application provides the possibility to build shared time- lines, capturing in a coherent representation different perspectives of an event and supporting people in comparing their input with the ones of other group members. Timeline is available free of charge on the Android Market, code is released open source4. 9LHZDOOFRQWHQWLQWLPHOLQH $OO\RXUFRQWHQWZLOOVKRZLQ\RXUWLPHOLQHDWWKHWLPH RIFUHDWLRQ Figure 3: The timeline user interface and main annotation types 3 Demonstration scenario The following scenario is based on user studies with the Italian Civil Protection and has been validated with field experts. A simulation of the scenario is documented in a video available at http://youtu.be/8RU50Lih72M. Context A major flood is causing serious disruption and material damages at SomeTown. With the worsening of the weather conditions, also the population is at risk and there are a number of missing persons. 4 https://github.com/andekr/Timeline-App Step 1 – work (set-up, during crisis) Giacomo works as a volunteer in a unit with search dogs and they have been called in to help with searching missing persons. His coordinator, Mirco, decided to provide all the members of his team with WATCHiT, configured to collect but not share the heart rate; collect and send to the coordination team the location a person has been found; visualize messages from the coordination team. Step 2 – work (during crisis) The data that Giacomo (volunteer) collects in the field through WATCHiT is sent to the coordination team. Getting updated and reliable information allows them to take at any moment informed decisions. They also use it to send back information to the field (e.g. when an area needs to be evacuated). Step 4 – Individual reflection (situated, after crisis) Mirco (coordinator) is not completely satisfied because he feels that finding some of the missing persons has taken too long. Therefore, after a couple of days he goes back to the area covered by his team and starts a debriefing session with CroMAR. By looking at the information in the system and at the actual territory, he realizes that the searching would have been more effective if he had distributed his team differently. It was difficult to see this at the time, when it was dark, windy, and rainy. Step 5 - Team reflection (not situated, after crisis) Mirco (coordinator) calls his team for a debriefing session. It is impossible to get all of them out where the event took place, so they cannot use CroMAR. They rather meet in their office and use the TimeLine to check their shared timeline of the event. The timeline collects the public input from the WATCHiT devices of all the team, together with pictures and short SMSs that they have posted during the event to take note of interesting issues. During the session, some of the team members decide also to share information that they have collected in their individual timelines. Mirco also shares some of the information he collected in CroMAR. Using their individual per- spectives and comparing them with the data collected in the field, they manage to get a good understanding of their strengths and weaknesses as a team. Step 6 - Organizational reflection (towards preparedness) The disaster manager is checking all the recommendations that they have received from the different reflection sessions conducted by the various teams. It seems that the coordination among different units has not been at its best. Looking at the visuali- zation of the notes in the map, it is also easy to identify one problematic spot. The disaster manager will summarize all the lessons learned into a shared document that collects critical points and can be re-used in future emergencies. 4 The MIRROR technical infrastructure An abstract view on the information flow between WATCHiT, CroMAR, and TimeLine is illustrated in Figure 4. In the described scenario, WATCHiT acts as pure data provider, while TimeLine is a pure data consumer. CroMAR is both: it consumes data provided by WATCHiT and it provides data accessed by the TimeLine. The data exchange between the applications is realized with the MIRROR Interop- erability Framework. The applications send their data to spaces provided by the MIRROR Spaces Service (Schwantzer 2012). When data is sent to a space, all appli- cations registered at the space are notified and the payload is delivered to them in real time. In the scenario, two instances of MIRROR spaces are created: a private space owned by Giacomo, only visible to him through multiple applications, and the “Flood Event” team space, accessible by everybody involved in the operation. Both spaces are configured to be persistent and spaces can be re-configured anytime using a web application, which allows for example to create and destroy spaces or to add new users to an existing space. The data is exchanged over XMPP publish-subscribe nodes, which are managed by the MIRROR Spaces Service and can be accessed by all members of the space. The interaction between users, apps, and spaces is illustrated in Figure 5. Figure 4: Information flow between involved applications Figure 5: Interaction between users, applications, and spaces 5 Discussion and conclusions In the paper we presented the combined use of a set of individual and collaborative lightweight applications to support work and reflection at different levels. We are fully aware that crisis management requires also the usage of more comprehensive organizational tools. At the same time, given the complexity of learning and working in crisis management, an ecological approach might successfully complement existing more traditional solutions. Though an ecological approach might lead to applications that are simpler to use, it is also important to understand how to provide the workers with a meaningful experience of the provided support, avoiding the risk of fragmenta- tion. Acknowledgements The work presented in this paper is co-funded by EU-ICT 7FP MIRROR project (http://www.mirror-project.eu) and NFR-VERDIKT 176841/SIO FABULA (http://research.idi.ntnu.no/teseo/). We acknowledge the help of Gianni Della Valle and Regola in the definition of the scenario. References Boud, D., Keogh, R., & Walker, D. (1985). Reflection: turning experience into learning. Routledge. Cernea, D., S Mora, A Perez, A Ebert, A Kerren, M Divitini, DG de La Iglesia, N. Otero (2012). Tangible and Wearable User Interfaces for Supporting Collaboration among Emer- gency Workers, Proc of CRIWG 2012. pp. 192-199. Di Loreto I., S. Mora, M. Divitini (2012). Collaborative serious games for crisis management: an overview. Proc. 21st International IEEE WETICE 2012. Kristiansen A., Andreas Storlien, Simone Mora, Birgit R. Krogstie, Monica Divitini (2012). Mobile and collaborative timelines for reflection. Proc. of IADIS conference on Mobile Learning 2012, Berlin, Germany. IADIS Press. Krogstie, B., Prilla, M., Knipfer, K., Wessel, D., and Pammer, V. (2012). "Computer support for reflective learning in the workplace: A model. "International Conference on Advanced Learning Technologies (ICALT) 2012. City: ACM: Rome. Mora, S., Boron, A., & Divitini, M. (2012). CroMAR: Mobile Augmented Reality for Support- ing Reflection on Crowd Management. International Journal of Mobile Human Computer Interaction, 4(2), 88–101. doi:10.4018/jmhci.2012040107 Roberts, R. and C. Lajtha (2002). A New Approach to Crisis Management. Journal of Contin- gencies and Crisis Management vol 10 ( 4) 2002 ,pp. 181 – 91 Sagun, A., D., Bouchlaghem, and J.C Anumba (2008). "A Scenario-based Study on Infor- mation Flow and Collaboration Patterns in Disaster Management," Disasters (33:2), August 2008, pp. 214-238. Schwantzer, S., Müller, N., Faltin, N., (2012) D2.2 Software Architecture – version 2, MIRROR deliverable BRIDGE Risk Analyzer: A Collaborative Tool for Enhanced Risk Analysis in Crisis Situations1 Mass Soldal Lund and Atle Refsdal SINTEF ICT, Oslo, Norway {atle.refsdal,mass.s.lund}@sintef.no Abstract. When a crisis occurs, such as a fire in a chemical facility, difficult decisions need to be made based on assessment of risk. Is it safe enough for re- sponders to enter the area? Do we need to evacuate the public from the nearby area? Assessing risks may require information from a number of different sources, as well as collaboration across organizations and management levels. In this paper we present ongoing work to develop a collaborative tool to support risk analysis in crisis situations. The tool will be tightly integrated with a com- plementary tool to make coordinated situation assessments, planning, decision making, information gathering and sharing, thereby providing a unified and in- tegrated crisis management support facility. Keywords: Risk analysis, crisis management 1 Introduction Crisis management is a highly challenging task. Big decisions need to be made based on information from a number of different sources, such as detectors, sensors, by- standers, the public, on-site responders, and external domain experts. Successful crisis management depends on the ability to identify and obtain the relevant information, as well as to process this in a way that provides a good basis for making decisions. A recent example from Norway showed how unavailability of operational information, partly due to poor and outdated ICT solutions, contributed to the escalation of a major crisis [16, pp. 332–334]. These challenges are a major motivation for the BRIDGE project (http://www.bridgeproject.eu). Focusing on large-scale emergency manage- ment and the ubiquity of ICT support, the project aims to facilitate cross-border and cross-agency collaboration, allow the creation of a common, comprehensive, and reliable operational picture of the incident site, enable integration of resources and technologies into workflow management, and enable active ad-hoc participation of third parties. 1 The work on which this paper reports has been funded by the European Commission through the projects BRIDGE (Contract no. 261817) and NESSoS (Contract no. 256980). We are grateful for the feedback we got from experts during workshops and demonstrations. Risk analysis is an essential prerequisite for decision making. Ensuring that the dif- ferent actors involved in the crisis management and response have a shared under- standing of the relevant risks is an important contribution to establishing shared situa- tion awareness and a common operational picture. In this paper we present ongoing work to develop a collaborative tool to support risk analysis in crisis situations, called the BRIDGE Risk Analyzer (BRA). The BRA will be closely coupled with a tool, called the BRIDGE Master [1], for supporting coordinated situation assessments, planning, decision making, information gathering and sharing. The Master provides, among other things, functionality for visualization and management of all collected information and available resources during an incident and integration with hand held devices to be used in the field. Together, the BRA and the Master will contribute to a unified and integrated crisis management support facility. In this paper we present the method used for researching and developing the BRA as well as our current results and findings. The paper is structured as follows: In Sect. 2 we present the general research and development method used. A description of how this method has been instantiated in the first and second iteration is given in Sect. 3 and Sect. 4. In Sect. 5 we present related work, before concluding in Sect. 6. 2 Method As research and development method we adopt an approach to technology research provided in [21]. The approach is focused on development of new and better artifacts and prescribes an iterative process of three phases. The first phase – problem analysis – is concerned with identifying the needs for new and better artifacts. This should preferably be done in interaction with potential users and other stakeholders. In the second phase – innovation – the goal is to con- struct an artifact that satisfies the identified needs. The third and final phase – evalua- tion – is an investigation into whether or not the artifact actually satisfies the needs. In order to do this investigation, hypotheses and predictions concerning the artifact must be formulated based on the needs. Then these must be tested using a selection of es- tablished research strategies. (For an overview of research strategies, see [13, pp. 31– 34]; the research strategy chosen for the early iterations in the research and develop- ment of the BRA can be classified as judgment studies.) 3 First Iteration Based on Paper Prototype For the initial iterations we chose to use a lightweight instantiation of the method. The goal was to quickly reach a point where we had something concrete that could be presented to experts in the crisis management domain. This approach would ensure that we would receive feedback and corrections for bad ideas at an early stage. 3.1 Problem Analysis: Literature and Discussions Our initial problem analysis was carried out as an informal process where we acquired knowledge about the crisis management domain in general and risk analysis during crisis situations in particular mainly through literature, brainstorming and discussions. Typical resources that we drew upon included literature and investigation reports such as [5,17,19]. Moreover, we obtained domain knowledge through the Emergency pro- ject (http://heim.ifi.uio.no/~ketils/emergency/the-emergency-project.htm) which aims to improve decision support in emergency situations. Finally, we drew upon our gen- eral knowledge about risk analysis. The above process allowed us to establish the following initial set of requirements for a tool, targeted toward the incident command level, to support risk analysis in situations where the decision frame is longer than a few minutes: R1: Be simple and intuitive to use. R2: Support identification and assessment of potential risks toward the safety of responders or the public, infrastructure, the environment, or other assets. R3: Facilitate exploitation of preparatory risk analyses performed before the crisis. R4: Support editing/updating of risk models during the crisis. R5: Support geograph- ical location of risks. R6: Support identification of information that is typically need- ed to assess risks. R7: Facilitate participation of actors, such as domain experts, not present at the incident site in the analysis. 3.2 Innovation: Paper Prototype Following the strategy of a lightweight approach to the first iteration, the first artifact was developed as a paper prototype [20] of an application to be deployed on an inter- active multi-user touch table. Paper prototypes can be developed with little resources, while still providing a good basis for discussions and feedback. Fig. 1 shows a picture of a part of the paper prototype. Although it aimed to fulfill all the requirements above, space restrictions mean that we must limit ourselves to explain some of the central aspects. Fig. 1. Paper prototype of the BRA demonstrated at the evaluation workshop We chose to use graphical risk models expressed in a simplified version of the CORAS language [12]. The CORAS language was developed in order to be easily understood, and from other domains we have positive experiences with using CORAS models during risk analysis sessions involving actors from very different back- grounds. Moreover, we believe that graphical models are well suited for use with a touch interface. The functionality includes interacting with the model and sending information request to external experts. Table 1. Evaluation of predictions P1.1 The Oslo participants found the tool useful for the command center, but want- ed simpler support for the incident command. This was modified after we ex- plained that a library of predefined risk models would be used, so that risk models need not be built from scratch during the crisis. One participant seemed to disagree that the tool was too complicated for the incident com- mand. Still, our overall impression was that a simpler tool is wanted for the incident command level, so P1.1 was not confirmed. Interestingly, the Lancas- ter participants found the models too simple to be used by scientific or tech- nical advisors, but suitable for local authorities and police, and possibly also for informing the press and the public. P1.2 As far as we could observe, all participants quickly grasped the meaning of the models. They did not ask questions that indicated misunderstandings or in- comprehension. We therefore consider that P1.2 was confirmed. P1.3 The functionality for requesting support from external experts was only briefly explained due to time restrictions. It did not raise further discussion or com- ment from the participants. Our impression is that this was seen as a useful feature, but a clear evaluation of P1.3 could not be made at that point. P1.4 A need for a list of risk treatment options that is related to different risk levels, so that different options are proposed depending on the risk level was suggest- ed. This means that P1.4 was falsified. P1.5 Apart from the comments described in the evaluation of P1.1, the participants' feedback did not indicate that any of the features were unsuitable or redundant. 3.3 Evaluation: Workshop The paper prototype was evaluated primarily through workshops organized by BRIDGE [1] in Oslo 29/9-2011 and in Lancaster 16/4-20122. The workshops included interactive sessions where the paper prototype was presented to experts from the cri- sis/emergency domain and the experts were asked questions and encouraged to give their feedback. Three experts participated in this session in the Oslo workshop, while two experts participated in the Lancaster workshop. Although not explicitly formulat- ed as such prior to the workshops, our underlying hypothesis (H), and the predictions 2 BRIDGE also organized a similar workshop in Delft 6/12-2011. However, in this workshop we presented a version of the BRA for mobile devices, so this is less relevant for this paper. (P) derived from the hypotheses, can be captured as follows: H: The tool adequately supports the incident commanders and their assistants w.r.t. risk analysis during large- scale crisis management. P1.1: The workshop participants will consider the BRA easy to use for incident commanders and their assistants. P1.2: The workshop participants will easily understand the graphical risk model. P1.3: The workshop participants will find the possibility to requesting support from external experts to be useful. P1.4: The workshop participants will not identify additional features that they consider neces- sary. P1.5: The workshop participants will not consider any of the presented features redundant or unsuitable. Table 1 summarizes our evaluation of the predictions based on an informal analysis of notes and video recordings of the workshops. We can of course only draw prelimi- nary conclusions to be followed up by more systematic investigations later. 4 Second Iteration Based on Executable Prototype In the second iteration we focused on building an executable prototype, but still doing fairly lightweight evaluation. The goal was to present something that resembles the final artifact to get feedback on design decisions at an early development stage. 4.1 Problem Analysis: Refinement Based on Workshops and Interaction The second problem analysis was primarily based on the evaluation from the first iteration. Perhaps the most fundamental feedback was the considerations regarding the target group. Workshop participants had expressed doubt as to whether the tool was simple enough for use by the incident command, but they had also stated that it would be useful for the command center, and that it could help making better assess- ments. This, together with the fact that a command center will typically be more in- volved in a large emergency than the smaller incidents, and that BRIDGE is con- cerned with large-scale emergencies, led us to change the target group for the tool to include the command center, rather than to discard the design. This means that we added the requirement that it should be possible to use the tool cooperatively both at the command center and the incident command. We envision that the command center personnel will typically do most of the actual tailoring and editing of risk models during the crisis, while the incident command will be able to see the results and make adjustments as they see fit. This harmonizes well with the idea that the higher com- mand levels should provide support for the on-site responders. However, the tool itself should not place strong restrictions on how the work is divided between the levels, as feedback from the workshops indicates that the level of sophistication of support tools used by the incident command level can vary greatly. We plan to devel- op a simpler version for mobile devices later, but this is beyond the scope of this pa- per. The evaluation after the first iteration also led to the inclusion of a requirement based on the proposal described under the evaluation of P1.4. Hence, the list of re- quirements from Sect. 3.1 is extended with the following: R8: Facilitate collaborative use of the tool at the command center and the incident command. R9: Support identi- fication of proposed risk treatments that depend on estimated risk level. 4.2 Innovation: Executable Prototype The executable prototype of the BRA is developed as a Microsoft PixelSense (http://www.pixelsense.com) application for the Samsung SUR40. Samsung SUR40 is a computer built as a table with the table top made up by a 40'' multi-touch screen. Fig. 2 shows the prototype BRA deployed on the touch screen table. In addition to functionality for creating and editing simplified CORAS diagrams, the prototype also connects to middleware developed in the BRIDGE project. Through this middleware it exchanges messages with the Dynamic Expertise Integration Network (DEIN) [18], a system for communicating with off-site experts as part of the crisis management. In summary we can say that the development of the executable prototype during the second iteration focused on the fulfillment of requirements R1, R2, R4 and R7 de- fined in Sect. 3.1, while requirements R3, R5 and R6, as well as requirements R8 and R9 defined in Sect. 4.1 were postponed to later iterations. Fig. 2. Executable prototype of the BRA deployed on a Samsung SUR40 table 4.3 Evaluation: Demonstration For the second evaluation of the BRA, the prototype was featured as one of several tools in a project wide demonstration of BRIDGE, held in VersuchStollen Hagerbach (http://hagerbach.ch ) in September 2012. The BRA was used to review risks of esca- lation of a crisis and to send risk specific requests for information through the DEIN system. At the time of writing, we are still waiting for the participants' feedback. The overall hypothesis H from the first evaluation remains the same, except that we included command center personnel in the target group. Due to the different na- ture and focus of the second evaluation, new predictions were formulated to fit the particularities of the demonstration: P2.1: The domain experts consider the use of risk models in the BRA as a useful tool for use at the command center and the incident command. P2.2: The domain experts consider sending requests for information to DEIN from BRA a useful feature to support the risk analysis. P2.3: The domain ex- perts do not consider any of the demonstrated features of the BRA redundant or un- suitable. 5 Related Work The study of the effectiveness of visual or graphical communication of uncertainty and risk goes back a couple of decades, though according to a survey from 1999 [11], studies testing visual aids in risk communication until that point in time were few. In one of the first studies [8] a group of non-technical was people subjected to a number of graphical means for visualizing uncertainty. This study showed that how uncertain- ty is presented by graphical means is relevant for how it is perceived. A study of communication of health risks [3] found that the respondents preferred a presentation combining a short text and an illustration over a longer piece of text. The 1999 survey [11]concludes that the evidence available in 1999 points in the direction that visual aids are useful for communicating risk, but that the tasks of the reader (the purpose of the communication) always must be considered when choosing what aids to apply. Research on the CORAS language [6,7] indicates that a simple iconography com- bined with text labels is effective in communication of risk, and thus points in the same direction as earlier research. In [2] a risk model, expressed in the CORAS language, for forest fires is developed based on a process similar to risk and emergency preparedness assessment in the off- shore industry [15]. The model is parameterized by influence factors such as the di- rection and speed of the wind and the quality of the wood. In [4] an interactive map- based tool capable of visualizing risk is presented. This tool has inspired certain as- pects of the BRA. There exist a number of computerized support tools for incident management, such as Essential Incident [9], opsIncident [10] and E Team [14]. They all provide support for information collection and, to varying degree, risk analysis. However, we are not aware of any tool that uses graphical risk models to be viewed and updated on a mul- ti-user interactive touch table in a way similar to the BRA. 6 Conclusions and Future Work Focusing on the method of research and development as well as the results, we have presented ongoing work to develop a collaborative tool to support risk analysis in crisis situations. Our goal is to provide, in conjunction with the BRIDGE Master, a unified and integrated crisis management support facility. Although results so far are promising, a number of issues still need to be addressed in later iterations. The next step in the research and development process is obviously to evaluate the outcome of the demonstration described in Sect. 4.3, before initiating a new iteration of the process. In the problem analysis step of this third iteration the evaluation of the demonstration will be used to revise the list of requirements. The innovation step will focus on further development of the executable prototype to support the requirements not addressed so far. Requirements R5 and R6 will be supported by integrating with the BRIDGE Master and thus making its features and information available to the BRA. Requirements R3 and R8 will be supported by a risk model repository to hold preparatory risk models as well as risk models shared among several instances of the BRA. Requirement R9 will be supported by automated reasoning based on the infor- mation provided to the BRA and conditions specified in the preparatory risk models. The evaluation of the third iteration will be a second demonstration where the focus will be on the user interfaces of the BRIDGE system. References 1. BRIDGE Newsletter, no. 2 (2012) 2. Brændeland, G.: Forberedende beslutningsrisikoanalyse for håndtering av skogbrann i El- verum kommune. Technical report A17367, SINTEF ICT (2011) [In Norwegian] 3. Connelly, A.N., Knuth, B.A.: Evaluating risk communication: Examining target audience perception about four presentation formats for fish consumption health advisory infor- mation. Risk Anal. 18(5), 649–659 (1998) 4. Eide, A.W., Stølen, K.: Geographic visualization of risk as decision support in emergency situations. In: 5th International Conference on Human System Interaction (HSI'12) (2012) 5. Flin, R.., Arbuthnot, K. (eds.): Incident Command: Tales from the Hot Seat. Ashgate Pub- lishing Company (2002) [Reprinted 2008] 6. Grøndahl, I.H., Lund, M.S., Stølen, K.: Reducing the Effort to Comprehend Risk Models: Text Labels Are Often Preferred Over Graphical Means. Risk Anal. 31(11), 1813–1831 (2011) 7. Hogganvik, I., Stølen K.: A graphical approach to risk identification, motivated by empiri- cal investigations. In: 9th International Conference on Model Driven Engineering Lan- guages and Systems (MoDELS’06). Lecture Notes in Computer Science, vol. 4199, pp. 574–588. Springer (2006) 8. Ibrekk, H., Morgan, G.: Graphical communication of uncertain quantities to nontechnical people. Risk Anal. 7(4), 519–529 (1987) 9. IHS. Essential Incident. Flyer (2010) 10. IHS. opsIncident. Flyer 11. Lipkus, M.I., Hollands, J.G.: The visual communication of risk. J Natl Cancer Inst Monogr. 25, 149–163 (1999) 12. Lund, M.S., Solhaug, B., Stølen, K.: Model-driven risk analysis. The CORAS approach. Springer (2011) 13. McGarth, J.E.: Groups: interaction and performance. Prentice-Hall (1984) 14. NC4. E Team. Flyer (2011) 15. NORSOK Standard Z-013: Risk and emergency preparedness assessment. Edition 3 (2010) 16. NOU 2012:14: Rapport fra 22. juli-kommisjonen (2012) [In Norwegian] 17. NOU 2001:9: Lillestrøm-ulykken 5. april 2000 (2001) [In Norwegian] 18. Pavlin, G.: Dynamic Expertise Integration Network (DEIN): User Manual (Draft), Version 0.6. Thales Research and Technology 19. Rake, E.L.: Crisis Management. Coping and decision making on-scene. Ph.D. thesis, Uni- versity of Stavanger (2008) 20. Snyder, C.: Paper prototyping. IBM developerWorks (2001) 21. Solheim, I., Stølen, K.:Technology research explained. Technical report A313, SINTEF ICT (2007) Tactical Information Visualization for Operation Managers in Mass Casualty Incidents Mathias Wilhelm, Eva Burneleit, Sahin Albayrak DAI-Labor/TU-Berlin, Ernst-Reuter-Platz 7, 10587 Berlin, Germany {firstname.lastname}@dai-labor.de Abstract. In mass casualty incidents, operation managers have to make deci- sions under highly stressful conditions. At present, the tactical information is mostly written down on paper-based worksheets, which are inconvenient to use. As a result, the operation managers tend to avoid the paper sheets and try to re- member information which is error-prone. To overcome this issue, this paper presents an IT-supported tactical worksheet for touch devices. It describes a us- er-centered approach that gathers the requirements on the proposed worksheet from a comprehensive long term expert panel with three senior fire brigade of- ficers, two of their assistants, three researchers, and one designer. To validate the specified requirements, a first prototype was implemented and pre-evaluated in a real mass casualty incident simulation with 20 casualties. The evaluation revealed further design and implementation aspects to be considered in future work. Keywords: tactical worksheet, tactical decision making, tactical information visualization, mass casualty incidents 1 Introduction In a mass casualty incident (MCI), operation managers are confronted with a great amount of information, which they have to process in order to make tactical decisions. Despite modern technologies, the information is still gathered by the on-site staff and communicated via radio, and by paper. In order to store and to structure all infor- mation, a so called tactical worksheet (TWS) is used. Interviews with senior fire bri- gade officers performed in context of this paper revealed that paper-based TWSs are stationary and inflexible due to their size (DIN/ISO A3 and larger). Additionally, more than one sheet is necessary because the operational information is dynamic and changes during the operation. Consequently, the information of the current worksheet has to be transferred to an additional one or, alternatively, it must be switched be- tween the current TWS and the previous ones. Due to this overhead and discomfort, operation managers tend to avoid paper-based TWSs and manage all information in their mind. Interviewed senior fire brigade officers stated that because of the high stress, huge amount of information and long operational duration, they can lose con- trol of the information management or even forget important information. In extreme case, this issue can cost life. Addressing these issues, this paper proposes an electronic version of a TWS which is gathering and managing operational information in real time to support the opera- tion manager in his decision making. The TWS was developed within the ALARM1 project [7] aiming to develop modular IT-solutions which support emergency medical service providers and rescue staff in mass casualty incident response and training. In fact, the ALARM solution contains a ubiquitous computing infrastructure providing, for example, RFID tags in order to record information of casualties, handheld devices for the rescue stuff, cameras, mobile tablet computers and a robust AD-HOC network supporting seamless WLAN, GPRS, and satellite communication. This infrastructure allows a broad collection of operation information seeming appropriate for the pro- posed TWS. In the following section, the paper gives an overview of the state of the art in which this work is motivated. In section 3, it describes the user-centered design pro- cess and the requirements gathered from the expert panels and interviews with senior officers and their assistants of the Berlin fire brigade. Based on the collected require- ments, the TWS solution is described in section 4, which is presenting software de- velopment aspects in general as well as the user interface and the interaction design aspects. In section 5, the implementation of a first prototype and in section 6, its pre- evaluation is briefly described. The paper ends with a conclusion in section 7, in which the approach is discussed and an outlook presenting planned future work. 2 Related Work To overcome the disadvantages of paper-based worksheets and to give operation managers support in an MCI, there exist different approaches. In the following, se- lected approaches will be presented and briefly discussed. In [2], a multi-touch table solution supporting natural and intuitive interaction for the command and staff position is presented. This solution gives an overview about the current situation by visualizing the number and the location of casualties as well as of available rescue resources on a map. It is designed primarily for the leading medical doctor and it supports no input in order to send orders to the rescue resources. A generalized support system for rescue staff is presented in [3]. The advantage of this system is that it can be connected with nearly any existing database, because it applies a semantic description for the data input. The focus of this project is more on generalized information and data visualization and less on supporting communication, e.g. for giving commissions to the rescue resources. A triage system providing infor- mation of the casualties for large displays and handheld devices is presented in [8, 1]. A design methodology for interactive emergency management systems is presented in [5]. This methodology is applied on a task management system including a backend, decision and planning support, and a user interface for mobile devices. In [6], a design guideline for mobile checklist applications as well as a prototype imple- 1 ALARM: Adaptive Lösungsplattform zur Aktiven technischen Unterstützung beim Retten von Menschenleben (in English: Adaptive solution platform to the active technical support in saving life) mentation is presented. The guideline is focused on the different organization (e.g. police or fire brigade) involved in MCIs. It provides different features such as execu- tion monitoring and logging. All presented approaches support the decision process of the operation manager, but none of them accompanies the operation manager from the beginning to the end of the operation. Further, no approach discovers the whole spectrum of an operation. This is the starting point of the research of this paper. 3 Methodology In order to develop a TWS tailor-made meeting the requirements of an operation manager, a user-centered design approach was applied. This approach is oriented mainly on the software requirement analysis and design process proposed in [4]. It consists of four stages (noted below) and was performed with three senior fire brigade officers and two of their assistants representing the stakeholders. The whole design process was guided and performed by two researchers and one designer from the in- stitute of the authors. In the following, the different stages are listed in detail: 1. Requirement Process: At first, the relevant roles including their connection and the workflow of an MCI were determined by open interviews. The interviews were performed separately with each of the stakeholders and followed a formless struc- ture. The stakeholders were asked to explain the whole workflow of an MCI. In this process, the interviewer made notes and asked questions in between. All de- termined roles were covered by the stakeholders. 2. Requirement Elicitation: This elicitation of the requirements of the stakeholders consisted of a combination of an open interview and scenarios. These scenarios were oriented on the gathered workflow in stage one. In this process, each stake- holder simulated a complete MCI workflow based on different paper-based TWSs investigated from different free available internet sources 2. 3. Requirement Analysis: Based on the information gathered in stage two, the rele- vant requirements were identified, structured and documented. Afterwards, a wireframe study was performed and discussed with the stakeholders in order to create the interaction concept and to model the cooperative workflow. Finally, mockups serving as design templates for the prototype implementation were creat- ed and discussed. 4. Requirement Validation: In order to validate whether the conceptual design meets the requirements of the stakeholders, a first prototype was implemented and evaluated in a small real simulated MCI with 20 casualties. During the whole simu- 2 Tactical worksheet examples which were applied for the scenario with the stakeholders: http://www.idf.nrw.de/service/downloads/downloads_hilfsmittel.php (accessed on 2012/08/22) http://www.orgl-pm.de/Taktisches_Arbeitsblatt_MANV_PM.pdf (accessed on 2012/08/22) http://snuconline.com/SNUC_Online.com/Tactical_Worksheets (accessed on 2012/08/22) http://www.srpmic-nsn.gov/government/fire/sog.asp (accessed on 2012/08/22) lation, the stakeholders working with a TWS prototype were observed and, after- wards, interviewed regarding the usage of the TWS. The gathered information was used to step back to stage three in order to perform the requirement analysis again based on this new information. The information gathering process and the requirement analysis proved to be very time consuming. The following statement of a fire brigade officer highlights the diffi- culty of the requirement analysis: “99% of the decisions are decisions from the gut and only 1% is based on tactical information.” This means, that only few decisions are based on tactical information such as weather forecast, geographical peculiarities, or casualties and resources statistics, but these decisions can cost life. The main chal- lenge was to identify exactly these requirements for the TWS in order to provide the right information at the right time. 4 Requirements In the following, the identified requirements are listed and discussed: Domain knowledge:  Up-to-date overview of all casualties: Based on the casualty statistic, the operation managers plan the operation and manage the rescue resources.  Up-to-date overview of available resources: Operation managers must be aware of the available resources at the operation. In particular, they must ensure that enough resources are available to transport the casualties to hospitals. Another aspect at a long-term MCI is that the operation managers are responsible for the crew. There- fore, they need to know the total number of resource staff involved in the MCI. These aspects imply that it must be recognizable which resources are still ap- proaching and which already arrived at the operation location (and where they are).  Map: Based on a map, operation manager can plan the operational structure, e.g. where the treatment area should be created.  Operational areas: It should be possible to create the operational structure with the TWS. Further, it should be possible to assign a leader and resources to operational areas as well as to provide the visualization of their position and area on the map.  Dangers: The dangers should be illustrated on the map including detailed infor- mation about the dangers.  Weather forecast: Based on the weather forecast, operation managers plan the op- erational structure. For instance in case of a fire, they must mind the forecast wind direction in order to know the direction of the smoke. Needs:  Tasks and Requests: In order to keep the operation manager aware of the given tasks and received requests from the subunits, the whole task and request handling should be covered by the TWS and it should keep track of the task status.  To make notes and sketches: One expressed request was the possibility of making notes via voice, stylus input or picture snapshots in order to document the opera- tion, to send the rescue coordination center additional information/impressions of the operation, or to add some important notes.  Remember/alarm functionality: Caused by the high impact of stress, operation managers tend to forget the time. This issue can lead to forgetting periodic occur- ring tasks (such as giving a situation report to the rescue coordination center) or frequent checks of the state of given assignments/requests.  Documentation: At present, no reversion-save documentation system has been found recording the decisions of the operation manager and the overall operation progress. Such documentation is very useful for the review and the post-analysis of the operation as well as for the training of rescue staff. Furthermore, it could be useful for the operation manager to clarify the operational decisions in case of any legal actions.  Checklists: The importance of checklists was noted in nearly all interviews within the first and the second stage of the design process. A checklist should contain fre- quently occurring tasks at each MCI such as to wear a signal vest signing to be the operation manager, to create a treatment place, or to give the situation report to the rescue coordination center. In order to create one, some example checklists from the fire brigade were received. All fire brigade officers disliked the checklists in the wireframe concept. It was recognized that they have not to be reminded of eve- ryday business duties. However, it was discovered that they need to be reminded of periodic tasks such as to give a situation report to the rescue coordination center. Design aspects:  Strict hierarchal chain of commands: The TWS must not violate the strict hierar- chal chain of commands. For instance, a sub-operational unit leader should not be able to send a request for additional resources (e.g. for transporting casualties to the hospitals) to the rescue coordination center.  Simple to use: MCIs as well as their simulations occur very rarely. Thus, it can happen that operation managers have no contact with the TWS for month or even years. Consequently, all user interfaces must be intuitive, easy to use and robust. 5 Concept After the identification of the requirements on the TWS, the following six workflow use cases were created in order to design the interaction workflow: alerting and drive, arriving and role changing, situation assessment and situation report, giving commis- sion and sending a request, (sub-) operational units, and information and note area. The design is based on the requirement, that all important operation information must be visible on one view. Additionally, the design concept should be transferable to different touch devices, e.g. large multi-touch tables, tablets or smart phones. To ful- fill this requirement, to create the interaction concept and to model the cooperative workflow, a wireframe-based prototype was developed (Fig. 1). Particularly with regard to the requirement of displaying all relevant information on one view, the de- sign concept has been split into the following four equal sized areas (Fig. 2):  Map area: This area provides the following full multi-touch-based interactive views: a street map, a combination of a satellite view and a street map, an object plan if available, and a free sketch/note area. The two map views include the illus- tration of (sub-) operational units, dangers, casualties and some additional infor- mation such as wind direction.  Information area: Here, the over-all operation information is displayed ranging from arbitrary information such as operation address, (operation) time, to casualties and resources statistics.  (Sub-) operational unit area: In this area, all (sub-) operational units are listed providing specific information such as (sub-) operational unit leader, assigned re- sources, or casualties in this (sub-) operational unit.  Task and Request area: This is a management area providing an overview of all given tasks/commissions and received requests, as well as an log view document- ing the inputs of the user and incoming events, and a note and documentation area allowing to record or to write down some notes. Fig. 1. Wireframes for the TWS at different design/conceptual phases (left is an early version and right an advanced one). Fig. 2. The final mockup showing the four area design. In order to provide a more detailed and larger view, each area can be resized by a short single touch inside an area expanding buttons. It is also possible to enlarge two areas at the same time. Last, but not least, the TWS supports drag and drop actions between the different areas for special interactive elements, e.g. dragging an operation unit from the operation unit area on the map. Thanks to a modular design, all areas and their interactive elements can be used as single modules. Therefore, it is possible to transfer the whole concept to smaller screens. Besides the requirements concerning interaction and design aspects, further func- tionalities were considered in the conceptual phase such as an automatic sending of the situation report (because the TWS holds all information to be given in a situation report and thus, the operation manager does not have to be reminded to do it), remind- ing of special events (e.g. that not enough resources are available to transport the casualties or to check the state of given commissions), and a role rights management component controlling and managing the displayed information for all roles. After the wireframes were accepted by the fire brigade officers and their assistants, mockups were created. These mockups served as design templates for the prototype implementation. 6 Requirement Validation To validate whether the design concept meets the requirements of the operation man- ager, a preliminary prototype was implemented and evaluated in an MCI simulation with 20 supernumeraries acting as casualties. This simulation was originated to per- form an integration and cooperation test of all components developed in context of the ALARM-project [7]. Consequently, the simulation did not claim to simulate an MCI. Aligned to the ALARM-project solution, the TWS receives and sends all infor- mation from/to a local server, the so called local platform, via ActiveMQ3. The local platform is the central element of the operational structure. It gathers all accruing operation information from mobile clients such as triage or transport information. Every time new information is coming in, the local platform forwards this information to the TWS. The TWS prototype itself was implemented in Java using MT4j4, sup- ported no input functionalities, and was deployed on a Motion J3500 tablet PC5. The simulation consisted of only one treatment area which was already build-up at the beginning. During the whole simulation, one researcher accompanied the opera- tional manager and noted everything related to the TWS including issues, the way of interaction, and remarks of the operation manager. This intermediate evaluation re- vealed open design issues such as the difficulty of reading color-coded casualty statis- tics in bright daylight and new requirements such as more variations of the casualty statistics, and the wish of recognizing possible problems in the triage process such as the need of more rescue staff for the triage. The notes from the simulation are current- ly analyzed and will be considered in the requirements analysis again. 3 http://activemq.apache.org/ (accessed on 2012/08/22) 4 http://www.mt4j.org (accessed on 2012/08/22) 5 http://www.motioncomputing.com/products/tablet_pc_J35.asp (accessed on 2012/08/22) 7 Conclusion In this paper, an IT supported tactical worksheet supporting operation managers in their decision making was presented. It includes the comprehensive requirement anal- ysis and conceptual aspects. Although the requirements were established in context of the ALARM project for the Berlin fire brigade, they should be general enough to apply to other fire brigades. Finally, a preliminary prototype was evaluated in a real MCI simulation with 20 casualties in order to validate the design concept developed from the identified requirements. The evaluation revealed useful feedback to the de- sign which has to be still analyzed. Based on information gathered from this analysis, the requirement analysis as described in section 3 has to be performed again. Fur- thermore, it will be considered how the ubiquitous computing infrastructure of the ALARM solution can be used to recognize critical situations at the MCI. The re- worked design concept and an enhanced prototype implementation will be tested on a real MCI simulation with about 33 casualties. Acknowledgements. This work originated in conjunction with the ALARM project which is sponsored by the German Federal Ministry of Education and Research (con- tract/grant number 13N10109). References 1. Adler, C., Krüsmann, M., Greiner-Mai, T., Donner, A., Chaves, J.M., Estrem, À.V.: IT- Supported Management of Mass Casualty Incidents: The e-Triage Project. In: Proceedings of 8th International ISCRAM Conference. (2011) 2. Artinger, E., Coskun, T., Schanzenbach, M., Echtler, F., Nester, S., Klinker, G.: Exploring Multi-touch Gestures for Map Interaction in Mass Casualty Incidents. In: 3. Workshop zur IT-Unterstützung von Rettungskräften, Informatik 2011. (2011) 3. Babitski, G., Bergweiler, S., Grebner, O., Oberle, D., Paulheim, H., Probst, F.: SoKNOS: Using Semantic Technologies in Disaster Management Software. In: ESWC’11. LNCS, vol. 6644, pp. 183–197. Springer Berlin/Heidelberg (2011) 4. Bourque P., Dupuis, R.: Guide to the Software Engineering Body of Knowledge 2004 Ver- sion. In: Guide to the Software Engineering Body of Knowledge, 2004. SWEBOK (2004) 5. Humayoun, S., Catarci, T., Leoni, M., Marrella, A., Mecella, M., Bortenschlager, M., Steinmann, R.: Designing Mobile Systems in Highly Dynamic Scenarios: The Workpad Methodology. In: Knowledge, Technology & Policy 22, pp. 25–43. (2009) 6. Krüger, U., Wucholt, F., Beckstein, C.: Electronic Checklist Support for Disaster Re- sponse. In: Proceedings of the 9th International ISCRAM Conference. (2012) 7. Lawatschek, R., Düsterwald, S., Wirth, C., Schröder, T.: Alarm: A Modular IT Solution to Support and Evaluate Mass Casualty Incident (MCI) Management. In: Proceedings of the 9th International ISCRAM Conference. (2012) 8. Martí, R., Robles, S., Martín-Campillo, A., Cucurull, J.: Providing Early Resource Alloca- tion During Emergencies: The Mobile Triage Tag. In: J. Netw. Comput. Appl. 32(6), pp. 1167–1182 (2009) Applying AmI Technologies to Crisis Management: AmI 2012 Workshop Summary Monica Divitini1, Babak A. Farshchian2, Jacqueline Floch2, Ragnhild Halvorsrud2, Simone Mora1 and Michael Stiso2 1 NTNU, N-7491 Trondheim, Norway {monica.divitini, simone.mora}@idi.ntnu.no 2 SINTEF ICT, P.O.Box 4760 Sluppen, N-7465 Trondheim, Norway {babak.farshchian, jacqueline.floch, ragnhild.halvorsrud, michael.stiso}@sintef.no Abstract. The AmI4CM workshop was organized as part of AmI 2012 in Pisa, Italy. This short paper summarizes the workshop content and the discussions that took place during the workshop. 1 Introduction The workshop aims to bring together researchers and practitioners working on the application of AmI (Ambient Intelligence) to crisis and disaster management. Because of their pervasiveness and ease of use, AmI technologies hold a great potential to support crisis management in an efficient and effective way. The focus of the workshop is to better understand (1) the strengths of the AmI paradigm, (2) challenges to its application, and (3) its potential in the development of innovative solutions. The workshop is open to participation from different standpoints, including platform and user interaction issues, methodological approaches, and specific applications. The workshop is jointly organized by three projects that investigate ICT support for crisis management from different perspectives. BRIDGE1 aims at building a system to support interoperability – both technical and social – in large-scale emergency management. MIRROR2 aims at developing ICT tools for supporting workplace reflection and learning. Training of crisis workers is also a core application domain of the MIRROR project. SOCIETIES3 aims at extending the application of pervasive computing beyond the individual to communities of users, developing the concept of Cooperating Smart Spaces. Disaster management is chosen as one area for 1 http://www.bridgeproject.eu/en 2 http://www.mirror-project.eu/ 3 http://www.ict-societies.eu/ 2 Babak Farshchian et al. the evaluation of the proposed solutions in SOCIETIES. All three projects are funded by the EU Seventh Framework Programme. 2 Workshop Organization Papers: The workshop has an open call and is advertised in a long range of relevant lists and communities. Organizers use easychair.org to do the review process. The workshop papers are peer-reviewed by the organizing committee4. Eight papers were received by end of deadline for submission in 2012. All eight were accepted for participation in the workshop. As you can see in the proceedings, the papers represent diverse aspects of AmI in crisis management, including tools, platforms, studies and observations. Workshop participation: The workshop was divided into two parts: presentations in the morning and a SWOT analysis in the afternoon. All accepted papers were presented by the authors during the workshop, and all but one of the authors participated in the SWOT session in the afternoon. The SWOT session was interactive and involved all the participants at equal level. Preparations: In addition to the paper review process we also asked the participants to create profile cards for themselves, which turned out to be very useful during the workshop (see Figure 1). We also asked Jacqueline to give the workshop an overview of AmI, how it was defined in the literature, and what applications it had. The presentation was given in the beginning of the workshop in order to create a common understanding of the subject. Figure 1: Profile cards prepared by the participants, showing their research interests and backgrounds. 4 Since this is the first time we organized this workshop we did not extend to a larger reviewer group. This will be done for future editions. Applying AmI Technologies to Crisis Management: AmI 2012 Workshop Summary 3 3 The SWOT Analysis Besides the papers that are presented in these proceedings, the other major deliverable from the workshop is a SWOT analysis5 that we did during the workshop. The process consisted of two parts, one brainstorming part and one clustering part. In the brainstorming part the participants were given a 20 minutes individual task of writing down their contribution to the analysis on Post-It notes. Afterwards each participant was asked to present the contribution to the others. We used the windows in the room to hang the notes. Table 1 at the end of the paper shows a raw format of the contributions. The clustering part was about grouping the contributions to major thematic groups. This task was also done involving the whole group of participants (see Figure 2). At the end we documented the results in a mind map. A portion of the map is shown in Figure 3. The groups under each heading included the following:  Strengths: Support for situation awareness, support for non-experts, diffused enabling technologies such as smart phones, relevance for the society.  Weaknesses: Technology-driven focus, inherent technological complexity, contribution to information overload, lack of robustness in the available technology and systems.  Opportunities: Emerging technological trends that can help AmI4CM, can contribute better to organizational aspects and logistics, can help in analysing large amounts of data, can be used also for preparedness.  Threats: Methodological weakness (real world evaluations and validations almost possible), integration and standardization challenges, technological challenges (e.g. infrastructure failure during disasters), lack of acceptance (e.g. big brother issues, usability issues). If you need the complete mind map document please contact one of the co-organizers. 4 Future work The workshop home page6 will work as a blog for the community of the participants. We believe the workshop contributed positively to the field. The participants were very active before and during the workshop. We hope the workshop will continue as a series as part of the AmI conferences or elsewhere. We thank all the participants for the cooperation. 5 SWOT analysis (alternately SWOT Matrix) is a structured planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. (Definition from Wikipedia) 6 http://research.idi.ntnu.no/ami4cm/ 4 Babaak Farshchian et al. Figure F 2: SWO OT analysis, clustering ph hase. Figure 3: A portion of th he mind map after the clusstering exerciise. Applying AmI Technologies to Crisis Management: AmI 2012 Workshop Summary 5 Table 1: Raw data from our SWOT analysis. Helpful Harmful Strengths: Possibility to automate, to collect and Weakness: Lack of trust in automation, Lack of privacy, distribute relevant information, to monitor stress Infrastructure to set up, Many prototyped solutions are not level, situation awareness, information feathering, stable enough, e.g. network, Security/privacy, Inability to correct information in correct time, peripheral observe relevant information, Introduce additional technology, early detection and early warning, replace trivial manual labour, improve training and technical overhead, A tendency to remove the social, A reduce cost of training, countering information tendency to focus on the technical, Non-technological overload, sound methodological approach, sound issues might hamper use of technology during crisis, Too algorithms, the cloud as an emerging platform, much reliance on infrastructure, Provide useful possibility for support in tracking of resources during information, Saving time, Regional differences, need to do crisis, knowledge integration and dynamic access to lots of adoption work, Access to social data might be information, tools for supporting crisis management limited in rural areas, Lack of common in the field, in addition to support at organizational level, seamless integration with practices using HCI framework/middleware for integration, Problems making methods, provide better structure, response, use of sense of a lot of collected data, Weakness in the design human capacity, coordination, ubiquitous access to process, with multiple stakeholders, Lack of robustness, information, relevance for society Rising complexity of the systems, and integration with Internal origin existing infrastructures. Complex systems with a lot of risks, Lack of integration with everyday life for normal people, Fragile and too complex systems Opportunities: Good body of knowledge available, Threats: Communication barriers among agencies, There both technical and socio-technical, Possibility of is a gap between technical and application-related including crowds (as sensors and processors), knowledge, Infrastructure threats, Dependency on Nanotechnology, Improve situation-awareness, Can technology can become a problem when technology not get rid of unnecessary organizational overhead, available, Low user acceptance, Misinterpretation of Leverage the need for testing of tools, and introduce prototypes because they are often too mature for user more realistic training, Improving logistics, e.g. involvement, Network and service availability, Difficult to water supply, patient logistics, Focus on pervading get tools in daily practice, Successful use of this type of practices instead of replacing them, Complex technology might require too much costs, Accountability, calculations on demand, that can be done by Lack of acceptance due to privacy issues, Users not computers, Searching for information in big allowed to do real crisis, barrier, Invasiveness of AmI repositories, Discipline of developing AmI, maybe technologies, Acceptance and the difficulty of it, Trust in only for training and simulation, is important, technology when there is no continuous usage, Integration Information overload, Lack of control. Devices do into existing organizational patterns and existing stuff but we might not understand what and why, technologies, Difficulty with standardization, Lack of Making volunteers aware of what they contribute to, transparency, Very different scenarios; challenge for Can use mobile app stores to deploy applications generalizing, Methodogically weak when it comes to more easily, To build self-organizing communities, evaluation, Big brother more automation, Preparedness linked to environment (e.g. level of water in a river) and External origin people (e.g. who is expert in what), Can bring the different phases of crisis management together, e.g. integrating data from crisis field to post-crisis, Smart phones, mobile internet, More funding is coming