Vehicle Live Location
Production screen recordings
Dark mode
1. Intro
One of the most special tasks I was tasked with was designing the feature for the “vehicle live location” on the map.
The design process may seem straightforward, but the cases in which things may not go according to plan are numerous.
Therefore we strived for an experience that will feel as natural as possible even when things don’t go as planned.
2. What problem are we solving?
One of the main pain points of users who use public transportation is the “lack of control”, this feeling is being felt especially during the waiting times of which users need to wait passively for their line to arrive at the station.
In extreme cases this can provoke feelings of anxiety and helplessness, depending on public transport reliability.
Therefore we sought to alleviate this pain by providing a sense of control and enabling our users to track their line in real time, see its progress on the map and eventually feel in control.
3. Goal
The goal was to provide real time tracking for lines on the map, viewing their progress will provide a sense of control and alleviate the pain of anxiety by passively waiting, not knowing if the line will or will not arrive.
This was a straightforward goal, but the way to get there was not.
First, one requirement was that this feature needed to be a “global” feature and not be limited to a screen specific screen.
In the Moovit app we have multiple screens that provide a map according to context, in addition the development costs to develop the feature for each screen were significantly higher than developing the feature as its own screen.
Each screen solves a different pain depending on context, therefore the solution to add the “line live location” for each screen that contains a map was not sufficient.
This constraint was eventually one of the advantages of the feature. I specifically decided to use the native “iOS Modal Stack” component (on Android we developed a similar custom mechanism), for it provides an additional layer when opened, but doesn’t take the user out of context entirely.
This provided an initial workspace to work with on the feature itself.
4. Impact
By providing the real time tracking and progress of lines, addressing the negative feelings that can be felt by users, we will gain users’ trust, add to their sense of control, keep our users engaged with the app and in the long term improve their retention and satisfaction with the Moovit app.
Business wise this was an immense opportunity for Moovit to also keep users engaged and add to ad-impression and ad-revenue, all while providing real value to users.
4. What do our competitors do
Google maps
Google maps provides the option to see lines on the map, but only a handful of the upcoming lines. Overall they do a good job, but it’s hard to navigate between the multiple line options and it’s not obvious which line is operated by which operator, and requires a tap for that.
In addition, multiple lines are hard to distinguish because of overlap in routes and operator colors.
Transit
Transit also does a good job, but the main problem is that the app only shows a specific line, and not multiple lines. In addition, it’s impossible to view line-live-locations for a specific station, and no additional data is provided.
Citymapper
Cityampper only shows the live location of one line only one the “line page”.
After reviewing current solutions of our competitors, we've concluded that a "global" feature that will be accessible from multiple locations in the app is the superior approach in Moovit's case, as it will be recognizable globally, the feature will behave the same regardless of where the user opened it therefore simplifying its learnability and interaction.
5. Discovery process
Challenges ahead
Delayed GPS updates
Live location data is being refreshed every 10-30 seconds, depending on operator and country.
But the data we receive is not as accurate as can be because of signal latency. This happens because the GPS update from the line (bus / tram / train etc) has to be transmitted first to the operator, and after that to us. In some countries / cities the data may go through a governmental operation (to keep data monitored) - this latency is something we need to address.
GPS fluctuations and signal loss
Lines might not be transmitting, they might go in tunnels or underground, they might drive inside densely built cities in which the GPS signal can have hard time transmitting. Expected signal losses had to be taken into account.
No GPS data
Not all lines have GPS signal. Some only have the real-time data and no GPS signal. This means we cannot know for certain where the line is, only the data of arrival times.
Data overload
For popular stations in which numerous lines stop at, there might be too much data that can be presented.
GPS data transmission latency:
6. Mapping the data
To understand how to provide the optimal experience, we first need to understand the data we are working with.
Making the connections:
In order to show "live location" for a line, we first needed to add an anchor for the line itself. This anchor was the station. Using a station as an anchor meant there's more context to the line live location, for example, when the line will arrive, how many stations left etc.
Structure example:
1. Azrielly station (for example)
a. lines 1, 601, 51, 82...
i. Line 1 arrives in 2 min
ii. Line 601 arrives in 5 min
iii. Line 1 arrives in 7 min
iiii. etc
Because the lines were a subset of the station, the main question was how do we structure the data? Categorizing each line on its own was one of the first ideas.
This means that for a specific station, the user can only see the specific line he / she wants. The downside of it was that it’s only 1 line, but there can be multiple lines that are relevant for the user. In addition this means an additional “layer” of navigation for the user, which is something we wanted to avoid.
Also, in the roadmap for the feature was filtering options in the future which would address this issue.
Therefore I've decided not to go with this approach but with a more “flat” approach, and not give an additional layer of “line selection”, but instead to show all the lines in a sequence from the most upcoming to the latest one.
Initial testing:
From prototype testing it showed that providing an additional "selection" of specific line was not a good idea. It added to the visual noise and took too much space, added to cognitive load (choosing from 1-3 options was a minor task but selecting from 10+ line options which might happen in popular stations was a much harder task)
7. Line states with corresponding cards
Initially, the idea for the line information was to provide a “tooltip” bubble for the selected line with an additional data, the problem with it was that it meant the interaction itself can only be done using the map, this can be challenging for some users (zooming in/ out/ losing orientation etc.) in addition development costs for it were also higher therefore in order to present the user additional information for the selected line, we’ve decided to utilize a card that will hold the relevant data for each the line on the map.
The data in the card will be:
1. Relevant line
2. Time of arrival
3. Last GPS update
4. Number of stations remaining until arrival
The idea was to place the cards at the bottom of the screen. This had the advantage of being close to the thumb-zone, users could reach it easily, also as the information was an additional to the location on the map, it was optimal for it to be at in the periphery of sight and not taking too much attention in the center of the screen which where the “line icons” themselves were.
Line states
Because the GPS data we receive is always ~30 seconds late, we've decided on a threshold of up to 2 min from last update that we can say the location is almost certainly accurate.
Above the 2 min mark since last update (in case fresh data was not received from varying reasons mentioned above) we've added an indication that will notify of a "problem" - the case for it was that this state was an intermittent one and fresh data can be received and the state will go back to "good".
In case fresh data was not received since 5 min and above, we alert with a red "critical" icon to explain of the GPS problem and we cannot know where the line is at.
In the case no GPS data at all, we will show the card, but without the icon on the map, not all lines have GPS signals transmitting but they are still operating as usual.
8. Putting it together
Mid point design
Navigation
There are 2 options to navigate and select a line:
1. Tapping on one of the line-icons on the map
2. Swiping the card
There’s always a direct connection between the card and the line-icon in focus. Once swiped / tapped on a line icon, the zoom of the screen will focus on the selected line and the station and adjust the view accordingly.
Forgiveability & Control
Under the cards I've located the “card management” component.
Because there can be numerous cards, I added an “infinite page indicator” that stayed the same size regardless of the amount of cards. Adding a numeric card-counter added to the sense of navigation and control.
Also adding, a “reset” button provided the added forgiveability in case users wanted a quick fix and returned back to the default selection which was the most upcoming, instead of having to manually searching and tapping on the most upcoming line, or swiping all the way back.
In addition, users might change zoom and interact with the map, therefore I've added a "reset map zoom" floating-action button (FAB) at the top right to easily reset the zoom and focus of the map.
Selected line VS unselected line
RouteEach line has a route, showing the selected line’s route was obvious by coloring it according to the operator color (convention through the app) but we also needed to find a way to present the “unselected routes” in which there can be numerous.
At first we thought of coloring them with a tint of the operator color. This was good if it was 2-3 line options. But from our testing, more than that and it was visually hard and too distracting.
Therefore we used a neutral gray color to show the “unselected routes”.
Route breakdown
Station name
Locating the station name as a pin above the station was a problematic approach. There might be stations with long names, different languages might not look good.
Therefore I opted for a top bubble with the station name. The container can grow depending on string size. In case string is too long, I've added a slide animation in loop for the station name.
_______________________________________________________________________________
Line icon
We also needed to have a clear distinction of the selected VS unselected line.
At first I thought that only expanding the size of it and adding a circle around for distinction was enough, but testing prototypes against real world data I soon discovered the “visual noise” on the screen was significant, therefore I needed a “stronger” visual emphasis on the “line marker”.
That’s why I've decided to increase the selected line size, and color it fully to draw attention to it easily.
Moreover, unselected lines icons will still be colored by the operator color (dan / egged / metropolin etc.) to provide an initial hint of the operator instead of having to tap on it to find out.
Card additional information
Amount of stations left until arrival
Because the line live location gave a sense of “real world” view, meaning what the user sees is an exact representation of the real world, which in itself was good, I’ve added an additional piece of information that didn’t exist prior to the feature and that was the “stops ahead” count, to show not just how much time left, but also how many stations / stops left until the line reached the user.
Last GPS update
Because the data we present is always a couple of seconds late (because of the problems mentioned above of latency and GPS signal and different operators) we had to show additional data that explained the “freshness” of the data.
The most common cases are the ones between 30s - 2:30m updates, we presented it as a part of the card, but also as the “line marker” on the map.
1st iteration:
The first iteration was not explaining what was the meaning of the time at the bottom left. Only if users tapped on it they would fully understand its purpose. This raised the problem that some users might never tap on it, therefore we had to add an explanation for it.
In addition some languages might be too long, users might increase phone's font size, and we also wanted to add additional data that might be needed in case of "service alerts" like detours, line changes etc..
Therefore we opted for an "automatic information swap" that will change every couple of seconds and repeat in loops the information available to show - most cases are 2-3 pieces of information.
2nd iteration
1. Explained the GPS update time
2. Additional information animation such as detours / pickup & drop-off only etc.
Note: At the time I had another project at hand, therefore this specific improvement was done by a colleague and a friend of mine Marcelo Macacdar.
Recording from working production
Additional information bottom sheet
In addition, tapping the cell will present an explanation of the data being shown:
Tapping interaction
9. Final design:
10. Breathing life to new design
In the design of this feature I wanted to add a sense of “breathable” design that felt more “open” rather than “closed”. This was an up to date design, but still have it in Moovit ambience.
Therefore the main canvas is the “map”. On the top we have the station name & icon to allow for quick identification. In addition we added a slide animation in case the name was too long.
All this provided a "breathable" design in which there are no hard corners and components that are "floating" on the canvas of the map.
In addition, I aimed for "liveliness" in the feature, so there's slide transitional animations once lines receive GPS update, to feel the progression in the feature.
Lines progress transitions
Dark mode
Route deviation edge case
11. Battery optimization
Initially we were showing the "live location" for lines up to 1 hour, regardless of amount of lines. Testing this showed that it was draining the battery on numerous stations, because there were transition animations, and lines on the map that the phone had to calculate their position on each update.
In addition, looking at the data showed that most users would not swipe to later on options and only looked on the most upcoming 1-3 lines.
Taking this into account, and to save the users' phone battery, we've limited the amount of "live locations" lines to 20, which saved battery drainage and kept the right amount of lines on the map.
12. Overall
The live location feature had a tremendous value both to users and to Moovit.
Users who experienced the feature, had an increase of +90% retention (!).
The initial duration of using the feature was 10-12 seconds, but with time this duration rose to 35-45 seconds (!). This meant additional increase of ad-revenue from ad-exposure.
Currently this feature is being provided only under subscription, because of it's potential and its high value it provides.
Links:
Additional entry points
There are multiple feature entry-points across the app, these are 2 examples.
Thank you