The Apps’ New Competition – Progressive Web Apps

Applications (apps) intended to be installed on Smartphones and tablets have been around for years. App Stores first appeared in 2008 and quickly became busy destinations. In 2013 Apple released a protocol known as iBeacon and various manufacturers built devices supporting the protocol in fulfilling its purpose of broadcasting a radio signal over Bluetooth Low Energy (BLE) which could be received by Smartphones and other mobile devices. (BLE, unlike previous versions of Bluetooth, has a tiny impact on battery life if turned on all day.) Apple introduced iBeacons to its retail stores and other retailers followed suit. In general terms, the purpose was to alert users of an Apple app that there was content available nearby. When thinking about iBeacons, it is helpful to remember that they are recognized by an app, to which the user gave certain permissions at the time of install. Those permissions might include the right to know your location, your name and other personal details, and this information allows the app provider to build a database about you – when and how often you visit, what you purchased, how long you were in the store, how you moved through the space and more. In return for divulging your personal identity, you are likely to receive offers, loyalty points, expanded product information and other value adds both in and away from the store.

Apple’s iBeacon versus Google’s Eddystone

Until the summer of 2015 the Apple iBeacon standard owned the road. Then Google introduced a protocol they named “Eddystone”, after a legendary British lighthouse. While Apple’s protocol is proprietary, Eddystone is open source, with several frame sets, the key one being Eddystone-URL. A beacon running the Eddystone protocol can be made to broadcast a URL, a web address that anyone suitably equipped (on both Android and iOS mobile devices) may receive, discover and choose to visit or not. And herein lies the key distinction between the two protocols. iBeacon needs a dedicated app to receive its broadcast. Eddystone’s signal can be received by the Chrome browser, the Opera browser, with others coming onboard. Dedicated apps are costly to develop, costly to persuade people to install, take up space on both the screen and in onboard storage, and only serve one master, which means the user has to be really attached to the app provider. Otherwise, the app will be ignored and likely deleted to make room for something else. Eddystone requires only the browser Android users are likely to have, and that’s more than a billion people. And the Chrome for iPhone version will receive Eddystone broadcasts too.
App-less discovery of beacon-delivered content nearby is a game changer, and Google’s recent initiative, Progressive Web Apps, takes it to a new level. Google has created a toolkit for developers that allows the creation of websites that look and function like apps, including features like an icon on the phone’s home screen and offline functionality. What they don’t require is installation or updating because at heart they are delivered to the phone from the web. Here’s an example:
washingtonPost_PWA225 washingtonpost_send2phone600
This is the splash screen of the progressive web app created for The Washington Post. You can fetch it yourself from here. As you can see from the invitation below, accessing this content requires only a link, not an app install. And once you’ve clicked on the link sent to your phone you can choose to place an icon on your home screen, providing virtually identical access as to any real app you’ve installed. The PWA delivers on the promise of near-instant load times and scrolling shows virtually no lag. The jury is still out on how much content you can access once you’ve gone offline. I got some but not all. But further to the plus side, these apps never need updating, don’t take storage space and can be created at a cost that makes the solution affordable to many prospects that might not want to take on the cost of a custom app and the effort to get it adopted by a large enough audience who then must get attached to it or the effort is in vain. According to Google, every step in an app install decreases the number of people who will complete the process. From 1,000 who begin the process, something like 240 will complete the installation, and the number who go on to regularly use the app is deeply depressing to developers.
As the politicians like to say, “make no mistake about it.” This development will be huge over time. Imagine receiving a beacon notification on your mobile Chrome browser inviting you to click through to content like the invitation above. In two clicks you have the PWA available.
If the revolution in proximity, place and context has you by the throat, check back here from time to time. We’re on the story.

For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.

Progressive Web Apps for the Physical Web

Less than a year after introducing the open source Eddystone protocol for Bluetooth Smart beacons, Google has made impressive progress toward making easier the discovery of the URLs the beacons transmit, with more improvement to come. The company shows no inclination to create push notifications, as iBeacon apps are likely to do, but it is preparing a version of its Chrome mobile browser to discover beacon transmissions by default.

Another evolving story involves creating fast, robust, app-like experiences built using modern web capabilities – physical web apps. In removing much of the cost of entry for the capabilities offered by native apps Google is providing a means for virtually any business to compete like a big boy. These web apps can be enabled to work offline and can provide a home screen icon that makes them as easy to return to as Facebook or any other app on your mobile device. The video below might go into more detail than non-coders (like me) will find useful but it does provide an excellent description of the promise involved – complete with a functional example.

For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.

DIY Eddystone Beacon Settings -Beyond the URL

How successful would I be at getting your attention by blowing a dog whistle? Not very unless you were already aware of me. The Physical Web has much the same problem. Bluetooth LE (BLE) radio broadcasts are “there”, but invisible unless you possess the tools to receive them, the dog-ears if you will. When Apple introduced the iBeacon in 2013 the idea was that a custom app would recognize a given beacon’s ID and present content to the device holder. A beacon in this environment, with user permission at time of install, could wake up an app to deliver content. But app development can be prohibitively expensive for many otherwise interested parties, and with so many apps available, offering device real estate to any given option can be a hard sell. So, when Google introduced the Eddystone-URL protocol, requiring initially just one app for any available content, it generated considerable excitement.

Eddystone-URL enables a beacon to broadcast a simple web address or URL. The promise is that a variety of mobile browsers will enable detection of the broadcast and display the address. Chrome for iOS can do it now. Opera for Android makes the same claim. The Physical Web app does it for Android and in early 2016 Chrome for Android mobile will offer the feature. As big as that is, the even bigger news is that it will beep discreetly just once when it becomes aware of content nearby. No need for dog-ears. You can ignore it but at least you will know there’s content available.

The DIY Piece

This development allows for a near future where we can “surf” reality, where the digital and physical realms connect. What excited me when this opportunity began to sink in is that almost anyone could participate. For example, I could create a web page to sell something, like my car or my guitar. I could edit my beacon’s settings to broadcast the address of that web page. I could put that beacon in my car and advertise to anyone walking near, provided that they meet the specs – a Bluetooth LE receiver (like a Smartphone) with Bluetooth enabled and the desire to look.

I needed proof of concept and with beacon purchases, a few dead ends and hours of reading I got it. Around my keyboard as I write this are five Eddystone-compliant beacons, each broadcasting a different URL. When I pull down the notification screen on my Android phone I see a notice that there are beacons nearby. If I click that notice I will usually see between two and four lines that resemble search results, each of them clickable. Why I don’t see five every time is a function of settings and battery conservation, of which I will say more a bit later in the piece. When I do see all five here’s what it looks like:
I chose common sites, mostly with short URLs because there is a character limit. If you need to, you may use a URL shortener like or

How you edit beacon settings to change a URL differs with devices and apps. I use an app from Sensoro, the manufacturer of my five Eddystone units. Of the five, three came in a kit whose maker purchased the beacons from Sensoro. Two I purchased direct from Sensoro. Their app allows me to edit settings on those beacons but when I try to use it on the kit beacons I’m asked for a password I don’t have. That is a security feature that prevents someone with the app from editing settings on another owner’s beacons. To edit the kit beacons I need to use the kit maker’s app.




In the example above I’ve picked a popular website for the URL broadcast. Were I to create my own web content, I could revise it at any time without changing the URL. That would go a long way to addressing the management issue, assuming I was satisfied with initial settings for advertising interval and signal strength. If I wanted to have regular access to those and other settings the cloud platform is more practical.

Look at the centre panel. Here I can select how often per second I want the beacon to broadcast its advertising packet, in this case the URL I’ve chosen. The more often it broadcasts the more likely the receiving browser or app will be listening just then. The penalty is shortened battery life, the same reason that the listening side isn’t listening without pause. Mobile devices run on battery power too and the harder they work the sooner they need a charge. But if you own a coffee shop and your beacon is offering a free donut to passers-by you want to reach as many as possible, and that means broadcasting as near-continuously as possible.

I am on the road to learning to speak beacon. I look forward to meeting you along the way.

For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.