Beacons Provide Modern Take on Scavenger Hunt

It was the holiday party season and we wanted to create an interesting application to show off our freshly delivered developer preview of Estimote Beacons – low power, low cost bluetooth sensors. What better than a scavenger hunt app in San Francisco to take advantage of the micro-location based nature of the beacons, while testing it out on other ThoughtWorkers?

Here’s what we learned.

The Tech

Let’s start with a look at the technology. These beacons are enabled by Bluetooth 4.0, a low power iteration of Bluetooth championed by hardware like Fitbit and smart watches. The batteries in the Estimote Beacons are purported to last two years.

Strengths of the Estimote Beacon include long battery life, it can be used indoors and outdoors, and it’s compatible with iOS and Android. On the downside, the proximity measurement isn’t very precise. It uses the registered strength of the bluetooth signal, which is finicky, as well as easily disrupted by physical objects. There’s also no directional measurement – directional functionality requires other measurements like the compass or GPS.

The lack of precision wasn’t a showstopper though. We tested RSSI (Received Signal Strength Indicator) readings for the beacons at different distances. Despite the fluctuation, our chosen RSSI threshold for finding a clue reliably corresponded to two to four feet.

We designed our app for use with iOS 7 (Estimote Beacons can also be used with Android devices, but the SDK was released a week too late for us). We built a clean interface with built in beacon interactions – the background and message on the bottom bar changed depending on proximity of the clue’s Estimote Beacon.

Check it out on github (https://github.com/shanear/beacon_finder)

We had some extra time towards the end of the week, so we added a web scoreboard element. We built it with a Ruby on Rails based API and some cool fonts.

The Event

The scavenger hunt was more than just building the app. We asked some folks around the office for their favorites spots and took five of the best ones. We scoped out the top picks throughout the week, took pictures, and assessed good spots for the beacons. When we dropped the beacons off, we found that businesses were excited about the publicity. As for the public parks, we only got a few weird looks while casually hiding them in shrubberies.

Since the app store is slow, we also needed a good way to distribute the app to teams. TestFlight was recommended to us, but is difficult to set up for non-devs without some assistance. Since the event was starting in the office, we decided to install the app on each device manually, and the process went surprisingly smoothly.

The night of the party we had six teams (each between two to four people) sign up. We could send teams out at different times because the app kept track of their total start-to-finish time for scoring.

We then headed over to the party to meet the teams as they finished up over the course of the next hour or so. One team emerged victorious, as they were the only team able to find every single location.

Four Lessons learned

1. Estimote Beacon Sensitivity Testing
   Test on location – we might have been able to figure out that some of our hiding spots were too difficult, but we didn’t have the app running when we actually placed the beacons. One person had to reach all the way over the bar at one location before the app declared that location “found.”
2. Event Planning
   We reached a little on the walking distance for the scavenger hunt to fit in all of our locations, and it might have been too much. A couple teams gave up, or aggressively skipped. Turns out people will rush through an activity that ends at an open bar. We could have thought more about that.
3. iOS Best Practices
   Being from development backgrounds of languages and frameworks with stronger communities, we were surprised by how hard it was to find good example code and best practices online for iOS development. Maybe books are the way to go?
4. Website Bug
   We knew adding an untested feature near the end of the project was risky, but we thought a web API would be fun. We figured it wouldn’t harm the actual scavenger hunt if it wasn’t perfect. There did end up being a bug. API request URLs for teams with a space in their names were incorrect, and didn’t update them correctly. The bug didn’t affect the app experience, but hampered our ability to use the web scoreboard (we did update it manually though).

Thanks to my co-authors Shane Russell and Maurício Silveira Sanches. 
Interested in reading about different uses for Beacons? Check out the best of NRF write-up.