16 October 2017 by Ross Maguire

iBeacons at GC HQ

iBeacons at GC HQ

Research suggests that there are many benefits to implementing flexible working patterns within the workplace, including positive changes in staff's health and wellbeing, and increases in productivity. So here at GC, we decided to give it a go!

To be deemed a success there needed to be some metrics with which to analyse and measure any positive changes in production, wellbeing and the popularity of the newly proposed 'flextime'. One way to do this was by using technology to automatically clock members of staff as they enter in and out of the building. But how? We needed to find something that could be easily installed across all current and future offices, scale with the business as the number of employees increases, and have the flexibility to record further information.

Myself and fellow placement student Joel quickly decided on using 'iBeacons'; a bluetooth low energy transmitter, with a custom application written natively for iOS and Android, and a web driven reporting dashboard. We chose iBeacons specifically as they are small discrete devices that can be placed out of sight, have around two years of battery life, and don’t require any installation. We opted for Bluetooth over GPS as it would work inside the building and enable us to see what entrances were most used or high traffic areas within the office space.

Getting Started with iBeacons

We decided on a company called 'Estimote' as our provider for the bluetooth beacons. Through their own SDK and customisable beacons, we found Estimote to be the easiest to implement the technology we required and thus saved us a lot of development time in the process.

We needed to think of a way to use these iBeacons to monitor our newly implemented 'flexitime'. So we decided to develop a single application for both the Android and iOS platform, so that staff could be checked in and out of the office simply by having their phone present.

Creating Our Check-In System

Android Devices - Developed by Ross

For the android application, we began by producing prototypes to test the functionality of seeing a beacon in range using a mobile device’s bluetooth.

Using the throwaway prototype methodology, we were able to create basic apps that would incrementally get better as we would learn new things about the Android Platform / Bluetooth beacons and correct any bugs that we had encountered along the way.

One issue that we encountered consistently in the development process was that the beacon's connection kept dropping, which in turn would flag that the user has checked in and then immediately checked out. This was due to issues with Android and running the monitoring code in the Activity (single screen with a user interface). We fixed this by separating the code from the activity and have it running in a background service so it was able to run independently from the app.

Many attempts and prototypes later, we had produced an application that would find nearby beacons and once a connection was made, data about the time and person (which is used to determine whether it is a check-in or check-out) is sent to a database hosted on a server that is used to pull reports from and produce analytical data about people’s attendance.

This was created using the Java programming language for the Android application, MySQL for the database, and various PHP scripts to act as a medium for communication between the device and the server.

IOS Devices - Developed by Joel

The first decision that had to be made was what version of IOS to develop for. IOS development has a choice of two languages: Objective C, and the more modern, Swift. Whilst swift is easier to develop in due to it being a newer language, after discussing it with some of the team we decided to build in Objective C. This decision enabled the app to be available to more versions of IOS, and we wanted to ensure that everybody could install and use the app irrespective of what phone they had.

By going down this path it meant that we had to learn a whole new coding language. However after a few short days of training we were able to come up with prototypes of apps, that we slowly built up until we had a very basic version of our app. Using this throwaway prototyping method allowed us to learn whilst developing, build our knowledge on what worked and what didn’t.

At the end of our prototyping stage we had an app that could find nearby bluetooth beacons and notify the user when they came in range of one. We used this as a foundation to build more features; login screens, database connection, background connectivity and many more. And, after a few weeks of development we had all the features we deemed necessary to create a working system.



Reporting Dashboard:

Our data from the iBeacons are collated in the Reporting Dashboard. This website is used to produce reports based on the data inputted from the employee’s check-ins and check-outs.

The dashboard also has the functionality to add new users to the application which is essential for new employees starting. It is also possible for other members of staff to pull reports if necessary from this data; Project Managers for example.

Lessons Learnt

The system is currently functional and being used by GC members of staff, and is continuously being improved to make the experience better, and produce more valuable and precise data. Perhaps we could use it to implement real-time analytics to produce live heat maps of which meeting rooms are used. Or we could use the data to manage our projects more efficiently and be able to allocate the resources as and when they are needed. The possibilities are endless - which we will keep exploring as our placement year at Greenwood Campbell unfolds!

Share