Like most development teams, the Technology group at Engine Digital is an ambitious bunch. We drool over new technologies, scour the Internet for the latest web trends, and high five each other after successfully decoding the framework of the week.
This world we live in resembles a dog’s life – 1 human year equals 7 in the digital world, or something like that. We trek through a competitive landscape where every day the learning curve grows steeper. Like Johnny 5, we need more input–we strive to learn it all.
So how do we stay afloat? How do we stay relevant? How do we keep things interesting? We buy things. Whether it’s the latest Kinect, or the newest Arduino Kit, or even the colourful Google Cardboard–we buy it all up. We feel giddy inside when the shiny new packages arrive. Full of ambition we tear them open and dream big.
But after a while, the dust gathers. We gaze past our monitor full of client work, lower lip slightly pouting, and make eye contact with that untouched piece of tech. We find ourselves saying things like “If I can close a few more tickets I might carve out enough time to get that LED blinking.” Or, “I just need some time to deploy a quick prototype to see if that Beacon actually works”. And all of a sudden after a few months of solid work, the clouds clear, the sun comes out, and our Tech Lead says, “Today we dust off our table of tech toys and create.”
Got a problem? Yo I'll solve it.
Engine Digital is a busy place. We use several tools to manage various parts of our process. One of our biggest challenges is manning the physical environment. Meetings can often run late, and sometimes it isn't clear which rooms are available for impromptu planning sessions, conversations, or conference calls. We needed a way to monitor each room and communicate its availability with the team. So we set out to prototype a notification system that allows anyone in the office to see how many people are in each of our meeting rooms in real-time.
Detecting proximity and triggering a response.
When it comes to location tracking within a given environment, Beacons answer the call. After some research we discovered Estimote; a company that produces small, colourful Beacons that can be positioned in any location or to any object to create new, contextually rich mobile experiences. They emit a radio signal that can communicate with a Bluetooth enabled device. Fortunately for us, the Beacons are sold in a 3 pack, just enough to cover off the key locations within our office–the Boardroom, the Lounge, and the Kitchen
Additionally, the company has created a nifty iOS app to interact with their Beacons. In our case, we were able to access each Beacon and adjust its name and signal radius. Our goal was to prevent any signal overlap to make each room as accurate as possible. During our development we tested several different ranges and concluded that a 15ft radius provided the best accuracy. Increasing the range too much on a Beacon can decrease the battery life and cause overlapping signals, so we needed to be modest with our settings.
Someone's in the Lounge, now what?
In order for a Beacon to add value, it must be capable of communicating with another Bluetooth enabled device. When a device enters or exits a Beacon's radius it can respond accordingly. Fortunately for us most people in our office carry mobile devices equipped with Bluetooth. However, a device on its own has no capability of triggering a response when in a given range. The only way for a device to interact with an Estimote Beacon is through a native application. While a native app can seem quite daunting to produce, there are a great deal of tools that encourage rapid development. Enter Cordova.
But wait, how do we use Cordova's APIs to communicate with Estimote's Beacons? Thankfully we stumbled upon the Estimote Cordova plugin. Once more, using Cordova's simple command line, the plugin was installed and ready to use in under a minute. Perfect.
Hold on, doesn't your app need a design?
When rapidly prototyping, the interface design isn't always a priority. This doesn't mean design isn't important, of course it is. But oftentimes we hope to test a theory, or some new functionality and we simply don't want to be delayed by crafting a market-ready UI at this stage in the process. In our case we hoped to piece our project together in a hurry–in under a week in fact.
Our application required two screens; one that would allow a user to sign in by entering a simple username and another that would list each room and identify the users who occupied them. For such a simple application, a few conventional UI elements and animations would do the trick. For this, we decided to use the Ionic Framework.
One thing to note, however, when using the Ionic server–you should not expect your application to work correctly in a desktop browser. While testing the UI it worked perfectly, but plugins and native application features should always be tested on an actual mobile device.
Everybody else is Arduino'ing, so why can't we?
We had some Beacons talking to our native app and we had some users logged into the app–a great start. But there was still another tool in the ole tool belt – our Arduino kit. By using the LED panel we were able to build a simple heads up display that would now show each room's occupancy count in real-time.
To communicate with the Arduino it required us to hardwire the device to a computer using a USB serial port. We then created a Node.js app that could listen to incoming connections using Socket.IO. Now, when anyone enters a room, the Beacon sends a signal to the mobile device, the mobile device communicates with the Node server through Socket.IO, and a message is sent through the USB port to the Arduino. This message is translated into register signals using Arduino's native language Sketch. The service also broadcasts the room counts back to every app that is listening and updates their interface. And voila, just like that, our real-time connected experience prototype is complete.
Our app worked great for a prototype. We demoed it on a Friday evening for the full team to participate. While it might not be a polished product, and definitely not ready for the App Store, we were able to solve a minor business challenge through rapid prototyping and trial and error. Eventually we'd like to deploy to Android devices, but of course, different devices have difference nuances. More trial and error is likely on the horizon and there are still some kinks to iron out. But with any great challenge comes an opportunity to learn.
Back End Developer
Front End Developer
Front End Developer