A Moving Target: Location, Location, Location
It’s a founding principle of Picnic to not only build something that’s functional, but something that is an authentically cool and enjoyable product for our users. With this in mind, the foremost idea gleaned from last year’s early brainstorming sessions was to enable the user to see a live map view of their groceries being delivered, all the way to their front door.
The humble map has always been popular in visual media, and further options for customisation using Google Maps API has opened up a world of opportunity — quite literally. This has helped developers offer everything from zombie outbreak simulators to crime hotspot mapping in London, to real-time global flight movements. And that’s just the tip of the iceberg.
We’d already experienced superb real-time map features in apps like Uber, so it seemed a no-brainer to make a similar element available to our app users.
This seems nice and simple to implement, right? Our electric vehicles were already GPS-enabled, which meant that we just needed to drag-and-drop a map view into the apps, hook it up to our backend, receive the vehicle’s real-time location updates, and render a nifty Picnic truck icon on the map. Done! Beer Time! Boy, we were so wrong.
A reality check
This implementation certainly sounded feasible from a technical perspective. Unfortunately, the output was a billion miles away from aesthetically enjoyable, let alone something practically useful or valuable to our users.
We were expecting greatness. Instead, we got a truck that teleported itself to different places on the map, at random intervals. Just like the Tardis, but without Dr. Who or the time-travel adventures. The one major goal we had in mind was to make this map smooth and user-friendly. Clearly, this wasn’t going to be achieved with our initial approach.
What next?
This forced us back to the drawing board, and to rethink the map feature from scratch. The process of doing this taught us many key lessons.
Firstly, we realised that when dealing with external systems, there are some components over which you have no control. In our case, the first rock we hit was that the location update intervals from the trucks were hard-programmed to send every 10 seconds, regardless of network conditions. This immediately shattered our hopes of showing a smooth-moving truck on the user’s screen by simply plotting the available GPS data.
This took us along to the second issue, which was that GPS coordinates are not quite as reliable as one would hope. Unfortunately this meant that sometimes we’d get accurate GPS coordinates, and at other times the map would suggest that our truck was on top of a house, swimming in a canal or lake, or walking a dog in the park.
A change in mindset
With these freshly-discovered technical limitations in mind, we diverted our attention away from the engineering mindset, and considered why this feature would be useful to a user in the first place. Other than it being cool and innovative, does it actually solve a problem for them?
By gaining this new perspective, we realised that its true value lied during the final moments of the grocery delivery. The last few minutes before the truck arrives at the user’s home is when people want to know when it’ll appear around the corner.
This encouraged us to approach the implementation not from the location side, but from the timing side (i.e. the customer’s ETA). In focusing on measuring the final delivery moment correctly, we opened up a world of alternative solutions rather than simply to display the live GPS positions on a map.
The devil in the detail
This is all very interesting, but how is it related to application development? Well, in order to understand the solution we implemented, it’s advisable to review how our delivery logistics work.
Every day, we calculate ahead of time the exact route planned for each vehicle, together with its estimated time of arrival for each stop along the route. The precision window is approximately 20 minutes.
When the vehicle leaves the Picnic warehouse, it immediately starts to report its GPS location. This sticks to the 10 second interval, which was mentioned earlier. Based on that location, in combination with the orders that it delivers on the way, our backend fine-tunes each subsequent user’s individual ETA.
At the final leg of the user’s journey, when they are next in-line for a grocery delivery, we get much more precise about ETA information.
Applying the information
As a result of the above, we already knew the exact route of the vehicle. We also knew — albeit somewhat unreliably — the location of the vehicle along that route. Furthermore, we knew the exact times that different orders on the same route had been delivered.
The question was whether we could use this information to sidestep our technical limitations, and demonstrate a seamlessly smooth truck floating across the map towards our users’ front doors, in real-time. Was it possible? I think you can guess what’s next.
Implementation
Our implementation works much the same way. When a delivery starts, the apps are provided with the planned delivery route, and thereafter will automatically move the truck icon on the user’s map. This is based on the initial ETA to each user’s home.
As time goes by, the GPS coordinates come into play. Deliveries are made. Eventually, our initial planned scenario deviates very slightly from reality. This data is fed back to the application, which responds by altering the speed of the truck on the map. The truck icon moves faster or slower, providing it with the chance to catch-up or back-up to the truck’s real location.
In one fell swoop, we’ve removed the issue of the “Tardis” truck jumping from one position to the other across the map. The problems caused by inconsistencies and loss of GPS data are negated, and we were able to offer a consistently smooth and uninterrupted live map feed for Picnic’s app users.
After a few dead-ends, some trial and error, and dash of fine-tuning, we settled for this implementation. It offered the correct balance between business requirements, customer needs, and what was technically possible within our current setup.
In summary
Well, what have we learned? For starters, we know that displaying live feeds of a moving object in the wild is quite simple, but ensuring that it doesn’t completely suck under edge conditions is way more difficult!
Eventually, the most important discovery was that this feature — which we’d initially planned as a nice-to-have — became one of the most valued features for our users. In truth, apart from viewing the map and truck, seeing the ETA, and some details about the driver, the functionality of the map screen is very limited to the user.
Amazingly however, the level of engagement is extremely high. Users are spending on average over 3.5 minutes viewing the map. It’s a feature they now rely on, especially when they juggle receiving deliveries with their daily routines.
There’s still a lot that we can improve. We’re currently working on enhancing our ETA accuracy by improving the route algorithms. This will make them more dynamic by taking into account weather conditions, time-of-day, individual driver patterns, the types of houses and streets, and much more. As always, yet more fine-tuning is required!
