2016 web mapping track: towards cartographic standards for web based flood hazard maps by eben dennis and robert soden
Download as PPTX, PDF1 like292 views
This document discusses developing cartographic standards for web-based flood hazard maps. It outlines the researchers' backgrounds and motivation for the work. They conducted interviews, analyzed existing flood map applications, created a prototype map, and surveyed experts. Key findings include that most maps are too complex for the public and lack important information. The research aims to establish best practices for web map design to effectively communicate flood risk.
2016 web mapping track: towards cartographic standards for web based flood hazard maps by eben dennis and robert soden
- 1. Towards Cartographic Standards for Web-Based Flood Hazard Maps ICON Engineering, Inc. & University of Colorado, Boulder
- 2. Who We Are Eben Dennis ICON Engineering, GIS Coordinator Civil Engineering firm FEMA Mapping Partner Primarily Public Sector projects (UDFCD, Boulder, Denver, Greeley, Ft Collins) Certified Floodplain Managers UC Denver Geography Program Graduate Robert Soden University of Colorado, Boulder, PhD Student Co-Risk Labs, Principal California-based research and design company Previous Background World Bank Global Facility for Disaster Reduction and Recovery
- 3. Why Are We Doing This? Web-based flood maps and web-based maps in general are mostly garbage. The tendency to create a GIS in the browser is a massive pitfall for both the public and experts attempting to utilize these applications. Web-based mapping is still a relatively new field, and cartographic/design standards are not widespread if they exist at all. These applications have clear potential, but the design standards still need to be developed to provide best practices for effective communication and end- user suitability.
- 4. User Centered Design Specify the context of use: Identify the people who will use the product, what they will use it for, and under what conditions they will use it. Specify requirements: Identify any business requirements or user goals that must be met for the product to be successful. Create design solutions: This part of the process may be done in stages, building from a rough concept to a complete design. Evaluate designs: Evaluation - ideally through usability testing with actual users - is as integral as quality testing is to good software development. From usability.gov
- 5. Why Web-Based Flood Hazard Maps? The ability to distribute and communicate flood maps in an effective and wide- reaching manner enables its use in all phases of the risk cycle, from planning and mitigation to response and recovery. The barrier to access for both developers and end-users is becoming lower and lower with each new iteration of web-mapping products.
- 6. Previous Research - Public Facing Typical Problems: “Map portals over-focus on the the map, under- focus on text-based search and discovery” Providing multiple data layers in a web-map application decreases usability for most of the audience Solutions: Treat your data more like a search engine, include auto-complete, make it obvious. Focused, single-topic applications; accomodate the small number of power users by making data available for download; provide custom basemaps with some data already built in.
- 7. Previous Research - Public Facing Timoney’s Four Requirements of a Web Application: FAST, INTUITIVE, INFORMATIVE, FAST Many tools included in out-of-the-box web applications look and act like a desktop GIS, which is great if you’re a trained GIS user, not so much for the other 98% of your audience. If you want a layer to contain information on a click, why would you make a user click on an ‘Info’ button first?
- 8. Previous Research Roth & Cartographic Interaction “How maps are manipulated by the map user” Contrasts with the classic Communication Model Map & user influence each other Speed of application can affect productivity and focus
- 9. Interviews Conducted interviews with floodplain engineers, clients, and end users to help determine the utility of the applications. Two audiences were identified: Public - typical homeowner, wants to know if they are in the floodplain Expert - engineers and clients utilizing maps as a data immersion tool Decisions made with this application will potentially affect the public user
- 10. Methodology
- 11. Competitor Analysis Analyzed 25 different flood mapping sites Nearly all government owned/operated What interaction operations are supported? How is flood risk represented? Clear Statement of Purpose Clear Branding/Ownership Disclaimers Address Lookup Dictionary/Links to Further Info Guidance for Property in the Floodplain Base Map Options
- 12. Competitor Analysis Almost everyone using ESRI stacks Good news is that most sites had address lookups Bad news is that almost none of the sites tell you what to do if, in fact, your home is in the floodplain. Who do I actually talk to about buying it? What if my house is elevated? What the heck is an elevation certificate? These are all important pieces of information that users want to know in this context.
- 14. Competitor Analysis GIS on the internet Too many buttons that have no intuitive meaning to non-GIS users No clear purpose Slow load times, near impossible to keep user interest
- 15. Competitor Analysis Single purpose application Limited interactions Plenty of opportunity for self- directed learning by users Not too text heavy, but does a good job of providing links to users who are interested in learning more
- 16. Walkthrough Created web-map application for a public audience Single purpose of the application is to identify flood hazards in Boulder, CO Built on Mapbox GL and Turf.js (fast!) Consists of search bar, map panel, info panel, small legend Limited interactions Statement of purpose is given up front in the info panel Flood information is provided for users in and out of the floodplain Additional flooding information is provided in a custom basemap Had public users think aloud while they used the application
- 17. Walkthrough
- 18. Walkthrough - Findings People used the search bar, overwhelmingly - though some were confused by autocomplete. Almost as overwhelmingly, they don’t read text Simple, actionable instructions - what is the key information the public needs at each stage of the project?
- 19. Walkthrough - Findings The NFIP 100-year floodplain presents a limited portrayals of flood hazard. People were genuinely surprised when they realized that areas outside the floodplain were affected by the 2013 Colorado floods. In making these sites simple to use, we need to be careful to not convey simplistic understanding of science - when we added the 2013 flood footprint and it created just enough dissonance for people to get engaged and start asking interesting questions
- 20. Survey For the expert audience, we utilized two existing applications built by ICON Engineering. All of the questions on the survey were open-ended, with the exception of difficulty ratings, in order to better simulate a real-world decision making process. The audience is wholly comprised of CASFM YMG members, so the expectation is they will be comfortable with web-map applications and have the ability to accurately answer technical questions.
- 22. Survey - Application 1 Too many clickable elements Alternatives aren’t easily distinguished Flow direction arrows extremely useful Speed, clickable information, layer toggles? All good things. Missing statement of purpose, lacking instructions, more description needed for layers
- 24. Survey - Application 2 Transparency on transparency isn’t the most effective Layer switching not as intuitive as toggles/checkboxes Speed? Still a good thing. Needs a better description of what each layer represents When multiple elements are clickable, more clarity for what layer fired the popup
- 25. Next Steps
- 26. Next Steps Better in-page analytics Click tracking Time spent on page More data! Gather more user feedback on the two expert systems Iterate!
- 27. Questions? Slides available at ebendennis.github.io/notes
Editor's Notes
- #9: The gulf of execution describes the disconnect between the user’s objectives and the provided cartographic interaction operators. The gulf of evaluation describes the disconnect between what the user expected to accomplish through the cartographic interaction and the interface’s representation of the result of the cartographic interaction
- #27: Finalize and write up the results of this study Gather user feedback on two expert systems once they are fully launched Better analytics - we need data