An intelligent map checklist

When you create an intelligent web map or map service, you are sharing something that you hope will stand on its own and be useful to others. How can you deliver a map that is both attractive and useful for your audience?

This checklist helps you assess your map as an information product designed for a specific audience. When do you need to consult this checklist? Use it any time before you publish your map.

Various staff at Esri developed and honed the checklist over the years as we built and shared maps with our colleagues and customers. Over time, we noticed which “little things” seemed to help other people find and use these maps effectively.

The goal of this blog is to encourage you to develop and use your own checklist, perhaps using this one as a starting point. While this version focuses primarily on web maps and map services, additional sections in your checklist could focus on critical things you know to provide when serving image services, feature services, WMS or KML.

People who use this checklist report that it helps them focus on their map as an information product – one that needs to be easy to understand, and well documented.

We all share a common goal: to publish maps that are technically correct, with clear messages both on the map and in the documentation. A checklist helps ensure that these things are considered. But it does not turn a bad map into a good one. There are other blog entries dedicated to map design and the rapidly-evolving web and mobile environments for maps.

Many map publishing projects start with an .MXD, which later is shared as a service. The checklist is quite useful early in the process, as you settle on what layers to use and how to show them cartographically.

Take the map’s legend, for example. As you add and symbolize layers in your .MXD, the default layer name, default field name and default class labels that the software suggests are what will appear in the final product. In ArcMap, look at your table of contents and take the few minutes required to translate file names and jargon into words and numbers that communicate (e.g. see Figure 1 below).

Figure 1: What you see in your MXD’s legend is what appears in your web map. Avoid cryptic file names, field names and legend labels that report numbers but not context. The legend in this example uses qualitative phrasing (e.g. “Great Increase”) as well as numeric (e.g. “More than 1.5%) because the audience likely has no idea what constitutes significant increases or decreases.

Just as the legend is the key to understanding the map visually, documentation about your map is the key to understanding its story. Over time we have found that good documentation about your map is as important as the cartography and the legend. Did you know that the information you put into the MXD properties will end up appearing in several other places? See examples below:

Figure 2: Documentation starts in the MXD and flows to a web map.

As you build your map services, ask yourself: “What would an end user of this map want to know about this map’s subject?” Document that in a clear, easy to read summary (1-2 sentences) and a description (longer, but not a dissertation). Build a web map from your service and put it in an application, to see things from another perspective.

For publishing web maps, the checklist emphasizes the essentials. The map’s title, summary, description, tags, credits and access/use constraints are the main text elements to enter. Create a thumbnail for your map that is visually appealing and distinct. Define a compelling popup.

Figure 3: Documentation from a web map flows to applications that use it.

Your map services are also going to be used by application developers. A good map provides key information to the developer, so that their basic questions are answered: “What is this map? What does it show? What time period does it cover? What is the source of its data? What rights do I have to access and use this map service?”

Popups are an important way to connect with your audience, and good news – they are easier than ever to configure. Unfortunately, many people choose the default popup “style,” which is an identify-style table of rows and columns like this:

Figure 4: Default popup style reporting raw data.

In just a few minutes’ time, you can write a more understandable, reader-friendly sentence or two about the data using a simple chart like this:

Figure 5: Sample popup with simple text and chart to set the context. Figures have an appropriate number of decimal places rather than the default (2).

Notice above how the theme of the map (“Persons without medical insurance”) is also the focus of the popup. The popup has been transformed from a table of numbers into a readable sentence and chart. These give additional context by providing state and national figures for comparison. These figures were added to the source data specifically for this popup’s chart.

Necessary? Absolutely! Just because you (or your customer) knows the data and its subject well doesn’t mean your audience will. The popup above is a simple example of the difference between showing data versus information.

When you have a first draft of your web map or map service ready, review it against your checklist. Before you show anyone the map, look through the checklist to see which items are essential to address. After you share your work with a trusted colleague to review and provide feedback, return to the checklist to finish going through the rest of the items.

Using the checklist forces you to consider how well you communicate your map’s message. Send us feedback on the checklist. What works well? What could be improved upon?