We Are a Go

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 prototype¹. 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 Fonts² 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.