Aside — what are beacons?

The term beacon is a little vague and seems to cause a lot of confusion so it’s worth a quick introduction.

Apple introduced iBeacons during WWDC 2013 and most people tend to think of them as a physical device. But iBeacon is really just a term trademarked by Apple for any device that adheres to a broadcast specification that Apple created that transmits three numbers over low energy bluetooth¹: an ID that’s unique for each device (UUID) and two numbers (‘Major’ and ‘Minor’) that can be anything you want although Apple does have recommendations around sensible ways these numbers should be used.

The most important thing to understand about beacons is that alone they’re not much use at all. Because all a beacon does is broadcast some information about itself, a system involving beacons also requires one or more observers that are listening for beacons and reacting accordingly based on the information that a beacon is broadcasting. Typically this involves the observer querying an API with the UUID, major and minor which can then return information or trigger some action.

Often the observer will be a smartphone, but as we’ll soon see there are other models as well.

The signal strength of a detected beacon can then be used to estimate how far away any beacon is. The stronger the signal, the closer the beacon. Apple has provided a nice wrapper around this in their development SDK meaning that developers have a consistent way of estimating the distance.

Low energy bluetooth can be detected from quite a surprising distance², but it’s important to understand that the signal that BLE broadcasts on is absorbed by water, and since people are 70% water that a crowded environment will impact the signal strength, and also the distance estimate³.

Also, while an observer can estimate how far away a beacon is, it’s not directional so there’s no way of telling if a beacon is ahead of you or behind, just if it’s ‘near’ or ‘far’⁴.

For something to be called an iBeacon it has to follow that specification. Other companies like Estimote are extending that specification so that their beacons also broadcast additional information like temperature and detection of motion.

So beacons can be a specific physical device, but any device that can transmit low energy bluetooth can also be a beacon (or iBeacon) as long as it follows that protocol. You laptop, smartphone and Apple TV can all act as an iBeacon.

A framework for thinking about beacons

The typical beacon system works like this: You download an app to your smartphone (e.g. the Apple Store app) when you enter a store associated with the app (as long as you have Bluetooth enabled!) you’re welcomed with a nice message.

As you browse around the store the app automatically updates with information about the products that are nearby.

Then, if you’re lucky perhaps a notification will pop up offering you a discount on a nearby product.

This is a great use case to introduce the potential of beacons, but for me has already become cliche.

To move beyond this example and explore a wider range of possibilities I’ve created a framework of specific roles for objects involved in a beacon system.

Roles

The framework defines specific language for some common roles that beacons can play in some experience.

In a workshop setting this framework is a useful tool to bootstrap everyone’s knowledge of beacon beacons can do, structure thinking, and also clarify communication⁵.

Roles in a beacon system are split between broadcasters and observers.

Broadcasters send a unique identifier to identify itself and possibly other information.

Observers listen, measure and react to the presence of nearby broadcasters.

Anchor

Anchors are beacons associated with a fixed position⁶. Most of the time this also means a stationary position (like the entrance of a store, or a area within a building) but I like to extend it to mean a fixed relative position (e.g. when you’re in a taxi it may be moving, but it’s not moving relative to your position).

For my definition, anchors are broadcast only.

Tag

Tags are beacons associated with a specific object that’s small enough to be picked up and moved around. For example tags might be attached to specific items in a store⁷.

Like anchors, tags are broadcast only.

Pass

A pass is a beacon that’s intended to be worn by someone perhaps as a distinct object like a broach, lanyard or wristband, or maybe integrated with an existing piece of clothing or jewelry.

The expectation of this role is that a pass is always worn by a specific person and works as an identifier for that individual⁸.

A lot of the time the function of a pass could be emulated with a device like a smartphone. But a pass some some benefits such as low cost, long battery life, and not reliant on having people install an app.

Tokem

A tokem is bit esoteric and will make a lot more sense when it’s explained in a scenario.

Instead of associating a physical place, object, or person a tokem simply exists as a physical representation of something in digital space⁹.

Device

I use device as a shorthand notation for any personal portable device (like your smartphone, tablet or watch) with the hardware to support low energy bluetooth.

Devices will often be used as the observer in a beacon system, but there is nothing preventing devices from also acting in a broadcasting mode.

To date, for a device to participate in a beacon system, it will need to have an specific app installed.

Display

A display is intended to be though of as a fixed digital display that acts as an observer of nearby beacons.

Hub

A hub is an observer of beacons that’s not meant to be seen or interacted directly with and just sits unobtrusively in the background.

Target

A target is an observer that’s the opposite of a hub. Instead of being hidden away, they have a very tangible presence that acts as a some affordance to invite interaction with it.

Example Scenarios

By themselves, these roles are pretty academic. If you’re running a workshop with a group of people that aren’t familiar with these beacons then these roles are probably not going to be very useful.

Instead, introduce the roles with a few example scenarios of how they can mixed and matched. Remember that a beacon system requires at least one type of broadcaster role, and one type of observer.

Contextual information

Model: Anchor(s) broadcast to device

One example of this system is the cliche example I explained earlier. Anchors are placed at strategic positions (store entrance, store departments) and people who have the right app installed on their device receive notifications or updates as they enter and browse through the store.

Another classic example of this system is in a gallery where anchors are placed next to key exhibits and the device can then display additional information (or trigger an audio guide) about the artwork as people browse the space.

An anchor attached to a poster advertising a movie, book or music could suggest a download or some associated digital content.

Smart defaults

Model: Anchor(s) broadcast to device

In our studio we have a ‘West Wing’, an ‘East Wing’ and use Sonos to play music in these different areas. With anchors set up in each wing a device could automatically understand which area it’s in and we could control volume, lighting and temperature without manually picking which area we’re currently in.

A cafe or bar with anchors attached to each table could allow people to use their device to order and pay for drinks and send the order to staff with information about which table they’re sitting at.

An anchor attached to a taxi could provide the device a quick way to rate the doctor, or an anchor on a bus could help a device understand what route they’re currently on (and so then give information about upcoming stops).

Trigger an action

Model: Anchor(s) broadcast to your device

Instead of requiring people to interact with device remember that the device could also perform actions automatically triggered by the presence of an anchor beacon. For example an app could automatically check in when you’re near an anchor.

One company is using this system in the work environment so that meeting rooms are automatically booked when you enter one that’s unbooked.

An auxiliary display

Model: Device broadcasts to a display

Instead of your device acting as an observer it can also broadcast itself as a beacon.

To see how this is useful image the arrivals and departures board at the airport. Instead of displaying details for all flights, it could detect the proximity of your device and not only highlight details of your flight, but also give extra details like distance to the gate, and send a warning to gate staff if you’re running late.

This scenario could also apply at a conference, at work, or in retail (remember those creepy billboards in Minority Report).

Measuring product engagement

Model: Tag(s) broadcast to a hub

This is another great scenario suggested by Estimote. Tags can be attached to key products on display. If the tags have the capacity to detect motion (like the Estimote Stickers) then the hub can measure which products moved the most (or in other words which products people picked up and inspected). Store staff can then use this information to make sure that the most popular items are given window space to entice people to visit.

This is interesting in that it’s the first system we’ve discussed so far that doesn’t rely on people downloading and installing some app to their device.

Smart table

Model: Tag(s) broadcast to a display

Another example that does’t reply on people having a device is a display mounted as an interactive table. When products with a tag are placed on the display, more information about the product can be shown.

Room key

Model: Device broadcasts to a target

A hotel room could have door integrated with a ‘target’ that observes for devices broadcasting as a specific beacon. This could allow your room door to unlock without even taking your device from your pocket⁸.

Event wallet

Model: Pass broadcasts to a target

In a festival you might not want to worry about carrying your wallet with you the entire time, or reply on your smartphone having power. Instead you could keep a pass on you that easily identifies you to festival staff when you’re buying food, drinks or accessing a VIP area⁸.

Keep track of important things

Model: Tag(s) broadcast to your device

Adding a tag to things that are valuable to you (like your keys or wallet) can allow your device to warn you if you leave them behind somewhere.

One company is making sunglasses with a tiny tag manufactured directly within the frame with a solar panel that keeps the tag charged.

Trigger digital actions with physical objects

Model: Tokem(s) broadcast to a target

For this system imagine some surface (the target), and multiple wooden blocks (the tokems). Each block/tokem could represent something digital (like a bunch of playlists or lighting conditions) that can be toggled on/off by stacking or removing them from the target. It might seem like a painfully cumbersome way to interact with technology, but I think it adds an interesting humanist approach to digital technology.

Start inventing!

These are just a few ideas of systems that work with beacons. In the past 6 months beacon developer packs from Estimote have already dropped from $99 for 3 ‘Esimote Beacons’ to $99 for 10 ‘Estimote Stickers’ and we can expect that the trend will continue.

There are a lot of interesting experiences that you can make with off-the-shelf beacons like these, but also consider what might be possible if you put together some more more complex by attaching a BLE device to a raspberry pi or similar.

As usual, I’d love to hear any thoughts, experiences, or ideas you have about using beacons!

Notes