Written by Your users don't want a web map.
What?
They don't want a web map. Yes, that's right, your users don't want a web map.
What they want is the answer to a question. A web map is merely a tool that, if designed correctly, is the best medium with which to deliver that answer.
In many cases the answer is visible on the map straight away using symbology and a legend. Answers to questions such as:
- Which properties are located within the floodplain?
- What is the average household income for each county?
- Which zip codes already have a reseller?
But in many cases, the default map view can't deliver this answer; especially when the question is more complex, multifaceted, or can't be foreseen by the map maker ahead of time. In such cases a map needs to provide a query tool that allows the user to answer their own questions.
Questions such as:
- Which properties are within the floodplain and claimed this year?
- Which counties have average household incomes > $75k and more than 65,000 residents?
- Which zip codes already have a reseller and generate more than $125k in sales last year?
A query tool allows the user to build queries based on the attribute data of a layer and have the results displayed on top of the standard map layers.
The same answers can often be generated by a spreadsheet, but what a spreadsheet can't do is visualize patterns in the data.
For example, a spreadsheet containing insurance claim data for flood damage can tell you which properties claimed; but it can't easily show you whether those claims were concentrated in a specific area or were correlated to their proximity to a river or lake.
Why Your Map Needs a Query Tool
A web map can make patterns easy to visualize. Imagine a map showing properties that your company insures, along with rivers, lakes, and the extent of last year’s flood. The map could color-code the properties based on whether they made a claim, it could even change the marker size based on the size of the claim.
This is great, but what happens if the question gets more complex? Say, for example I only want to see properties that were on the premium package, or properties for which previous claims have been made?
In such cases we have two solutions, one is to make ever more complex symbology in a futile attempt to cover every question we can envisage, or we can provide a query tool that allows the user to quickly answer their own questions without restriction.
Your Query Tool Needs to Be User Friendly
A common mistake when creating a query tool for a web map is to make it behave like a desktop GIS. This is a mistake, in most cases the very reason for producing a web map is to put a useful tool in the hands of clients, colleagues or customers that don't have access to a GIS and in all likelihood have never even heard of the term, never mind used one.
Desktop GIS selection tool, ouch!
Desktop tools for building selection sets are extremely powerful, but they are also extremely complicated. It's your job as a web map designer to deliver a query tool that can be used by anyone—without any prior training. Or as they say in the design world, "Don't make them think".
Web Map Queries Made Easy
A well designed query tool that is easy to use usually has the following traits:
- It is laser focused
- It does not use jargon
- Results can be obtained with a small number of clicks
- It allows the user to easily restrict the results by areas and distances
- It does not resemble a database or GIS selection tool
Rather than a Swiss Army Knife, your query tool needs to be a scalpel that delivers precise results with minimum fuss or effort.
To achieve this, your map needs to be laser focused on answering questions around a very specific topic. If your users are interested in multiple topics within a common theme, then make multiple maps with each one laser focused on its specific reason for existence.
Good design is all about simplicity, if your workflow can't be refactored to the point where it's simple, then that is usually a strong indication that it is trying to do too much and should be separated into multiple maps.
For example, a single map called "Insurance Claims", that allows the user to visualize any kind of claim and perform any type of query. It will likely contain lots of layers, and a complex query tool that offers the user a huge range of attributes to query.
This approach is very likely too broad and inherently complicated for the end user. A much better approach would be to break the map up by claim type, and provide with each map only the layers related to that claim type and the query tool being restricted to attributes that relate to that claim type.
For example:
- Flood Claim Lookup Map
- Fire Claim Lookup Map
- Theft Claim Lookup Map
How a Web Map Query Tool Should Work
So let's take a look at a practical case study. In this example we have a map that is used to discover the commercial floor space of buildings in Manhattan. After meeting with our staff we have established that when searching for properties the two important factors are the total commercial floor space and special purpose district.
Our building layer contains dozens of attributes, but we decide to limit our query to commercial floor space and the special purpose district. We also decide to allow the user to limit the results by area.
Here's what the map and query tool now look like:
So let's break down this query tool and look at some of the features that make it easy to use.
Firstly, the special purpose districts are listed in a dropdown menu, this means the user doesn't need to remember the various types or worry about typing them incorrectly.
Also, the commercial floor space is displayed as a range, with the user being able to see the minimum and maximum possible values. They are also only permitted to enter numbers. These two features combined make it impossible to enter an invalid query.
Lastly, we give them some options to limit the query by area, they can draw a radius, a box, draw a shape around an area of interest or select one by one which buildings to include in the query.
This query tool is self-explanatory, anyone can use it regardless of their previous experience with GIS or databases, and by restricting the possible query parameters we've made it clear to the user what is expected of them.
When the user clicks the "Get Results" button all of the results are highlighted on the map which has now zoomed to the extent of the result set.
Once the user has performed a query we also need to consider what they may want to do with the results. The options available in this tool are:
- View the results as a table
- Download the results as a spreadsheet
- View a report which contains aggregate data for the results
It’s important to give your users to download, print, interact and examine the results on screen, in most cases simply showing the highlighted results is insufficient.
Using Mango to Build Your Query Tool
The query tools and example map covered above were built using Mango, all that was required was a Mango account, a web browser and some data. What wasn't required:
- Programmers
- Servers
- Expensive software licenses
The query tool in Mango has many options and can be customized to meet the exact requirements of your users. What's more, configuration is completed with only a few clicks.
Here you can try out the query tool used in this example for yourself:
