Someone should make a JSFiddle that demos these different progress bar mathematical functions so you can visually compare them side-by-side.
Also relevant: Tom Scott's recent video[0]
Rethinking the Progress Bar (2007) [pdf]
31–40 of 63 posts
Re: Rethinking the Progress Bar (2007) [pdf]
#32Earlier quoted context omitted.
Its a bit harder than that, I'd say. Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed. I am having that exact problem in an application I am developing.
Downloading is an async operation of unknown duration, which is best represented by a spinner. Processing, on the other hand, should be deterministic. I'd say, have a spinner and a progress bar (dimmed, while the spinner is active, then switch to a dimmed, but filled spinner and an active progress bar.)
Why use a spinner for downloading? Don't you know how many bytes you need to fetch and how many you have received so far?
wget has a progress bar, and it works perfectly fine.
EDIT: Though, if the server does not have a Content-Length header, you will get an indeterminate progress bar (a kind of spinner, I suppose) in web browsers, if that's the kind of thing you mean?
Re: Rethinking the Progress Bar (2007) [pdf]
#33Earlier quoted context omitted.
Back in 90s the progress bar was so bad it was more entertainment. 5 minutes left, 4 minutes, 23 days, 1 minute, 4000 years left. The last 1% Taking longer the first 99% If you installed the same software repeatedly get an idea of how long each section of the bar would take. Windows 3.1 I’m looking at you.
Yeah, this used to be a real pain point. Page 311 of the .NET Framework Design Guidelines has this quote from Chris Sells (then a program manager for .NET, I think): > Please make progress reporting move forward, if for no other reason than my family makes fun of me when they see a progress report going backwards, as if it's my fault. Personally, I've implemented several progress percentage algorithms and while I oft…
Oh I had forgotten about the going backwards ones!
It was like the machine was personally taunting you.
Re: Rethinking the Progress Bar (2007) [pdf]
#34I had a friend who implemented what he referred to as Zeno's Progress Bar. After every unit of time passed, the progress bar would progress half the distance to completion. So 0 -> 50% -> 75% -> 87.5% and when the task finished it would jump to 100%. It didn't bother to measure the actual progress at all. Key factor was making users think something was happening and not give up before it was done. In hindsight, it le…
Watching that progress bar was physically painful. I'd rather not use software that lies to me.
Re: Rethinking the Progress Bar (2007) [pdf]
#35Earlier quoted context omitted.
Progres bars have several goals, but making yours users happy secure that they know how long they'll spend and not feeling like they waited too long is certainly one of them. Why do you classify that as a dark pattern? It's not harming people in any way, but the opposite.
Why do you classify that as a dark pattern? It's not harming people in any way, but the opposite. It's lying. Lying is inherently harmful. Just because a computer is doing it doesn't make it unethical. Especially since people trust computers to be precise and correct.
[deleted]
Re: Rethinking the Progress Bar (2007) [pdf]
#36I had a friend who implemented what he referred to as Zeno's Progress Bar. After every unit of time passed, the progress bar would progress half the distance to completion. So 0 -> 50% -> 75% -> 87.5% and when the task finished it would jump to 100%. It didn't bother to measure the actual progress at all. Key factor was making users think something was happening and not give up before it was done. In hindsight, it le…
I've used NProgress for years in JS apps and it defaults to a similar progress (though it uses a smoother "ease-out" curve than pure "Zeno").
Though one interesting thing to note is that both of these curves violate one of the findings in this article that users seem to prefer the bar to move slower at the beginning than the end and what you like want is more of an "ease-in" curve.
Re: Rethinking the Progress Bar (2007) [pdf]
#37Earlier quoted context omitted.
Downloading is an async operation of unknown duration, which is best represented by a spinner. Processing, on the other hand, should be deterministic. I'd say, have a spinner and a progress bar (dimmed, while the spinner is active, then switch to a dimmed, but filled spinner and an active progress bar.)
Imagine a train network operator who says: we cannot say how long a trip will take with 100% accuracy, therefore we are not going to tell you at all. And evwn more evil: on the trains they blind the windows and rob you of every clue that would tell you where you are and how fast you are going. This would be pretty uncomfortable. What train riders (and users) are interested in is how long a thing should take in princi…
On the other hand, time tables should provide actual data in linear time (not some "apparent time" – "You'll arrive in 'just fine' at your destination."). I don't know the extent of the download, but, if not not substantial, it should just add a small offset prior to the main operation. Otherwise, if you're downloading a huge database, you can draw estimates from progress and display a sub-progress of this first task. (There are APIs for this).
In the now gone days of usability, it was considered good practice to annotate the progress bar of a complex task by displaying textual information regarding the sub-task and the progress made. This could be considered here as well. (E.g., "Loading data, estimate: 3.4 secs.")
Re: Rethinking the Progress Bar (2007) [pdf]
#38Earlier quoted context omitted.
Its a bit harder than that, I'd say. Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed. I am having that exact problem in an application I am developing.
This is hard because predicting a duration for each process is hard. For some processes getting feedback that granular might be hard (for a download this is more or less easy, you get the moving window average downloadspeed and the total filesize and use simple arithmetic to get the duration). For other things this can be hard, e.g. if the peocess you use doesn't offer that kind of granular metrics.
Download speed is not too important when showing a progress bar (unless one wants to do somethings fancy). If you know total content length and how much you have downloaded you just calculate the fraction and update the progress bar according a couple of times a second.
Re: Rethinking the Progress Bar (2007) [pdf]
#39Earlier quoted context omitted.
Its a bit harder than that, I'd say. Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed. I am having that exact problem in an application I am developing.
Wasn't this solved back in the days of floppy disk OS installation? You have one progress bar showing progress for this floppy, and another showing progress for the entire operation.
That is indeed a solution :)
I was merely constructing a case for using fancy progress bar calculations. And conflating two non related operations into one might be one of those.
Re: Rethinking the Progress Bar (2007) [pdf]
#40Earlier quoted context omitted.
Downloading is an async operation of unknown duration, which is best represented by a spinner. Processing, on the other hand, should be deterministic. I'd say, have a spinner and a progress bar (dimmed, while the spinner is active, then switch to a dimmed, but filled spinner and an active progress bar.)
Why use a spinner for downloading? Don't you know how many bytes you need to fetch and how many you have received so far? wget has a progress bar, and it works perfectly fine. EDIT: Though, if the server does not have a Content-Length header, you will get an indeterminate progress bar (a kind of spinner, I suppose) in web browsers, if that's the kind of thing you mean?
There are browser APIs, as well. However, network performance may vary. Personally, I would add textual information, like an estimate of the time required.