“We are like dwarfs sitting on the shoulders of giants. We see more, and things that are more distant, than they did, not because our sight is superior or because we are taller than they, but because they raise us up, and by their great stature add to ours.” – John of Salisbury, Metalogicon, circa 1159
The next generation of location-based services uses live location to make assignments, track orders, track miles, personalize experiences and power great product experiences. A fleeting glimpse by product managers and developers might lead to a false view that maps platforms are sufficient to build these features. This post covers what maps do and don’t.
Say you want to build an in-app tracking view of an order. It needs to be a smooth experience (think animated icons) with accurate location (route polylines maybe), live ETA (that updates every minute), user/order information (a drawer to reference) and trip status (why is it stuck there). To build this, what can developers count on maps for and not? Read on for the answers.
Developers build live location features in their product because it is core to their business. In the process, they end up having to build infrastructure. Developers who have built and operated this underlying infrastructure on their own have a deeper experience of the pains involved. Often, this is the first time they start questioning if that part of the stack is core to their business and if there is an API for that. In the chance that they find HyperTrack as that API they were dreaming of, a new problem arises.
In many in-house location stacks, the de facto interface at which the infrastructure stops and the feature begins is the location stream. You generate the location stream on the device, log/store it on the server, and then consume it in the product. For enterprises using vehicle tracking systems (VTS) and GPS chips, there is a legacy reason to go down this path. When other teams and software modules in the stack are consuming this stream, it is hard to imagine ripping it out and replacing it with HyperTrack SDKs and APIs.
And then begins: “But it does solve a bunch of things we are dealing with”, “Hey they seem obsessed with it and we are not, they must know something we don’t”, “Let’s deploy it on that new feature or new set of users in that new project”, “Let’s run this in parallel with our stack and compare the results before phasing it in”, etc.
It is then that one of the two questions comes up:
- “Can we provide our location stream as input to your API and get your location stream as output?”
- “Can we use your location stream as input to our API and everything upstream will start working better?”
Tl;dr – Bad idea. Using location streams as the interface is architecture debt. Pay it off.
New hires at HyperTrack usually impress the team with the code they check in on day-one. Aman raised a few more eyebrows on his first day when he caught a bullet of a shot during the evening cricket ritual at the office. He swerved like Neo in Matrix, though instead of dodging the bullet, he ended up singlehandedly snatching it out of thin air.
On Mar 22, Google announced that users of Google Maps can share their trips and real-time location with friends when on the way. Then on Mar 27, Facebook announced that users of Facebook Messenger can share their live location with friends to make meeting up easier and safer. The news from Google and Facebook comes hot on the heels of the Feb 3 news story that Whatsapp has been testing real-time location sharing. Apple has had Find My Friends app packaged into iOS 9 and later since September 2015 so iPhone users can share live location with their friends.
In six months of being live in public Beta, we have been amazed by the number of industries, countries and use cases for which developers want to build dynamic location-based services. We have learnt a lot from their usage and continue to evolve the HyperTrack platform to be useful to them. We find companies of all sizes rolling out apps for their internal users and customers, and they seem to have a natural desire to build features that require a continuous understanding of their users’ location. This needs to be achieved with high accuracy, low latency, efficient battery consumption and managed costs of 3rd party web services. The current location-based services of the smartphone Operating Systems fall short and developers end up having to build and operate a bunch of infrastructure to power such features. HyperTrack exists to solve this problem.
Over the past year, we have interacted with thousands of developers from over 30 countries and as many industries. These conversations have helped us understand the use cases that compel developers to build location tracking features into their products. Turns out, they are forced to build and operate complex location tracking infrastructure to make the features work.
HyperTrack APIs have been built to enable these use cases such that developers can focus on features that are core to their business and not have to worry about the infrastructure. In the previous post, we drew a distinction between location tracking features and infrastructure, and proposed a better primitive to solve the problem. In this post, we walk through the HyperTrack API framework and how the building blocks work for your use case.