- The Realities of Installing iBeacon at Scale (Brooklyn Museum) — death by a thousand mundane little real-world pains.
- How We Build Software (Intercom) — rare to see descriptions of how to build product teams.
- MProgress.js — Material Design progress bars for the web.
- Eight Fallacies of Distributed Computing — your network is unreliable, slow, congested, insecure, changing, expensive, and inconsistent. And that’s on a good day.
"iBeacon" entries
Beacosystem evolution, hurdles, and resources
A look at the issues and trends in deploying beacon-based solutions.
In this post, the third of our series, I’ll look at some of the issues in using and deploying beacon-based solutions, some of the trends in both hardware and software offerings, and share some resources where you can find more detail on everything I’ve covered so far.
First off, let’s take a look at some of the topics that can cause issues, or trip us up when starting to consider a new iBeacon-based solution. In no particular order, these include:
Notifications, Notifications, Notifications
I have many conversations with potential clients that go something like this (in condensed form):
Client: “We want to do a beacon project”
Me: “Great, what are you thinking of?”
Client: “We want to trigger messages to people as they come past or in to our place on their phones”
Me: “OK, is this iOS only?”
Client: “No – of course not – in fact, most of our users are on Android”
Me: “Ah – ok… well…”
(long conversation follows)
With the initial hype and excitement around iBeacon, it’s understandable that there’s some confusion around what’s possible, and what’s not, across all the mobile handsets available today. For now, I’ll focus on just iOS and Android, though we could usefully expand to include Windows and Blackberry. Read more…
Google’s Physical Web vs Apple’s iBeacon
How proximity approaches compare and a look at the flourishing proximity startup ecosystem.
Editor’s note: This is the second post in a series looking at beacon technology and the burgeoning beacon ecosystem.
In the first of this series, I covered some of the basics behind proximity, Bluetooth Low Energy, and iBeacon, and walked through some use cases where proximity and iBeacon have started showing up in retail, travel, and other applications.
While iBeacon has arguably galvanised the notion of using proximity in applications and services, it’s not the only game in town.
In this post, I’ll cover one of the alternatives to Apple’s iBeacon, Physical Web from Google, and then I’ll zoom out to look at the flurry of activity in startups in the evolving “Beacosystem.”
First, a small recap on what helped iBeacon gain so much traction, so quickly and helped shape the landscape for a proximity ecosystem to emerge.
Creating an ecosystem
Apple’s iBeacon is a layer, or a “convention,” that builds on the Bluetooth Low Energy (BLE) Standard. Apple has spurred an ecosystem around iBeacon by doing several things, which all feed into each other:
- Baked support for iBeacon into its mobile operating system (iOS) so that APIs are readily available for developers.
- Included support for background notifications at the OS level, so that push notifications can be triggered in certain situations, but without killing your phone’s battery.
- Provided a certification program to enable hardware manufacturers to create iBeacon-compatible hardware. This allows third-party manufacturers to provide iBeacon-compatible hardware of all shapes, sizes, and form factors, At last count, there were more than 50 suppliers of iBeacon hardware.
- Enabled every iOS device to be an iBeacon. This has many potential uses, from iPad-based POS systems welcoming you to a store, to the Hailo App letting you know that you can pay by Hailo.
- Ate its own dog food, by using iBeacon with their Apple Store App in all their US based Apple Stores.
What are iBeacons?
How to get started with proximity sensors.
Editor’s note: This is the first post in a series looking at beacon technology and the burgeoning beacon ecosystem.
Apple galvanized the whole area of proximity-enabled applications and services when it launched iBeacon at WWDC in June 2013. When iOS7 launched later that year, it was the first time support for a variety of proximity use cases was both designed in — and available at scale in — a mobile platform.
Since then, hundreds of companies have become involved in different ways in the iBeacon ecosystem — what I call the “Beacosystem.” These companies are making beacon hardware, offering proximity/iBeacon software platforms, creating shopper marketing platforms, using beacons to deliver signals for location analytics and mobile marketing solutions, powering indoor location services, and more.
This post introduces proximity and iBeacon, covers some background on how it works, and explains why there is some excitement and hype around the uses of proximity in various verticals, including retail.
Four short links: 9 February 2015
iBeacon at Scale, Product Teams, Progress Bars, and Distributed Fallacies
iBeacons, privacy, and security
The technology is at risk of dying off — and that would be a shame.
iBeacons and various BLE technologies have the potential to shake up many established ways of doing business by streamlining interactions. Although there are potentially many uses for iBeacons, much of the initial discussion has focused on retail. (I’ll follow up with some examples of iBeacon applications outside retail in a future post.)
As I described in my initial post in this series, all an iBeacon does is send out advertisement packets. iBeacon transmissions let a receiver perform two tasks: uniquely identify what things they are near and estimate the distance to them. With such a simple protocol, iBeacons cannot:
- Receive anything. (Many iBeacon devices will have two-way Bluetooth interfaces so they can receive configurations, but the iBeacon specification does not require reception.)
- Report on clients they have seen. Wi-Fi based proximity systems use transmissions from mobile devices to uniquely identify visitors to a space. If you take a smartphone into an area covered by a Wi-Fi proximity system, you can be uniquely identified. Because an iBeacon is only a transmitter, it does not receive Bluetooth messages from mobile devices to uniquely identify visitors.
Application programming for iBeacons
iBeacons don't communicate directly with end users — applications are required for translation and action execution.
Once you are set up with an iBeacon, no matter whether it is a dedicated device or a program running on a host device, you are ready to start writing applications. The iBeacon “protocol” is simple, as we saw in the introductory post: it defines regions in space as “where I see a specified combination of UUID, major, and minor numbers.” There is no descriptive text or mapping transmitted in the packets sent by a beacon. Translation between the beacon’s transmissions and any actions are done entirely within an application running on the receiving device, even if the application is a simple text message to say “welcome to this place.”
For developing applications on iOS, the core documentation is the developer’s guide to region monitoring. For many years, iOS has enabled applications to use the physical location of a device in applications through the CoreLocation framework, which is what users enable in the Location Services settings in the Privacy panel. iBeacon functions were added to CoreLocation in iOS 7.0. Naturally, devices must have hardware support for the underlying Bluetooth Low Energy functions, which in practice means an iPhone 4S or later iOS device. Macs sold since late 2011 also have the required Bluetooth hardware. Read more…
iBeacon basics
Proximity is the 'Hello World' of mobility.
As any programmer knows, writing the “hello, world” program is the canonical elementary exercise in any new programming language. Getting devices to interact with the world is the foundation of the Internet of Things, and enabling devices to learn about their surroundings is the “hello world” of mobility.
On a recent trip to Washington D.C., I attended the first DC iBeacon Meetup. iBeacons are exciting. Retailers are revolutionizing shopping by applying new indoor proximity technologies and developing the physical world analog of the data that a web-based retailer like Amazon can routinely collect. A few days ago, I tweeted about an analysis of the beacon market, which noted that “[beacons] are poised to transform how retailers, event organizers, transit systems, enterprises, and educational institutions communicate with people indoors” — and could even be used in home automation systems.
I got to see the ground floor of the disruption in action at the meetup in DC, which featured presentations by a few notable local companies, including Radius Networks, the developer of the CES scavenger hunt app for iOS. When I first heard of the app, I almost bought a ticket to Las Vegas to experience the app for myself, so it was something of a cool moment to hear about the technology from the developer of an application that I’d admired from afar.
After the presentations, I had a chance to talk with David Helms of Radius. Helms was drawn to work at Radius for the same reason I was compelled to attend the iBeacon meetup. As he put it, “The first step in extending the mobile computing experience beyond the confines of that slab of glass in your pocket is when it can recognize the world around it and interact with it, and proximity is the ‘Hello’ of the Internet of Things revolution.” Read more…
Four short links: 27 February 2014
A Fine Rant, Continuous Deployment, IBeacon Spec, and LaTeX Gets a Collaborative Multiplayer Mode
- Our Comrade, The Electron (Maciej Ceglowski) — a walk through the life of the inventor of the Theremin, with a pointed rant about how we came to build the surveillance state for the state. One of the best conference talks ever, and I was in the audience for it!
- go.cd — continuous deployment and delivery automation tool from Thoughtworks, nothing to do with the Go programming language. The name is difficult to search for, so naturally we needed the added confusion of two projects sharing the name. Continuous deployment is an important part of devops (“the job of our programmers is not to write code, it is to deploy working code into production”—who said this? I’ve lost the reference already).
- Apple iBeacon Developer Programme — info locked up behind registration. Sign an NDA to get the specs, free to use the name. Interesting because iBeacon and other Bluetooth LE implementations are promising steps to building a network of things. (via Beekn)
- ShareLaTeX — massively multiplayer online LaTeX. Open sourced.
Four short links: 6 January 2014
Tiny Emulator, iBeacon iPwn, Filter Principles, and Steadicam
- 4043-byte 8086 Emulator — manages to implement most of the hardware in a 1980’s era IBM-PC using a few hundred fewer bits than the total number of transistors used to implement the original 8086 CPU. Entry in the obfuscated C contest.
- Hacking the CES Scavenger Hunt — At which point—now you have your own iBeacon hardware—you can just go ahead and set the UUID, Major and Minor numbers of your beacon to each of the CES scavenger hunt beacon identities in turn, and then bring your beacon into range of your cell phone running which should be running the CES mobile app. Once you’ve shown the app all of the beacons, you’ll have “finished” the scavenger hunt and can claim your prize. Of course doing that isn’t legal. It’s called fraud and will probably land you in serious trouble. iBeacons have great possibilities, but with great possibilities come easy hacks when they’re misused.
- Filtering: Seven Principles — JP Rangaswami laying down some basic principles on which filters should be built. 1. Filters should be built such that they are selectable by subscriber, not publisher. I think the basic is: 0: Customers should be able to run their own filters across the information you’re showing them.
- Tremor-Correcting Steadicam — brilliant use of technology. Sensors + microcontrollers + actuators = a genuinely better life. Beats figuring out better algorithms to pimp eyeballs to Brands You Love. (via BoingBoing)