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) . Our mission is to help content creators,  publishers, entrepreneurs and companies to build new revenue streams on the Internet of Things.

Samsung and the Physical Web Get CloseBy

Samsung has announced support for Physical Web URL detection in its Samsung Internet browser – the default for Samsung devices.

Called CloseBy, the support allows users to activate an extension to their browser which will then deliver a notification when they’re “close by” to a Physical Web beacon. Tapping on the notice, the user is taken to a Web page within the Samsung Internet browser.

The Physical Web is an open source standard for broadcasting a URL from a Bluetooth LE beacon, Wi-Fi direct or other hardware.

Challenges Ahead

CloseBy is still in beta and is reporting its share of glitches. These will be worked out.

But for brands, retailers and developers there’s increasingly a larger challenge in how to effectively managing the end user experience.

Fragmentation is a potential problem. When coupled with the fact that Physical Web has been designed primarily with a “lean-forward” consumer in mind, this is creating a challenge in consumer education.

Simply put:

  • If you want to make sure that most of your users (say, visitors to your store) can be made aware of and “see” a Physical Web URL, some sort of visual prompt is required
  • This is caused by an inability to actively notify users that there is a URL nearby. In theory, your Physical Web URL will appear 100% of the time in the notification tray (although there are serious enough issues with this as well). But getting users to check their notification tray requires some sort of physical world prompt (a sign, say).
  • Google Nearby attempts to solve this by “surfacing” notices. How this happens is opaque.
  • To solve for these challenges, a retailer or location should provide signage or prompts. Just like consumers needed to learn the purpose and use of QR Codes, the theory is that they’ll also learn about Physical Web URLs.

But with the Samsung launch, we now have another series of steps a consumer needs to take to “see” a Physical Web URL.

So how do you resolve the different types of education needed for different devices? It seems unbearable to think of a Physical Web sign with different activation instructions for 3-4 different device types!

(We haven’t even discussed iOS where Physical Web is available through notification widgets for Google Chrome!).

Change is Good. Change is Bad.

Further complicating issues is that there are changes happening with little education of the ‘beacon industry’ and developers.

A stellar comment by “mjanke67” on GitHub captures the heart of the issue:

I would suggest that until that level of Physical Web adoption occurs, users simply won’t drop their drawers (ed: notification tray) to check for scanned Nearby objects. Ultimately, the Physical Web adoption may never grow because it has been setup for future and not current levels of adoption. To address this – it is key that users retain their ability to view Nearby Notifications in both the Status Bar and Lock screen. To ensure that users don’t get offended by too many notifications, disable their display within the Lock Screen by default but give them the ability to enable notifications on the Lock Screen if they so desire. This same control (or another) could be used to enable display of an icon within the Status Bar when a notification has been added to the drawer. With this level of control in place, interested users can be shown or taught how to get notified by Physical Web objects. Disinterested users will leave Status Bar and Lock Screen notifications disabled (their default state) and will be unaffected.

Another key point that I would raise is that Nearby Notifications did exist within the original deployment of Nearby within Google Play Services (GPS) and were removed without warning after my company and others built product around the Nearby featureset. Removing original service features without discussion or warning is (choosing my words carefully) – very very uncool.

This last point is worth noting: features may change without warning.

And while many of them might be in the end service of users, or in the end service of providing a balance between users and developers/locations, it can be disconcerting (or a show stopper) to plan an entire roll-out only to have the use case itself change in a significant way before (or during) launch.

So, sure, all of these tweaks and improvement are good – but they often come with a lack of explanation and non-existent access to meaningful interaction data.

Samsung Gets Closer?

So, Samsung now supports Physical Web URL detection. It joins Opera (which I think was first to the party) but clearly represents a far more substantive audience.

But there are a few things left unclear – and maybe anyone testing the beta version can chime in with a comment below.

  • Is CloseBy like Google Nearby in how it “surfaces” notifications? Their post and screen shots seem to show a lock screen notice.
  • If it does display a lock screen notice, is this a 100% reliable notification?

In other words, at what step does the following screen appear in a user’s journey?


Second, Samsung mentions a server:

Upon receiving a URL from the Physical Web object, your phone sends that up to our servers in order to find the title of the page and determine whether to show it.

Can we assume that this is simply a way to parse a URLs metadata in order to display a notice? Where does this content come from? How do the fields on a web page match over to the notice that the user sees?

And are these notices consistent with how other Physical Web detection works, or will developers need to create different metatags for different systems?

Beacon Next

It’s an exciting time for the beacon industry. The Physical Web, Samsung CloseBy and Google Nearby are giving options across devices for the delivery of messages to users.

To fully take advantage of beacons, the next step would be to lead a user to download a beacon-capable app. Within an app, a developer can more finely control and measure the impact of proximity on an end user.

So, this part of the “funnel” is important and Samsung’s entry is a welcome development.

But the large beacon ‘ecosystem’ is leading to a fast-changing and fragmented set of user experiences which will create new challenges in how we educate consumers and how we prompt them in physical spaces.

Share Your Thoughts – Have You Tested CloseBy?

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 tested Samsung Internet? What has your experience been? How well does it handle notifications and consumer on-boarding? And how well do you think we’ll be able to manage consumer interactions and education?

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


BeaconControl: Open Source Beacon Management

Launching this week, BeaconControl is an open source platform for managing proximity experiences using Bluetooth LE beacons.

It promises to help extend the stack of tools available to developers, organizations and brands and allow for more seamless integration with existing systems.

“The platform eliminates the need to focus on low level issues such as hardware integration, security and beacon deployment,” Marley Fabisiewicz, Founder of BeaconControl, tells me.

His Warsaw software agency Upnext has developed BeaconControl. The open source platform includes a suite of software tools which includes:

  • SDKs for iOS and Android
  • An open source Web management tools based on Ruby on Rails (with a RESTful API), and
  • A free mobile app for beacon deployment and set up.

The company is partnering with to provide the first “deep integration” with the physical beacon itself.

This allows developers and organizations to physically configure a Kontakt beacon and have that configuration link to the BeaconControl dashboard.

Why Beacon Management is Needed

When Apple launched support for Bluetooth LE proximity detection through its iBeacon specification (and accompanying iOS developer tools), brands and organizations often struggled to both understand and implement beacons into their mobile experiences:

  • You needed beacons. Most of the beacons on the market came with back-end management systems. Some of those systems were required if you wanted to use that vendor’s beacon. Gimbal was an early example of a beacon company whose back-end system (while rich and robust) was what you were really buying when you bought one of their beacons.
  • You could use third-party management systems. If you chose beacons that didn’t require that you use their management systems you could turn to one of the dozens of start-ups offering proximity management platforms.
  • You could choose to build your own proximity management system. This could be a costly proposition. It came with the added challenge that the technology was relatively new, support for Android was still in its early days, and best practices for user experiences were yet to be established.

With Google announcing more robust support for proximity and beacon detection and putting their weight behind the Physical Web (through the open source Eddystone protocol), the management of beacons has become even more complex.

And while Google itself now offers a degree beacon fleet management services and basic tools for delivering content, a developer or business still needs to think about how their beacon infrastructure will support the end user experience across a myriad of devices – from Android phones to Apple Watch.

Building an Open Source Beacon Management Community

BeaconControl hopes to help accelerate the proximity industry by making its tools available under an open source license, and to encourage developers and engineers to support its development.

Fabisiewicz tells me that developer involvement will help build momentum for BeaconControl:

We have already entered great partnerships with the Silicon Allee campus in Berlin and the NewLab in New York City to develop sustainable, “technology enabled workspaces” based on BeaconControl. We are in talks with various startups and corporations who have expressed interest in BeaconControl. But at the moment we would love to see developers start using the platform and contribute to the movement.

Developers can check out the BeaconControl code on GitHub and contribute to improving the web-side management dashboard.

For the more technically-minded, Fabisiewicz explains the architecture:

The core stack is Ruby on Rails and that’s how it will stay in the future as we deeply believe in Ruby on Rails.

In terms of mobile integration we are already providing iOS SDK and Android SDK is coming soon, so the mobile mobile landscape is currently covered.

Beacon Control is designed with Service Oriented Architecture in mind, so that any technology stack can integrate it and use it through the REST APIs. Depending on community feedback, we will consider developing wrappers in other languages.

What Does It Mean for Businesses?

For organizations looking to deploy beacons, you need more than just a device. You need a way to manage the interactions that go with a beacon.

You can choose a beacon provider who has accompanying dashboard and management tools, but risk vendor lock-in. Or you can work with a “platform” (from Urban Airship to any of the dozens of proximity providers who specialize in the field).

These approaches have pros and cons: from cost efficiency and speed-to-market, to being able to rely on vendors whose sole purpose is often thinking about and developing for proximity.

But if you have the resources, or if you have the need to integrate proximity campaigns into existing systems, developing your own beacon solution has often seemed a viable approach.

Now, you’ll have the option of using an open source library to get your project started.

Developers Unite!

If it can involve a larger group of developers, BeaconControl could potentially become an emerging standard for proximity management.

With a new generation of sensors and beacons on the horizon, this open source approach can give the industry a leg-up on its ability to respond to technical change.

Its founder tells me that:

We are at the very beginning of proximity technology and we think that BeaconControl can evolve into a platform that supports various types of sensors in the future. Currently Mesh beacons are a very interesting technology, they can turn the current generation of location-broadcasting beacons into a two-way, Net-connected network. Generally we think that proximity technology has the potential to change the world, but it will take time and a lot of effort like with mobile payments.

BeaconControl might also be a sign of things to come. As the industry shakes out, more companies may choose to open source parts of their technology in order to focus on other areas: consulting, analytics or infrastructure management.

For Upnext, BeaconControl is the perfect fit for an agency that focuses on innovation and mobile experiences.

As Fabisiewicz tells me, BeaconControl opens up a range of possibilities for his company:

First and foremost, we are aiming to create a community that builds the physical web and the IOT. We are trying to give innovators and technologists a headstart with our platform. We will eventually make money by consulting with companies to integrate BeaconControl into their applications. We are also thinking of marketplace (like an app strore) for BeaconControl where the entire community can distribute their add-ons for BeaconControl and monetize them.

BeaconControl will help to kickstart new forms of innovation in the proximity industry and will attract developers who are inspired by working together to create new standards and best practices. It represents a milestone on the beacon industry and is, perhaps, a sign of things to come.

Share Your Thoughts

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

Is BeaconControl what you were waiting for? How do you think an open source proximity management platform will impact the industry? Will start-ups who sell proprietary solutions need to consider their own open source strategies? Drop a comment below, or pop me a note on Twitter.

Google Loves Apple (In a World of Beacons)


The launch of Eddystone by Google has, at long last, addressed a challenge in creating proximity experiences with beacons. Namely, that the software tools for beacon detection and interaction were less robust for Android development than for Apple devices.

The media narrative, as always, paints the move by Google as a showdown between Eddystone and iBeacon.

Mashable calls Eddystone a rival, Ars Technica announces that iBeacon needs to move over because Eddystone is a fighter, and Tech Republic concludes that it has clear advantages in the showdown with Apple.

Now, you can’t blame the media. It makes good copy.

If Google launched some kind of self-driving toilet paper the media would call it a rival to the iPad, siphoning off valuable screen time from its arch enemy in Cupertino.

And while there’s a broader truth to the Apple v Google narrative (which I’ll get to in a minute), the truth is that the move by Google has made life easier for brands, retailers, developers and device manufacturing companies.

What Your Clients Need to Know

If you work in mobile development you’ll know that the last thing your clients need to hear is that there’s yet more fragmentation – between Android devices, between Apple and Android.

The good news is that, at the simplest level, Google’s announcement of the Eddystone beacon format (and the accompanying development tools) means that we can now create beacon experiences for both Android and Apple devices in a way that assures a higher level of confidences that the experiences will be on par.

Better yet, Eddystone has added a few tricks to how beacons work that will benefit both Apple and Android apps. These tricks include the ability to embed beacon management functions inside your app (instead of needing to rely on some type of admin app or cloud beacon), a promise of increased beacon security, and the ability to link beacons natively to web URLs.

By launching an open specification and leveraging the capacity of beacons to interleave multiple signals, brands, retailers and venues can get the best of both worlds:

  • Android apps that respond as fluidly to beacons as Apple apps
  • Access to new beacon features across both platforms
  • No need to buy new beacons – especially if your hardware provider is one of Google’s preferred manufacturers (and we note that almost all of them are our own!). Just update your firmware and you’re good to go.

There’s No App For That

The second part of the media narrative about Eddystone is its capacity to deliver a URL in place of a unique identifier. The promise is that on Android, you’ll be able to deliver messages without an app.

Part of this promise will be reliant on what Google releases with Android M so it’s too early to judge how deep this promise will go. We’ve long speculated that the secret war horse for Google will be Chrome – a trojan horse on Apple devices that could conceivably contain beacon detection and help Google bypass the gatekeepers in Cupertino.

Regardless, the capability of reaching consumers without an app isn’t confined to Google.

Apple has been using Passbook to trigger beacon interactions and will be extending this through Offers, a new iAd “wrapper” on Apple Wallet. We assume that this will allow brands to target iAds based on location and allow the delivery of Wallet Offers (similar to Apple passes) which embed beacon detection (as previously available).

So while it’s a compelling value proposition – the ability to bypass apps entirely, it’s not confined to Google.

Who Owns The Experience?

It’s when we look beyond the beacon that the Google v Apple narrative starts to make a bit more sense.

Both Apple and Google give you tools to register your “place”. Both want to help you map your indoor location. Both want to provide “contextual experiences” through Siri, Google Now, and search.

And both want to serve ads:

  • Google wants to use all the data it can get to serve better (and more) ads across more platforms (including iOS)
  • Apple wants to generally keep the data anonymous but still wants to make money through its iAd platform.

Apple’s main focus is the user experience, and we can expect to see more and more tools to integrate beacons into payments, Apple Wallet, in-home connectivity, and location-based context. Google’s main focus is giving users better and better free tools and applications but in the larger service of ad revenue.

Neither approach is bad for brands or venues. But each provides strategic pros and cons – from sharing your data about your customers with Google through the lack of access to individual user data on the Apple platform.

But these trade-offs and decisions have nothing to do with the beacon. The choice to integrate that beacon, to make Google aware of its presence, to integrate it with Google Now (with the benefit of “app-less” consumer interactions but with the cost of providing Google data about your customers) are strategic ones.

As a retailer, you’re faced with the same questions you’ve already struggled with: who owns the data about what happens in your store, and are the trade-offs worth it?

But, again, those questions have nothing to do with the base function of the beacon, and are supplemental decisions about how far you want to go with Eddystone.

For now, it’s enough to know that beacons just got better, and users of both Apple and Android devices will benefit from the innovation.

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? Google has clearly done Apple one better with Eddystone. But is it really a “threat”? How will you use Eddystone?

Samsung Makes Its Move: Beacons for Android, No App Required

Samsung will launch the Samsung Placedge Platform at their developer’s conference tomorrow, and with it will cut out the need for a brand to have its own app to detect beacons. Instead, Samsung will provide a sort of uber-application that sits at the device layer, detecting a shared registry of beacons and pushing messages via a shared service.

They also invite developers to create their own apps using the Samsung tools. This makes it possible to both push messages through the Samsung app and reach them again through your own app. The appeal to brands might be irresistible – allowing them to reach consumers who BOTH have AND don’t have an app.

The move by Samsung helps to reinforce that beacons aren’t an Apple-only thing. And it highlights the competition for access to the engagements that happen in place.

Samsung has staked its own territory with Placedge – bypassing the individual retailer or brand app and providing a “uber service app”, giving retailers a full suite of tools to manage campaigns and beacons.

The Placedge website promotes simplicity:

Once the Proximity Service app is installed, dynamic and relevant information and coupons will be pushed to the user’s phone. By leveraging various features provided by the Samsung Proximity Platform, partners can create highly-targeted marketing campaigns to generate more foot traffic and sales.

The platform won’t look dissimilar to the dozens of beacon campaign systems on the market today, from Lighthouse to LocalSocial. But Samsung is taking things a step further by building its own proximity layer and user experience – potentially in conflict with patents held by Apple.

It’s Time for Android

While Bluetooth beacons have become synonymous with the Apple iBeacon brand, the devices are based on the open Bluetooth standard and Android phones with KitKat or higher have been able to detect beacons.

Beacon detection through standards like Radius Networks and its AltBeacon open specification allows app developers to create proximity-based experiences. Deploy a few beacons in your location and both Android and Apple apps can respond to the devices.

But with both platforms you still need an app. And while beacons make proximity experiences possible, they don’t on their own deliver content, coupons or interactions. You still need an app for that, and you usually need a cloud-based content and campaign management system to get it all to work.

There’s No App for That

Samsung has decided to supplement the app layer by building its own. Sitting on the level of the phone, it provides retailers and brands direct access to consumers and provides a suite of campaign, push message and coupon delivery tools.

In other words, the company has decided to try to own a good chunk of the middle layer between the beacon and the consumer…and will give companies like Urban Airship (which has made a big push into beacons, including through a partnership with Gimbal) a run for their money related to push messages.

Samsung is announcing that its doors are open for partnerships:

‘The Samsung Proximity Partnership Program provides an opportunity for partners to configure and deploy an effective location-based marketing campaign. Samsung would like to support you to make a successful story All you need to do is to register to our proximity service partnership program, and then we will provide the full end-to-end solution.  In order to get started, join the Proximity Service’s Web Console with Samsung account. We will verify your account and give you a company code, and you will be ready to go!”

Yet by bypassing the app layer, Samsung is providing brands and developers a way to reach consumers who don’t have your app installed.

They offer developers tools to build on top of this experience, although details remain to be released, with Samsung inviting developers to “Build an app using the Proximity Platform to drive more mobile traffic to your app.”

By building its own infrastructure, Samsung also seems to be making a play for the digital wallet,  setting the stage for a showdown with Apple Pay.

You’ll Still Need a Beacon

Samsung has seemingly announced support for “your own beacons” but highlights four companies on its website. No details have yet been released on the configuration requirements for the beacons – whether they have specific requirements for ad intervals or packets, security layers or other features.

Our personal preference has always been Radius Networks if you want something out of the box and ready-to-roll – their work on Android frameworks has always been light years ahead of the industry.

In fact, the company is immediately launching a Placedge-ready beacon and developer kit – so there’s no need to wait, just jump right in and get started:

The Beacon Developer Kit for Samsung Placedge is an early-access kit featuring a proximity beacon for use in development and testing with the Samsung’s mobile proximity platform. This developer kit contains a pre-configured Bluetooth Smart™ beacons implemented in a tiny USB package that can be powered by any available USB power source.

The Early-Access program provides developers access to hardware proximity beacons that are compatible with the Samsung Placedge platform. Users of the kit should recognize that the features, functions and capabilities of beacons that work with the Samsung Placedge platform are subject to change and likely to change during the Early-Access period.

Apple/Samsung Showdown?

Apple made its earliest bets on developers. Whether they continue to let beacons live ONLY at the app layer remains to be seen. With Apple Pay, it won’t take much for them to create a new device-level layer for beacon-detection and payments and to allow developers and apps to tap into that larger ecosystem.

They also have a strong patent portfolio around retail-driven experiences with beacons, and their decision on whether to exercise that portfolio will be an interesting sign of whether the Apple/Samsung patent wars of years past are truly behind us.

But Samsung has made its bet: forget the app, forget beacon campaign management systems – bypass all that and go direct to the consumer with Samsung. Reach consumers who don’t have your app – and (possibly) then migrate them into your own experience, using the Samsung tools and SDK.

How open the system will be to creating experiences AROUND Placedge, how the beacon notices on the Samsung app layer can trigger engagement with a brand’s own app, and how this will be received in the halls of Cupertino are still to be determined.

We’ll learn more at the Samsung Developer’s Conference and in the weeks ahead.

But for now it’s game on. Welcome to the world of beacons, Samsung. Now let’s see how app developers, beacon management companies….and the consumer respond.

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 of Samsung’s move? How will it play out in the “becosystem”? How will consumers respond to a sort of “uber app” for beacon coupons and messages? Drop a comment below.

iBeacon Alternative: Arduino Beacons and Evothings HTML Studio

Want to create your own beacon? Grab an Arduino and check out the Evothings road map to make it happen. The company demonstrates how to use their Evothings Studio to deliver interactions based on HTML and Javascript to to the end user, whether for iOS or Android.

Using a relaxation/exercise example, the company notes that by creating your own beacon from widely-available Arduino components, you can overcome limitations with the Apple iBeacon specification. They make a strong argument for the approach:

In this tutorial, we will create a mobile app for Android and iOS, that uses an Arduino compatible board with a BLE shield to create a beacon. This can be thought of as a Do-It-Yourself version of Apple’s iBeacon technology – which is proprietary and restricts the way you can scan for beacons.

The reason we are using the Arduino for the beacons is that it can be easily programmed and that it is a cool tinker-friendly piece of technology that you can evolve far beyond the limits of iBeacons. The foundation of the iBeacon technology is the use of a small BLE (Bluetooth Low Energy) device that periodically advertises a UUID (Universally Unique Identifier) – however we will use the BLE name which is accessible across all mobile devices.

Apple has specific criteria for how it broadcasts a Bluetooth LE signal and locks down the ability of developers to, for example, change the advertising packets when using your iPad or iPhone as a beacon (as noted by David Young of Radius Networks in a discussion of AltBeacon).

Using Arduino also helps you bypass a challenge with Android devices. Most can’t broadcast as a beacon device although the capability will be unlocked with Android-L, the latest version of the operating system.

Here’s a video of the demo app and its interaction with an Arduino beacon:

Share Your Thoughts

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

Thanks to Evothings for pinging us about the tutorial. And if you create your own Arduino beacons, let us know about it in the comments below!

iBeacon in the Enterprise

iBeacon will play a role in the office of the future.

The role of mobile in the enterprise has undergone a sea change in the past year or two.

With companies increasingly abandoning hope that they can prevent the “bring your own device” (BYOD) tidal wave, employees are demanding consumer-level quality in enterprise app experiences. If they don’t get it, they’re hacking their own solutions, carrying their own companion phones where they do their ‘real’ work, and bypassing the approval procedures of the IT department.

But this week, we were reminded that the office of the future won’t just see employees choosing their own phones or laptops…we’ll see physical spaces powered by iBeacon and related technologies.

[Disclosure: we’re not strangers to this space and are partners in a platform that uses beacons and facial recognition to authenticate contractors on job sites and contractors and to manage volunteers at large events].

Robin Connects Spaces

We’re big fans of Robin. This week, they secured $1.4 in funding to continue work on enabling the smart office of the future. As TechCrunch reports:

Imagine walking into a room, having it recognize you, then customize itself to your particular preferences. That’s not the future – it’s happening now thanks to an up-and-coming startup called Robin which uses iBeacon and BLE (Bluetooth Low Energy) devices to detect nearby people and things. Designed for use in the workplace, Robin can automate conference room bookings just by you walking into a room. And after you enter, it can also update the screens in the room and the nearby devices, to give you control.

The company is edging towards releasing an SDK for developers which uses RestfulAPI and web sockets to ‘control’ a room. While there’s no date on the release (they’ve been working on it for some time) the tool kit could become a major player in how you get connected devices in the enterprise to ‘talk’ to its users.

Kinvey Launches Authentication

While at first glance it might not seem like it’s connected to beacons, Kinvey has become the leader in providing back-end cloud services for mobile development in the enterprise.

This week, they launched Mobile Identity Connect, which lets enterprises connect their mobile apps to secure sign-in that integrates with identity management systems such as LDAP:

Kinvey’s Mobile Identity Connect is designed specifically with mobile in mind. It presents a client developer with a simple, consistent, OAuth2 authentication flow for all enterprise authentication use cases. Utilizing Kinvey’s AuthLink technology, Kinvey Mobile Connect proxies the authentication to the underlying identity system, and retrieves a token to access enterprise resources. This token is encrypted and temporarily stored in Mobile Identity Connect token store, and an OAuth2 token is generated and returned to the device. Subsequent requests for resources then use the authentication context to securely deliver data and services to mobile devices.

When combined with Kinvey’s support for beacons in the enterprise, the company is positioned to be the go-to resource for many developers.

Brivo Labs

A big player in enterprise and enterprise security, Brivo is also a contender for the connected space. Their developer APIs are robust, integrate beacons, and use ‘social sign-on’ for office environments, sports clubs and other venues.

This week, we were struck by their work with door locks – an unlikely win, perhaps, but if you’ve ever struggled to get into your own office after hours you’ll be able to relate!

Share Your Thoughts

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

What does the office of the future look like? How will beacons play a role? Any projects or tools you think we should share?