instagram for fun and profit

Back in December 2011, I was approached by Michael Joffe to make something happen for the early 2012 installment of his dance party art things, this one being called “Oui Paris”.

So, I stuck together some bits of ruby and javascript and made “audiogram”, an instagram feed that updates in real time, and Michael threw a dance party around it.

The folks at the Brockton Collective were awesome and created a timelapse of the whole thing:


A couple of times I had to drunkenly climb a ladder and troubleshoot it. (Here is more proof that I was there).

Michael longed for something deeply interactive that would directly engage with the crowd. I’d always wanted an excuse to play with the instagram api and the rest was covered in NOW Magazine:

In order to do so, the organizers have implemented an interactive element that they’ve deemed “the world’s first Instagram music visualizer”. With the help of developer Phillip Mendonça-Vieira, they’ve created a display wall that will project partygoer’s pictures in real time, in the ersatz nostalgic haze of the Instagram photo app. All you need to participate is a smart phone1.

“Instagram has become a huge part of sharing life experiences… and in a way it tells much more of a story than a status update,” Joffe explains. “So with this party we wanted to do an experiment wherein a tool that is used to share experiences becomes the reason for the event itself.”

The event was a success; apparently something like 400 people2 showed up on a cold January night. The whole thing ended up being one of the coolest things I’ve done to date.

Most importantly, people seem to have had a good time.

Neat. What did the app look like?

I’m glad you asked. This video will give you the general idea:


The reason I am writing about this now, in 2013, is because I never got around to making the above recording until a few months ago. I don’t understand why, or what overcame me, it really wasn’t that much work3.

Some people really took a liking to it, and the app has since been used in a conference party, a corporate holiday party, a wedding, a winter music festival series, and a sexy aids fundraising dance party4.

Cool. What did you use to make it?

I wrote a little sinatra thing that spat out new instagram photos when asked. I put down a layer of masonry and wrapped it together with jmpress.js. It works surprisingly well: new photos show up within five seconds of being posted.

The waterfall effect was achieved by prepending new instagram thumbnails in a div taller than the screen; masonry does the rest. I also remove elements a couple rows below the fold as a crude form of garbage collection. Without it, Chrome quickly starts to run out of memory.

I was reticent to accept Michael’s invitation. I wasn’t sure if I could put together something that was cool enough5 and as a result it only really came together the week before the party date. Overall, I spent about five nights poking at it and one long evening and an afternoon frantically making it work.

In the process I wrote some of the most terrible javascript ever committed to disk. I’ve since rewritten all the ruby a couple of times over, but that javascript remains inscrutable because I really don’t want to touch it. That javascript is why I haven’t linked to the github page. I’ve gotten a lot better at it since then.

What did you learn from this experience?

Telling the bouncer to let your friends skip a huge line feels pretty cool6.

I think to this day, event and location apps are underexplored. Something to facilitate documentation and increase serendipity. I think my phone could someday output significantly more whimsy into my life.

The barrier to making something neat can be surprisingly low; the important thing is to play with it and see what you can make. I’ve been terrible at following this advice.

tl;dr if someone asks you to write software for a dance party, say yes.

  1. It was the beginning of 2012; smart phones were common but not yet ubiquitous and instagram had only recently become a thing and it was cool and exciting and and no one thought it was going to be worth one billion dollars.

  2. Per the Brockton Collective’s writeup. Michael wrote about it here.

  3. Oh, and the #ouiparis photos that pop up are obviously not from the dance party. In the preceeding year and a half, other people have begun to use #ouiparis. I love this kind of stuff, unique and obscure events buried away in tags. I feel there is one great short sci fi story in me where a crucial bit of plot stems around a 14 month old foursquare checkin someone made at a house party.

  4. It was seriously overshadowed by the burlesque, the vigorous dancing, and the fact that nobody wore pants.

  5. Without any advance notice, he put my name on the facebook event and the event listings he got into the alt-weeklies, and by then it was too late for me to wuss out.

  6. Me, pointing: “Would it be cool if they came straight in?”,
    Extremely Nice Bouncer Guy: “Dude, it’s your party.”

# 22 Oct, 2013

Modern Javascript and Server-Side Rendering

I served as Director of Animated GIFs at a recent conference. Steven Sanderson made a pretty good writeup of the event.

I’m aware that this was a gauche position to take, but I originally started out with a question: Do I start learning Ember or do I start learning Backbone? Much to my surprise the answer I left with was: pick up Batman.

There are many ways to consider the different frameworks but in a nutshell: 1) data-binding feels like a superior solution to wrapping moustache {} in script tags, and more importantly, 2) Batman is clearly dedicated to conventions and patterns that I have come to love and admire.

Now, I’m not interested in ‘opinionated software’. I’m interested in getting work done. I’m interested in an application development framework that holds my hand throughout the process. I’m interested in software that makes hard decisions for me, so that I don’t have to repeatedly solve the same problems. As it turns out, I’m also a big fan of the MVC pattern as implemented by dhh et al. I think we’re on to something1.

Yet there is one major problem that almost no framework seeks to resolve, and most attempted to dodge, and that is of server-side rendering.

Problems with rich js web apps

Now, I’m not going to pretend that I’m actually concerned with graceful degradation. Lord knows I’ve sprinkled just enough jQuery into my apps that they wouldn’t work otherwise. I’m also going to conveniently ignore progressive enhancement for the moment, because I’m open to the idea that you have to occasionally burn your bridges in order to move forward.

As far as I can tell, there are two real concerns:

  1. The Google Problem
  2. The Twitter Problem

Google

Google can’t parse javascript, condemning your content/app/idea to permanent obscurity.

I’m not super concerned with this. While being able to fully parse javascript on crawl is a phenomenal technical problem, someone’s going to solve it eventually; the economics of the situation dictate it.

However, it’s still something we’ll have to deal with over the next five years, and you’re insanely irresponsible to pretend it doesn’t exist.

Twitter

The twitter problem stems in that when I am looking at a resource (for instance) it is somewhat preposterous that you have to load the application, and then issue another request for the actual data2.

It’s preposterous for two reasons.

First and for all, the resource locator I just pointed to contains all the state necessary to construct the page. The server, that ultimate guardian of persistence, already knows what information I’m trying to obtain. Resources are amongst the most important UI conventions we’ve established over the past couple of decades. The ability to share links to any application or content is incredibly powerful, and it’s not an achievement that we’re not going to abandon.

More importantly, adding a second round trip to your application load can really harm your user’s experience.

Latency is the final frontier

Whenever someone talks about the minified size of their libraries, I can’t help but roll my eyes. Bandwidth is not an issue. Anyone who has worried about shaving a few kilobytes off their libraries has wasted their time.

We all manage to watch streaming HD video on a daily basis. Economics will also solve any bandwidth gaps we may suffer. What remains after that is permanent, in that at the high end our latency time is already mostly dominated by the speed of light.

If you’re genuinely concerned about user experience, it is all about sub ~300ms loading times. We’ll get fatter pipes, but we’ll always have laggy cell phone connections. If you’re careful and intelligent about the way you send data down the pipe you don’t even need all that much javascript in order to achieve the rich experiences we seek.

Now you tell this to a lot of js people and they’ll hold up their nose and say that the answer is to build spaghetti evented apps. The one language everywhere paradigm is a nice dream but it’s not necessary (and given the limitations of Javascript, nor is it desirable).

You’re not going to actually be sharing that much code - outside of validations - between the server and the client. In fact, there’s lots of code that I specifically don’t want my clients to have access to.

So let’s continue to write apps in our preferred engineering aspects of choice. As long as an interface gets exposed it doesn’t matter.

You just have to have content on first page load.

  1. This is not to knock against any of the other vendors who gave talks that weekend. For instance, I was impressed with knockout. Steven et al achieved a very cool engineering feat when they openly set out to be interoperable with as many other libraries as possible.

    The beauty of something like Knockout - where you get to choose your preferred routing library - is also its downfall; the whole point of an application framework is that it’s some other asshole’s job to worry about maintaining all the glue between the different aspects of the framework.

    The way I see it, the biggest advances in programming productivity over the past couple of decades have revolved around making some poor asshole upstream from you worry about maintaining the platform on which you write your applications.

  2. Twitter suffered from this but they have since made it go away

# 03 Aug, 2012

A timelapse of the BBC and assorted thoughts

The cron job I set up to capture the nytimes’ frontpage was also set up to collect the BBC’s:


Catch the Chilean miners at 0:30. The Arab Spring begins in earnest around 3:00 with Tunisia (and eventually picks up Egypt). The Japanese tsunami hits around 4:30.

The video goes from September to May; I cropped it to match the music. The song is the first movement of Philip Glass’ Violin Concerto No. 1. For some reason the top red banner didn’t render properly. I have no idea why youtube didn’t render a 720p version.

Differences in reportage

There are several interesting things going on here.

The thing that stands out the most in comparison to the nytimes is how the BBC’s editors behave more placidly in their content curation. Where the nytimes crams its homepage with as much information as possible, the BBC picks the most important story of the day and runs with it.

I suspect this difference comes down to a dramatic divergence in the sheer volume of content both organizations feel the need to showcase. Where the BBC is happy to file short, factual pieces, the nytimes house style seems to force them into multi page arrangements. Where the nytimes quantifies the BBC strives for brevity.

This can be seen most clearly when you compare their coverage of the Chilean miners:


One pleasant upshot of this, however, is that the nytimes’ homepage is more dramatic. If I want to know the most important story of the day, the BBC will do me right. If I want to follow an event with bated breath I might be better served by the nytimes.

See how they covered the Egyptian revolution:


There is another great thing about the above video: you can see around 1:56 how the news cycle briefly moved on once the pace of new developments slowed down. I feel like this has nagging implications on our own perceptions of foreign events. You can see how the two sites share a large portion of photography and how quickly a subject gets dropped once it stops being news.

Woe betide protestors in Bahrain and Syria for being late to the party and living in uninteresting countries. Heaven help you once your civil war stops featuring dramatic reversals, like in Libya.

(Note: this more a limitation of our collective attention span. We just have a limited capacity for empathy. I didn’t even mention the Ivory Coast.)

Anyhow, I also produced a video comparing their coverage of the Japanese tsunami:


So, which news organization should I follow?

Frankly, the nytimes features a lot of noisy, America-centric news pieces. Just by watching the timelapses I felt vastly more informed on “what is happening out there” based on what the BBC decided to feature.

That said it’s important to keep in mind that the nytimes offers a “global edition” which was not captured by my timelapse, and that the BBC you get on TV in the UK has a more domestic bent than their global news website.

The BBC offers a very broad, yet shallow coverage. They’re great for quick summaries, but all too often they seem almost alergic to drawing conclusions. I’m infuriated by their policy of putting everything in quotes; it’s as if they’re trying to absolve themselves of any responsibility for interpretation.

The nytimes on the other hand produces awesome multimedia illustrations for the stories they cover. Their biggest problem in my humble opinion might be a reticence to embrace the medium; all of this quality work gets hidden in a side bar and becomes lost to the tides of time. They also have excellent photography editors.

Could you now espouse some bullshit on the nature of media in these tough digital times?

Certainly!

Once an iPad equivalent drops below $100 it will stop making economic sense to pulp hundreds of tonnes of trees and ship them out on a daily basis. If you don’t operate on a mandated subsidy it’s going to be difficult to justify ongoing costs in news coverage. Especially given that there’s some mounting evidence that news simply isn’t profitable.

The upshot of this is that in the meantime quality news coverage is going to contract and we’ll probably suffer somewhat on a intellectual, moral, and democratic level, etc, etc.

I’m not too concerned; our democracies emerged without the modern news distribution apparatus’ and we’re suddenly starting to see corps of semi-professional, semi-volunteers picking up the slack on a local level. The next ten years are going to be crummy on almost any vector you want to pick, but at least we’ll be experiencing the last and most complete expansion in distribution and access to information.

This is incredibly exciting. This will never happen again. Everything we do now will be taken for granted and ignored by future generations. We’ll figure things out eventually.

You're a web developer, though. Your opinion is meaningless. You are wasting all of my time. You can barely write as it is.

I, uh, hrm.

Whatever. For some miracle I've kept reading this far. Tell me about things you're actually qualified to talk about.

Okay!

First things first, I was wrong when it comes to automated archives. The nytimes does keep an archive. So does the Boston Globe. An enterprising fellow keeps a detailed archive of the BBC News. I’m a lot less pessimistic about preservation.

Andy Rutledge came out and redesigned the nytimes frontpage. It’s pretty, he has a lot of good points and I agree with him when it comes to information saturation. Some people think he’s missing out on a few important details. In the meanwhile they’ve all put forth interesting ideas that are better articulated than anything I can contribute.

This is probably best critique of the critique I’ve found to date. I’m just going to bring out what I think is the money quote:

Why not take a page out of blog design and have a running tally of your most recent major headlines? This way I can visit a news site any time of the day and see what I missed previously. Can’t you safely assume that a majority of the readers aren’t going to scan the whole front page for something that interests them, especially if you are trying your best to draw their attention with major headlines?

I can’t prove it but I’ve been saying this for years now. I think that’s probably the best move forward, but I suspect that’s going to require a paradigm shift in how we think of content management systems.

A final note

This is all I have left to say about timelapses. I’m astonished you’ve read this far. Give me a shout if you have any questions or comments.

# 02 Aug, 2011