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.

A Dutch progress/speed bar in the Windows 8 copy dialog

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:

Half the time at full speed, half the time at half the speed.

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.

  • Want to make sure I'm understanding. When you say speed, you are speaking of the "data" speed. When you say progress, you are speaking of the overall progress. Yes, these may appear to be silly questions. Because, from what I can tell, it's not the speed - it's the size of the data which causes the bar to progress faster across the board - which should be expected, yeah?
    – Josh Bruce
    Commented Mar 21, 2013 at 16:38
  • @JoshBruce It says Speed: 18,4 MB/s. The more bytes are copied in a second, the higher the line (and subsequently the graph) and the faster the progressbar will progress to the right. Commented Mar 21, 2013 at 16:40
  • 1
    I can share some insight: the graph was designed to provide at least some utility to all users, regardless of their level of tech knowledge. For neophytes, it helps them understand that progress is being made even if the progress % is slow to change. Particularly helpful when they're copying TONS of data and don't realize it, which is a very common scenario. For more advanced users, it provides useful feedback about transfer rates and system state.
    – Noah C
    Commented Mar 21, 2013 at 19:10
  • 1
    Windows's copying dialog has been doing this for quite a long time already. Perhaps the graph is to... confuse people more?
    – Alvin Wong
    Commented Mar 22, 2013 at 2:37
  • 1
    The problem with progress bars is that the total time cannot be predicted, so the abscissa can't be time. I've seen attempts at having the abscissa being time and it is annnoying as progress moves left/right as end time is continually re-estimated.
    – QuentinUK
    Commented Mar 22, 2013 at 13:39

10 Answers 10


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:

enter image description here

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.

  • 1
    The graph will seem to grow in its fixed width, effectively shrinking the resolution of the graph over time. I like it. Commented Mar 21, 2013 at 22:11
  • I had the feeling a histogram might be a good solution for your design :)
    – Noah C
    Commented Mar 21, 2013 at 22:15
  • +1 This is the correct answer, and may be what Microsoft is already doing. Has anyone tested to see? Commented Mar 21, 2013 at 23:13
  • It's similar, but different: in Microsoft's implementation, the histogram does not compress during the duration of the file transfer.
    – Noah C
    Commented Mar 22, 2013 at 1:11
  • 1
    @Dani - I'm guessing you meant the right-most edge. Yes, the right edge represents both 100% progress and the current time. This design should only be used in a scenario where the user cares about watching throughput/performance and the designer needs to save space. It's not so helpful for people who just care about seeing progress, and it's likely to simply be confusing to a whole range of casual users.
    – Noah C
    Commented Mar 22, 2013 at 20:06

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. Chart Suggestions

  • 2
    Thanks. The Abela book has some gems in it. I do lots of UI work, and it's helped me improve my process quite a bit when it comes to data visualization.
    – Noah C
    Commented Mar 22, 2013 at 1:17

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.

  • 4
    I'm an average technical person and the graph is not useful to me because the speed graph (vertical) is not a function of time but of progress (horizontal). And progress and speed are related. So, fast progress will result in a wide high peak and slow progress in a narrow, low peak... or something. Commented Mar 21, 2013 at 16:42
  • 1
    It is a change so as every change a little time is needed to use it easily. With the previous version you hd no information. ...now you can see if you system is too much in work with other job...now you can have the information when the system is stressed and you can act. Commented Mar 21, 2013 at 17:55
  • 2
    @Virtlink Although I see what you mean in this comment, it's actually an assumption, not a fact. The scenario you described may happen. There may be bursts of high transfer rates and large troughs. That said, I find it useful as a tech person because I know where this happened - not in terms of a timeframe, but in terms of progress over a bounded set of files.
    – user8889
    Commented Mar 21, 2013 at 20:40
  • 1
    By the way, @JohnGB, the transfer rate is, by normal use and definition: volume of data per unit of time, right? I do want a graph in my control that shows the transfer rate, but the Windows 8 graph apparently shows something else: volume of data per unit of progress, for which I don't know the name and don't see how the most technical people would find that useful. Commented Mar 21, 2013 at 21:24
  • 2
    @Virtlink the Y-axis is transfer rate. The x-axis doesn't have to be time for that to be accurate. Unless you want to be able to integrate to get data transfer that is.
    – JohnGB
    Commented Mar 21, 2013 at 21:45

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.

enter image description here

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?

  • You are absolutely correct about the graph. I was still figuring this out and drew it with a 3/4 1/4 ratio instead of the correct 2/3 1/3 ratio. Horizontal is progress from 0 to 100%, or indeed just as correct, 0 MB to 100 MB (or whatever your file size is). I would expect MB's vertical and seconds horizontal, so the graph shows MB/s. Since vertical is the transfer rate in MB/s, and horizontal is the size in MB, the graph shows MB/(s*MB) (MB/s/MB) instead. If my basic math is correct, I can strike the MB's against each other: the graph actually shows 1/s. :P Commented Mar 21, 2013 at 23:15
  • 1
    @Virtlink: Well, the graph shows (MB/s) vs. MB. You're correct though that the derivative graph would have units 1/s, and would give, roughly, how (un)stable the transfer speed is at each point in the file. But, that's off-topic :) Commented Mar 21, 2013 at 23:29
  • @ruda.almeida I agree. Best answer here because it points out the flaw in the question.
    – xdumaine
    Commented Mar 22, 2013 at 12:59

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):

enter image description here

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.

  • I like it, but now there is a one-to-one relationship between the height of the graph and the distance of the ticks. When the ticks are far apart, the graph will peak. So then I don't need the graph and could represent the same info with, for example, a color gradient (darker color/closer ticks, lighter color/ticks spread out). Commented Mar 22, 2013 at 13:20
  • The x axis is not "percent", it's data copied. But yes, the apparent confusion seems to arise from the use of a non-time axis where one is expected. (It doesn't seem at all confusing to me though.) Commented Mar 27, 2013 at 2:19

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

enter image description here

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.

  • Thank you, that's indeed what I meant. By the way, the elapsed time is an estimate, you meant estimated time, right? Commented Mar 21, 2013 at 19:28

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.

  • Are you sure the speed of the animation is variable? I doubt it. Commented Mar 21, 2013 at 18:57
  • 1
    The stripes seems to slow down under heavy disk access. Now it's hard to say if it's a design decision or a consequence of the HD/CPU/system being overloaded when accessing/writing information.
    – SuperFluxx
    Commented Mar 21, 2013 at 19:19
  • So you are just guessing then? Can you provide evidence that speed of the animation is purposely controlled?
    – wim
    Commented Mar 22, 2013 at 0:09
  • Unfortunately I can't. Regardless, I'm providing an example as a starting point. From a UI/UX standpoint this UI element still answers the question and is a valid UI/UX solution.
    – SuperFluxx
    Commented Mar 22, 2013 at 0:16
  • 3
    The OS X stripes don't speed up as far as I can tell, but yes, they will naturally slow down if other processes grab their processor time. However, the fact that we're still somewhat 'fooled' by this stripy optical illusion to some degree reinforces what a smart design choice it was back in the day.
    – calum_b
    Commented Mar 22, 2013 at 10:25

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.

enter image description here

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.

  • One could overlay that graph with a graph plotting the speed. Commented Mar 24, 2013 at 13:58

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.enter image description here


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.