If you’re interested in self-quantification in general, The NYT Magazine recently ran a good article titled The Data-Driven Life. About a month ago I received my Fitbit, one of the devices mentioned in the article, and you can see the public data I have collected so far here. I’ve been using it primarily to get a sense of how much I actually walk and how little I actually sleep – two things about which it’s slightly too tedious to make daily notes but which still might be interesting to examine in the aggregate.
A couple weeks ago I presented Wanderli.st during Thesis Week at NYU’s Interactive Telecommunications Program. The list of all of the presentations is here, and ITP has a copy of the video hosted here, but I’ve also embedded it below. Some of the slides are difficult to read in the video, so they are embedded as well. If you’re in a hurry and think you can read faster than I was talking (hah!), the notes on which the talk was based are below each slide.
I’ve been thinking a lot the best way to continue this work now that I am free from academia, and about how Wanderli.st fits with other proposals such as Diaspora (which has gotten incredible support). I’ll continue to publish updates here, and let me know if you have any ideas you’d like to discuss!
Note: I had originally wanted to synchronize the PDF of the slides with the video, but I couldn’t find a good tool to help me with this – Omnisio has disabled the ability to create new presentations since they were acquired by Google, and the Zentation player was simply too ugly (despite their much prettier main website). Let me know if you can recommend something!
I gave this five-minute presentation at ITP on Saturday as part of the Startup Talk/Pitch Fest organized by faculty member Nancy Hechinger. Ron Conway and his partners at SV Angel, Dennis Crowley of Foursquare, Tom Cohen, and other members of the ITP community were in the audience. I got some good feedback and people were interested in the idea.
A PDF of the one-page handout I passed around is here. I’ve included the notes that I followed roughly during the presentation below the fold, since Google makes it hard to find them otherwise. The presentation can be conveniently accessed at http://bit.ly/wanderlist-20100327.
Where Do You Go provides Foursquare users with a dynamic heat map of the places they have visited on top of a standard Google Maps interface. Users can create snapshots of their maps and hotlink them as static URLs on their personal webpages, or they can use the simple WDYG wrapper pages to share their maps on Twitter. The maps will self-update automatically in the background as users continue to visit new places and checkin with Foursquare.
The idea initially came out of the difficulty I experienced in explaining to people the areas I tend to frequent in this expansive metropolis – “south of 14th Street and north of Delancey” is somewhat accurate, but really misses many of the nuances in my habits. It would have been relatively straightforward to make a static image of just my own checkins, but I wanted something that updated over time as I went to more places, and I wanted something that was also usable by other people.
WDYG was a project for the Mashups class I took last Fall, and I launched it on December 18th, just before I exhibited it at ITP’s Winter Show. Many people used the built-in “tweet this” button to share their maps with their friends, and then those friends saw those maps and wanted to create and share their own maps, and so on… this viral distribution contributed to much of the non-trivial amount of traffic the site has gotten, but I also got somedecentpress.
Below are two maps I made of my checkins in Manhattan and one from my trip last summer to Amsterdam (which was coincidentally one of the early Foursquare cities, although now you can check in anywhere), and there’s a fourth heat map embedded in the sidebar. You can click the maps to visit the shareable page that each one has. The heat maps will update in the background as I check into new places, but it will skip checkins from the past 12 hours to protect my privacy, and the coloring is sufficiently vague as to make it ambiguous which places it is to which I am actually going.
The heat maps are created using a heavily modified version of the gheat-ae Google Code project, which is a port of the gheat Google Code project, without which I wouldn’t have known where to start (although it was mostly non-functional and un-documented when I found it). There are a few interesting things I’m doing to make the heat maps consistently attractive, so I’ll dive into the technical details a little.
The checkins are plotted on the map conceptually as dots that are darkest in the center and fade out towards the edges, and they’re drawn mostly independently of each other (i.e. I’m not doing any expensive distance calculations between the venues). To draw the tiles the application adds all the geo-located dots together to get a ‘darkness’ value for each of the pixels in the 256×256 pixel tile. I wanted a smooth gradient from the center to the edge of the dots, even if there were lots checkins at the same venue. I used the OS X application Grapher to experiment with functions that might create the desired effect and minimize hard edges of the stacked dots. I went with something similar to the highlighted equation below and implemented it in the calc_point function in the tile generation code – here x is the distance from the center of the pixel and y is the how dark that point will be when mapped to a pixel.
Next I needed to specify the actual color chosen from the color schemes for each pixel in the tile. The pixels correspond to a color that is a certain height up or down one of the below color scheme images (the cyan-red color scheme isn’t generated from an image, but we won’t worry about that here). Both the range and rate-of-change of the colors affects the appearance of the maps.
As described above, I needed to map the array of ‘darkness’ values for each of the 256×256 pixels in a tile to a height up or down one of these color schemes. I wanted the ‘darkest’ point on any map to correspond to the ‘hottest’ point in the color scheme (at the top of the image), and I estimated what that maximum level should be (at which the color scheme becomes ‘over-heated’ or ‘blown out’ or ‘over-exposed’) by calculating the total number of checkins and the total number of venues currently visible on the entire map. Then I needed a way to scale each darkness value so that it would always show some color for a checkin (in case a user had only one checkin somewhere away from his/her other checkins) but would be slow to reach the maximum level (i.e. the ‘hot’ end of the color scheme). I experimented with log functions in Grapher and settled on the formula in the scale_value function in that same tile generation code – here x is the value of the pixel resulting from the stacked dots and y is the level which will be mapped to a point on the selected color scheme.
Please let me know if you are interested in explanations of other aspects of the tile generation or the code in general – I think the above tricks are particularly cool, but there’s lots of interesting stuff going on within the application that I’d love to talk about.
And last but not least, the inspiration for the name of the project (finding a good name is, of course, always the hardest part of anything) – thanks to Jorge for the suggestion!