Keywords

1 Introduction

Unfortunately, disasters and emergencies happen all around the world every day or even every hour, and most of them are not even man-made but natural. They can be in a small scale such as a fire in a building or in a large one such as a tsunami hitting several coastal countries. When a disaster strikes, mapping the threat and getting the precise information and overview of the hazard become the most crucial and challenging tasks. There is a long list of ICT-based technologies (esp. software) that have been developed in recent years in order to successfully support these tasks, emergency management procedures, and actors involved in disasters (victims and emergency responders). For instance, crisis mapping tools such as [1–3] or disaster and crisis smartphone apps presented in [4–6].

By including ICT as a necessary component of emergency management, useful interfaces for emergency systems are required. The user interface (UI) and the usability of these systems are highly critical. We may hear from people around us complaining about the usability or interface of software or apps they use daily, but this cannot be the case for emergency management tools, such as smartphone apps that are developed to support emergency responders and victims. They need to be reliable and effective even when users are under stress. When facing disaster scenarios, momentous decisions rely on the effectiveness and efficiency of these technological tools to provide the information and communication processes. Users of the emergency management systems are under more pressure to [7]: absorb information rapidly, judge its sense, meaning, relevance, and reliability, decide what the options for action are and make effective decisions accordingly. Therefore, the accomplishment of a series of cognitively demanding steps rely on the effectiveness of the technology (e.g., apps) and the design of the human-computer interaction (HCI) used in emergency scenarios.

There are several studies on the role of HCI and its challenges for mobile devices (also known as Mobile HCI) (see e.g., [8–12]), in emergency management (see, e.g., [7, 13, 14]). In this paper, we study these challenges extracted from the literature and their corresponding solutions. Then, we investigate whether these challenges have been addressed in two crisis management tools that authors with a thorough understanding about their features have used in their research, i.e. GDACSmobile [15] and SmartRescue application [16]. The former is an information system that acts as a real-time multi-hazard platform using smartphones and Twitter. The latter is an application for both monitoring hazard developments and tracking victims during a disaster applying smartphone sensors and a publish-subscribe platform. This paper also studies the usability of these two apps in a designed emergency scenario, a fire onboard a ship.

The rest of this paper is organized as follows. Section 2 describes the challenges in designing HCI. Section 3 explains the two selected applications and their corresponding mobile HCI challenges in details. In Sect. 4, the usability of these apps in an emergency scenario will be studied. Section 5 concludes the paper.

2 Challenges in Designing HCI

There are many challenges in designing HCI for emergency management smartphone apps. There are some general challenges, such as: software challenges (e.g., menu, navigation, browsing, image, and icon), hardware challenges (e.g., screen size, battery life, keyboard, touch screen, and mobility), Internet connectivity, attempting to provide users with powerful computing services and resources through small interfaces [9], the fat finger problem [10] referring to the fact that finger touch is much more imprecise than pointing with a mouse in terms of addressed pixels. In addition to these general challenges, there exist some specific challenges from HCI point of view for smartphone apps developed for supporting emergency issues that can be found in [7].

It is important to have a non-complex UI that helps victims in danger and stress or rescuers to handle the emergency management apps as easily as possible. This can be done by limiting the number of functionalities available on a single screen or within one mobile app [12]. The mobile app developers should also consider that their user groups might be elderly, disabled people, children, or even injured people. Flentge et al. [13] also proposed that the design of HCI for those working in the disaster field should be different from those in the command and control posts. They suggest audio and/or video interaction for those working in the affected area and multi-user interfaces for crisis management teams working in the command posts. In the same paper, they have listed the following challenges of designing HCI for incident management: (1) Reduction of complexity, which addresses the need for a compact form of presenting information in an emergency situation, the ease of use, and the simplicity of user interfaces; (2) Priority of the primary task, which states that interacting with emergency management tools should not distract responders from their main tasks and responsibilities; (3) Heterogeneity of the involved actors, which recommends that the UIs of the emergency management tools should support all kinds of users from victims to experienced, well-trained users; (4) Heterogeneity of ICT, which points out that the involved organizations have different technological systems. Therefore, flexible and adaptive user interfaces are needed; (5) Security and privacy, which concerns the information security and data privacy of the developed tools; and (6) Context-awareness, which deals with the adaption of interfaces to users, devices at hand, and environments. Context information can have a substantial impact on emergency response by contributing to an accurate view of the emergency situations.

In the next section, we present the two emergency management apps, GDACSmobile and SmartRescue and discuss if the six above-mentioned challenges have been addressed in designing HCI of these two apps by the developers.

3 Studied Applications

In this section, we give an introduction on GDACSmobile and SmartRescue apps. We study how the developers of these two apps have tackled the HCI design challenges mentioned in the previous section by [13]. The results are summarized in Table 1. The reason for selecting these two apps, as discussed in Sect. 1, is that the authors had the opportunity to employ them in their research and in a serious emergency game designed by the ISCRAM summer school.

3.1 GDACSmobile

The GDACSmobile project has been developed by the Information Systems Department of the University of Münster and the Joint Research Centre (JRC) of the European Commission aiming to expand GDACS by community involvement. The goals of GDACSmobile project are: to enhance the quality of circulated information using smartphone apps and Twitter; to reduce the level of uncertainty in the received information from Twitter by means of bounded-crowdsourcing; to be able to exchange information and coordinate emergencies in the first phase after a major disaster using smartphones.

The GDACSmobile system consists of a smartphone client app which is used for accessing content and sharing/updating information, and a web-based server application which is employed for data (e.g., reports on a disaster) retrieval, storage and analysis. GDACSmobile can be used by both disaster management professionals (“authorized/registered users”) and the affected population (“public users” or “authorized users”) to share their observations from the affected area as “situation reports”, both via the GDACSmobile client app for mobile devices, and via Twitter. Via the client app, both users group can also receive updated reports providing them by valuable information to support their decision-making. Figure 1 shows some screenshots of the UIs of the client app for an authorized userFootnote 1.

Fig. 1.
figure 1

(a) A map view of the alerts, (b) The main menu for each selected alert, (c) Map showing all reports related to the selected alert and its corresponding information window, (d) Reporting page.

Full size image

3.2 SmartRescue

The SmartRescue project started in 2012 in the Centre for Integrated Emergency Management (CIEM) [17] at the Universitetet of Agder (UiA), Norway. The aim of this project is to apply latest technologies in smartphones to support victims in need and rescuers. The project also has several goals: detecting fire and predicting its future development; using advanced sensors embedded in smartphones in order to assist crisis managers to locate victims during the evacuation procedure; constructing risk-minimizing evacuation plans; avoiding congestion in escape routes.

To accomplish these goals, a smartphone-based app with the ability of processing sensor readings into useful information for the crisis responders was developed. It consists of a robust content-based publish-subscribe mechanism that allows flexible sharing and receiving of sensor data. A publisher is the user who wants to share the data that his/her SmartRescue app has sensed by the sensors in the smartphone. A subscriber is the user who wants to receive this sensed data. A user can be both publisher and/or subscriber. The system also employs a machine learning technique that predicts the fire status in the next couple of seconds. In addition to the smartphone app, there is a web-based server available for data collection and analysis, which also acts as a subscriber. Figure 2 presents some screenshots of the UIs of the SmartRescue app for both user groups (victims and rescuers).

Fig. 2.
figure 2

(a) The main menu, (b) The “Setting” page, (c) The “Subscriber” page, the user can choose what sort of sensor data to receive. The same option exists for the “Publisher”. (d) The map a building that is showing the location of the user (blue marker), the location of the publishers (typically victims, red markers), and the location and condition of the fire in different areas of the building (red and green circles) (Color figure online).

Full size image

3.3 HCI Analysis for GDACSmobile and SmartRescue Apps

The table below discusses if the developers of the apps, GDACSmobile and SmartRescue, have addressed the challenges of designing HCI when developing their apps for emergencies.

Table 1. HCI Analysis for GDACSmobile and SmartRescue apps
Full size table

4 SmartRescue and GDACSmobile in Practice

In this section, an emergency scenario, a fire on a cruise (i.e., a passenger ship) with about 5 floors and more than 1000 passengers and crews onboard is defined. The aim of having this scenario is to investigate the usability of the two chosen apps in practice.

4.1 Defining the Scenario: Fire Onboard a Passenger Ship

When fire is noticed by any of the passengers or crew, first the crew and then the captain of the ship will be informed. After informing the captain, the corresponding crew will go directly to the location to assess the situation. When the fire is approved, then the captain asks for more information to get an overview of the situation. Depending on the size and location of the fire, the captain should decide if it is an emergency or not. If the fire is steadily spreading over the other parts of the ship and is difficult to extinguish, then the captain considers it as an emergency and asks other emergency organizations to join in extinguishing the fire and evacuating the passengers. The captain then sounds the general alarm to initiate the mustering of the passengers, and then if necessary gives the order to abandon the ship. The ship crew alerts the passengers and tries to evacuate the entire ship or a part of it, while other crew members have to extinguish the fire. The crew acts as emergency responders. The crew of the ship is trained to act as firefighters and first aid team. They follow the orders given by the captain of the ship.

When fire spreads from one compartment to another, crew tries to close the compartment to prevent fire from spreading. The captain will give all the necessary information to the ship company, if they require while managing emergency. On the ship, there will be an on-scene commander (OSC) who reports the situation to the captain (operational commander (OPC)). The OSC will distribute all the fire teams for different tasks like cooling down areas above, on the sides and below, and search of the areas affected by the smoke. Based on the reports from the OSC, the captain will make the decisions. The ship has hospital and trained first aid team that take care of the injured passengers. The chief officer is the medical person onboard, and reports to the OPC. If the injured passengers need medical attention urgently, then they will be taken by helicopter.

Utilizing GDACSmobile Onboard.

By getting onboard the ships and as part of the safety instruction, passengers are asked to install the client app on their smartphones. They are also informed about the hashtag they need to use for reporting or getting reports through Twitter. In order to use the GDACSmobile app, several crew members have been selected as authorized users in case of emergency. When the passengers of the ship notice a fire, they can use either the GDACSmobile client app or Twitter to report about the emergency situation by sending messages with text and/or with image. For instance, passengers can send their locations in the ship with directions in form of text or pictures. The information which is sent by passengers will be received by the emergency responders onboard in order to help the victims. When passengers use client app, they can send message as public users to get help from or to report about the situation. But passengers have to use a hashtag for sharing the information via Twitter. Victims of the emergency can view the other submitted reports as a list or on map view when the administrator accepts the report and makes them available. With the available reports, users (either authorized or public) can get the overview of the situation by viewing the map. Reports from authorized users are considered accepted by default. These reports are used for evacuating and helping the victims of the ship.

Utilizing GDACSmobile at the On-Scene Coordination Centre.

When the reports are submitted by both passengers and the crew of the ship through the client app or via Twitter, administrator (chosen by the captain) on the web-based server will view the reports and edit the received reports, he can either public accept, accept, reject, or just save the reports to be later used for helping the victims and the emergency management. Administrator is able to add extra information such as description and comment to the available reports. By using GDACSmobile app, emergency responders can receive the emergency related data to get an overview of the situation as well as to help the victims by alerting the public via Twitter. OSC can use these reports to assign the tasks to the other crew of the ship and also to inform to the OPC i.e., the captain. OPC uses these reports to assess the situation and take the decisions on evacuating, providing first aid, and managing the emergency.

Utilizing SmartRescue Onboard.

For the security and the safety procedure, before the journey starts, the passengers of the ship are asked to install this app in their smartphones in order to send the information to the emergency responders during an emergency. When fire is noticed and reported, crew of the ship will inform the captain and then a group will go to the location of the fire. They can locate the fire using the SmartRescue app. They can act either as a publisher (to send information) or a subscriber (to receive information). The passengers, who chose to be publishers, send sensed data from their smartphones. Some of the crew members, as subscribers, receive the published data such as the location of the passengers, their condition (if they are moving or not), the location and condition of the fire. They can also receive data about the temperature, pressure, and the humidity of the area the publisher is in. This generates a global picture of the fire. The app can also predict how the fire is going to develop in the near future using Bayesian networks (BN). The crew members who are acting as firefighters inform the OSC and he informs the OPC about the emergency procedure. Thus, the captain can make decisions about the evacuation procedures, extinguishing plan, and so on.

Utilizing SmartRescue at the On-scene Coordination Centre.

At on-scene coordination centre, the OPC will be in lead. The SmartRescue app will support him and the OSC to get an overview of the emergency situation. When the passengers and the crew act as publishers, the OPC and the OSC subscribe to receive data about the location and condition of the victims, the location of the crew, and the location and condition of the fire. Based on the available information and the ability of the app to predict fire, OPC and OSC can make better decisions.

5 Discussion and Conclusion

This paper tried to gather some of the most important challenges of mobile HCI in emergency management apps that might be overlooked by app developers. Two emergency management and crisis mapping tools was selected as a case study. By applying the two selected apps in an emergency scenario, the role of HCI is the design of the apps as discussed in Table 1 is more visible. As both apps are context-aware applications, they can sense their physical environment either by reading the sensors or by reporting using image or text. Both apps are easy to use, but still there can be some potential improvements. GDACSmobile has different UIs for its user groups, while SmartRescue has only one single UI. Both of these approaches can have pros and cons that can be discussed in future works. For having a deep understanding on the usability and goodness of the interfaces in these apps, there exist several usability test approaches, such as serious games, interviews, online surveys, and ISO 9241. As a future work, these methods will also be studied.