Authors: Calvin Ng, Developer and Merry Chen, UX Designer
We’ve talked about what geofencing is in a previous blog post, but how does it all work under the hood?
As it turns out, geofencing is not as daunting to implement as it first appears. As in many cases, Googles web APIs provides much of what is needed to hit the ground running. The Geolocation API, introduced as a part of the HTML5 standard, allows us to determine the location of any device with an internet browser using a combination of GPS, WiFi access points, cell towers and other common sources. Googles Geocoding API simplifies the process of converting the street address of a location to latitude and longitude coordinates. Finally, the ubiquitous Google Maps API enables us to beautifully visualize our information and provides a great navigational tool for users. Now that we have all our tools, let’s put it all together.
Where are we again?
Geofencing is all about keeping track of where your employees are, and if they are in the correct location. As such, the most crucial piece of information is the users’ current position. This is provided by the Geolocation API widely available on all modern browsers. The “Get Current Position” function will retrieve your current position and the “Watch Position” function allows you to specify a handler function to be called whenever your position changes. Both these functions return an object that stores the users’ position and accuracy.
The position object is just a set of latitude and longitude values, and the accuracy gives us a tangible measure of the confidence that the reported position is your true position. This is represented by a circle of which your position is the center and accuracy is the radius. Basically, the browser is saying that it is 95% confident that your true position lies somewhere inside this circle.
Are we there yet?
So, how can we tell if someone is actually within a given location if there is a large inaccuracy? One strategy could be to use a small accuracy threshold, this would be some minimum requirement the users’ device must meet before we can say anything about their position. Once met, we simply assume the reported position is the real position. If, on the other hand, accuracy doesn’t matter as much to you, you could employ a “good enough” strategy, setting a larger accuracy threshold and calculating if there is an intersection between your accuracy circle and your destination.
Once you know where you are, calculating the distance to your destination is as simple as a call to Google’s Geometry Library within the Google Maps API. Alternatively, if you don’t want to use the GMaps API, you could consider manually calculating the distance on a spheroid with the Haversine formula.
Where’s the map?
We’ve talked a bit about the internal logic of geofencing, but arguably the most important part is what is actually presented to the user.
1) Placed UI in correct context.
In the following image, the map pin is red and has a question mark icon to indicate that the device’s accuracy is not available. And the geo-fence perimeter is red and dotted to indicate that the system cannot locate you.
In the following image, the worker’s current location is indicated by the red pin with an X icon. And the geo-fence perimeter is red and dotted to indicate that he is not within the designated area to check in.
In the following image, when the worker is within the designated area to check in and their device’s accuracy is acceptable, the map pin turns green and the geo-fence perimeter has a solid green border.
2) Revised our error messages.
Instead of describing the error in great detail, we focused on error resolution by providing the user with a clear and concise action.
3) Include visual indicators.
By using visual elements, we are able to make the warnings more meaningful and understandable. The user can see where he is on the map, for checking into shifts.