To help us better understand and appreciate the opportunities and constraints of the iBeacon profile we decided to create a small prototype using iBeacons. We called it Social Jukebox, an autonomous jukebox that automatically adapts the playlist based on audience preferences. Here we briefly describe how Social Jukebox works and what we learned from the prototype.
Social Jukebox was inspired by the frustration caused by conflicting music tastes in the office. Its function was to solve this by providing a democratic service that played songs based on the collective preference of those in proximity. It achieved this by automatically checking people in as they entered pre-set zones. Once checked in, their stored song tastes (genre, album, BPM, date) would be amended to that zone, and songs matching the dominate tastes had a higher chance of being played.
This was made possible using iBeacon, a Bluetooth LE (BLE) profile created by Apple that enables a battery-efficient way of detecting proximity. In essence it works by broadcasting its identity every few seconds so that any devices listening can intercept these advertisements and, if desired, process them.
The technology is still relatively new, so we thought this project would be a perfect way to test out its capabilities and limitations. Here’s everything we learned.
If you read a lot of tech news you would presume that iBeacons offer some special intelligence or gateway to your user, but this is not the case. iBeacons broadcast their identity, which in turn offers an opportunity to act intelligently. This intelligence comes entirely from the device and the apps running on it.
When your application is active, detection of an iBeacon can take anywhere between 5-10 seconds (longer when exiting the region). When closed this can take considerably longer. The reason for the variable delay is that the discovery requires the broadcast and search to coincide with each other–affected by how frequently the iBeacon advertises itself and how often the receiver scans, and there is an obvious trade-off between responsiveness and demands on the battery.
As mentioned above, iBeacon is a profile built on top of BLE. Thus, any device supporting BLE can detect an iBeacon including Android devices with Android OS 4.4+ installed.
Previously when designing software you had a relatively linear user experience. In contrast, the essence of context-aware computing is about adapting and behaving accordingly to different scenarios–even with this simple prototype required a fair amount of code to handle the different states.
One common request from our testers was to allow some form of explicit influence over the playlist either via their phone or a central device. Even though this prototype was designed to be invisible, it’s still important to ensure you expose enough functionality to give users a sense of control.
One suggestion was to provide a way for users to filter their playlist by mood, providing the opportunity to influence the environment based on the collective mood of the audience.
What if a competitor’s app also listened out for your iBeacon’s identities? iBeacon identities are public, so if these are static then there is nothing stopping anyone from listening out for them. In some instances this is desirable, in others its not, and luckily for those instances when its not desirable technology vendors have already solved this. GimbalT offers a solution that uses rolling, dynamic identifiers, making piggy-backing more difficult.
Designing context-aware experiences is on the rise due to the ability to deliver tailored and automated digital experiences. iBeacons by themselves are not that interesting but you can add an effective environmental signal that can be used to better understand the user’s current context. It gives those of us who design and build digital experiences an opportunity to start building simple contextually aware interactions and figuring out what works and what doesn’t.