Cartography with an actual blindfold

Last month, Andy gave a talk at the OpenVis Conference entitled Blindfolded Cartography. Essentially, things to look out for when designing maps (especially interactive ones) so that when real data comes in, the map/design/page doesn’t get wonky. Things like too long text, missing data, skewed data, etc… The last week or so, we’ve been working on adding accessibility features to one of our projects and wanted to share a few thoughts and lessons on Cartography with an actual blindfold.

First off, what are accessibility features and why should you care? Accessibility features are features and general design patterns that allow people with disabilities to view and interact with your content. This can range from simply allowing keyboard navigation all the way up to screen readers. Now, why should you care? We can get fairly pedantic about whether a font size should be 16pt or 18pt, should this light brown text be #f2e1cb or #f8f1e7, should this div have a margin of 20px or 22px? If we as developers take that much care about things that a lot of users aren’t going to consciously notice, shouldn’t we take at least some care with things that some of the users are really really going to notice?

So what categories of accessibility should you be aware of? There are 4 areas that I’m going to talk about; I’m sure there are more, but these cover the majority of cases that I’m currently aware of. Color, keyboard navigation, ARIA, and Screen Readers. Also, I should note, I am not an expert in this. What follows are the notes of a developer brand new to the area of accessibility.

Color

Color can cover a whole host of issues, but the main areas to watch out for are color blindness and low contrast. About 10% of all males have some form of color blindness, of which the most prevalent is red/green (protanopia) color blindness. That’s a big percentage of your users. Simple fix – don’t put red and green right next to each other. As a mapping company trained in classical cartography techniques, this one is pretty much embedded in our blood and bones. Other versions of color blindness do exist though. It’s up to you to decide how many versions you want to design for (since the more you cover, the less options you have for design). A good site to figure out which colors you can use is Colorlab.

Color lab example image - magenta for red green color blind people
Magenta vs Gray for Red/Green color blind people

A color tool for Cartography specifically and which has colorblind options is ColorBrewer (which Axis Maps hosts).

Color brewer example image
Color Brewer

The other major category related to vision is contrast. Many users have a harder time distinguishing low contrast color pairings. For example, #ccc color text on a #999 background. You can check contrast between colors using the Color Contrast Check tool.

Contrast checker image - #999 vs #ccc
Contrast Checker – #999 vs #ccc

Testing: The best way to test for color blindness issues is to have a someone who is actually color blind look at the site (and since 1 out 10 men are, there is a good chance you know someone who is). Barring that, run the various colors through Colorlab and the Color Contrast Check tool.

Keyboard

There are two types of people who use the keyboard only; the visually impaired and those with a disability making use of a mouse impossible (for those of you wondering, as I did, how you can use a keyboard but not a mouse, many alternate input devices emulate a keyboard but not a mouse – e.g. Sip and Puff devices).

There are a couple of key points to keep in mind when designing for keyboard users. Most browsers are already pretty good at keyboard navigation, IF the HTML is organized in a logical order. While this isn’t a problem when writing HTML for the most part, where you can run into issues is with adding pieces via Javascript. It’s really easy to add a bunch of divs with JS and as long as they look in the right place, ignore the fact that they are not keyboard navigable. One major gotcha, div is not keyboard navigable by default. You have to add the attribute tabindex="0" to make it navigable. a links and button elements are keyboard navigable by default so those don’t need an extra tabindex attribute. Best practice is to make all clickable areas that go somewhere a links and all clickable areas that trigger functionality button elements. Unless absolutely necessary, don’t use div for buttons/links.

tabindex=0 simply adds the element to the keyboard navigation index. Sometimes, especially with adding elements via Javascript, the default tab order ends up not really being a logical one. In these cases, you can override the tab order by changing the tabindex to any positive numerical value. A tabindex=1 will come before tabindex=2 and so on. This is not considered good practice, but in production, sometimes this ends up being the only way without a complete rewrite of the code.

Testing: Keyboard navigation is really easy to test. Just use the site with only the keyboard. Can you access all the functionality? Can you get to all the links and do they work by pressing space or enter? Are all the buttons/divs/links/etc… in a clear and logical tab order?

ARIA

ARIA stands for “Accessible Rich Internet Applications” and is designed to let screen readers and other assistance software help make interactive pages usable by all users. ARIA tags are usually element attributes such as aria-hidden and role. Like other element attributes such as id and src, there are attributes for pretty much every element and they apply differently. I’ll mention a few that are good to know about:

  • aria-hidden – makes a particular element hidden from screen readers. This is useful if, for example, you have a description that is truncated for display reasons, but is expandable through mouse interaction.

HTML
Two divs. One with a class of hidden making it all but invisible to the naked eye, yet still there. The other one is the normal div that everybody sees, but with an aria-hidden="true" attribute to hide it from screen readers so they don’t repeat themselves.

<div class="full-description hidden">Blah blah, this is the full description and is not truncated with ellipsis</div>
<div class="description">Blah blah...</div>

CSS
Hidden class that reduces the element to 1px by 1px. The clip and overflow: hidden hides everything that goes out of the 1px by 1px box.

.hidden{
position: absolute !important;
margin: 0 !important;
padding: 0 !important;
height: 1px;
width: 1px;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
overflow: hidden;
}
  • As seen above, the use of the .hidden class is very important. This allows screen readers to “see” something, even though people can’t see it.
  • Using a hidden class is different than using display: none or visible: hidden. Changing the display to none or the visibility to hidden takes the element out of the screen reader’s view.
  • roleARIA-role w3 page – this one can get complicated as there are four different categories that can be used, but the idea is that you can tell the screen reader what the element is for. The four categories are:
    1. Abstract Roles – Do not use.
    2. Widget Roles – Define what the element is to be used for. This is helpful when, for example, you have div operating as a button. Most of the time, you should just mark it up as a button, but if you can’t, then you can assign role=”button” and it acts as a button to screen readers.
    3. Document Structure – Defines what structure the element has. This is so the screen reader can take special care with the pronunciation and navigation of that element. For example, the math role tells the screen reader that mathematical formulas are in coming and to take appropriate action (such as saying “eh-ex-squared” instead of “ax-squared” when ax2 is encountered).
    4. Landmark Roles – Define the different areas of the document (such as navigation, main, search, etc…) so the screen reader can jump between them easily.
  • alt tags – This is pretty well known, but I’ll reiterate. Put descriptive alt tags on all images so that the screen reader knows what the picture is about. Make sure it’s short though, no need to wax eloquent on all the little details of the logo.
  • links – This is probably the one I’m most guilty of. Don’t have links where the only linked text is “Click here.” In context, this is fine. But out of context this doesn’t make any sense. And many screen reader users navigate by pulling up a list of links in which only the text of the actual link is available, so the links very well may be spoken out of context. Don’t say “click here”, say “Link to Annual Report PDF”. Oh, and don’t leave the full link in visible text or the screen reader will read “double-u, double-u, double-u, dot …”.

Testing: Testing ARIA tags is mostly about testing things with a screen reader. The testing part of the Screen Reader section below has more information.

Screen Readers

And now to the most well known accessibility genre, the screen reader. Screen Readers work by reading off the text from a web page. How they do this is different for each one and can devolve into a similar situation as the early 2000’s with web browsers – each one its own special flower. There is some standardization and it is getting better, but you will still run into situations where different screen readers read the same markup differently (especially when Javascript gets involved).

The four main ones that are relevant to interactive web sites are JAWS, NVDA, VoiceOver, and ChromeVox. JAWS, the most widely used screen reader, is a commercially licensed piece of software for Windows, especially popular in academia and government. NVDA is an open-source program for Windows. VoiceOver belongs to Apple and is bundled with OSX. ChromeVox is a Google created plugin for Chrome that is really helpful for developers (though because of its integration with Chrome, it does create some headaches as seen below).

Each screen reader sees the world slightly differently. This can create some head bashing moments as the notes below make clear. They were filed as apart of a Github bug report for the accessibility upgrade I was working on this week. The list was a long list of images where each one, on click, would open up to a carousel widget to view more images from that spot. The carousel widget had a left and right HTML button that were supposed to be navigable by keyboard arrows, mouse clicks on display arrows, and keyboard “enter” when the focus was on a display arrow.


Tabbing through list

  • Chrome – reads each section when the section is focused, reads header
  • FF – reads all the sections when the entire list is focused (i.e. on normal tabbing through), reads each section when focused, does not read header when tabbed to, but does read header when shift-tabbed to
  • IE – reads each section when the section is focused, reads header

Arrows

  • Chrome – does not read the arrow aria-label, reads the title and description of each carousel image after interacting with the arrow
  • FF – reads the arrow aria-label, when the focus is shifted to a new arrow (i.e. at the beginning or end when the current arrow is hidden) reads the new arrow, otherwise, doesn’t read anything on interaction
  • IE – same as FF

Screenshot of the carousel  with the problem arrows
Screenshot of the carousel with the problem arrows

For the life of me, I couldn’t get Chrome to read the aria-label on the arrows, until I took the ChromeVox tutorial and realized that screen readers don’t just use tab to navigate. They use the arrow keys, the plus/minus keys, and a whole host of other shortcut keys. Tab is just for interactive elements (and apparently Chrome/ChromeVox was not reading the aria-label for interactive elements). This is by design. Keyboard only users just need tab to move through the interactable elements. They can read the non-interactive elements already. Screen Readers use other keys to move through the non-interactable elements such as paragraph blocks.

Which brings me to the final point, Screen Readers are complicated pieces of software that work in ways that are very different conceptually than how the majority of users see and interact with a web site. The best way to test your site is to get someone who knows how to use a screen reader properly, to test it. Failing that, make sure that you are at least somewhat versed in how your chosen screen reader actually works. It’s more than just tabs.

Testing: ChromeVox is a free plugin for Chrome that is really easy to setup and use. Make sure that you go through the tutorial first though as there are facets of screen reader navigation that are not necessarily intuitive for people used to mouse navigation. VoiceOver is included with OSX so that should be easy enough to include in testing if you are using a Mac. NVDA is free software as well, though for Windows. By using one or all of these, you should run into any bugs that will affect screen readers. Things to look for: can you hear all the content? Is anything behind an “interactive wall” that is not accessible with keyboard/screen reader? Do all the images have alt tags so you know what is going on without seeing the actual image?

Conclusion

Accessibility concerns affect a small but significant portion of users. If things are designed with them in mind, that can only be a good thing. Many of the above suggestions, with the possible exception of catering to color blindness, shouldn’t change a single thing on how your page looks, feels, and interacts. But by following them, more people will use and enjoy whatever content is there.

And if you really want to get a handle on how this stuff works in practice, do as Mercator did and use an actual blindfold:

Blindfolded Mercator

Blindfolded Cartography

This is an adaptation of a talk I gave at the 2015 OpenVis Conference in Boston, expanded in a few spots and abbreviated in others. You can see slides and, ugh, video from the talk.

At Axis Maps, a rough napkin sketch of our projects often looks like this:

Map viewer sketch

We’re tasked with designing and building interactive maps of data that, for one reason or another, we can’t yet see. Sometimes the client doesn’t have data ready soon enough. Sometimes we expect data to change or be added after our work is done. Sometimes it’s just too vast for us to lay eyes on all of it. Whatever the reason, this reality of web mapping is a significant departure from what we knew back in cartography school.

Traditional cartography allows—encourages, perhaps—perfectionism. We were taught attention to detail, and to find and tell the story in our data. Crafting beautiful, effective maps and telling stories with them is one thing when you can obsess over every detail; it’s quite another when you have to do it as though blindfolded. (And I don’t mean sea monsters and mapping unknowns; I mean mapping real things that are known but somehow inaccessible to the cartographer.)

Compromise

As always in cartography, this is all about making compromises. We make design choices that we know are not are not ideal for most cases, but are at least acceptable for all cases. What follows is a list of some areas where we’ve found the “blindfold” particularly challenging, and some compromises that we or others have found helpful. And an occasional shrug where we haven’t found good answers yet. Much of this is about design, some of it is about code (JavaScript), some of it isn’t even about maps, and none of it is perfect.

Data classification

John Nelson has a succinctly handy explanation and demonstration of why data classification decisions are important on choropleth maps. One way of dividing data into bins can produce a starkly different map from another way, potentially in a functionally and aesthetically bad way.

Data classification example by John Nelson
Data classification example by John Nelson

We want to devise a classification scheme around several questions: Will the map be useful and look good? Are the class breaks meaningful? Are they understandable? Are they pretty numbers? As usual, this isn’t too difficult when dealing with a single data distribution. But we need satisfactory answers to those questions for any data set, without our manual intervention. And real data… well, real data are always messy.

Data in designs vs data in reality

Two common solutions are Jenks optimal breaks, where class breaks are calculated to optimize both grouping and spacing, and quantiles, in which each bin contains the same number of values. Both offer some assurances of visible spatial patterns, but both have drawbacks. For example, optimal breaks can be hard to understand, and quantiles can inappropriately group or split values.

Optimal breaks and quartiles

One compromise we’ve used can be described in two parts:

1. Unevenly distributed percentile breaks. Quantiles are friendly, readable, and somewhat reliable, so we often err toward them. Instead of dividing data into evenly sized classes, though, we might break down some of the classes further to separate or highlight extremes or important breakpoints, for example the top 5% in the histogram below.

A compromise classification

2. Use percentiles of unique values, not all values. Datasets often contain many duplicate values; when quantiles are calculated properly, a single value could span several classes. (A common example is having a whole bunch of zero values.) To avoid weird map legends and to better bring out geographic patterns, we might base our classification on the distribution of only unique values, avoiding duplicates.

// basic example
function getValueAtPercentile( data, percentile ){
  return data[ parseInt( (data.length - 1) * percentile ) ];
}
// using underscore.js
var dataArray = _.sortBy( [ 0, 0, 12, 23, 2, 5, 0, 5, 19, 0, 0, 0, 33, 9, 25, 0 ], Number );
var uniques = _.uniq( dataArray, true );
getValueAtPercentile( dataArray, .25 ); // = 0
getValueAtPercentile( uniques, .25 ); //  = 5

null

Expect holes in the data. Assume that sometimes data will be bad or missing. Catch these missing values in code, and, importantly, design for them. “No data” is data too.

Andy Kirk gave a talk called “The Design of Nothing: Null, Zero, Blank” at last OpenVis in 2014, covering (among other things) some no-data scenarios. It’s worth a look:

There are two sides to handling missing data. On one side is code that won’t break if a null value is thrown at it. Basically this means a lot of error handling and bailing out of functions if they’re passed null values. But it also requires some understanding of the data format. A missing value could come through in a variety of ways.

// no data might be...
null
undefined
NaN
""
"NULL"
-9999
// &c. &c.

 
Be careful to avoid the JavaScript gotcha of equating zero with “no data”—usually not the same thing in reality.

// a tempting way to catch "no data" in javascript
if ( data ){
  // yay, we have data!
} 

// but watch out!
var data = 0; // zero is real data
if ( data ){
  // zero won't get us in here :(
}

 
The other side is design. One common scenario is missing data in a choropleth map. We like using texture to indicate missing data. It’s distinct, not easily confused with colored values; and it’s explicit, keeping “no data” as part of the story instead of hiding it. If you’re working with D3, check out Textures.js for easy texturing.

choropleth textures

Another common case is gaps in time series data. Again, it’s good to be explicit. Interpolation can be misleading. For example, I like the dashed line in the iOS Health app. It explicitly indicates a gap in data without losing continuity.

iOS health - gaps in data

On maps, one thing we’ve tried is using a special symbol to indicate a gap in data. Below is a frame from an interactive animated map where proportional symbols remain on the map even when there’s no data for the current year, showing the most recent available data but with a different, hollow symbol.

Gaps in time series data on a map

Text

Text in an interactive map setting is more than just labels. Marty Elmer has written nicely about prose on maps, and how it’s ubiquitous yet overlooked. Text, too, can be an unknown part of map data—one that can ruin otherwise beautiful layouts.

The big lesson from experience here is to restrict the space allotted to text. If you’ve designed for a short sentence, assume you’ll be fed a novel, so make sure text doesn’t overflow all over everything. CSS properties like max-height and overflow:auto can help. For shorter labels, truncation and abbreviation (such as via text-overflow:ellipsis may be useful, but also take advantage of what you do know about the data to be clever about this. For example, in the chart below we knew that some labels would be for congressional districts. If we simply chopped off those labels after a few characters, they’d all be the same, so instead we put the ellipsis in the middle and retained the district number at the end.

Label abbreviations

One last thing: mind your number formatting! It’s easy to forget to design label formats for things like singular versus plural or different orders of magnitude, in which case you end up with some funny-looking labels.

Bad number formatting

The Lorem Ipsum Map

All of this, broadly, is about the challenge of designing around missing or fake data. The “lorem ipsum map” is a phrase used by Rob Roth and Mark Harrower (2008), as a caution against designing user interfaces around a placeholder map. In studying the usability of a map we made for the UW-Madison Lakeshore Nature Preserve, they found some negative reactions to the cold, metallic UI (which we designed first), in contrast to the green and fuzzy map (which we didn’t add until later). It’s hard to offer solid advice about this, other than to suggest trying to understand at least the basic nature of the unknown data and what it might look like. ¯\_(ツ)_/¯

Instead of designing around a blank spot, however, we often generate fake data. That of course can be a challenge itself, because how do we design somewhat realistic fake data when we don’t know what the real data look like? Carolyn Fish has a good term for this goal—”smart dummy data“—and an interesting anecdote about challenges she faced trying to make OpenStreetMap data stand in for totally inaccessible (to her) classified data.

All that said, fake data can be an excellent test of code. In some ways, the more unrealistic the better. If the code can handle ridiculous data scenarios, it can probably handle the real data.

The Human Touch

Big picture time. The ultimate goal, really, is to approximate good, human design when we’re forced to do it through rules and algorithms applied to unknown data. I’m going to keep pointing to Daniel Huffman to explain why this matters, at least until he makes good on his promises to follow up on four-year-old articles.

To illustrate how enormous a task handmade design can be in the web cartography age, consider The Essential Geography of the United States of America by David Imus. You probably saw this map a few years ago when a Slate writer declared it “The Greatest Paper Map of the United States You’ll Ever See.” Indeed, it’s a lovely map with tons of manual details.

The Essential Geography of the United States of America

The map is 1:4,000,000 scale, and according to the Slate article, it took nearly 6,000 hours to complete. 1:4,000,000 is approximately zoom level 7 in the standard slippy map scheme. Just for kicks, let’s extrapolate and say David Imus wanted to design a fully multiscale web map (zoom levels 0 to 18) with the same attention to detail. How long would it take him? I’ll spare you the details of my calculation: it’s 2,803 years and 222 days. And that’s only the United States. Im-freaking-possible, in other words. That’s why we need algorithms.

Big Design

This gets into what I want to call “big design.” So-called “big data” isn’t just a computational challenge; it’s a design problem too. How do we accomplish good human design when there’s simply too much data for a human to see?

The problem is perhaps unique to cartography, where at some level we want to see almost every piece of data we have, not aggregates and distillations. For most of us that means a map based on OpenStreetMap data down to the highest detail levels. With 2 million users mapping all over the world, quality and consistency can’t be 100% guaranteed. Our challenge is to come up with design rules that ensure the map looks pretty good everywhere, at all scales. Yikes.

Nicki Dlugash of Mapbox spoke to this very topic at NACIS 2014. To summarize her advice:

  1. Prioritize areas you care about for your specific use case.
  2. Prioritize the most typical or common examples of a feature.
  3. Look for the most atypical examples of a feature to develop a good compromise.

To help you along the way, there are things taginfo, where you can explore OSM tags and get a sense of things like geographic variation; or things like this view in Mapbox Studio where you can inspect many places at once.

Mapbox Studio "places" view

And of course the nice thing about OpenStreetMap is that you can always fix the data if you find problems!

Good Luck

Well, I hope that assortment of tips and problems has been useful. Good luck as you stumble through the dark!

Blindfolded Mercator

FatFonts World Population Map

We’re excited to announce that we’re bringing the work of some of our friends to the Axis Maps Store. We’ve always been interested in new ways to encode and represent data. Also, typography. We ♡ typography big time. It was both of these interests that lead us to the work of Miguel NacentaUta Hinrichs, and Sheelagh Carpendale and the FatFonts project. From their site:

Fatfonts are designed so that the amount of dark pixels in a numeral character is proportional to the number it represents. For example, “2″ has twice the ink than “1″, “8″ has two times the amount of dark ink than “4″ etc. You can see this easily in the set of characters below:

Blockfont onelevel cut1

This proportionality of ink is the main property of FatFonts. It allows us to create images of data where you can read the numbers, and represent tables that can be read as images (like the example below).

Blockfontexample1

It’s a fantastic technique for cartographers (especially when making static maps) because the ink density allows you to see geographic patterns while the digits give you the exact values for each grid cells. This bi-visual technique essentially replicates an interactive data probe on a static map.

If you’re interested in using FatFonts in your own maps, you can download the font faces from the project home page.

The FatFonts World Map

If you want to get your hands on your very own FatFonts map, the World Population map is now available at the Axis Maps store. They were a natural fit and quantitative cousin to our typographic maps. Like the typographic maps, the FatFonts maps show the big picture from afar, but reveal their extensive detail as you move closer. From Miguel’s blog:

The poster is made using an equal area projection of the world, and it represents data collected by CIESIN and others. Each grid in the main map, which represents an area equivalent to 200 by 200 km has a 2-level digit FatFont digit in it. That way we can know, with a precision of 100,000 people, how many humans live there.

Since the number of dark pixels of a FatFont digit is proportional to the number that we are representing, we can calculate how many people each black pixel represents. For an A1 poster in the main area of the map at 600 pixels per inch, each pixel represents approximately 1880 people! FatFonts with the orange background are up by an order of magnitude, so there the ink of a pixel represents approx 18,000 people.

It’s a fascinating map that clearly illustrates how unevenly population is distributed across the globe. Particular areas of interest are highlighted and given higher-resolution treatment:

detail_1_600

The FatFonts World Population map is now available from the Axis Maps store. All profits will be re-invested to fund more FatFonts research.

Yakkin’ ‘Bout Mappin’

Last week, we made an election map that shows how counties voted in relationship to several different demographic variables. It gave us a chance to take value-by-alpha (VBA) mapping one step further than we did after the 2008 election. Back then, we produced a nice little static map. Our new, interactive map is a bit more substantial, having a user interface, loading data, including a charting component, and displaying a data probe with details on mouseover.

Unlike our typical interactive mapping project, this one was rather small in scope. We wanted to make something that could come together quickly and easily and be seen before people stopped caring about the election. There was also no client, so we were free to work however we pleased in order to get done fast. In other words, no one was telling us that we had to make this work in IE7! All said and done, we devoted twenty-eight hours to the map before sharing it on Twitter.

Because the project was short and received a sustained, concentrated effort from each of us, a behind-the-scenes look at its development seems like it might be of interest to other mapmakers. If nothing else, it serves as an example of how three people, working in different parts of the world, interact together online to get work done. Something for the human geographers out there, at least, if not for the cartographers.

What follows is our Campfire transcript covering the duration of the project. Outside of this transcript, there was no video, voice or other written communication between us. The language here has been smoothed out and edited somewhat in order to reduce each thought, question, or decision to its essence, although there are some direct quotations thrown into the mix.

We think about every project, large or small, slow or fast, client or not, in terms of three primary components: data, design, and code. They are essential ingredients of web cartography and what any aspiring cartographer should learn. To that end, the transcript below has been tagged with colored dots that represent the predominant component in play at any given moment in time, plus a yellow dot for instances when our thoughts were mostly on project planning or management issues.

As you scan through, some patterns to note are:

  1. Entries pertaining to all three components, as well as a basic project plan, are found in the first 30 minutes.
  2. The number of entries about data start out heavy and all but disappear on Day 2.
  3. Entries about code pick up steam toward the middle and end of the project.
  4. Entries about design appear rather consistently throughout the project, with a run of back and forth data-design entries in the middle of Day 1 and a similar back and forth run of code-design entries at the end of Day 2. Interesting!

Planning = Planning
= Data
Design = Design
Code = Code

Day 1 – November 7, 2012

8:15 AM Planning “Want to make a map?” -Dave
8:15 AM Planning “Maybe just this one last time. Then I’m retiring.” -Andy
8:20 AM Design How about an election-by-demographics map using the value-by-alpha (VBA) technique?
8:25 AM Code What’s the best technology setup for this? (Polymaps? CSS?).
8:25 AM Planning Let’s get started this way:

  • Andy: prepare the data
  • Dave: get interactive setup going
  • Ben: put together an interface design
8:30 AM Data I’m exploring election data from The Guardian in Excel.
9:05 AM Data What kinds of demographic data would be worth mapping? Which are effected by geography?
9:05 AM Design What kind of chart should accompany the map?
9:15 AM Design Margin of victory versus demographic variable by county sounds like a decent chart.
9:25 AM Data Here’s a Shapefile with geographic and election+demographic data.
9:25 AM Planning We need to share this file with the world.
9:25 AM Data Let’s explore the Shapefile in indiemapper.
9:30 AM Design We should wait and share this data once it’s all cleaned up.
9:40 AM Data Here’s a second version of the Shapefile with our map data.
10:00 AM Data What’s the best way to store the data? A series of JSON files?.
10:05 AM Data What scale is appropriate for the county boundary data? Will we need to zoom in?
10:10 AM Data There’s no need for detailed, large-scale county data.
10:10 AM Data Let’s store data and geography separately.
10:10 AM Data I’m preparing the data in Google Refine.
10:20 AM Design Anyone have good red/blue color specs?
10:25 AM Design Here are two 5-class sequential color schemes, one for red and one for blue.
10:30 AM Data Looks like there are problems with this data.
“It has Obama winning most of Wyoming handily.” -Andy
10:40 AM Data “In Colorado, that’s showing the Constitution Party candidate!” -Andy
10:55 AM Data I’m fighting with pivot tables in Excel. Trying to get sums into columns instead of grouped in rows.
11:00 AM Planning “Back in a moment… need to go do something to my car before it starts raining.” -Andy
11:45 AM Data Here’s a third version of the Shapefile with our map data.
11:50 AM Design Here’s a VBA map showing county margin of victory by population.
11:50 AM Design Switch to black background.
11:55 AM Design Let’s go with 2-class winners. It’s too hard to see both change in color and alpha.
12:05 PM Design Here are new red and blue color specs.
12:10 PM Design Here’s a new VBA map showing county winner (2-class) by population.
12:10 PM Design “That’s looking pretty okay.” -Dave
12:10 PM Design How is population classified? The map looks kinda bright, making it hard to see population differences.
12:10 PM Design Should we go with equal-interval or unclassed population instead of quantiles?
12:20 PM Data “Argh, this stupid data. Chicago is red!” -Andy
12:25 PM Data For unclassed data, opacity should be a percentage of the max, right?
12:25 PM Design “Los Angeles is ruining it for everybody.” -Dave
12:30 PM Data How about capping the population values at a certain threshold?
12:50 PM Design Here’s a new VBA map showing winner by population, capped at the 90th percentile.
12:55 PM Data What about going with population density instead, in order to control for county size?
12:55 PM Design Here’s a new VBA map showing winner by population density.
1:20 PM Data Here’s the fourth version of a Shapefile with our map data.
“Gave up on Excel, used a Python. Er, Python, not a Python. No snakes involved.” -Andy
1:25 PM Design The user interface mockups are done.
2:00 PM Code Maybe we ought to go with D3 so we can use a map projection.
2:05 PM Design Does using VBA even make sense for mapping demographic variables? What if there is no real correlation between the demographic variable and county winner? VBA might be best for things that are magnitudes or certainty.
2:15 PM Design It’s worth a try. In the end, it’s just a bivariate color scheme.
2:25 PM Data Here’s the final version of the Shapefile with our map data.
2:25 PM Planning Let’s tweet that data.
2:25 PM Data I’m still not sure if population or population density makes more sense here. If we think of VBA as a cartogram, shouldn’t we just map totals?
3:05 PM Design Does this map need a legend?
3:10 PM Planning How should we proceed, now that we’ve got data and an interface design?
3:15 PM Planning What exactly are we trying to make here? A static map viewer? A basic interactive map with data probe and linked chart?
3:20 PM Code If it’s a static map viewer, how about using indiemapper + SVG?
3:25 PM Code There are problems getting a good data probe and chart that way, plus the SVG is too huge.
3:30 PM Code D3 and JSON is sounding like the best approach.
3:45 PM Code The D3 shell is made.
“It was an election day sweep for President Robert Smith of the Goth Party.” -Dave
4:10 PM Code Here’s what it looks like with colored data.
4:20 PM Data The JSON files are ready.
4:30 PM Planning Let’s divide up the remaining work (data probe, data loading, chart, and ui).
4:40 PM Design Let’s put the project data on SVN so it’s easier to work together.
4:55 PM Data Any other interesting demographic variables we should be mapping?
5:15 PM Data Here is poverty:
5:30 PM Data Here is uninsured:
6:10 PM Data Data loading is complete for five demographic variables (birth rate, medicare, poverty, uninsured, wealthy, and non-white).
9:05 PM Design We should go back to quantiles for the demographic data so the maps look balanced with respect to alpha.
9:10 PM Design We probably need non-linear alpha steps to make them look right. Differences should be optical, not mathematical.
9:40 PM Data Can we get data indexed by FIPS code in those JSON files?

Day 2 – November 8, 2012

8:30 AM Design Yeah, let’s do 10-class quantiles for the demographic variables.
8:45 AM Data Get rid of Alaska and Hawaii. There’s no data for those in the source.
8:50 AM Code The 10-class quantile maps are online.
8:50 AM Design They still look too bright overall.
8:55 AM Data Let’s problem solve any data issues. Class breaks and data distribution look okay, at least.
9:05 AM Design Let’s try that non-linear alpha scale to even these out visually.
9:10 AM Design “That’s hella-nicer.” -Dave
9:15 AM Design What kind of instructions will people need to understand these maps? E.g., Brightness is NOT margin of victory.
9:25 AM Code A basic chart is working.
9:25 AM Code How can we easily link the map and chart on mouseover?
9:30 AM Code Try looping through counties to find matches.
9:30 AM Design Here’s a new, cleaner, down-pointing triangle PNG for the user interface.
9:30 AM Code How’s that chart looking?
9:35 AM Code Are the fonts in the mockup on TypeKit?
9:40 AM Design Yep, that’s Ubuntu Regular and Condensed.
9:55 AM Code We need a red and blue PNG for the bars in the chart.
10:10 AM Code The new fonts are in.
10:25 AM Design We need a better way to do the x-axis labels on the chart. They get buried and probably aren’t very clear.
10:25 AM Code Let’s drop in an Axis Maps Logo.
10:30 AM Design Does the page feel too tall? Can we fix that without shrinking the map?
10:40 AM Design Here’s a mockup showing new chart labels.
10:55 AM Code Implemented the new chart label design.
11:00 AM Design Let’s put in an active state for the selected variable text in the UI.
11:05 AM Code Implemented the new active state.
11:05 AM Design There’s a problem with positioning the divider in the new chart labels design. How about a text pipe instead?
11:15 AM Code Implemented chart label tweak.
11:20 AM Design Horizontal page scrolling won’t go away.
11:25 AM Code The scrolling problem is fixed.
11:25 AM Design Let’s give the map a final look over.
11:30 AM Code Let’s stick in a new map title and add some instructions for users.
11:30 AM Design Dang. The page gets cut-off in Firefox.
11:45 AM Code The FF page problem is fixed.
11:50 AM Design Dang. The chart isn’t showing up in Safari.
12:05 PM Code The Safari chart problem is fixed.
12:10 PM Planning Let’s tweet this map to the world!

The Aesthetician and the Cartographer

An ugly map

Sometime around 2006, when everyone and their grandma started cranking out terrible Google Maps mashups, the Cartography world soiled its collective underpants as it looked like the once specialized profession was about to become obsolete. Fear was channeled into outrage at the whole idea of the “democratization of cartography” because it facilitated—encouraged, perhaps—the production of bad maps that ignored everything Cartographers had learned and taught over the years. In other words, “they took our jobs!

Eventually we all calmed down when we saw that people still appreciated good cartography and there was still a place in the world for us—probably even more room for us than before. Then the tools improved by leaps and bounds, to the point now where it’s possible to use them for good web cartography and it’s easy to make maps beautiful. But it might be time to get uppity again.

There is a potential problem in that last thing: beautiful maps. These are prized an awful lot these days, and I’m worried that it’s distracting everyone from the real essence of cartography and the problems that needed or still need to be solved. There seems to be an idea floating around that Cartography is now winning the War on Bad Maps because we’ve defeated Ugliness. TileMill hype is an easy thing to point to here: consider MapBox’s repeated use of the word “beautiful”; or Brian Timoney’s recent, justified praise of the accessibility and openness of TileMill’s newest capabilities, unfortunately framed in the familiar GIS versus Cartography divide that treats the latter as little more than cosmetic surgery, aesthetic touches separable from the rest of the mapping process. Meanwhile with some regularity a web map project seems to find the ultimate “success” of ending up in an art exhibition or winning the Purtiest Map Evar Award.

It all brings into question what Cartography really is (and isn’t) or needs to be in the modern web mapping world, something I’ve been pondering a lot over the past year. (Big-C “Cartography” is used here to mean the the specific profession, theories, and body of knowledge, not simply the making of any maps.) Yes, a good cartographer has graphic design skills and an eye for beauty, but as a discipline and profession it is not about aesthetics.

A beautiful map

Beauty is unquestionably important in cartography. It’s what turns functional maps into good maps and good maps into great maps. And we don’t need to be above putting form over function sometimes. Eye candy sells, and sometimes grabbing attention or being just plain artsy is whole the point of a map. The number of beautiful maps floating around lately, the public appreciation of them, and the proliferation of tools that make them possible are all very pleasing developments. We shouldn’t mistake aesthetics for Cartography itself, though. Cartographic expertise is, in essence, knowing the right way to represent geographic phenomena and data for analytical or various other purposes, and understanding of all stages of the mapping process, not simply knowing how to swoop in at the end and make a map pretty. Sure, we can make every map delicious by wrapping it in metaphorical (or real?) bacon, but it won’t be good for you.*

It’s so much easier to see the aesthetic side of maps than all the informed decisions behind them, and now that it no longer takes specialists to use the production tools and code, aesthetics start to look like the only area where specialized Cartography comes in. We don’t talk about the real Cartography enough for it to be chracterized otherwise. For every blog post or tweet you see about the newest cool graphical capability of Mapnik or d3 or anything else, how many do you see giving advice on when to use it?

Just as we always associated ArcMap with “ugly” and Illustrator with “pretty,” aesthetics continue to be tied to specific tools, and GIS and cartography people still let themselves be defined by the tools they use despite the trends away from reliance on a single piece of software. As usual we have the problem of knowing tools versus knowing concepts. It’s vital to know tools and understand how they work, of course, but in the end they’re only as useful as the operator’s knowledge of cartographic concepts. Today’s tools are new, but a lot of the amazing new capabilities we’re seeing are not new at all; they’re just better implementations. They lower a lot of barriers and have big impacts, sure, but tools are still only tools. BYOCartography.

(When it’s not aesthetics or tools, by the way, it’s the idea that map = data. You can see this in the Apple Maps uproar. But that’s a different kettle of fish for another day.)

I don’t want Cartography to be reduced to mastery of pulling levers to make pretty things. Not because I fear for my career—I can pull levers with the best of them—but rather because it limits the gains in the quality of web mapping. You don’t need to have an advanced degree in Cartography or be an old-school Cartographer to make good maps, but you do need to take the time to understand the when and why of mapping techniques, not just the how.

A map that needs some 'splainin

The traditional Cartographic solution to this kind of problem is to complain and criticize, but we need to point out what’s right more than what’s wrong. (Yeah, yeah, irony here. But think of this post as more of a lament than criticism.) After all, it’s not that bad things are happening—quite the opposite—it’s just that a lot of good things remain invisible and left out of the conversation. So next time you make a killer map, don’t just talk about how you did it; talk also about why you made the design choices you did. Let’s make it understood that there is more to Cartography than aesthetic sensibilities and technical skill, and encourage all mapmakers to be true Cartographers.



* You’ll have a cart attack. Ha!

Advice to the Aspiring Interactive Cartographer

I often get emails from recent geo-grads or new professional students asking something like:

“I’m looking to expand my skills to make interactive maps. What do I need to know to become an interactive cartographer?”

Because our industry is evolving at such breakneck speeds, the required skill sets are constantly changing. Flash actionscript code has been replaced by Javascript and HTML5. Basemap cartography is endlessly tweaked as Mapnik XML instead of Illustrator layers. We can easily build and support our own tile servers. It’s exciting change and it allows us to do more with our maps faster and cheaper.

Unfortunately, if you’re trying to break into interactive cartography and haven’t been involved with its evolution on a daily basis, it can be very tough to know where to begin. It’s no longer as easy as “learn ArcView if you want to be a GIS Tech, or Illustrator if you want to be a cartographer.”

However, while the tools may be changing month-by-month, there have been three broad areas of core competency for all interactive cartographers that have been consistent throughout:

  1. You need to be able to find, manipulate, and store spatial and non-spatial data.
  2. You need to be able to design a functional and attractive cartographic representation of that data as well as the UI controls to operate it
  3. You need to be able to implement that design through code

Working with data is probably the most underestimated part of a cartographer’s job. The steps required to go from source to ready-to-map are different for every dataset, but there are some general tasks you’ll come across at some point. You’ll need to be able to find data, navigating though state GIS websites designed in the 1970’s for administrative boundaries or combing though big data repositories (US Census, World Bank) for a single supplementary attribute. Once you find your data, you’ll need to be able to manipulate it to work with the other datasets required for your map. This is where you’ll put that GIS education to good use but more often than not you’ll find yourself trying to remember how Excel Pivot Tables work. With the data ready to be mapped, you’ll need to decide how to store it and how your map will retrieve it. Simple data can be stored in a text file like CSV (that you’re probably already comfortable with) but more complex data will often require a database. It’s really helpful to know a bit about data structures, and feel comfortable enough with a server to do some basic installation and maintenance.

Design for an interactive map comes in two separate but highly connected pieces. Cartographic design involves designing the “map” part of the map. Most of the design decisions you’ll make during this phase of design are no different than if you were doing cartographic design for a paper map. Is this the right thematic representation of this data? Does my visual hierarchy clearly communicate the message of this map? Is my basemap garish and stupid, drawing attention away from the point I’m trying to make? You’ll also need to design the UI controls to operate the map. This is a much harder skill to cultivate and is most likely something you haven’t been exposed to in your GIS / cartography curriculum. The best way to get to be a better designer is to look critically at lots and lots of web maps. Compartmentalize their interface components and decide for yourself what works on them. Steal the stuff that works and think about how the stuff that doesn’t could be improved. Learn how to quickly make UI mock-ups and wireframes of your map. Iterate over your designs before you build them, using that critical eye you’ve developed critiquing other people’s work on your own. Repeat for 2 weeks or so and then put it down because it’s probably good enough.

Andy said this best:

“Our coding process goes something like this. 1) Load the data. 2) Make things work. 3) Make things pretty. Like I mentioned before, having everything designed ahead of time is vital. We can start with something rough but functional without worrying about design, because we already know how it will look and behave in the end. It also lets us know when we’re finished; interactive projects have a way of never ending if there are no clear goals at the outset.

“After hearing from enough of my cartography peers whose hatred of programming burns with the fire of a thousand suns, I must say this: yes, coding sucks. I write code all the time, and it often makes me want to punch the computer in the face. But it’s worth it. Totally worth it. It only takes a little skill to produce awesome things. A willingness to write some code opens a lot of doors, and it doesn’t require devoting a lifetime to becoming a master programmer. It doesn’t even require being a good programmer.”

If you’re an absolute beginner this is a great place to learn the basics. Then, choose a mapping library that you like (they’re all good) that will do what you need it to do and run through the basic tutorial (usually gets you a basic map on a blank page). Once you’ve got that down, all you have to do is start putting in the hours at the keyboard.

Axis Maps has always been a small company with a very strong DIY ethos (just ask Ben who can now add “shipping tycoon” to his CV). My favorite part of working on projects here is we’re constantly learning how to solve the hundreds of problems that come up through the course of any project. You’ll never know how to do it all yourself but if you give yourself a good foundation in the basic concepts, you can start making maps and learning as you go like the rest of us.

Pirate NG Kids

“But hasn’t everything already been mapped?”

In a recent post I remarked on the common reaction people have when I say that I’m a cartographer. In my experience people are usually mildly astounded and fascinated by this exotic profession (and just like that we are new best pals), and as the conversation progresses they ask if that means something like Google Maps. But sometimes it’s the most dreaded, annoying question that every cartographer has heard: “hasn’t everything already been mapped?”

There is of course a real answer to that question (perhaps it’s something like, “everywhere, but not everything” or perhaps it’s “there’s actually this one spot in Idaho we haven’t hit yet”), but it’s more amusing to dwell on the things we cartographers hear from our new acquaintances than on what we say in reply. In that spirit, a week or two ago I posed the following on Twitter:

Survey time. Cartographers, fill in the blank based on your experience. Person: “What do you do?” You: “I’m a cartographer.” Person: ______

It generated some excellent replies. If you’re not a cartographer, when you meet one remember that these are things we’ve all heard. If you are a cartographer, please comment to share your experiences too!

@stefanie_gray has heard several good ones.

“You’re a cartographer? But isn’t the map done?!” (Yes, there is only one map! Ever! And it’s DONE!)

“Why would you study cartography if every place has been discovered?” (Uh, did I say I was in ‘conquistador studies’?)

“Hahaha making maps? On the computer? There’s already Google Maps, no need for anything else!”

@wallacetim‘s neighbor doesn’t like his prospects.

“Where’s the money in that?”

@kg_geomapper seems to hang around a mix of high-tech and low-tech map users.

Person: [response always involves mention of either a road atlas or google maps!]

I also get “oh yea, I love old historical maps”

@mapgeek reports a modern twist on the old “hasn’t everything been mapped” bit. Google did it!

“But hasn’t everywhere already been mapped by google?” aargh

She has also, much to my horror, encountered someone who is less than impressed with cartography. And from a geologist at that!

I also got a “god, how boring” response once!

I think he may have been something to do with geology! oh the irony!

@fgcartographix has also found uninterested people (which is too bad, because I usually count on cartography for an easy conversation topic) but also the usual Googlers.

Person: and then changing the subject.

Person: There’s still area to map with Google Earth? (got that one twice…)

@desjardins meets people who have a passing familiarity with a dictionary.

“um, so what does a cartographer do?” or “that’s maps or something, right?”

@NadiiaGorash knows a similar crowd.

Person: WHO?!? Me: …. Person: I see. Mapmaker!

But @nichom finds people a step behind.

Person: < blink> (mental search for what ‘cartographer’ means) Me: I make maps. Person: Cool! (let fun conversation ensue)

@vtcraghead points out that those with good taste (my judgment, not necessarily his) may know about cartography because of Arrested Development.

We are living in the shadow of Buster: http://www.youtube.com/watch?v=tj7RlQdF25A

@clubjosh has figured out a good reply to the standard line.

usually get the “hasn’t everything been mapped” line which gets my “Yeah, but some moron keeps changing things” retort

@g_fiske talks to the good ones. The ones who appreciate us.

Person: “Oh, I love maps!”

And @musingbouche is not a cartographer, but knows what to say if she meets one.

cool!

Did I miss any? Comment on this post with any other good ones you’ve heard!

Map Evolution 2



Over the summer, a friend asked me to put together a map of Punta Gorda, a small coastal town in the country of Belize. He works for Hillside Health Care International, a non-profit organization providing medical care in that area. The map was needed to help orient and guide volunteer health care professionals visiting from the States while serving at the clinic. It was to be printed in color on a letter-sized page.

In talking with my friend, I knew right away that the biggest obstacle was going to be getting good local data for the map (and getting it for free, because there was no money set aside for the project). Most importantly, I needed data for local roads (locations and names) and point features (hotels, government buildings, grocery stores, banks, etc.), these being the two main pieces he wanted clinic volunteers to have at their disposal.

Of the big free mapping services, Google Maps had the most complete road network for the town, so it served as my starting point. I had hoped there might be a nice Open Street Map shapefile to work from, but this area is still mostly a blank slate:

View of Punta Gorda in Open Street Map

So, I decided the simplest and easiest approach to getting those roads on the map would be to trace them in Adobe Illustrator. That’s where the remainder of the map design work was planned, and there was no good reason to construct a spatial database or harness the powers of GIS for our purposes, let alone the time and money to do so. We knew this would limit what what could be done with the map in the future, but a simple map illustration existing wholly outside of a GIS served our immediate purposes on the cheap.

The point features were collected in the field by my friend, who personally biked the streets of Punta Gorda and used his local knowledge and that of others who live there to collect and verify the names and locations of streets and places. His work was all done by hand by annotating an early draft of the map. While he was collecting data, I finished the layout and styling. Then, with his annotations overlaid on my working version, I placed markers at each point of interest (red and blue shapes and National Park Service-style symbols), added labels, and created the index that sits in the lower right-hand corner of the map.

Throughout the production process I captured screen shots showing the evolution of the map. When it was finished I sequenced them together to form a simple movie, as I did for the evolution of a map of downtown Madison, WI. Each screen represents about 10-15 minutes of real production work. While this PDF shows the final state of the map, the Punta Gorda movie (see it bigger here) shows how I got there. As you’ll see, it generally involved the transformation of a satellite image into a map by way of a healthy dose of cartographic abstraction and symbolization.

Ed Parsons dislikes cartographers, “more than anyone in the world”

The title was one of the opening statements made by Google’s “technology evangelist” Ed Parsons in a recent talk for the British Computer Society. In the talk he argues traditional street maps are bad (all of them) because they fail to engender a sense of place and because they abstract the world using map symbols. He goes on to say Streetview is good and doesn’t suffer any of these problems. So is Google Earth. The take-home message is that 2D is bad! Maps symbols are bad! Photos are good! And paper is bad! [subtext: Google doesn’t make paper, but if we did, we might soften our stance].

Here is my concern: I’m not aware of any research to support such simplistic claims. Merely saying them, repeatedly, doesn’t make them true. The wayfinding research that I have seen shows that for some users, for some map reading tasks, yes, absolutely Streetview and Virtual Earths and geo-tagged photos can help. And for some users and some situations paper is better than pixels. And for some users, and some kinds of data, 2D is better than 3D. But none of those statements is a blanket truth and by outright rejecting all traditional maps in his talk–even if just for wayfinding on mobile devices–an otherwise solid argument is overshadowed by hyperbole.

If drug companies made arguments like these they might try to convince us by saying “Aspirin is bad. Aspirin may make your arms fall off. But our new drug has none of these problems. Use our new drug.” The difference is drug companies are legally obligated to back-up their claims. It is perhaps the reason they don’t employ “evangelists.”

The deeper, more troubling message that we hear again and again is that cartography is little more than making street maps.  And the flip side of that coin is the only reason we use maps is for wayfinding. Streetview is very cool (it really is), but it is also pretty specialized in its uses and the advent of it does not in fact “kill cartography.”

Cartography is more than taking photographs of a street. It’s a shame that someone with this level of influence at Google has such a limited view of why we map.

Data Probing and Info Window Design on Web-based Maps

Info windows are the familiar pop-up balloons that often appear when interacting with features on a map. This activity is generally called data probing. For example, click on a Google Maps marker and up comes a little bubble with information about the place. The uses for data probing are seemingly limitless, ranging from the retrieval of map-based comments, annotations, and descriptions of ‘what’s here?’, to map stats and info graphics, to map use instructions (e.g., “get directions”), explanations (e.g., “group of 3 markers”), and controls (e.g., “zoom here”), to alternate map views (e.g., an historical map). All of this, of course, can come through in the form of text, photos, audio, and video.

Data probing is essential. In one sense, its needed because we’ve got tons of data about the world, but just small, low-resolution computer screens to view it all on. Like a drop-down list or an accordion menu on a Web page, data probing is a design compromise that can save space on maps. In another sense, however, data probing is an important design decision that can help direct map readers’ attention and understanding from the general to the specific by offering details on demand. Without data probing, we’d either have crazy-cluttered maps or watered-down maps not taking advantage of all of that rich data out there.

Of course, data probing is everywhere outside of mapping as well; on charts, graphs and all sorts of other info graphics. But here I focus on Web maps, specifically on info window design, and outline some major design considerations and provide a few examples that could help inspire your next effort.

Design Considerations
1) Size
Large footprint info windows hold lots of data but end up obscuring much of the map itself. Often, it’s the geographical context and the distribution of data around a probed location that’s helpful for a more complete understanding of a place. When an info window obscures the map, the missing section must be held temporarily in a user’s working memory until the window is closed. For this reason, it’s usually worth minimizing this kind of cognitive load and coming up with ways to make info windows more compact.

Compactness depends a lot on the volume of data that will wind up in the info window. Tiny, “tool tip”-sized window are great for small amounts of data, like a summary statistic, geographical feature name or ID, or a line of text. Larger windows, holding multiline text, images, etc., typically range between 250-350px wide and 100-400px tall. On some maps, both sizes can be used in tandem to good effect, like in the University of Wisconsin Campus Map (below).

University of Wisconsin, Campus Map
University of Wisconsin Campus Map, showing large and small info windows.

Instead of expanding much beyond the larger size mentioned, its worth considering ways of organizing info window content to keep the footprint compact. One solution we really like is the idea of using tabs to categorize content and/or mini-slideshows for previewing distinct chunks of material. EveryBlock’s city maps and Stamen Design’s London 2012 map are good examples:

EveryBlock city map
EveryBlock info window, showing mini-slideshow content.
London 2012 map
London 2012 info window, showing tabbed content.

We also like the idea of info windows that re-size dynamically (within limits) to best fit their content. When content is just a bit larger than a probe window, this can prevent the need for a scroll bar, which just creates extra work for the map user. Conversely, when content is small, the window shrinks to fit, avoiding big blank spaces that unnecessarily obscure the map. Really large amounts of content, like a full news article, are probably best presented on a new page or somewhere off the map and retrieved via hypertext links (e.g., “full text”).

Avoid too much empty space
Avoid too much empty space.

2) Position
If we apply what we learn from Eduard Imhof’s work on label positioning, the preferred place for an info window attached to points and other small objects would be to the right and somewhat above it. In contrast, left and in-line positioning would be less desirable, although Imhof acknowledges that any placement is permissible and sometimes even necessary. Compared to positioning map labels, however, info windows are somewhat of a unique challenge. This is partly because they tend to be larger in size and partly because of our interest in keeping them on screen when opened near the edges of a map or application window.

Avoid cutting-off info windows.
Avoid cutting-off info windows.

Perhaps the most common approach to keeping info windows on the screen is to auto-pan the map. This works especially well if the map extent is limitless in all directions, because there’s no concern about auto-panning off the edge. Too much auto panning, however, can be disorienting, especially when the action itself is unexpected or the distance and speed of panning are too great. Auto panning can also be disrupting to users, due to a change in the map extent, which can alter the location or visibility of markers and data layers previously in view.

One ‘smart’ info window that I really like repositions itself left/right/top/bottom around a probed location to stay on screen AND minimize the amount of auto-panning. There’s a working example and source code for this by Dmitir Abramov. Maybe, a ‘super-smart’ info window would also be aware of related geo-data (e.g., map markers) and reposition itself to minimize contact with that, as well?

3) Stem
The info window stem is the visual link that connects it to a probed location. The problem of obscuring map context in the immediate spatial neighborhood can be solved by lengthening and/or shifting the stem along the window’s edge. It’s often the immediate geographical context that we’re most interested in, anyway. The question, ‘what’s near here?’ can be as interesting, if not more interesting than ‘what’s here?’. So, generally speaking, we prefer longish tails, but can think of cases where a short tail would be preferred (e.g., like on cell phone maps or other tiny map windows).

Longer stems can reveal neighboring map content.
Longer stems can reveal neighboring map content.

Another option is to go without a stem at all, which keeps the area around a probed location totally open. The strong connection between location and info window is lost, but this can be restored to some degree with a highlighting technique, like in the The New York Times map, Geography of a Recession, below. Here, the highlight (black outline) gives users positive feedback and helps link it to the info window, which appears/disappears on mouse-over/off. For stemless windows that are persistent, (i.e., require a click to open and/or close) highlighting becomes even more important to maintain this visual connection.

New York Times, Geography of a Recession.
New York Times info window without a stem.

4) Open/Close
Opening and closing an info window should be immediately obvious to users. The advantage of mouse-over windows, like in the NYTimes example above, is that they appear with almost no effort at all and can’t easily be missed. However, this ‘always on’ nature can make if feel ‘in the way’ sometimes, especially if finding non-probable map or window space takes work.

A really obvious “X” button in the upper right corner is maybe the most immediately obvious way to close a probe. Clicking ‘away’ from the info window itself can also be effective, as long as other uses for a mouse click are also considered. In other words, should an info window close upon click+drag map panning? (Probably not.) Should it close when another location is probed via mouse click? (Probably, yes.)

One option that I don’t see too much of is that for opening multiple info windows simultaneously. Two or more open windows is very basic, yet invaluable, way of comparing details across locations. Universal Mind’s LaunchPad demo (below) allows users to open multiple info windows and then drag-and-drop them anywhere on the map. A similar approach might give users the option of “pinning” info windows to the map at their stem points, thus maintaining stronger visual linkages to locations. Perhaps, the windows could also be repositioned, with stems changing in length and direction.

Universal Mind, LaunchPad
Universal Mind's LaunchPad, showing multiple info windows.

5) Look and Feel

  • Drop Shadow. Drop shadows helps focus attention on info windows, elevating them above other map content and setting them apart from visually complex map backgrounds.
  • Window Corners. Choice of square or rounded corners is mostly a stylistic decision. If rounded, make sure that the corner radius stays constant when scaling dynamically (9-slice scaling works well for this).
  • Title. Window titles should help users answer basic questions like, ‘what are we looking at here?’, or ‘what is the name / address of this probed location?’
  • Graphic Styles. Good use of type styles and colors, background color, and/or subtle divider lines can help organize content and go along way in making it faster and easier to read.
  • Stem Position and Angle. Stems positioned too closely to a corner can appear somewhat unstable. An angled stem, as opposed to a stem that extends perpendicularly from a side, can add a bit of visual interest, but too sharp of an angle can appear awkward, as shown below. Corner-anchored stems, although more uncommon, distance a window farther from its location than side-anchored stems, assuming equal lengths. They seem to appear most stable when extending at about 45 degrees (see below).
Stems at steep angles or near corners appear less stable
Stems at steep angles or near corners appear less stable.
Corner stems appear most stable at a 45-degree angle.
Corner stems appear most stable at a 45-degree angle.

Alternatives to Info Windows
There are plenty of examples in which data probing doesn’t bring up an info window at all. Rather, data is presented in some other part of the page or user interface. Although obscuring map surface area can be avoided this way, one issue to consider is split attention. This can weaken linkages and create more work for the user, whose attention has to be in multiple places–and potentially across large distances–on screen. OpenStreetMap and Flickr’s Yahoo! Maps mashup are both good examples of this alternative.

OpenStreetMap.
OpenStreetMap splits apart a probed location (blue outline) and its related info.
Flickr map
Flickr's map splits apart a probed location (white star outline) and its info.

Other Examples of Info Windows
1) Bing Maps
Mouse over/off to open/close. Dynamic window and stem positioning. No auto-panning. Short stem. Dynamic scaling.

Bing Maps
Bing Maps

2) Google Maps
Click to open/close. Window and stem are fixed position. Auto-pan to stay on screen. Long stem. Dynamic scaling.

Google Maps
Google Maps

3) Stamen Design, Oakland Crimespotting
Click to open/close. Scrolling content. Fixed size and position. Short stem. Slight semi-transparent background.

Stamen Design, Oakland Crimespotting
Stamen Design, Oakland Crimespotting

4) Washington post, Time-Space: World
Modified Google info window. Click to open/close (small info window on mouse-over). Blue scroll buttons move between points in the cluster for a unique way of organizing content.

Washington Post, Time-Space: World
Washington Post, Time-Space: World

5) Yahoo! Maps
Click to open/close (small info window on mouse-over). Window and stem are fixed position. Auto-pan to stay on screen. Short, almost non-existent, stem. Dynamic scaling.

Yahoo! Maps
Yahoo! Maps