How to make a progress-speed bar more understandable?

Question

I've just installed Windows 8 and noticed the brand new File copying dialog. When expanded, it shows the progress and the current transfer speed in one graph. However, the graph confuses me greatly. The faster it copies, the quicker progress increases (left-to-right) and the higher the graph (bottom-to-top). I think this makes the speed graph non-linear, and I have trouble reading the graph. This makes the graph no more than a toy.

^{It's in Dutch but I think the gist is clear.}

I assume Microsoft's design team have discussed all pros and cons of this graph, so there must be some merit to this design. I would like to write a custom control for my own application that also shows progress and speed in one bar, but I don't think this is the way to go. How to make the speed part of the bar more understandable and useful? What are the alternatives?

---

To illustrate the problem I have with it:

This graph indicates that for half of the total transfer time, the file was copied at half the speed (e.g. 30 seconds of half speed if the total copying took one minute). That would be useful information but is not clear to me from the graph.

Answer 1

You can overlay your progress bar with a transfer rate graph pegged to 100% width. The result is a constantly updating histogram that remains linear throughout the operation. This gives you a simple way to display both progress and transfer rate on the horizontal axis. An example:

This is a rough visual example; to make it more readable you'd want to properly label things to ensure the progress bar and the histogram are district.

If your users care about watching throughput over time -- perhaps for debugging or instrumentation purposes -- this layered approach provides an easy way to monitor it during the operation. If users aren't expecting this data or this type of design, they might just find it distracting.

Answer 2

As you've pointed out, forcing speed and progress into one fixed-length bar -- per the Microsoft example -- reveals the inherently non-linear relationship between time and progress :)

But more importantly for your project: make sure you understand your user and determine your motivation before jumping in. What is the purpose of your progress bar in this case? And what is your goal by adding additional elements like transfer rate? Will it materially benefit your users? What are your users doing during the transfer? Will the additional data be actionable? If not, how will it be useful? Does graph linearity affect your user? And so on.

That said, it sounds like you want to display a linear graph, but you also want to visually combine it with the progress bar:

I think this makes the speed graph non-linear, and I have trouble reading the graph ... I would like to write a custom control for my own application that also shows progress and speed in one bar...

The speed graph in the Microsoft example is necessarily a function of progress since it has been overlaid onto a fixed length progress bar. But if you have determined that a graph of speed over time is useful to your user, and a linear graph is necessary, then here are a few concepts:

1. You can de-couple the two elements, resulting in a separate progress bar and speed graph. This doesn't directly answer your question but it is an option, and certainly the easiest to design and maintain.
2. You can plot the graph in three dimensions so you have enough axes to represent your three variables: data, progress, and time. Pretty, but probably overkill, and not very space-efficient in our world of 2D interfaces.
3. You can do variations of option #2 that are flattened into two dimensions by using color or other signals in place of a dimension. Those will tend to require more interpretation, though.

P.S. - I can't cite it directly at this time, but I have some insight into Microsoft's reasoning for their design. It was specifically built to convey a sense of velocity; this type of visual feedback was useful to the widest range of users, even though the result is slightly interpretive. Their internal usability testing found that users who experienced a slow progress bar were more satisfied when they had the option to view a line histogram, especially if it updated frequently. Remember that many users have a very loose grasp of file sizes, so it's quite useful for someone to see that their 20GB file transfer is still moving along, even if the progress percentage is changing slowly.

P.P.S. - When I'm thinking about data visualization, I often start with this chart from Andrew Abela's book Advanced Presentations by Design.

Answer 3

They are trying to include two separate statistics in the graph. The left to right is the % progress, and the graph shows transfer rate (with the black bar showing the average).

For most people this is overkill, and for most situations a simple progress bar is fine. However this only shown when you ask for 'more details', and so that is what you are getting. More details.

For a technical person this is actually fairly useful information, and I think well chosen. Especially since it is by default hidden.

Edit: There is no reason that the x-axis has to be time if the y-axis is a rate. The only time that would matter would be if you were planning on integrating the graph to get the data amount - which is clearly not the intention here as you already know that amount.

Answer 4

This graph indicates that for half of the total transfer time, the file was copied at half the speed

Actually, that graph would look more like this.

This graph indicates that for the first 2/3rds of the progress - ie. for the first 2/3rds of the file - the file transferred at full speed, then dropped to half-speed. Thus, it is not "time" on the X-axis, but "MB". The first, say, 66 MB transferred at full-speed, while the remaining 33MB transferred at half.

I agree that seeing transfer-rate vs. file-size is both counter-intuitive, and less useful than a graph of transfer-rate vs. time. Are you sure the Microsoft graph is actually doing this, and not displaying the more-intuitive transfer-rate vs. time graph using histograms?

Answer 5

It took me a while to understand where the problem is, because it is very subtle. The y axis is speed (bytes/sec), while the x axis is percent. In a usual time series plot, the x axis would be elapsed time.

This is fine in many cases, since for a roughly constant transfer rate, percentage ~ time. Even if not, you can still infer two pieces of information: The current progress, and the current speed, compared to other speeds that occurred. I often want to know the maximum attained speed, especially when copying files over the network (e.g. so I can tell people off who are hogging my bandwidth).

You're right that you don't easily get information about how speed changed with time, and you can't really interpret the profile of the graph. If you think that's neccessary, consider adding tics to the x axis at regular time intervals (say every two seconds):

This lets you see periods when you made a lot of progress, where the tics are spread out, and periods when the process was stalled, where the tics are close together. If you imagine the graph distorted so that the tics are spread out evenly, you'll have a proper speed/time graph.

I just whipped this up quickly in Gimp. I'd probably play with the tick distance to make the effect more pronounced, and also change the vertical gridlines to match the tics.

Answer 6

If my assumption is correct in my last set of questions. We might try two states for the same view.

Basically, while the file is being downloaded - you get the standard progress only view, with the extra data of speed (right now), total time elapsed, and estimated total time.

Once the file has completed transfer - if you have the bar expanded - the view would shift (maybe fade in the area chart) to display the data transfer rate along the time-based plot, with the median indicated by the horizontal line (in green for the example).

Because, as you seem to be pointing to, the progress bar is a function of bytes loaded over total bytes - while the transfer rate is a function of current time versus start time - which is a different x-axis plot.

Displaying both at the same time:

Because the time remaining is an estimate, therefore not a fixable (static) width, to display both concepts at the same time, I would stack them on top of one another (progress bar + stats as is, but use the unexpanded height). Put the transfer rate above it - with the axis labels on top. While the process is happening - update the elapsed time number - as we go.

So, at second zero, you would see nothing in the rate graph. At one second, the right label would say 1, and the area chart would basically be a straight line (or, more accurately, a line from 0 to however many bytes were loaded during that second). At second two, the first data value would be 50% of the width of the chart, and drawing a line to the end with the new data value. And, your median line could then appear to show the average rate. Then just keep redrawing the graph every second tacking on the latest data rate.

Once the progress bar hits 100%, the graph stops refreshing, displaying the total elapsed time, with a complete trail of rates.

You could also overlay them - literally on top of one another - by making the area chart layer one, the progress bar - with some type of transparency layer two. But, I caution against this because it still might cause some confusion - the top label (transfer rates) are linked to the bottom layer - while the 0-700kb label are related to the progress bar.

Answer 7

Take a look at the Mac OS progress bar. The bar grows from the left to the right to represent completion. Speed of completion seems to be represented by how fast the stripes move inside.

I'm not telling you to copy it, just to use it as a starting point from which you can add details based on your requirements. Then design, test, improve, repeat.

Answer 8

I think that if you want to show the speed and progress at the same time as a graph, then what you need is a monotonically increasing curve which basically plots percent complete versus time: an extension of the simple 1D progress bar into 2D, showing the progress history, not only the current progress. The graph will tell you at a glance facts such as that the progress stuck at 15% for 45 seconds, but then went from 15 to 37 in just 3 seconds. The slope (time derivative) of the curve is speed, just like in a distance-time plot.

If speed itself is plotted (the derivative), people don't understand that (even if the update rate does not change) because they have to mentally integrate the area under the curve to figure out the progress.

For instance we could make UI in which at regular intervals we sample the amount of progress that was made (kilobytes copied or whatever) and plot a bar of a corresponding height. So the area under the curve, at the end, would represent the total progress. But even people who understand integration would have trouble guessing when 50% has been surpassed.

Answer 9

I don't think this graph adds much more to the original progress bar. I don't think it makes sense for the horizontal axis to rescale because progress is relative to the amount of work done, and the amount of to be done doesn't change unless you are trying to provide an estimate of how much more time it takes to complete the task.

What I would suggest is to put another bar that indicates an estimate of the time remaining based on current speed, highest and lowest historical speed. It gives users a better expectation of what information is being presented and how it relates to the display.

Answer 10

I believe this chart is trying to show something along the line of a probability density function (PDF) for speed versus progress. While it has nothing to do with probability, it has a similar form. I find this chart helpful for a few reasons: 1) If my transfer says two hours for 2 GB, I can see what the transfer speed is and evaluate from there, and 2) To simply satisfy my curiosity.

JohnGB brings up a good point about it being hidden by default, and that's why they can get away with this technical type of data in a simple chart.