Pace Graphs — Up Is the New Down
By: Strava Engineering
Tags: Running, D3js, Front End Development, Data Visualization, Web Development

In April 2013, Strava released a complete redesign of run activity pages on the web. The changes were comprehensive from both product and engineering perspectives. Amidst a large number of new features and feature enhancements, one seemingly small user experience decision was made that has caused ongoing debate both inside and outside the company: all pace charts would use increasing values on the y-axis to indicate slower pace.

While this decision was a small part of the overall activity page redesign process, it was not made flippantly. Pace is an inversion of speed and is expressed in time per unit distance. Higher pace values do actually represent slower running speeds, in the same way that higher times represent slower race performances. The Science of Sport, known for their analysis of endurance sports, uses charts where increasing y-axis values represent slower times and paces when analyzing elite marathon performances.

In our research, we found that runners are divided on which direction is more intuitive for pace charts, and they hold those opinions strongly. We received volumes of feedback on the redesign, and the axis direction of our pace charts was a hot topic of dispute.

Consistency Across Platforms

At the time of the activity page redesign, mobile and web product development at Strava was mostly decoupled. Our iPhone and Android apps did not update their pace charts, leading to an inconsistency across platforms.

Since then, we have worked to more strongly align the mobile and web roadmaps. There is soon going to be a new type of pace chart on all platforms, and designing these charts for all platforms at once put a spotlight on our inconsistency. As a result, we decided to once again invert the web pace charts and return them to consistency with mobile: faster goes up. While this does invert the units of pace, it allows us to consistently represent speed and intensity when plotting activity data.

Consistency Across Data Streams

At no point in this debate did anyone suggest that our cycling charts should use increasing y-axis values to represent slower speeds. There is no question that a line chart of speed should go up for faster values. Plotting faster paces with an increasing y-axis allows the top of charts to always represent the fastest parts of activities, regardless of whether the data is represented in terms of speed or pace.

In addition to speed and pace, Strava charts other data streams such as heartrate and power where increasing y-axis values represent increasing intensity. Plotting faster pace in the up direction aligns increases in intensity when viewing multiple data streams at once, such as in this interval workout:

Perhaps the Highest Debate to Code Ratio Ever

We use D3.js for charting on the web. The manner in which D3 maps data domains to display ranges made inverting our pace charts trivial in some cases.

This scale previously mapped low domain values (faster paces) to higher range values. The y-axis points down in the SVG coordinate system, so higher range values were rendered at the bottom of the chart. In this particular case, all that was required to invert the chart was to invert the display range. Now, low domain values (again, faster paces) are mapped to low range values, which in SVG puts the fast pace at the top of the chart.

In some cases, inverting the charts required slight changes to padding and other details, but the technical scope of the change was extremely small:

Onwards and Upwards

From this point on, faster paces will be at the top of pace charts across the Strava platform. Up is the direction of progress and improvement, and we hope this small change will bring a more positive, consistent experience when analyzing run performance.