Urban Data Challenge

Last Saturday was my first-ever hackathon — The Urban Data Challenge, sponsored by GAFFTA, swissnex, the Berkeley Center for New Media and Rebar.

I arrived at 9am and introduced myself to Casey Reas, co-founder of Processing, who was leading the hackathon and a super-nice guy. When I was working as a New Media Exhibit Developer at the Exploratorium (2012-13), Processing was the primary tool we used for building installations. Thanks Casey!

I arrived alone and expected a bunch of nerdy 20-somethings. Instead, I ran into some old friends, including Karen Marcelo, who has been generously running dorkbot for 15+ years and has an SRL email address. (coolPoints *= coolPoints)

And, I shouldn’t have been surprised, but Eric Socolofsky, whom I worked directly with at the Exploratorium was also present. He is a heavy-hitter in terms of code and data-viz and taught me how to get the Processing libs running in Java, which makes hacking much much easier.

I sat down at a table with Karen and invited Eric over. Also sitting with us were Jesse Day, a graduate student in Learning, Design and Technology at Stanford and Kristin Henry, artist and computer scientist. The 5 of us were soon to become a team — Team JEKKS…get it?

The folks from GAFFTA (Josette Melchor), swissnex and BCNM took turns presenting slides about possibilities for data canvas projects for 30 minutes. This was followed by another 30 of questions from a curious crowd of 60 people, which mean a lot to ingest.

The night before, we were given a dataset in a .csv format. I’d recommend never, ever looking at datasets just  before going to sleep. I dreamt of strings, ints and timestamps.

The data included four Market Street locations, which tracked people, cars, trucks and buses for every minute of time. There was a lot of material there. How did they track this? Answer: Air quality sensors. That’s right, small dips in various emissions and others could give us minute-by-minute extrapolations on what kind of traffic was happening at each place. This is an amazing model — though I still wonder about its accuracy.

This was a competition and as such, we would be judged on three criteria:
Audience Engagement: Would a general audience be attracted to installation? Would they stop and watch/interact?

Legibility of Data: Can people understand the data and make sense of the specifics?

Actionability: Are people spurred to action, presumably to change their mode of transport to reduce emissions?

At 10:30, we started. I don’t have any pictures of us working. They’re pretty much exactly what you’d imagine — a bunch of dorks huddled around a table with laptops.

After introducing ourselves and talking about our individual strengths, it was apparent we had a strong group of thinkers. We tossed around various ideas for about 30 minutes and then decided to do individual experiments for about an hour.

We decided to focus our data investigation on time rather than location. The 4 locations would somehow be on the same timeline for visitors to see. Kristin dove into Python and began transcoding the data sets into a more usable format. She translated them into graphics.

I played around with a hand-drawn aesthetic, tracing over a map of the downtown area by hand and drawing individual points, angling for something a little more low-tech. I also knew that Eric would devise something precise, neat and clean, so left him with the hard-viz duties.

Karen worked on her own to come up with some circular representations in Processing. As with everyone, in a hackathon, people work with the strong toolsets they already have.

Jesse was the only one of us who didn’t start coding right away. Smart man. He was also the one with the conceptual breakthrough, and began coloring bars on the vehicles themselves to represent emissions.

We huddled and decided to focus on representing the emissions as a series of colors. We settled on representing particulates, VOC (body odor), CO, CO2 and EMF (phones, electricity), not sure at the time if they were actually being tracked by the sensors.

More coding. Eric and I tapped into our collective exhibition design/art design experience and talked a compelling interaction model. The two things that people universally enjoy are to see themselves and to control timelines. Everyone liked the idea of “seeing yourself” as particulate emissions.

We all hashed out an idea of a 2-monitor installation and consulted with Casey about whether this was permissible (answer = yes). The first would be a real-time data visualization of the various stations. The other monitor would be a mirror which — get this — would do live video-tracking and map graphic of buses, cars, trucks and people onto corresponding moving bits in the background. Additionally, you could see yourself in the background.

Since it was a hackathon-style proposal, it doesn’t have to actually work. Beauty, eh?

2:30pm. 4 hours to make it happen. The rules were: laptops closed at 6:30 and then we all present as a group.

Jesse did the design work. We argued about colors: “too 70s”, “too saturated”, etc. Eric worked on the arduous task of getting the data into a legible data visualization. I worked on the animation, which involved no data translation.

I reused animation code that I’ve used in the Player Two rotoscoping project and for the Tweets in Space video installation. The next few hours were fast-n-furious and not especially “fun”. Eric was down to the wire with the data translation into graphics. At 5:30, I was busy making animated bus, car and truck exhaust farts, which made us all laugh. At 6:30 we were done.

We had two visualizations to show the crowd. Eric’s came out perfectly and was precise and legible. I was thankful that I roped him into our team. (note: video sped up by 4x).

The animation I wrote supplemented the visualization well. It was scrappy and funny we know would make people in the audience laugh.

Neither Karen and Kristin were able to make it for our presentation, so only the boys were represented in the pictures.

We were due up towards the end and so had a chance to watch the others before us. Almost everyone else had slide shows (oops!). There were so many both crazy and conventional ideas floating around. I can’t remember all of them — it’s like reading a book of short stores where you only can recall a handful.

I did notice a few things: a lot of the younger folks had a  design-approach to making the visualizations, starting with well-illustrated concept slides. A few didn’t have any code and just the slides (to their credit, I think the Processing environment wasn’t familiar to everyone). One group made a website with a top level domain (!), one worked in the Unity game engine, there were many web-based implementations, one piece which was a sound-art piece (low points for legibility, but high for artistic merit) and one had a zombie game. Some presentations were a muddled and others were clear.

We gave a solid presentation, led by Jesse, which we called “Particulate Matters” (ba-dum-bum). We started with the “hard” data visualization and ended with the animation, which got a lot of laughs. I felt solid about our work.

The judging took a while. Fortunately, they provided beer!
The results were in and we got 2nd place (woo-hoo!) out of about 14 teams. 1st place deserved it — a clean concept, which included accumulated particle emissions with Processing code showing emission-shapes dropping from the sky and accumulating on piles on the ground. The shapes matched the data. Nice work.

We got lots of chocolate as our prize. Yummy!

It turns out that Karen is the geekiest of all of us and in the days after the hackathon, improved her Processing sketch to come up with this cool-looking visualization.