Beacons, Physical Web and the future of context

Marcin Klimek
5 min readJun 2, 2016
Source: Brafton

Back in 2013, Apple introduced the iBeacon protocol standard supported by all iOS devices. In simple words, the operation system gained the functionality of sensing devices around. It was a silent launch. A single word on one of the WWDC keynote slides. It was enough to resonate in the tech community. Huge hype appeared around subjects related to context detection on mobile devices. This hype gave birth to few companies fascinated by this new possibilities. These companies decided to explore context awareness mechanisms and develop originally introduced technology further.

Three years have passed. Beacon technology showed that it is capable of delivering great value to customers with examples like Target Retail Network or Guggenheim museum in NY. But it’s not easy to build and manage big networks of context delivering beacons. There are a lot of things we need to figure out and improve. Referring to Ray Kurzweil’s book Singularity is Near Beacons reached 5th stage in technology life cycle:

“While providing some distinct benefits, the newer technology is found on reflection to be lacking some key element of functionality or quality.”

That’s a very natural thing. I’m more than sure we will solve all these issues very soon. Continuing on Kurzweil's tech cycles definition, 6th stage appears shortly after:

“This is usually short-lived victory of the aging technology. Shortly thereafter, another new technology typically does succeed in rendering the original technology to the stage of obsolescence.”

I clearly see iBeacon technology being taken to a whole new level. This time by Google. Last year they introduced Eddystone open protocol standard with 3 initial flavours UID, URL and TLM. This year secured version of these appeared along with very profound announcement of deep Eddystone integration in Android.

Nearby API has been on the market for a while. This year, it gains new superpower called Nearby Notifications. They allow you to inform users about context around them on the operating system level. Don’t worry. They won’t vibrate your phone all the time. You need to go to notifications view to see what’s in range. They are non-invasive notification, giving you information exactly when and where you need it.

Google Beacon Platform allows you to configure those notifications. It introduces new abstraction level for the beacons world along with tools like Beacon Dashboard. You don’t care about raw identifiers broadcasted by the beacons. You care about user-defined attachments delivering particular information. You have three possible attachment flavours to use:

  • HTTPS Web URLs where you can provide particular website useful for you device
  • App Intents with Fallback URLs allows you to show a particular Activity (view) in you app if it’s installed. Fallback link is provided when it’s not on the device.
  • Direct Installs which allows users to install application associated with the device.

Attachments can be changed dynamically by different entities. This abstraction level allows for beacon network management almost without the need for device setting changes.

The Physical Web integration is another great addition. This time provided as a Chrome extension on Android. It works on iOS too by the way. Its not surprising Google came up with this idea. It extends the Internet we know (and use google.com for it intensively) to the physics spaces. Objects broadcasting URL links (using Eddystone-URL frame format over Bluetooth LE) are picked up by Android Service, then filtered and returned as non-invasive notifications. This mechanism delivers clear value to the user. Giving easily accessible extended information for particular context. It gives poor control over experience delivered to the user but works well with simple use cases.

Two additional technologies are worth mentioning here. First one is Web Bluetooth standard, allowing web pages connect to Bluetooth LE enabled devices. No application apart the web browser is required here. Another one is Google’s Instant Apps technology where part of an app can be shown to the user without previous installation. These two solutions blur difference between web and apps and lets the Internet Of Things access devices much faster.

There is a trade-offs that must to be made with all this technology though. An Internet connection is required as Google Cloud usage is obligatory. This is a quite brave decision of Google but the only logical one. Internet access is essential for their business model. They put a lot of effort with projects like Sidewalk Labs and Project Loon to make Internet a commodity.

Progress in beacon technologies enables much better experience for the user. Let’s use Saeco’s connected coffee machine as an example. It’s complicated to use it the first time with my phone. I needed to find out about Saeco’s app first and then search the App Store or Google Play. Install and open it. Navigate to coffee selection screen, pick a coffee flavour I like and confirm my choice.

Google Superpowers simplifies process above drastically. You just need to approach the coffee machine. Tap notification that will bring you directly to the part of the app responsible for flavour selection. Make your choice and confirm. Awesome, right?

Apple has been closely looking at the beacons market for almost 3 years now. They are all about user experience and I’m sure they will progress with iBeacon soon. Looking at last year WWDC announcements they have core technologies already in place. Bitcode, On-Demand resources or extensions gave a good base for similar mechanisms Google introduced this year.

Humans mainly consume context information now. Evolution of beacon standards is very important to progress the Internet Of Things development. Machines will consume context in the future. You can easily think about the smart connected car, approaching the parking lot. Today you need to handle parking payment. In the future, it will be car’s responsibility. It has to have a way to detect parking lot and communicate with it efficiently. Simple URLs handled by packets like Eddystone-URL will evolve into fully functional APIs, like REST we use now for web services.

It’s an exciting time for beacon companies, but more exciting for users who will gain the fantastic user experiences of the physical world.

--

--

Marcin Klimek

Early adopter/evangelist of emerging technologies focused on Augmented and Virtual Reality. Actively shape the #FutureOfWork as CEO of ExplodedView.io.