Guest Post: Doug Thompson, Fidgets
Chrome 57 has launched, and with it in-browser support for the Physical Web. Now, when a user goes to conduct a search or enter a web URL, any nearby Physical Web addresses will appear just below the address bar as seen in the above graphic.
It adds another piece to the proximity puzzle – allowing your browser to show nearby URLs when you go to enter a Web URL or go to conduct a search.
Use Cases for Chrome URLs
Being able to see nearby Physical Web URLs in your browser suggests some interesting use cases/value propositions:
Closing the Gap on Physical Web Objects – in the world of the Physical Web you walk up to a “thing” and use it. In general, their use case is for that “thing” to include a Physical Web icon. You need to know that the object has a URL attached to it. This is usually accomplished through physical-world icons/signage. You then need to know to “pull down” on a notification tray to see it.
By adding Physical Web URLs to your browser search/address bar, there’s another path to making sure users will more easily be able to “see” that URL.
Show-rooming – Retailers still struggle with ‘show-rooming’ – where users will be shopping, say, for a fridge and go online to compare prices when in the store. By attaching a physical web beacon to the fridge, the retailer has a last chance to catch the user’s attention with a link of their own.
In the Home – This is, perhaps, where beacons can truly start to merge over with the connected home. Device makers (say, the Nest thermostat) can embed a Physical Web broadcast. Now, your thermostat, connected TV or other device can offer up a manual, support hotline or other information as an available link in your browser – and possibly bypass the need for a custom app.
Bluetooth in the Browser
Things start to get really interesting when you take into account the fact that Chrome also supports Bluetooth connections. By allowing Chrome to connect to nearby Bluetooth devices, you can create use cases where a Physical Web signal leads to a web URL. The web URL leads to a page with support for Bluetooth connectivity.
(We should note that Bluetooth proximity and Bluetooth connectivity are two entirely different things!)
Google does a deep dive on this capability and provides libraries for Angular, Node and Polymer.
We can envision use cases where you approach a fitness machine in a local gym, it has a Physical Web logo, a Physical Web URL shows up when you search in Chrome, and the web page it takes you to can connect to the machine and read out heart rate or other information.
Go Chrome, or Go Physical Web?
This addition to the “proximity pathway” is great. But it adds another layer to an already confusing set of instructions for consumers.
One interesting question: when you’re creating an in-location sign/symbol or marker to let consumers know there is a nearby URL, should you flag it as Physical Web, or Chrome?
I’ve been wondering whether the Chrome logo wouldn’t be a better way to go. It bridges Android and iOS, is a recognized symbol, and is WAY easier to explain.
Because when the current instructions look like THIS, wouldn’t THIS be easier to understand?
This post originally appeared on Thompson’s blog, BEEKN.