Archive of articles classified as' "Uncategorized"

Back home

In Defense of Bad Maps

November 19, 2013

Last month at the annual NACIS conference, I gave a presentation called “In Defense of Bad Maps” — an attempt to demonstrate the value of prolific, popular, yet supposedly “bad” cartography on the web; and to propose a small bit of advice on how to approach cartographic sacrifices in the real, professional world.

This was a last-minute submission, not without occasional regret, and as such there are no especially strong arguments here, but my hope the is that the talk provided one or two things to think about as web cartography continues to grow and evolve. Presentation slides have been posted, but as usual they don’t mean much without the spoken component. Here’s a summarized version.

F tha map police!

Now, I was going for something a little trollish, at least in the title, but I’m too mild-mannered (by day) to go on a true rant, so the provocation—while evident, I hope—is minimal. This is the tl;dr synopsis:

  1. There are “bad” maps on the web, they sometimes become very popular in spite of (or even because of) being bad, and they bother cartographers.
  2. “Bad” does not mean they fail utterly and are without use, however.
  3. All of us commit cartographic crimes, as tradeoffs and sacrifices are part of any real-world job.
  4. We can be wise and responsible in practicing “bad” cartography to good effect.
  5. We should reconsider how we conceive of web cartography, and perhaps break away from the rules of old.

Bad maps

A “bad map” could be a lot of things, but here I’m focusing on four categories, a few of which I suspect are related the potential of a map to become popular among a web audience.

  • Breakin’ the law: Rule-breaking maps are easy to identify and pick on. Mercator projection? More like jerk, hate yer projection, amirite??
  • Lack of design: It’s the dreaded pushpin map, which is the web equivalent of the godawful GIS map with a north arrow the size of a baby. It’s easy to accept defaults and crank out a web map in seconds, but defaults are rarely good across the board.
  • Form over function: Some maps pretend to say something but really don’t—they’re eye candy with no real value added by the cartographer.
  • Code over content: Similarly, there is, uh, the code candy map. A map is presented as something useful and important, but in fact exists mainly as a demonstration of its underlying technology. (This “crime” is perhaps more often committed by the people who promote the map, not the cartographer.)

Who cares?

We care about this because, well, it’s what we do. It’s what we’ve done for hundreds of years. Good cartography has been figured out, and we don’t want to take steps backward. Furthermore, perhaps, we’ve so bought into the idea of maps being powerful that we feel bad cartography may even be dangerous in the long run—or else we just want to assert how important and powerful we are as cartographers.

And, in a point to which I’ll later return, I think we look for bad maps because we don’t really embrace the web; we treat it as an obstacle to overcome. Try to find literature on web cartography that doesn’t give substantial treatment to limitations: screen resolution, colors, projection, and so on. Why did we cheer when D3 came along? We cheered because it allowed us to overcome the Mercator projection, not because it opened up so many new possibilities.

Why we do it

When it comes to deliberate carto-crimes, we make bad maps because of money. A client or boss asks us to do something stupid, and we do it because we like having a job. Or we do something bad but eye-catching, and the attention leads to work. Or we don’t have the budget or time to do a good job, so we do something quick and not so good.

Or, besides money, we make bad maps as part of a process of exploration. We’ve always done this. It’s just that it used to mean printing something out that never left the confines of our cubicles, except in the trash. The web is a much more public and open environment in which we’re encouraged to publish and share our processes, which may include bad cartography.

Bad maps are no big deal

My conjecture is simply that most “bad” maps under-inform rather than misinform. That is, they don’t entirely succeed in their purpose, but they do offer some small takeaway. And, if the sacrifices in cartographic integrity mean that the small message is more likely to reach a wide audience, the map is valuable.

Map message

The open, public exploration process is important, too. Maps needn’t always “say something” but rather can be used to prompt questions and discussion. Having more maps out there, even if many of them are technically bad, inspires us to think about a variety of issues, and additionally drives a sort of design competition that will lead to all-around better cartography.

Wise uses of bad cartography

We can, then, judiciously and wisely practice bad cartography for good reasons. Here are some ways:

  • Know the basics. Yes, you should learn basic cartographic rules and best practices. Ignorance is no reason to do anything. And, in our experience, cartographic expertise is respected. Our clients trust our decisions because of it.
  • Design in proportion to meaning. If your map is meant for a silly fluff piece that intends to do no more than raise a smile for two seconds, then sure, go ahead and make it a dumb non-normalized Mercator choropleth map. If it’s meant to explore a complex and important topic, then give it the proper thought toward good, sound cartographic design.
  • Be clear in purpose. If your map is for exploration or experimentation, let that be known. If it’s a code demonstration, bill it as such. Don’t pretend that a map is saying important things about its subject if you didn’t design it to do so. On the web, we can’t control every context in which our maps appear, but we can give them the right start and help prevent them from being carried away for the wrong reasons.
  • Accept feedback. Nothing on the web is permanent or final, and especially if we are trying new things, we should be willing to change them based on feedback from others. You don’t always have the time or resources to change something after you’ve published it, and yes this is the internet so people are probably going to be awfully rude in their comments, but you can still learn something for your next project.
  • Be smart in responding to client/boss requests. If they request something bad, first try to talk them out of it or propose better alternatives. Try some smart business maneuvers to discourage them or shift the responsibility for the decisions. When those things fail, then give in and do the bad thing. It’s not the end of the world.
  • Choose your battles. Continuing on that last point, prioritize the elements of your design. Not everything is worth defending when a client asks for a change. For example, we’ll give up on the look of UI controls most easily, then non-spatial content, then basemap symbology, and then we’ll most strongly defend thematic symbology. We’d rather have a map be not that good than be wrong.

Moving forward

What I mean to say is that bad maps are nothing to worry about, and are not a plague to fight. But we have a chance for things to be different and better, and to escape the same old types of critique.

Let’s study and understand the use and impacts of web maps specifically on massive, public audiences. What is the actual impact of a “bad” but popular map? What makes a map popular in the first place? I’m looking forward to continued attention on web map use from the academic side of cartography. There’s work from Ian Muehlenhaus on online persuasive cartography, Sarah Battersby on Web Mercator, and even more casual folks like Marty Elmer on viral maps.

Let’s continue to educate users on map reading. I feel confident in my use of a bad map, but maybe that’s because I know maps well. That should not be a privilege. More map literacy means more trust of users, which means less dumbing down of maps because we fear users won’t understand them, but also less fear that “bad” maps will be misused or dangerous.

And, importantly, let’s rethink what web cartography is. We cartographers are in a print mindset, no matter how much we think we are web mappers. The rules of web cartography are a mashing together of a bunch of different things: the principles of print cartography, web design, computer science, statistics and “data science,” and whatever else. Crucially, it’s all founded on cartography rules that were developed for static maps. We don’t need to start over, but let’s at least have a thought exercise: what would web cartography look like if we didn’t base its rules and principles on print cartography? The web is different in so many crazy ways from paper; should the rules really be the same?

web cartography

I used to be in that camp that always says, “there isn’t a new cartography; only new underlying technology.” But I’ve been backing away from that lately. True, at the moment the bulk of web cartography isn’t anything truly revolutionary—it’s only modern means of producing, presenting, and interacting with the same types of displays we’ve always had. (Think choropleth, proportional symbols, etc. We jazz these up considerably over paper versions, but fundamentally the cartography is the same.) But maybe there is a new cartography out there. Maybe our fidelity to the rules of paper prevents us from discovering it. And maybe that’s why born-and-bred cartographers are not the ones leading the charge these days.

Above map by Marty Elmer

5 Comments

Axis Maps Summer Internship

April 23, 2013

This summer we’re going to try something new by taking on an intern. Here are the details:

What: You’ll be making an interactive map of physician performance across New York. It’s a relatively small dataset covering 120 physician practices and 12 measures focusing on heart care. The map is in partnership with our friends and colleagues at IPRO and will be used to improve the quality of care in New York.
We want you to see the entire process of making a map so you will be responsible for this project from start to finish including:

  1. Working with the client to learn about their data and functionality requirements
  2. Preparing the data to go into the map
  3. Designing the map and UI elements
  4. Building the map in javascript
  5. Testing the map

We’ll be supporting you every step of the way with project planning,  best practices, technical assistance, and design reviews.

When: 8 weeks starting June 17th

Who: We’re looking for anyone looking to sharpen their interactive cartography skills, however, students currently enrolled in undergraduate or graduate programs will be given preferential consideration. To get the most out of this experience you should:

  1. Have experience working with all types of data (spatial, tabular, databases, etc.)
  2. Be somewhat comfortable with map and UI design
  3. Know the basics of building a map in javascript
  4. Be willing to learn all the stuff you don’t know

Where: Wherever you want to be with a computer and internet connection. We all work remotely at Axis Maps and keep in constant contact through Campfire, our group chat system. You’ll be expected to keep semi-regular business hours logged in to Campfire. We’ll have scheduled weekly status meetings (via Skype) dedicated to your project and you’ll be expected to attend regular Axis status meetings as well.

How much: $3,500

To apply: Please send:

  1. Cover letter
  2. Resume / CV
  3. Link to your online portfolio

to David Heyman at info@axismaps.com by May 6th.

1 Comment

Mapping Superstorm Sandy

November 1, 2012

Poking around on Twitter today I saw a couple mentions of this map from ESRI, next in what I’m sure will be a long line of maps about Superstorm Sandy. This was the first thematic map I’ve seen about the storm but it struck me as hugely ineffective. Comparing 2 variables (census statistics vs. storm impact) requires a bivariate map. Mapping one variable and hiding the other one behind a mouse action makes it impossible to see any trends or gain any meaning from the two datasets as a whole. Unless you’re interested in just a couple of counties or having the clicking abilities of a 14-year old Farmville addict, the relationship between the data will be lost.

After manually replicating the data from the map, I put together some quick maps of a few value-by-alpha maps (here’s a stellar though academic introduction from its inventors) using indiemapper. VBA maps were originally conceived to visualize election results by visually-weighting (using alpha) red / blue colored counties by their relative populations. The end result gives you an overall sense of the election by making those counties which contributed more to the result (because of their higher population) more visually prominent.

These maps use the same technique except now alpha is controlled by storm impact. Areas with a higher level of impact are more visually prominent that areas of less impact. These maps hopefully quickly give you an understanding of the population affected by the storm. While I’m sure this was the intention of the ESRI map, because of some misplaced interactivity trumping thoughtful cartography, it can’t say the same.

Median Income

Income

Black Population

Black

Percent Residents on Medicare

Medicare

Percent Uninsured

Uninsured

Unemployment Rate

Unemployment

No Comments

Your Map and the Internet

May 25, 2012

Sometimes it’s important to explain the fundamentals, just to make sure everyone is starting on the same page and to keep expectations in check. Because our heads are constantly caught up in maps and the internet, we sometimes forget that there are a few basic underlying concepts that others (clients, friends, family, etc.)  might not be grasping fully when they use our maps. A better understanding might help them through potential rough spots and frustrations, often simply resulting from a poor internet connection. We found that explaining these concepts with words alone didn’t get the message across very well. Words like “server”, “code” and “wireless” can stick better when accompanied by a picture, as can the broader concepts that surround them related to how computers request and receive code and data for mapping purposes. This is the internet infographic we came up with:

 

 

No Comments