ArcGIS Tracker

Esri

At Esri, I lead design for Android and iOS apps that help teams improve field coordination and operational efficiency in industries like utilities, government, public safety, transportation and more.

A simple, battery-efficient location tracking app that gives users the ability to share their current and previous locations while going about their work.

Justin Velgos (iOS) and Erich Rainville (Web), and I (Android), along with a team of developers, product engineers, a project manager, and stakeholders worked together to design and develop Tracker.

Goals

Explorer set a baseline precedent for how our field apps should look and feel. Workforce’s usability needs to hit that bar and continue to increase it. We want to improve the information hierarchy so long lists are less daunting and easier to parse. Lastly, we want to spend some time in the field improving our understanding of how people complete their work.

Challenges

Members of the team can reference these components in Abstract, or get the gist on our documentation site.

Schedule

To optimize our app for minimal use, we created a simple schedule for users to specify when they’d like tracking their location to automatically start and stop.

Our first iteration of this design is most useful for shift workers, i.e., those that need to be regularly tracked. We’ll be paying especially close attention to customer feedback in this area.

This feature helps solve all three challenges mentioned above. First, displaying a map with tracks that are constantly being drawn and a location that’s constantly being updated can significantly affect battery consumption. With the schedule automatically turning tracking on and off, the user doesn’t have to keep the app in the foreground or ever manually open it.

Second, we utilize notifications when the tracking status changes. When the schedule turns tracking on and off, we display system notifications confirming the change. While tracking, a persistent notification (that can’t be dismissed) is shown to let the user know they’re currently being tracked. Additionally, even with a schedule set, if the user needs to manually turn tracking on or off, they can at any time from within the app. The app will let the user know the next time tracking will turn on or off.

Finally, the schedule enables a sort of “set it and forget it” mentality. Sure, users can open the app at any time to see where they’ve been within the last 72 hours and where they currently are, but they might not. For most scenarios we’ve heard, they’ve got more pressing things to do.

Track visualization

How should tracks look when overlaid on the map? Should they be points or lines? What color should they be? How might we account for tracks that overlap? How might we convey directionality, activity (walking, driving, stationary, etc.), and other additional information that we get from a single track point?

These are some of the questions we asked ourselves when thinking about how tracks should be shown in both the mobile and web apps. This posed quite a challenge because ideally, the solution we arrive at should work for all major tracking scenarios: search and rescue, site planning, surveying, damage assessment, and more.

Early on, we discovered that directionality and overlapping tracks are impossible to present in an intelligible and visually appealing way when the tracks are visualized as a series of points or breadcrumbs. It was clear to us that a user’s tracks should be displayed as lines.

Early track designs utilizing points over lines and a color ramp to indicate elapsed time.

When thinking about directionality and activity, we looked around for examples in other mapping apps. After a bit of trial and error, we decided to superimpose arrows on the track lines every certain amount of meters/feet—depending on the user’s speed and activity. These arrows are only be visible when zoomed in to a point where they’d be easy to discern and not distracting or confusing, in the event of overlapping tracks.

Current track designs utilizing lines over points and directional arrows when zoomed in.

There were a ton of considerations when selecting a color for the tracks. We thought about which color would look best across the light and dark theme basemaps the mobile app supports. The Tracker brand color was a bit too vibrant to use on a map. We referenced popular navigation apps—Google Maps, Apple Maps, and a few others. Blue lines seemed to be associated with directions and navigation, allowing us to harness that existing mental model. We decided to play with opacity and saturation instead of alternate colors to convey activity. On the web side, the tracks of hundreds (and potentially thousands) of users could be shown simultaneously, on the same map. The web app would have to represent the tracks of different users with different colors. We didn’t want to give the use of different colors a different meaning on the mobile app side.

Outcome and retrospective

We’ve heard interesting use cases from customers and themes from customers that I can’t wait to explore: back office-to-mobile app communication, geofencing, panic/emergencies, indoor tracking, and more.

This is an evolving design with evolving requirements and use cases, and we’ll be looking to assess customer feedback where possible.