=Paper=
{{Paper
|id=None
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-953/ami4cm2012-all.pdf
|volume=Vol-953
}}
==None==
https://ceur-ws.org/Vol-953/ami4cm2012-all.pdf
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