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 Nacenta, Uta 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:
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).
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:
The FatFonts World Population map is now available from the Axis Maps store. All profits will be re-invested to fund more FatFonts research.
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:
Entries pertaining to all three components, as well as a basic project plan, are found in the first 30 minutes.
The number of entries about data start out heavy and all but disappear on Day 2.
Entries about code pick up steam toward the middle and end of the project.
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!
Day 1 – November 7, 2012
“Want to make a map?” -Dave
“Maybe just this one last time. Then I’m retiring.” -Andy
How about an election-by-demographics map using the value-by-alpha (VBA) technique?
What’s the best technology setup for this? (Polymaps? CSS?).
Let’s get started this way:
Andy: prepare the data
Dave: get interactive setup going
Ben: put together an interface design
I’m exploring election data from The Guardian in Excel.
What kinds of demographic data would be worth mapping? Which are effected by geography?
What kind of chart should accompany the map?
Margin of victory versus demographic variable by county sounds like a decent chart.
Here’s a Shapefile with geographic and election+demographic data.
We need to share this file with the world.
Let’s explore the Shapefile in indiemapper.
We should wait and share this data once it’s all cleaned up.
Here’s a second version of the Shapefile with our map data.
What’s the best way to store the data? A series of JSON files?.
What scale is appropriate for the county boundary data? Will we need to zoom in?
There’s no need for detailed, large-scale county data.
Let’s store data and geography separately.
I’m preparing the data in Google Refine.
Anyone have good red/blue color specs?
Here are two 5-class sequential color schemes, one for red and one for blue.
Looks like there are problems with this data.
“It has Obama winning most of Wyoming handily.” -Andy
“In Colorado, that’s showing the Constitution Party candidate!” -Andy
I’m fighting with pivot tables in Excel. Trying to get sums into columns instead of grouped in rows.
“Back in a moment… need to go do something to my car before it starts raining.” -Andy
Here’s a third version of the Shapefile with our map data.
Here’s a VBA map showing county margin of victory by population.
Switch to black background.
Let’s go with 2-class winners. It’s too hard to see both change in color and alpha.
Here are new red and blue color specs.
Here’s a new VBA map showing county winner (2-class) by population.
“That’s looking pretty okay.” -Dave
How is population classified? The map looks kinda bright, making it hard to see population differences.
Should we go with equal-interval or unclassed population instead of quantiles?
“Argh, this stupid data. Chicago is red!” -Andy
For unclassed data, opacity should be a percentage of the max, right?
“Los Angeles is ruining it for everybody.” -Dave
How about capping the population values at a certain threshold?
Here’s a new VBA map showing winner by population, capped at the 90th percentile.
What about going with population density instead, in order to control for county size?
Here’s a new VBA map showing winner by population density.
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
The user interface mockups are done.
Maybe we ought to go with D3 so we can use a map projection.
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.
It’s worth a try. In the end, it’s just a bivariate color scheme.
Here’s the final version of the Shapefile with our map data.
Let’s tweet that 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?
Does this map need a legend?
How should we proceed, now that we’ve got data and an interface design?
What exactly are we trying to make here? A static map viewer? A basic interactive map with data probe and linked chart?
If it’s a static map viewer, how about using indiemapper + SVG?
There are problems getting a good data probe and chart that way, plus the SVG is too huge.
D3 and JSON is sounding like the best approach.
The D3 shell is made.
“It was an election day sweep for President Robert Smith of the Goth Party.” -Dave
Here’s what it looks like with colored data.
The JSON files are ready.
Let’s divide up the remaining work (data probe, data loading, chart, and ui).
Let’s put the project data on SVN so it’s easier to work together.
Any other interesting demographic variables we should be mapping?
Here is poverty:
Here is uninsured:
Data loading is complete for five demographic variables (birth rate, medicare, poverty, uninsured, wealthy, and non-white).
We should go back to quantiles for the demographic data so the maps look balanced with respect to alpha.
We probably need non-linear alpha steps to make them look right. Differences should be optical, not mathematical.
Can we get data indexed by FIPS code in those JSON files?
Day 2 – November 8, 2012
Yeah, let’s do 10-class quantiles for the demographic variables.
Get rid of Alaska and Hawaii. There’s no data for those in the source.
The 10-class quantile maps are online.
They still look too bright overall.
Let’s problem solve any data issues. Class breaks and data distribution look okay, at least.
Let’s try that non-linear alpha scale to even these out visually.
“That’s hella-nicer.” -Dave
What kind of instructions will people need to understand these maps? E.g., Brightness is NOT margin of victory.
A basic chart is working.
How can we easily link the map and chart on mouseover?
Try looping through counties to find matches.
Here’s a new, cleaner, down-pointing triangle PNG for the user interface.
How’s that chart looking?
Are the fonts in the mockup on TypeKit?
Yep, that’s Ubuntu Regular and Condensed.
We need a red and blue PNG for the bars in the chart.
The new fonts are in.
We need a better way to do the x-axis labels on the chart. They get buried and probably aren’t very clear.
Let’s drop in an Axis Maps Logo.
Does the page feel too tall? Can we fix that without shrinking the map?
Here’s a mockup showing new chart labels.
Implemented the new chart label design.
Let’s put in an active state for the selected variable text in the UI.
Implemented the new active state.
There’s a problem with positioning the divider in the new chart labels design. How about a text pipe instead?
Implemented chart label tweak.
Horizontal page scrolling won’t go away.
The scrolling problem is fixed.
Let’s give the map a final look over.
Let’s stick in a new map title and add some instructions for users.
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.
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.
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.
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?”
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:
You need to be able to find, manipulate, and store spatial and non-spatial data.
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
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.
“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.
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!
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:
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.
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.
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).
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:
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”).
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.
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?
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).
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.
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.
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).
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.
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.
2) Google Maps
Click to open/close. Window and stem are fixed position. Auto-pan to stay on screen. Long stem. Dynamic scaling.
3) Stamen Design, Oakland Crimespotting
Click to open/close. Scrolling content. Fixed size and position. Short stem. Slight semi-transparent background.
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.
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.
Lots of maps are coming out that document when, where, and how stimulus money is being spent through the ARRA, like these at the Foundation Center. With all of the reporting, accountability, and transparency required of ARRA grant recipients, I’m sure we’ll only be seeing a lot more of these in the future. Recovery.gov directs traffic to states’ Web sites where some of this data is appearing. I’m looking forward to seeing more and more mash-ups and interactive maps and graphics as developers and designers get their hands on this stuff and data from other sources that track stimulus money.
For now, we decided to get involved by putting together a static map that shows where our ARRA tax dollars are going for energy-related programs administered by the DOE. As underlying layers, the map shows states’ historical energy consumption trends and their projected trends required to meet consumption goals set for 2012.
I’m sure we could all talk about the politics around ARRA funding and energy consumption and how this might or might not be shaped by patterns that the map does or doesn’t show. But to me, a few of the most interesting things about this map are related to its design:
1) Encoding data in state boundaries
I’ve always been attracted to National Geographic political reference maps, with their countries each outlined in a different color. On those maps, outline color clearly helps distinguish one place from another. Plenty of other maps use enumeration unit outlines to represent data, too, like those that categorize administrative boundaries using line weight, dashes and dots, etc. I wondered what was to stop the application of this idea to a thematic map? Why not try to take it one step further and encode numerical data, as opposed to nominal data, in unit outlines? I haven’t seem many examples of this.
The main limitations here are line weight and unit size. Line weight has to be heavy enough so that color can be seen and read. For my map, this seemed to work best above around 4 pts. Only thing is, as enumeration units get smaller, the outline can eat up more interior space and obscure the presence of a second data set, which in this case is the historical energy consumption trend, encoded using unit fill color. So, I had to cheat a little bit with some small states and states with small pieces (e.g., Delaware and Maryland) and decrease the line weights a bit under 4 pts. I don’t see this approach working very well with really small enumeration units like US counties, unless the map scale is really huge.
2) Color selection
The challenge here was to select colors for three data sets (historical energy, projected energy, and ARRA money) that not only encoded data properly but were harmonious (i.e., not competing or ugly). The historical energy data set has a natural midpoint around zero, so it needed a diverging color scheme. On the other hand, the projected energy data, having no midpoint, required a sequential scheme (thanks to ColorBrewer 2.0 for both sets of specs). Proportional rings for ARRA money just needed to be readable and look nice on top of the other colors.
Here are some earlier attempts at getting color right. In my first try, I used a grayscale sequential ramp for the historical data (state fill color), matching the middle value to the map’s background for a pseudo-diverging ramp feel. But this seemed overly subtle and downplayed the importance of clearly distinguishing states with decreasing and increasing energy consumption trends.
So, my next try was to replace the grayscale ramp with a true diverging ramp. Yuck. The mix of red outlines and fill colors bothered me on an purely aesthetic level. Other diverging ramps with other hues in them produced similarly ugly results.
The final colors for historical energy consumption trends (blue-white-red) seem to best emphasize the data’s midpoint, with red doing its part to connote “alarm” in the states with a poor track record. The projected energy consumption data set is now lower down in the visual hierarchy (shown using a grayscale color ramp on state outlines), but this seems to be acceptable compromise. Using gray prevents these two ramps from competing for attention or overlapping and confusing the map reader. From my perspective, at least, it also results in an (yes, subjective) improvement in overall color harmony.
Other thoughts about the ARRA funding map? Please add them to the comments.
Google Earth is amazing. As we’ve commented here before, it continues to blow our minds and has also done wonders for the popularity of maps. And let’s be honest, it looks super cool. There is no doubt that Google Earth is much sexier than that boring old atlas collecting dust on your shelf: It’s interactive, seamlessly integrates distributed data sources, animates the surface of the earth over time, facilities virtual communities, can be customized by both developer and user, etc, etc. It’s hard to not be impressed.
So all of our maps should be in Google Earth, right?
In fact, despite recent efforts to create a suite of thematic mapping approaches, Google Earth is a terrible environment for presenting many kinds of thematic maps. I’d go so far as to say that the 3D prism maps and 3D graduated symbol maps we see popping up in Google Earth are pure chart junk, of the kind Tufte warned us about repeated for past 25 years.
Chart junk takes what should have been a simple-to-read graphic and makes extracting information (1) slower, (2) more difficult, and (3) more prone to reading errors, because of excessive ornamentation and unnecessary design additions—like adding a 3D effect that communicates nothing in and of itself but simply “looks cool.” This is not idle speculation: Research consistently shows chart junk and “redundant ink” hurt otherwise fine graphics.
Want to see for yourself? Download these two example KML/KMZ files from blog.thematicmapping.org and run them in Google Earth. While you’re looking at them try to extract numbers or compare places: KMZ File 1 | KML File 2
“BUT THEY LOOK COOL”: A TECHNOLOGY IN SEARCH OF A PROBLEM
As Abraham Maslow said, “If the only tool you have is a hammer, you will see every problem as a nail.” This seems to be the case with virtual globes and the developers who love them and insist that any and all kinds of thematic data belong there. Instead, I’d challenge us to take a step back and ask,
WHY DO WE MAKE THEMATIC MAPS?
For a long time folks like Robinson, Dent, and MacEachren have been arguing that thematic maps exist to support two basic tasks: (1) the ability to extract numbers/facts about specific places (e.g., 15C in Paris) and (2) the ability to judge those values in geographic relation to other places (e.g., 5C warmer than London, about the same as Milan). In other words, we want both specific details and overall patterns to be obvious on our thematic maps. And we want all of that AT A GLANCE.
The problem with digital globes (as with all globes) is you can’t see half the planet and, due to curvature, really only about a 1/3 of the planet clearly at once. Which leaves us with a conundrum: If you’re only mapping a small place (e.g., a country), why do you need to have it on a globe? And if you have a global dataset, why would you allow your readers to only ever see ½ the data at once? They can rotate the globe (more on this later) but they’ll never be able to see the entire dataset at once. That makes understanding overall patterns very difficult, and asking folks to “remember” half of a global dataset while they spin the globe to the other side is far, far beyond the meager limits of our working memory. If you’re not convinced, just try it.
KNOW YOUR HISTORY
What makes these recent developments even more frustrating is that in the 70s and 80s, with the advent of digital map making, cartographers flirted with, and largely rejected, faux 3D prism maps and 3D graduated symbol maps (like the two examples above) since they suffered from several limits:
visual occlusion (not all of the map can be seen at once since some places hide others)
people suck at estimating volumes, especially of complex shapes (e.g., try estimating the size of moving van you’ll need for your home)
mental rotation of complex shapes is extremely hard, so hard that it is often used as a measure of intelligence in IQ tests.
Many a thesis and dissertation was written in the past 40 years demonstrating these limits to human visual processing.
The nice thing about Virtual Earths is that you can rotate them, so the problem of visual occlusion is solved, right? Yes and no. Yes, interactivity and the ability to rotate the globe can help reveal hidden places, but no, these virtual globes introduce a significant extraneous cognitive load because the user must now think about controlling the globe (not always easy with a mouse) while also trying to focus on the thematic content. In fact, adding a complex task, like visually acquiring the Google Earth controls and then trying to figure out how to move/scale/reposition the globe between two other tasks effectively “flushes” short-term working memory. It’s a kind of mental sorbet, which is why giving folks something distracting to do is a common trick in memory tests (they lose their train of thought). Why would we deliberately do this to our map-readers?
BIG PROBLEM: INCONSISTENT SCALE
In the examples above it is really hard to judge relative sizes. Why? Because the scale of the symbols is constantly changing, and the ones closer to the viewer are much larger (and at a different scale) than the ones far away. Given that it has been long established in cartography that people are terrible at estimating sizes, and even worse at estimating volumes, it is utterly inane to compound this failure by drawing the symbols at different scales. Of course it is worse than this: Rotating the globe slides each symbol through its own scale transformation path, changing in size with every pixel the maps are moved.
This is an absolute rule:If you want to give people the best chance to judge the relative sizes of objects, they should all be drawn at the same scale.
STILL NOT CONVINCED? LET’S DO SOME USER TESTING
TASK #1: As quickly as you can, how does Nepal compare to Uzbekistan?
TASK #2: As quickly as you can, find all of the other places on the map similar to Nepal? Which place is most similar? Which one least?
Hard, isn’t it? To be honest, it shouldn’t be: A regular 2D classed choropleth map or proportional symbol map would make short work of those questions. So what did we gain by extruding the countries up into space? Not much that I can see.
The Lack of a zero-line referent makes it hard to judge absolute magnitudes.
The “fish eye lens” effect mean each prism is viewed from a different angle than its neighbors, making comparison just a little bit harder as we have to mental account for these differences in our estimates.
It is hard to judge the height of something when you are staring directly down at it. This matters because height is the visual variable that does the “work” in this graphic—it’s how the data are encoded visually. Why obscure the very thing map-readers need to make sense of the graphic (e.g., the side-view height of each polygon)?
I need to be convinced of two things: (1) something is fundamentally wrong with our proven and highly efficient planimetric thematic maps, and (2) that reprojecting this data onto a virtual globe somehow solves those problems. Otherwise, we truly have a cool new technology in search of an application, and that’s just putting the cart before the horse.
Some suggestions: First, unless the 3rd dimension communicates something and isn’t merely redundant data already encoded in the colors, sizes, etc., do not include it (for all the reasons outlined above). Second, if you want folks to perform “analytical map reading tasks” such as estimating relative sizes, distances, or densities, keep scale constant. Third, do not obscure parts of the map behind other parts if that isn’t inherently relevant to the data (e.g., this is fine for terrain visualization). Fourth, and most importantly, do some user testing before presenting a new technique as the best thing ever: It’s how research works and why it is important.
So what things are Google Earth (and other Virtual Globes) good for? The consensus around here is (1) to engender, quite powerfully at times, a qualitative “sense of place” or “immersion”; (2) for virtual tourism (e.g., sit on top of Mt Everest) or virtual architecture/planning; and (3) to perform a kind of viewshed analysis and see what can and cannot be seen from locations (line-of-sight). All of those are inherently 3D-map reading tasks in which the immersive, 3D nature of the map is important. By comparison, population data (one number per country) is NOT inherently 3-dimensional and is only made to suffer when dressed-up in prism maps and 3D figurines.
Cartography, like all good design, is about communicating the maximum amount of information with the least amount of ink (or pixels). The world is just too complex and interesting to be wasting our ink/pixels on non-functioning ornamentation.