If you haven’t seen it already, head over to the indiemapper blog for a quick tutorial on how to create some cool water/land boundary effects with a few clicks of indiemapper.
Good news, we’ve improved the export options from ColorBrewer2.0. Starting today you’ll notice a new export option: permalink. This allows you to bookmark and share specific color schemes + number of classes without having to hunt around for them. For example, this will automatically open an 8-class red sequential scheme. Neat, huh?
If you have other ideas for ColorBrewer, drop us a note.
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.
We are so pleased to accounce that indiemapper.com has launched and is ready for everyone to start making beautiful maps right away. Sign-up for you 30-day free trial. Watch screencasts of what indiemapper can do for you. Once you sign-up, you can always browse our easy-to-follow tutorials and support site to get you started, or if you are like most of us, just dive in and have fun.
Happy map making!
After months and months of non-stop design and development, the release of indiemapper is imminent. We’re all palpably excited about this product and can’t wait to get it in everyone’s hands. Thanks to everyone who has provided their invaluable expertise and enthusiasm along the way.
We’ll be spending the next 12 days fine-tuning indiemapper for launch. You can head over to http://indiemapper.com for full details. Also, be sure to follow @axismaps on twitter as we start to introduce you to all the new stuff we’ve been working on.
Without further delay, I’d like to present to you an introduction to indiemapper:
If you’ve been wondering why our blog has been a little quieter as of late, let me present to you the reason: Indiemapper. It’s our web-based mapping application built to help you make great looking maps from digital data FAST. It’s not quite ready for release yet but I did want to share with you a 3 minute overview screencast and 3 sweet looking maps made using indiemapper. As always, check out http://indiemapper.com for more details and information.
PS – Thanks to everyone who came out to our NACIS session and PCD demo. Your feedback and enthusiasm has been invaluable!
Indiemapper Overview Screencast
30-day Precipitation Totals
Europe at Night
2008 Election Results by County Population
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.
Need a quick and easy way to get shapefiles into your AS3 project? Fear not! Over on his blog, Andy has posted a set of supplemental classes to Edwin van Rijkom’s SHP code library. It’s a simple solution that will help you get from data to interactive map faster than ever.
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.
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.