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 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

New ideas in terrain mapping for cyclists


I live with a couple of cyclists, who spend many of their summer days out on the trails west and south of Madison. A few months ago, one of them asked me to make a bike map for him, pointing out what he felt was a shortcoming of the ones available to him: it’s hard to figure out where the hills are. This is particularly critical if you ride in places like the Driftless Area, as my roomates do. A map showing you where to turn and which roads have wide shoulders and low auto traffic is very useful, but it doesn’t tell you how rough the next hill is going to be.

Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize
Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize

So I set to work considering how best to show elevation changes along a route, and I came up with a relatively simple concept: encode the elevation of points along the route using line width.

The symbology here is, I think, fairly efficient. By varying the width I am encoding three pieces of information: the elevation of the path, the slope, and the aspect. The first is not particularly useful, but the other two are the critical pieces of information for the cyclist. Importantly, both need to be on the map together – knowing the slope of a hill is great, but you also have to know whether, as you head along the road, you’ll be climbing up that steep grade or coasting down. Getting all that information into one symbol is not necessarily that hard. Both slope and aspect are derived from elevation, so it’s really just a matter of producing a map which shows elevation in a way that makes it easy to see the pattern of how elevation changes. Show the one variable, and your brain fills in the other two. But, it works a lot better if the symbology makes it easier for your brain to figure out how elevation changes. Compare the two maps below:

Using the visual variables of lightness or size to encode data
Figure 2: Using the visual variables of lightness or size to encode data

One encodes elevation along the path by width, and the other by color value. In my opinion, slope is much easier to figure out when line width changes than when the color value does. The color at A is darker than the color at B – but can you quantify how much darker? And can you do it as easily as you can tell how much wider the line is it at A vs B? Speed and ease of understanding are, I think, particularly important given how the maps are to be used. I am told that these will be read by people who don’t even stop their bikes while reading the map (I don’t really know anything about biking – I’m not usually permitted outside the confines of the UW Cartography Lab). So, the map has to work when they’re not looking closely or long at it. The second advantage of line widths over something like color variations is that line widths are more robust – they won’t vary according to lighting conditions, as the users bike in and out of the shade of trees and in varying levels of cloud cover.

The map on the left (using lightness) does have a couple advantages of its own. A small one: by not changing line width, we don’t have to worry about lines getting too wide (causing crowding) or too narrow (and thus being hard to see). The other advantage is really more of a lack of a disadvantage – the highest elevations are not dominant. Look back at Figure One for a moment – notice how the south-center part of the map stands out the most. It’s at the highest elevation, so it has the widest lines. But it’s also mostly flat stretches, which means that it’s not a big deal to our cyclist – they want to know about the hills, about the changes. Encoding elevation by colors keeps the reader from focusing attention as much on the high elevations, which won’t stand out quite so badly.

Instead of encoding something the cyclist doesn’t care about (elevation) and letting them figure out the things they do want to know (slope and aspect), we could just encode the latter directly. Again, though, we need both for it to be useful, and so here’s where it gets tricky. Slope isn’t so bad – it’s just however many degrees the angle is, so that’s something we can pretty easily put into a color ramp, for example. But aspect is the hard part, since it depends on which way you’re going down the road. It’s uphill one way, and downhill the other. You could put little arrows or some other indicator next to the road to indicate which way is uphill. Or perhaps encode the aspect in color hue (red for north, blue for east, etc.) while changing the lightness of the color to indicate the grade. Or, you might try this:

The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.
Figure 3: The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.

There are more possibilities, obviously. But I am of the opinion that these solutions are somewhat weaker than simply showing elevation directly – the reader has to process two different symbols (or two properties of the same symbol) and extract two pieces of information. Maybe that’s still easier than processing the symbols to extract elevation, and then calculating slope and aspect internally. But I do not think so. If you present someone with a map they intend to use to figure out the lay of the land, they’re expecting to see the terrain – hills, valleys, etc. Figure 3 above is getting too abstract. It doesn’t feel like land anymore, and so it’s harder to interpret. This is why people like hillshading – mountains look like mountains, and that’s something we can understand without a lot of processing.

I imagine a reader could train themselves to interpret something like Figure 3 faster and easier, since it does show what they want to know with about the least amount of ink possible, and without showing anything extraneous. But that will take effort and learning. Right out of the gate, I think a map showing elevation is easier to understand, because it’s a lot easier to figure out what the landscape is going to look like.

Thinking about the landscape was, in fact, what led me to the initial technique of encoding elevation by line weight. I had simply thought of it in terms of looking down on the world from high up. Roads which are at a higher elevation would be closer to your eye, and so appear larger than those far down in valleys. Whether or not this particular concept is working in the back of people’s minds when they see these maps is another matter, but it at least provided the inspiration. The more academic analysis came later, much of it while I was writing this up.

While I appreciate any general feedback readers would be so kind as to provide, I’m particularly interested to know if anyone’s seen anything like this before. It’s not a terribly complicated symbology idea, so I imagine someone somewhere must have thought of this.

Map Evolution

Recently, we took on a nice little print mapping project for a few hotels located in downtown Madison, Wisconsin. The project involved making a one-sided, page-sized map showing hotel locations and the locations of a few points of interest in the area. The idea was that hotel guests could use the map to find their way around downtown as well as get a sense for where they were staying in relation to the university, interstates, airport, etc. The map was to be printed in grayscale, plus 3 spot colors (red, yellow, and blue).

Before starting out, we discussed the possibility of sharing the project with those interested in seeing all the stuff that goes into designing a map like this. The map design process is notoriously difficult to articulate and we’re keen on the idea of making pieces of it more transparent, where possible. One option was to screen capture the hotel map as it appeared in the production software at regular time intervals from blank page to finished product. So, here is a sequence of 116 images, originally captured at 10-minute intervals, compiled to show the evolution of the hotel map in just under 2 minutes. Clearly, not all maps are made in the same way, but this should expose some of the kinds of design decisions made in a relatively simple project like this.

Watch the larger version of Map Evolution (990 x 766px) — best for seeing change in map details.

Election map follow-up

After posting our election map last month, we received a number of excellent comments and suggestions. It’s late, but I thought I’d finally post the couple of variations of the map that I’ve managed to find time to put together. The maps below do two things differently from the original:

  • Vary the brightness of counties by population density rather than total population. This was a frequent suggestion. I think it has a few of its own drawbacks too, but it looks pretty good.
  • Different color schemes. Just for fun, I’ve used the purple color scheme that has become common in recent elections. I also liked the suggestion in one comment to saturate colors by margin of victory, so I’ve done that too. In these, full blue would be total Obama domination (Obamanation? Obamadom?), full red would be the same for McCain, and gray is an even split.

No snazzy posters this time. Just a few map snapshots.

First, the original colors mapped by population density, as posted in the comments on the original post.
Election map, population density

The purple color scheme. First by total population:
Purple election map with county populations

And by population density:
Purple election map with county population densities

Margin of victory by total population:
Margin of victory election map with county populations

Margin of victory by population density:
Margin of victory election map with county population densities

Apologies for any trouble seeing the images. It’s tricky to find a brightness that will look right on every screen.

The Best of Both Worlds: Semi-transparent choropleth maps in GeoCommons Maker!

When we were building GeoCommons Maker! one of the key map design challenges we faced involved producing semi-transparent choropleth maps. Choropleth maps are perhaps the most common type of thematic map and are regularly used to show data that is attached to enumeration unit boundaries, like states or counties. Ever seen a red state / blue state election map? This is a basic choropleth. There are a lot of more sophisticated ways that choropleths can be made to best represent a given data set, for example, by playing around with classification, categorization, choice of color scheme, etc., but we won’t get into those here.

I want to talk about color. Traditionally, choropleth maps are read by looking at the general pattern of unit colors and/or by matching the colors of specific map units to a legend. Other reference data is often removed from the map because it is either, 1) not necessary to communicate the map’s primary message or 2) makes communicating this message more difficult. It could be argued, for example, that other reference map information, like green parks, gray airports, brown building footprints, and blue water distract readers from seeing the general pattern of choropleth colors on the map, which is where the map’s most important message can be found.

For GeoCommons Maker!, we wanted to allow people to make a kind of hybrid, semi-transparent choropleth map that would show both thematic data (colored choropleth map units) AND the rich reference information on popular map tiles (e.g., Google, Microsoft Virtual Earth) without sacrificing map reading and interpretation ability and confidence. We believe that there are lots of times when reference and thematic data can work extremely well together to really benefit a map’s message (e.g., a soils map that shows terrain or a vegetation map that shows elevation). So, we wanted to build this functionality into Maker!, and allow people to make maps that show the best of both worlds.

The Problem with Transparency

The fundamental problem with transparency is that the color of semi-transparent map units can shift due to the visibility of color that lies beneath them. This is not at all surprising, but can make the basic legend matching task difficult, obscure the pattern of color on the map, or just as bad, make patterns appear out of nowhere. Here’s a look at what happens to colors using the same semi-transparent choropleth map units on different backgrounds. These are screen captures from early design mock-ups for Maker!.

The first image shows (hypothetical) opaque choropleth map units with a 7-class color ramp. The next three images show the same units at 50% opacity on top of Google terrain, streets, and satellite imagery. Notice how colors shift when compared to the opaque map at top? See how lightly colored units nearly disappear on the streets map, and darkly colored units nearly disappear on the satellite map? Yikes!

Mock-up of an opaque, 7-class choropleth map for Maker! (Google terrain)
Mock-up of an opaque, 7-class choropleth map for Maker! (Google terrain)
Same mock-up, at 50% opaque (Google terrain)
Same mock-up, at 50% opaque (Google terrain)
Same mock-up, at 50% opaque (Google streets)
Same mock-up, at 50% opaque (Google streets)
Same mock-up, at 50% opaque (Google satellite)
Same mock-up, at 50% opaque (Google satellite)

The Solution to Transparency

We employed three design solutions to ensure that semi-transparent choropleth maps in Maker! would work, despite potential map reading problems: 1) unit boundaries, 2) data probing, and 3) transparency control.

1) Unit boundaries. In Maker’s choropleth maps unit boundaries are color coded but remain opaque, even when unit fill color is semi-transparent. This gives map users some true color information to work with, and should improve their ability and confidence to spot map patterns or match colors to a legend. In other words, while unit fill colors can get you close, unit boundaries can get you the rest of the way there.

Screen-shot from Maker! showing opaque choropleth unit boundaries
Screen-shot from Maker! showing opaque choropleth unit boundaries
Corresponding legend for the above map
Corresponding legend for the above map

2) Data probing. We also took advantage of a relatively common and very helpful interactive map feature known as data probing. Exact values for any choropleth map unit can be obtained by clicking on them. In Maker!, we designed the data probing feature to go one step further and give values for all of the possible attributes associated with each map unit, not just the mapped attribute alone (see the scrolly list, shown in the probing pop-up below).

GeoCommons Maker! Data Probe
GeoCommons Maker! Data Probe

3) Transparency control. Finally, we gave mapmakers a transparency control, as well as a chance to take some responsibility for how well their maps communicate. The transparency control lets mapmakers decide what works and what doesn’t. Given the huge range of possible maps that can be made with Maker!, some user controls like this are necessary (as well as being kinda fun!). Here, transparency can be adjusted for a custom fit with any chosen tile set, color scheme, or other mapped data. Settings on the control (shown below) range from 50-100% opaque.

Screen-shot from Maker! showing the transparency control
Screen-shot from Maker! showing the transparency control

The Best of Both Worlds

Our decision to include semi-transparent choropleth maps in Maker! should give mapmakers and map users the best of both worlds. A semi-transparent choropleth is truly a hybrid map in that it can potentially offer all the advantages of combining rich reference data (i.e., underlying tile sets) with great thematic data (i.e. overlying choropleth units). Hopefully the choropleth maps coming out of Maker! will be easy to read and good looking, too!

Simplicity, not Simple

The first time I used Google Maps I knew that the world of cartography had just gotten a lot more interesting. It blew my mind. What really struck me then (and still does today) is that I didn’t have to learn how to use it: It just worked. It didn’t come with a manual, and I didn’t need a class in it. Rather, I would think, “Hey, I wonder if…” and sure enough it did just that. First try. It worked. What was happening was that my expectations of the map and the feedback it gave—and the speed at which it gave that feedback—left me feeling empowered to explore more, rather than frustrated or confused.

This is true of all the best tools in our lives: they make us feel confident (even smart), not intimated or confused or frustrated. And they quickly become completely transparent. The master violinist, photographer, or painter all work so comfortably with their tools that they are able to translate their powerful and nuanced intentions into a physical reality. We’ve all experienced this – when the interface between our cognitive and emotional selves and the world around us disappears and we are able to lose ourselves in a great book or a great movie (you cease to realize you’re sitting in the theatre watching reflected light on a screen or scanning printed characters on page).

When our tools disappear and become transparent, we are at our best. Psychologists call this ‘flow’ and I think it is the singular defining state of creativity: it’s what happens when we are so deeply engaged with the work we love that we lose track of time and need to be prompted by loved ones to stop and eat occasionally. Mozart had this problem, Newton had this too, and to a lesser extent, so do I every time I fire up Google Earth.  I often joke that Google Earth should come with a warning label: You will be here happily for hours. Proceed with caution.

Now reflect on how rare that experience is in the world of software and web interface design. Why is that? Why are we content to create maps that merely don’t crash? Below I outline how we might, as designers, aim a little higher.

The problem is, as design guru Donald Norman points out in his classic must-read The Design of Everyday Things, most people expect to be flummoxed by new technology, that’ll it be hard to learn, that it will be unpleasant at best.

Why else would people refuse to upgrade software despite obvious problems with their current version — because they’ve done the math, and the current flaws are better than having to learn a new version. Indeed, most people blame themselves when something doesn’t work, saying, “I must be stupid because other people know how to use this,” when in fact it’s most likely a counter-intuitive UI and poor or missing affordances that are to blame. The only reason why other folks know how to use it is because they’ve learned, through trial and error, how to work around those flaws. If software elicits “That made no sense, but I guess it worked…I’ll try to remember that for next time,” it is badly designed. If it elicits “I bet I can do x by using y,” you’ve earned your paycheck (ironically, most payroll systems I’ve seen are horrendous).

How do you know this isn't your interactive map or web site?

Success in UI design is not measured by “Did the person get something at the end?” but rather by “Did they grasp what the tool was capable of and how to use it quickly? What was the mental and physical workload required? How many dead ends did they go down before they found success? Did they enjoy the experience?” among other important questions. The TLX scorecard (designed by NASA) and the GOMS test are two such approaches used by savvy designers to score how well people use their tools, not merely if they can use them (or, as we often see, only use them if they’ve taken lengthy training courses).

Case in point: A Big Ten university I know reserves a mandatory full afternoon to show every new employee how to use the phone message system, representing millions in lost productivity. Uh, Houston, I think you might have a problem, and it’s not your employees. This isn’t just design snobbery it’s massive waste of money and time.


Let me propose that the best user interfaces (UIs) become transparent because they engender ”flow.“ For me, this is the holy grail of good design. The 9 components of flow, based on Csíkszentmihályi’s work (see his TED Talk) in the 1970s, can be used as a scorecard for any UI we design or use:

  1. Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one’s skill set and abilities).
  2. Concentrating and focusing, a high degree of concentration on a limited field of attention (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).
  3. A loss of the feeling of self-consciousness, the merging of action and awareness.
  4. Distorted sense of time, one’s subjective experience of time is altered.
  5. Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
  6. Balance between ability level and challenge (the activity is neither too easy nor too difficult).
  7. A sense of personal control over the situation or activity.
  8. The activity is intrinsically rewarding, so there is an effortlessness of action.
  9. People become absorbed in their activity, and focus of awareness is narrowed down to the activity itself, action awareness merging.


There is no simple magic formula, I suspect, for what defines a good interactive map (or any user interface) but I think some salient qualities include the following:

1. Give Them Something Quickly. Nothing boosts confidence like finding the power button immediately or sliding your credit card in the reader the correct way the first time (aside: omg card reader designers— after 30 years this is the best you can do? Seriously?!!). I’ve always liked Apple’s “welcome” movie that plays the first time you start up your new Mac – all you’ve done is find the power button but already you feel like you’re off to a good start. A blinking c: prompt is no way to greet your clients.

2. Adapt to the Skill-Level of the User. Maps and software should be smart enough to adapt to the level of the user, from offering pro-level shortcuts to revealing more advanced features as needed — not when they can’t be used and simply clutter up the screen and taunt the user with ”shame you don’t know how to activate me cause I’m all grayed-out.”

3. Understand Affordances. All interfaces, from airport signs to lawnmowers, live or die by them. If you are a designer, you need to eat, breathe, and sleep this stuff for the world already has too many ”Norman Doors.“ Named after Donald Norman (who talks about them in his aforementioned book), these are doors that have a horizontal bar across them and thus suggest that you’re suppose to push them, when in fact you have to pull them (RULE: horizontal bars to push, graspable vertical handles to pull). In the panic of a fire, such design flaws take on new significance.

4.    Eliminate Features Ruthlessly. My two current favorite UIs are the Google Search Engine and the iPod. Both are the model of simplicity and both burst onto the scene and quickly dominated their markets by doing the incredibly counter-intuitive thing: offer the user less. They both removed a whole bunch of features the competition thought were essential. Why? Because we are all swamped with too many choices in our lives (see “The Tyranny of Choice”) and simpler tools are (1) faster to learn, (2) faster to use, (3) cheaper to make, and (4) and less likely to break.

Unlike just about every product ever, over time the iPod has in fact gotten less complicated: The Gen 1 iPod had twice as many buttons as the Gen 3. The iPod shuffle? It got rid of the screen! Heck, the shuffle even eliminated the power jack and let folks recharge directly through the headphone jack (I still don’t know how they did that one). And it sold like hotcakes because it was cheaper to make and easier to use — they killed the features that were underused and kept just the stuff that really mattered to most casual users (pro users can still buy the more powerful models of iPod). And most folks learned, hey, you know, I really didn’t need all that stuff after all, and I just saved a bunch of money…and that is a happy customer.

5.    Build a Well Labeled Emergency Exit. If the user feels like at any moment they might break it, they won’t venture far. The best UIs increase confidence by providing reassuring feedback that progress is being made and encourage the user to keep going. We’ve all been stopped by cryptic warning messages that leave us feeling unsure of whether to proceed or cancel (I usually cancel, unless I’m feeling dangerous or it’s not my computer). Good ideas include a big reset button, unlimited undos, and lots of sign posts such as “Before we close the window, would you like me to save your work for you?” More advanced users can turn off such warnings once they’re weaned off of them. I have archiving software that asks me three times in three ways if I really, truly want to erase a drive and overwrite it. Given the cost of a mistake (10 years of my entire digital life) this five seconds of forced careful thinking is a suitable insurance premium.

Ben's pick for UI of the week - Swedish light swithces.
Ben's pick for UI of the week: Swedish light switches.

I asked Andy, Ben, and Dave to name their current favorite UIs and Ben suggested these cool light switches in his apartment in Sweden. He writes “(1) really big and square, (2) in the dark, just start smacking the wall, and (3) feels really good to smack the wall in the dark.” Hard to argue with that. Compared to the light swithces we have here in North America these are easier to use (less effort) and result in less fumbling (faster to use, fewer mistakes) and they remind us even the humble light switch can be improved with some careful thinking.

The trouble with pies

I made mention of 3D pie charts in an earlier post and thought I’d outline exactly why they are such a bad idea. As both a teacher and designer I campaign hard against “chart junk” and the needless and confusing eye candy tricks that software companies create to clutter-up our lives. I know these companies need to offer something to try and convince us to upgrade to the new version, but let’s be clear: drop-shadowing every element on the page, or adding an outer glow to the text isn’t going to make your message any clearer, and will most likely distract from the very thing you’re trying to show. My design philosophy can be summed up as:

In cartography, aim to be clear, not cool.

Anything that doesn’t contribute to the message, or worse, distracts from it, probably doesn’t need to be on the page. Since maps are small and the world is large, every inch on the page and every pixel on the screen has to count and we can’t afford to waste any of them. Draw what you need, and no more. Fans of Edward Tufte, Presentation Zen (recent post on ‘chart junk’), or old-school cartographer’s like J. K. Wright and Arthur Robinson will recognize all of this – this is hardly a new message. But it is one that still needs to be heard, apparently. For a quick overview of many of these arguments I’d strongly recommend reading John Krygier‘s excellent post “How useful is Tufte for making maps” (his 20 Tufte-isms is a great crash-course in Tufte).

Consider this graph (from here):

This pie chart commits a half dozen design mistakes and is a grrat example of chart junk
Pure chart junk: This pie chart commits a half dozen major design mistakes rendered it as little more than visual junk food (looks tasty at first, but isn't that good for you).

As an information graphic, let’s step back and think about what a pie chart is suppose to do and how it works at a perceptual level: Pie charts are used to tell us (1) how much of something exists, and (2) how much that is compared to the other categories. ‘How much’ is encoded by the size of the pie (or segment) and ‘relatively how much’ by the internal angles of the pies and/or their relative sizes. To extract data from the graphic you have to be able to quickly visually compute both areas and angles.

The bad news: Years of testing has shown that most of us are really bad at estimating the areas of even simple shapes – just try visually estimating how much carpet you’ll need for a room, especially if the room isn’t square if you don’t believe me – and we’re pretty bad at eyeballing and comparing angles too.

Not convinced, you say? Looking at the pie chart above:

  • What percent of the total does DP Tech have?
  • Is that more or less than IBM?
  • How much more/less?

Now think about presenting those data as a boring old table: DP Tech 4%, IBM 5%. Done. Simple. Think about the difference in mental workload, and the confidence you have in your answer when the data are presented as a 3D oblique pie chart and when they’re numbers sitting in front of you. This problem is so commonplace (and yet ignored) that most folks resort to putting numbers on pie charts because the graphic itself is not sufficient, which is waste of ink, their time and mine. If you have that little confidence in your charts, just give me the numbers!

Here’s a rule of thumb I like to use:

If a map/graphic needs ‘crutches’ like number labels and can’t stand on its own, don’t use it. It’s the difference between “A Tale of Two Cities” and “A Tale of Two Cities: A Novel.”

People read the simple 2D pie faster, with greater accuracy AND greater confidence.
People read the simple 2D pie faster, with greater accuracy AND greater confidence.

The same data is presented three different ways above, and each change made to “enhance” the simple 2D pie chart makes it worse because the two basic perceptual tasks – ‘how big is something’ and ‘what are the angles’ – are much harder to perform when the pie is lying down. This is exactly what happens when design decisions are made in a vacuum and based simply on “it looks cooler this way” rather than an understanding what we need from a graphic to make it readable/work.

Problem 1: Adding the 3rd dimension adds no new information to the graphic. That’s bad because it is wasted ink (that could be doing real work) and it requires the tilting of the pie so the designer can show off the 3D effect. If the height (z-dimension) added some additional data (i.e., a second data variable), it might be worth adding, although I would caution against that since we’re even worse at estimating volumes than we are at estimating areas (which is why “how many jelly beans in the jar” contests or “how big a moving van do I need?” continue to challenge us – we’re terrible at numerically estimating volumes beyond the crude level of “bigger / smaller”).

Problem 2: On both oblique pies the scale is not consistent across the graphic. In other words, the same pie segment will look larger or smaller to you the observer simply based on where it lands in the circle…things closer to us will look larger, even if they’re not. This couldn’t be more counter-productive when we’re simultaneously asking the viewer to estimate areas. This is an absolute rule: If you expect people to judge the size of things, don’t change the scale of the objects on them.

Problem 3: Splitting the pie apart makes matters worse because the further objects are from each other, the harder it is to compare them (which is why we like to hold things side-by-side if we want to carefully compare them). Why? The extra time and effort it takes for your eyes to search for and acquire the now-separated segments uses-up your precious (visual) working memory and requires more eye trips back-and-forth to make the same estimation. Cognitive scientists call those back-and-forth trips extraneous cognitive load which cut the available brainpower (working memory) that can be devoted to the real task of comparing segments (intrinsic and germane cognitive load).

Solution? Simple: Stop using oblique, exploded, jazzed-up 3D pie charts. 2D work better, are easy to read, faster to read, and easier to make. Importantly, they also can be drawn much smaller and remain legible – as cartographers we’re always looking for ways to do more with less ink. If your powerpoint slides feel naked without fancy transitions and giant 3D graphics, you’d do better to work on the substance of the talk, rather than bury your good ideas in a pile of chart junk.

I’ll leave with one of my all-time favorite spoofs – the Gettysburg Address as Powerpoint.

A new kind of election map

Update, Dec. 22: A few variations of the map technique are posted here.

2008 election results with population

We spent some of our spare time last week exploring data from the 2008 presidential election and thinking of some interesting ways to visualize it. Above is one map we put together.

One thing we sought to do was present an alternative to cartograms, which are becoming increasingly popular as post-election maps. Cartograms are typically offered as an alternative to the common red and blue maps showing which states or counties were won by each candidate, wherein one color (presently, red) dominates the map because of the more expansive—but less populated—area won by one candidate. Election cartograms such as the popular set by Mark Newman distort areas to reflect population and give a more accurate picture of the actual distribution of votes. A drawback of cartograms that we’re very aware of, however, is that in distorting sizes, shapes and positions are necessarily distorted, sometimes to the point of making the geography virtually unrecognizable.

Our map is one suggestion of a different way to weight election results on the map while maintaining correct geography. What we’ve done is start with a simple red and blue map showing which candidate (Republican and Democrat, respectively) won each county in the lower 48 states. Then, to account for the population of those counties (or, the approximate distribution of votes), we’ve adjusted opacity. High-population counties are fully opaque while those with the lowest population are nearly invisible. Against the black background, the highest concentrations of votes stand out as the brightest.

We’ll let viewers be the judge of its cartographic effectiveness, but we hope you’ll at least agree that it looks pretty cool!

Click on the image at the top of the post to view a larger version, or see it in a Zoomify viewer, or download the full size (suitable for printing).

I’m not here to make your data look pretty.

“Good design is clear thinking made visible” -Edward Tufte

Geographic Visualization, the Artist Formerly Known as Cartography, derives much of its power to speak because it is visual. We humans are voracious abstract visual thinkers: just try not seeing the characters in front of you as words that denote meaning. Or eevn wehn the wrods are sellped wonrg, our bainrs jsut power thugroh fnie, in part because we don’t just see letters, we mentally ‘chunk’ information into high-level structures shaped in large part by a clever bit of programming called prior experience. In fact, we can only read as fast as we do because we don’t read individual letters but groups of them called words, and beyond that at the highest level, because languages have understood rules that make certain combinations of letters and words impossible allowing our brains to filter-out the ridiculous and focus on the likely. This, however, is both a blessing and a curse since we can process information very, very quickly (hitting a 95 mp/h fastball), but we often only see what our brains tells us we should expect to see (why trick pitches work). As a result, words, maps and other graphic representations have an expressway into our consciousness, often imparting vast amounts of data in mere glance. We can’t help it – it’s literally how we’re wired.

While the eye-brain system is a masterpiece of evolution, it also has these well-known limitations and pitfalls. Optical illusions are one such example, including the one below by MIT professor Edward Adelson which is one of the best I’ve ever seen: It beautifully illustrates how our brains automagically discount the actual gray of the squares (their real lightness) in order to keep the logic of the checker-floor true (it discounts the shadow cast by the cylinder, our own built-in ‘image correction software’). Here’s the proof.

The brain sees what it expects to see
The brain sees what it expects to see: Squares A and B are exactly the same shade of gray. For real.

Within visualization we worry about both Type 1 and Type 2 errors; seeing things that aren’t there, and missing things that are. Given both the power of graphics to speak so clearly to us and the very real limitations of ‘visual thinking’, it behooves us to not only use such power wisely, but to also understand as Alan MacEachren notes, how and why maps work.

Maps, Schmaps

When some visiting speakers come to my department and learn I’m ‘the cartographer’ it’s amazing how many times their next comment is “I know my maps are bad” and smile or chuckle, but with the unspoken “but that doesn’t really matter to my message/findings/purpose.” Can you imagine if I confessed that I was ‘the statistician’ and they said “I know my stats are totally wrong” and brushed it off with a smile? This is especially disturbing when these maps are so often the central piece of evidence offered up by these speakers (“as you can see here on the map, there is a clear correlation between…”). It’s not so much that this is bad graphic design that worries me; It’s that this is bad science.

I’ve seen many researchers take years to painstakingly collect and verify their data. Science is by design a very slow and thorough process and it has to be to ensure that our knowledge claims are correct. But after taking sometimes years to collect the data, I’m astonished when I see brilliant scientists content to present their findings using clunky maps and graphics that showcase how bad software defaults are and little else (don’t get me started on 3D pie charts!). They look as if they were slapped together in 20 minutes and that saddens me because their work deserves better than this, especially when one considers that these images so often become the public face of this data. Indeed, many famous maps and graphs are produced and reproduced for years, long after the original paper they were attached to have been forgotten. As Edward Tufte has demonstrated time and time again, better designed graphics would make their arguments clearer, more convincing, the data richer and more nuanced.

Why Design Matters

To be clear: Good cartography is more than making data pretty. It’s a recognition that the best data in the world can be diminished–or worse, distorted–if the map is clumsily executed. It’s a recognition that the map is the intuitive and flexible interface between our data and the knowledge we seek to gleam from those data. We may live in a glorious digital age, but let’s face it, those 1’s and 0’s we’re so good at collecting don’t really come alive until we translate them into images and maps and graphs that are representations of data, those data themselves being representations of the real thing.  Maps should not, thus, be confused with reality (although they are often assumed to be perfect mirrors of reality).

Most importantly, good design and good map-making is an understanding that the graphic choices we make fundamentally change what our data say, and thus, what we think we know about the world. If we’re sloppy about how we choose to represent our data (and by proxy, the world), then we’re being sloppy about the knowledge those images create inside our heads. This is why relying on software defaults, the one-size-fits-all-needs approach to design, is something we at Axis Maps have worked so hard to fight.

When maps are offered-up in the dual role of both ‘evidence’ of our knowledge claims, and the means by which we explain those knowledge claims to others, should they not be subject to at least the same standards that would be applied to any other part of the scientific process (e.g., data quality, statistical significance)? Maps are the ultimate executive summary: caveat emptor.

I’ll leave with a quote from the delightful blog Presentation Zen (August 30th, 2006):

To many business people, design is something you spread on the surface, it’s like icing on a cake. It’s nice, but not mission-critical. But this is not design to me, this is more akin to “decoration.” Decoration, for better or worse, is noticeable, for example — sometimes enjoyable, sometimes irritating — but it is unmistakably *there.* However, sometimes the best designs are so well done that “the design” of it is never even noticed consciously by the observer/user, such as the design of a book or signage in an airport (i.e., we take conscious note of the messages which the design helped make utterly clear, but not the color palette, typography, concept, etc.). One thing is for sure, design is not something that’s merely on the surface, superficial and lacking depth. Rather it is something which goes “soul deep.”