Making the case for hover interactions in digital maps

Why producing static image maps is not a viable solution to cross-device compatability

In keeping with my recent spate of mapping nerdiness, I decided to take an interactive map I produced last month displaying statewide annual population changes a step further by adding mouseover/hover capabilities. Here’s the hover-y, nicely-colored choropleth map I came up with. But before I get into the nitty-gritty of how I created the map — which I’ll explain step-by-step in a later post — let me exercise a bit of self-indulgence by defending my growing belief in the need for hover capabilities when visualizing geographic data.

Not too long ago, I was an avid believer in the no-frills, less-interactivity-is-more approach to mapping geographic data, espoused by the brilliant Brian Boyer (@brianboyer), News Applications Editor for NPR and a former member of the News Apps Team at The Chicago Tribune. Boyer’s argument for the need to keep maps simple — like they used to be back in the days of ink and paper — certainly has its merits. After all, the process of bringing a physical map closer to one’s eyes to get a better view is a natural, timeless user interaction, and maps like this one, which Boyer produced during his time at The Tribune, are far more intuitive in communicating information upon first glance than many of the infoWindow-laden Google maps being produced by news organizations these days, many of them simply for the sake of being called ‘interactive’ (for those of you fortunate enough not to be mapping nerds, infoWindow is just Google-speak for the clickable popup boxes you see in Google maps).

But Boyer’s minimalist mapping aesthetic only really works when you have one or two pieces of textual data you want to display for each geographic area. What if you have multiple pieces of information you want to display for each polygon, such as in this snazzy map from The Texas Tribune? Or, less likely but equally problematic, what if you need to bind non-textual data to your geographic polygons, such as images or Google Charts? In cases such as these, you’re going to need to provide some sort of interaction that allows the user to expand and collapse the data for each area individually, or you’ll just end up with a chronic case of visual overload.

Not to mention, on a more abstract level, studies have repeatedly shown that users tend to spend more time on applications that provide direct feedback based upon their actions, even if that feedback sometimes makes their ability to consume information at first glance less efficient (see Donald Norman’s 2005 book Emotional Design: Why We Love (Or Hate) Everyday Things, in which Norman asserts that the feeling of emotional satisfaction and empowerment users receive from triggering an action not only puts them in a clearer state of mind, but also makes them more engaged in the information at hand). So, if we’re trying to communicate geographic data to users as effectively as possible, it only makes sense that we’d want to have a certain degree of user interaction — both for the sake of preventing visual overload and for making users feel more engaged. Such is the logic behind clickable infoWindows.

Still, clickable popups leave us with another problem: Users have to make the conscious and deliberate effort to click a polygon to see the data for that geographic area. Requiring clicks may sound like a trivial task to the designer or journalist-programmer, but for the short-attention span user, it can be an awful lot to ask for. To be fair, however, click-triggered popups may not be much of a problem for maps with only a few dozen polygons. But for maps with hundreds of small polygons — say, census tracts or zip codes — it can be very tedious to click the right polygon without first having to zoom into the map so far that you lose sight of the broader context.

All of this leads me back to a conversation I had a couple of months ago with a friend of mine from Columbia’s J-School, Michael Keller (@mhkeller), who’s now working as the Senior Data Reporter at The Daily Beast. Michael insisted to me after a Hacks/Hacker event that providing hover interaction for maps is almost always a good thing, because hovers require less work on the part of the user. I’ll admit that I was dubious at the time, thinking of hovers as often unwanted, accidental triggers that can be distracting to the map and data at hand. But lately I’ve come around to his way of seeing things. If implemented correctly (i.e. no flashy interactions that cover up other parts of the map), hovers are almost always a good idea. For example, thisrecent map of New York Stop-and-Frisk data that Keller produced for The New York World using CartoDB and Leaflet is so detailed that it couldn’t possibly have worked without infoWindows, and would have been unwieldy if it relied on click-triggered interaction. By including floating mouseover capabilities, the map allows the user to scan quickly through the chloropleth map to see individual Stop-and-Frisk data from each block, without having to attempt to click through minute geographic areas.*

I’m certainly not advocating interaction for interaction’s sake (although such a case could be made, given the dynamics of the Web). But I am saying that hovers give more immediate visual feedback than click-triggered events, especially in maps. Hovers help draw users into the data without requiring them to seek it out consciously — almost like a catchy lede would in a print narrative. So for the time-being, I’m pro-hover.

EDIT: Keller later messaged me letting me know that some examples that better illustrate the power of hovers include this map and this map, both of which use hover functionality to help highlight the effects of proposed redistricting efforts in the New York State Senate. What you’ll also notice about Keller’s maps is that they include hover states, which I also think is a necessity, especially for maps that include lots of small polygons.

Originally published at carlvlewis.net on July 13, 2012.