Nov 9, 2010
As a matter of policy, Stamen generally don't work with advertising agencies. It's too hard to figure out what to do when you're not in direct conversation with the person holding the checkbook and able to make the final call, and there's too much silence involved. Usually you wind up having more conversations about what it's going to take to convince the client to release their data and making up for gaps in the material than you do working with interesting datasets and lovely visualizations, and that's something that seems to be endemic to the whole process of advertising.
Ben Terret, who works with Really Interesting Group, Newspaper Club and Weiden + Kennedy London, convinced me otherwise over a martini or three at the Rite Spot, and I'm proud to say that our resulting collaboration on the Nike Grid project is live as of this weekend.
There's a thread running straight from Newspaper Club to this project. We've got all this marvelous infrastructure—newspaper printing presses and everything that goes along with that, like delivery trucks, ink distribution systems and pre-press services in the one example, and phone boxes, land lines running underneath the streets and advertising services on the booths on the other—and we're not really using it anymore. Newspaper presses are falling into disuse, and apparently British Telecom don't even bother to repair broken phone boxes anymore. My working life started in earnest when I was a bicycle messenger in New York in the late 1980s, and all of that business was done over beepers and the phone booths of Manhattan, so I've never really quite gotten over this idea that there'll come a time when there simply aren't any public phone booths on the streets. But it's clearly on the horizon, as is the death of the physical newspaper. So the idea of doing something with all this infrastructure while it's still around is really appealing to me, and I continue to be impressed with the guys at RIG for bringing these kinds of issues to the fore in a way that's both eye-opening and commercially relevant.
In any case there are a few specific parts of the project to talk about. The background maps are a custom tileset designed by Geraldine using data from Open Street Map (and credited properly as such, this time) and generated using Tile Stache.
AKQA put together the snazzy interactive map that uses the tiles, combining the designed street tiles in combination with Google's satellite imagery...
..with results that are eerily reminiscent of satellite/street combination maps that we made for the London 2012 Olympic and Paralympic Games:
This last bit deserves a final point: W+K are taking each day's race data and publishing daily updates highlighting various aspects of the race. Today's video isBoys vs Girls, showing the relative points and badges etc. accumulated by boys vs. girls over the course of the day. It ends with a "get running, girls!" message, and I love that data visualization is being used as a way for a brand to tell a story, in something close to real time, in a specific way tailored to the events on the ground:
Shawn and I are camped out in a trailer outside BET studios in Washington, DC to support BET, CMT and MTV's "A Conversation with Barack Obama," which airs at 4pm Eastern Time today. It's the usual madcap Keystone Cops situation that seems to be an inevitable part of live television production with wires and cables dangling every which way, and I sure hope the rain dies down by the time the event starts, if only so that we can hear each other over the incessant pounding on the roof of the trailer.
The visualization is online here, and builds on work that was previously battle-tested at the 2010 Video Music Awards. The idea is that you post messages to twitter with the #ask hashtag, followed by the issue you're interested in asking the President about. If it's a good one, he may answer it on the air. There's a list of the tags we're actively monitoring at this point on MTV's site, and we're actively monitoring the hashtags and plan to change and adjust the piece right up until show time. It is a live visualization, after all. This is our fifth live event collaboration with the good people at Twitter and MTV, and Eddy, the product we designed to support this kind of live twitter/television interaction, continues to evolve as we learn more and more about how the internet and live events can support one another.
There are lots of strong-looking men in suits walking around now with serious expressions and earplugs tucked into their collars, so it seems like this show is about to hit the road. More after the event. If you've got something you'd like to ask the President, twitter's here for you.
We've—finally!—collaborated with the fabulous Jen Bekman's 20x200 on a print edition of a Stamen project, Prettymaps. 20x200 makes it possible for people to buy art at whatever level they're comfortable, from $20 to $200, and the project has put art into the hands of lots of people who wouldn't otherwise afford it, so good on them. Jen's written up a pretty comprehensive blog post about the project, which I've shamelessly copied and pasted below.
I don't have much else to add to what Jen's written (she's good) other than to say that any profits we receive on the project will be donated to the Humanitarian Open Street Map Team (Aaron's idea), in recognition of the incredible work that team does to increase citizen access to data under sometimes difficult and dangerous conditions. Oh, and also to mention that Aaron signed his name 2127 times during the making of the project, and is on a well-deserved break as a result.
Greetings from the West, collector friends! I write to you from my second city of San Francisco, which is fitting, considering it's both the subject of today's edition and the happy home of its makers. As long-time subscribers know, I spend a lot of time in the Bay Area and like it that way. Living here in the 90s was formative and it's a place that continues to inspire the tech-centric entrepreneurial side of my Jekyl & Hyde / art & tech existence. Its community of creative technologists is dismantling the wall that exists between the two, as exemplified by today's edition, prettymaps (sfba) by Aaron Straup Cope, produced in association with Stamen, an innovative studio founded by my long-time friend (and high school classmate!) Eric Rodenbeck.
We live in a time of big (huge!) data; Stamen was among the first to recognize that all this data can be beautiful and has made a name for itself by creating stunning, often interactive, visualizations of complex datasets. Their vision was endorsed by MoMA, when Paola Antonelli included Cabspotting in their history-making Design and the Elastic Mind exhibition. As Stamen was making a name for itself in the art and tech worlds, Aaron was making some ground-breaking of his own in the engineering group at Flickr, doing amazing things with photographs and mapping data. prettymaps is the product of the convergence of not just data, but talent and what a beautiful result! With beauty comes understanding—by making data beautiful, a path is cleared into an overwhelming and often intimidating barrage of information.
This edition is particularly exciting to me because it's a MAP and maps are something that we're really nuts about.* What exactly are prettymaps made of? They're made of you! When you visit prettymaps.stamen.com, what you're seeing is an amalgamation of community-generated data. It draws from things like Flickr Shapefiles, which are Flickr's geo-tagged photos plotted out (there are lots and lots, like, tens of millions) and road, highway and path data collected by Open Street Map.
Today's SF map is the first in a series from Aaron. You can count on seeing prints documenting our favorite cities released in the coming weeks, and that's just the start of it! Our editions past also evidence our affections for making sense, and sometimes nonsense, of information: Stefanie Posavec's dismantling of Walter Benjamin, Chad Hagen's Nonsensical Infographics and even Wendy MacNaughton's attempt to turn emotions into parse-able pieces. We're information junkies when it comes down to it, and our aesthetic addiction is well-evidenced in the editions we're queuing up for the balance of the year.
*We've been drooling over The Map as Art at 20x200 HQ. The book features the work of more than a couple artists we're crazy about, including a not-to-be-named (yet!) legendary artist/designer we're working with to bring editions to you.
By Jen Bekman
It's time to start talking in public about the major revision to Bing Maps that Stamen designed for Microsoft.
It's not every day you get asked to re-imagine the state of online mapping for a company that has the resources to actually take a shot at it, and in looking back over the project archive in preparation for this post, I'm basically overwhelmed by the size of the undertaking that Blaise Aguera y Arcas and his group asked us to participate in. It's too big, and has become impossible for me to sum it up in any kind of cogent way—so I'm going to start by posting a few sample artifacts from along the way and see if that opens any floodgates.
Luckily, Justin O'Beirne has done an extremely detailed and comprehensive review of the design, right down to examining the similarities to old Rand McNally maps and hard-core analysis of micropolitan area placement. Another reason why it's been so difficult to get this post out the door is because Justin's done such an incredible job looking at all of the moving parts. But more on that later.
We designed a tileset for the maps that was intended to just...calm things down a bit. One of the things that it gets hard not to notice after a while is that 99% of the map tiles out there are hyper-colorful, with bright popping hues for freeways and on-ramps and all the rest of it. While this arguably makes for a clear map when you're trying to drive somewhere, it makes designing a map of things on the map a bit of a challenge, since the map itself is competing visually for attention. So the first thing to do was to come up with a way of thinking about the map as a place to put things on, not a map that already had everything on it. We called it "mylar" because it minds me of how old architectural drawings look when you draw on the matte side of a sheet of plastic mylar paper: muted, subtle, and leaving lots of room for a foregrounding effect above it. There are a few examples below, and a more complete set of them here.
There's no type in this set, except at the street level. The idea is that these are for use when the type is part of the presentation layer, as it is in this demo that we put together using this tileset underneath the California Stimulus Map that we did last year:
And here's how it looks in the context of Crimespotting:
It's about taking a deep breath, calming things down a bit, being considerate about the typography, and giving the map the room to serve as a canvas for things to play out on top of it.
One of the major themes to think about in was the migration of alot of the content out of the tiles themselves and into an interactive framework. The idea was that you could, for example, click on a city and be zoomed in to it, something that I think the delivered project does pretty well. In order to make this happen we had to think alot about the relative sizing of type and roads at various zoom levels—and to rethink the whole notion of there being discreet zoom levels at all. We wound up with lots of diagrams like this to illustrate things like the drop off rates of the sizes of the different road types as you move in and out of the map:
We had the chance to really think about how much information you might want to see on the map at any time. Justin has detailed thoughts on ideal densities for cities, and I think there's alot that we and Microsoft can do moving forward to improve the specific densities of areas like the Interstate 44 corridor in Missouri. The exciting part, for me, was to be able to think about the kinds of opportunities that open up if those kinds of decisions become dynamic. Like, what if there are always 50 labels on the map, regardless of what zoom level you're at? What if there's only one?
To this end we put together some demos that let you play with these numbers a bit. Be gentle on these if you would, they're pretty much raw files straight out of a client work process without alot of thought given to the niceties of interface and user experience. But the thing to try is to to adjust the number of labels and the scale factor, and see if you can find an arrangement you like. Pretty soon I wind up with maps that look like this:
Which I think is just lovely. Another fun thing to do is to set the max # of labels to 1 and drag around. You wind up with a map that only shows the largest city in the viewing area, which is a nice way of thinking about a place: what's most important here?
There's alot more to say. I haven't touched on breadcrumbs, or clicking on cities, or dynamic labeling. Next time. In any event: Bing maps!
This is my first post on our new Citytracking project, which is being supported by a grant from the Knight News Challenge. We've been working on it for a good part of August.Thus far it's been primarily talk and thinking and writing, working on the overall structure of the project, trying to get a handle on what a two year project intended to change the way people talk about cities feels like. I think that it's OK talk about the very early stages without having much other than thinking to show—my friend Teru Kuwayama (more him later), who also won a grant, is writing about getting ready to go to Afghanistan, and while there's certainly no comparison between Citytracking and what he's getting himself into, I feel good knowing that other grantees are talking about their projects in the very early stages of them.
I should also say that it's important to note that it's really the whole Stamen team that won the award, and not just me: while the award announcement lists "Eric Rodenbeck, Stamen Design" as the winner, I'm mainly there to represent the group whose collaborative work has made the grant possible.
In any event, Stamen projects tend to be somewhat more bounded than this, both in time and ambition, having to do with a specific and bounded dataset or problem domain. Perhaps more importantly, for projects of this scale, there's almost always a specific client. This time our client is us—and we can be pretty demanding :)
So one thing that's happening is that Geraldine's starting to think about logos:
And the studio's been meeting regularly to talk over some options, plan this fall's conference, and so on:
There's quite a bit we don't know. What we do know is that Citytracking is intended to be a public, open source project that takes data about cities and makes it more legible—more beautiful, interesting and accessible. We know that we're intending this project for three audiences: cities, journalists and the public (including businesses). And we know we want to make the project 1) so simple that regular citizens can get involved, 2) robust enough that real analysis can happen, and 3) interesting enough that children will play with it. Along the way we're planning to release server-side codebases, mapping algorithms, managed datasets, APIs and API specs, and new views on data. And finally we want to do this work in public, in close dialogue with our audiences, so that we know we're not going down rabbit holes and doing work that's not valuable.
It's this last bit, the public bit, that helps turn the problem into something that can be tackled and keeps it from becoming overwhelming. The question is not: What do we do for the next two years? but rather: What do we do next? The important thing is to do it in public, and listen to what people have to say. One important thing that has come out in our meetings about it is the idea that this project is not "the map that ate the world"—the end all be all project that is going to satisfy the need of every non-profit that wants to map their spending over time. The project is: Here's some work, grab the code, the license is cool, don't worry about it, use it, go ahead and publish your stuff. So in that vein we're hoping to be as transparent as possible—and there's the little matter of the grant requirement that we blog about it every couple of weeks to keep me motivated.
Our ideas so far have fallen into four categories, written in outline on the whiteboard sketch from our latest planning meeting above: Walking Papers v2, Crimespotting v2, Tile Farm, and Dotspotting.
This one seems like a natural for the grant; the notion here is that we take what's already been done on the Crimespotting project, both from an interface and a technical perspective, abstract out the feature set, and make it open source. Basically:
This is one of the themes that we keep coming back to—all these pieces are out there, the stack is getting cleaner and the technology is great and there are plenty of ways to do this work, but it could be made much more straightforward and accessible to the people who want to tell stories about cities. It needs experts to do it now; the project is to make it easier for cities and journalists and the public.
If the point is to make tools that let people tell stories, and do it in a way that's free and open source and lovely, then maybe let's start at the beginning. Let's start from scratch, in a 'clean room' environment with this stuff. We could start from a baseline that's really straightforward, tackling the part that's about getting dots on maps, without legacy code or any baggage. Just that, to start. Dots on maps.Our experience with different city agencies so far is making me realize that if this stuff is really going to work out in the long run, it's going to need to be able to consume stuff that cities actually use and use now, and not have to rely on fancy APIs. It's great that San Francisco and New York are releasing structured XML data, but Oakland is still uploading Excel spreadsheets (it's actually awesome that they do), and the Tenderloin police station is printing out paper maps and hand-placing colored stickers on them. At some point, if this really is the way things are going, we're going to need to meet the needs of actual functioning city agencies—and while APIs are great and necessary, for now that means Excel spreadsheets and Word docs. It also means being able to easily read in data that people have uploaded to google maps, interface with SMS systems like those that Ushahidi are pioneering.
There's baseline work to be done here to make this stuff internet-native. Every dot should have an HTML page of its own, for example, like they do on Crimespotting. You should be able to easily download the location of the dot, download the maps, download collections of dots. Maybe there's an 'export to PowerPoint' function, since that seems to be the lingua franca of most city departments. There should be a hosted version as well as one where you can download the software and install it yourself.
Shawn keeps asking: Where is the tool that lets you hoover up a city's shape files and look at them? Mostly they're sitting in folders, accessible via pulldowns and long lists. Especially as a developer, you want to be able to do quick visual comparisons and not have to download a bunch of .zip files just to get to work. The project is all about taking the stuff that people sort of can do, with lots of effort and fancy tools, and make it so regular people can engage in this work.
Currently, Dotspotting is looking ilke the best candidate. What I like most about it is that it's something that could genuinely open up some of this work to people who don't already know how to use these tools. It's a little risky—I'm nervous about getting bogged down in the technical details of extracting lat & long positions from Word files—but the Knight Challenge feels to me like it's at least partially about trying things that are new and risky. In my next post I'll talk more about the design & coding with that we're starting on now.
We've been working with Stamen to provide visual analysis of the huge datasets that we're working with, and how people can communicate this data in sophisticated ways. A first step toward that goal is the release of a free and open-source set of tools and map engines allowing people to perform relatively sophisticated operations on their data in the browser. The project has been online for a while at http://github.com/simplegeo/polymaps, and you can download the source code there; what's new is the addition of a series of example maps so you can demonstrate what's going on, and human-readable documentation so you can use them for your own projects. Some of the examples are straightforward, letting you do things like group points into clusters and drop scaled gradients on to map locations. Others are more robust, letting you do things like change which direction is north by rotating the map and visualize the quality of street surfaces in San Francisco.
We've been lucky enough to work with Mike Bostock on these this summer, and he's really outdone himself. If I had doubts about the ability of non-flash browser-native tech like Canvas and SVG to do expressive and richly interactive mapping (and I did), consider me a convert.
Now about that easter egg...
Close readers of Aaron's blog and flickr stream know that he's been thinking for some time about making maps out of things that people do, whether it's geotagging photos or tracing streets or deriving urban areas from analysis of satellite photos, and posting his experiments with them as he goes. I'm zazzed (thanks AG) to announce that he's racheted up of this effort into a combination of —wait for it—four different datesets into a cracklingly lovely pastiche, available for your perusal at http://prettymaps.stamen.com.
The thing to watch here—besides the lovely, and also that this experiment is likely to make your browser cry for a while until we work out the kinks—is that, at certain zoom levels and in certain places, the things on the map are addressable on rollover. Which is to say: they're not pre-rendered graphics that are cooked down into tiles for easy delivery, but actual shapes, actual streets, actual areas that can be individually targeted and messed with. So when it says "Columbus Circle" in the map above, and "Embarcadero" in the map below, that's because things called Columbus Circle and Embarcadero both are actually on the map, and not pictures of them, if you get my meaning.
Everything you see in the image above - every dot, every shape, every blue road, all of it—is its own special snowflake, with its own unique properties, right in the browser—and we're only just beginning to understand what that might mean.
More on this as we go—and hopefully the servers will stay up overnight, but in the meantime, enjoy!
Did you know that the Cabspotting project we designed with Scott Snibbe for the Exploratorium, is still going strong, providing a live view into the minute-by-minute realtime positions and status of the Yellow Cab taxi service in San Francisco? And that the project has an API that you can use to access this data in close to real time, provided you agree to keep us in the loop & not use it for commercial purposes and not to put too much strain on the server?
Eric Fischer, whose Locals and Tourists photoset on flickr tore up the charts a few weeks ago, has been taking similar techniques (red is for photos taken by tourists, blue is for locals) and applied them to taxi pickups and dropoffs in SF. The Cabspotting set on flickr has more examples, including origins vs destinations and more. In the image above you can see a clear concentration of red (empty cabs) in the lower right where the depot is, and a hotly contested downtown where an archipelago of red empties nestles in a sea of blue fulls.
And Alex Bayen sent us a white paper called "Estimating arterial traffic conditions using sparse probe data," (link is down at the moment but you can get to it here in the meantime) which was presented at the 13th International IEEE Conference on Intelligent Transportation Systems, is about the extraction of overall traffic flows in cities from smallish amounts of data, and has images like this:
Which I understand about half of, but all of which I like.
The Cabspotting site has contact info if you'd like to get in touch about using this data for your own projects.
One of these days I'll get around to updating the maps section of our site, 'cause things've changed since the California Stimulus Map (although I still think the Robert Louis Stevenson quote is pretty good, it's basically 1/2 of our whole business plan). In the meantime I wanted to share a few things that Mike Bostock, who's taken a break from his studies at Stanford and contributing to the beautiful Protovis project (check out these examples) to work with us at Stamen on some browser-based mapping projects. We'll be releasing these in a more formal way in the next week or so, as part of our ongoing work with SimpleGeo, but I was enamored enough of these examples to want to post them ahead of time.
The first lets you manage tiles that are rotated off of the north-is-up tyranny—I say again tyranny—that most browser-based map engines lock you into, by making it possible to manage gridded tiles that are rotated at arbitrary angles. If the red rectangle below is the outlines of the browser, this demonstrates the engine's ability to keep the tiles in order no matter what angle the tiles are at. Pressing 'a' and 'd' will rotate things slideways, should you choose to:
What this gets us is the ability to arbitrarily change the rotation of maps that we're working with, independent of zoom level, so we can start to do things like easily look at the more eastern stretches of the Bay Area in a horizontal format, start to get views on the relationships between cities and towns and oceans and things that north-is-up leave behind on the table. And it can zoom, baby, take you all the way into Discovery Bay and back out again if that's your thing (click & drag around to see this in action):
And while you're setting longstanding map conventions on their ear (the madness! dogs and cats living together!), you might as well take things one step further and change the zoom level on the tiles you're requesting, so that a perfectly normal-looking and well-behaved slippy map, much like what you'd see here:
is suddenly loading twice as many map tiles, at twice the resolution, and displaying them at half the size that they're normally shown at:
To which you might say: so what, map nerd? On the second one, I can't read the text.
To which I'd probably say yes, ok, not-map nerd, but—which one gives you a better overview of the parks system in the Bay Area, the green stuff? Particularly around Half Moon Bay & the south Bay, there's detail in the second view that's simply not available in the first. And yes, you could maybe get to this view more directly, by firing up your desktop GIS system and running a query on the statistically relevant open space bounding boxes between a certain lat & long position south of San Francisco. But from where I sit that looks an awful lot like knowing the kind of answer you want to get, from the kind of question you already know how to ask. Somebody—in this case Stamen, since we designed this tileset, decided that you needed to be able to see green stuff at zoom level [n] and not at [n-1]. Did they (ok, we) make the right decision? How would you know?
The exciting part, for me, about this work is that it let's these kinds of questions emerge in a way that's opportunistic and dynamic and lets the medium speak for itself in a voice that comes directly from the actual material. All kinds of decisions are made in the crafting of a mapping tileset about what cities to show at what zoom levels, what kinds of features to display and how, where borders are between countries, and so on.
The idea that these kinds of decisions, and the ramifications that might fall out from these decisions, is in our hands, up for dispute and dialogue, available for messy debate and talk pages and inadvertant discovery...well that's the whole point, isn't it?
This is the kind of work that makes me want to code again, to fill directories with numbered iterations on the same idea, make the kind of thing that friends who code would step through and think "I wonder whether you could...oh right!" We'll see.