Abstract
Smart cities have a huge potential to increase the everyday efficiency of cities, but also to increase preparation and resilience in case of natural disasters. Especially for disasters which are somewhat predicable like floods, sensor data can be used to provide citizens with up-to-date, personalized and location-specific information (street or even house level resolution). This information allows citizens to better prepare to avert water damage to their property, reduce the needed government support, and — by connecting citizens locally — improve mutual support among neighbors.
But how can a smart city application be designed that is both usable and able to function during disaster conditions? Which smart city information can be used? How can the likelihood of mutual, local support be increased? In this practice report, we present the human-centered development process of an app to use Smart City data to better prepare citizens for floods and improve their mutual support during disasters as a case study to answer these questions.
1 Introduction
Natural disasters and crises like floods, situations during which normally dry areas are completely covered with water, are rare but devastating events. Floods can be differentiated as flash floods, floods due to heavy rain, storm floods, and stream flooding [48]. During a flood disaster, the water rises far above the normal water levels and reaches cultural land. Floods frequently do direct and indirect damages that are both intangible and tangible [48]: Direct damages include loss of lives, spread of diseases, damaged or destroyed cultural artefacts and natural monuments (intangible) as well as loss of property and costs for rebuilding (tangible). Indirect costs include psychological effects (intangible) and reduced commercial activity and buying power (tangible).
While potentially devastating to lives and infrastructure, floods are a natural part of the general water cycle and cannot be prevented [48]. However, they can be predicted and thus prepared for, as floods usually occur only after precursor events (e. g., after melting snow or heavy rain, or during storms at the coast) and the affected areas are mostly determined by closeness to bodies of water (coast, river), water levels and elevation. But despite warnings from government agencies (e. g., in Germany by the Federal Office of Civil Protection and Disaster Assistance) preparation is often suboptimal due to insufficient or missed information [33].
Informed citizens are necessary, however, to effectively deal with disasters like floods and to prevent or mitigate damages. Timely and situation specific information and behavior recommendations are needed to avoid confusion and panic and to use the available resources as effectively and efficiently as possible. Reliable and valid information also increases feelings of safety, reduces perceived loss of control and supports informed decision making [49]. In general, the less information provided, the larger the uncertainty in the population, which in turn leads to more frequent errors [33]. The beneficial effect of information even applies prior to a flood, as education about risks (e. g., living in an area at risk of floods) can lead to a higher degree of information seeking and disaster preparedness measures [34].
Thus, timely and situation-specific information to prepare for floods, and to cope with them once they occur, is crucial. Information must get to the right people at the right time and people must be kept informed even when confusion or panic is likely to clutter information channels. This requirement applies both prior and during floods, and to official information, as well as information exchange among people living in the same area (e. g., when they communicate to provide mutual support and pull resources). This raises the questions of how the information can be provided and how the mutual support among those affected by a flood can be facilitated.
In addition to official information from government agencies, the increasing digitization of cities (smart cities) and whole regions (smart regions) can be used to provide up-to-date location specific information. Smart cities can be defined as “places where information technology is combined with infrastructure, architecture, everyday objects, and even our bodies to address social, economic, and environmental problems” [53]. Using sensor information of smart cities and regions directly avoids the loop through government intermediaries like disaster protection agencies. Thus, this data provides up-to-date information about the environment and can quickly inform the population about the current situation, e. g., the location specific water levels and the overall trend. If a smartphone app is used, the available information (provided by the individual user or collected via the smartphone sensors, e. g., GPS) can be used to provide much more timely and location specific information than via mass media like radio and television. As individual devices might not be working during a disaster (e. g., due to blackouts) and some citizens do not have smartphones, public screens can be used to fill the gap.
The same app can also connect citizens in the same city or region and facilitate mutual support (informal help done privately and without payment, cf. neighborhood support, [18]). This self-organization of those affected by a flood (e. g., to request and offer manpower or tools) can relieve agencies and relief organizations and save the already stressed resources to centrally coordinate voluntary help.
However, disasters like floods do present specific challenges, including to the digital infrastructure underlying smart cities. Before investing in resilient technology, the usefulness of using smart city information and an app to prepare and deal with floods should be assessed. Specifically, whether and how an app using smart city information and allowing communication among people in the same area can lead to better disaster preparedness and mutual support.
To examine these questions and reveal the potentials and challenges of combining smart city data and citizen participation to increase disaster resilience, a human-centered development process (following DIN EN ISO 9241-210, [13]) using software ergonomic criteria [27] was applied. Scenario-based design [51] was used during the design process. The app was developed in two stages – first the base version using smart city information from water level sensors and providing disaster information as short articles, then an expanded version with added functionality for mutual support. As the requirements of a smart city disaster app affect both information from sensors and mutual support, and the requirements for mutual support were determined during the first iteration, the development process is described for both app development stages together for improved readability. Thus we present the analysis (Section 2), conceptual design (Section 3), implementation (Section 4), summative evaluation (Section 5), and general discussion and conclusions with lessons learned from this case study (Section 6).
To focus the development of the app on a concrete use case, we use the city of Lübeck for this case study. The river Trave flows through the city (and around its historic center), due to which it is at risk of floods. Floods due to stream flooding are also predictable, usually hours in advance by measuring the water levels higher up the river, or even by detecting a rising trend of nearby water levels. Given the regions’ investments into smart city and smart region infrastructure, this information is available for usage. Thus, this use case allows us to examine the use of smart city information and develop an application which can be evaluated locally.
2 Analysis
To analyse the state of the art and determine the requirements, a literature research, an online search for existing apps and websites, and expert interviews were conducted (see Section 2.1). The overarching questions that shape the analysis were: What is the physical and temporal context prior, during, and after a flood, what are the tasks to prepare and cope with a flood, which organizations are involved to provide information and support, which solutions already exist that can inform the development of the app, and who is affected by it (see Section 2.2). This information was used to derive the requirements and determine how smart city information can be used to better prepare for and cope with the situation (see Section 2.3).
2.1 Data Basis
A literature research was conducted between the 21st of April 2020 and the 30th of May 2020 using the online databases of the ACM Digital Library [1], the digital library of the German society for computer science [19], the literature catalogue of the university of Lübeck [40] and Google Scholar [24]. The search was focused on areas of disaster protection, crisis communication, smart cities, and mutual support among neighbors, with search terms being, e. g., organization of voluntary helpers, crisis communication, communication public safety, neighborhood help, social capital, mobile warning apps, public displays, risk perception, disaster crowdsourcing, and persuasive technology.
A web search was conducted to identify organizations and projects providing information about floods. Relevant websites that were identified are the websites of the Federal Office of Civil Protection and Disaster Assistance [8], the German Weather Service [57], the Federal Maritime and Hydrographic Agency [10], the website of the state “Schleswig-Holstein” [37] and, given the use case, the website of the city of Lübeck [39]. Using the last website as starting point, the private project Projekt-i-quadrat [29] could be identified, which provides information (incl. checklists) about preparedness for heavy rain in the city.
An App store search (Google Play Store [25] and Apple’s App Store [30]) was conducted to identify smartphone apps that warn about disasters and crises and/or offer information to prepare or cope with disasters. The reviews of the most frequently downloaded apps (NINA [5], KATWARN [20] and BIWAPP [41]) were analyzed for mentioned usability problems that can inform the design of the app.
Expert interviews were conducted with five members of different organizations from the areas of disaster protection and neighborhood support (two women, three men, including ID1) a pastor, ID2) a leader of cooperation efforts in a relief organization, ID3) a coordinator of crisis prevention and quality management in a relief organization, ID4) a chairman of a relief association, and ID5) a senior firefighter in emergency preparedness and response). An interview manual was used in combination with the critical incidents methods. Participants were asked to remind themselves of the last disaster they had faced and describe what they did and which problems they faced. They were asked to start with a detailed description of the incident and then go through the stages: prior to the incident, when it started to happen, during, when it did end, and after the incident. The focus was on what those affected by the flood experience and should do. Prompts were used to gather additional information, e. g., regarding communication, tasks, or use of existing apps. Depending on the specific expertise of the interviewee, further questions were asked, e. g., if the person was involved in neighborhood support, questions were asked how to identify barriers, if the person was involved with damage control, questions were asked regarding frequent damages.
2.2 Floods
Context: Given the use case of the city of Lübeck with the river “Trave” flowing through it, the focus is on stream flooding. Here, the physical context is the area next to rivers which is at risk of floods. However, due to the – at times – massive damage, the physical context reaches beyond the flooded areas to include possible support by individuals and organizations from areas that are not directly affected.
As stream flooding usually does not happen suddenly [48], but because of long rain periods (summer) or melting snow (winter; [23]), the time can be predicted hours or days in advance. As water will flow downhill and elevation levels are known (if the user can access the elevation level of his current position), rough predictions can also be made for the affected physical location. That prediction might be off if, e. g., when a low elevation is surrounded by elevations above the water level, or if backed-up water leads to a local rapid rise in water levels, or if protective structures break (e. g., a dam), but should be a good data basis in most cases. The immediately available information are measurements of rising water levels close to the property of the user, thus this data can serve as a directly available and useful information source.
Looking at the crisis management process of the Federal Ministry of the Interior, Building and Community, disasters can be divided into four phases: I. General Preparedness, II. Preparation, III. Handling, and IV. Wrap-Up after a crisis (cf. [11]). We group the first two steps as “prior to the crisis” and focus on preparation and handling the flood, less on the wrap-up.
Tasks: Tasks by those affected by the flood were determined with expert interviews (IDs) and literature research: Task 1 Preparing for a crisis: Getting information like recommended actions, checklists, information about possible dangers and risks (ID 2, 5), Task 2 Being informed about the current situation: Getting information about an imminent crisis and the current/developing situation (ID 5), Task 3 Searching for reliable and valid information sources: Dealing with specific questions or problems that can arise prior or during the crisis (ID 2, 5), Task 4 Organization in groups: Working together with other affected individuals to solve common problems, e. g., getting a pump for a house with multiple tenants, Task 5 Searching for resources and support: Dealing with missing resources and support (ID 1–4), Task 6 Offering resources and support: Providing resources and support (ID 1–4), and Task 7 Acting to mitigate the risk and consequences of the crisis: Actually implementing the preparations and using the information and support.
Organizations Involved: From an organizational perspective, in Germany, disaster preparedness is the domain of the federal states. This organisation is coordinated by the local fire department in close coordination with local relief organizations [7].
Different organizations are responsible to provide official information about potentially dangerous situations: General warnings are provided by the Federal Office of Civil Protection and Disaster Assistance. Information and warnings about tides, water levels and storm floods are provided by the Federal Maritime and Hydrographic Agency. Warnings about storms are provided by the German Weather Service. As different organizations are responsible, an app should access all of these sources for relevant information and warnings. As an app can access the users (and their properties’) position, warnings should be filtered to provide only the actually relevant information.
Offers of support by voluntary helpers are frequently organized by associations, church groups, or relief organizations. Those who would like to provide support contact these organizations and are then matched with those who need help. Information about this support is spread via social media, websites of the organisation themselves, and flyers (interviews, see Section 2.1). To relieve these organizations and facilitate efficient use of limited resources, the matching should be done automatically.
Existing Websites and Apps: Websites and apps were developed to help people to better prepare for floods (and other extreme events). Based on the web search (see Section 2.1) different apps were found and examined. These include official government websites and apps, as well as unofficial apps. These apps can be categorized in the areas of 1. information, 2. warnings, and 3. crowdsourcing/crowdtasking.
1. Information: The Federal Office of Civil Protection and Disaster Assistance provides general information about disasters, incl. regarding to floods. This information is provided as short articles and downloadable brochures and includes preparedness information like checklists and concrete recommendations when disasters happen. On a state level, the state of Schleswig-Holstein provides information about likely disasters in that state, current warnings and information about contact persons. Concerning floods, the state provides maps with marked areas that are at risk of floods ([12]). Information about current waterlevels (incl. a 30-day history) are provided by “pegelonline” system. [55]. Other apps provide information on how to deal with specific problems, e. g., first aid apps that provide step-by-step instructions as text/images or videos (e. g., first aid apps like “Erste Hilfe DRK” or “ASB App Erste Hilfe im Notfall”).
2. Emergency-Warning-Apps: These apps are often offered by government departments and provide location specific information, e. g., “NINA” [6] or “WarnWetter” [58]. The position is determined by using the location function of the smartphone or via manual selection. Push notifications are used to provide the warnings. Some apps additionally provide information, e. g., NINA offers additional information and recommendations, checklists and tips. Other apps use the available official information, e. g., KATWARN [17] or BIWAPP [42]. They still keep information and warnings location specific but include different kinds of dangers (e. g., not only extreme weather events). Some apps like BIWAPP also inform users when warnings were lifted. An app with a specific focus on water levels is “MEINE PEGEL”, which is a cooperation project of multiple states [36] and provides information about current water levels. A major disadvantage of the examined apps is the low uptake, which is only 16 % of the population in Germany (e. g., NINA: 4 %, KATWARN: 6 %, [50]). Reasons for the low uptake are, among others, lack of trust in the provided information. Late warnings (a concern mentioned by interviewees ID 2 and 5) and false alarms are especially detrimental. The later can happen when the affected area is smaller than the zone for which the warning was announced. Consequently, users lose trust in the usefulness of the apps [35]. Additionally, the large time period between disasters can make disaster preparedness more difficult. One user of the App reviews thought a warning app was broken, because the last notification was long ago. However, there just were not any impending disasters in that region.
3. Crowdsourcing/Crowdtasking: The aim of apps/websites in this category is to connect voluntary helpers with those who need assistance. Apps like Hands2Help [43] allow users to register themselves as helpers and informs them if they are needed, e. g., to fill sandbags in preparation of a flood. The app “Mobile Retter” informs those who want to help about medical emergencies in their nearby environment. More general sites that facilitate mutual support are sites like FragNebenan [21] or nebenan.de [22]. They aim to connect neighbors who might not know each other, usually by providing places to post offers of and requests for help. To keep the offers and requests local, groups can be restricted by physical location of the user. Proximity matching can be used to connect users who are close-by. For example, the application Next2You [47] uses Bluetooth (with a range of max. 100 m) to connect nearby people. A similar function could be used to connect those users during a crisis which are near each other, even if they did not have an previous interaction “in real life”.
Looking at all three categories, while each category of websites/apps provides useful information on functions to prepare and cope with disasters, an app which combines these categories could not be found (e. g., combining warnings and mutual support). Given that warnings alone, without giving the user the tools to deal with the impending crisis, might spread confusion and panic, the combination of warnings with information and mutual support should be extremely useful.
Users of the App and Other Stakeholder: Any app that supports the preparation and coping with floods includes all potentially affected people as target audience. Given that these are all people living in the affected area, this target audience is highly heterogeneous. As affinity to technology interaction varies widely within a population (see, e. g., [56]), usability and universal design are high priorities for such an app. Considering that many senior citizens do frequently not possess the necessary knowledge and skills (interviews, see Section 2.1), alternative forms of reaching them must be provided. For example, more technology-oriented users can function as mediators to people who do not, cannot, or do not want to interact with an app, e. g., by downloading and distributing information from the app. Lack of devices (in general or due to power outages during a disaster) can be compensated with public displays in safe locations (e. g., with the app running in a public access mode to provide access to information and functions).
When it comes to mutual support, there is usually a high willingness to provide support. Around 70 % of respondents in a survey [18] stated that they did provide support in their neighborhood. When it comes to crisis situations, there are usually more helpers than those who need help (interviews, see Section 2.1). However, support depends on the perceived closeness between the people providing and receiving support, with those living close to a helper receiving more support from this person (e. g., both living in the same part of the town). People also have different preferences for providing support. Some people provide social support, others practical support, others both or none [18].
2.3 Requirements and Use of Smart City Information
Looking at the previous analyses, the main problems when it comes to preparing for and dealing with floods to prevent direct and indirect, tangible and intangible damages could be identified. From these problems, the requirements can be derived, esp. when smart city information — esp. sensors in the environment or on the user’s smartphone — are used to better deal with disasters. To facilitate the process, a claims analysis was used to examine the current approach on dealing with floods and determine which areas can be best covered by the app. All characteristics of the identified situations are written down together with their effects on the actor. For each situation both positive and negative effects are considered. These so-called claims are then later used to develop a design which facilitates the positive impacts and decrease the negative impacts of the current practice. For readability, after addressing general requirements of such an app, we continue to follow the time context (prior, during, after a flood).
General Requirements: The app itself must be usable even under stressful conditions, which places a strong emphasis on usability. However, due to the rare nature of floods, users might rarely open the app and thus might not be familiar with it. This can lead to further uncertainty during the crisis [33]. Thus, the app should follow well known design patterns and the user should have reason to become familiar with the app prior to the disasters. For example, the mutual support function should also be usable outside of disasters (e. g., to improve general preparedness). Navigation within the app can follow the phases of disasters themselves, i. e., prior, during, and after the disaster and focus should be on these main functions.
Given that the provided information are safety critical, messages and warnings must be provided with meta-information to assess their timeliness and trustworthiness. This includes information about the author/organization, when the information was created and last changed, reason for the change, links to sources, and the last update of the locally stored database.
To actively use smart city information, the information should be personalized to the user, using his device and locations of interest (e. g., home, office). At the same time, data privacy is an important concern (e. g., mentioned in the reviews of the examined apps, see Section 2.2, Existing Websites and Apps). Anonymous usage must be possible. If data are requested, esp. by external services like Google Maps, then these requests must be justified to the user, who must be able to reject individual requests. If possible, any sensitive information, like the location of the user, should only be stored on the device of the user itself.
Prior to a Flood: Preparation strongly influences how a crisis unfolds. All of the identified problems are also relevant during a flood as well.
General preparedness for crisis is usually neglected. For example, people usually stock up on food and other indispensable goods (like toilet paper) only when the a crisis is imminent, leading to panic buying (interviews, ID 5). Thus, information is needed about indispensable goods that can be stocked long-term, the required quantity, and why they are important to have.
Timely and relevant information to correctly estimate the danger and access to resources to prepare for the rising water levels is crucial. Especially if the users did not encounter a flood before, people can be surprised when the water levels rise strongly within a few hours and previously considered “dry” areas are now under water. In the use case of Lübeck, reports about possible storm floods usually concern only the North Sea, while Lübeck is close to the Baltic Sea, which is affected by winds from the east. This situation frequently leads to citizens being surprised by extreme weather events which are not reported by the nationwide news media (interviews, ID 5). As floods can take multiple days and affect infrastructure and access to goods, preparation can be insufficient (e. g., regarding power supply, food, drugs). Thus, information about risks and ways to prepare for floods must be provided in advance of a flood (e. g., checklists that can be used in the app to check ones level of preparedness). Information should also be integrated from multiple sources in one app and personalized to the specific situation and prior knowledge of the user (see Section 2.2, Existing Websites and Apps).
Additionally, trust in the accuracy and validity of the warnings is a crucial element. False alarms must be avoided, which can be done at least for those false alarms that arise from warnings of actual floods that did not affect the user because the warning was not specific enough (e. g., warning was at region, and not at street level). Thus, the resolution should cover the street or even house level, not only a city or county, which can also facilitate efficient mutual support. This resolution can be achieved by using smart city information from sensors recording water levels and by assessing the position of the user via their devices. If possible, warnings should take the closeness to water, water-levels and topological structure into account (addressing which areas the water can reach) to provide more accurate warnings. Similarly, late warnings impede trust in the application. Thus, the app should indicate that a connection to water level data and the source of the warnings is established. It should inform the user when timely warnings cannot be guaranteed (e. g., when new updates, incl. status updates, could not be received for some time, with the time frame varying on the current at-risk status of the area the user is in). If there is any doubt that warnings might not arrive in time, the users should be informed about that issue. This also addresses the problem that users might think the app is broken, because there were no messages for a long time, while there were no potential disasters to warn about. As the water levels vary frequently, information about the current water level from smart city sensors can be provided (incl. last update time) to show that the app works, and the displayed information is up to date. Regular information about water levels might also increase the risk awareness of the citizens and thus facilitate timely disaster preparation (ID 5).
Creating networks for mutual assistance is also crucial prior to the crisis, as the demands of the crisis itself are grave enough and starting to find help in the situation only makes matters worse. This applies especially to people who are already in danger (e. g., senior citizens) and are strongly affected by the flood. They need to rely on voluntary assistance (interviews, IDs 1 to 4). However, networks for mutual support are often only created during a crisis (interviews, IDs 1 to 4), when communication is difficult, and people might already be isolated. They might also not know which help is available or how to access it. Existing websites and apps for neighborhood support (e. g., FragNebenan [21]) were not developed for crisis situations and none of the examined crisis apps provide ways to coordinate mutual support during a crisis. Thus, available, easily accessible (e. g., nearby) help must be quickly accessible from within the app – both to request and to offer help. Proximity matching (e. g., via location information or even Bluetooth) can be used to connect nearby individuals, not only because it makes help more efficient, but also more likely. This function should also be available for relief organizations, who usually have more resources than individual citizens. Resources (e. g., manpower, sandbags, pumps, food, drugs, tools) must be used very efficiently, as they are usually in short supply and misallocation incurs a hefty price (e. g., two people need sandbags, the first gets too many and the second not enough, so second person’s cellar gets flooded). Thus, information about needed support must be specific and up to date, esp. when help is no longer needed and can be better used elsewhere. Thus, to support mutual help, the app must provide ways to offer and request help, post comments, withdraw postings, and mark them as done. Private communication channels are also needed to coordinate the help. Online groups can allow for quick communication within, e. g., the same street, while public requests should be provided with a scope (e. g., direct neighborhood, district, whole city). As users have different preferences for the kind of support they like to provide (social support, practical support, or both), users must be able to state that preference.
![Figure 1
Adaptation of the model “Responding to an Emergency: Five Step to Prosocial Behavior” [3] to the context of neighborhood help during floods.](/document/doi/10.1515/icom-2021-0016/asset/graphic/j_icom-2021-0016_fig_010.jpg)
Adaptation of the model “Responding to an Emergency: Five Step to Prosocial Behavior” [3] to the context of neighborhood help during floods.
Mutual assistance requires prosocial behavior, i. e., “a helpful action that benefits other people without necessarily providing any direct benefits to the person performing the act, and may even involve a risk for the person who helps” [3]. Prosocial behavior was widely researched in social psychology (esp. by Latané and Darley in the 1960s). A useful model of the steps needed for prosocial behavior is provided by [3] (p. 381), based on the work of Latané and Darley (see [38] for a good and still relevant overview). Applied to the context of floods (see Figure 1), the model requires for potential helpers to 1) notice the situation, 2) correctly interpreting the situation as an emergency, 3) assuming personal responsibility to help, 4) assessing one’s ability to help, and 5) deciding to act. Thus, to facilitate mutual support, users should be 1) notified about situations 2) in which people need assistance 3) for which they themselves are best suited to help and 4) have the necessary resources to help, and 5) facilitate the process to help by removing or reducing obstacles. The later includes reducing organizational overhead and making not necessarily needed information optional (cf. [14], when the motivation is low, the required behavior must be very easy to do). Given that diffusion of responsibility (“the amount of responsibility assumed by bystanders in an emergency is shared among them” [3], i. e., the more people, the less each one feels responsible to help) and the bystander effect (“the likelihood of a prosocial response to an emergency is affected by the number of bystanders who are present” [3], i. e., the more people, the lower the likelihood that someone helps) are frequent problems in prosocial behavior, care should be taken to specifically address those people who are best qualified to help. Additional aspects that determine prosocial behavior include clear information about the duration and effort required, especially how much commitment is involved [18]. Also, users should be able to specify which assistance they are willing to give and when. As reciprocity is less important for those who help, but more important for those who accept help [18], ways to reciprocate for those who accept help should be provided as well.
During a Flood: Frequently, parts of the city infrastructure break down [48], including power outages, and parts of the city become inaccessible, i. e., are enclosed by or even under water.
Power outages are a major problem for any digital solution, as they will – after the battery reserves are gone – make its use impossible. This applies both to the smartphones themselves as well as the smart city infrastructure (when large areas are affected). As the general population is insufficiently prepared for power outages [32], stop-gap measures and fallback options are needed. To reduce power consumption and extend battery life, screen brightness can be reduced. However, this requires strong visual contrasts in the app. Additionally, the principle of short-lived interactions should be applied. Connections should be kept only as long as needed and communication should be conducted via text. As a more extensive preparation to ensure a resilient infrastructure, the public displays can be equipped with a rugged power-supply. They can provide access to the system on the display itself, provide network access, and allow charging of digital devices. They should be placed in those areas in which people likely become enclosed by water yet be in positions above even high-water levels (using maps that indicate high risk areas for floods). Projects like “Katastrophen Leuchttürme” with autarkic communication systems between government agencies and those affected by the flood are steps in this direction [32]. Mutual support can also bridge the time until power is available again, when people who have power make it available to those who have not. As power might only be available in a few places, in which the app might be used by different users, the app must be able to be used in a public screen mode, in which information and access to mutual support is still possible.
Network outages are a likely consequence of a power outage but can also happen independently from it. To provide at least some basic functionality, information must be available on the app independent from network access. Functions that require network access like mutual support can be implemented via peer-to-peer networks. Additionally, public displays can serve as network nodes, esp. if they are connected with other available networks. Bluetooth, an option for proximity matching, can also be used to create Bluetooth-Mesh-Networks [31] to exchange information without active internet connection.
Both because of power outages (failing fridges and cooling units in supermarkets) and of being inaccessible due to the enclosing water, supply shortages are a common problem after about 3–4 days [32]. Consequently, mutual support of those enclosed by water (esp. sharing of food, which can be prepared or consumed without using electricity for cooking), becomes important during a flood. Resources must be used efficiently, mutual support structures must be established prior to the flood and must work during the flood.
Given the often quickly changing situation, timely information and warnings become even more important. Users should be notified as quickly as possible. While mutual assistance is desperately needed, helpers are often unfamiliar with the specific situation and its demands, including information on how to protect themselves from dangers (interviews, ID 1, 2). Thus, helpers need this information in the app and ways to exchange information during the crisis. In case of unforeseen problems and to provide information about the conditions in the affected areas, contact information for further help and disaster response are needed. Additionally, given that the smartphones can be located (and while respecting the data privacy of the users by using opt-in), a location function could be used to quickly get some information about the people still active in the disaster area (or at least of those with working smartphones).
After a Flood: Rebuilding again requires resources (incl. to remove water from cellars via pumps) and mutual support (incl. manpower). Thus, the same requirements as during the flood are in effect. Additionally, as floods are repeating events and in spirit with “an ounce of preparation is worth a pound of cure”, reflection can be used to prepare for the next flood.
To support reflection, those affected by the flood can use the event to determine what worked well and to identify possible improvements. Given that digital communication leaves traces, the data from the interactions with the app, including information about water levels, provided and received support, can be used as aide memoire. Insights from these reflections can be shared, first to help others in dangers of flood (incl. those who have not encountered a flood before) better prepare for the next flood, and second to provide the developers of the app with suggestions on how to improve its usability. Thus, the app should support users to reflect on the crisis and store their insights, both for themselves and for others.
3 Conceptual Design
Using the information from the analysis, the app was developed iteratively. Scenario based design (see Section 3.1) was used to develop the functionalities (activity design), ways the information can be presented (information design), and how users can interact with the app (interaction design). Metaphors were used in the ideation process (e. g., “seeking help from neighbors using the app” is like “posting flyers with contact data”, “asking neighbors directly”, “seeking help from volunteer organizations”) and claims analyses were implemented to assess the suitability of the designs compared to existing solutions. A formative evaluation (see Section 3.2) was conducted to get feedback from potential users (citizens of the city of Lübeck) about design and functionality. This feedback was used to improve the designs. Additionally, the final designs were evaluated on whether users had further suggestions and, as it was the basis for the actual implementation, whether the users liked the visual aesthetic of the app.
Sketches from the information design phase (left) and from the interaction design phase (right).
3.1 Scenario Based Design
Scenario-based design covers activity, information, and interaction design. Based on an analysis of the claims of the current practice, three design stages with different levels of abstraction were conducted in succession in order to facilitate the positive impacts and decrease the negative impacts of the stage before. All design processes happened in an iterative way. After a first complete design prototype had been developed, it was evaluated regarding usability and adapted again according to the previous procedure.
Activity design specifies the functions of the system. Metaphors and existing technical solutions were used to support divergent thinking. Activity scenarios and claims analyses were used to evaluate the designs. Given the identified requirements of a disaster preparedness app, the focus is on the provision of general preparedness information, notifications about dangers and water levels, and mutual support.
Provision of general information should provide information about disasters and their specific dangers to make users more risk aware, provide tutorials with concrete action steps to prepare for these dangers, ways to check one’s own level of preparedness to come to an accurate assessment, and emergency contacts. Notifications about dangers and water levels should provide current warnings (which are removed once they no longer apply) and the current water levels (for the specific places which are important for the user). Mutual support should allow users to create offers and requests for help, create and join interest groups, and exchange private messages. It should also allow users to specify the kind of support they want to provide, the area in which they are willing to help, and the time periods when they are available.
Information design aims to determine different ways to visually present the functionalities. Metaphors and activity scenarios were used to support divergent thinking and claims analyses were used to aggregate the advantages and disadvantages of the solutions. The mobile first approach was used to ensure that the designs work on all screen sizes, from smartphone to public display. Sketches were used to determine working layouts (see Figure 2, left, for the first sketches). Main criteria used during the information design were: 1. use of a common smartphone app layout to capitalize on the users’ familiarity with this type of design, 2. use the main phases of disasters as main navigation areas for easy access, 3. use a consistent layout for messages, articles and instructions, 4. use meta information like author and institution to increase trust in the information, 5. use different media in the articles to increase understanding, 6. display the current water level for the selected place on each screen as a water line with height information, 7. request information from the user, if at all, only in steps to avoid overburden the user, 8. clearly indicate new content (esp. articles on preparedness) to ensure users are always up to date, 9. if personal data is required, the user must know why it is necessary and how it is used, and 10. if data is required from the device itself (e. g., position), request for permissions to the user are only made when this data is actually needed and the reasons for the request are made transparent. For mutual support the main design criteria were: 1. message functionality (showing the personal network of contacts), neighborhood support (showing requests and offers), own postings (for quick access), and a profile (specifying which help the user is willing to provide, in which area, and when requests can be made/notifications are send), 2. clear indication which postings are offers vs requests, 3. clear indication how many people have already offered help and whether the request is still valid, and 4. information when the posting was created and when it becomes obsolete.
Interaction design was used to find ways to connect activity and information design. Interaction patters from common smartphone apps were used as basis, and metaphors and existing applications were used to facilitate ideation. Storyboards were used to capture possible interactions and claims analyses were used to evaluate the designs. Figure 2 (right side) shows examples of the interaction designs. Main criteria during inaction design were: 1. every interaction should provide feedback indicating its success or failure (via animation if it is hard to see), 2. users get informed when information change and new information becomes available, 3. users must receive warnings even when the app is closed, 4. a global menu must be available to quickly provide access to other areas in the app, 5. information about the water level, while visible in the background on every screen, must be quickly put in the foreground and augmented with more information, 6. if a lot of information is presented, search and filter options must be available to quickly find relevant information. Regarding mutual support, the main design criteria were: 1. displayed requests should be pre-filtered according to the users’ preference, but allow manual override, 2. users should be able to quickly ask for additional information to assess the required commitment, 3. offers of help to a request should immediately trigger an interaction with the person who seeks help, in order to make prosocial behavior as effortless as possible, and 4. searches and filtering should be assisted by a hidden glossary that ensures hits even when synonyms are used (e. g., users can call a “spade” a “shovel” and still find it via the search).
3.2 Formative Evaluations of the Designs
The developed concepts and sketches of an early version were assessed in a formative evaluation (sketches looked similar in style to Figure 2, left side). The focus was on assessing their usability as early as possible, and to identify and resolve possible problems (e. g., problems in interpreting the designs, missing functions, or unclear wording). To reach participants that best represent the heterogeneous user group, multiple channels were used (online platforms, social networks, paper flyers in areas at risk of floods). Given COVID-19 regulations, participants got mockups of the activity, information and interaction designs via e-mail. The evaluation itself was conducted via telephone or video conference. Participants were given a short introduction into the topic, answered the affinity for technology interaction scale (ATI, [16]), were asked for their requirements and ideas for a disaster and neighborhood help app, and evaluated the designs. Tasks were given for each design (e. g., determine the current water level, are there unread messages or articles) and think-aloud was used to assess the participants’ reactions. Participants were also asked about problems when conducting the tasks.
Five participants (four female, one male, age between 20 and 75 years) took part in the formative evaluation. ATI was close to the middle of the answer scale (
Main results of the formative evaluation were that the navigation within the app was clear to the participants, and user requirements mentioned by the participants largely matched the previously identified requirements. However, the water level in the background of the app should be better visible. Also, that the displayed water level applies to the location the user has selected should be clearer, and the option to select multiple locations should be provided (e. g., home, office, car, living places of relatives or other people). While information and checklists to assess their level of preparedness was seen as helpful, participants needed more information to correctly interpret the results.
The designs were adapted based on the feedback of the formative evaluation. To assess the app design again and evaluate the visual aesthetic of the designs, mockups were created. They served as the basis for a short video of the interaction of a user with the app (https://www.youtube.com/watch?v=Jf5miatpC1g) and were presented in an online questionnaire. Visual aesthetics, using the Visual Aesthetics of Websites Inventory questionnaire (VisAWI, [45]), was assessed as strong contrasts were used (to allow the use of the app with low display brightness in order to save power), yet the app should still be appealing to use. The link to the questionnaire was distributed via social networks and student mailing lists and was accessed 119 times, of which 73 answered could be used. For the VisAWI (ranging from 1, negative, to 7, positive), the total score was 5.15 (
4 Implementation
Using the designs from the conceptual phase and the identified requirements (see Section 2.3), the main features of the app were developed. To ensure its use on a wide variety of devices, the app was implemented as a progressive web app (PWA). It combines the functions of a web application, but also supports device functions like push notifications and offline use (cf. risk of network outages during floods). Given that the app should be usable both as a personal app and as an app for public displays, and to avoid parallel development of two apps, a PIN-protected setting is available to secure personal information and allow its use by different users. This way, every user can make his device available for others if needed.
Software packages were selected based on being open-source software or freely usable software, as well as being compatible with current web standards. The backend required only a few data structures to save information and warnings, thus JSON could be used to store simple hierarchical structures. This decision in turn required a document-oriented database system. Given its wide availability and its fit, mongoDB [44] was chosen. For middleware, compatibility with JavaScript was required to work with a PWA. Given its popularity, extensibility, and its usability on different platforms, nodeJS [15] in combination the Mongoose extension and the web framework express.js [52] were selected. Firebase [26] was used to send push notifications. For the frontend (PWA), due to its offline functionality and access to native system functions, vue.js [59] was used. It was extended with the cli-plugin-pwa plugin (to create the PWA functionality) and the Vuetify library [54] (to adhere to a commonly known smartphone app design to capitalize on the prior experience of the users).
When the user specifies a location, the coordinates are determined using the freely available web service Nominatim [28]. Opentopodata.org [46] is then used to determine the elevation level of these coordinates. It uses the elevation model EU-DEM25 with a vertical accuracy of ± 7 meters. While the error of measurement is high, it is currently the most accurate freely available model. In future iterations, users could enter the exact elevation level manually, if they have other means of accessing it (incl. using observed water levels as a guide). This elevation level data could then be made available to people living in the same area. Additionally, backup services could be implemented if the used services are not available. The location information is used to determine all water level sensors within 30 km using pegelonline [55] (see Section 2.2, Existing Websites and Apps) and select the closest station. Using distance as a criterion for the selected station might be off in some situations (e. g., if a location is close to two bodies of water, which are separated by a high elevation, and the water level information comes from the wrong body of water). However, it should provide accurate data in most cases and provide the user with up-to-date water-level information close to his property. If the selected station is not currently used by any user, then it is added to the database. If a location is removed, the water level sensor associated with this location is checked. If there are no other users who get information from this station, then it is removed from the database. Thus, only sensors that are currently requested by users are monitored. If the high-water mark is reached, users who subscribed to that station get informed about it via a push notification.
Figure 3 shows screenshots of the different views of the app. Videos of the interaction with the app (without mutual support functionality) are available at https://www.youtube.com/watch?v=0cARlY_H9_Q and https://www.youtube.com/watch?v=cWOn893fNAk (public display mode).
Screenshots of different views of the app (see image for details).
5 Summative Evaluation
To evaluate the implemented app and gain further insights on how to use smart city data and citizen participation to increase disaster resilience, a summative evaluation was conducted both for the base version of the app and the extended version with mutual support functionality. The focus was on assessing usability, possible ambiguous or unclear design elements, and to identify missing information or functionality. The later informs which further smart city information would be needed to improve the app.
5.1 Method
To evaluate the app under COVID-19 restrictions, remote usability tests were conducted either via telephone or videoconferencing tools (with screen sharing).
Participants were informed about the purpose of the app. For both tests, they provided demographic data, and filled in the affinity for technology interaction scale [16] and the VisAWI scale [45], and had some time to get acquainted with the app. Then they had to perform tasks like determining the water level in specified places, find out whether new information was available, or assess their degree of preparedness. For the base version, the System Usability Scale [4] was used to get an overall usability measure, Think Aloud to better understand the user’s behavior, and an open interview was conducted to get further information about the user’s evaluation of the app. For the version with mutual support functionality, screen sharing was used to detect interaction problems and more detailed questions about the new functions were asked.
Participants were recruited in local forums and on social networks. For the base version, six participants (three male, three female, four 18–35 years, one 35–65 years, and one >65 years) took part. Their ATI values ranged from 3.1 to 5.5 (
5.2 Results
Regarding usability, the average SUS score of the base app is 85.42 (
Users mentioned the following issues and requested additional functions/information for the base app (main issues only, brackets show the number of participants who mentioned the same issue):
Structure: If a new location is selected, user should immediately be shown the water level (
Functions and Information: Predictions and history of the water level (
Visualization: Currently selected location should always be visible (
For the mutual support functionality, on a scale of 1 (very negative) to 7 (very positive) participants rated whether they were satisfied with its functions with
5.3 Discussion
Participants of both evaluations were quickly able to use the app. It was easily understood and behaved in predictable ways.
In the evaluation of the base version, usability (SUS-Score) was high, even for participants who gave the lowest rating. Given affinity for technology interaction of the participants was rather high, it raises the question whether this positive result can also be achieved for users who do not like to interact with technology (cf. [56]). However, suggestions for improvement can be used to further increase its usability. Except for not immediately knowing for which location the water level is shown (if more than one location was entered by the user), the suggestions are not critical issues. Overall, the app was rated as usable and useful. Similar results were found for the evaluation of the extended version with mutual support functionality, which participants rated as useful.
Visual aesthetics was also high for both iterations of the app. It was seen as professional and trustworthy, despite selecting colors with high contrast to allow its use with low display brightness in case of power outages.
6 General Discussion and Conclusion
To determine how smart city data and citizen participation can be combined to increase disaster resilience, we conducted a user-centered design process to develop an app that uses smart city information – mainly available water level sensors – and a mutual support functionality to assist users to better prepare and cope with floods.
Literature research, expert interviews, and examination of existing apps and websites provided useful information to determine the requirements of the app. They also highlighted the need for up-to-date, location specific information (on a house or street level, not a region level) that smart city sensors can provide. During the conceptual design phase, the information was used in combination with scenario-based design to determine functionality, information visualization and interaction. The designs were evaluated in a formative evaluation and implemented using open-source and other freely available technologies. Summative evaluations were conducted to assess the usability of the app, both of the first version and an extended version that provides mutual support functionality. Usability was high and despite choosing a design with strong contrasts that can be used with low display brightness (to conserve power in case of a power outage), the visual aesthetics of the app were rated positively.
The user-centered design process did show that to be both usable and able to function during disaster conditions, a smart city application must be designed to provide the user with personalized information which the user controls. This personalization includes the warnings that apply specifically to the user’s location(s), not to whole districts or regions, which also reduces the number of false alarms (incl. if a flood happens in the region, but the user’s property is not affected). It also should take the personal situation of the user into account. This includes prior knowledge and preparedness, e. g., by using individualized checklists, and risk assessment, e. g., which water levels the user considers as threatening (set own limits for water levels that trigger notifications). Given the rare occurrence of floods in combination with their potentially devastating effects, push notifications should be used to warn the user. A crucial aspect when using smart city information is the digital infrastructure (power and network access), which can be affected during floods. Thus, power should be conserved as much as possible and fallback options should be considered, e. g., public displays with power reserves and robust network connections. A bottom-up strategy to cope with network outages is the use of ad-hoc peer-to-peer networks to exchange information locally. Information must also be available on the app itself to still be available if network access is lost. Also, users must be informed if functions are no longer available and which fallback options are available.
Regarding the smart city information that can be used for a crisis-support app, the main data sources used in the app came from a tightly knit network of water level sensors. Sensors that assess rainfall or wind can provide additional information that improve accurate prediction of floods. For some kinds of floods (e. g., heavy rainfall/melting snow up-river) the best data for prediction likely comes from sensors some kilometers upstream (in cases of backed-up water or storm floods even somewhat downstream). If the whole stream is tracked via sensors, showing the rising water levels along the stream might be highly useful as well (esp. over time). Despite being well-suited for predictions, given the need to personalized information to protect one’s personal property, users should be able to continue to get information about the water levels closed to their properties, as it is currently implemented in the app. The water level information must be put in context with elevation models that take into account the areas the flood water can reach, and which areas are safe as they are high enough or enclosed by higher elevations. Previously captured senor data or maps showing areas at risk of floods based on prior floods can be used. This information shows not only areas in which property and lives are in danger, but also indicates possible escape routes and places in which public displays can be erected. Other geospatial data (e. g., places at which sandbags or other resources are available) can also be provided. To increase trustworthiness, sensor data should be annotated with meta information (e. g., source, last update).
When it comes to increasing the likelihood of mutual local support, building networks for mutual assistance prior the crisis is crucial. During the crisis, prosocial behavior can be facilitated by allowing users to choose the manner and timeframe of the help they want to provide, clarifying the involved commitment. The “Five Step to Prosocial Behavior” model [3] is extremely useful to increase the likelihood that people will help. Users should be informed of a precarious situation, showing that assistance is (still) needed, that they are best suited to help (or even the only one), and obstacles that might hinder the decision to help should be removed as far as possible (see Figure 1). This process relies on provided information (which help is needed by one user, which help is another user willing to provide) and physical closeness of both users (determined by localization features of the smartphone or provided by the users). The mutual support functionality should make this process more likely.
The usability of the app can be further increased both by a more resilient infrastructure and by improvements of the app. While suggestions to improve the resilience of the smart city disaster app were made (e. g., using public displays to provide access to the system in case users cannot use their own devices due to lack of power or lack of network access), its implementation and evaluation is beyond the scope of the present paper. However, first projects exist and the app itself can already be used in a public display mode. The app itself can be improved by adding additional sources of warnings (e. g., using MoWaS [9]), adding offline data exchange and ad-hoc network functionality (e. g., via Bluetooth), using improved elevation models to increase accuracy (e. g., ESA Copernicus data), allowing for manual correction of the elevation data in the app based on reported water levels or other sources, automatic selection of water level sensors based on the best prediction of water levels at the selected locations, adding additional sensors (incl. other types of sensors which increase prediction), automatic energy save mode, using the current risk to change update frequency of water levels, and adding additional information to better prepare for disasters (incl. using reflection to learn from each flood and provide these insights to other users, esp. those living nearby).
However, questions remain regarding the performance of the app in actual disasters. It is also an open question whether app reduces panic behavior, or whether, e. g., the mutual support functionality becomes a vector by which panic could spread when many people send urgent calls for assistance.
Of possible disasters, and despite the risk to the digital infrastructure that would also affect a smart city disaster app, floods are well-suited to be dealt with by a such an app. Sensors are available that provide information about water levels that allow prediction of floods in advance (time frame and affected areas). Available maps show areas that are at risk. Preparation is possible to both protect property and lives (e. g., using sandbags and pumps, or evacuating people, livestock, equipment) and cope with the crisis (e. g., stocking up on foods and drugs). Mutual support can be provided (e. g., manpower, resources) and the main danger is the (flooded/damaged) environment once the flood happens. There is, in contrast to pandemics, usually little danger from the interaction itself (unless social order breaks down and looting starts). However, some if not all aspects of this smart city disaster app should be applicable to other crises as well.
Thus, the present app with the city of Lübeck as a use case can serve as a proof of concept of a user-centered design process that uses smart city data and citizen participation to better prepare users for disasters and help them cope with them.
About the authors
Daniel Wessel (PhD in Psychology) is a postdoctoral researcher at the Institute for Multimedia and Interactive Systems (IMIS) of the University of Lubeck. His research interests include mobile media, evaluation, e-government, smart cities, and in general the interaction between psychology and digital technology.
Julien Holtz (M. Sc. in Media Informatics) is a software engineer at UXMA GmbH in Kiel. His research interests include mobile development, web development, and HCI in the field of disaster management.
Florian König is a researcher at the Institute for Multimedia and Interactive Systems (IMIS) of the University of Lubeck. His research areas include user-centered design, e-government, smart cities, modern web technologies, mobile augmented reality systems, e-participation, and e-learning systems.
Acknowledgment
This paper is based on the master thesis of the second author and a supervised bachelor project by the first and third author. We like to thank the project members Wiebke Lutz, Julia Richter, and Paul Siraf who developed the mutual support functionality for the app. We also like to thank all participants who evaluated the application and the anonymous reviewer who provided fair and useful feedback. Thank you very much.
References
[1] Inc ACM. ACM Digital Library. https://dl.acm.org, 2020.Search in Google Scholar
[2] Aaron Bangor, Philip Kortum, and James Miller. Determining what individual SUS scores mean: Adding an adjective rating scale. Usability Studies, 4(3):114–123, 2009. ISSN 1469493X. 10.1002/14651858.CD012733.pub2.Search in Google Scholar PubMed PubMed Central
[3] Robert A. Baron, Donn Byrne, and Nyla R. Branscombe. Social Psychology. Pearson Education, Inc., Boston, MA, eleventh edition, 2006.Search in Google Scholar
[4] J. Brooke. SUS – A quick and dirty usability scale. In Usability Evaluation in Industry, pages 189–194. Taylor and Francis, London, 1996.Search in Google Scholar
[5] Bundesamt für Bevölkerungsschutz (Deutschland). NINA – Die Warn-App des BBK. https://play.google.com/store/apps/details?id=de.materna.bbk.mobile.app&hl=de&gl=US, 2020.Search in Google Scholar
[6] Bundesamt für Bevölkerungsschutz und Katastrophenhilfe. Warn-App NINA. https://www.bbk.bund.de/DE/NINA/Warn-App_NINA.html, May 2020.Search in Google Scholar
[7] Bundesamt für Bevölkerungsschutz und Katastrophenhilfe. Warnung der Bevölkerung. https://www.bbk.bund.de/DE/AufgabenundAusstattung/Krisenmanagement/WarnungderBevoelkerung/WarnungderBevoelkerung_einstieg.html, May 2020.Search in Google Scholar
[8] Bundesamt für Bevölkerungsschutz und Katastrophenhilfe. https://www.bbk.bund.de, 2020.Search in Google Scholar
[9] Bundesamt für Bevölkerungsschutz und Katastrophenhilfe. Das Modulare Warnsystem. https://kurzelinks.de/ielz, 2020.Search in Google Scholar
[10] Bundesamt für Seeschifffahrt und Hydrographie. https://www.bsh.de, 2020.Search in Google Scholar
[11] Bundesministerium des Innern. Leitfaden Krisenkommunikation. Technical report, 2014.Search in Google Scholar
[12] Der Ministerpräsident des Landes Schleswig-Holstein mit der Staatskanzlei. ZeBIS. http://zebis.landsh.de/webauswertung/pages/home/welcome.xhtml, May 2020.Search in Google Scholar
[13] DIN EN ISO 9241-210. Ergonomie der Mensch-System-Interaktion – Teil 210: Menschzentrierte Gestaltung Interaktiver Systeme. Beuth, Berlin, 2020.Search in Google Scholar
[14] B.J. Fogg. A behavior model for persuasive design. In Proceedings of the 4th International Conference on Persuasive Technology (Persuasive ’09), 2009. ISBN 978-1-60558-376-1. 10.1145/1541948.1541999.Search in Google Scholar
[15] OpenJS Foundation. nodeJS. https://nodejs.org/en, 2020.Search in Google Scholar
[16] Thomas Franke, Christiane Attig, and Daniel Wessel. A Personal Resource for Technology Interaction: Development and Validation of the Affinity for Technology Interaction (ATI) Scale. International Journal of Human–Computer Interaction, 35(6):456–467, 2019. 10.1080/10447318.2018.1456150.Search in Google Scholar
[17] Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS. KATWARN. https://katwarn.de, May 2020.Search in Google Scholar
[18] Sabine Fromm and Doris Rosenkranz. Unterstützung in Der Nachbarschaft. Springer Fachmedien Wiesbaden GmbH, Wiesbaden, 2019. ISBN 978-3-658-22322-9.Search in Google Scholar
[19] Gesellschaft für Informatik e.V. Digital Library. https://dl.gi.de, 2020.Search in Google Scholar
[20] CombiRisk GmbH. KATWARN. https://play.google.com/store/apps/details?id=de.combirisk.katwarn, 2020.Search in Google Scholar
[21] FragNebenan GmbH. FragNebenan – Das Netzwerk für gute Nachbarschaft. https://fragnebenan.com, May 2020.Search in Google Scholar
[22] Good Hood GmbH. Nebenan.de. http://nebenan.de, 2020.Search in Google Scholar
[23] Konradin Medien GmbH. So gefährdet Hochwasser Mensch und Umwelt. https://www.wissen.de/wie-hochwasserentsteht, May 2020.Search in Google Scholar
[24] Google. Google Scholar. https://scholar.google.de, 2020.Search in Google Scholar
[25] Google. Google Play Store. https://play.google.com/store, 2020.Search in Google Scholar
[26] Google. Firebase. https://firebase.google.com/?hl=de, 2020.Search in Google Scholar
[27] Michael Herczeg. Software-Ergonomie. De Gruyter Oldenbourg, 4., erw. edition, 2018. ISBN 978-3-11-044685-2.Search in Google Scholar
[28] Sarah Hoffmann. Nominatim. https://nominatim.org/, 2020.Search in Google Scholar
[29] hydro&meteo GmbH. Projekt-i-quadrat. https://www.projekt-i-quadrat.de, May 2020.Search in Google Scholar
[30] Apple Inc. App Store. https://apps.apple.com, 2020.Search in Google Scholar
[31] Bridgefy Inc. Use-Cases. https://bridgefy.me/use-cases/, August 2020.Search in Google Scholar
[32] Sabina Kaczmarek, Frieder Kircher, Patrik Bohne, Richard Nagel, Holger Barsuhn, Cornelia Lawrenz, Martin Surma, Eva Dittes, Claudius Ohder, Birgitta Sticher, Hans-Peter von Stoephasius, Sarah Geißler, Benedikt Schweer, and Ingo Schwenzien. Katastrophenschutz-Leuchttürme. Technical report, Berlin, 2015. URL https://www.berliner-feuerwehr.de/fileadmin/bfw/dokumente/Forschung/Katschutz-Leuchttuerme/LBD_Pro_KatLeuchttuerme_Schlussbericht_BFw.pdf.Search in Google Scholar
[33] Inga Karl, Kristian Rother, and Simon Nestler. Begleiter und Helfer in der Not – Apps für Krisen und Gefahrenlagen. In Mensch und Computer 2015 – Workshop, pages 29–36, 2015. 10.1515/9783110443905-005.Search in Google Scholar
[34] Milou Kievik and Jan M. Gutteling. Yes, we can: Motivate Dutch citizens to engage in self-protective behavior with regard to flood risks. Natural Hazards, 59(3):1475–1490, 2011. ISSN 0921030X. 10.1007/s11069-011-9845-1.Search in Google Scholar
[35] Christoph Kotthaus, Thomas Ludwig, and Volkmar Pipek. Toward persuasive design for emergencies: Pointing citizens in the right direction. In International Reports on Socio-Informatics (IRSI), Proceedings of the CHI 2016 – Workshop: Crowd Dynamics: Exploring Conflicts and Contradictions in Crowdsourcing, 13(2):41–52, 2016.Search in Google Scholar
[36] Landesanstalt für Umwelt Baden-Württemberg. Meine Pegel. https://www.hochwasserzentralen.info/meinepegel/index.html, October 2020.Search in Google Scholar
[37] Landesportal Schleswig-Holstein. https://www.schleswig-holstein.de, 2020.Search in Google Scholar
[38] Bibb Latané and John M. Darley. The Unresponsive Bystander: Why Doesn’t He Help? Appleton-Century-Crofts, New York, 1970.Search in Google Scholar
[39] Hansestadt Lübeck. https://www.luebeck.de, 2020.Search in Google Scholar
[40] Zentrale Hochschulbibliothek Lübeck. https://www.zhb.uni-luebeck.de, 2020.Search in Google Scholar
[41] Marktplatz GmbH – Agentur für Web & App. BIWAPP. https://play.google.com/store/apps/details?id=de.mplg.biwapp, 2020.Search in Google Scholar
[42] Marktplatz GmbH – Agentur für Web & App. BIWAPP – die App zur Warnung und Information der Bevölkerung. https://www.biwapp.de, May 2020.Search in Google Scholar
[43] Martin-Luther-Universität Halle-Wittenberg. Hands2Help. https://www.uni-halle.de/uzi/arbeitskreise/repit/repitprojekte/h2h, 2020.Search in Google Scholar
[44] Inc. MongoDB. MongoDB. https://www.mongodb.com/2, 2020.Search in Google Scholar
[45] M. Moshagen and M.T. Thielsch. Facets of visual aesthetics. International Journal of Human-Computer Studies, 68: 689–709, 2010.10.1016/j.ijhcs.2010.05.006Search in Google Scholar
[46] Andrew Nisbet. Open Topo Data. https://github.com/ajnisbet/opentopodata/, 2020.Search in Google Scholar
[47] Susanna Paasovaara, Ekaterina Olshannikova, Pradthana Jarusriboonchai, Aris Malapaschas, and Thomas Olsson. Next2You: A proximity-based social application aiming to encourage interaction between nearby people. In Proceedings of the 15th International Conference on Mobile and Ubiquitous Multimedia, MUM ’16, pages 81–90, Association for Computing Machinery, New York, NY, USA, 2016. ISBN 978-1-4503-4860-7. 10.1145/3012709.3012742.Search in Google Scholar
[48] Heinz Patt and Robert Jüpner. Hochwasser-Handbuch. Springer Vieweg, Wiesbaden, 3. edition, 2020. ISBN 978-3-65826742-1.10.1007/978-3-658-26743-8_1Search in Google Scholar
[49] Britta Renner and Martina Gamp. Krisen- und Risikokommunikation. Pravention und Gesundheitsforderung, 9(3):230–238, 2014. ISSN 18616763. 10.1007/s11553-014-0456-z.Search in Google Scholar
[50] Christian Reuter, Marc-André Kaufhold, Thomas Spielhofer, and Anna Sophie Hahne. Soziale Medien und Apps in Notsituationen: Eine repräsentative Studie über die Wahrnehmung in Deutschland. BBK Bevölkerungsschutz, 53(9):22–24, 2018. ISSN 1098-6596. 10.1017/CBO9781107415324.004.Search in Google Scholar
[51] Mary Beth Rosson and John Carroll. Usability Engineering: Scenario-Based Development of Human-Computer Interaction. Academic Press, San Francisco, 2002.10.1016/B978-155860712-5/50002-3Search in Google Scholar
[52] Inc. StrongLoop. Expressjs. https://expressjs.com/de/, 2020.Search in Google Scholar
[53] Anthony M. Townsend. Smart Cities: Big Data, Civic Hackers, and the Quest for a New Utopia. Norton & Company, New York, 2013.Search in Google Scholar
[54] Vuetify. https://vuetifyjs.com/en/, 2020.Search in Google Scholar
[55] Wasserstraßen- und Schifffahrtsverwaltung des Bundes. PEGELONLINE. https://www.pegelonline.wsv.de/gast/start, October 2020.Search in Google Scholar
[56] Daniel Wessel, Moreen Heine, Christiane Attig, and Thomas Franke. Affinity for technology interaction and fields of study: Implications for human-centered design of applications for public administration. In Proceedings of the Conference on Mensch Und Computer, pages 383–386. Association for Computing Machinery, New York, NY, USA, 2020. ISBN 978-1-4503-7540-5.Search in Google Scholar
[57] Deutscher Wetterdienst. Deutscher Wetterdienst. https://www.dwd.de, 2020.Search in Google Scholar
[58] Deutscher Wetterdienst. Die Warnwetter App. https://www.dwd.de/DE/service/dwd-apps/dwdapps_node.html, 2020.Search in Google Scholar
[59] Evan You. Vue.js. https://vuejs.org/, 2020.Search in Google Scholar
© 2021 Walter de Gruyter GmbH, Berlin/Boston
