As engineers we want life to be easier than breathing. We want apps to replace unnecessary (random) human interactions bots to replace assistants even swiping left or right over the awkward effort of initiating contact the 90’s way. Usually these thoughts find little resonance with the ‘others’ but here’s a use case where we finally felt accepted understood at one at last with those who think Calculus was primarily a Tintin character.
Every other evening we’re out for drinks or a movie or some other shindig. More often than not one person in the group reaches the venue first and then either waits around thinking about the cosmos or for the more frantic kind starts calling everyone else with the usual questions “where are you at?” “how long are you going to take?” and so on. This is usually frustrating for both parties – the one that needs to chill and the one that needs to be more punctual.
So we figured if we could let our friends know whenever we are on our way and all of us who are in for the plan that evening can see each other on a map that would be cool right? The challenge with this use case is that users haven’t really accepted the somewhat creepy ‘Nearby Friends’ or the always-on Latitude (RIP). If users were to adopt this behavior understanding their context would be critical. This is when the echo team had a voila moment. Users on echo were already doing –
- making plans with their friends to meet at a place of their liking
- all the friends in the plan were automatically added to a ‘messaging group’
- these ad-hoc groups were tagged with a tentative time and date
Problem solved! So we thought. As it turned out for a typical plan we had 4-5 people coming from different parts of the city. It wasn’t simply a matter of sharing one’s location like we would on whatsapp or some such platform. We also needed to:
- poll a user’s location refresh every few seconds share it to a common database so other users can access it.
- calculate the eta and save that in the database (for i < n i = 0 i++)
- fetch the location and eta info from the database and post it to eligible users
In addition to this we also wanted to show each user in the plan on a map give users full control in case they wanted to stop transmitting factor in connection issues end the trip once the user is at the destination and a thousand other things without which the feature set just did not make sense.
Simply put as an early-stage 2 person startup time is our most valuable resource. We never had the bandwidth for a science project in order to develop a feature we really wanted in the product.
Along came HyperTrack – known to us since it was founded by two seniors from IIT Bombay (heya insti folks!). HyperTrack was servicing the logistics arms of consumer-focused business giving them the means to provide their end-users an Uber-like experience.
They had SDKs for Android iOS for a business’s driver and consumer apps. A delivery professional could easily start a trip in his driver app and the consumer at the other end could see in real time the driver’s ETA and location as he arrives at the drop point. If you ignore the terms for a minute it was apparent how this could easily fit into echo’s use case. Once someone is on the move going to their chosen destination they could theoretically transmit via the driver SDK. At the same time her friends could receive via the consumer SDK. Of course these folks in the plan would all be ‘drivers’ and ‘consumers’ at the same time and we already know who is eligible to ‘consume’ what.
When we proposed this to the HT team they were excited by the prospect of extending their architecture to support the multiple user tracking case. In just a little over a week HyperTrack came back to us with revised SDKs that would support our use case.
Neat documentation their python library that we set up in 1 day SDK integration in 1 day and figuring our own sh*t out in 4 days later we had the feature set ready to test in our staging environment.
We registered our users as drivers and consumers on sign up. echo also triggers a push notification at a fixed interval before your plan is due to start. Celery came in handy for task scheduling. The push notification allows the user to easily start their trip – a delivery task of sorts – which is then shared with appropriate friends.
On the other side(s) the friends’ consumer SDKs take the list of tasks assigned to them shows the current location and ETA of every task being fed in on the map and updates it in real-time.
There are straightforward methods for starting completing and tracking tasks. The map provided in the SDK is highly customizable; we can simply override methods to change the UI of map its markers and other UI elements associated.
In conclusion a feature we really *really *wanted in echo was built only because of HyperTrack and for this they shall have our undying love.
echo is currently in a private beta and if you would like to give it a spin shoot us an email at ss@echoplans.com
Keep up with us on Twitter @echoplans
