Everybody loves a good Google Map mash-up. For those of our clients who already have geographically tagged data, an interactive map provides an intuitive way to visualize the scope of their work and at the same invites their audience to interactively play while learning more about their organization. And of course it has that Web 2.0 cachet that buzzes in the ears of CTOs. Sometimes the result is “neat” but fairly unexciting – more of an excuse to use display data that happens to have city, state and zip with it than a meaningful experience for the user.

Share Our Strength\'s Great American Dine Out Map

Under the best of circumstances, the map is useful to the end-user and compels them to dive in and play around, while at the same time delivering relevant information. On a recent project, Beaconfire worked with Share Our Strength to develop a Google Map for their Great American Dine Out campaign. It’s a fantastic program that has participating restaurants giving a portion of their proceeds to end childhood hunger during the week of September 21st to 28th. Diners give to charity simply by eating out at participating restaurants – all you need is your appetite and a way to find the restaurants in your neighborhood. Which, of course, is where the map comes in. I’m lucky enough to live in an area with plenty of options to choose from – if you’re in the neighborhood that week, there’s a good chance you’ll see me over at Dino eating too many appetizers and drinking artisanal gin (anything for a good cause!).

But back to the map – as useful and hopefully well designed as I like to think it is – it’s not all that different from other mash-ups. At times it might seem as if you could just swap out the data with something else and get the exact same effect. The sidebar information might change, the markers might be transformed into smiley faces or KOA rest stops, but the behavior would be the same. In fact, Google MyMaps is based on this concept – no matter what data you have, the map works the same way. You might even start to think of Google Maps as a straightforward and predetermined set of interactions. But in the wild, Google Maps often act very differently from each other, and both usability engineers and developers have tough choices to make when they create the code behind it – what to show, and more importantly, what NOT to show.

Take, for example, Trulia.com, a real-estate site that integrates a Google Map with complex criteria filtering to display homes for sale in a particular area. Utilizing the same neighborhood criteria from the Great American Dine Out on a Trulia map, I quickly find that:

  1. I will never be able to afford a home next to the restaurant where I drink artisanal gin
  2. If I drag the map about 1 screen over to another zip code, the sidebar is empty and new markers don’t pop-up on the map

Why? Well, because I have current filtering criteria limiting my search to a particular zip-code. And dragging the map changes the location I’m looking at but not the original filtering, presumably because I’m still only interested in homes that met my criteria. Compare this to the Great American Dine Out map – if I move the map to another location, the sidebar is updated, older markers fade away and new markers appear. Why? On the latter map, the search criteria is simply a starting point, and the map makes the assumption that when you start dragging it around with your mouse that you’d like to see the restaurants in the newlocation irrespective of what you initially search on. Which is better? I’d say it depends on the map.


One of the biggest challenges developers face when creating a Google Map mash-up is displaying a large number of data points. There are practical, not hard-coded limits to this – if you really want to show 5000 pin points on a map you can, but your users already left the page well before you displayed them all. Let’s say you have 1000 different data points, but a reasonable number of markers may only be 50 to 100. What are your options? In a situation where the user already has a specified location, most developers simply limit the number of returned data points by either a hard limit on the number of points or a radius which might allow for a variable number of points to show up. Sometimes the limit is explicitly stated, sometimes it is implied, and sometimes developers integrate dropdowns into the search criteria to let the user decide just how slow they want their Firefox to be for the new few minutes. In the Dine Out map we used a combination of an implicit limit on the number returned (never more than 35) and, if you zoom out far enough, an explicit radius showing you the geographic limits of the search.

But a more complex situation arises if you need to show the breadth of data on a national map scale. At that zoom level, you should rightfully be showing all 1000 points but that would make a less than usable map, in more ways than one. Different maps use different techniques to handle the situation, and now Google even provides a built-in way to do this (via the GMarkerManager object) which randomly displays a reasonable number of markers from a larger set. The former approach may not be very effective, however, if your data is not evenly distributed geographically. Here are some other approaches:

  1. Group the data by state/regions. This is how Health Map handles it, and has the clear advantage of a set upper limit on the number of points displayed. It does raise the question of where to place the marker within each state or region: regional capitol or geographical center? The capitols are set points but don’t place the markers very evenly from each other. Geographical centers allow a nicer distribution but the simplest boundary calculations mean an oddly shaped area might have markers in the sea!
  2. Distinct markers based on the number of data points. In this method, a group of 10 close data points might get a larger marker to represent several points.
  3. Colored overlays. Regions can receive a colored indicator of the number of data points in the region.

These methods aren’t necessarily distinct from one another. A developer might utilize the Marker Manager to display a random set of true data points while using colored overlays to indicate overall presence, or any other combination of techniques.

The point is, the methods used here aren’t just additional tricks to make your users ooh and ahh, they’re a fundamental part of the map experience and effective ways of controlling the flood of information pushed to the user. Truth be told, when you are developing a Google Map, getting all the data into the map is the easy part. Figuring out what to hide is where the leg work is.