Archive of articles classified as' "Design"

Back home

Yakkin’ ‘Bout Mappin’

November 15, 2012

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:

  1. Entries pertaining to all three components, as well as a basic project plan, are found in the first 30 minutes.
  2. The number of entries about data start out heavy and all but disappear on Day 2.
  3. Entries about code pick up steam toward the middle and end of the project.
  4. 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!

Planning = Planning
= Data
Design = Design
Code = Code

Day 1 – November 7, 2012

8:15 AM Planning “Want to make a map?” -Dave
8:15 AM Planning “Maybe just this one last time. Then I’m retiring.” -Andy
8:20 AM Design How about an election-by-demographics map using the value-by-alpha (VBA) technique?
8:25 AM Code What’s the best technology setup for this? (Polymaps? CSS?).
8:25 AM Planning Let’s get started this way:

  • Andy: prepare the data
  • Dave: get interactive setup going
  • Ben: put together an interface design
8:30 AM Data I’m exploring election data from The Guardian in Excel.
9:05 AM Data What kinds of demographic data would be worth mapping? Which are affected by geography?
9:05 AM Design What kind of chart should accompany the map?
9:15 AM Design Margin of victory versus demographic variable by county sounds like a decent chart.
9:25 AM Data Here’s a Shapefile with geographic and election+demographic data.
9:25 AM Planning We need to share this file with the world.
9:25 AM Data Let’s explore the Shapefile in indiemapper.
9:30 AM Design We should wait and share this data once it’s all cleaned up.
9:40 AM Data Here’s a second version of the Shapefile with our map data.
10:00 AM Data What’s the best way to store the data? A series of JSON files?.
10:05 AM Data What scale is appropriate for the county boundary data? Will we need to zoom in?
10:10 AM Data There’s no need for detailed, large-scale county data.
10:10 AM Data Let’s store data and geography separately.
10:10 AM Data I’m preparing the data in Google Refine.
10:20 AM Design Anyone have good red/blue color specs?
10:25 AM Design Here are two 5-class sequential color schemes, one for red and one for blue.
10:30 AM Data Looks like there are problems with this data.
“It has Obama winning most of Wyoming handily.” -Andy
10:40 AM Data “In Colorado, that’s showing the Constitution Party candidate!” -Andy
10:55 AM Data I’m fighting with pivot tables in Excel. Trying to get sums into columns instead of grouped in rows.
11:00 AM Planning “Back in a moment… need to go do something to my car before it starts raining.” -Andy
11:45 AM Data Here’s a third version of the Shapefile with our map data.
11:50 AM Design Here’s a VBA map showing county margin of victory by population.
11:50 AM Design Switch to black background.
11:55 AM Design Let’s go with 2-class winners. It’s too hard to see both change in color and alpha.
12:05 PM Design Here are new red and blue color specs.
12:10 PM Design Here’s a new VBA map showing county winner (2-class) by population.
12:10 PM Design “That’s looking pretty okay.” -Dave
12:10 PM Design How is population classified? The map looks kinda bright, making it hard to see population differences.
12:10 PM Design Should we go with equal-interval or unclassed population instead of quantiles?
12:20 PM Data “Argh, this stupid data. Chicago is red!” -Andy
12:25 PM Data For unclassed data, opacity should be a percentage of the max, right?
12:25 PM Design “Los Angeles is ruining it for everybody.” -Dave
12:30 PM Data How about capping the population values at a certain threshold?
12:50 PM Design Here’s a new VBA map showing winner by population, capped at the 90th percentile.
12:55 PM Data What about going with population density instead, in order to control for county size?
12:55 PM Design Here’s a new VBA map showing winner by population density.
1:20 PM Data 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
1:25 PM Design The user interface mockups are done.
2:00 PM Code Maybe we ought to go with D3 so we can use a map projection.
2:05 PM Design 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.
2:15 PM Design It’s worth a try. In the end, it’s just a bivariate color scheme.
2:25 PM Data Here’s the final version of the Shapefile with our map data.
2:25 PM Planning Let’s tweet that data.
2:25 PM 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?
3:05 PM Design Does this map need a legend?
3:10 PM Planning How should we proceed, now that we’ve got data and an interface design?
3:15 PM Planning What exactly are we trying to make here? A static map viewer? A basic interactive map with data probe and linked chart?
3:20 PM Code If it’s a static map viewer, how about using indiemapper + SVG?
3:25 PM Code There are problems getting a good data probe and chart that way, plus the SVG is too huge.
3:30 PM Code D3 and JSON is sounding like the best approach.
3:45 PM Code The D3 shell is made.
“It was an election day sweep for President Robert Smith of the Goth Party.” -Dave
4:10 PM Code Here’s what it looks like with colored data.
4:20 PM Data The JSON files are ready.
4:30 PM Planning Let’s divide up the remaining work (data probe, data loading, chart, and ui).
4:40 PM Design Let’s put the project data on SVN so it’s easier to work together.
4:55 PM Data Any other interesting demographic variables we should be mapping?
5:15 PM Data Here is poverty:
5:30 PM Data Here is uninsured:
6:10 PM Data Data loading is complete for five demographic variables (birth rate, medicare, poverty, uninsured, wealthy, and non-white).
9:05 PM Design We should go back to quantiles for the demographic data so the maps look balanced with respect to alpha.
9:10 PM Design We probably need non-linear alpha steps to make them look right. Differences should be optical, not mathematical.
9:40 PM Data Can we get data indexed by FIPS code in those JSON files?

Day 2 – November 8, 2012

8:30 AM Design Yeah, let’s do 10-class quantiles for the demographic variables.
8:45 AM Data Get rid of Alaska and Hawaii. There’s no data for those in the source.
8:50 AM Code The 10-class quantile maps are online.
8:50 AM Design They still look too bright overall.
8:55 AM Data Let’s problem solve any data issues. Class breaks and data distribution look okay, at least.
9:05 AM Design Let’s try that non-linear alpha scale to even these out visually.
9:10 AM Design “That’s hella-nicer.” -Dave
9:15 AM Design What kind of instructions will people need to understand these maps? E.g., Brightness is NOT margin of victory.
9:25 AM Code A basic chart is working.
9:25 AM Code How can we easily link the map and chart on mouseover?
9:30 AM Code Try looping through counties to find matches.
9:30 AM Design Here’s a new, cleaner, down-pointing triangle PNG for the user interface.
9:30 AM Code How’s that chart looking?
9:35 AM Code Are the fonts in the mockup on TypeKit?
9:40 AM Design Yep, that’s Ubuntu Regular and Condensed.
9:55 AM Code We need a red and blue PNG for the bars in the chart.
10:10 AM Code The new fonts are in.
10:25 AM Design We need a better way to do the x-axis labels on the chart. They get buried and probably aren’t very clear.
10:25 AM Code Let’s drop in an Axis Maps Logo.
10:30 AM Design Does the page feel too tall? Can we fix that without shrinking the map?
10:40 AM Design Here’s a mockup showing new chart labels.
10:55 AM Code Implemented the new chart label design.
11:00 AM Design Let’s put in an active state for the selected variable text in the UI.
11:05 AM Code Implemented the new active state.
11:05 AM Design There’s a problem with positioning the divider in the new chart labels design. How about a text pipe instead?
11:15 AM Code Implemented chart label tweak.
11:20 AM Design Horizontal page scrolling won’t go away.
11:25 AM Code The scrolling problem is fixed.
11:25 AM Design Let’s give the map a final look over.
11:30 AM Code Let’s stick in a new map title and add some instructions for users.
11:30 AM Design Dang. The page gets cut-off in Firefox.
11:45 AM Code The FF page problem is fixed.
11:50 AM Design Dang. The chart isn’t showing up in Safari.
12:05 PM Code The Safari chart problem is fixed.
12:10 PM Planning Let’s tweet this map to the world!
1 Comment

Web cartography… that’s like Google Maps, right?

December 5, 2011

A few weeks ago I was graciously invited by Jeff Howarth to speak to cartography and geography students and faculty at Middlebury College, Dave’s alma mater. I showed some of the work we do at Axis Maps, described our processes, and offered my perspective on what web cartography is all about. The topics were mostly aimed at undergraduate cartography students who may be considering a career path like ours. (While we’re at it, check out some of the student maps.) This post is not at all verbatim but more or less sums up what I said.

The “what do you do?” exchange is always fun for me when meeting new people. When I tell people I’m a cartographer, two reactions usually occur. The first is something like “wow, that’s so cool! I’ve never met a cartographer!” (Lesson: maps make you popular at parties.) Then follows something along the lines of “so what does that mean, like Google Maps?” I then attempt to explain succinctly that yes, sometimes it is kind of like that, but no, it really isn’t.

It’s a little amazing that it’s only taken six or so years for the popular conception of a map—or at least a web map—to become so strongly tied to one type of map, and one exemplar at that. It’s both a blessing and a curse for a practice like ours at Axis Maps, in ways that I hope will be evident as I summarize the way we approach interactive web cartography.

THOROUGHLY DELIBERATE, PURPOSEFUL DESIGN

I made a bad map a couple of weeks ago. It showed 24 hours of bus GPS tracks in Boston, colored according to speed.

MBTA bus speed map

Cartographers, trained in their science, would tell me it’s a bad map. It’s a totally inappropriate color scheme for numerical data. It doesn’t generate any clear insights. But the map’s intended audience—the people for whom it was designed—speak differently. It’s eye-catching and novel, it’s reasonably popular, and most importantly it prompts interest and discussion on the state of transit in Boston. Rules and conventions shouldn’t be ignored to the point of misleading or misinforming map users, but just as with wholly “correct” and “useful” maps (which we also try to make!), this particular map successfully accomplished its purpose.

The point is something that seems to define our work and, I think, modern web cartography beyond the general practice of “making maps”: it’s all about purposeful design. Cartographic design is more than visuals and aesthetics; there’s room for the cartographer’s design decisions at every step between the initial earthly phenomenon and the end map user’s behavior.

Daniel Huffman has argued for the human element in cartography with regard to the discipline’s artistic side, and the more I think about it, the more it seems that this is not just about art in cartography; it’s part of what makes a Cartographer something more than a mapmaker. Cartography is about the careful thought behind the design of a map, not just any work (automated or otherwise) that results in a map.

DATA → DESIGN → CODE

So how does cartographic design play out at Axis Maps? We like to think of a project as three-stage process. We begin by finding out what the client wants mapped and for whom, and then assessing and obtaining the necessary data. Next we develop designs for the map, user interface, and interaction based on the known goals, assets, and restrictions. Finally, in a stage that is labor-intensive but conceptually trivial, we write code to build the map as designed. Without getting too far into the boring details of how we work, I want to mention a few notes on each stage.

Data

Anyone who has tried to make a map, chart, or anything like that will know that working with data is an easily underestimated task. Data come in a million formats and are often messy. Jeremy White, graphics editor and cartographer at the New York Times, has said that when people ask his advice on what software to know for his line of work, to their surprise he answers Excel. It takes at least passing familiarity with a variety of formats and scripts and tools to be prepared. And getting data onto a map isn’t just a matter of using ArcGIS anymore. I haven’t used ArcGIS even once in the past four years.

I’ll say two specific things about data. First, we always take care to obtain a data inventory from the client and to develop a data model early on. The data inventory (a list of everything that needs to be shown on the map) is an important first step before we begin designing anything, because obviously we need to have complete knowledge of the requirements in order to come up with a good design. Similarly, the data model (the way the data are organized, basically) will be necessary to know how to write code that loads and processes the data later on.

Second, all of that matters because complexity of the data and map can vary a lot, and it can’t be unknown when we go to design an interface. The chart below, from a paper by Robert Roth and Mark Harrower (PDF), explains why complexity matters. (It’s talking about interface complexity rather than data complexity, but we find them to be related.) We need to know about complexity and the map’s audience in order to execute a successful design.

Interface complexity vs user motivation (Roth and Harrower)

Design

If there is one clear thing I can say about our design process, it’s that it works like this: mock up EVERYTHING. Everything! We try not to leave anything to imagination. We generate mockups for every interface state, every map view, and every interaction. This usually means a couple dozen screens in the end, showing a step-by-step simulation of a user interacting with the map. We think that locking down all these designs before writing a single line of code is crucial to smooth development and good design. Otherwise we run the risk of cobbling together designs on the fly while writing code, resulting in a messier product.

We’ll always miss a few things, but with enough thinking and discussion we manage to identify most problems before encountering them during development. Our design process, like most I’m sure, is very iterative and involves a lot of attempts and review. Ben, our main Design Guy, draws on experience, conventions, constraints, user feedback, a keen sense of aesthetics, and, I assume, magic to turn ideas into great-looking and smoothly functioning designs. (Maybe he’ll have a chance to describe his methods here sometime.) He notes that there are always a zillion ways to attack a design problem, and for every alternative there is always a better one. We discuss to death possibilities for every little detail until the optimal solution is achieved. Ben’s idea of improvement in design skill is being quicker and requiring fewer attempts to arrive at the best solution to a problem.

FInding the design solution

Code

Writing code takes up the bulk of our time, but in concept it’s almost a formality to us. It’s all about choosing the right tools for the job (Flash, OpenLayers, Polymaps, jQuery, and so on) and then building what we’ve already so carefully designed. We don’t do this work in order to do interesting or novel technological things; we do it to make good maps. If cool technological developments come out of it, all the better, but it’s almost never the main purpose. In my own invented definition of cartography, cartographers are not the ones whose drive is to develop mapmaking technologies. Another related community does that, spending less energy on designing actual maps. It all works well as long as the groups exchange knowledge and each knows what the other is doing.

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.

Our coding steps for the London Low Life map

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. It’s just another skill, not so different from, say, drawing Bézier curves in Illustrator for static work. Nathan Yau’s tale (and his Visualize This book) is a good one to learn from for those who have resisted getting into programming.

WHERE DOES DESIGN BEGIN?

After describing the design we do, it’s worth noting that visuals and user experience design are only one part of the overall process of designing a map. Kirk Goldsberry, visiting scholar at Harvard and professor at Michigan State University, recently impressed upon me that design in a cartographic context—broadly meaning the decisions that go into map—is not merely figuring out the visuals, but rather exists in the entire mapping process, something I touched on earlier. Leaving out map use for now, consider the progression from phenomenon to graphic. At one end is the actual thing that is happening, at the other end is the map that represents it. In the middle are data, meaningless in isolation and not to be confused with the phenomenon itself.

Design in cartography

Above are some activities that exemplify the progressions from phenomenon to data, from data to graphic, and the whole thing from phenomenon to graphic. Ideally a cartographer designs the entire process: what data are collected, how they are collected, how they’re organized, how they’re represented, how the map looks, how interaction works, &c. Dr. Goldsberry gave the example of old-timey explorers. They went places, recorded the data themselves for the purpose of making a map, and then they crafted the map itself. They designed everything. Sometimes a cartographer can still own the whole processes, but it’s rare these days, especially in web mapping. Realistically I think most activity falls either between phenomenon-to-data or data-to-graphic, with most of us who call ourselves cartographers existing in the latter category. We work with the data we have, but it’s worth bearing in mind that we’re doing something (i.e., making a map) that the data may not have been meant for, and this can affect our user experience design decisions.

WEB MAPPING, or PUTTING THINGS ON TOP OF OTHER THINGS

Returning to Google Maps, it has defined not only the layperson’s idea of a web map but also the web mapper’s idea of a web map, it seems. Ever since the early days of Google Maps mashups, the trend in web maps has been basemap + stuff on top. There’s almost always this strict separation of layers—layers that often were not designed to go together, although that part is gradually on the decline. We’ve advanced to the point where pretty good cartography is possible and easy in this framework (thanks to tools like TileMill), but it remains the case that web cartography usually means designing around the tiled Mercator slippy map system, and often using someone else’s tiles, instead of seeking the ideal solution. We all do what’s feasible within technological and time constraints, of course. At Axis Maps we take advantage of the built-in capabilities and user familiarity with standard tiled web maps all the time. But I do sense a risk that “web map” is coming to mean only one type of map, the “things on top of other things” map.

So perhaps my purpose today is to remind us all that there’s more than one kind of web map. Cartography is not Google Maps. It’s not OpenStreetMap. It’s not mashing up geotagged data from various APIs. It’s not rendering tiles. It’s not “geo” (“geo” is a stupid non-word and I wish it would die). It’s not GIS. Cartography is in the thoughtful design of maps, no matter how they are built or delivered.

8 Comments

Representing ‘No Data’ on Interactive Maps

June 13, 2011

We spend a lot of time determining the best way to represent data given to us by our clients. Whether in the user interface or on the map itself, it’s at the core of what we do. In contrast, I’ve been surprised recently by the amount of time we’ve spent thinking about how to best represent data we do NOT have. Here, I’m talking about places where data was either not collected or not reported. Needless to say, discovering empty cells in a spreadsheet is not at all uncommon, albeit frustrating at times. This is the nature of data collected in the real world. But what is the best way to represent “no data”? It only takes a single missing value to raise the question and present this rather unique design problem.

Below are a few of the ways we’ve chosen to represent ‘no data’ in recent projects when interpolation or other means of smoothing out and covering up missing values was not an option. We feel that instances of ‘no data’ are nothing to hide from or ignore. In fact, in some cases, I’d argue that representing ‘no data’ can be a good thing and actually help to tell a more complete and truthful story about a mapped phenomenon that wouldn’t otherwise be seen.

 

Proportional Point Symbols

In the Jewish Life in America project for Adam Matthew Digital (project description), we mapped immigration, education, and population data at a number of countries, states, and cities over time to show how change took place. However, not every city has data available at every time slice. For those years when cities had no data, we mapped empty proportional point circles, sized according to the last year in which recorded data was available. For example, in the figures below the map shows that around 1890 Chicago had a Jewish population of 50,000. No data is available for St. Louis for this year, but in 1850–the last year in which data was recorded–we can see there was a Jewish population of 600 people.

Jewish population in Chicago, c1890

Jewish population in St. Louis is not available at c1890. The value at the last available time slice, c1850, is given instead.

Mapping hollow circles at years with no data can be helpful in a few different ways. First, it allows comparisons to be made between every city, albeit across years in some cases. Second, it reduces the distracting “pop-corn” effect of city points appearing and disappearing with each click of the timeline. Third, it shows the spatial distribution of all cities having some jewish population across time. Finally, and perhaps most simply, it makes for a less empty-looking and data-starved map.

 

Choropleth

For the Children’s Environmental Health Initiative Interactive Map Dashboard, we mapped a range of health, demographic and program data. In the figure below, late pre-term births at the census tract level in Durham, NC are shown. Features with ‘no data’ are represented by a gray fill color, a common technique found on choropleth maps. They can be hidden from the display via a checkbox in the user interface where the number of features without data is also shown.

Tracts with no data are represented using a gray fill color. An interface control counts and hides them.

The same map, but with ‘no data’ features hidden from display.

Places with ‘unstable rates’, although not exactly instances of ‘no data’, do not have big enough sample sizes to make meaningful inferences (as well as having some privacy concerns related to the small sample). Like features with no data, unstable rates can be hidden from the map display and ignored when necessary. However, unlike ‘no data’ these places are included in the map classification and are color-coded (i.e., not grayed-out). By treating each independently, users can refine how they want to display this more empty end of the data spectrum.

The same map, but with ‘unstable rates’ hidden from the display.

Assigning the color gray to ‘no data’ might seem like an obvious and easy choice, however, we’ve had to be somewhat careful in the past. Gray tends to recede and lie lower in the visual hierarchy than other colors on the map, and from a design perspective this can be advantageous in a number of ways. At the same time, this makes it especially important that the different meanings for “gray” are clear to the end user and that it be used consistently across the map and user interface.

While working on designs for the Illinois Public Health Community Map in collaboration with IDPH and IPRO, for example, we found that multiple uses for gray would be needed. In fact, a county on the map could be assigned one of three different gray values, and it was possible that counties representing each type could appear coincidentally. They could be gray 1) because a user zoomed in to a particular sub-region of the state, 2) because a user focused data around certain percentiles with the provided histogram control, and 3) because no data was available in the database. In addition, the health data we were mapping was calculated in several ways (e.g., “Rate of discharge” and “Deviation form Statewide Benchmark”), each requiring a different map color-scheme. In the mockup below of the Western IL health region, out-of-region counties are shown in light gray, out-of-focus counties in medium gray, and a single county with no data is shown in dark gray. To be safe, we chose sequential, diverging, and bivariate color schemes that didn’t include gray so as to avoid any potential confusion.

Mockup of the Western IL health region showing out-of-region counties in light gray, out-of-focus counties in medium gray, and a single county with no data in dark gray.

Basemap

One feature of the London Low Life Map we produced for Adam Matthew Digital (project description) involves the overlay of historical maps on a modern basemap of London so that both images can be seen together using an opacity control. However, not all of the historical maps were scanned at the same resolution, meaning the extent that zooming is possible can change from map to map. As a simple means of handling maps with ‘no data’ at the higher resolutions, we disable part of the zoom widget when the handle reaches a certain point. Zoom levels that are not available for a selected map are shown, but not clickable. This is similar to what Google Maps does when switching over to terrain from the roads map, although in that case the zoom widget is shortened instead of disabled.

In this map, the zoom track is disabled to represent the limits of available base map data.

3 Comments

San Francisco Typographic Map

December 9, 2010

HOORAY! The San Francisco typographic map is finally finished and is ready for purchase today. I made a big push to get this map ready for the holidays (with some help from Andy and Ben) and we’re really happy with the way this turned out. More images.

I went a bit overboard and decided to map the *entire* city; The amount of fine detail in this map is pretty astonishing. To fit the entire city onto a poster, of course, means the type itself has to be much smaller to fit it all in. In fact, the street text is half the size of the Chicago map (6 pt surface streets versus 12 pt) so there’s lots of detail for your eyes to enjoy.

GO BIG: Given the crazy density of streets I strongly recommend you get one in poster size (23×34 or up) so you can best see all of the parks, water features, and twisty streets the city is famous for.

WHAT’S THIS ABOUT LETTERPRESS?! Great news, we’ll be offering limited edition, gorgeous letterpress prints on rich cotton paper in the first half of 2011. While we love Zazzle (their prints rock), many of you asked (and begged!) for us to do these as hand-made, limited edition art prints and we thought that was a great idea. Want to be the first to know when they go on sale? Go here.

WHAT’S NEXT? We have New York City (Andy) and Washington DC (Ben) coming up shortly. They look sweet.

32 Comments

Typographic map posters

September 30, 2010

Today we’re pleased to show off a pet project that’s been occupying us off and on for nearly two years. After some emotional separation issues, we are declaring finished a few typographic map posters—one of Boston, and color and black and white flavors of Chicago. Everything in these maps is made of type.

Chicago typographic map

Chicago typographic map

Boston typographic map

These look good hanging on a wall, so of course prints are available. Check out the page we’ve set up with some more detailed images and links to get copies for yourself.

I began this project with the Boston map, thinking it would be fun to expand the style of my small party announcement map to a full city. The idea caught on here at Axis Maps and soon Mark and Ben had parallel effort underway for a map of Chicago, a city to which several Axis Mappers have some affinity. Ben took the lead on that map, and some twenty months later we both added our respective finishing touches and reluctantly let go.

There was nothing automated about making these maps, unless you count copying and pasting. Everything was laid out manually, from tracing streets over an OpenStreetMap image, to nudging curved water text, to selectively erasing text to create a woven street pattern. The Boston and Chicago maps differ in style, but the end result is similar: from a distance it can appear as an accurate reference map, and as you get closer you notice the thousands of words it comprises.

This has been a fun, if long, process, and we hope other people can enjoy these maps as much as we have. There are only two cities for now, but look for more in the future! Our list right now is San Francisco, New York (Manhattan), and Washington, D.C.

99 Comments

Map Evolution 2

September 9, 2010



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:

View of Punta Gorda in Open Street Map

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.

9 Comments

Data Probing and Info Window Design on Web-based Maps

July 13, 2009

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).

University of Wisconsin, Campus Map

University of Wisconsin Campus Map, showing large and small info windows.

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:

EveryBlock city map

EveryBlock info window, showing mini-slideshow content.

London 2012 map

London 2012 info window, showing tabbed content.

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”).

Avoid too much empty space

Avoid too much empty space.

2) Position
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.

Avoid cutting-off info windows.

Avoid cutting-off info windows.

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?

3) Stem
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).

Longer stems can reveal neighboring map content.

Longer stems can reveal neighboring map content.

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.

New York Times, Geography of a Recession.

New York Times info window without a stem.

4) Open/Close
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.

Universal Mind, LaunchPad

Universal Mind's LaunchPad, showing multiple info windows.

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).
Stems at steep angles or near corners appear less stable

Stems at steep angles or near corners appear less stable.

Corner stems appear most stable at a 45-degree angle.

Corner stems appear most stable at a 45-degree angle.

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.

OpenStreetMap.

OpenStreetMap splits apart a probed location (blue outline) and its related info.

Flickr map

Flickr's map splits apart a probed location (white star outline) and its info.

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.

Bing Maps

Bing Maps

2) Google Maps
Click to open/close. Window and stem are fixed position. Auto-pan to stay on screen. Long stem. Dynamic scaling.

Google Maps

Google Maps

3) Stamen Design, Oakland Crimespotting
Click to open/close. Scrolling content. Fixed size and position. Short stem. Slight semi-transparent background.

Stamen Design, Oakland Crimespotting

Stamen Design, Oakland Crimespotting

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.

Washington Post, Time-Space: World

Washington Post, Time-Space: World

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.

Yahoo! Maps

Yahoo! Maps

2 Comments

New ideas in terrain mapping for cyclists

May 28, 2009

danielbio1

I live with a couple of cyclists, who spend many of their summer days out on the trails west and south of Madison. A few months ago, one of them asked me to make a bike map for him, pointing out what he felt was a shortcoming of the ones available to him: it’s hard to figure out where the hills are. This is particularly critical if you ride in places like the Driftless Area, as my roomates do. A map showing you where to turn and which roads have wide shoulders and low auto traffic is very useful, but it doesn’t tell you how rough the next hill is going to be.

Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize

Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize

So I set to work considering how best to show elevation changes along a route, and I came up with a relatively simple concept: encode the elevation of points along the route using line width.

The symbology here is, I think, fairly efficient. By varying the width I am encoding three pieces of information: the elevation of the path, the slope, and the aspect. The first is not particularly useful, but the other two are the critical pieces of information for the cyclist. Importantly, both need to be on the map together – knowing the slope of a hill is great, but you also have to know whether, as you head along the road, you’ll be climbing up that steep grade or coasting down. Getting all that information into one symbol is not necessarily that hard. Both slope and aspect are derived from elevation, so it’s really just a matter of producing a map which shows elevation in a way that makes it easy to see the pattern of how elevation changes. Show the one variable, and your brain fills in the other two. But, it works a lot better if the symbology makes it easier for your brain to figure out how elevation changes. Compare the two maps below:

Using the visual variables of lightness or size to encode data

Figure 2: Using the visual variables of lightness or size to encode data

One encodes elevation along the path by width, and the other by color value. In my opinion, slope is much easier to figure out when line width changes than when the color value does. The color at A is darker than the color at B – but can you quantify how much darker? And can you do it as easily as you can tell how much wider the line is it at A vs B? Speed and ease of understanding are, I think, particularly important given how the maps are to be used. I am told that these will be read by people who don’t even stop their bikes while reading the map (I don’t really know anything about biking – I’m not usually permitted outside the confines of the UW Cartography Lab). So, the map has to work when they’re not looking closely or long at it. The second advantage of line widths over something like color variations is that line widths are more robust – they won’t vary according to lighting conditions, as the users bike in and out of the shade of trees and in varying levels of cloud cover.

The map on the left (using lightness) does have a couple advantages of its own. A small one: by not changing line width, we don’t have to worry about lines getting too wide (causing crowding) or too narrow (and thus being hard to see). The other advantage is really more of a lack of a disadvantage – the highest elevations are not dominant. Look back at Figure One for a moment – notice how the south-center part of the map stands out the most. It’s at the highest elevation, so it has the widest lines. But it’s also mostly flat stretches, which means that it’s not a big deal to our cyclist – they want to know about the hills, about the changes. Encoding elevation by colors keeps the reader from focusing attention as much on the high elevations, which won’t stand out quite so badly.

Instead of encoding something the cyclist doesn’t care about (elevation) and letting them figure out the things they do want to know (slope and aspect), we could just encode the latter directly. Again, though, we need both for it to be useful, and so here’s where it gets tricky. Slope isn’t so bad – it’s just however many degrees the angle is, so that’s something we can pretty easily put into a color ramp, for example. But aspect is the hard part, since it depends on which way you’re going down the road. It’s uphill one way, and downhill the other. You could put little arrows or some other indicator next to the road to indicate which way is uphill. Or perhaps encode the aspect in color hue (red for north, blue for east, etc.) while changing the lightness of the color to indicate the grade. Or, you might try this:

The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.

Figure 3: The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.

There are more possibilities, obviously. But I am of the opinion that these solutions are somewhat weaker than simply showing elevation directly – the reader has to process two different symbols (or two properties of the same symbol) and extract two pieces of information. Maybe that’s still easier than processing the symbols to extract elevation, and then calculating slope and aspect internally. But I do not think so. If you present someone with a map they intend to use to figure out the lay of the land, they’re expecting to see the terrain – hills, valleys, etc. Figure 3 above is getting too abstract. It doesn’t feel like land anymore, and so it’s harder to interpret. This is why people like hillshading – mountains look like mountains, and that’s something we can understand without a lot of processing.

I imagine a reader could train themselves to interpret something like Figure 3 faster and easier, since it does show what they want to know with about the least amount of ink possible, and without showing anything extraneous. But that will take effort and learning. Right out of the gate, I think a map showing elevation is easier to understand, because it’s a lot easier to figure out what the landscape is going to look like.

Thinking about the landscape was, in fact, what led me to the initial technique of encoding elevation by line weight. I had simply thought of it in terms of looking down on the world from high up. Roads which are at a higher elevation would be closer to your eye, and so appear larger than those far down in valleys. Whether or not this particular concept is working in the back of people’s minds when they see these maps is another matter, but it at least provided the inspiration. The more academic analysis came later, much of it while I was writing this up.

While I appreciate any general feedback readers would be so kind as to provide, I’m particularly interested to know if anyone’s seen anything like this before. It’s not a terribly complicated symbology idea, so I imagine someone somewhere must have thought of this.

10 Comments

Map Evolution

January 15, 2009


Recently, we took on a nice little print mapping project for a few hotels located in downtown Madison, Wisconsin. The project involved making a one-sided, page-sized map showing hotel locations and the locations of a few points of interest in the area. The idea was that hotel guests could use the map to find their way around downtown as well as get a sense for where they were staying in relation to the university, interstates, airport, etc. The map was to be printed in grayscale, plus 3 spot colors (red, yellow, and blue).

Before starting out, we discussed the possibility of sharing the project with those interested in seeing all the stuff that goes into designing a map like this. The map design process is notoriously difficult to articulate and we’re keen on the idea of making pieces of it more transparent, where possible. One option was to screen capture the hotel map as it appeared in the production software at regular time intervals from blank page to finished product. So, here is a sequence of 116 images, originally captured at 10-minute intervals, compiled to show the evolution of the hotel map in just under 2 minutes. Clearly, not all maps are made in the same way, but this should expose some of the kinds of design decisions made in a relatively simple project like this.

Watch the larger version of Map Evolution (990 x 766px) — best for seeing change in map details.

6 Comments

Election map follow-up

December 22, 2008

After posting our election map last month, we received a number of excellent comments and suggestions. It’s late, but I thought I’d finally post the couple of variations of the map that I’ve managed to find time to put together. The maps below do two things differently from the original:

  • Vary the brightness of counties by population density rather than total population. This was a frequent suggestion. I think it has a few of its own drawbacks too, but it looks pretty good.
  • Different color schemes. Just for fun, I’ve used the purple color scheme that has become common in recent elections. I also liked the suggestion in one comment to saturate colors by margin of victory, so I’ve done that too. In these, full blue would be total Obama domination (Obamanation? Obamadom?), full red would be the same for McCain, and gray is an even split.

No snazzy posters this time. Just a few map snapshots.

First, the original colors mapped by population density, as posted in the comments on the original post.
Election map, population density

The purple color scheme. First by total population:
Purple election map with county populations

And by population density:
Purple election map with county population densities

Margin of victory by total population:
Margin of victory election map with county populations

Margin of victory by population density:
Margin of victory election map with county population densities

Apologies for any trouble seeing the images. It’s tricky to find a brightness that will look right on every screen.

4 Comments