Back in April I remember reading an article by Dave Evans over at techcrunch titled ‘We need to get the Internet of Things Right’ that really struck a chord with me. In a weird way Dave seemed to be reading my mind, and the kind of thought process that’s been guiding what we’re trying to do with our own Peakkin project. At the time we were still keeping our work under wraps, but I’ve been meaning to write my thoughts on that article ever since I first read it.

Dave’s basic argument is that as more and more devices become ‘connected’, we’re doing mistakes by moving to a paradigm where each device requires its own app in order to function. Today we have sensors in our buildings, our household appliances, our clothes – you name it; but each of these devices makes the data that it collects available to a single app, to be used for its own particular purpose. We are building small, isolated networks of connected devices that collect and capture data; but which then limit the usefulness of this data by making it accessible only for the limited functionality of a single app.

Dave gives the example of how he saw a ‘connected toothbrush’ in a conference, that was able to capture information about the length of time a child brushes its teeth, and send this data to a dedicated application that allows the family members to compare brushing times between each other. A nice gimmick, but questionable as to whether it would justify the much higher price of a toothbrush for a parent.

Imagine Dave asks us, if the toothbrush was connected to a wider network to which it would share data, and which could be accessed by multiple nodes in the network. Sensors in the toothbrush could collect medical information from the person’s mouth, and send it to the web. From there it could be available to any range of individual applications and services to which the individual could subscribe to, that could analyze this data and evaluate possible medical issues. If any issues are found this could be communicated to the family doctor, and based on the data communicated to the doctor, an alert then sent automatically to the family. The toothbrush no longer collects data for a simple gimmicky app – it collects data that is accessible by a range of potential solutions all communicating to each other, and which can find different ways to make use of it.

Networks become powerful when the number of connections they make increase, and when membership to the network and the data in it can provide something of value to all its members. Imagine if we did not have the internet, but we instead connected computers together into millions upon millions of much smaller, independent networks, each connecting machines together in a tiny geography, and for specialised purposes. What if we had a tiny ‘New York medical internet’ connecting computers in New York for the sole purpose of sharing medical information, a ‘London restaurant internet’, and a ‘Paris publishing internet’… with each of these only working with its own dedicated browser. It sounds crazy right? Yet that seems to be what we want to do with the Internet of Things.

How does this all relate to what we’re trying to do with Peakkin you may ask? What we want to solve is a similar issue of segmentation into ‘silo’ networks, brought about by a different, but related technology: beacons. Think of beacons as small, inexpensive devices, that broadcast short range signals that can be picked up by devices like phones and tablets, and which trigger some form of activity on the device. The metaphor typically used is that of the lighthouse: a device that constantly communicates its presence to other devices around it.

If sensors are devices that collect information ‘in’, beacons are devices that communicate information ‘out’. Beacons have a large number of intrinsic advantages. They are extremely cheap. They are extremely energy efficient, lasting for years on a simple coin battery. They work equally well indoors and outdoors. They are small and discrete, so do not create a visual distraction to people close to them. Their broadcasts can be ‘monitored for’ by a phone even when it is otherwise sleeping, notifying a user when in range of a specific broadcast. Ever since beacon technology came about, beacons and the technology and protocols surrounding them (Low Energy Bluetooth, ibeacon, altBeacon, Eddystone, etc.) have been touted as bringing about a revolution for proximity based communication. The typical example given is how beacons can be used for proximity-based marketing: imagine we are told, walking near a dress next to a store, and our phone letting us know that there’s a special offer available, while directing us to a page from where we can order the dress in our size to arrive at home.

A report by Business Insider has called beacons the most important retail technology since the mobile credit card reader, and predicts billions in sales to be affected by the technology. And yet the technology has still not taken off, even as the hardware becomes ever more widely available. We think the reason for this is the segmentation and silo-thinking that the technology encourages.

You see, the way beacons work is by constantly broadcasting out the same tiny data packet every few milliseconds. As a simplification, imagine a lighthouse that keeps beaming the number ‘251’ out again and again, and again. ‘251’ on its own doesn’t mean anything. An application is always needed installed on a user’s phone, that knows, “When I see ‘251’, this is what needs to happen on the user’s phone”. The way the industry works right now, if you want to somehow use beacon technology for proximity based communication, you either need to build your own app, or find a specialised app that somehow uses beacons in a way that fits your purposes.

What we end up is with a similar scenario to what Dave describes. We build isolated ‘networks’ of beacons, that are only useful when partnered with specific applications that typically use them for no more than gimmicky functionality. We have apps that give ‘points’ when you walk inside a very specific department store, and apps that will let you know about the seat availability of very specific restaurants, but which use the technology no further than the very limited use cases each app is designed for.

If I’m an end user interested in instant ‘micro-blogging’ communication, I’m not forced to download a different version of Twitter from every vendor, and for every possible scenario in which I might be interested to communicate. Yet when it comes to proximity-based communication, we expect that it’s realistic to segment the market into thousands of apps, each only useful in a specific geography, for a specific type of use.

This segmentation has proven a huge challenge towards making this technology reach its full potential. Google has made an attempt to resolve this with its ‘Physical Web’ initiative: a protocol that allows beacon devices to communicate a web URL rather than a random data packet, that can be read natively by the operating system on a device, without the need of an independent app. The way google sells the concept is, you should be able to walk up to a vending machine, and be directed to a website online associated with it with just a single tap on your phone.

It’s an interesting idea, but one that still doesn’t solve the riddle of how to best manage proximity-based communication. You may not need to build an app to communicate, but now you need to build a website, and need to be able to update it whenever you need to broadcast something different. Communication remains one-way, unless you also build a separate response mechanism within whatever web location you are directing users to. But perhaps most importantly, there is no way for a device to accurately filter such URLs in the background, and notify users when next to something of interest. URLs are presented simply as a list of context-less links, whenever the user chooses to go to their notifications area. This removes one of the most attractive benefits of the technology: the ‘nice surprise’ factor of being notified that you are next to something that interests you as your phone passive monitors in the background.

The hardware that makes proximity-based communication possible is all around us. Not only are beacons dirt cheap to buy, what a lot of people don’t know is that modern phones are both able to receive as well as broadcast this form of signal – so most of us already have a beacon in our phones without even knowing it. Just this simple feature could bring about about hundreds of possibilities for social communication with the people around us, yet nobody has ever taken advantage of it. Instead we maintain a huge software barrier that makes this technology and its vast capabilities unapproachable to most potential users.

Communication is an activity with an intrinsic social effect. The more people we are able to communicate with on a platform, the greater the value of that platform to us. The technology that powers the platform should be invisible to the user. Unfortunately we seem to have missed this point, with most developers seeing beacons as only the means to add ultra-specialised location-based features into their own niche-applications.

When we first heard about beacons years ago now, we became obsessed with how to bring the potential of proximity based communication to the masses, through one, single, simple to use, unified application. That was how the concept for Peakkin was born – one application, and one platform, whose aim is to allow ‘anybody’, to communicate ‘anything’, from ‘any’ number of beacons (or from a phone acting as a beacon), in ‘any’ location; while at the same time allowing the user to set their own precise filters, that determine what the user wants their phone to be monitoring for in the background.

With Peakkin we’re trying to do 4 things:

  • To facilitate proximity-based communication of ‘any’ content, without limiting the user’s potential use cases, and from any number of beacons or broadcasting devices. Whether it’s a simple text message, a web link, a file attachment, a piece of HTML that renders to a custom design, the user should be able to broadcast it.
  • To allow the user to have precise control of filters that determine the broadcasts to monitor for. Peakkin should not be just a broadcasting application – it should be a user’s 24/7 discovery tool that informs them whenever they are close to a broadcast containing content that matches their interests, but ignores anything else around the user that would not interest them.
  • To make all this available in a single app, so users have just one thing to download on their phone – but also provide the tools so that broadcasts set up through this platform, can also be made visible within existing applications.
  • To build something that’s extremely simple to use, that lets people both send, as well as receive broadcasts, and allows them to communicate back and forth with each other. Peakkin should not just be an ‘ad-reader’ for the broadcasts of commercial locations around us. I should be able to use it to broadcast out my presentation files in a conference, my thoughts about the game to the people around me in the football stadium, or my profile to the individuals looking for a relationship in the nightclub I’m going out to; just as a department store can use it to set up hundreds of beacons broadcasting out its special offers within its floor-space.

Are we there yet? Of course not. Our prototype is an oversimplified version that is far from meeting these goals, and is really no more than a showcase of a concept. But we’re getting there, and perhaps faster than one might think.