Background

For the past 13 years, we have thrown a Holiday party for our friends and clients in New York. Each year it gets bigger, stranger and more complex, as we try to out-do ourselves and amuse our entertainment-minded clients. It’s not as fun as it sounds. So, in accordance with the time- honored tradition of exponentially increasing our stress level around the Holidays, we decided to throw a technology component into that mix. (What took us so long ...?)

In September of last year (2013), we began to toss around ideas for how we might accomplish something like this. We had some general parameters:

• slightly irreverent
• engaging (and not in a "head down" playing it on the subway kind of way)
• unobtrusive
• fun! (but not completely stupid)

The Initial Plan

Ernst and Chris had been working a bit with D3.js recently for our largest client, so we thought it might be interesting to build a visualization of users’ movements in and around the party location (in this case, a bar). Since we assumed that most or all of the party-goers would have recent smartphones, we thought that maybe we could use bluetooth to sense where they were and visualize their movements on screen. Googling around, we determined that it might be possible to embed Raspberry Pi devices around the bar and passively detect users as they moved past them. We thought this might be a good idea since it didn’t require anything to be running on the user’s handset (other than bluetooth), and would work with both Android and IOS. As Chris found out, in order to do this correctly, you really have to pair with the target device (i.e. user’s phone) which would require some user involvement. It would also require an internet connection for each device so it could communicate with a server, and then there would be a lot of radio noise, possibly false positive detections, yada, yada. We decided to scrap this technique because it seemed too error-prone, had a lot of technical risk, and violated a few of our requirements.

The Revised Plan

Chris began to read a bit about Apple’s new iBeacon technology and presented an idea for how we might be able to utilize it for this application. Chris originally found out about it by reading about Estimote’s product line and thought that it would make it a lot simpler to handle the proximity use-cases, AND we didn’t have to fool around with Raspberry Pi’s. There were a few issues with this: (1) it would only run on IOS; and (2) the delivery time for the Estimotes was about 4 weeks. The clock was ticking so we decided that (1) was ok, but (2) wasn’t an option.

We began Googling ‘Raspberry Pi, iBeacon, etc’ and found that you could configure the Raspberry Pi as an iBeacon device. We collectively decided that this would be faster, and possibly more interesting to some of the geeks that would be at the party.

After a lot of internal discussion (read: ‘spirited debate’), the plan we all agreed to (tacitly or otherwise) was the following:

We would be build an iPhone app that utilized the iBeacon services of the IOS CoreLocation stack. The app would ostensibly be a ‘game’ which would have two (2) main use-cases: (1) a ‘treasure hunt’ where users would use the app to find hidden ibeacons at the party; and (2) track their proximity to the bar and increment their ‘bar score’ over time. The user who had the highest bar score or the fastest time to retrieve all of the beacons would win prizes.

A server process would track each user’s interactions with the ‘claim’ (or treasure-hunt beacons), and their proximity to the bar via network integration with the app. To enhance the experience, we would build visual displays that would render (in real-time) each player’s beacon claiming progress and their ‘bar score’ updates (which, unsurprisingly, directly correlated to how drunk they became.)

At this point, we had about 7 weeks to get it all done.

How did it turn out?

We weren't sure if we'd finish. Or if Apple would accept it. And after 2 rejections (first asking for a video demo and then asking for the iBeacon hardware), we weren't sure if it would be ready in time for the party. And even if it was ready ... would the server crash?

And the biggest worry of all ... even if it worked .... would anybody even bother playing?

Much to our surprise, it all held together ... and folks played enthusiastically. Players attempted varied strategies. Theories and speculation circulated about such things as how to make your bar score go up quicker. Guests tore apart furniture and even scanned each other in search of iBeacons (which was a good tactic, considering the final iBeacon was in Craig's pocket).

We only wish we had more time to do an Android version! Then we would have gotten a bunch more players. And a few folks hadn't the latest IOS or iPhone. Here's how it broke down:

What's Next?

This turned out pretty good. Like any good party, it gets better when shared. So we're sharing it with you. Check out our notes and the code. Add to it and make it bigger and better.