He argues that there are several kinds of “code” that can shape human behavior. So, for any given problem (e.g., speeding in a residential neighborhood) there are several codes at work trying to prevent you from committing it. There’s a moral/social/ethical code (e.g., you diswant the disapproval of your neighbors who have small children), there’s legal code (e.g., if you speed you’ll get a ticket, maybe lose your license, go to jail), and there’s physical/reality code (e.g., a speed bump that physically prevents you from going too fast). The premise of the book is that there’s increasingly a new kind of code, computer code, that is stronger than laws and social norms, almost on par with reality (e.g., if your car has software that prevents it from going faster than a certain speed, perhaps tied to GPS to track what street you’re on and what the speed limit is).
The arguments range widely in their responsible citation of academic research, reliance on anecdotal evidence, and general quality. While I agree more with Shirky and Bilton than with Carr and Richtel, I don’t see that any of them have examined the issue from the perspective that I find most interesting: It should not be a question of whether or not the Internet is making us better or worse at thinking. Instead, it should be a question of whether we are better at thinking now that we have the Internet than we were without it.
We, as humans, are unique in that we modify the things in our environment into tools that extend our natural abilities. Consider, for example, our ability to run. Running is useful for both catching trains when we’re late and for escaping sabre-toothed tigers when we don’t want to be eaten. Thousands of years ago, when we were more likely to be worried about the latter situation, we had thick calluses on our feet to protect them from the uneven and unpredictable surfaces on which we might have to run. Now, we have shoes that we have engineered to serve that same purpose and to provide additional support, making us even faster than before. If we were to be caught by a tiger without our shoes then we woud not be able to run as well as our ancestors could have, since the calluses and muscles in our feet have adapted themselves to the shoes and are no longer optimized for running barefoot. But that is practically never the case – we always have our shoes, so they always augment our natural abilities, and we’re always better runners than we could otherwise be.
The Internet does for our thinking what shoes do for our running. My thought processes have developed in a world in which I am always connected to the vast resources of the Internet for both seeking information and communicating with others. The Internet exposes us constantly to additional pieces of information (in-line hyperlinks, emails, tweets, etc.), and while Carr sees these things as distractions that make it difficult to focus on the task at hand, I experience them as sources to be synthesized into the broader thought to which I am devoting my energy. The multiplicity of inputs enhances the output.
Of course not all of these ‘distractions’ are relevant to the task at hand, and we must make intelligent decisions about what it is to which we are connected at any given time. It would be silly to try to read a book while at a noisy bar with friends, and it would be foolish to blame the book if the reader found it difficult to focus in that physical environment. Similarly, it would be silly to try to read a PDF at my computer while receiving constant notifications of new tweets, and it is foolish to blame the Internet if the reader found it difficult to focus in that digital environment. When Carr cites the study in which students using Internet-connected laptops during a lecture retained less information than those who did not, he should be blaming the students for not paying attention, not the Internet for making distractions available.
There are many other specific statements made in the articles that I’d like to discuss, but I don’t have time to go through them point by point. For now, I’d like to draw attention to the illustration by Charis Tsevis in the last article linked above, in which the connected devices are plugged directly into the Internet-augmented thinker.
As we become increasingly connected to the Internet through an ever widening array of devices, our ways of thinking will adjust further to take advantage of the increased access to the Internet’s vast resources. Those that feel that the Internet is making them dumber should re-examine the ways in which they are using it. Tools must be used properly in order to be effective – running shoes work best when the laces are tied – and I feel that I’ve found ways to use the Internet that make me smarter than it was possible for me to be before.
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.
Users are given a variety of options for customizing their maps before sharing them: they can adjust their maps to make them ‘hotter’ or ‘colder’ if there is either too little or too much coloring, they can easily jump to another city, they can select from a variety of color schemes, they can adjust the size of the map image, and they can select from one of several zoom levels. A user can then create a ‘snapshot’ of his/her customized dynamic JavaScript Google maps that will have a static URL, and the user can then embed that .png elsewhere on the Internet or tweet the corresponding wrapper page (that has a conveniently auto-shortened bit.ly URL).
The Python code for the entire project is available on GitHub and the application runs on Google App Engine, a framework that abstracts away challenges related to server administration and scaling (i.e. worrying about getting and configuring more computers to run your application when you suddenly get a lot of traffic). It uses Foursquare’s API and John Wiseman’s wrapper library for it as well as the bit.ly API, the Google Maps API, jQuery, and Blueprint CSS.
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.
Google serves their maps in pre-generated 256×256 pixel tiles, and they provide functionality in their JavaScript API for the client to overlay custom tiles on top of their map tiles. To display each overlay tile I query the App Engine datastore for the venues within that tile (and just outside of it, at a distance based on the zoom level, so that I get coloring from venues that are not within the tile but still bleed into it). Checkins are stored with the venue at which they occurred, so each venue has a latitude and a longitude and a number of checkins that the user has there (if two users check in to the same place, they each get a separate copy of the venue in the datastore). A heat map tile to be displayed on top of a Google maps tile might look like this:
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!
