The Physical Web specifies a concept of how places and objects can broadcast information or add functionality to themselves using so called Eddystones, which broadcast URLs via the Bluetooth Low Energy beacon profile. These URLs can point to information or web apps tied to this object in a browser or to deep link into installed apps on iOS and Android. This allows developers to make phones react to real world context without having a dedicated app installed on the user’s phone, like it is the case with iBeacons.
(HINT: If you do not want to go too far into detail and just want to know how you can use that right now, scroll down to “The easiest way of implementing this“)
To make this work the user needs to have the latest version of Google Chrome installed, the phone must be capable of the Bluetooth Low Energy beacon profile (iOS 7+, Android 4.3+) and the user must have Bluetooth as well as location services activated.
Today it is pretty likely that a lot of users already meet these perquisites since location services are needed by a lot of apps and Activity Trackers or Smartwatches also requiere the Bluetooth Low Energy beacon profile.
To make your web app work with the physical web standards it needs to be HTTPS and your URLs must be at most 17 bytes long. This 17 byte limit has some exceptions. “https://” as well as for example “.com” counts only as one byte, meaning “https://m.xamoom.com/abc123” is exactly 17 bytes long.
- https:// => 1
- m.xamoom => 8
- .com => 1
- /abc123 => 7
Of course there is one last thing that you need: the web app itself. You’ll need to have a web app incl. a CMS which can deliver location based content or functions, based on location idenfiers. (Hint: That’s was xamoom does for you!)
Indexing and other challenges
If your web app meets these perquisites, there is still a not too small challenge for your web app to overcome: Google needs to index that. To be more precise, a bot called “Google-PhysicalWeb” will do the job. This thing is looking for the following meta information in your web app.
<head> <meta charset="UTF-8"> <meta name="description" content="YOUR CONTENT DESCRIPTION"> <link rel="shortcut icon" href="YOUR FAV ICON"> <title>YOUR CONTENT TITLE</title> </head>
If you have very static content in your web app this seems to be a very easy thing to do, but as soon as your web app loads information dynamically it gets tricky, because this information must be there in the moment the bot looks at the content. To test what the Google bot would extract from your web app you can use this online test: https://beaufortfrancois.github.io/sandbox/physical-web/url-validator/
The bot will use this information to generate a notification on the user’s phone, like the one you see in the header of this article, as soon as the users phone gets in reach of the Eddystone.
The next problem is indexing of your location based content. Google and other bots will crawl your we bapp and index everything, so it can be found in their search engines. Very often you do not want that, because you want this content or function, since it is bound to an object or location, only to be found via the Eddystone (so when the user is really there) and not by anybody on the web. The other reason why you might not want that is, that you might have the same content on your “normal” website and if Google finds the same content twice on the internet this results in a lower search rank. Now you might say that you simply lock away all bots using your robots.txt, but this won’t help you since the “Google-PhysicalWeb” would also skip indexing your web app and therefor never show your Eddystones on any phone. Finding a solution for this dilemma will challenge your web developers a lot.
We already talked about the notification Chrome will show on your phone. Here it is important to say that they are silent and low-priority. Meaning that you will see them on Android only if you swipe down your notifications and on iOS you will need to add Chrome to your notification center. This has a good reason, because if a lot of people deploy Eddystones and each and every Eddystone would cause your phone to ring, it would drive users crazy. The silent low-priority notification gives the power of deciding when he wants to be informed or interact back to the user, which – from a UX perspective – is a very good way of handling that.
The easiest way of implementing this
Now that you know which challenges await you, we want to tell you the good news: xamoom handles nearly all of that for you. If you use xamoom as your location CMS, everything you must do is request a custom web client (build for your Domain) from us, upload it to your (https://) domain and write URLs, which are already prepared for you in the xamoom backend, to your Eddystones. So, don’t reinvent the wheel, we can handle that for you.
If you want to know more about use case and some of the pros and cons of Eddystones to take a look at this article.