Note: this was originally posted to the Almighty blog and is cross-posted here.
I had a brief exchange on Twitter this morning with Bit.ly Chief Scientist Hilary Mason in response to a profile piece - published yesterday in Fast Company – highlighting some of the many ways in which Bit.ly’s massive volume of data about our sharing habits could be brought to bear. The piece focuses – as is the nature of Fast Company – on benefits to brands of products like predictive algorithms that spot trending topics and conversations.
While I think there’s a lot of value in products of that nature (and as Erik points out, Bit.ly’s gotta get paid), I don’t think that they’re particularly unique to Bit.ly – Twitter and Facebook are both making moves that will corner pieces of this market for themselves. Frankly, I think that there are more interesting ways for Bit.ly to create products for the marketplace that leverage the unique nature of the data that people are creating with their tool – be it via the bit.ly website, a plugin or a 3rd party application.
Hilary, to her credit, asked what I’d like to see from Bit.ly (also to her credit is her terrific blog). Here, then, are a few thoughts:
1. Publishers are racing to customize the delivery of content to users, while struggling to build the foundations of community that will allow them to generate the kind of affinity and usage data that will inform that level of customization. Facebook affords publishers one approach to that level of customization, but bit.ly data creates an altogether different model for customization in which registered bit.ly users could be served content in which they are not only interested, but also have a propensity to share based upon past behaviors (certainly a valuable interest for all manner of publishers). As significantly, this can be delivered at scale.
2. There are plenty of good reasons to share a link, and any number of people willing to school you on the voodoo of how and when to share information. The fallacy at the core of most of this conventional wisdom is the notion that each of our networks are static (or similar). Bit.ly, though, (with enough data in hand) can tell me when the links I share to my blog posts are most-likely to find traction within my networks, and suggest the best times for sharing my new favorite pop-up Tumblr (as well as the platforms most likely to care). I’d like to see Bit.ly data used to tell me when a link has already made the rounds and I’m late to the party. As a voracious consumer and sharer of information, I’d pay for these kinds of insights – and I suspect that many of my peers would, as well.
3. Finally, I think that there’s a very real extent to which the data that Bit.ly is capturing is, itself, content. As conversations continue to migrate off of publishing platforms leaving message threads to the vehement and the loyal, the links that are being shared on social platforms comprise a valuable (if less-obvious) piece of the stories to which they are related. The trending links to archival Steve Jobs profiles and interviews were as much a part of our collective remembrance of him as his obituaries. The roll out of links to small pieces of content around the #occupyWallStreet movement are integral to understanding of the way that this has become something much larger. The ability to license this information – this data we create – to other content creators and publishers would seem an exciting, real-time opportunity for Bit.ly (and one I would think that they’ve already been pursuing).
There’s nothing terribly profound about the code I wrote last weekend (or the utility - James Darling of Berg built something very similar a week or two ago using an old Kindle): a few dozen lines of AJAX and CSS that ping the public API of NextBus and displays the waiting time for the next three buses headed from our nearest street corner to Harvard Square. There are quite a number of free and paid web and mobile apps that deliver bus schedules and arrival times. For the most part, though — and this is a point that Darling makes particularly well — those services excel at delivering at scale at the cost of a compromised delivery of the answer to the immediate question, namely: when will the next bus that I want be at my corner?
I’ve been thinking a lot lately about the fact that I spend a good deal of my time talking about apps and utilities and very little time making them. There was a time when I made a lot of things with code — rather poorly-structured things in hindsight, but tools that served a purpose, however small and shoddily-constructed. Over time, I found that I was more comfortable (and possibly more valuable) shaping and selling solutions than developing them. Which is fine — except that it’s really not. Alan Kay was famously known to invoke the truth that ‘simple things should be simple and complex things possible’. Increasingly, I find that my job is to find elegant means of describing and explaining the possibilities created by complex, interdependent tools and platforms. Often, the best tool at my disposal is not a brief or a deck, but a functioning prototype1. For me, at least: with words, I can describe an idea; with code I can articulate a system.
What I set out to prototype last weekend was something decidedly ambient- a single-use page that delivered utility in a very specific way that — and this was critical — I could live with. I was also eager to develop a tool that we could position in our home to serve a specific purpose, and summarily ignore or remove, like this:
A few hours of coding later, sitting on our dining room table, our home iPad correctly predicted the arrival of the #77 bus on the corner of our street. If I got up from the table when the display read three minutes, put on my shoes and walked to the corner, the bus showed up on cue. I know because I tried it. Three times just to be sure.
The end product was, I think, a pretty close approximation of the idea I had set out to articulate: astoundingly simple display of information that looked good on a tablet (or as good as something I might design was going to). The red screen made for a warm glow and I’d minimize my waits on cold winter commutes.
Not an app — a single-use site, really. My bus, my corner, my page — all built with Google Web Fonts2 and Google-hosted jQuery. The following morning, I decided to develop an version for use at the office — mostly excited by the prospect of marrying multiple bus lines into a single experience (both the 86 to Harvard Square and the 70 to Central Square make stops in front of our building).
The multi-route version of the prototype, displaying time remaining until the #86 and #70 buses arrive at our offices.
It felt good: two days from sketches in a notebook to an idea that is best articulated by spending some time in a room with it, rather than a written brief.
The funny thing about an articulated idea is that people tend to want to make it their own (which is a good thing). Kit wanted a version for her new commute. So did Abby. And Lucia. So now I’m toying with something that delivers on that ask without complicating things: a simple application with simple inputs that delivers on a single task in a way that requires no updating, no maintenance, no ongoing attention.
These are the home and work prototypes. They’re optimized for the iPhone and iPad, so if you’ve got the option to view them there, I’d recommend it. If you have ideas of ways in which the idea could be better articulated, I’d like to hear those, as well.