University of Southern California Dissertations and Theses

Designing an earthquake preparedness web mapping application for the older adult population of Los Angeles, California

(USC Thesis Other)

Designing an earthquake preparedness web mapping application for the older adult population of Los Angeles, California

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content

Designing an Earthquake Preparedness Web Mapping Application for the Older Adult Population of Los
Angeles, California

by

Brian Everitt

A Thesis Presented to the
Faculty of the USC Graduate School
University of Southern California
In Partial Fulfillment of the
Requirements for the Degree
Master of Science
(Geographic Information Science and Technology)

August 2019

ii

Copyright © 2019 by Brian Everitt

iii

To my wife and family for their patience and support during the process of this project.

iv
Table of Contents
List of Figures .............................................................................................................................. viii
List of Tables ................................................................................................................................ xii
Acknowledgments........................................................................................................................ xiii
List of Abbreviations ................................................................................................................... xiv
Abstract ......................................................................................................................................... xv
Chapter 1 Introduction .................................................................................................................... 1
1.1. Motivation ...........................................................................................................................2
1.1.1. Older Adults and Disasters ........................................................................................2
1.1.2. Older Adults and Web Design ...................................................................................6
1.2. Study Area ..........................................................................................................................9
1.3. Application Description ....................................................................................................11
1.4. Thesis Structure ................................................................................................................12
Chapter 2 Related Work ................................................................................................................ 13
2.1. Application Design for Older Adult Users .......................................................................13
2.2. UX and UI Web Mapping Design for the Older Adult Population ..................................15
2.3. Web Mapping Applications for Earthquakes and Other Disasters ...................................17
2.4. VGI and Crowdsourced Information for Disasters ...........................................................21
Chapter 3 Application Requirements ............................................................................................ 24
3.1. Application Interface Design Requirements .....................................................................24
3.2. Mapping Application Interaction Functionality Requirements ........................................26
3.3. Map Design Requirements ................................................................................................28
3.4. Map Content Requirements ..............................................................................................29
3.4.1. Earthquake-Related Layer Requirements ................................................................30
3.4.2. Shelters Layer Requirements ...................................................................................30
v
3.4.3. Emergency Services Layer Requirements ...............................................................31
3.4.4. Requirements for Preparation Needs Assistance Request Layer .............................31
3.4.5. Requirements for Senior Reference Layers .............................................................32
3.5. Software Requirements .....................................................................................................32
Chapter 4 Software, Data, and Base Application Development ................................................... 34
4.1. Software ............................................................................................................................34
4.1.1. Esri For Desktop ......................................................................................................34
4.1.2. REST Services .........................................................................................................35
4.1.3. AGOL WebMaps .....................................................................................................35
4.1.4. AGOL Web AppBuilder ..........................................................................................35
4.1.5. Web AppBuilder Developer Edition ........................................................................36
4.1.6. Esri Efficiency .........................................................................................................37
4.1.7. Code and File Customization Software ...................................................................37
4.2. Data Sets, Sources, and Preparation .................................................................................37
4.2.1. Shelter Data ..............................................................................................................38
4.2.2. Earthquake-Related Data .........................................................................................39
4.2.3. Emergency Service Layers ......................................................................................40
4.2.4. Senior Reference Layers ..........................................................................................40
4.3. VGI Layer Preparation ......................................................................................................40
4.4. Customizing the Map Background ...................................................................................41
4.5. Map Creation ....................................................................................................................44
4.5.1. Adding Layers to the AGOL Map ...........................................................................45
4.5.2. Symbology ...............................................................................................................45
4.5.3. Setting Layer Pop-Ups .............................................................................................49
4.6. Base Application Creation in Web AppBuilder ................................................................50
vi
Chapter 5 Application Customization ........................................................................................... 55
5.1. Preparing for Customization .............................................................................................55
5.2. Customization of Application ...........................................................................................64
5.2.1. Updating the Application Title and Title Bar ..........................................................64
5.2.2. Customizing Widget Button Sizes on the Dart Controller .......................................67
5.2.3. Customizing the Widget Panel.................................................................................72
5.2.4. Customizing the Legend Widget .............................................................................76
5.2.5. Customizing the Turn On/Off Layers Widget .........................................................78
5.2.6. Customizing the Nearest Widgets ............................................................................82
Chapter 6 Results .......................................................................................................................... 86
6.1. Final Application Design and Use Examples ...................................................................86
6.1.1. Final Application Information Widget Display .......................................................88
6.1.2. Example of Zoom Slider, Home, and Location Widgets. ........................................89
6.1.3. Turn On/Off Layers Widget Use .............................................................................91
6.1.4. Identify Layers with the Legend and Pop-up Box ...................................................94
6.1.5. Using the Print Widget.............................................................................................95
6.1.6. Using the Add Assistance Request Point Widget ....................................................97
6.1.7. Using Nearest Shelters Widget ................................................................................98
6.2. Training Materials ...........................................................................................................100
6.3. Application Test and Results ..........................................................................................101
6.3.1. Application Testing ................................................................................................101
6.3.2. Comments and Observations .................................................................................102
6.3.3. Survey Design ........................................................................................................103
6.3.4. Survey Responses ..................................................................................................106
6.3.5. Section Two ...........................................................................................................108
vii
6.3.6. Survey Section Three .............................................................................................110
Chapter 7 Conclusions ................................................................................................................ 111
7.1. Issues with Data and Software ........................................................................................111
7.1.1. Data Issues .............................................................................................................111
7.1.2. Software Issues ......................................................................................................112
7.2. Application Results Discussion ......................................................................................113
7.2.1. Application Accessibility .......................................................................................114
7.2.2. Application Training ..............................................................................................114
7.2.3. Application and Map Terminology Issues .............................................................115
7.2.4. Text Size Issues ......................................................................................................115
7.2.5. Map Layer Issues ...................................................................................................116
7.2.6. Button Design Issues..............................................................................................118
7.2.7. Device Design Issues .............................................................................................118
7.3. Future Research and Development .................................................................................120
7.3.1. Future UI/UX research ...........................................................................................120
7.3.2. Future Software Research ......................................................................................121
7.3.3. Future Hardware Research .....................................................................................122
7.3.4. Other Applications .................................................................................................122
7.4. Conclusions .....................................................................................................................123
References ................................................................................................................................... 124
Appendix A ................................................................................................................................. 126

viii
List of Figures
Figure 1. Anticipated Increase of Older Adult Population in California ........................................ 4
Figure 2. Study Area of Los Angeles ............................................................................................ 10
Figure 3. California Earthquake Probability ................................................................................. 10
Figure 4. Preparation Needs Assistance Request Point Domains ................................................. 41
Figure 5. Screenshot of Non-Customized Esri Base Map ............................................................ 42
Figure 6. Tile Style Editor ............................................................................................................ 43
Figure 7. Screenshot of Customized Base Map ............................................................................ 44
Figure 8. Shelter Symbology ........................................................................................................ 46
Figure 9. Emergency Service Symbols ......................................................................................... 46
Figure 10. Earthquake Hazard Symbols ....................................................................................... 47
Figure 11. Screenshot of Earthquake Hazards Map ...................................................................... 48
Figure 12. Senior Reference Layer Symbols ................................................................................ 49
Figure 13. Shelter Pop-Up Code ................................................................................................... 50
Figure 14. Dart Theme Layout ...................................................................................................... 51
Figure 15. Web AppBuilder Theme and Style .............................................................................. 52
Figure 16. Widget Chooser Panel ................................................................................................. 53
Figure 17. AGOL Web AppBuilder Base Application ................................................................. 54
Figure 18. Web AppBuilder Developer Folder Structure ............................................................. 57
Figure 19. Web AppBuilder Developer Edition Window ............................................................ 58
Figure 20. Code Downloaded Directly from AGOL to Local Computer ..................................... 59
Figure 21. Code Downloaded to Local Computer Via Web AppBuilder Developer ................... 59
Figure 22. Unzipped Folder Structure .......................................................................................... 60
ix
Figure 23. Application Folder Structure ....................................................................................... 61
Figure 24. Theme Folder ............................................................................................................... 61
Figure 25. Widget Folder .............................................................................................................. 62
Figure 26. Application ID ............................................................................................................. 63
Figure 27. Inspection Tools .......................................................................................................... 64
Figure 28. Controller Bar Non-Customized.................................................................................. 65
Figure 29. Dart Controller Title and Box Code ............................................................................ 66
Figure 30. Dart Controller Box Code Changes ............................................................................. 66
Figure 31. Icon Node Image Code ................................................................................................ 68
Figure 32. Icon Node Code ........................................................................................................... 68
Figure 33. Dart Controller Widget JavaScript Code ..................................................................... 68
Figure 34. Location Widget Button CSS ...................................................................................... 69
Figure 35. Image Size Change ...................................................................................................... 69
Figure 36. Dart Controller Tools Box ........................................................................................... 70
Figure 37. Zoom Slider Changes .................................................................................................. 70
Figure 38. Ellipsis Collapse Changes ........................................................................................... 71
Figure 39. Customized Controller Bar .......................................................................................... 71
Figure 40. Customized Bar on Mobile Device ............................................................................. 72
Figure 41. Widget Panel Before Customization ........................................................................... 73
Figure 42. Minimize and Close Icon Changes .............................................................................. 74
Figure 43: Widget Panel Title Style Code .................................................................................... 74
Figure 44. Changes to Panel Widget Handle ................................................................................ 75
Figure 45. Widget Panel Content Text Size.................................................................................. 75
x
Figure 46. Widget Panel Content Text Color ............................................................................... 76
Figure 47. Dart Panel Background ................................................................................................ 76
Figure 48. The Legend Before ...................................................................................................... 77
Figure 49. Legend Font Style Code Change ................................................................................. 77
Figure 50. Legend After ................................................................................................................ 78
Figure 51. Turn On/Off Layers Widget Before ............................................................................ 79
Figure 52. Layer List Title Code ................................................................................................... 80
Figure 53. Layer List Content Text Size Code ............................................................................. 80
Figure 54. Checkbox Size Change ................................................................................................ 81
Figure 55. Checkbox Background Color Change ......................................................................... 81
Figure 56. Turn On/Off Layer Widget After ................................................................................ 82
Figure 57. Nearest Shelters Widget Before .................................................................................. 83
Figure 58. Nearest Widget Balloon Code ..................................................................................... 84
Figure 59. Nearest Shelters Widget After ..................................................................................... 85
Figure 60. Final Application Home Page ..................................................................................... 87
Figure 61. Final Application Mobile ............................................................................................ 87
Figure 62. Application Information Widget ................................................................................. 88
Figure 63. Zoom Slider Widget .................................................................................................... 89
Figure 64. Zoomed in Map ........................................................................................................... 89
Figure 65. Zoomed to Device Location ........................................................................................ 90
Figure 66. Default Map Extent ..................................................................................................... 90
Figure 67. Home Button ............................................................................................................... 90
Figure 68. Turn On/Off Layers Widget Button ............................................................................ 91
xi
Figure 69. Layers Greyed Out ...................................................................................................... 92
Figure 70. Layers Displayed Bold ................................................................................................ 92
Figure 71. Hospitals Off ............................................................................................................... 93
Figure 72. Hospitals On ................................................................................................................ 93
Figure 73. Close Button ................................................................................................................ 93
Figure 74. Legend Widget Button ................................................................................................ 94
Figure 75. Legend and Map Comparison ..................................................................................... 94
Figure 76. Pop-up Activated ......................................................................................................... 95
Figure 77. Print Widget Button Icon ............................................................................................. 95
Figure 78. Setting Print Parameters .............................................................................................. 96
Figure 79. Map Print Output ......................................................................................................... 96
Figure 80 Add Assistance Request Point Widget Button Icon ..................................................... 97
Figure 81. Add Assistance Request Point Picker.......................................................................... 97
Figure 82. Adding Assistance Request Point to the Map ............................................................. 98
Figure 83. Nearest Shelters Button Icon ....................................................................................... 98
Figure 84. Nearest Shelters Widget Panel .................................................................................... 99
Figure 85. Activating Map Picker ................................................................................................. 99
Figure 86. Nearest Shelters Map Pick......................................................................................... 100
Figure 87. Nearest Shelter........................................................................................................... 100
Figure 88. Verbal Comments and Observation Notes ................................................................ 103
Figure 89. Survey Questions Section 1 ....................................................................................... 104
Figure 90. Survey Questions Section 2 ....................................................................................... 105
Figure 91. Survey Questions Section 3 ....................................................................................... 106
xii

List of Tables
Table 1. Data Sets and Data Sources ............................................................................................ 38
Table 2 Survey Section One Question Responses ...................................................................... 108
Table 3. Section Two Layer Usefulness Results ........................................................................ 108
Table 4. Section Two Layer Identifiable Question Responses ................................................... 109

xiii
Acknowledgments
I would like to acknowledge the Spatial Science Institute at the University of Southern California
for all of the training and instruction to make this project possible. I am especially grateful to my
advisor, Dr. Elisabeth Sedano for all of her guidance over the process of this project. I would
also like to thank those for service on my committee and their support, Dr. Jennifer Swift, Dr.
Yao-Yi Chang, and Dr. Jennifer Bernstein. I would also like to thank Dr. Caroline Cicero for her
help in setting up the testing of this application for older adults. Special thanks to Dr. Jennifer
Swift for introducing me to the idea of this application through working with the USC Provost-
funded Wicked Problems Practicum, and working with Dr. Elisabeth Sedano in helping me get
the application tested with older adult users. I would like to acknowledge Dr. Karen Kemp for
her guidance throughout the proposal process, and I would like to thank Richard Tsung for his
technical support with ArcGIS Online. I am deeply appreciative of the US Army Corps of
Engineers as my current employer for being flexible with my time and supporting me through
the process of this project. Many thanks to Laura Trejo and Robbie Spears with the City of Los
Angeles for meeting with me to discuss ideas of this application project and possible
requirements. Lastly, I would also like to thank the older adults who tested the application which
provided feedback on what the application did well and what improvements the application
needed. Without all of these people, the application project could not have been accomplished.

xiv
List of Abbreviations
AGOL ArcGIS Online
API Application Programming Interface
DHS Department of Homeland Security
FEMA Federal Emergency Management Agency
GIS Geographic Information Systems
REST Representational State Transfer
SSI Spatial Sciences Institute
UI User Interface
USC University of Southern California
UX User Experience
WPP Wicked Problems Practicum

xv
Abstract
One of the greatest natural disaster threats to the Los Angeles area is earthquakes. A large
earthquake could wreak havoc on the area, causing major damage and loss of life. Recent
research from disaster events has shown that older adults (those 65 years and older) are one of
the most vulnerable demographics to disasters. Older adults benefit from specialized planning
and preparation designed specifically for their demographic. As the older adult populations are
rapidly on the rise in the Los Angeles area, the county and city have devised plans to prepare and
aid the community with natural disasters, including earthquakes. As a part of this effort, this
project was to research, design, develop, and test a prototype web mapping application for the
older adult population of Los Angeles to better prepare them for earthquakes and increase their
awareness of nearby emergency services.
This project brought together map layers of earthquakes hazards, emergency services,
and shelters, and other mapping layers related to seniors such as senior centers and nursing
homes into a single web mapping application. This project customized the web mapping
application user interface and user experience design in order to make the application user-
friendly to older adults. The developed web mapping application allowed users to zoom to their
location, pan the map, identify map layers, turn on/off map layers, print a map, search for the
nearest emergency services and shelters nearest their location, and add an emergency preparation
needs point to the map. With the results of this project, progress was made with understanding
successful and unsuccessful methods of apply UI/UX designs of web mapping applications for
older adults. The results can be applied to future research in order to best meet the needs of older
adults with web mapping applications.
1

Chapter 1 Introduction
With the older adult population of Los Angeles on the rise, the City of Los Angeles has been
working to make plans in order to make the city a more age-friendly place to live. As part of
those plans, the city has placed emphasis on disaster, and emergency planning for the older adult
population as older adults are often the most vulnerable to natural disasters. With the city lying
on some of the most active geological faults in the world, older adult Los Angelenos need to be
prepared for earthquakes. The purpose of this thesis project was to design a geospatial solution to
meet the needs of the aging population of Los Angeles in preparing earthquake disasters. The
end goal of this research was the creation of a prototype web mapping application specifically
designed for use by Angelenos 65 years of age and older in earthquake preparedness. An
underlying goal was to research and test web mapping application User Interface (UI) and User
Experience (UX) design methods for older adults within this earthquake web mapping
application. This project was a novelty because there was no known web mapping application
about earthquakes and earthquake preparedness specifically designed for older adults. An
application would be very helpful in the process of preparation, awareness, and reporting for
faster response. This project contributed to aiding society by researching the design of a web
Geographic Information System (GIS) application for the older adult community to use in
preparation earthquakes in the Los Angeles area.
The rest of Chapter 1 introduces the motivation, the study area, a brief application
description, and the thesis structure. Section 1.1 details the motivation for this projection. Section
1.2 describes the study area. Section 1.3 provides a brief description of the application. Section
1.4 gives the thesis structure for the rest of the document.
2

1.1. Motivation
This section describes the overall motivation that pushed this research project. The two
main areas that pushed this project was the need for assisting older adults with disaster
preparation and the need for specialized design of application for older adults. The following
subsections describe these motivation areas in more detail, giving background to the need for a
web mapping application designed to help older adults with earthquake preparation.
1.1.1. Older Adults and Disasters
Older adults have been found to be more vulnerable to natural disasters, and older adults
have also been found to benefit from emergency preparation planning gear toward them. Section
1.1.1.1 describes the older adult population vulnerability to disasters. Section 1.1.1.2 discusses
background information for older adult preparation for disasters.
1.1.1.1. Older Adult Population Vulnerability to Disaster
Among those most vulnerable identified by studies such as the study of “Earthquake
Preparedness in an Aging Society by Davey and Neal, are those of the older adult demographic
of those aging 65 or older (Davey and Neal 2013). Research has found that older adults among
those who are most vulnerable during and after earthquakes because of health issues and social
issues that many in the age group face. Those in the older adult demographic are also more prone
to be immobile and unable to evacuate on their own.
Brown and Peterson (2014) state that 90% of older adults often live in the community,
and almost a third live alone. They also note that many suffer from immobility, visual
impairment, mental cognition, diminished sensory awareness, and various chronic health events.
They find that harm and vulnerability to older adults in catastrophic events are widespread.
Despite older adults only making up 15% percent of the Gulf Coast population in 2006, 71% of
3

those who died were of 60 years and older, and most of these died in their homes. In Japan, 56%
of the fatalities from the earthquake and tsunami in 2011 were older adults. The chapter
suggested that the issues lie with preparation and planning provided for the older adult
community and that 0there is a growing need for specifically designed planning for their
demographic. The overall population of those over 65 will double in the US, and the overall
complexity and frequency of disaster events appears to be getting greater. The research points in
direction of the to the heavy need for planning for vulnerable older adult demographic and points
to some promising practices such as the Florida Department of Health creating a Geographic
Information System database of older adult vulnerabilities and needs down to the zip code level
in order to be better prepared to meet those needs and identify the older adults needs in an
affected area (Brown and Peterson 2014)
The Age-Friendly Action Plan for the Los Angeles Region (2018) by the Purposeful
Aging Los Angeles Initiative (comprised of Los Angeles public officials, the AARP, private
sector, and universities) identified emergencies and disasters as a major domain to plan and
prepare for in order to better preserve, prepare, and protect the lives of those of the older adult
community in need. The plan states that the older adult community in Los Angeles is rapidly
growing and would grow to 2.1 million by the year 2030. According to the California
Department of Aging (2015), The Los Angeles County older adult population will grow 171.3%
between the years of 2010 and 2060 (Figure 1). The growth would represent a major increase
and change to the demographics to the area and causes major concern for the well-being of this
growing age group. As this demographic grows, the needs of this group grow and the need to
better prepare them for disaster as they will make up a larger part of the population. The
Purposeful Aging Los Angeles Initiative with the Age-Friendly Plan for the Los Angeles Region
4

(2018) has made it a priority to plan to increase preparedness and plans for the older adult
community in Los Angeles. In conjunction with this plan, The Wicked Problems Practicum
(WPP) held in 2018 by the University of Southern California (USC) combined efforts from the
School of Gerontology and from the Spatial Sciences Institute (SSI) to create geospatial
applications for this effort and identified a great need in developing geospatial applications for
the older adult community. This thesis project idea was born out of the author’s involvement
with the WPP in order to find a better solution for the older adults of Los Angeles. Section
1.1.1.2 discusses research into disaster planning for older adults, and the types of needs older
adults have for disaster planning and what can be useful to them in order to be better prepared.

Figure 1. Anticipated Increase of Older Adult Population in California
(California Department of Aging 2015)
5

1.1.1.2. Preparation for Older Adults in Disaster Events
The Red Cross (n.d.) study, “Disaster Preparedness for the Elderly by the Elderly,”
identifies several needs for the older adult community in order to be prepared for a disaster.
Some of those needs are listed as medical supplies, food, water, batteries, dry clothing,
transportation, and maps. Maps are important because they can show information on locations of
stores for supplies, emergency services, and routes for possible evacuation (Red Cross n.d.). This
document points out the need for preparedness designed specifically for the older adult
community and the importance of having knowledge of one’s surroundings before an earthquake
event.
The Department for Aging of Los Angeles web page provides several helpful documents
of older adults in order to be better prepared for disasters. Within the helpful documents, the city
lists several things to have on hand for emergency supplies for disasters. The items include
bottled water, canned and dried foods, batteries, first aid kits, emergency kits, and other items.
The city website also points to the importance of planning to know if to evacuate, stay in place,
or arrange for transportation with those that have no vehicle or have mobility issues (City of LA
n.d.).
In 2014, on the show “Aging Well in LA,” (LA City View 2014), the host Paul Peterson
discussed the topic of emergency preparedness with City of LA officials and discussed how older
adults could be better prepared. Petersen interviewed the Los Angeles Department of Aging
head, Laura Trejo, and officials from the Fire Department and the Emergency Response Office.
The city officials explained the importance of knowing shelters locations and having emergency
kits ready to go. The city officials suggested that older adults are sometimes reluctant or have
issues putting together emergency kits and evacuating without help. The emergency management
official suggested that older adults needed to be prepared for evacuating with pets and to be
6

aware of shelters that are pet-friendly. The fire department representative discussed the need for
understanding routes and understanding maps and knowing what resources are available to older
adults in their neighborhoods. The fire department official also suggested that knowing of the
dangers and hazards will help the older adults be more aware and prepared. In another part of the
interview, the city officials suggested that mobility issues and other disabilities that older adults
have need to be planned and prepared for by officials, family, friends, and volunteers in case
those disabilities and mobility issues need to be provided for (LA City View 2014).
1.1.2. Older Adults and Web Design
This section gives the background for need of researching and designing web mapping
applications specifically for older adults. Section 1.1.2.1 describes the older adult adaptation to
computer to computer technology and mobile phones. Section 1.1.2.2 introduces the reasons and
need for specialized design of software applications for older adults. Section 1.1.2.3 introduces
the need to design web mapping applications specifically for older adults.
1.1.2.1. Older Adult Adaption to Computer Technology and Mobile Phones
As time has progresses, the segment of the older adult population that is familiar with
computer technology grows. More senior adults are being exposed to and taught the technology.,
and younger seniors are more likely to have been exposed to computers and smart phones before
they officially joined the senior demographic. These older adults are more familiar with modern
technologies. Pew Research numbers from 2017 show that around two-thirds of those 65 and
older now go online and a record number of older adults are now using smartphones (Anderson
and Perin 2017). The survey also reports that well over half of those over 65 now have
broadband at home. According to the survey, over 58 percent say that digital technology has a
positive impact on their lives and society, 75 percent say they go online on a daily basis. The
7

Pew Research does, however, show that some seniors are still disconnected. The survey also
shows that the oldest adults in the population tested are less likely to use computer technology
(Anderson and Perin 2017).
Research does suggest the heavy need for older adult users to be trained on technology,
as 48% of those surveyed said they need training (Anderson and Perin 2017.) Barnard et al.
(2013) also point to the need for training and education for older adult users. The study showed
that working with computer technology helped with cognitive skills, but older adults were more
likely to use technology successfully with help. This research points to the importance of
working with older adults to design computer technology and training for them to help them
better to understand the technology and programs.
Another Pew Research Center survey completed in 2015 looked at the US Smartphone
usage (Smith and Page 2015). The study found that nearly two-thirds of Americans owned
smartphones at the time. The survey also shows that over 68 percent of users use their
smartphone for breaking news, and 67 percent use their phones for navigation now. According to
the research, over 80 percent of users of 50 years and older use their smartphones for internet use
which points to a large number of those over 65 using smartphones for internet use; however,
according to the research conducted, only 27 percent of users in the survey were those 65 and
older. These numbers, according to pew research, are a good reflection of the general population.
(Smith and Page 2015). In February 2018, the Pew Research fact sheets showed a 46% increase
in mobile smartphone usage by older 65 and up. The upward smartphone usage trend by older
adults suggest that this trend will only increase as those who use smartphone technology get
older and older adults are exposed to the technology become more comfortable with the
technology (Pew Research 2018).
8

While the research points to a higher number of older adults of those 65 and older using
the internet and mobile phones, there is still roughly just under half using smartphones.
However, those in that quarter cannot be ignored. The numbers also show an upward trend in
users. The research provided by the Pew Research Center shows that both computer browser-
based applications and mobile smartphone applications should be considered moving forward.
The research also suggests that using the internet for mapping and navigation that a mapping
application could be useful and successful.
1.1.2.2. The Need for Software Application Design for Older Adults
Most of the research for a design for older adults focuses on design for physical ailments
that come with older age and stress the need for high usability. Most of the articles from
magazines and journals that the author found pointed to designing applications for the older user
that were not map based. Even though the articles are not map based, the information found in
the articles can still be applied in this research. The articles point to making the application easier
to use and that several applications do not consider older adults, but they should. Articles by
Ollie Campbell in Smashing Magazine (2019) and Emily Grace Adiseshah (2016) on Usability
Geek Magazine online both suggest designing fonts that are larger, buttons that are larger, high
contrasting colors, easier to use navigation of buttons, and easily understandable language. In the
book, Designing User Interfaces by Jeff Johnson and Kate Finn (2017), the authors make the
strong claim that poor usability can lead to the desired audience not using the application. All of
the research pointed to the need for designing an application for the specific needs of older
adults. Their research also showed that if a mapping application was going to be designed, it
should consider the things that would make it more user-friendly. Chapter 2 will go into more
detail of the research into designing software applications for older adults.
9

1.1.2.3. Web Map Design for the Older Adult User
A few studies (Kovanen et. al. 2012; Veronko and Petrovic 2015) investigated different
methods to improve web maps for the older adult user and the issues that they face with visual
problems and aid. Kovenan et al. (2012), researched design of mobile web mapping applications
for older adults looking specifically at plain cartographic design and color schemes that best fit
older adult visual issues. Verenko and Petrovic (2015), researched online web maps focused on
contrast and color for older adults. No other studies specifically focused on web maps design for
older adults. The older adult population of Los Angeles is very much in need of an earthquake
web mapping application design specifically for their community because other earthquake-
related web mapping applications have not been designed specifically with those users in mind.
1.2. Study Area
The study area, as seen in Figure 2, focuses on the Los Angeles Area as the project
coincides with efforts of the Aging Purposeful Los Angeles Initiative, which aids older adults in
disaster preparation for earthquakes. Los Angeles is situated upon one of the most active fault
areas in the world and has several minor earthquakes on a regular basis. The San Andreas is the
more notable of the faults that are in Southern California; however, there are hundreds of other
smaller faults in the Los Angeles area. The city itself is situated on six major fault systems.
Based on research from the USGS, the area of Los Angeles is at high risk for having several
moderate earthquakes or even a larger catastrophic earthquake (Figure 3).
10

Figure 2. Study Area of Los Angeles

Figure 3. California Earthquake Probability (Southern California Earthquake Center 2011)
Scientific research suggests that Southern California is ripe for a major earthquake. While
it has been several hundred years for a major earthquake to hit, the Los Angeles area has been
subjective to a few damaging earthquakes in the moderate level and several in the minor level. It
has been over 327 years since the last major earthquake hit Southern California; however, the
11

area has been hit by earthquakes that are considered moderate earthquakes such as the
Northridge earthquake that occurred in 1994 which caused major damage. The area has also been
hit by several smaller earthquakes that have also caused damage. According to the USGS,
Southern California has a 99.7% chance of having another moderate size earthquake of those
between 4.8 and 6.7 on the Richter scale and 37% chance at having a major earthquake 7.5 or
greater on the Richter Scale in the next 30 years. The research by Dolan et al. suggests that it is
only a matter of time before another moderate or major earthquake occurs due to the build-up of
major seismic pressure and natural release of that pressure. (Dolan et al. 1995)
With earthquakes come hazards such as tsunamis, landslides, fires, building collapse, gas
leaks, water pipe ruptures, electric outages, and many more hazards that are life-threatening. The
document from the USGS suggests that a major earthquake for Southern California could be a
Hurricane Katrina type of disaster for Los Angeles with the amount of destruction possible. The
threat of an earthquake and the damage that they can do should be considered a major threat and
should be planned and prepared for by all those in the Los Angeles area especially those who are
most vulnerable (Southern California Earthquake Center 2011).
1.3. Application Description
The EQ Prep App was designed to allow easier user and interaction for older adult users.
The application was built on the Esri ArcGIS Application Programming Interface (API) for
JavaScript using the Web AppBuilder framework and presented to the intended older adult users
via a web browser on whichever device that they chose to access it on so as long as the device
can access the web. The application was designed to allow the user to interact with the map with
several different widgets. The application was design to allow users to pan, zoom, and find their
device location on the map. The users can identify map features by clicking on them and by
12

checking the legend widget. The EQ Prep App was designed to allow users to turn on and off
map layers and add points using the add assistance request points. Users can also print a
screenshot of the map using the print widget and find the nearest emergency services and shelters
to their location use widgets that will find those nearest features from one to five miles away.
1.4. Thesis Structure
The rest of this thesis is comprised of organized chapters, sections, and subsections that
discuss research, design, development, results, and conclusions from the EQ Prep App project.
Chapter 2 discusses research related literature and related existing applications that were used in
order to provide a basis for the requirements for the application. Chapter 3 details the
requirements for the application. Chapter 4 describes the data and methods used to develop the
map and base application. Chapter 5 details the process of customizing the application. Chapter 6
shows the results of the application and application test. Chapter 7 discusses the issues found
with the data, results, and provides a discussion on ways forward for the final application and
future research. Chapter 7 also offers the final conclusion for the thesis project.

13

Chapter 2 Related Work
This chapter explores related research and development to understand better the need for a web
mapping application to support the older community of Los Angeles. The first section describes
research on application design for older adult users. The third section discusses web mapping
user interface and design and cartographic design research for the older adult user. The third
section examines existing web applications for disasters and earthquakes. The fourth section
gives background information into the use of volunteered geographic information (VGI) in GIS
systems for emergency disasters and relates to the use of VGI input by older adults in the web
mapping application. Collectively, this work points to the need for a web mapping application
development designed for older adults for earthquake disasters and the considerations that need
to be made when designing the application.
2.1. Application Design for Older Adult Users
Several articles that the developer found while researching design for older adults pointed
to the specific needs that older adult users have and the need to design applications specifically
for older adults. The articles discussed what some of the issues were and the best ways to address
those for older adult users to make apps for user-friendly for them. The ways to address these
issues were used as key considerations for this project in the design of the application.
Campbell (2016) argues that people in the tech world that design applications often forget
about the older adult generation in their work. The author urged the reader to realize that the
older adult population is growing and need more attention given to the design of application to
older adults. The author describes the need to design for older adults because of issues with
vision, called presbyopia, that makes it difficult to read things up close. The author also says that
as people age color vision declines, making it harder to see making things such as different
14

shades of blue harder to see. The author suggests when the design for older adults to use a
minimum of 16 font and use high contrast ratios in text and color to help with vision problems.
The author also mentions the need for attention to design for the interface with screen size being
considered. The screen sizes should be larger and avoiding smaller screens. The author suggested
buttons of at least 44 by 44 pixels where they could be applied. The design of application for
older adults had to consider older adults being able to interact with touch screens and using a
mouse to click.
Adiseshiah (2019) offered some key tips when designing for older adults. The first was to
make the application reader friendly. In agreement with Campbell, Adiseshiah suggested that
developers make the font as large as possible with never going below 12-point fonts for any text.
The author also indicated that the developer should put larger texts into the design even though
some devices will let users change text themselves. The author described that not doing so could
cause issues when older adults are forced to manually override sizes in applications because the
device may not be able to change everything proportionally. The author also agrees that high
color contrast is important for visibility and readability as well as clear language. Adiseshiah
went on to say that the buttons also needed to be easier to click with buttons being at least 41px
where applicable.
Johnson and Finn (2017) point to the necessity of designing for older adults in order to
make applications more user-friendly. The authors found older adults to be more likely to take
longer to learn to use an application. They also found that older adults are more likely to have
issues with finding targets on the screen and have more issues with accidental movements or
clicks with a mouse or touch screen. All of those things have to be taken into consideration when
designing the interface of an application for older adult users. The authors also mention several
15

things that have to be considered with eyesight with screen brightness, color contrast, and font
style. The authors pointed out that designers often only think about font size but not color and
font. The authors recommend using san serif fonts that are not light in width and do not use all
capitals in body text, but titles are ok. Limiting the number of things on the screen was also a
recommendation listed by the authors that needed to be considered. The authors also indicate the
need to highlight by using larger text, different colors, and bold fonts for important items to
make them stand out.
All of the research into designing applications for older adults was found to be helpful in
building requirements for the application design. The requirements for the application are further
discussed in Chapter 3 using many of the principles found in the research mentioned in this
section and in the next section. The next section discusses research into the design of
cartographic web applications for older adults.
2.2. UX and UI Web Mapping Design for the Older Adult Population
One of the key features of this study is the attention to detail of the design of mapping
application for the older adult population. While there are several factors that must be considered
when designing web mapping applications, older adults, there are few articles that address the
creation of web mapping applications for older adults. This issue needs to be highly considered
as older adults have issues that may make certain parts of maps, user interface, and user interface
harder to understand and see. A few articles also address cartographic design and mental map
cognition for the older adult.
Kovanen et al. (2012) argue that a growing number of the older adult population have
some issues and inabilities when it comes to reading maps, especially mobile mapping
applications with smaller displays. The research suggests that there are too few studies that
16

address the issue of making maps and mobile maps to be understandable and readable for the
older adult user. The study suggests making maps with “plain language” as a way to make maps
easier to understand. The authors argue that creating simpler maps make them easier to
understand by the older adult user. The older adult user tends to find maps with more
information are harder to understand and overloaded with information. The authors also
suggested that the best option for helping the older adult community understand maps is to make
maps specifically designed for their community that can address issues that they face with
understanding and reading the maps. The authors came up with the concept of “plain
cartography” in order to address the issue of creating simplified maps designed specifically for
the older adult user. The study aimed at creating principles in order to find a balance between
visual clarity, information density, and including certain map levels for the understanding of
associability. The study suggests making maps with more contrast and highly considering the
font types and styles that are being used within the maps. Halos were often used in the research
in order to provide color contrast to help differentiate labels from background layers. The change
in colors and high contrast made the elements easier to see for those for visual issues. The study
also suggests working with levels for symbology to decide what the most important layers are so
that the symbols may be easier to understand and not overcrowd the map with information. The
authors make the case that simplifying the symbology by leveling different elements makes the
maps easier to understand. The authors also argue that the high contrast in the maps makes the
different elements easier to see for those with visual impairments, which is common in older
adults. The last thing that the authors pointed to was that design of web mapping applications for
mobile devices is difficult because mobile device screen sizes are often smaller and present that
present challenges to make features more visible on the smaller screen (Kovenan et al. 2012).
17

This study is most informative about the design to consider in mapping for the older adult
community that will be employed in this study. This study also points to the need for designing
maps separately for the older adult community.
Vrenko and Petrovic (2015) suggest that as the older population grows, more attention
needs to be paid to those users in the design of the web map viewer. The study argues that with
the limited visual ability of many older adult users, more thought should be given to the size of
text and colors used by the design of web maps. This study also suggests that attention needs to
be given to how web map layers will contrast and pop off of the map that makes the requested
information easier to see. Mobility was also another issue noted by the study that some older
adult users may not be able to use a mouse easily or be able to zoom in certain functions with
their hands. Another issue is the ability of cognition, and the study suggests making the map
easier to understand. The authors go on to mention that the three main components of
visualization that need to be addressed are data, graphics, and interface. The study suggests that
brightness also has to be considered as a key concept as the map interface needs be easy to be
seen as well as map layout design has to be considered (Vrenko and Petrovic 2015). While this
research does not specifically address making web mapping applications for earthquake
disasters, the research does provide vital information for this study to consider in research and
planning the design of a mobile mapping application for the older adult. The study also backs up
the Kovenan (2012) study by describing the need for maps to be designed specifically for the
older adult user.
2.3. Web Mapping Applications for Earthquakes and Other Disasters
Web GIS applications have played a major role in supporting natural disasters, including
earthquakes for several years. Organizations such as the Federal Emergency Management
18

Agency, the Red Cross, the United States Geological Survey, the United States Army Corps of
Engineers, and the California Geological Society all have used GIS applications in awareness,
response, and recovery of natural disasters. Several of those organizations also have created web
mapping applications, with success tracking earthquakes, displaying earthquake hazards, and
showing shelter information for users and emergency officials. Efforts by private groups have
also proven effective in providing web mapping applications for crisis situations.
The Federal Emergency Management Agency (FEMA) provides a web mapping
application for identifying shelters which can be used in a disaster. The application only tracks
shelters locations and federally declared disasters and does not include other earthquake hazard
layers within this application for earthquake awareness. The FEMA web mapping application
viewer is built on the Esri platform, employing in a plain, out-of-the-box Web AppBuilder
format. The application shows locations of open and closed shelters and the different types of
shelters available to users. Users can zoom to their location if the browser is able and see if any
shelters are near their location. While this application is useful in showing shelter types and
which shelters are open and closed and their location, this application lacks the ability for users
to route to those locations or search for one that is nearest. Currently, the user would have to do
that based on pure personal observation. The project plan for the earthquake awareness and
response application designed for the older adult user was to allow users to see these same
shelters, but also allow them to be able to route to those shelters and find the closest one to their
location by use of a widget. The FEMA application does not also provide any additional data
layers such as earthquake locations, faults, or hazards zones (FEMA n.d.).
Several web mapping applications have been developed to address the disaster itself. One
such application is the United States Geological Survey (USGS) Earthquake Viewer. The USGS
19

Earthquake Viewer is an open sourced format web map viewer designed to show recent and
historical earthquakes. The web mapping application is also designed to show faults and general
hazards zones. While the earthquake viewer is one of the best applications for finding
information directly related to earthquakes, the earthquake viewer lacks other layers related to
disasters such as emergency services and does not allow for any user input such as adding points
for preparation requests (USGS n.d.).
The American Red Cross has a multitude of mobile applications related to disasters,
including earthquakes. The earthquake application includes very helpful information for what to
prepare for and tips of what to during and after a quake. The user also has the ability within the
application to add information for an unknown event. Users can also use the application to take
quizzes on the preparation, knowledge, and planning in order to make sure the user understand
the information being given. The application will also alert the user if a nearby earthquake has
occurred. The mapping portion of the application provides mapping layers of recent earthquakes,
radar, clouds, Red Cross shelters, and people that are in your shared group list. The application
provides a very good model for an overall mobile application not just for mapping; however, the
mapping portion does lack functionality and layers that would be more useful for an earthquake
preparedness application designed for the older adult user. The map only allows one layer at a
time to be on, which would not be useful to someone trying to see layers for shelters and
evacuation routes at the same time. Since the application focuses only on the shelters and
earthquakes, several useful layers are lacking such as earthquake hazards, fault locations,
emergency services, senior centers, nursing homes, and other layers important to older adults
(Red Cross 2018).
20

Another web mapping application project through the USC was designed and built for
earthquakes within the Los Angeles area. McPherson (2016) completed a thesis research project
developing an earthquake web mapping application for the students of University Park Campus.
The research project centered upon creating a web map viewer of earthquake information in
order to test the effectiveness of web mapping application for earthquake awareness and
preparedness as compared to the static map. The mapping application contained layers for
building locations, emergency supplies, assembly areas, and emergency disaster routes. The
application was built using Esri’s Web AppBuilder through ArcGIS Online (AGOL) which
allowed a simple, easy design. The application included a very helpful tool called the “Locate
Nearest” widget that allowed for a user to set a location and buffer area to find the nearest
supplies. The type of analysis is very useful to the plans for this research project. While
McPherson’s study only compared static maps against the dynamic web mapping application,
this study provides a very good guideline for designing an application using Esri’s web mapping
application for earthquake preparedness. The application was missing several pieces for user
input of information to add to the data on the mapping application as well as actual recent
earthquake information and the hazards. Also, the application was designed as for the intended
use of those in the campus area and did not include any study into the creation for an older adult
user and the methodology to incorporate the needs of many older adult users (McPherson 2016).
The Shake Alert LA application is a native mobile application that was unveiled in 2019
(City of Los Angeles 2019). The application has different button functions for preparing for an
earthquake, earthquake alert map, view recent earthquake, and recover for an earthquake. The
application shows recent earthquake on one screen. The application can alert you if an
earthquake is happening in your area. The application provides preparation information on what
21

to prepare for and how to prepare for an earthquake, and the application provides tabular
information about what do related to post-disaster recovery. The application does not provide a
visual information map with multiple earthquake hazard layers, shelter layers, and emergency
service layers all in the same map that the users can visually see. It also only provides the
information post-earthquake showing open shelters. The application does not show all shelters
and emergency service locations in the preparation part of the app. The application design in this
project does not have a documented preparation page showing helpful hints. The application
design in this project also does not feature in post-recovery parts as this project was focused on
the design of preparation web mapping application. While the Shake Alert LA application is
design for multiple user use, it does not appear to be designed with the older population user as
the foremost user. This project was ongoing at the time of the release of this application, and the
developer compared design plans against this application for best practical uses. As this
application was a native mobile application, not many considerations were taken into account.
The designed application in this project was browser based. The application design in this project
met other criteria and desired results than the LA Shake Alert application (City of Los Angeles
2019).
2.4. VGI and Crowdsourced Information for Disasters
VGI, as a part of GIS, has begun to play a major role in providing real-time locational
information in disaster situations that is vital as time is of the essence in disasters (Goodchild and
Glennon 2010). Efforts after a Haiti Earthquake used VGI and crowdsourcing from social media
with great success to create geographic products used in response (Zook et al. 2010). A volunteer
GIS group by the name of Standby Task Force also has successfully created Esri web mapping
applications to be used by emergency officials and general public for emergency response in
22

situations with Hurricane Maria in Puerto Rico, an earthquake in Nepal, and several other
disaster events mashing up information related to the emergency and crowdsourcing social media
for information on road closures, outages, and needs.
The term “volunteered geographic information” was coined by Goodchild in 2007 as a
phenomenon of user-generated geographic information. Goodchild describes certain efforts such
as OpenStreetMap and WikiMapia that use the general public in order to create geographic data
and update the information (Goodchild 2007). Goodchild continues on in a later study to
understand the user of volunteered geographic information for disaster events. Goodchild
explained that while there are some concerns with data quality that the speed at which data can
be collected from those citizens on the ground is far outweighing. He argues that the volunteered
geographic information method as a good alternative to other procedures of data collection
through agencies and emergency management groups. In another article in 2010, Goodchild
observed the use of the volunteered geographic information for wildfires in southern California
and found that never before had the citizens been able to be so involved before with the reporting
efforts and be able to see the information so quickly (Goodchild and Glennon 2010).
One good example of the usefulness of volunteered geographic information in an
earthquake disaster occurred after the Haitian Earthquake in 2010 (Zook et al. 2010). Volunteers
collected information and sent it to emergency management groups. These groups then shared it
to users sitting all over the world to update maps with satellite imagery for the island of Haiti.
This effort proved very promising as the detailed maps of the area desperately lacked updates
and availability. The effort also comprised of programmatically scanning social media post in
order to crowdsource for information of those who were trapped under rubble or in need of help
and using social media to call for help. The crowdsourced information was then mapped based
23

on the geotagged information in the social media post. This information was vital in aiding
emergency responders to find individuals faster that they might not have otherwise known were
in need assistance (Zook et al. 2010).
Over the past few years, a volunteer group by the name of Standby Task Force has
worked to develop several web mapping applications for disaster events for hurricanes and
earthquakes to provide real-time information to emergency officials of the situation on the
ground. The work completed by Standby Task Force created web maps that took crowdsourced
information from social media and created an awareness map for the public and emergency
officials to use to see where people may be trapped, or road may be cut off or damaged. The
Nepal Earthquake map was an excellent example of the work completed by the Standby Task
Force to aid in the earthquake in relief and how a volunteered web mapping application could aid
in the relief of earthquake victims and allow those affected to aid in their own relief efforts
(Standby Task Force 2015).
Although these systems used volunteered geographic information and crowdsourced for
more information, none of these systems and studies researched designing a GIS system that
allows older adult users to provide VGI. These studies and systems proved that crowdsourcing
and using VGI can be very helpful and give background and reason to giving the older adult user
the ability the interact with a system to provide VGI.
24

Chapter 3 Application Requirements
This chapter discusses the requirements for the web mapping application. Sections 3.1 and 3.2,
respectively, identify application interface design requirements and functionality requirements.
Section 3.3 discusses map design requirements. Section 3.4 discusses map content requirements.
Section 3.5 discusses the software requirements for this project.
3.1. Application Interface Design Requirements
With the intended users of this application being older adults, the application interface
had to meet certain design requirements based on previous research provided in chapter 2 for
older adult web applications and web mapping applications. When designing web mapping
applications for older adults, the design had to consider some physical and mental limitations
that affect many older adult users. Many older adults suffer from visual impairments such as
color blindness and limitations being able to see the small font and certain fonts. Many older
adults also suffer memory and mental processing issues. The design of this project had to
consider those limitations with the design of the application.
The first thing that the design of the application had to consider was text. The application
had to have large enough font that could be clearly be read. Based on conversations with Dr.
Caroline Cicero from the USC School of Gerontology and Laura Trejo from the Departing of
Aging with the City of Los Angeles, a minimum font of 14px should always be used but the
larger the font, the better. Some of the research suggested using at least 16px. Font style also
played a key role in being able to read font on the screen. Based on this information, key
requirement number one for application interface design was to make font sizes at least 14 pixels
for the application. Requirement number two for application interface design was to use sans
serif fonts. According to several of the researched articles on the best fonts to use, San serif fonts
25

are more clearly legible for users in general to read but even more so for older adults. The third
requirement for the application interface design was to used contrasting font colors for text. Font
color that is a clearly contrasting font that shows up better against backgrounds was also a
requirement for the application.
The second thing to consider in the design requirement was the size of the application
buttons. The fourth requirement is that the design of the application buttons had to be designed to
be larger. Larger buttons are easier to find and click for older adult users. Based on the literature
and design review for older adults, buttons should be made for ease of clicking the buttons.
Making buttons larger is even more important for applications can be accessed via a device that
is touch screen enabled. The button must be made wider so that a finger or stylus can easily
touch the button. Buttons should be made larger and at least 41px in places that could be done
that way. Hardware and software limitations would have an effect on some of the sizes of the
buttons chosen.
The third thing that had to be considered in the application requirement was the contrast
in color of application elements. The fifth requirement for the application design requirements
was for the application to have high contrast in colors between elements that could be easily
seen. The application had to have a color theme that had a high color contrast between elements.
Colors that are close in color were not to be placed together. The application design also had to
consider colors that are not on the same color scale for color blind impairments as there is a
higher number of people with color blindness that are older adults. Colors that are often
misinterpreted due to color blindness were not to be used together in the application
development.
26

The fourth thing that had to be considered was the ease of navigation of the application.
The sixth requirement for the application design was that the application needed to be designed
with a simplified design and theme that was easier to use. Having all of the application widget
buttons on the web page be easy to find and near one another allows for easier navigation of the
application and makes it easier to use. Buttons that are spread out and on multiple places on the
screen makes the application harder to use and navigate. Buttons also needed to have icons that
are easily recognizable or make the connection for what the button performs.
Based on the concepts and of the need to design the application for the older adult users,
six total requirements were found: 1. Use application font sizes of 14px or greater, 2. Use san
serif fonts throughout the application, 3. Use font colors that will contrast well with the
background. 4. Make buttons larger to be easier to pick. Make buttons at least 41px by 41px
where possible, 5. Use high contrasting colors between elements, 6. Use simplified application
navigation design.
3.2. Mapping Application Interaction Functionality Requirements
The requirements for the application functionality of the mapping application were based
on previous and research by the developer for earthquake preparation web mapping application
and functionality that would be important for older adults in an earthquake.
The basic web map interaction capabilities of panning and zooming were an important
functionality to include. Users needed the ability to be able to look at a location on the map and
choose different views of the map. Users needed to have the ability to zoom in to see more detail
in the mapping application to be able to see different features. The users also needed to be able to
zoom out of the application when necessary to see more features further out. Users also needed
to be able to pan or move around the map to look at different areas at different zoom levels.
27

Based on the needs of the users mentioned here, the first requirement of the mapping application
functionality was to give the user the ability to zoom in and out and pan the map.
The second requirement of mapping application functionality was adding the ability for
the application to zoom to the user’s location on the map. Users needed to be able to center the
map on their location so that they could see the map features nearby or further interact with
them. Because the purpose of the mapping application was to be used for earthquake preparation,
users needed the ability to find their location on the map and use their location to find out more
information about the area around them in order to be more prepared for an earthquake.
The third requirement of mapping application functionality was to have the ability in the
application for users to identify map features. Users needed to be able to get more information
about the area and map layers. The mapping application needed to have the ability for users to
identify map layers and information about map layers. The mapping application needed a legend
to clearly identify what layers were and how the layers were symbolized, and the application
needed the ability for a label or popup to identify the map layer and information about the layer.
Based on conversations that the developer had with Laura Trejo with the City of Los
Angeles Aging Department, the fourth requirement for application functionality was for the
ability to be able to print to be added to the functionality of the application. Users needed the
ability to print the map view from the screen in order to have a copy of the map at a later time if
they were unable to access the application in the case of an earthquake event.
The fifth application functionality requirement that was added to the list for application
functionality was the ability to add a point to the map. The developer wanted to test the process
of allowing the older adult users to interact with the mapping application to be able to provide
data to the mapping application. During previous disaster events, the use of VGI had been found
28

to be useful for emergency officials in being able to provide more efficient support. Because of
the application intended use of earthquake preparation, the users needed to be able to add a point
along with their specific preparation needs.
The sixth application functionality requirement was the ability for users to easily find
nearest shelters and nearest emergency services. The users need the ability to find these quickly
using the system to find the nearest by distance rather than just choosing visually. Users need to
be able to locate all the nearest shelters and see their distances and names. Shelters and
emergency services are important places to know the location of in case of a disaster event.
Being able to locate those places and being able to find the nearest ones near an application
user’s location was an important part of the functionality requirements. Being able to quickly
locate nearest shelters, allows the user to make plans based on what the closest shelters and
emergency services are to their location.
3.3. Map Design Requirements
For this project, the map in the application was dependent on parameters used for
mapping for older adults, emergency hazards, and commonly known symbols for places. Prior
research, discussed in Chapter 2, identifies basic concepts for map and layer design that steered
the requirements of the map design.
The first basic concept was simple map design. Map layers can be simply symbolized and
set to be scale dependent so that multiple layers aren’t all provided at once. When too many map
symbols are showing up and covering up the map, the map is harder to understand and read. The
first part of the concept is to decide what map background layers are most important to map for
reference and which can be left off to help simplify the map. The first map design requirements
were to simplify the map background and the map layers that were added on to the map. The
29

map needed to include based reference guides such as roads and familiar places, but also the
layers needed to be simplified by not breaking things out into so many classes and turning layers
to be set to turn on at different scales.
The second basic concept was providing high contrast in colors. This fit into the second
requirement of the map design. The map needed to have contrasting colors that could be seen
similar to the requirement of high contrast in colors for the application. Some older adults cannot
distinguish colors that are near the same hue and near each other on the map, which could cause
separate map features to blend together and appear continuous. Higher contrast in color between
map features make the different features “pop” and be seen more clearly.
The third basic concept was to use larger text with high contrast within the map for
labels. This concept made the third requirement of the map design. Labels for map features that
use larger text makes map text easier to read for older adults that have vision impairment. For the
same concept of contrast, the text needed to be clearly seen and not blend with the map layers.
The fourth map design requirement also be of the san serif font because serif fonts are harder to
read within web applications.
The fourth basic concept was to make symbols easily understandable, or intuitive. This
concept was made the fifth map design requirement. Symbols needed to be larger than typical
symbols so that they could be clearly seen. The symbols also needed to be familiar symbols that
are often used for map features of that type so that the map features could be easily identified.
3.4. Map Content Requirements
In order to know what map layers needed to be included or excluded in this mapping
application, requirements were set for what needed to be included. Based on the simplification
concept mentioned in the previous section, part of the research for this project included finding
30

the “happy medium” of the right number of layers for the application. For this project, there were
five different classes set for the layers by author: earthquake-related layers, emergency services,
shelters, preparation needs assistance requests points, and other reference layers that older adults
might relate to or be familiar with such as senior community senior center and nursing homes.
Section 3.4.1 discusses the earthquake-related layer class requirements. Section 3.4.2 discusses
the shelters class requirements. Section 3.4.4 introduces the emergency service class
requirements. Section 3.4.4 describes the preparation needs assistance request point class
requirements. Section 3.4.5 discusses the senior reference layer class requirements.
3.4.1. Earthquake-Related Layer Requirements
Since this application was designed for earthquake preparation, earthquake hazard related
layers were decided as required for this application. Users needed to be able to see earthquake
hazard layers in the map. Due to the concept of simplification, only certain earthquake hazards
would be required. Overall, earthquake hazards would not be required as the entire Los Angeles
area is in a hazard area. Because this mapping application was designed for earthquake
preparation, live earthquakes or past earthquakes were also not a requirement. For this
application, liquefaction areas, landslides, and the fault lines were requirements for the
earthquake hazards. The earthquakes hazards would help the users be able to identify if their area
was in or near an earthquake hazard area.
3.4.2. Shelters Layer Requirements
For emergency preparedness and planning purposes, the project research identified
shelters as important layers that were required to be a part of this application. Designating the
shelters that were wheelchair accessible was also set as a requirement as the shelters needed to be
31

identified that were more accessible than others as more adults suffer from mobility issues and
would need more accessible shelters.
3.4.3. Emergency Services Layer Requirements
For emergency preparedness and planning purposes, the project research also identified
emergency service location as important types of information to have included in the mapping
application. For the emergency services, hospitals and urgent care facilities were decided as
requirements as those emergency services would be the more important emergency services as
compared to pharmacy and normal primary care facility locations. The emergency services
would also be limited to just hospitals and urgent care facilities for the simplification concept.
3.4.4. Requirements for Preparation Needs Assistance Request Layer
In order to allow for the older adults to contribute to their own preparation of earthquake
and interact with the map, the preparation needs assistance points were required for the
application. Giving the ability for older adults to place a point on the map with a preparation
needs assistance request would allow the older adults to place points on the map with various
needs that could be used by the city to stage supplies and assistance to those of the older adult
community to help them prepare and make plans for an earthquake emergency. Older adults
could request the need with assistance for batteries, preparation training, canned good, bottled
water, pets, transportation, emergency kits, or assistance. Conversations with those in the
emergency field and gerontology field in Los Angeles, documents from the Red Cross, and the
LA Age Friendly Action Plan all supported need for the ability for older adults to interact to be
involved with preparation planning and requests. Literature supported that volunteered
geographic information was very useful in planning and preparation for emergency events.
32

3.4.5. Requirements for Senior Reference Layers
Gerontology experts suggested adding nursing home and senior centers to the map as
these could serve as helpful reference layers for older adults. First, older adults might find
nursing home locations useful because they either might live in nursing homes or have friend
that live at those locations and may be familiar with those locations in reference to roads and
other landmarks. Second, older adults also might often visit senior community centers, and
activities are also held at these locations for older adults. These reference layers may help older
adults navigate the map and be able to relate to locations based on those layers.
3.5. Software Requirements
In order to be able to develop a web mapping application for earthquake preparation for
older adults and test the UI/UX design, software requirements had to be met that were able to
meet the project requirements. First of all, the application would have to be built using software
that was accessible by anyone via the web on multiple types of devices. Second, the application
would have been accessible on multiple browsers because many users would use different
browsers. Third, because of the need to have points created, a software would have to be used
that could create geographic data. Fourth, the software would also need to push data to the web.
Fifth, the application software would have to be able use web data rather data on the device
itself. Sixth, the software platform chosen would need to make the transition from offline data, to
web services data, to web map, to web mapping application, to customized web mapping
application, and then to the web server. Seventh, an API would also have to be chosen that could
meet functionality requirements and UI customization requirements. Eighth, software would
have also to be chosen that could be used to meet the customization requirements and push the
33

web mapping application to the web server. Chapter 4 will discuss the software chosen to meet
the requirements for software laid out here.
34

Chapter 4 Software, Data, and Base Application Development
This chapter will detail the software chosen, the data chosen along with sources, and the
methodology that was performed to develop this application. Section 4.1 describes the software
chosen for this project based on the requirements. Section 4.2 details the data chosen and
included in the application. Section 4.3 examines the methods by which data schema creation
that needed to be created was done for the VGI data layer. Section 4.4 discusses the method by
which the base map was created. Section 4.5 details the map creation. Section 4.6 reviews the
process of development for the base application functionality and design.
4.1. Software
This section describes the choice of the Esri platform overall and particular programs
within the Esri suite of options for application development. Section 4.1.1 discusses Esri for
Desktop. Section 4.1.2 describes REST Services. Section 4.1.3 gives information about AGOL
Web Maps. Section 4.1.4 provides information about AGOL Web AppBuilder. Section 4.1.5.
discusses Web AppBuilder Developer Edition. Section 4.1.6 describes Esri efficiency for ease of
transition of data content to the web mapping application.
4.1.1. Esri For Desktop
Using the Esri software platform offered the ability for ease of transition to go from data
creation all the way to a finished product all using the same platform and ArcGIS API for
JavaScript. The software allowed any necessary layer creation to be made in ArcGIS for
Desktop. The data schema for the assistance needs request points could be created in ArcGIS for
Desktop. The querying of data and data extraction could be done in. ArcGIS for Desktop could
35

also be used to push data layers to the web by creating REST services that would be hosted either
on AGOL or an ArcServer.
4.1.2. REST Services
REST stands for Representational State Transfer, and REST is a type of the architecture
for a web service. REST services are often used for web GIS data and fit the requirement of web
GIS services. All of the data used in the project were available through REST services. REST
services could be served directly to the AGOL map from either servers directly within the Esri
AGOL environment or from servers ran by other companies or agencies.
4.1.3. AGOL WebMaps
Esri also offers the ability to build out a map within the AGOL environment pulling from
all of the REST services as map layers and allows for some customization of the symbology,
transparency, labels, and scale of the map layers. The online mapping platform could allow to set
the levels of the layers and bring in customized map backgrounds. The Esri AGOL platform map
could also be used to query data. The map in AGOL could then be easily made into a mapping
application using Web AppBuilder wizard.
4.1.4. AGOL Web AppBuilder
Web AppBuilder is the built-in web mapping application development tool that Esri
supplies with AGOL. Web AppBuilder allows for the ease of taking a map designed in ArcGIS
to web mapping application in just a few steps. The Web AppBuilder tools allow for the adding
of simple widgets to meet a variety of functions to interact with the map. The widgets can be
configured in the online Web AppBuilder, and certain packaged themes can be applied. The app
could then be released as is or it could be exported out to customize or imported into Web
36

AppBuilder Developer edition for further customization of themes that the online Web
AppBuilder does not allow
4.1.5. Web AppBuilder Developer Edition
Web AppBuilder Developer Edition by Esri allows for the further customization of
themes and codes that can be applied to the code. Web AppBuilder Developer could take
application started in Web AppBuilder in AGOL and allow for important that application and
organizing the code. If an application is directly exported from AGOL, the code is not organized
and recognized as the type of code it is by code editing software. The Web AppBuilder
Developer software allows for the code to be important and organized as well as customized
themes that could be applied to multiple applications.
The application could then be exported so that further code editing directly to that
application alone and the code to apply to several applications. The Esri ArcGIS API for
JavaScript is set up to support customized use of Esri tools, and for developer applications to be
registered and rehosted on another web server. Changing all the code using the Esri API for Java
Script was more advantageous because the code be changed directly to the application itself
rather writing large amounts of new code to create new widgets and other map interaction. The
code was already in place and only had to be customized around the previously developed Esri
Web AppBuilder framework.
4.1.5.1. Code and File Customization Software
Adobe Dreamweaver and Photoshop were chosen as the software to write and customize
code and photo files. Dreamweaver allows for a local site to be set up to organize files and how
they appear on the remote web server site. Dreamweaver also allows for the application code to
37

be edited and published to a web server. Firefox inspector tools were used to identify specific
code that needed to be changed in the application.
4.1.6. Esri Efficiency
Using the Esri software platform, Web AppBuilder framework, and the ArcGIS API for
JavaScript efficiency supported consumption of data and allowed creation of the application
through multiple phases without required additional mapping software platforms and APIs. The
Esri API could meet all the functionality requirements for the desired functionality through easy
to create widgets through the Web AppBuilder. Custom code would not have to be written to
actually create the widgets themselves. The Esri application code could also be customized easily
to meet UI/UX requirements. The Esri API also allowed for the ability to deploy the application
to the public without having to log in and the application be free to the user.
4.1.7. Code and File Customization Software
Adobe Dreamweaver and Photoshop were chosen as the software pieces to further
customize code in the application and photo files of the application. Adobe Dreamweaver
allowed for the local site to be set up to organize the files and how they would appear on the
remote web server site. Dreamweaver also allowed for the application code to be edited and
pushed to the web server. Firefox inspector tools were used to identify specific element code that
needed to change in the application.
4.2. Data Sets, Sources, and Preparation
This section details the data that was used in the application and the processes for
preparing each to be served into the web map in order to meet the required data layers. The data
includes the following: preparation needs assistance requests, shelters, fault lines, liquefaction
38

zones, landslide zones, hospitals, urgent care facilities, community senior centers, and nursing
homes. Data in the application comes from several different sources, including federal, state, and
local agencies. All data is loaded to the application in the form of REST services. Table 1 shows
the data included the application and the source from which it comes from. Section 4.2.1 details
the shelter data. Section 4.2.2 reviews the earthquake-related data. Section 4.2.3 discusses
emergency service data. Section 4.2.4 discusses nursing homes and senior community center
data.
Table 1. Data Sets and Data Sources
Data Set Source Format
Faults LAHub REST
Liquefaction Zones CGS REST
Landslide Zones CGS REST
Shelters FEMA REST
Wheel Chair Accessible Shelters FEMA REST
Nursing Homes DHS REST
Senior Centers LAHub REST
Hospitals DHS REST
Urgent Care Facilities DHS REST

4.2.1. Shelter Data
Data on shelters were sourced from the FEMA National Shelter System. The data layer
contains shelter locations that are in the National Shelter System. The information for each
location contains the place name, address, city, and other information, such if the shelter open or
closed. The shelter data also has information concerning ADA compliance and wheelchair
accessibility. The data was available through a REST service by way of a Feature Access service
and a Web Mapping Service. The service proved to be unreliable early in the development
process because of server maintenance issues. The data had to be exported, filtered, and re-
39

hosted. The shelters were queried to the Los Angeles area and then extracted to a file
geodatabase. The shelters would be timestamped as of the day they pulled extracted to be used
only for the prototype application for testing. The features were then shared to USC SSI’s AGOL
account to be used as feature access layers. The layers were broken into all shelters and
wheelchair accessible shelters to notate the difference and make it easier to locate shelters that
had wheelchair access.
4.2.2. Earthquake-Related Data
Data on fault lines, liquefaction zones, and landslide zones were added to the application.
The fault line dataset was sourced from the LA Geohub AGOL organizational account which is
owned and operated by the City of Los Angeles. The data was originally provided to them by the
California Geological Survey. The service provided clear, simplified fault lines which fall in line
with the principles of simplified symbols over use of complicated symbols. The fault line had a
single symbol as opposed to other fault line layer services on AGOL. Other fault line data
services such as the one from the USGS had the layers broken into multiple different types of
faults. The LA Hub only had the fault line along with the name for the fault.
The liquefaction and landslide hazard datasets were sourced from ArcGIS servers
produced by the California Geological Survey. The REST service links for each service provided
polygon areas of hazard that allowed the ability to be individually added and symbolized to
ensure that layers contrasted clearly within the map. The California Geological Survey is the
authoritative source for these layers, which ensures data integrity, and using their services
ensured that the data would be up to date in the application.
40

4.2.3. Emergency Service Layers
The emergency service locations were added as a REST service from a FEMA server that
is comprised of the Department of Homeland Security Homeland Infrastructure Foundation-
Level Data. The dataset is curated by the United States Department of Homeland Security and
contains GIS data from multiple different parts of the infrastructure. The infrastructure data set is
commonly used by government agencies during emergency situations because the dataset has
locations of places that are emergency related such as hospitals, urgent care facilities, and police
stations, etc. Only hospitals and urgent care facilities were chosen in order to simply the map
layers to adhere to limiting the number of layers in the application for ease of use for older users.
4.2.4. Senior Reference Layers
Nursing homes and community senior centers were added to meet the requirement for the
senior reference layers. The nursing homes and community seniors are both feature layers of
reference for the older adult community. The senior reference layers are sourced from REST
services online. The nursing home location layer was sourced from the FEMA server storing the
infrastructure datasets, and the senior community senior centers were sourced from the LA
Geohub AGOL organization which is run by the City of Los Angeles. The data is created and
served out by partners of the City of Los Angeles. Both layers were added from reliable sources
to ensure data integrity for emergency planning.
4.3. VGI Layer Preparation
To meet the requirement of allowing users to add assistance request points to the map, a
new dataset had to be created for the data points to go in. First of all, the data schema had to be
created that contained the type of attribute information that could be created, such as assistance
request type and description fields. The data template and REST service were created by the
41

developer for this project based on the requirements to meet the web-based data requirement and
the requirement. The preparation needs assistance request points layer was created using the
software ArcMap for ArcGIS. The types of requests were created as domain types and then
added to the field of the assistance request points. Figure 4 shows the setting of the database
property domains for the preparation needs assistance request points. This was set up to create an
easy to pick from template of point types to choose from. Once the points were created, the data
layer was saved and then shared as a web feature access service to the USC SSI’s organizational
account on arcgis.com. The web feature access service was then set to be editable by users so
that the map feature layer could be edited in the map.

Figure 4. Preparation Needs Assistance Request Point Domains
4.4. Customizing the Map Background
Map backgrounds in web maps are typically comprised of vector map tiles or raster
imagery tiles added to give the map reference for the operational layers to be layered against.
The application was designed and built using the Esri API and the Web AppBuilder. The Esri
42

Web AppBuilder offers a small variety of out-of-the-box map background layers. The out-of-the-
box map backgrounds are tiled layers that bring detail based on the scale. The larger the scale,
the more detail the map provides.
To meet all of the application map and layer design requirements, the application needed
a background with a simplified map removing and combining some detail, high contrasting
features, and larger, clear map layers and symbols. None of the out-of-the-box map backgrounds
in Web AppBuilder met those needs. An example of an out-of-the-box Esri basemap can be seen
in Figure 5. Therefore, the project development used a relatively new vector tile style editor that
Esri provides to customize a map background.

Figure 5. Screenshot of Non-Customized Esri Base Map
Using the vector tile style editor shown in Figure 6, a base map was chosen and edited to
simplify and bring out a higher contrast. The map background colors were changed to tan, and
the roads were changed to dark black so they would contrast well from the background. The
roads were set to appear more detailed the more a user zoomed in user was. The scale level of the
43

roads was set that the most detailed roads only turned on when zoomed in to the community
level to make the map easier to see without all the roads cluttering the map when zoomed out.
The labels were set to the highest contrast possible and increased in size to make the font larger.
Fonts were also set to sans serif and bold as those fonts are easier to read online for older adult
users (Johnson and Finn 2017). Water layers were all turned to the same color of blue, and some
smaller bodies of water were omitted to simplify the map. Buildings were set to only appear at
the 17
th
scale level to declutter the map at smaller scales. Only the largest of parks and forest
areas were set to be displayed unless zoomed into the map, in order to simplify the default map
extent map. Place names were only shown for larger cities, and they were shown with larger
fonts and bold outlines.

Figure 6. Tile Style Editor
The finished customized map background consists of the edited and customized features
and label text (Figure 7). The map features a more common single base brown/tan color that
44

makes features easier to see when overlaid on top of the base map. The base map features less
detail at larger scale levels with larger labels with high contrast. The roads also display a
simplified symbology, and many other background features were set to be not displayed. The
roads were also symbolized to show more contrast against the background by choosing black and
dark grey as opposed to light colors.

Figure 7. Screenshot of Customized Base Map
4.5. Map Creation
The next steps were to bring all the data layers together into a single map and customize
the map. Section 4.5.1 discusses bring the map layers together in the mapping application.
Section 4.5.2 describes applying symbolization. Section 4.5.3 discusses creating pop-ups for the
map layers for identification.
45

4.5.1. Adding Layers to the AGOL Map
The map was opened on AGOL within the USC SSI organizational account to begin
adding layers using the add layers button. Layers that were hosted within the developer’s content
on AGOL were added by doing a simple search for layer names. The other layers that are hosted
on AGOL by other users were added by searching for layers in AGOL and clicking the add layer
button. Layers that were not hosted on AGOL and were hosted on outside REST services were
added using the search for web layer and copying in the URL to the individual REST services to
add them to the map. The layers were ordered so that shelters would be on the top, the senior
centers and nursing homes below that, the emergency services below that, the earthquake related
layers beneath those, and the assistance request points just above the customize map background
layers.
4.5.2. Symbology
After the map layers were added to the map, the symbology was set for the map layers.
The symbology of the layers chosen was based on the design requirements for mapping for older
adults. Layers were simplified to make the map clearer and set to be scale dependent so that they
would only turn on when the map was zoomed in.
4.5.2.1. Shelter Symbology
Shelter layers were symbolized with commonly recognized shelter symbols in high
contrast against the background map. Wheelchair accessible shelters were symbolized with
FEMA’s symbology, which features a green square with a wheelchair symbol (Figure 8). This is
a common symbol for wheelchair accessible places. All other shelters were shown with the dark
grey and white shelter symbol from the Esri template for shelters. Since this was the symbology
template used by Esri, it is commonly known shelter symbology and should be easily
46

recognizable. This symbol choice provided high black and white contrast and would not blend
with the green wheelchair accessible shelters.

Figure 8. Shelter Symbology
4.5.2.2. Emergency Service Symbology
Emergency service features were symbolized with commonly used symbols for
emergency services so that the layers would be recognizable (Figure 9). The points were set to be
at a high contrast with a map background and with other symbols. The point symbology was set
to 40px sizing, which is larger than the normal default setting for the symbols chosen. Hospitals
were symbolized with a black H in a white square box, which is a common symbol for hospitals.
Urgent care facilities were symbolized with the common red symbol for emergency medical
care.

Figure 9. Emergency Service Symbols
47

4.5.2.3. Earthquake Hazard Layers
Earthquake hazards were symbolized to identify areas of hazards so they could easily be
distinguished and understandable. The earthquake faults were symbolized with thick red lines. In
a lot of the datasets found available, the earthquake faults are broken into many pieces and
categories for the type of fault; for simplification, faults were shown as one consistent line
symbol that would pop against the map background (Figure 10).

Figure 10. Earthquake Hazard Symbols
The liquefaction layer was given a light blue color that shows up well against the tan map
background and does not blend with other layers. The landslide hazard zones were symbolized
with a light pink color as to contrast well with the other layers in the map. Both the landslides
layer and the liquefaction layer were set to medium transparency so that the map background
could be seen through polygon symbols. Below shows the symbology used for the earthquake-
related hazards. Figure 11 shows the map with the liquefaction, landslide, and fault layers turned
on.
48

Figure 11. Screenshot of Earthquake Hazards Map
4.5.2.4. Senior Reference Layers Symbology
As with other layers, the senior reference layers symbology was chosen to contrast with
other layers and the background (Figure 12). Community senior centers were represented as
point symbols with a building and flag representing a meeting place as senior centers are
locations that some older adults will meet for activities and events. The colors in black and white
show up against the tan map background and do not blend with other layers. The nursing homes
layer was chosen based on familiar symbology with the word home. The house symbol from Esri
templates was chosen for this layer.
49

Figure 12. Senior Reference Layer Symbols
4.5.3. Setting Layer Pop-Ups
A key functionality requirement for the application for users to be able to identify
features of the map. To meet this desired functionality, pop-up information boxes were added to
the map layers. Pop-ups were set to provide information on what the map layer is, and the
specific feature clicked, such as a place name, address, phone number, or other information.
The typical pop-up within Esri AGOL display either one attribute, a list of attributes in
table format, or a customized format. In order to show different attributes and to be able to
customize the pop-up, the custom pop-up was chosen. The HTML customizations provide
options for font choice and size to make the information appear larger than the default popup.
Pop-ups for the earthquake hazard layers were set to show only the name of the layer. Pop-ups
for the reference layers and the emergency service layers were set to show the place name,
address, and phone number. Pop-ups for the shelters were set to show the shelter name, address,
and city (Figure 13).
50

Figure 13. Shelter Pop-Up Code
4.6. Base Application Creation in Web AppBuilder
The base application was created in Web AppBuilder in two processes. Section 4.8.1.1
will discuss the process of setting the theme, color, and title. Section 4.8.1.2 will discuss the
process of selecting and configuring the base widgets.
4.6.1.1. Selecting Theme, Color, and Name
The first step in the process of creating the base web mapping application was to choose
the application theme from Esri’s set of out-of-the-box themes (Figure 14). The dart-controller
theme was chosen because all of the tools and the title of the application all appear in a container
at the bottom of the application. Using the dart controller theme would be easier to use as it
makes navigating the functions easier in order to meet the easier application navigation
requirement. Many of the other themes had buttons all over the interface rather than having them
51

all along the bottom. The dart theme also has individual panels that open as windows when the
widget buttons are clicked on. The panel windows can be individually closed also when the user
is finished. Research on older adult applications suggested that keeping the buttons together
would make using the application easier for older adults. Other themes the widget buttons and
titles all over in different places and different tabs.

Figure 14. Dart Theme Layout
The color of the theme was also chosen as red because red is often associated with
emergency application apps and draws attention (Figure 15). The red color also contrasts well
with other elements that might be on the device screen. The color theme controls the color of the
title bar, panel bars, pop-up box wrappers. The name was initially set to the EQ Preparation
Application, but it was renamed later to EQ Prep App to be shorter due to sizing constraints on
smaller screens during a later step.
52

Figure 15. Web AppBuilder Theme and Style
4.6.1.2. Application Widgets
The next step in the base application was to choose and configure the widgets. Using
Widget Wizard in Web AppBuilder (Figure 16), the first group of widgets that were added to the
app to the left of the ellipses included the Zoom Slider, Home, Zoom to Location widgets in
order to meet the requirements to be able to zoom in and out and find location. The second group
of widgets that were added to the app to the right of the ellipses included the About, Legend,
Operational Layers, Print, Edit, and the Nearest Widgets. The nearest widget was added twice to
be able to find nearest shelters and nearest emergency services. These widgets were added to
meet the requirements of printing, turning on and off layers, adding points, and finding the
nearest emergency services. Adding the Legend widget helped with meeting the requirement for
identifying features, but the pop-ups configured in 4.5.3 also helped to meet that requirement.
53

Figure 16. Widget Chooser Panel
The Zoom Slider widget was added to be able to allow zoom in and zoom out functionality
to the map. The Home widget was also added to allow the user the functionality to back to the
default location of the map. The map default location was set to show the entire Los Angeles metro
area. The Find My Location widget was added to give the user the ability to zoom to their location.
The widget asks the web browser for permission to use the device’s location. When the widget is
turned on, the map will zoom to the area and show a blue location marker on the map.
The Application Information widget was added to display information about the
application, such as a demo link, how to document link, and disclaimer information. The About
widget was set to be turned on when the application opens so that the user would see the links
and disclaimers at the outset. The Legend widget was added to the application so that the user
could identify map symbology and associated map layers. The operational layers widget was
added so that users would have the ability to make the map as simplified or detailed as they
would like with the ability to turn on and off layers. The Print widget was added so that the user
54

could print out a view of the map that could be later used away from the application. The edit
widget was added to allow the user to add preparation needs assistance request points. The
Nearest Emergency Services widget was added and configured to let the user find the nearest
hospitals and urgent care facilities. Its widget button was given a customized icon that
represented emergency services with a red cross and white outline. The Nearest Shelters widget
was added and configured to allow the user to find the nearest shelters and wheelchair accessible
shelters. The widget button was given a customized icon to represent shelters. Both of the nearest
widgets were both set to a default 1 mile and to a maximum 5-mile search radius. Once all the
widgets were added, the base application (Figure 17) was complete and ready for further
customization outside of AGOL Web AppBuilder.

Figure 17. AGOL Web AppBuilder Base Application

55

Chapter 5 Application Customization
This chapter discussed the customization of the base application that was created in AGOL Web
AppBuilder. Section 5.1 discusses the steps taken to prepare for the customization of the
application by setting up and using Web AppBuilder Developer Edition and setting up the code
editing software that was used to edit the code and push the application to the hosting web
server. Section 5.2 describes customization of the application code.
5.1. Preparing for Customization
The next step in the process was to further customize the out of the box application
developed using AGOL Web AppBuilder. As the application stood, design requirements were
not all met. The next steps involved getting into the application code files and making the
necessary customization to the application code in order to get the desired results. In order to do
that, the application had to be imported into Web AppBuilder Developer Edition on the local
machine and then exported from Web AppBuilder Developer Edition to a different location on
the local machine to make the necessary changes to application code. Sections 5.2.1 discusses
setting up Web AppBuilder Developer Edition. Section 5.6.2.2 details using Web AppBuilder
Developer edition in order to import the application from AGOL and then exporting the
application from there and why the Web AppBuilder Developer Edition was used for this process
Section 5.6.2.2 details application folder structure after the application was exported from Web
AppBuilder Developer Edition. Section 5.6.2.3 discusses setting up the Adobe Dreamweaver
software and setting up the application to be edited by Adobe Dreamweaver.
56

5.1.1.1. Setting up Web AppBuilder Developer Edition
The next step in the application process was to use Web AppBuilder Developer Edition to
customize the application beyond what is possible in AGOL. The Web AppBuilder Developer
Edition program was downloaded to the local machine with a developer license. Using the
startup batch file within the Web AppBuilder Developer folder, the developer started the
program. The developer edition was then registered with the developer’s AGOL account by
giving an App ID and the Web AppBuilder developer machine’s address which was the local
computer name where the Web AppBuilder Developer was installed. After registration, the Web
AppBuilder Developer Edition was ready to be used to import the base application that had been
built in Web AppBuilder on AGOL.
The fold structure shown in Figure 18 shows all of the top folders directly below the Web
AppBuilder Developer folder. The folder includes the client folder, the builder folder, stemapp
folder, the stemapp3d folder, the docs folder, and the server folder. The code files that affect 2d
applications imported in to Web AppBuilder Developer Edition are stored in the stemapp
directory. The themes files that can be applied to an application are located in the themes
directory and specialized themes can be added there. The widgets folder contains files for the
make-up of the available widgets. New customized widgets can be added here.
57

Figure 18. Web AppBuilder Developer Folder Structure
5.1.1.2. Using Web AppBuilder Developer Edition
The process for using Web AppBuilder Developer for this project was to import the
application and restructure the application files to be edited using a code editing software. The
EQ Preparation Application developed in AGOL was imported into Web AppBuilder Developer
Edition from AGOL using the Web AppBuilder that can be seen in Figure 19 with the
application imported. The Web AppBuilder Developer edition takes the applications from AGOL
and updates the folders and code to be recognized in code editing software. If an application is
downloaded directly from AGOL, the application files are not recognized correctly, and the code
is not organized, as shown in Figure 20. Web AppBuilder Developer takes those files and
organizes the structure of the code so that the code editing software could recognize the files
once the application was exported from Web AppBuilder Developer. The results of what the
code looked like after using Web AppBuilder Developer Edition can be seen in Figure 21. Web
AppBuilder Developer wouldn’t have been used otherwise as the Web AppBuilder Developer
edition allows changes to be made only to code for themes and other common file code to be
applied to the application or other applications once imported. The developer wanted to be able
58

to make changes to the code of the application itself and not make changes to code in Web
AppBuilder Developer Edition that is only for the codes that are in Web AppBuilder Developer
that can be applied to any application. Make changes to the code in Web AppBuilder Developer
wouldn’t change the code to the application itself. If the developer did that, then the base code
would be changed and applied to any application in Web AppBuilder Developer.

Figure 19. Web AppBuilder Developer Edition Window
59

Figure 20. Code Downloaded Directly from AGOL to Local Computer

Figure 21. Code Downloaded to Local Computer Via Web AppBuilder Developer
Once the application was imported and restructured by Web AppBuilder Developer, it
was then exported using the exporting application tool in Web AppBuilder Developer edition to
60

a zipped folder on the local computer that could then be unzipped into separate application folder
(Figure 22) located on the local machine that can then be edited with Adobe Dreamweaver and
pushed to a web server. Section 4.6.2.3 gives a description of the unzipped application folder
where the files to edited for customization were located.

Figure 22. Unzipped Folder Structure
5.1.1.3. Application Folder Structure
In the unzipped application folder shown previously in Figure 23, edits had to be made to
CSS, HTML, JSON, and JavaScript files in order for the application to look and interact as
desired. The structure was set up as the EQAppSite as the top folder name which would become
the site name. The application was housed under the EQAppSite folder. The EQ Prep App folder
contained the notes, configs, dynamic modules, images, jimu.js, libs, themes, and widgets folders
as seen in the figure. Changes had to be made to files in the themes folder, widgets folder, and
the jimu.js folder. The themes folder contained the files related to the theme of the application,
such as styling, HTML codes, and JavaScript files that make the theme pieces work. The widgets
folder contained the files for the different pieces of the application widgets such as the HTML,
61

styling, and JavaScript files. Jimu.js is a class of JavaScript files and CSS files related to the Esri
Web GIS API. The EQ Prep App Folder also contained the main config JSON file
(EQAppSite\EQPrepApp\config.json) that had to be edited, as shown in Figure 23. The main
config file contained much of the code that controls the application content.

Figure 23. Application Folder Structure
The themes folder contained the files that make up the application theme. Since the Dart
theme was chosen, only the Dart theme files were present. The Dart theme folder (Figure 24)
contained folders for notes, dijit CSS, fonts, images, layouts, nls, panels, styles, and widgets.

Figure 24. Theme Folder
62

The widgets folder underneath the main application folder contained the subfolders for
each widget included in the application (Figure 25). Each widget folder contained style.css files
that contributed to the appearance of the application that needed to be customized.

Figure 25. Widget Folder
5.1.1.4. Code Editing Software and Method
Adobe Dreamweaver was the code editing program used for this project. Adobe
Dreamweaver was chosen as it can be used to edit CSS, HTML, JSON, and JavaScript files and
push them to the web server. Since the application was local to the computer before pushing to
the site, changes could not be seen after editing the code. Because of this issue, the site was
pushed to the web server using Adobe Dreamweaver before the customization process took
place. Pushing the site to the web server places all the files related to the site on the local
machine to the web server site. This site was pushed to the USC SSI web server location set
aside for the developer. Dreamweaver copied the site set up and mirrored that structure on the
web server.
Once the application was pushed to the web server, the application had to be registered
with the developer Esri account in the Esri on AGOL in order for the Esri API to work. A record
had to be created for the application in AGOL, and the application ID had to be associated with
63

the application. The application ID had to be copied from AGOL and placed in the main config
JSON file. Figure 26 shows the application ID being associated in the main config file located at
this location (\EQAppSite\EQPrepApp\config.json). Once the application ID was associated, the
application would function properly and come up on the web server.

Figure 26. Application ID
In order to find the code element that needed to be changed, the developer used
developer inspection tools found in the Mozilla Firefox web browser package. Using this method
proved more efficient than search for the correct code to change in the folder structure as some
of the styling code overrides other style codes. Inspection tools were used to find the code
location that needed to be customized and then the developer could make changes to the local
files and then push changes to the web server. The application was refreshed to check to ensure
the changes to the code brought the desired results. Figure 27 shows an example of using the
inspection tools to locate the associated style file that needed to be changed.
64

Figure 27. Inspection Tools
5.2. Customization of Application
The next subsections discuss the customizing process of the application code in
Dreamweaver in order to meet the desired customization for user experience and interface
requirements. Section 4.8.3.1 describes updating the Controller Bar and Title. Section 4.8.3.2
discusses making the changes to the widget buttons on the Controller Bar. Section 4.8.3.3 details
the customization made to what is called the widget panels. Section 4.8.3.4 describes the changes
made to the Legend Widget code for customization of the appearance. Section 4.8.3.5 recounts
the customizations made to the Turn On/Off Layer Widget. Section 4.8.3.6 discusses the
customizations made to the Nearest Widgets.
5.2.1. Updating the Application Title and Title Bar
The Dart Controller Bar is the bar at the bottom of the application that is a part of the
Dart theme chosen previously. The Dart Controller Bar contains the title of the application, the
65

controller tools, and the widget buttons to access the widgets. The out-of-the-box Dart Controller
Bar settings with Web AppBuilder on AGOL had certain limitations as far as the size of the bar
to expand, button size, and certain limitations on the text size. The title text could only go so
large before getting cut off by the bar size. The button sizes could not be changed. Figure 28
shows the Dart Controller Bar before customization. In order to make room for a larger
application title, the application dart controller bar had to be enlarged. The enlargement would
also help make room for larger widget buttons in the dart controller. All of these things would
need to be changed in order to meet the requirements of the application design and functionality.

Figure 28. Controller Bar Non-Customized
The application title size is set in the config file in the main app directory
(EQAppSite\EQPrepApp\config.json). The font size was changed to 14. The font size is also
controlled by the style file for the dart controller noted in the next paragraph. Different files
contain code that can control the look of the application. In some cases, code in the config file is
overridden by other code in different files. For example, the font size is controlled by a config
file and a style file. The title was shortened during this process as “EQ Preparation Application”
was too long when viewed on a mobile device. The Title was changed to EQ Prep App.
The Dart Controller Bar that contains the widgets, tools, and title had to be increased in
order to make room for the larger title and to make room to increase the widget button sizes. The
changes were made in the CSS file for the Dart Controller style
(EQAppSite\EQPrepApp\themes\DartTheme\widgets\DartController\css\style.css). The change
had to be applied to the height of the Dart Controller. The Dart Controller height size was
66

changed to 200px. The Dart Controller title height size was changed to 80px. The font size and
line height for the title were both changed to 60px (Figure 29). The Dart Controller box height
was changed to 80px (Figure 30).

Figure 29. Dart Controller Title and Box Code

Figure 30. Dart Controller Box Code Changes
67

5.2.2. Customizing Widget Button Sizes on the Dart Controller
The next step in the customization process was to make the widget buttons in the dart
controller larger. The two different groups of widget buttons were the tools widgets and the other
widgets. The widget buttons were separated by an ellipsis on the dart controller bar that collapses
the other widgets. The tool widget buttons were on the left side of the ellipses, and the other
widget buttons were located on the right side of the ellipse. The two different groups of widget
buttons were styled separately.
The widget buttons that were to the right of the ellipses were only 24px by 24px in the
base application. The buttons were doubled in size to make them easier to see and to click. The
code had to be customized in a few different files in order to make the desired changes. The dart
controller widget style file
(\EQAppSite\EQPrepApp\themes\DartTheme\widgets\DartController\css\style.css), had to be
edited as well as the JavaScript
(\EQAppSite\EQPrepApp\themes\DartTheme\widgets\DartController\widget.js). The button icon
node image width and height were change to 48px in the style file (Figure 31). Icon node image
controls how large the image was for those specific widget buttons on the Dart Controller Bar.
The icon node was changed in the style.css file from 44px by 44px to 70p by 70px for buttons in
order to make the buttons larger (Figure 32). Height was added to change the height to 80px in
the widget JavaScript file in order to make room for the larger widget buttons for the action
(Figure 33).
68

Figure 31. Icon Node Image Code

Figure 32. Icon Node Code

Figure 33. Dart Controller Widget JavaScript Code
The widgets button icons in the toolbox on the dart controller to the left of the ellipsis had
to be individually increased from 24px by 24px to 48px by 48px (Figure 34). The images for the
buttons also were increased in pixel size from 24px by 24px to 48px by 48px using Adobe
69

Photoshop (Figure 35) Icon node is the button that is pushed. The images for the icon buttons are
sourced from image files in the application folders. If the image sizes were not changed, the
images would have been distorted within the button icon. Instead of being a single image that
would make sense, the image would have been multiplied into rows to fit the size of the button
rather than just expanding to fit the new increase button size. This process was followed for the
Locate, Home, Zoom, and Zoom Out buttons. The container for the dart controller tools also had
to be increased to make room for the increase in size (Figure 36).

Figure 34. Location Widget Button CSS

Figure 35. Image Size Change
70

Figure 36. Dart Controller Tools Box
The zoom slider button contains both the zoom in and zoom out buttons. Both of those
buttons were doubled in size, and the zoom slider itself had to be increased accordingly (Figure
37). The collapse ellipse button between the toolbox widgets and other widgets was also
increased in size in order to match the sizing of the widgets and to make the button easier to click
on to collapse the widgets buttons (Figure 38).

Figure 37. Zoom Slider Changes
71

Figure 38. Ellipsis Collapse Changes
The final widget bar contained a double sized bar, title, and widget buttons with a red
background and white text for high contrast and larger symbols and text (Figure 39). The text
and buttons should be easy to use. The on-hover text was not able to be changed because the
code was unavailable to be customized. On most browsers, the size of the bar can also be
changed by setting the zoom scale on the browser to be larger or smaller. This larger default
setting allows for this bar and buttons to be larger upon default to make the process easier rather
having to have to find the zoom scale on the browser. The controller bar on smaller mobile
devices was too large and covered up a large portion of the screen (Figure 40). The widgets
buttons also must be swiped to see all the buttons. The title was also shortened so that the title
could be larger and still displayed on multiple screens sizes.

Figure 39. Customized Controller Bar
72

Figure 40. Customized Bar on Mobile Device
5.2.3. Customizing the Widget Panel
The widget panel is a window that contains the information that appears when a widget
button is clicked. The top of the widget panel has a title and buttons to close and minimize the
panel. The handle is the top of the window that contains the panel title, minimize button and
close button. The original non-customized widget panels all had dark grey backgrounds with
small white text and small dark grey close and minimize buttons. Figure 41 shows an example of
one of the widget panels before customization. The widget panel was customized to give all of
the widget panels a new look in order to meet the requirements for application design of larger
text, contrasting colors, and easier to use buttons.
73

Figure 41. Widget Panel Before Customization
Changes to the panel handle were made in the panel CSS file that is located here:
(\EQAppSite\EQPrepApp\themes\DartTheme\panels\DartPanel\style.css). The panel title size
was made larger, and the panel close and minimize buttons colors were made darker to contrast
better against the red. The buttons were changed from light gray to dark black (Figure 42).
Adobe Photoshop was used to change the image colors. The font size on the title label was
changed to 20px from 16px. The font color was changed to white from black (Figure 43). The
widget panel handle also was increased to accommodate the larger title and buttons (Figure 44).
74

Figure 42. Minimize and Close Icon Changes

Figure 43: Widget Panel Title Style Code
75

Figure 44. Changes to Panel Widget Handle
The text in the content of the panel was changed from white to black, and the background
of the content pane was changed from grey to a white for better visual contrast. The font size of
the panel text was increased from 12px to 24px on line 83 in the CSS file
(\EQAppSite\EQPrepApp\jimu.js\css\jimu-theme.css)( Figure 45). The panel content text color
was changed from white to black by changing line 113 in the common CSS file in the dart theme
folder (\EQAppSite\EQPrepApp\themes\DartTheme\common.css) (Figure 46). The panel content
background was changed from dark gray to white by changing the code to line 107 in the CSS
file in the dart theme panel folder
(\EQAppSite\EQPrepApp\themes\DartTheme\panels\DartPanel\style.css)(Figure 47)

Figure 45. Widget Panel Content Text Size
76

Figure 46. Widget Panel Content Text Color

Figure 47. Dart Panel Background
5.2.4. Customizing the Legend Widget
The next step in the customization of the application was the customization of the Legend
widget. The original non-customized widget featured a dark grey background, white text, smaller
font, and dark grey close and minimize boxes (Figure 48). The changes to the background colors
and close and minimize were done in the customization of the widget panel section. Changes
applied there apply to all of the widget panels. The Legend text style is set in the Legend CSS
file in the widget directory (\EQAppSite\EQPrepApp\widgets\Legend\css\style.css). The default
font size for this widget was 12px. The widget font size was increased to 24px for increased
readability (Figure 49). The layer symbols in the Legend were not able to be changed in the code
in order to make the symbols larger. The final Legend widget displayed larger black text with a
white background and black close and minimize buttons (Figure 50).
77

Figure 48. The Legend Before

Figure 49. Legend Font Style Code Change
78

Figure 50. Legend After
5.2.5. Customizing the Turn On/Off Layers Widget
The Turn On/Off Layers Widget panel displays a layer list with checkboxes beside each
layer name for turning each on and off. The original non-customized Turn On/Off Layers widget
panel displayed a grey background with white font and small text (Figure 51). The original non-
customized Turn On/Off Layers Widget also displayed dark grey close and minimize buttons and
smaller check boxes with white check marks. The panel color and close and minimize buttons
were previously customized in the step to customize the widget panels discussed in 4.6.3.3.
79

Figure 51. Turn On/Off Layers Widget Before
In order to make further customizations to the Turn On/Off Layers Widget, the styling
would need to be changed to the widget style file. The styling for the text size and checkboxes is
set in the layer list files in the layer list widget directory of the application
(\EQAppSite\EQPrepApp\widgets\LayerList\css\style.css). The layer list title text size was
increased from 14px to 30px in order to make the title of the layer list stand out and be clearly
readable (Figure 52). The layer list item font size was changed from 12px to 24px (Figure 53).
80

Figure 52. Layer List Title Code

Figure 53. Layer List Content Text Size Code
The checkboxes were changed in color and in size for easier interaction. The changes to
the checkboxes were made in the jimu.js style CSS file
(\EQAppSite\EQPrepApp\jimu.js\css\style.css) The size of the checkbox was increased from
16px to 20px (Figure 54). Changing the size to any larger resulted in errors with the line sizing.
The colors were changed to black check marks in white boxes from white check marks against
light blue boxes when checked. When unchecked, the colors were changed from grey boxes with
a white outline to a grey box with no outline against the now white panel background (Figure
55).
81

Figure 54. Checkbox Size Change

Figure 55. Checkbox Background Color Change
The final Turn On/Off layers, widget featured customized title bar with increased title
font size and customized close and minimize buttons with larger, darker black icons that were
made to give more contrast and more area for interacting with the buttons. The widget panel also
featured the customized font sizes that were increased in size in order to make the text more
legible for those that have trouble reading smaller font. The final widget panel also featured a
white background and black text instead of the normal grey background with white text to
increase contrast in order to make the text easier to read. The final widget panel for the turn
on/off widget also featured customized checkboxes for increased visualization for interactivity
(Figure 56).
82

Figure 56. Turn On/Off Layer Widget After
5.2.6. Customizing the Nearest Widgets
Next, the buttons within Nearest Emergency Services and Nearest Shelters widget panels
were both were customized. Although each widget interacts on different map layers, both of the
Near Me widgets are both affect by the same styling codes, so both widgets look the same except
for the information returned and the icons on the dart controller bar mentioned before. Within the
widget panels, a button that looks like a balloon is located on the right side of the panel. When
the button is not clicked, the user must enter a location in the search box of the panel. If the
balloon button is clicked on, then the user can choose a location on the map to search on, With
the base application out-of-the-box code, the balloon button when turned off did not show clearly
in the base application because it blended with the panel background. The balloon was greyed
83

out; and when clicked and turned on, the balloon color was turned to white with a white outline
which also matches the new panel background that was customized. The balloon size was also
smaller and harder to see when turned on in the base application (Figure 57).

Figure 57. Nearest Shelters Widget Before
In order to make further customizations, the style files of Near Me Widget folder had to
be edited and customized. The nearest widget styling code is found in the widget CSS file in the
Near Me Widget folder (EQAppSite\EQPrepApp\widgets\NearMe\css\sytle.css) The button was
changed to be balloon while when turned off so that it would show up even when off. This would
help prevent confusion in how to turn it on. When turned on, the balloon color was changed to
green because green often represents something that is on. The developer made the changes in
the color of the balloon icon image files with Adobe Photoshop. The image files were sourced
84

from the application files older. The balloon icon size was changed from 32px to 52px for easier
identification (Figure 58).

Figure 58. Nearest Widget Balloon Code
The final nearest widget displays for both the Nearest Emergency Service Widget and
Nearest Shelters Widget (Figure 59) featured the same layout and design interacting upon
different feature layers. Both widgets featured increased font size of the titles and darkened and
enlarged close and minimize buttons. The nearest widgets featured changes to the location picker
balloon that allows the user to pick a location on the map rather than to search a location in the
search bar by address. The balloon customization featured a change to the off and on-color of the
balloon in order to make the balloon easier to see and understand that the feature was turned on
versus off. The widget panels also featured changes to the background color and the text color in
order for the text to contrast more. The list picker also featured changes to the fonts and
background color for more contrast.
85

Figure 59. Nearest Shelters Widget After
86

Chapter 6 Results
This chapter describes the final customized application, the training documents and video, and
the results of the application test with the focus group. Section 6.1 discusses the application
results of design changes. Section 6.2 shows the functionality use results. Section 6.3 describes
the application training material. Section 6.4 discusses the results of the focus group application
test.
6.1. Final Application Design and Use Examples
Upon completion of the development process, the application was hosted on the USC SSI
web server at the following URL: https://gis-web.usc.edu/beveritt/EQPrepApp/ (available May
31, 2019). The completed application features a map display along with widgets to accomplish
functional tasks. The application was customized with UI and UX considerations for older adults
in order to make the application more user-friendly. The application was designed for both
laptop/desktop viewing shown in Figure 60 and from a smaller mobile device as shown in Figure
61. The following subsections discuss examples of the use of the application and widgets.
Section 6.1.1 shows the Application Information Widget. Section 6.1.2 provides examples of the
interactivity with the Zoom Slider, Home, and Location Widgets. Section 6.1.3 demonstrates the
use of the Turn On/Off Layers Widget. Section 6.1.4 details the use of identifying a feature with
the legend and a pop-up. Section 6.1.5 illustrates use of the Print Widget. Section 6.1.6
demonstrates the use of the Add Assistance Request Point Widget. Lastly, section 6.1.7 shows
how to use the Nearest Shelters Widget.
87

Figure 60. Final Application Home Page

Figure 61. Final Application Mobile
88

6.1.1. Final Application Information Widget Display
When a user opens the application, the Application Information Widget is displayed
(Figure 62). The final Application Information widget displayed information in the text with
links for the help document and the demo video. The information in the widget also displayed
disclaimers as to what actually was in the application and about the design and purpose of the
application. The widget was programmed so that the panel would open upon starting the
application so that the user could use the links to the demo video and help document that
explains the application parts and functionality. The panel could be closed after reading.

Figure 62. Application Information Widget
89

6.1.2. Example of Zoom Slider, Home, and Location Widgets.
The design functionality was to allow the intended users to be able to zoom around the
map, zoom to their location, and allow the user to return the map to the default location. This
section describes the use of those buttons in the final application. The user pushes the Zoom-In
button in order to make the mapping application zoom in, and the user pushes the zoom out
button to make the map zoom out (Figure 63). When the map is zoomed in, more detail and map
layers appear on the map (Figure 64). When the user uses the Location Widget, the map zooms
the user’s device location (Figure 65). When the user wants to get back to the default map extent
(Figure 66) when they opened the EQ Prep App, the user clicks the Home button (Figure 67).

Figure 63. Zoom Slider Widget

Figure 64. Zoomed in Map
90

Figure 65. Zoomed to Device Location

Figure 66. Default Map Extent

Figure 67. Home Button
91

6.1.3. Turn On/Off Layers Widget Use
As per the default, the map layers in the mapping application are all set to be on but are
also set to be only shown at certain scale levels. If the user wanted to change which layers were
on and off the user, the user would begin with clicking on the Turn On/Off Layers Widget icon
button on the Dart Controller Bar (Figure 68). The user would then make sure they are zoomed
in on the map to ensure that the layer would appear to be on not be greyed out, as seen in Figure
69. When the layers are at the right zoom level for the layer to turn on the layers in the layer list
of the Turn On/Off Widget panel display bolder (Figure 70). If the user, wanted to turn a layer
off such as hospitals, the user would click the checkbox to remove the checkmark to turn the
layer off (Figure 71). To turn the layer back, the user would click the checkbox again to bring the
checkmark back and the layer back (Figure 72). In order to close the Turn On/Off Layers
Widget. The user would click the black “x” button the top right of the widget panel (Figure 73).

Figure 68. Turn On/Off Layers Widget Button
92

Figure 69. Layers Greyed Out

Figure 70. Layers Displayed Bold
93

Figure 71. Hospitals Off

Figure 72. Hospitals On

Figure 73. Close Button
94

6.1.4. Identify Layers with the Legend and Pop-up Box
If a user wanted to identify a layer and information about map layer, the user would
simply find the layer by looking in the map and opening the Legend Widget by hitting the button
icon on the Dart Controller Bar (Figure 74) to make sure they are looking at the correct feature
they wish to identify. After the user compares the map to the legend to make sure they have the
correct feature to click (Figure 75), the user would click on the feature to bring up the pop-up
window that identifies information about that feature (Figure 76).

Figure 74. Legend Widget Button

Figure 75. Legend and Map Comparison
95

Figure 76. Pop-up Activated
6.1.5. Using the Print Widget
If a user wanted to use the Print Widget in order to get an electronic print of the map, the
user would click on the Print Widget button icon (Figure 77) on the Dart Controller Bar in order
to open the Print Widget panel. The user would want to make sure they have the map view set to
what they want to print and have the appropriate layers turned on or off that they want in the
printout. Users would then set their Print Layout, Map Title, and Format. Once the user has set
the parameters for the print, the user would hit the print button (Figure 78). The user can then
open the print file once it has completed creating the map print (Figure 79).

Figure 77. Print Widget Button Icon
96

Figure 78. Setting Print Parameters

Figure 79. Map Print Output
97

6.1.6. Using the Add Assistance Request Point Widget
If a user wanted to add an assistance request point to the map, the user would begin by
zooming to their location using the Location Widget or using the Zoom Slider Widget and
panning with their finger or mouse depending on the device to move to a desired location. Once
the user is set to a location, the user would click on the Add Assistance Request Point Widget
button icon Figure 80). Then once the user opens the widget, the user would select a type of
assistance request that they would like to put on the map (Figure 81). Once the type is selected,
the user places the point on the map and fills out the description (Figure 82).

Figure 80 Add Assistance Request Point Widget Button Icon

Figure 81. Add Assistance Request Point Picker
98

Figure 82. Adding Assistance Request Point to the Map
6.1.7. Using Nearest Shelters Widget
In order to use the Nearest Shelters Widget to find the closest wheelchair accessible
shelters or all shelters, the user would begin by clicking on the Nearest Shelters Widget Button
Icon (Figure 83). Then the user could either use the search bar to search for an address (Figure
84), or use the location picker. In order to use the location picker, the user would have to click on
the black balloon and turn the balloon green (Figure 85). Once the balloon is green, the user can
select a location on the map to search shelters given a radius. The radius can be set from one to
five miles. The widget panel will then display a list of results of the number of each feature
found (Figure 86). When the user clicks on the name of the map layer feature, the panel displays
the locations and their distances (Figure 87). The example would work in the same manner for
the Nearest Emergency Services Widget.

Figure 83. Nearest Shelters Button Icon
99

Figure 84. Nearest Shelters Widget Panel

Figure 85. Activating Map Picker
100

Figure 86. Nearest Shelters Map Pick

Figure 87. Nearest Shelter
6.2. Training Materials
The author developed training materials in order to help older adult users with the
application. The author wrote a document explaining the functionality with screenshots of the
101

application. The document began with general information about the document and the design
the intended purpose. The document then noted the EQ App web address with a live link that
could be clicked on to take the user to the application. The document then gave a view with
screens of the overall application on laptop device and a mobile phone device along with
descriptions of the buttons seen and the map. The next section of the document described the
different application parts, such as controller bar and the widget buttons on the controller bar.
The subsections thoroughly discussed each widget and what the purpose was of the widget and
how to use it. After completion, the document was loaded to the web server at the following
location: https://gis-web.usc.edu/beveritt/Documents/EQPrepAppHelpDocument.pdf (Available
May 31, 2019) The document was then linked in the Application Information Widget Panel. The
document can be seen in Appendix A. The developer also produced a demo video explaining
how to use the application and placed the video on screencast at the following location.
https://www.screencast.com/t/nqcy0iVjL. The link was posted in the Application Information
Widget so that users could click on the link for help.
6.3. Application Test and Results
This section describes the application test and the results of the focus group that tested
the application. Section 5.3.1 details how the application was tested. Section 5.3.2 will list out
the user comments noted during the application. Section 5.3.3 will discuss the design of the
survey. Section 5.3.4 will discuss the results of the survey.
6.3.1. Application Testing
A small focus group was assembled through the USC School of Gerontology with the
help of the School of Gerontology staff in order to test the document. An instructions document
102

and demo video were created to show the application functionality, and a short survey was
drafted for participants to share their opinions on the application content and functionality.
The focus group was held on March 8, 2019, at 12pm PST at the USC School of
Gerontology. It was proctored by two faculty advisors from the USC SSI. The student developer
attended via BlueJeans and provided an instructional walkthrough of the application. Attendees
of the focus group were then asked to review the help document and to test out the application
via their smartphones and laptops provided by the SSI. Surveys were handed out after the test.
As the faculty proctors answered questions and provided help to attendees, the student developer
watched via BlueJeans and took notes.
6.3.2. Comments and Observations
During the course of the application test, the developer wrote down comments from the
focus group of users and the assisting advisors. The developer also wrote down observations
based on comments while the focus group was trying to use the application after they were given
the help document and demo. Comments varied from different testers in regards to application
functionality, design, and usefulness. Below in Figure 88 is a bullet list of user, developer, and
advisor comments and observations that were recorded for results. Chapter 6 will go into a
general discussion of the comments and observation notes.
103

Figure 88. Verbal Comments and Observation Notes
6.3.3. Survey Design
The survey contained three different sections. The first section focused on application
functionality. The first section of questions asked if the functionality is useful and if they could
make the application function for that specific purpose. The second section was based on
application design of the map and map features. The second set of questions asked if the map
layer was useful information to have in the application and if they were able to identify the map
layers and differentiate the map colors. The design process of questions features simple yes or no
questions with a place to put the reasons why a test picked no. The third section of questions was
based on the overall application and were essay type questions that required the user to write the
answer in for those three questions. This third section requested the testers’ opinions. Figure 89,
104

Figure 90, and Figure 91 show the pages of the survey that was given out to tests in the focus
group. Section 5.3.3 will discuss the results of the survey. Conclusions reached from the
application test survey will be discussed in chapter 6.

Figure 89. Survey Questions Section 1
105

Figure 90. Survey Questions Section 2
106

Figure 91. Survey Questions Section 3
6.3.4. Survey Responses
This section discusses the responses of the survey to the application test with the focus
group of users held on March 8, 2019. Section 5.3.3.1 discusses overall response to the
application. Section 5.3.3.2 discusses the responses to section 1 of the survey. Section 5.3.3.3
discusses the responses to section 2 of the survey. Section 5.3.3.4 discusses the responses to
section 3 of the survey.
107

6.3.4.1. Response to the Survey Overall
A total of eight older adults took part in the focus group, and all but one completed the
survey. In regards to the question of the type of device used, six of the eight responded to the
question. Of those six, 100% of those testers used a smartphone to do the initial test of the
application although laptops were available in the room and later used by some. For the first
section of questions, seven of the eight testers responded with answers. For the second section of
questions, seven of the eight testers answered the questions; however, one of the eight was
inclusive what was chosen because the markings were not clearly in the box. Those answers for
section two were thrown out of the results. For the questions in section three, only six of the
eight responded to the overall app survey questions. The next section discusses the answers to
section one questions with more detail.
6.3.4.2. Responses to Section One
Responses to section one included the survey that was not responded to. The developer
included a blank answer to results as other tests left certain questions blank also. The table below
shows the number of yes, no, and blank responses and percentages of yes answers for each. The
highest percentage for section one was for question one at 88%. Questions nine through twelve
were the second highest all at 63% for yes answers. Questions seven and thirteen had the lowest
response of yes at 13%. For the comments as to the reasons many chose no or left blank,
responses included that some users could not get the map layers to appear or the application to
appear on their device. A few users also responded that with more time training and testing that
they could answer yes.
108

Table 2 Survey Section One Question Responses

6.3.5. Section Two
Section two question responses were related to map layers. Testers were asked if the
information was useful or not and if they were able to identify the symbols or not on the map.
Responses vary from yes, no, and blank. All eight of the surveyors responded in some fashion to
the questions in section two of the survey. One tester responded to all questions with no, with the
comment that they were not able to access. One other tester left questions blank for section two.
Table 3 below shows the responses to section two of the survey for the useful section of the
survey. Table 4 below shows the responses to section two of the survey for the identifiable
section.
Table 3. Section Two Layer Usefulness Results

109

For application usefulness, only nursing homes were given below a 50% score of yes as a
useful map layer. Those in the focus group only gave nursing homes 38% for usefulness in the
mapping application. The highest yes responses were for landslide layers and fault lines at 63%
useful. All other layers were seen as 50% useful. However, a few in the test group did not
respond. Also, one responder’s results for section two were counted as blank as the marks could
not be read. The results could have been higher if the questions were answered or been legible;
however, the answers could have also been no for those questions.
Table 4. Section Two Layer Identifiable Question Responses

For being able to identify layers and map symbols, the users responded with much lower
percentages. The highest percentage was 38% for seven of the layers listed. Only 25% of the
survey responders said that they were able to identify the landslide hazards and fault lines.
According to comments listed on the survey as to why the survey responders checked no or left
blank, they could not get the layers to come up in the application, and the layers needed to be
labeled better for what each layer was. Another surveyor commented on the survey that they
needed more explanation of what the layers actually were.
110

6.3.6. Survey Section Three
Survey section three responses provided an opportunity for users to answer questions in a
few words or sentences. For question one, “Is this mapping application useful for earthquake
preparation? Why or Why not?”, those in the focus group that responded to the survey responded
with answers like: “The idea is great!”, “Knowing where you live in reference to more dangerous
areas let you know what you have to prepare for,” “need more time to evaluate,” “no,” “yes,”
and “very, useful. It allows you to find nearby help in an emergency. I was easily able to identify
my house in an emergency.”
For question two, the survey asked if there were any other map features that needed to be
added to the application. Only four responses to this question were recorded. The responses were
as follows: no, shelters for large animals such as horses, markets, and food. Food and markets
could be grouped together; however, they are left separate because more can be bought at
markets than just food.
For questions three, the users were asked what could be done to improve the application.
The responders to the survey commented that more time to practice the application would be
helpful along with step-by-step guides. Another responder commented that the site was not very
good for the mobile phone because their phone kept losing site access. The same responder also
commented that the site was harder to navigate on the phone. Another responder comment that
they could provide more information if they were able to get the application to work better.
111

Chapter 7 Conclusions
This chapter looks back on the project as a whole, discussing issues that arose during the
application development and future research and development possibilities. Section 7.1 describes
issues found with data, software, and methods. Section 7.2 discusses the issues found with the
application results and the possible final application considerations to fix issues. Section 7.4
discusses future research that needs to be done. Section 7.5 gives the final conclusion
7.1. Issues with Data and Software
This section describes issues with the data, software, and methods encountered during
this project. Section 7.2.1 summarizes challenges in working with the data. Section 7.2.2 details
issues with the software. Section 7.2.3 will discuss issues with the methods.
7.1.1. Data Issues
The main issues with the data used in the application were based on integrity of using
data from other resources. One of the users in the application test commented that one of the
locations of a hospital is the location of a now-closed hospital. The data from for the hospitals
comes from a Department of Homeland Security (DHS) server. The developer is unsure how
often the data is updated; however, the DHS maintains this infrastructure dataset and is the
authoritative dataset. This issue with the dataset brings attention to the overall data integrity of
using data from other sources that could not be up to date. When preparing for emergencies and
knowing locations of places, knowing the correct location is very important, and data that is
incorrect could lead to people preparing to go to the wrong place.
Another issue with the data was based on the integrity of the system from which the data
is sourced. The FEMA Shelter server that houses and servers out the FEMA National Shelter
112

System web service data proved to be very unreliable throughout the development process. The
shelter server would be offline during times of development, which caused the application and
map to lose the data. The data had to be extracted and rehosted in a more reliable place, on the
USC SSI AGOL with a timestamp. Having to extract the data and rehost makes the information
only reliable for that timestamp because it is no longer connected to the authoritative dataset
being updated by the agency that oversees the program. The data was only good for testing. In
the future, issues need to be worked out with the FEMA Shelter web service.
7.1.2. Software Issues
One of the main issues experienced was with the chosen software platform of Esri
ArcGIS API for JavaScript and the Web AppBuilder framwork. Although the Esri software was
efficient in bring the map together in the web environment and allowing for redeployed
customized code, the API had a few limitations that proved to either be difficult to address, or
the code could not be accessed. The API works with web GIS; however, the API is not readily
customizable for multiple devices, such as to run on an iPad and a mobile phone, for the same
application. Changes to the code that made the widget buttons larger and the widget panels larger
caused issues with the application on the smaller screen mobile devices. Because those items
were enlarged based on a laptop device with a larger screen, the widgets buttons on the
Controller Bar were too large and would not appear on screen. The API did not adjust the
controller bar between devices so that all buttons were display. The widget panels would also
cover up the whole screen on smaller mobile devices. The API and application code did not
adjust for the smaller screens. The buttons needed to be larger and the text in the panels needed
to be larger; however, the code did not offer more a smaller screen friendly version of the
113

application that when opened, buttons and text were still large but not covering up the entire
screen and were still easily navigable.
The Web AppBuilder framework caused issues when certain code could not be updated
because the code resided on an Esri server that could not be touched. It was evident that Esri did
not want that code being edited; however, that code would have helped in making customizations
to make the application more user friendly. One example of the code not being edited because of
this limitation is with the space in the editor widget.
The Esri API use of sprite images for several icons impeded customization. A sprite
image contain several images per file. When the developer would try to enlarge a button icon,
more of the images would appear. The sprite images need to be changed to allow single icon
images per image file. This would allow for more customization.
The Esri API code was also not very well documented as to what code was in which
folder and what items were controlled by what code and file. The developer had to use inspection
tools in the browser to find certain elements to customize. If there was more documentation as to
where items were located in the code and folder structure, the developer could have made
changes to the code more easily.
Another issue with the software code was the inability to change the hover text when an
object is hovered over using the mouse. The developer even asked on Esri forums, and the
consensus was that the code couldn’t be edited. Limiting this ability didn’t allow the developer to
fully customize the information description of the buttons.
7.2. Application Results Discussion
Chapter 5 described the results of the development and of the focus group’s test of the
EQ Prep App. This section of chapter 7 summarizes key issues identified in the focus group and
114

how those issues can be addressed going forward. Section 7.2.1 discusses the application
accessibility issues and ways to address the issues. Section 7.2.2 details the need for additional
application training for users. Section 7.2.3 describes the issues with application terminology and
ways to address the issue. Section 7.2.4 analyzes the issues with text design. Section 7.2.5
examines issues with map layer design. Section 7.2.6 looks at application button issues. Section
7.2.7 discusses issues with device design.
7.2.1. Application Accessibility
Testers had difficulty reaching the application by way of the provided URL. Some testers
responded that they did not have internet on their phone. Some users were unaware of what the
browser was or if they had one. Some users had issues typing the long string into the browser.
Based on these issues, the developer believes an easier way to access the application needs to be
designed. Using a QR code or native application that could be downloaded to the device might
prove easier to use to get to for the older adult users. If the design is to be more user-friendly for
older adults, the way the users get to the application must be easier to access than the URL.
7.2.2. Application Training
A good portion of the focus group needed help operating the application. The help
document developed and live demonstration of the application were not enough to help the users
with the application. The comments from the focus group suggested that they wanted a step by
step tutorial and training exercises to learn how to use the application. The focus group also
wanted more personal assistance with the application and want more help while using the
application. In order to meet the needs of the intended audience and users of the application, a
step by step document and training classes need to be developed in order to help the application
be more successful with older adults. Assistants should also be trained on the application in order
115

to help and train the older adults with the application. Training documents also need to be
included to help with map terminology describe different map features such as liquefaction. The
developer believes that more training for the application could lead to a more successful
deployment of the application and a more successful application test response.
7.2.3. Application and Map Terminology Issues
Based on a few of the comments and survey responses relating to the description of the
application features and the map, there appeared to be an issue with the terminology of the
application. The testers mentioned that they did not know what some of the application features
were and did not understand some of the names of the layers in the table of contents. They
commented that a better description of the application buttons and may layers would be useful to
understand what buttons and layers were. Several testers also did not answer favorably to being
able to identify map features in the survey. Future considerations for the application should
include labels for features describing better what buttons do. Using labels for buttons could help
users identify buttons, and having a feature description or glossary could help explain
terminology. The developer should also consider testing more common terminology for the map
layers with those in the older adult community as well as adding a glossary of terms that explains
map features and application features.
7.2.4. Text Size Issues
Although all testers recorded that they could read the text, one of the advisors noted that
differences in text size in the application could be causing issues with the testers and that the text
sizes should be more standardized throughout the application. The application text sizes come
from many different CSS files within the application and are many different sizes in the original
code provided. The application development process only considered increasing the font sizes,
116

but the developer did not consider standardizing the fonts across the application. The method of
increasing the font sizes was only meant to test changing the code in the API and to see if the
changes to size were readable. The pixel sizes were to at least larger than 14 pixels and the
larger, the better as long as the text could fit within the space on the screen and be easily
readable.
The developer could consider standardizing the text in the code within the API more so
that the text sizes would not be several different sizes. The customized application should be also
be tested against a base application with no code changes to text sizes in order to get a better
result if the users could read the text in a non-customized application. Testing the customized
text against the non-customized text would show which customized text was more necessary to
change.
7.2.5. Map Layer Issues
This section discusses issues found with the map layers chosen for the application and the
design of the layer symbology. Many of map layers were added based on developer experience
with emergency applications with commonly used features, past earthquake applications, and
interviews with the Department of Aging LA, the EOC in LA, and the School of Gerontology.
The results of the application test gave a clearer picture of what older adults would users in the
audience would like to see in the application.
The results showed that certain map layers should either be combined or removed. For
the earthquake-related, only fault lines and landslide zones were seen as useful by the testers.
The liquefaction layers were not seen as useful by the testers. Some of the users verbally
mentioned that they did not understand what a liquefaction zone was. Based on those comments,
the application needs to either clear out jargon terms or better describe them as mentioned in the
117

terminology issues section. The liquefaction layers could also just be deleted in future
applications or combined in with landslides hazards as an overall earthquake hazards layer to
further simply that there are earthquake hazards but not break down the different types. Doing
this may help clear up the issue with liquefaction. Based on other responses to the survey to other
layers and what layers should be added, the developer believes that the nursing homes should be
removed from the application and that places for food should be added along with animal
shelters for larger animals.
As far as being able to identify the earthquake features, those all scored very poorly,
which was surprising as much attention was given to the layers and how they were identified.
The liquefaction and landslide zones were both polygon layers set with 40 percent transparency,
so the layers may have been hard to see on the map if displayed together due to overlap. Users
may also not have seen the layers if they were not zoomed to where the location of the layers
were. If the users were not zoomed to an area of where those features were, they wouldn’t have
seen them. As the layers were also set to be scale dependent, the layers were not seen when the
app was opened. The developer believed that to have an effect on how the questions were
answered for layer identification. The final application layers should also be set with scales but
explained more clearly that the layers are scale dependent. The legend for the map was also
closed so the user would have to open it to be able to see the legend and get the corresponding
feature for the symbols. So, the application might benefit from having an open docked legend
that explains the symbology. Having the open legend would allow the user to see the map and
corresponding explanation of the symbols they are seeing. Having a closed widget makes the
user have to open the legend widget. The developer believed that possibly there might have been
118

too many layers to interact with to begin with. The application could benefit by further limiting
the number of layers.
7.2.6. Button Design Issues
The major issue found with the buttons is that the users had issues with completing the
functionality for a few of the widget buttons. The users either didn’t understand or didn’t get to
the widget buttons in time for the testing. The developer believes that based on the results of the
test that the application may have had too many buttons for the older adult users to be able to
learn and use. The developer believes that having the basic map with the Pan, Home, Zoom, Find
Location, and the Find Nearest Shelters would be more of a suitable amount of functionality. The
developer believes that based on the results of the test that the Nearest Emergency Services, Turn
On/Off Layers, Print, and Add Assistance Request Points widgets should be dropped from the
application. The developer believes that layers should be set to be always on, but reduce the
number of layers shown instead of giving the ability to turn them on and off. The developer also
believes a simple search widget needs to be added so that users can just search for different
places in a search bar similar to the functionality in a google map search engine. With these
changes, the application may be more successful in tests of button functionality with testers.
7.2.7. Device Design Issues
Many of the issues were in relation use of the device itself rather than the application.
The results backed up previous research noted in Chapter 2, that larger screens were better for
older adult user design. All of the testers used mobile phones first, and then some tried the laptop
version. Most of the users testing mobile device experienced issues. Several of the panels for the
widgets would cover up the entire screen on mobile devices, a design limitation. Users
commented that they could not see the map on the screen or when going back and forth from the
119

widget panel to the map on the mobile phone device. All widgets buttons on the Controller Bar at
the bottom of the application displayed on larger screen devices such as laptop. On smaller
screen devices such as a mobile phone, the full bar at the bottom of the screen with all of the
widgets was only partially displayed. The user had to scroll through the widgets or swipe over to
see the additional widget buttons on the controller bar at the bottom of the application. Other
issues with devices were based on functionality; some users had issues with opening popups
widget panels. The developer believes that based on the results of the survey and comments
made by the mobile phones users, that there was not have enough screen space to see how to
open and minimize widgets or to allow the touch screen to function properly. After the users
tried the laptop version, the users commented that the laptop version was better because the
screen size allowed them to see things better.
Based on the comments and these observations, the developer needs to consider the
design of laptop and mobile versions separately. For example, a mobile version should show
more clearly on smaller mobile phone devices when designed only for mobile phone use. The
developer could then focus on the design for each. The application for mobile phones should be
designed as a native application that could be easily downloaded from an app store to the phone.
The laptop or desktop version should be shared with to the user via a link, so the user does not
have to type a URL. Separate applications would also allow for more specific layout designs to
be tested that could result in easier to use applications easier to use. The developer felt that based
on the results of the final application and test, the application was much more useable on a laptop
because of the larger screen, and using a mouse allowed for more room for larger text and
buttons. Creating a mobile-only version, the developer could focus on the mobile design for
120

buttons that are based more on mobile native application design rather than browser application
design.
7.3. Future Research and Development
This research project took on looking at design and develop of an earthquake preparation
web mapping application using a certain set of methods and software to meet the needs of older
adult users with UI and UX design-based customizations to the application code. Based on this
research, different areas can and need to be explored to truly understand designing web mapping
applications for older adult users. This section will discuss the future research the needs to be
done in order to fully understand the best methods, software, hardware, and deployment
strategies to serve the older adult community needs with web GIS applications. Section 6.4.1
discusses the future research needs into UI and UX design for older adults. Section 6.4.2
discusses the future research needs about relevant software. Section 4.2.3 discusses future
research needs into hardware used. Section 4.2.4 discusses the future research needs of other web
GIS applications geared toward older adults.
7.3.1. Future UI/UX research
Based on the results of this project, more research needs to be conducted into more
productive UI/UX changes than just changing button size, text size, and color contrasting. More
research needs look into working with older adults with physical ailments that may be harder for
them to operate the application in the current design. Future research also needs to be done to
look at audio commands and audio instructions for those that have issues seeing and using a
touch screen or a mouse. Future UI/UX research needs to be conducted using a focus group of
older adults to use different versions of designs in order to compare varying designs. Multiple
121

avenues are available for research in this field to design more user-friendly web GIS applications
for older adults.
7.3.2. Future Software Research
For this project, only Esri software, Web AppBuilder framework, and API for Javascript
were used for the main design and platform for this application. While the software was able to
create an application with the design functionality, some of the UI/UX changes could not be
accomplished. Other software needs to be researched that could accomplish all the UI/UX
desired changes to images and buttons.
Another issue that was found was that some of the Esri direction services provided in the
Nearest Widgets are Esri subscriber only proprietary software that requires credits and tokens to
be saved within the application registration. Use of the subscriber content or proprietary software
might not be the best long-term solution for an application that needs to be completely open to
the public. All services need to be researched more to find services that do not rely on subscriber
tokens to work. If the application became widely used, the cost would become a burden for the
developing organization. Limits can be set on how much the service can be used, but that would
limit the application.
The application was also browser-based, which produced some limitations shown in the
testing. For the future, other software needs to be tested to discover the success of the software at
creating similar applications with functionality. Other software may provide more functionality
such as better customization options to meet the UI/UX needs of the application. Future research
into the software used for a web mapping application for older adult users can only increase the
success of those types of applications.
122

7.3.3. Future Hardware Research
Based on the results found with issues into the design for multiple devices using one
design, future research must be done on the types of devices would be best for the deployment of
the application. The larger font and buttons customizations worked best on devices for larger
screens. Future research needs to be done in design for the smaller screen devices that many
users have in possession and the device the test group started out with. Research needs to be
done into what devices are best for older adult users and what devices older adults use the most
so that the design can be better driven toward different devices. As suggested earlier in the
document, users would benefit from a separate application designed for different types of devices
such as smaller mobile devices over larger scale devices such as laptops and desktops. Hardware
research would benefit the success of a web GIS application for older adult users.
7.3.4. Other Applications
The final future research consideration is the need to research other applications geared
toward older adults that can be used outside of Los Angeles and for other emergency events. As
the research suggests in Chapter 2, older adults benefit for maps and apps designed specifically
for them. One of the testers in the focus group mentioned the need for a mapping application for
other devices outside of earthquakes. Future research and development need to be done for other
emergency events that affect the area, such as wildfires. Another user mentioned that it would be
great if the application was design for use outside of LA. This research for this application could
be applied to other areas outside of LA and for multiple events. Research into multiple
emergency types and pre, during, and post-emergency event should also be done as all parts of
emergencies are important, and older adults could benefit from the research into apps for all
123

phases. The field is wide open for research for different types of emergency applications
designed for older adult use.
7.4. Conclusions
Overall, the purpose of this application was to research the design and development of a
web mapping application for older adults of Los Angeles. The research focused on certain
UI/UX design methods to customize the application to test a prototype of the application for
older adults. The methods proved successful in developing a functional application; however,
some of the designs features and functionality were not as effective as hoped. The results of the
application test and discussions will be used in future research and application design and
development plans to better ensure a more user-friendly and functional application for older
adult users. The outcomes of this project can also be used in the future to be applied to research
and design for other web mapping applications designed for older adult users.

124

References
Adiseshiah, Emily G. 2019. “UX Design Thinking from A Senior Citizen’s Perspective.”
Usability Geek, 2016, accessed Jan 18, 2019, https://usabilitygeek.com/ux-design-thinking-
senior-citizen-user/.
Anderson, Monica and Andrew Perrin. 2017. “Tech Adoption Climbs among Older Adults." Fact
Tank: Pew Research Center. ACI Information Group, May 2017, (Accessed October 8,
2018. http://scholar.aci.info/view/14bd17773a1000e0009/15c180642e80001230a5f42
Barnard, Yvonne, Mike D. Bradley, Frances Hodgson, and Ashley D. Lloyd. 2013. “Learning to
use New Technologies by Older Adults: Perceived Difficulties, Experimentation Behavior
and Usability.” Computers in Human Behavior 29 (4): 1715-1724.
California Department of Aging. 2015. “Data & Statistics - Facts About California's Elderly.”
accessed May 15, 2019. https://www.aging.ca.gov/data_and_statistics/facts_about_elderly/.
Campbell, Olie. 2019. “Designing for the Elderly: Ways Older People use Digital Technology
Differently.” Smashing Magazine. accessed February 06, 2019,
https://www.smashingmagazine.com/2015/02/designing-digital-technology-for-the-elderly/.
City of Los Angeles. 2019. “Shake Alert LA.” Apple App Store. 2019, accessed January 8, 2019.
https://itunes.apple.com/us/app/shakealertla/id1445922632?mt=8
Davey, Judith and Jenny Neal. 2013. Earthquake Preparedness in an Ageing Society: Learning
from the Experience of the Canterbury Earthquakes.
Dolan, James F., Kerry Sieh, Thomas K. Rockwell, Robert S. Yeats, John Shaw, John Suppe,
Gary J. Huftile, and Eldon M. Gath. 1995. “Prospects for Larger or More Frequent
Earthquakes in the Los Angeles Metropolitan Region.” Science 267 (5195): 199-205.
FEMA. n. d. “FEMA Viewer.” accessed October 20, 2018. https://gis.fema.gov/viewer/
Goodchild, Michael. 2007. “Citizens as Sensors: The World of Volunteered
Geography.” GeoJournal 69 (4): 211-221.
Goodchild, Michael F. and J. Alan Glennon. 2010. “Crowdsourcing Geographic Information for
Disaster Response: A Research Frontier.” International Journal of Digital Earth 3 (3): 231-
241.
Johnson, Jeff and Kate Finn. 2017. Designing User Interfaces for an Aging Population. US:
Morgan Kaufmann Publishers Inc.
Kovanen, J., J. Oksanen, L. Sarjakoski, and T. Sarjakoski, 2012. “Simple maps–a concept of
plain cartography within a mobile context for elderly users.” In Proceedings of the GIS
Research UK 20th Annual Conference. 2012.
McPherson, Krista M. 2016. “Assessing the Impact of a Web-Based GIS Application to Promote
Earthquake Preparation on the University of Southern California University Park Campus.”
Master’s thesis, University of Southern California, 2016.
125

Pánek, Jiří, Lukáš Marek, Vít Pászto, and Jaroslav Valůch. 2017. “The Crisis Map of the Czech
Republic: The Nationwide Deployment of an Ushahidi Application for
Disasters.” Disasters 41 (4): 649-671.
Purposeful Aging Los Angeles Imitative. 2018. “Age-Friendly Action Plan for the Los Angeles
Region 2018-2021”, August 7, 2018.
Red Cross. n. d. “Disaster Preparedness: For Seniors by Seniors.” accessed October 8, 2019,
https://www.redcross.org/content/dam/redcross/atg/PDF_s/Preparedness___Disaster_Recov
ery/Disaster_Preparedness/Disaster_Preparedness_for_Srs-English.revised_7-09.pdf.
Red Cross. 2018. “Earthquake: American Red Cross.” accessed January 15, 2019,
https://itunes.apple.com/us/app/earthquake-american-red-cross/id557946227?mt=8
Southern California Earthquake Center. 2011. Putting Down Roots in Earthquake Country.
Publication, Los Angeles: University of Southern California.
Smith, Aaron and Page, Dana. 2015. “U.S. Smartphone use in 2015.” Pew Research Center,
accessed October 15, 2018, http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-
2015/.
Soltani Nejad, Amir, Adibeh Barshan, Asma Baniasad, Ayoob Soltani Nejad, Ali Sam, and Ali
Sadie. 2017. “Investigating Social Vulnerability of the Elderly in the Earthquakes of Bam,
Varzaghan, and Ahar.” Salmand 12 (3): 360-371.
Standby Task Force. 2015. “Nepal Earthquake CrowdSourced Response Map.” accessed January
8, 2019.
http://www.arcgis.com/home/webmap/viewer.html?webmap=e887b1aec9d042d58cc8e533b
1791d71&extent=84.5456,27.3813,86.5685,28.235.
USGS. “USGS Earthquakes Application.” accessed January 8, 2019.
https://earthquake.usgs.gov/earthquakes/map/.
Vrenko, Dunja Zupan and Dušan Petrovič. 2015. “Effective Online Mapping and Map Viewer
Design for the Senior Population.” The Cartographic Journal 52 (1): 73-87.
Zook, Matthew, Mark Graham, Taylor Shelton, and Sean Gorman. 2010. “Volunteered
Geographic Information and Crowdsourcing Disaster Relief: A Case Study of the Haitian
Earthquake.” World Medical & Health Policy 2 (2): 6-32.

126

Appendix A

127

128

129

130

131

132

133

134

135

136

137

138

139

140

Abstract (if available)

Abstract One of the greatest natural disaster threats to the Los Angeles area is earthquakes. A large earthquake could wreak havoc on the area, causing major damage and loss of life. Recent research from disaster events has shown that older adults (those 65 years and older) are one of the most vulnerable demographics to disasters. Older adults benefit from specialized planning and preparation designed specifically for their demographic. As the older adult populations are rapidly on the rise in the Los Angeles area, the county and city have devised plans to prepare and aid the community with natural disasters, including earthquakes. As a part of this effort, this project was to research, design, develop, and test a prototype web mapping application for the older adult population of Los Angeles to better prepare them for earthquakes and increase their awareness of nearby emergency services. ❧ This project brought together map layers of earthquakes hazards, emergency services, and shelters, and other mapping layers related to seniors such as senior centers and nursing homes into a single web mapping application. This project customized the web mapping application user interface and user experience design in order to make the application user-friendly to older adults. The developed web mapping application allowed users to zoom to their location, pan the map, identify map layers, turn on/off map layers, print a map, search for the nearest emergency services and shelters nearest their location, and add an emergency preparation needs point to the map. With the results of this project, progress was made with understanding successful and unsuccessful methods of apply UI/UX designs of web mapping applications for older adults. The results can be applied to future research in order to best meet the needs of older adults with web mapping applications.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Designing an early warning system web mapping application for the Atlanta Metropolitan Area before a flooding event

PDF

Alaska Hike Search: designing a mapping application for Alaskan trails and user contributed hazards

PDF

Tracking Santa Barbara County wildfires: a web mapping application

PDF

Silicon Valley construction project web mapping application

PDF

Assessing the impact of a web-based GIS application to promote earthquake preparation on the University of Southern California University Park Campus

PDF

The community wildfire protection plan repository: using VGI to create a national collection of wildfire management information

PDF

Tracking trends in earthquakes and tropical storms: a web GIS application

PDF

Happy Traveler: discovering joy on university campuses and beyond through a web-based GIS application

PDF

Rails to trails web mapping application for the great Redwood trails: mapping northern California’s repurposed trails

PDF

Cartographic design and interaction: An integrated user-centered agile software development framework for Web GIS applications

PDF

Web-based relational spatiotemporal geodatabase of glaciers in California

PDF

Recreational Off-road Adventure Motorcycle mapping System (ROAMS): a web application facilitating adventure motorcycling in Idaho public lands

PDF

Analysis of park accessibility in Redan, Georgia Web GIS application

PDF

Generating trail conditions using user contributed data through a web application

PDF

Exploring commercial catch: creating a responsive Florida fisheries web GIS using ASP.NET, the Esri JavaScript API 4.x, and Calcite Maps

PDF

Preparing for earthquakes in Dallas-Fort Worth: applying HAZUS and network analysis to assess shelter accessibility

PDF

Angeles Hike Finder: creating a spatial database and web application to discover hikes based on attributes and difficulty

PDF

Development of a Web GIS application to aid marathon runners in the race selection and planning process

PDF

Geographic local routing for social connection: a novel application for the integration of routing technology and multi-user environments

PDF

Exploring global natural disaster and climate migration data: a Web GIS application

Asset Metadata

Creator Everitt, Brian Carlisle (author)

Core Title Designing an earthquake preparedness web mapping application for the older adult population of Los Angeles, California

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Geographic Information Science and Technology

Publication Date 06/18/2019

Defense Date 05/17/2019

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Earthquakes,emergency,Natural Disaster,OAI-PMH Harvest,older adult application design,older adult disaster preparation,user experience design,user interface design,Web GIS

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Sedano, Elisabeth (committee chair), Bernstein, Jennifer (committee member), Swift, Jennifer (committee member)

Creator Email bemsu06@gmail.com,beveritt@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c89-175939

Unique identifier UC11660341

Identifier etd-EverittBri-7497.pdf (filename),usctheses-c89-175939 (legacy record id)

Legacy Identifier etd-EverittBri-7497.pdf

Dmrecord 175939

Document Type Thesis

Format application/pdf (imt)

Rights Everitt, Brian Carlisle

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA