iBeacon meetup in Seattle - January 2015

I attended the iBeacon / Hack Things meetup in Seattle this week. The speakers were:

Key takeaways:

​1) QR Codes were ruined forever by a poor end-user experience; iBeacon developers need to make sure they don’t repeat those mistakes. The user-opt-in approach taken by iBeacons will help prevent that but if iBeacon powered Apps simply pop up the same adverts every time you walk in a store they will suffer the same fate.

​2) iBeacons are better than QR Codes or NFC tags because the user doesn’t have to perform a physical action (tap / scan), they can just walk close by.

​3) iBeacons transmit just three key pieces of information: a UUID, a major number and a minor number. Phones use very little power waiting for beacons to come into range and can then launch apps that have registered for specific values. It’s all totally consensual: the user has to have the app, the app has to know what beacons connect to it.

Apps for beacons need to be context aware. They should offer more than simple web-site-like interactions

​4) Chris talked about examples of museums using their software with beacons to display information about exhibits. Rather than storyboarding a single museum web site or app a better approach is to create an App that understands far more about the user’s context: one view for at home planning a visit; another view as you approach showing you where to park; another as you approach the ticket desk; specific exhibit information as you walk around and when you get home a summary of all the exhibits where you lingered.

Beacons enable apps to offer right-place, right-time information to users

​5) The right-place, right-time capabilities of iBeacons are really important. For example, an airline app detecting that you are in-line for check-in to an international flight might remind you to have your passport out and ready. The benefit to the consumer is shorter lines, the airline can process people more quickly.

​6) Jason talked about testing they have done inside large stores (no names mentioned but the layout looked like a large Target store). They took a surveyors wheel, attached a hall-effect sensor and wheel it around the store collecting data. Beacons were placed on end-caps and on shelving units. Combining beacon readings with accelerometer, compass and other sensors they calculate where in the store they think you are. Overall the software does well but there are areas away from shelves where it’s harder to pinpoint where the user is standing.

a ceiling mounted solution may be preferable

​7) People and shelves block signals (Jason), beacons go missing (Chris): a ceiling mounted solution may be preferable to solve both issues, but the glue needs to be right so they don’t fall off or stick so strongly that they can never be removed. Museums apparently don’t like beacons dropping off onto priceless antiquities.

​8) Hospitals are using iBeacons, partly for consumer-facing uses but primarily for ‘back office’ applications. Some are attaching iBeacons to mobile equipment like xray machines that can be wheeled around. I imaging locating these is hard since you don’t have a sensor network everywhere to track them. I was planning on attaching some iBeacons to our cars so I could track them but using our phones as the sensors and some simple reasoning: i.e. a phone running my app is near the Audi and near the house so the Audi is at home.

​9) Sensors have limited battery life - replacing 5,000 batteries in a retail chain is problematic - you all know what it’s like to manage just a few smoke detectors - imagine that x1,000. However in 2-3 years time technology will have moved on and you are likely to be replacing them with something else so don’t worry about it. That was the advice given. I guess we have to hope that in 2-3 years time we’ll have energy harvesting beacons that don’t need battery changes, but essentially this means that whatever you install today will likely end up in the landfill in 2018.

​10) Managing large networks of beacons is itself something for which you’ll need a system.

​11) Security is an issue (Estimote has a UUID rotating scheme now to address this). Imagine a successful app for restaurant bookings and payments. A competitor could come in and use their same beacons. On the other hand, maybe beacons should be considered more of a public utility, allowing anyone to trigger their app off the beacons in a restaurant. It seems like this could go two ways: (i) competing networks of beacons such that each restaurant has a whole wall covered in them; (ii) syndicates of companies working together on sharing beacons; (iii) public utility beacons.

Overall this was a very informative meeting, lots to think about as I implement my own ideas for beacons in home automation scenarios.

Sat Jan 31 2015 07:26:39 GMT-0800 (Pacific Standard Time)

Next page: iBeacons for Home Automation

Previous page: Logging with Xamarin Insights (but not on Unified App)