The Physical Web
The Physical Web is an open source web specification that Google released in 2014 with the goal to make it easy to interact with smart-devices in the physical world.
Basically, Google want to give every smart-device in the physical world a web address (yes, a simple URL), instead of a cryptic, unique identifier such as a UUID (reminder: Apple’s iBeacon technology uses UUIDs).
What is the big advantage of this approach? By broadcasting a URL, it is possible to go around the need for a Mobile App to interpret the meaning of the identifier.
Let me make an example:
- if your smartphone/tablet receives “11111111-2222-3333-4444-555555555555” from an iBeacon, a specific, ad-hoc App is needed to interpret it and understand where it is located, what functionalities are offered, etc.
- if it receives “http://www.cocacola-vendingmachine.com/NY-CentralStation” no particular interpretation is needed, and instead of an ad-hoc App installed on your smartphone, a Mobile web-browser will do
I’ll describe the same concept from another point of view: today Apple’s iBeacon technology doesn’t have an easy, dependable way to browse Beacons in close proximity and start interacting with them at once – you need to have the proper iBeacon-enabled App installed first.
Why? Because iBeacons broadcast just cryptic identifiers.
Use web addresses (URLs) instead of identifiers, and Beacons can be detected without specific Mobile Apps already on the smartphone looking for them.
The final goal is to be able to interact with any smart-device – for example a vending machine – without having to download and install a specific App first; downloading and installing a specific App for each specific proximity-based service in the world (offered for example by grocery-stores, railways stations, retailers, airports, etc.) is absolutely unrealistic.
Taking inspiration from the Physical Web, after a long wait (in July 2015) Google launched a full Beacon development framework that includes the open source Eddystone spec for Beacon broadcasting, together with additional tools, bells and whistles – for example Eddystone-enabled Chrome 44 for iOS.
Finally an official Google Beacon platform is available (…it was about time!).
It’s quite probable that in the future Google will Eddystone-enable also Google Now, Google Calendar, Google Maps, Google Play and so on – let’s wait and see…
Eddystone (named after the Eddy Lighthouse in the UK) officially is an open-source (currently available on GitHub under Apache v2.0 license) Bluetooth multi-platform Beacon protocol (compatible with Android, iOS and any platform that works with BLE Beacons), supporting Google services.
Eddystone includes (at the time of writing) two APIs:
- the Nearby API makes it easier for Apps to communicate with devices and Beacons in close proximity
- the Proximity Beacon API allows developers associate semantic location (e.g. latitude & longitude) and related data stored in the cloud
…more is coming, of course…
The most interesting Eddystone feature is the Eddystone-URL, that allows Beacons to broadcast a packet type that encodes a URL (instead of an identification number) and therefore can direct users to:
- your website
- download your Mobile App from Apple AppStore, Google Play, …
- a particular screen of your (already installed) Mobile App
Please note: beware, the Eddystone-URL’s length is 17 bytes, so a URL shortening service is required if your URL is longer.
See more on Google’s Physical Web Cookbook page (http://google.github.io/physical-web/cookbook/).
PS: in this Post I am sharing a preview of my new, updated “Beacon Bible 3.0” that you will be able to download from my blog-site http://www.gaia-matrix.com in mid-September.
[…just to be crystal-clear: it’s a white-paper, it’s free, I’m not selling anything…]