Browsing Google Chrome and the Physical Web

Google Chrome Physical Web URL

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?

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Have you engaged yet with a Physical Web URL via Chrome? What use cases do you think we’ll see? And do you think the Physical Web icon will be a driver of adoption, or will we see other ways to promote these new features?

Drop a comment below, or pop me a note on Twitter.

Content Creator or “Business Builder”? Drop Me a Line

On a side note, we’ve been partnering with content creators, publishers and entrepreneurs of all stripes. We’ve been building out tools to bring proximity channels to new markets. If you’d be interested in learning more, don’t hesitate to drop me a note – doug (at) fidgets.net . Our mission is to help content creators,  publishers, entrepreneurs and companies to build new revenue streams on the Internet of Things.

Advertisements

WWDC 2016: iBeacon and Apple’s Last Chance

Google is cleaning Apple’s clock in proximity. Their suite of software development tools leaves Apple in the dust – from tight integration of their Nearby API and their Eddystone beacon protocols, to the monumentally important physical web, Google is making sense of proximity.

It didn’t need to be that way. Apple was first out of the gate with the iBeacon protocol. They had ample opportunity to take it further.

But a few World Wide Developer Conferences later, and iBeacon is the orphan child of Cupertino – filled with vague promises never fulfilled.

The only hint of iBeacon heading in a new direction was the announcement that you would soon be able to deliver “Offers” . But the project was abandoned when Apple killed iAd. (And the link to the Apple announcement has long been dead).

The Mistakes Apple Makes

The launch of iBeacon promised to revolutionize how our phones would react to the world around them. Apple launched it with little fanfare and yet it prompted a wave of hype – the promise that retailers could reach consumers with coupons, that museums could display digital data “next to” a painting or sculpture, or that we could track down friends at a club because their phones would be broadcasting as beacons.

The initial problems were understandable. A new way to “listen” to nearby devices was bound to have a few bumps. And you’d expect over time that Apple would continue to enhance and improve the technology.

But after several years, the changes have been minimal. And in some ways they’ve perhaps even degraded.

The technology itself, however, wasn’t the only problem:

  • iBeacon was a trademark for beacons, but Apple offered little value in the iBeacon brand. You could adopt the iBeacon mark – or not. There was little incentive for beacon manufacturers to proudly wave the iBeacon flag, because it offered little assurance to end purchasers. Sure, it said that “this beacon can be heard by iPhones” but this caused more of a limitation than an opportunity – because the obvious next question was “What about Android?”
  • Apple lawyers got in the way. The company aggressively protected its ‘iBeacon specification’. But the move was kind of like trying to protect a proprietary version of WiFi – it’s a technology everyone needs to use, and by ‘blocking’ access it created market confusion and all kinds of end-runs around the iBeacon standard.
  • iBeacon detection became (even more) unpredictable. With every new OS release, you’d have to test all over again. The dependability of beacon detection kept changing. With one release, you would detect beacons quickly, and with the next O/S it seemed as if Apple was trying to conserve battery and had toggled back beacon monitoring. Without the ability to dependably say how long it would take to detect a beacon, and without being able to see ‘under the hood’ developers were faced with constantly checking their assumptions about beacon detection every time a new version of iOS was launched.
  • There was little integration with other parts of the Apple ecosystem. Have you ever tried to register your “place” with Apple? I can barely find the page. Google, on the other hand, offers much deeper integration with other parts of their ecosystem – in part because of how far ahead they are on things like maps, places, nearby and other protocols.

But perhaps more than the above, Apple neglected the one thing that it does best: focusing on the end user.

Instead, it has allowed app developers to make what they will of iBeacon and BLE, while offering little guidance on how to create great consumer experiences. As a result, we’ve seen struggles in develop “hits” – apps where consumers truly get a ‘wow’ factor.

This isn’t solely Apple’s fault, of course. Instead, the company has focused on other broader experiences – and will perhaps one day bring iBeacon back into the fold.

Physical Web is a Game Changer

Google, on the other hand, looked at the experience of proximity and has created beacon-detection tools that make sense – the Eddystone protocols are well considered, have rich documentation, great examples, and tight integration with other services.

But the true game changer is the Physical Web. And while it’s early days, the Physical Web creates opportunities for user experiences that truly make a difference – by hooking proximity into the web itself.

With the shift to browsers that can detect and control all kinds of BLE devices, the Physical Web is one part of a larger shift to a Web which reacts to the physical world – and in this open world Google will always be master.

The tension between open and closed systems will continue to tug and pull, but for right now open is winning and Apple is left behind.

WWDC – What’s Next?

All of which leaves Apple with one last chance – to elevate iBeacon from orphan child to star of the show.

If Apple makes a move, it won’t be to enhance the ability to deliver coupons. It will be part of a larger ‘connected space’ strategy which may incorporate Apple News, Music or other products.

But it’s a last kick at the can for Apple, in my opinion. Because depending what approach they take at their Developer Conference in a few weeks, developers may well migrate to a “Google-only” proximity strategy (including the use of Google tools on Apple devices).

It’s up to Apple, as they have many times before, to take what others have done and make it their own. But in this case, the mistakes they need to learn first are their own.

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Do you think Apple can change the game? Or will Google now dominate proximity? What could Apple do next with iBeacon – or is it too late? Drop a comment below, or pop me a note on Twitter.

Kontakt to its Customers: You’re All Doomed


Kontakt, one of the largest manufacturers of beacons, has a message for its customers: you’re all doomed.

In what might rank as one of the more bizarre examples of corporate messaging, the company’s founder has taken to LinkedIn to pronounce that with the arrival of the Eddystone beacon protocol (and related services) by Google, proximity companies are headed for the dust bin if they don’t radically change (and soon).

“Ask not for whom the bell tolls, proximity devs: it tolls for thee,” proclaims Szymon Niemczura.

But extending the logic of Szymon’s article, you can’t help draw the conclusion that it isn’t just the devs who will pay the price for Google’s entry into the market.

If you’re a retailer, a brand, a museum, a car company, a city or a theme park – you too should just throw up your hands and give up now.

Google will own mobile moments, the borg has arrived, and closed off becosystems will look something like AOL in the years to come: a walled garden that no one visits anymore.

And Apple? Naw. Says Szymon:

With a vanishing share of the smartphone market, the last thing the house that Steve built wants to do is give developers even more reason to jump ship.

Ah yeah. Poor Apple. Poor shrinking tiny little Apple. It’s hard to remember that they’re still around! It will be cute to see what little features they try to throw at us to protect their ever-vanishing market share and profits.

What’s Your Secret Sauce?

Now, I like Kontakt. They’re some really really smart people.

(Although, what’s with the videos that look like they were shot at summer camp? And by the way – audio engineering is a thing).

So maybe they have a secret sauce as Szymon claims: “At Kontakt.io, we think we’ve found our special sauce that will keep us growing and thriving as giants of the Internet space like Google, Apple, Facebook, and others compete over who earns what from the IoT.”

In response to which I have a question: China?

Because if Szymon’s observations are true, then the beacon itself has become king. The app layer, the SDKs and the software, the cloud services and back-end analytics will be swallowed up by the Web.

The promise of Eddystone is that you can turn your beacon into a Web endpoint and simply broadcast a URL.

And if that’s true, then it opens up the opportunity to flood the market with cheap beacons from China that do nothing more than broadcast a URL.

Do You Jump Into Bed With Google?

Setting aside the tone of Szymon’s article, it points to a larger question.

Because what’s clear is that Google has hit a home run. Eddystone is everything a beacon should be.

Google took a page from the Apple playbook: wait for the industry to develop, cherry pick the best ideas, and then come out with something that does everyone else one better.

The Eddystone format is brilliant.

But now you need to make a decision: do you go “all in” with Google, do you try to find a middle ground, do you focus on the “app-less” layer or combine different proximity experiences to create a unified customer journey?

Creative Tensions Between Open and Closed Systems

The way you answer the above questions will have a big impact on what kind of beacon you buy and what kind of customer experience you want to create.

In an interview with Kontakt, they clearly think that the “app-less beacon world” is a big deal:

Along with yesterday’s release of new Chrome browser for iOS with support for a Physical Web standard this became clear – proximity devices are able to communicate with our phones without the need for other apps. This means a Physical Web is finally visible and ready for broader adoption.

But here’s the problem: what does “communicate with our phones” mean?

Is that all we really want to do? Is your vision of the mobile world one in which the Web has won?

Szymon is right:

“10 years in Internet is effectively forever, and it’s a rare startup that considers what the landscape will look like as far out as two years, but this matters, so I’ll point it out: native capacity to push alerts and more direct from beacons to devices kills a huge number of app use cases.”

Truly, the traditional definition of an “app” is eroding.

There will be apps that sit on your phone but that you’ll never use on their own. Instead, they’ll be shared as ‘sheets’ inside other apps, provide deep linking capabilities, and sit as a kind of invisible thread across an ecosystem of experiences.

But that doesn’t mean that apps will be replaced by whatever Google has to offer, anymore than it means that HTML will win in the war against native.

Which is why Eddystone does more than just broadcast Web pages (although its ability to do so will open up some pretty great user journeys).

Like many engineers, Kontakt seems to be more interested in the transactional nature of systems than the very real human experience they entail.

(Just look at Kontakt’s Web site or its developer portal and you’ll see what I mean – they feel like were designed in 2002 by a bunch of engineers one weekend).

The implication here is that in the tension which will always exist between open and closed systems, the pendulum has swung: open will win, Google is right, native is disappearing and apps are dead.

If you’re willing to make that bet, great. Go for it. At least you’ve taken a stance! And perhaps in the longer arc of history you’ll be right – but until then we still have to worry about today.

What Kind of Beacon Will You Use?

In response to questions about Eddystone, Kontakt tells me that you’re going to need to make a choice (at least for now) in which of their beacons you choose: Eddystone OR iBeacon.

Why? Because battery.

In an interview, Kontakt tells me:

Our beacons broadcast 4 different frames one after the other: 3 advertising packets (Eddystone-UID, Eddystone-URL, Eddystone-TLM) and a scan response. To the best of our knowledge, Kontakt.io is the only company on the market who has offered that from day one.

We have been investigating the possibility to add also an iBeacon frame to the set, but broadcasting that many different packets is going to cause a pretty heavy battery drain. While we research ways to help keep a useful battery life on our product, we will also be looking at client demand for this feature. We don’t have any timeline on when we may roll this out, as it’s very much just in R&D right now.

Which is odd, considering that if you don’t interleave with iBeacon, then your beacon battery might be fine, but the iOS user’s won’t be. By relying on Core Bluetooth instead of the native framework from Apple, you can expect Apple users to take a hit on battery life if you’re solely relying on the Eddystone format.

These kinks might be worked out, but it’s an obfuscation to say that it’s your beacon’s battery which is the sole limitation.

In fairness, Kontakt isn’t entirely advocating a “throw out your iBeacons” stance. If you’ve got some of those old beacons lying around then sure, why not, you should hang on to them. (But I guess you should know that you’re missing out on some huge potential):

Every discussion regarding iBeacon and Eddystone formats, and which one fits our client needs better, always starts with a question about use case details. Eddystone opens new possibilities, but at the same time requires more complicated coding to integrate as it sends more types of data than iBeacon does. Beacons that use Eddystone-TLM format to send telemetry data (such as temperature data) will have shorter battery life because they are sending more data packets etc. All of that needs to be taken into account before we jump on the Eddystone bandwagon.

In general, I think that “switching” is probably not the correct choice for anyone with a live deployment right now. Anyone with a P.O.C. that’s running, though, or someone who’s in early tests? I would strongly encourage that those people try this out because this whole platform is growing in exciting ways and has huge potential.

For many use cases, an Eddystone URL format beacon might be fine. You might be able to move the needle a bit on customer engagement.

For everyone else, there are larger questions at stake.

Kontakt itself hints at this future. With the coming wave of mesh beacons, the company’s Cloud Beacon takes aim at what will happen when the next Bluetooth specification starts hitting the market. The company tells me they have big plans, and that those plans validate why its Cloud Beacon format isn’t threatened by Google’s Proximity API:

Our Kontakt.io Cloud Beacon remains the only enterprise-level tool for beacon monitoring that we’re aware of: if you need to be able to guarantee that you are scanning and looking at beacons in a given area at regular intervals, a Cloud Beacon is your best bet. On top of that, Cloud Beacons are part of our other real competitive advantages: security and sharing.

In the future we will introduce completely encrypted channels for communication between beacons, cloud beacons, and smart devices. This, combined with powerful features such as our scheduled profile shuffling (driven by our API) and the industry’s only Power Sleep mode designed to extend beacon battery life, means that the Cloud Beacon still has very strong USPs that make it an attractive prospect for any company looking to roll out beacons on the large scale.

An Industry Transformed

The industry has been transformed with the launch of Eddystone.

For beacon manufacturers, a new wave of low-cost alternatives from China will put pressure on them to tighten up the value-added services they provide, the relationships they have with developers, and the level of execution they put into their user documentation, community management and marketing.

For developers, the range of opportunities has expanded rather than contracted.

But while Eddystone might seem to cut through the clutter and remove barriers in app development it also creates a richer, and thus more complex suite of choices for brands, retailers, cities and cultural institutions.

I have deep faith in this industry.

I don’t need to give any of you a wake-up call or tell you that you’re doomed. Because for the 100s of proximity companies I’ve talked to, and for the hundreds of brands and retailers we’ve interacted with (and who are doing their best to make sense of a rapidly changing world), I’ve found that optimism in the face of progress is the best guarantee of innovation.

And this week, we’ve entered a new era in which to thrive.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

How will you respond to Eddystone? Is this a new era of doom or one of innovation?

iBeacon and Why Apple Streaming Music Might Be Free

Apple can make its streaming music service free. And it’s because of iBeacon.

The New York Times reports that industry analysts are predicting a tough climb for the company’s new streaming music service. Apple will need to shift from the pay-to-download model of iTunes toward the all-you-can-eat-buffet of streaming music. And in doing so, it will need to get the support of a music industry that can now turn to Pandora, Spotify or other services to push back on pricing and access.

But these reports are looking for the Apple advantage in all the wrong places – focusing on apps and pricing, iTunes and vivid visuals.

And while those things might be important, Apple has advantages that other streaming services don’t.

This includes access to a platform for music which is larger than the Web and bigger than mobile – a platform made possible, in part, by iBeacons.

Apple Is – Gasp! Not The First-Mover

According to Toni Sacconaghi, a financial analyst for Sanford C. Bernstein, Apple is late to the game.

“They’re used to being a shaper rather than a responder,” Mr. Sacconaghi said. “This is one of the few times where Apple is playing catch-up and not necessarily coming from a position of strength.”

Which makes me wonder what universe Sacconaghi is analyzing, exactly.

History has shown the opposite, of course. The entire Apple business model is based on coming late to the game – letting others get there first and arriving later with far superior products, whether music players, tablets, phones or watches.

If there’s a company on the planet who has shown it knows how to excel at coming second it’s Apple.

Regardless, the media seems happy to create a narrative in which there’s a good old-fashioned showdown between entrenched players like Spotify and the “newcomer” which is Apple.

Is The Apple Advantage an Interface?

These reports predict that Apple might have a shot because…well, because it will have a shiny interface:

The new music app, which is a collaborative effort between Mr. Reznor and other Apple and Beats employees, including Jimmy Iovine — who founded Beats with the hip-hop star Dr. Dre — will feature the streaming music service with many of the same characteristics as the Beats Music streaming service, one Apple employee said. Those may include curated playlists and a more vivid visual appeal, while conforming to Apple’s sleek and minimal design aesthetic, one person said. The name Beats Music will most likely be shed.

More vivid visuals. A minimal design aesthetic.

I can hear Jony Ive now, luxuriating over how every single pixel is perfect, hand drawn from molten gold with every musical note optimized down to nanogradients of sound.

The larger Apple advantage isn’t, of course, an interface. (iTunes has survived just fine even in its current incarnation as a benchmark for horrible UX design).

Apple’s advantage is its ecosystem, from the hardware to software, continuity between devices, and connectivity to your iPad, Apple TV or coming Watch.

If nothing else, Apple could drive a user experience which adapts a music stream based on whether you’re running or working out, can shift a stream from your iPhone to your home speakers with the flick of your thumb, and connect the mood of your music to the Philips lighting in your living room.

This ecosystem on its own, in addition to 800 million iTunes users, can give Apple an edge, regardless of the monthly price.

But there’s another frontier worth considering and it has nothing to do with the device in your pocket or the technology in your home. Because elsewhere the physical world is becoming a digital interface.

And streaming music could, one day, be embedded in things, with iBeacon showing us the way.

iBeacon and The Battle for Physical Space

iBeacon is Apple’s trademark term for Bluetooth Low Energy devices. By sending out a small radio signal, beacons allow our phones and other devices to “see” the world around them.

Beacons are being used in museums and public gardens, shopping malls and parking lots. They let the owner of a “place” send out a push message, a coupon, a piece of media or a special offer to a user’s phone via a ‘beacon-enabled’ mobile app.

Unlike NFC or QR codes, the user doesn’t need to do anything. Their app can be closed but their phone will still listen for beacons.

You can trigger a lock screen message or your app can just be a lot smarter when a user opens it up – sensing nearby beacons in order to present contextually relevant content.

Beacons represent one technology amongst many that are enabling digital interactions with physical space. Anything you can do online can now be triggered by people, places and things. You can “Pin” a store display, Tweet a painting in a museum, or browse a catalogue in the hardware store.

Often conflated with the Internet of Things (which generally refers to the ability of sensors and devices to talk to each other) they nonetheless represent a larger trend towards a fully connected physical world in which billboards know who you are (Minority Report style) and products on a shelf can talk.

Unlocking the Value of Proximity

This convergence of the physical world with digital affordances represents what we think is a platform that will be larger than the Web, which will be more disruptive than mobile, and which will enables new forms of value creation that weren’t previously possible.

With beacons we can link media, content, data and social interaction to the “last meter” of human experience. We can create digital engagement at the point of purchase, we can nudge users from one gallery to another in a museum, we can connect how we live, work and play to increasingly smart and data-driven systems.

This opportunity is both massive and massively frightening.

The convergence of the digital and physical worlds leads to self-driving cars and delivery drones, an apocalypse of artificial intelligence and the benefits of medical research conducted at massive scale.

It also unlocks value that was previously either unavailable, obfuscated or difficult: because if I can connect what you do on a phone to your presence in physical space, if I can connect a piece of media to the point of purchase, it means I can create a connection between digital media and physical activity or product purchases.

It’s this convergence which could both lead to a ‘renaissance of retail’ and its (even more) massive disruption.

In a future of beacons, we’ll see the “AirBnB of grocery” and the “Uber of retail”.

And we’ll see how things like music won’t just be portable. Their value will be embedded in everything.

The Next Big Apple Play is Loyalty

OK, I hate the term loyalty. Because most loyalty programs aren’t about loyalty. They’re transaction-based rewards for purchasing stuff.

I hate the idea of a product called called Apple Loyalty – it sounds like an airline rewards card or a bonus system for owning a ton of Apple devices (buy 10 iPhones and get a free Beats headphone!).

But if there was a company that was going to reinvent the concept of “loyalty” who better than the company that knows something about loyalty? And who better than a company leading the charge on mobile payments, with a growing infrastructure of merchants and payment providers, with the ability for stores to register their locations, and with the software tools to make beacon-detection part of the retail landscape?

Think of it this way:

  • You have two coffee shops near each other
  • One accepts Apple Pay, has iBeacon installed, lets you order in advance, makes the experience of buying your cappuccino frictionless
  • It also has a system in place where you show up, buy a coffee, and your Apple streaming music account is topped up or you’re able to pick up a recommendation from the staff or others who have visited the store

Or imagine going to a concert at a local club and there’s a “powered by Apple Music” sign at the front entrance.

You join a pop-up social network, you share some of your favorite Apple Music streams with fans nearby.

And once you leave your Apple Music account has been personalized, you have access to exclusive band interviews or raw clips from their last recording session, and your streaming costs for the month have been reduced by half because the concert promoter kicked back an account top-up with your ticket purchase.

An Apple patent for iBeacon imagines concerts as venues for media delivery:

Apple’s patent FIG. 15C indicates various location-based content that may be provided in connection with a concert or other music venue. A concert or music venue may provide content including, for example, music, setlists, virtual cards, website information, schedule information (e.g., for upcoming shows at the venue), graphics (e.g., album art, pictures of the band members, etc.), ticket sales (e.g., provide user option to purchase tickets in advance), general information relating to the concert, or any other information.

It’s not loyalty in the traditional sense. It isn’t about transactions it’s about experiences.

And it leverages the power of beacons: because for the first time, physical venues have a financial incentive and an ability to measure digital interactions against real-world behaviour.

If I own the coffee shop and I become an Apple Loyalty location I’m doing it because I can drive more foot traffic to my store compared to the one down the street. The fact that you as the customer get rewarded with Apple Music, if you get a bonus song instead of $2 off your next purchase, so much the better. I’d rather reward you with something you LOVE anyways instead of reducing your bill the next time you visit.

The coffee shop wins. Apple Music wins because it gets more “listens”. And the consumer wins because someone else is partly footing my music bill, and their experience of “place” becomes more deeply grounded in their digital and physical life.

iBeacon, Apple Pay and Apple “Loyalty” are simply the facilitating technologies which will help to triangulate our digital lives, our physical visits, and the interests of the places that we go.

Apple Everywhere

Apple isn’t alone in wanting to own the path you take through the world.

While Apple is focused on closed ecosystems and what I think of as “deeply connected” experiences, Google is coming at the same challenge from a different direction – using the “cloud” to provide an always-on, “deeply ambient” suite of technologies to help guide you through space.

Best typified by Google Now and Google Waze, their goal is to quietly collate where you go and how long you visit with its massive data sets in order to predict and present content that will become increasingly smarter and smarter. Google will know where you’re going before you’ve even decided yourself.

For Apple, the future is smart devices connected to relatively dumb “clouds” (an idea reaffirmed by Tim Cook’s focus on privacy).

For Google, the future is a smart cloud connected to relatively dumb devices.

But both are on a path to take your experience of them out of your pocket and into your home, into the stores you visit and into the music you listen to, television you watch, and games you play.

Beacons are part of this larger journey – dumb devices against which value can be assigned, music unlocked, experiences created, with the result being an absolute blurring of the lines between our digital personas and our physical bodies as they move through space.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

What do you think? Will Apple Music be more than just another version of ‘streaming beats’? How might it connect to Apple loyalty, Apple Pay and iBeacon? Drop a comment below.

Beacons Meet WiFi: Cisco Meraki Has Its Eye on Connected Spaces

Bluetooth LE beacons have shifted beyond prototypes and pilots into large-scale distribution. But this shift has brought us bumping up against the downside to a beacon’s elegance and simplicity. Because if a beacon is a relatively simple (and dumb) device, how do you intelligently manage them at scale?

One company thinks it has a solution. Meraki, a division of Cisco, launched a WiFi end point which can both act as a beacon and monitor devices in the area, report back to a cloud-based dashboard, and allow you to manage and shape WiFi traffic at the same time.

I spoke recently to the Meraki team. Adam Weis and Simon Tompson gave me an overview of their system and approach. For a company that’s managing massive networks of WiFi end points (70,000 hotel rooms in one case), they know a thing or two about fleet management.

And as beacons shift into distribution at scale, their approach will both help relieve some of the pain of beacon monitoring while offering the possibly larger advantage of being able to shape WiFi traffic and monitor WiFi networks from the same intuitive dashboard.

Beacons Call Home

The beauty of iBeacon (the trademarked term by Apple for its preferred configuration for the open standard of the Bluetooth Smart devices) was its simplicity. Apple did the heavy lifting in thinking about how beacons could be configured, provided easy-to-use software tools to help you create apps, and then stood back while the media branded the beacon industry with the iBeacon brush.

The move by Apple helped to accelerate an industry. By opening up support for beacon detection (and using your phone or tablet to broadcast as a beacon), we finally had a single standard that would work across all the major phone platforms. And by making the tools simple to use, it spurred a wave of innovation and testing which took advantage of the fact that a beacon doesn’t actually do very much.

Like any radio transmitter, a beacon transmits a signal. The signal contains a small packet of data (which also helps protect battery usage on both the beacon and the user’s phone), and that data includes unique ID numbers, some power and battery data, and a signal strength – all of which are used to identify which beacon you’ve detected and how far away you are.

But as the industry rapidly matured, this simplicity also started to show some cracks.

There was a scramble to make developing beacon detection for Android as simple as it was for Apple. And with Apple willing to enforce its trademarks and proprietary specifications, we started seeing separate beacon broadcasting specifications emerge, with a better-known example being the AltBeacon standard.

Beacon manufacturers emerged and took advantage of how relatively simple it was to build a beacon. But their simplicity came at a cost: it’s easy to create a beacon, configure it, put in a coin cell battery, and attach it to your wall.

But the beacons didn’t do much more than their original purpose. They broadcast a signal but they didn’t receive anything. If you wanted to reconfigure them or monitor their battery you needed to use an app while standing next to the beacon.

Your beacons, in other words, had no way to call home.

Managing Beacons at Scale

For a retailer, the idea that you’d deploy thousands of beacons across hundreds of locations and have no simple way to manage or monitor the devices without sending out staff seemed like a non-starter.

In the early days of the industry, more than one beacon company told me that managing your beacons wasn’t necessary: the devices were so cheap you could just throw them out when they died. But try telling that to a national retailer (or even a large museum!). Because the cost of training staff and sending them out to pop a new beacon on the wall was an instant deterrent to large installations.

The solutions included payloads embedded in user apps, extending the battery life through improved beacon performance, embedding beacons in light bulbs, or plugging them in. By making beacons last longer, the need to replace them would decrease.

But it was clear that beacon fleet management would quickly become a differentiator for the companies that could manage it well. Companies like Netclearance Systems launched a cloud management system and Kontakt.io recently launched its Cloud Beacon.

These solutions relied on placing another device in a store or venue: a sort of “hub” which could both call home and send/receive data, and could connect with beacons in the area in order to update their firmware, change their IDs, or monitor their batteries or performance.

In a World of WiFi, We Have An Endpoint

But Meraki thought it had a more elegant solution. Because why add another device to your location when you already need a box for the most pervasive endpoints available: WiFi.

The company has changed the game for how institutions manage WiFi infrastructure – moving us from the dark ages of what often looked like a command line interfaces to an elegant cloud-based solution that had a lot in common with the most intuitive dashboards available.

This was industrial scale WiFi management with a dashboard your mother might even love.

They took the pain out of managing WiFi endpoints. Organizations ranging from universities to hotel chains deploy, manage, monitor, secure and shape traffic for often widely distributed systems – and with Meraki do so in an intuitive way. (They were so successful that Cisco snapped them up).

So Meraki had a simple premise: since you’re already monitoring your WiFi with their endpoints, why not also use that same dashboard to monitor nearby beacons?

And while they were at it, they threw in the capacity of their WiFi box to ACT as a beacon – a boon to a smaller location that might not need a beacon in every aisle but just wants to send a beacon message when you arrive at the front door.

Their solution solved a simple problem: can I easily monitor all the beacons in the area, keep an eye on their batteries and other signals, and do something useful with the data?

Adam Weis, a brilliant guy and someone who helped drive a lot of the thinking behind the Meraki approach, explains:

Is Monitoring and Configuring the Same Thing?

The Meraki system is simple. It has an incredibly elegant and easy-to-use interface. It not only broadcasts as a beacon, but lets you monitor for ALL Bluetooth-enabled devices in its region:

It helps answer one of the more pressing challenges of fleet management: making sure your beacons are still working and that their batteries haven’t run out. By also monitoring other devices in the region, Meraki is providing a richer data set. I can now compare, for example, the number of total devices and then cross-tabulate that data to the number of beacon “app impressions”.

Meraki can’t, however, update a beacon’s firmware or update their UUIDs. To do that, you need to be able to “pair” with the beacon and the pairing is usually handled by tools provided by the beacon manufacturer. In many cases this might not be an issue – but an ideal scenario would be for Meraki to also partner with beacon manufacturers to allow institutions to also PAIR with the beacons via the Meraki dashboard.

In the meantime, it’s where solutions like the Kontakt Cloud Beacon come in – systems to manage your fleet of beacons and their ID numbers, but without the advantage of being a full WiFi endpoint.

WiFi + Beacon Is A Big Win for Many Use Cases

But let’s face it – in many cases, Meraki is enough. A library, for example, probably doesn’t need to swap the UUIDs of its beacons very often and firmware updates aren’t usually deployed, or rarely. And Meraki offers the advantage that it takes care of another key challenge in creating a ‘connected space’ – you need to manage WiFi access as well, shape WiFi traffic, and would prefer to do so in an intuitive way.

If your WiFi network can also ACT as a beacon and monitor the small fleet you have set up in your hotel lobby, say, then you’re getting two for the price of one: an intuitive WiFi management tool, a beacon, and the ability to monitor any additional beacons you place in your space.

Where Technologies Intersect

But there might be something more profound at play.

Because as beacons have shifted into larger deployments, they’ve also shifted into being just one of several technologies being used to ‘digitize physical space’. And it intrigues me to think about a future in which beacon detection can be combined with network monitoring and access management and then be used to shape new kinds of experiences in a location.

Today, you drop by a Starbucks and hop on a WiFi network. But in the future, a combination of beacon interactions and WiFi access might be combined to create new kinds of experiences.

We call beacons the “gateway drug to the Internet of Things”. They’ve been easy to understand. And they open our eyes to a world in which physical space is a new digital touch point. As they start to intersect with other technologies their management will become more complex but the types of interactions we can enable will also become more elegant, more innovative, and hopefully more useful to the end user.

Meraki has shown us one way that beacon technology will start to intersect with others. As we create the digital fabrics of physical space, it’s an early indicator that the beacon era is just getting started.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

What other technologies will beacons intersect with? What are the use cases for WiFi and beacon monitoring and where do you see Meraki fitting into your plans? Drop a line below.

Tutorial: Making a Smarter iBeacon Detector on iOS Using PubNub | Guest Post

Apple has been using BLE on its devices since the iPhone 4S. Because of that great head start, using your iPhone to detect beacons is much easier than on any other platform! In fact, Apple’s iBeacon protocol was the first to take advantage of the great qualities of BLE communication.

In our previous tutorials, we walked through an overview of beacon technology and how to build an iBeacon emitter.

In this tutorial, we will make a smarter iBeacon detector (ie. observer)!

Using PubNub and iBeacon, we can create two-way communication while still keeping the low energy asset of beacons! You’ll want to read a little bit on how we plan on doing this, this article will give you a high-level explanation on how our app is supposed to function. This weird, but simple setup increases the capabilities of iBeacons greatly!

We will first look into how to turn your iPhone into an iBeacon in Swift, and we will build the PubNub structure over it!

What are we waiting for? Let’s build amazing apps! This article is inspired by this example app so feel free to use some of its available source code.

 

 

Using your iPhone to detect iBeacons

In the scope of this tutorial, we will build a minimal app on which you can build upon and improve. As a result, we won’t really get into building the user interface. We want to keep it clean and simple.

Setting up your View Controller

First things first, let’s import our libraries.

[snippet id=”368″]

That’s all we’ll need for this.

The variables you’ll need in your view controller are as follows. We’ll talk more about them later on.

[snippet id=”369″]

For the sake of simplicity, we will have most of our application in the viewDidLoad() method. It’s up to you to arrange it as you wish.

[snippet id=”370″]

The first thing we need to do here is create a region element. The beacon region element defines how the proximity to a beacon or a set of beacon should or will look like. What this means in our example is that we are defining beacon regions that have our specified UUID. As a result, when we will detect beacons, we will only detect those with this particular UUID. We could have just as well initiated our region with a UUID, major and minor which would have limited our detection to beacons which satisfy all 3 conditions.

The next step is to create a location manager instance. The location manager is the element that will allow us to use the iPhone’s hardware to start detecting beacons. We will need to set a delegate which will call the location manager’s methods when certain events will be triggered. We set our view controller as the delegate. Don’t forget:

class YourViewController: UIViewController, CLLocationManagerDelegate {

For iOS 8 or more, it is necessary for the app to request the user’s authorization to use location tools. This line usually will not suffice. You have to manually add a couple lines in the info.plist file which is located in the “Supporting Files” directory. If you right click on it and open it as “Source Code”, you want to make sure you add these lines inside the “<dict>” markup.

[snippet id=”371″]

When the user first starts the app, a pop up dialog box will ask the user to authorize location services along with the string we just defined.

We can finally start monitoring for our beacon region!

For now on, our view controller will be waiting for the following events:

  • didStartMonitoringForRegioin
  • monitoringDidFailForRegion
  • didEnterRegion
  • didExitRegion

We will only implement one of those methods:

[snippet id=”372″]

When we started monitoring for regions, we are only subscribing to entering and leaving a region events. In the scope of our app, we need more information. Remember, we want our iPhone to connect to PubNub when we get close enough to a beacon. To save some energy, we will start to range beacons only when we enter a region of interest.

This will trigger a didRangeBeacons:inRegion: method much more frequently than the didEnterRegion method. It will be called as soon as the distance to the beacon changes.

[snippet id=”373″]

Alright! I hope we cleared out the logic for using Apple’s tools to detect our iBeacons. The next step here is to make our iPhone compatible with our smarter emitting beacon. If we want to establish a two-way communication with the beacon, we want to subscribe to the same PubNub channel as soon as we get close enough (you can think that “Near” distance suffice, here we will require to get at “Immediate” distance to start the communication).

Making your iBeacon Smarter with PubNub

Getting Started

The first thing you will need is the pubnub library for iOS.

We are going to use cocoa pods. If you don’t use it yet, you’re missing out. Easy installation and starter’s guide here.

In your project’s root directory

[snippet id=”374″]

Your podfile should look like:

platform :ios, “8.0”
target “YourProject” do
pod ‘PubNub’, ‘3.7.2’
end
target “YourProjectTests” do
end

You can make sure you are using the latest version of pubnub here.

Now you just need to type

$ pod install

Close Xcode, and open the YourProject.xcworkspace .

That wasn’t too hard right? It’s not quite over though.

Use Objective-C libraries in Swift

The pubnub library is written in Objective-C, but we are coding in swift. All you need to do now is to build a bridging header. Create a new Objective-C header in your project called YourProject-Bridging-Header.h for good practice, and type:

[snippet id=”375″]

Now in your project’s configuration panel, go to build settings and scroll down to the “Swift Compiler – Code Generation” section. Set the “install Objective-C Bridging Header” to Yes and in “Objective-C Bridging Header” type the path from your project’s root directory to your bridging header. It’ll be something like “YourProject/YourProject-Bridging-Header.h”


 

All set? Let’s roll.

Initializing PubNub

For the sake of simplicity, we will code our PubNub behaviour on the same view controller.

We will need to add 3 variables to our class:

[snippet id=”376″]

When a user connects to PubNub, he is identified with the content of this PNConfig object. For the scope of this tutorial, we will use demo keys. Get yours here!

In the viewDidLoad method, we will also start PubNub. Add these lines and don’t forget to set your class as a PNDelegate:

[snippet id=”377″]

Awesome! We are connected to PubNub!

We want to use the data advertised by the beacon to subscribe to the beacon’s channel.

Subscribing to the PubNub channel

We need to add a couple line to our didRangeBeacons method in order to subscribe once we get at “Immediate” distance from the beacon:

[snippet id=”378″]

That’s it. We just need to make sure we did not already subscribe to the channel.

[snippet id=”379″]

On the beacon’s side, our subscription event should trigger the beacon to send a message on the channel. We need to implement the method which will be called whenever a message is sent on the channel.

[snippet id=”380″]

Alright! We just received the message! We are good to go. It’s up to you to figure out what you want to do with it.

Finally, when we exit a region, we will want to stop all of these processes:

[snippet id=”381″]

With just a few lines of code, you just created a two-way communication with a beacon while still having a low energy consumption! How great is that? We hope you liked this article.

Next, we’ll build an iBeacon emitter.

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.

Tutorial: Making a Smarter iBeacon Emitter on iOS with Swift with PubNub | Guest Post

Apple has been using BLE on its devices since the iPhone 4S. Because of that great head start, the iPhone is easier to turn into a beacon than any other platform. In fact, Apple’s iBeacon protocol was the first to take advantage of the great qualities of BLE communication.

In our other tutorials, we walked through an overview of beacon technology and how to build an iBeacon listener (detector).

In this tutorial, we will make a smarter iBeacon emitter! Using PubNub and iBeacon, we can create two-way communication while still keeping the low energy asset of beacons! You’ll want to read a little bit on how we plan on doing this, this article will give you a high-level explanation on how our app is supposed to function. This weird, but simple setup increases the capabilities of iBeacons greatly!

We will first look into how to turn your iPhone into an iBeacon in Swift, and we will build the PubNub structure over it!

What are we waiting for? Let’s build amazing apps! This article is inspired by this example app so feel free to use some of its available source code.

Using your iPhone as an iBeacon

We won’t get into doing the user interface here, we really just want to focus using the iBeacon capabilities of your phone.

Setting up your View Controller

First things first, let’s import our libraries.

[snippet id=”382″]

That’s all we’ll need for this.

Inside our view controller class, we’ll have variables representing the UUID, the major and the minor of our advertised signal.

[snippet id=”383″]

You can chose any uuid or major and minor as long as the uuid is the same as the one you inserted in the app detecting your iBeacon signal.

Start advertising the iBeacon in a region

You need to create a CoreBluetooth peripheral manager which will control the advertising of your data. Don’t forget to set your View controller as a CBPeripheralManagerDelegate.

To simplify our app, we will start our peripheral manager when the view loads.

The first thing we want to do is build a beacon region. This will create an object defining the data you want to advertise: uuid, major, minor.

The next step is to create a peripheral manager instance. The peripheral manager is the element that will allow us to use the iPhone’s hardware to start acting as a beacon. We will need to set a delegate which will call the peripheral manager’s methods when certain events will be triggered. We set our view controller as the delegate. Don’t forget:

class YourViewController: UIViewController, CBPeripheralManagerDelegate {

For iOS 8 or more, it is necessary for the app to request the user’s authorization to use location tools. This line usually will not suffice. You have to manually add a couple lines in the info.plist file which is located in the “Supporting Files” directory. If you right click on it and open it as “Source Code”, you want to make sure you add these lines inside the “<dict>” markup.

[snippet id=”385″]

When the user first starts the app, a pop up dialog box will ask the user to authorize location services along with the string we just defined.

[snippet id=”386″]

Alright, so we generated a dictionary containing the data we want to advertise in the proper format. The region object holds the important data. The measured power argument represents the RSSI power of our emitting device from a meter away. Remember, inside the advertised data, one byte represents this value which is used by the receiver to estimate how far the beacon is. By entering nil, this will return the default RSSI value of your device. That’s probably what you’ll want to do 99% of the time.

Finally we start our CBPeripheralManager. Since we set our View Controller as the delegate, as soon as the manager starts, the peripheralManagerDidUpdateState:peripheral: method of the delegate object (i.e. our view controller) will be called.

[snippet id=”387″]

When the method is called with a powered on state, we can start advertising our data. Its up to you to decide how your app will behave for other states.

And that’s all it takes. Easy, right? Just a couple lines and we can start advertising our data! Beautiful.

The next thing we want to do is make our app magical. That’s where PubNub comes it.

Making your iBeacon smarter with PubNub

Getting Started

The first thing you will need is the pubnub library for iOS.

We are going to use cocoa pods. If you don’t use it yet, you’re missing out. Easy installation and starter’s guide here

In your project’s root directory:

[snippet id=”388″]

Your podfile should look like:

platform :ios, “8.0”
target “YourProject” do
pod ‘PubNub’, ‘3.7.2’
end
target “YourProjectTests” do
end

You can make sure you are using the latest version of pubnub here.

Now you just need to type

$ pod install

Close Xcode, and open the YourProject.xcworkspace .

That wasn’t too hard right? It’s not quite over though.

Use Objective-C libraries in Swift

The pubnub library is written in Objective-C, but we are coding in swift. All you need to do now is to build a bridging header. Create a new Objective-C header in your project called YourProject-Bridging-Header.h for good practice, and type:

[snippet id=”389″]

Now in your project’s configuration panel, go to build settings and scroll down to the “Swift Compiler – Code Generation” section. Set the “install Objective-C Bridging Header” to Yes and in “Objective-C Bridging Header” type the path from your project’s root directory to your bridging header. It’ll be something like “YourProject/YourProject-Bridging-Header.h”

All set? Let’s roll.

Initializing PubNub

For the sake of simplicity, we will code our PubNub behaviour on the same view controller.

We will need to add 2 variables to our class:

[snippet id=”392″]

When a user connects to PubNub, he is identified with the content of this PNConfig object. For the scope of this tutorial, we will use demo keys. Get yours here!

In the viewDidLoad method, we will also start PubNub. Add these lines and don’t forget to set your class as a PNDelegate:

[snippet id=”390″]

We are all set. All we need to do is to define the methods that will be called when events occur on the channel.

There is a long list of methods being triggered for various events, you’ll find it here. We’ll only implement one for our app.

[snippet id=”391″]

When someone joins the channel, the method is triggered and we send a message to the channel that the end user will receive! The message can be any object in the form of a JSON. Here we just send a string, but you could configure the message to have a receiver variable so that only the user who just subscribed receives it.

That’s it! Our iPhone acts like a beacon that emits information to join the PubNub channel. When the customer is close enough to the iBeacon, his phone will subscribe to the advertised PubNub channel. Our beacon is listening for presence events to the channel and immediately sends a message on the channel for the user to see!

Beautiful. Hope you like it. There is so much more you can do with so little code.

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.