Rethinking the Progress Bar (2007) [pdf]
chrisharrison.netWhen a program is performing a task that is going to make me wait I want lots of communication. Imagine I ordered a sandwich in a restaurant and its taking longer than expected. I'm now faced with a decision, do I wait or do I leave? I could make a better decision about what to do if I could see how many orders are ahead of me or if I can watch the kitchen and see a stack of ingredients ready to go, but the chef paused to clean off the grill. In the case of computer it can be hard to know beforehand exactly what its going to do and how long it will take. Maybe there is some kind of issue I need to fix before the task will ever be complete. As computers and networks evolve and improve (or degrade) it can be really hard for the programmer to have a good idea of how long a task will take to complete. In light of that, I would always err on the side of giving the user more information about what the program is doing and how long its taking.
On a file transfer I'd really like to know, how much has been copied, how much is remaining and the current (5 sec average maybe) bit rate. That gives me enough information to know whether its worth waiting around for it to finish or I should find an alternative or the connection has dropped.
Staring at a spinner, with no idea how fast or slow things are going is the worst and I'm going to give up a lot sooner than if I knew what was happening.
As computers and networks evolve and improve, a lot more things would get involved and it is going to be hard to tell how long any operation is going to take. Operating on an assumption of always instant feed back does not scale.
Ordering a sandwich in a restaurant apparently becomes less normal nowadays. Instead we order it online for delivery. I would find it extremely annoying if the delivery service keeps sending me messages about his status. If the delivery is going to arrive at the time frame I asked for, I don't want any extra information from them. While I wait for the sandwich delivery, I can order other stuff too. I only want any messages about anything I ordered is if the delivery is not going to make it. If I received such delivery error, I can submit another order from a different delivery service.
Now you can go down a level and consider how the restaurant operates in this case. The restaurant receives orders from a queue and make those in batches. Whenever the delivery person comes, the restaurant hands out packaged orders each with their endpoint addresses. The restaurant does not need any extra information from you or the delivery person, unless something unexpected happens. There is no need for extra communication unless there is an interruption.
If you are the restaurant owner, of course you need to manage ordering ingredients for the restaurant, and ordering sandwiches for yourself. Whatever you need to order, your system can be transparent to it. Once you make the decision what to order, you can go back to paragraph two above and start from there.
Destination file: C:\Windows\FONTS\GARAIT.ttf
loved reading this taking ages while installing from the floppy disk
As a summary;
- Participants preferred whatever they saw first
- Otherwise, accelerating or rapidly accelerating progress bars were generally preferred
If you're designing progress bars with an unknown time to completion, my recommendation is to use an accelerating function for the first 95% over the predicted median time to completion. Then linear timing function for the next 4% and set the time to 3x the median time to completion. Automatically fill the bar when progress completes, no matter what.
e.g. if an action takes a median time of 4s to complete;
f(0 <= t < 4) = 0.95 * ((t / 4) ^ 2)
f(4 <= t <= 16) = 0.95 + (0.04 * ((t - 4) / 12))
f(t > 16) = 0.99
I 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 leverages the human's susceptibility to the sunk time fallacy.
They may not have been the first to invent the idea or implement it. I found this description of the same idea here: https://cerealnumber.livejournal.com/27537.html
and an online implementation and demo here: https://jan-martinek.com/etc/zeno/
Wouldn't it be more useful to just show a spinner?
Or have zombie spinners eliminated all trust that they indicate ongoing activity?
Was setting up a new iPhone yesterday and got burned by a zombie spinner that I believed was indicating progress was being made on the iOS 14.4 update. Left it alone for 2 hours expecting it to be done only to find it as I had left it. Restarted the process and the spinner didn't appear at all. It was like it was a spinner which could only show in the event that it had broken.
Spinners are terrible since many devs forgot to implement error state
I do not trust the spinners personally
Watching that progress bar was physically painful. I'd rather not use software that lies to me.
I'm pretty sure Github does this when navigating from page to page. Makes sense—The browser has no way of knowing the progress of the HTTP request.
It seems to me that most progress bars are lies.
Usually by the time your software knows fully all the things that need to be done, then you are almost done anyway.
One approach is to remember how long a similar task took, and present progress based on the expected time will be similar.
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.
Most progress bars I know travel from 0% to 99% in a minute, and then take 10 minutes for the last percent.
I would leave a site that had a bar like that. It would piss me off way too much.
I'm still waiting for a neural net progress bar as a service that pipes in all available device data, measurable progress and a task id and spits out a prediction based on previous runs across _all_ previous tasks.
Should eventually figure out what tasks are IO bound, what are CPU bound, what are fixed time, etc. as well as what device configurations effect that. Could also predict a service is down given enough scale...
Inside this concept there is a Douglas Adams like short-history about a self-conscious progress bar.
I've thought about this so many times. I imagined a config file that listed stages with what resource they used most and how much of that resource it might take, like:
- Vendor: Foo Corp
- "Downloading files", Internet, 1000 MB
- "Extracting files", Disk, 2000 MB
- "Copying files into place", Disk, 4000 MB
- "Configuring", CPU, 100 seconds
The library would generate a progress bar that you'd update like:
- progress('Extracting files', 100), progress('Extracting files', 200), etc.
It would learn that 100MB of disk IO takes about this much time, and downloading 100MB from the Internet takes so long, and so forth. And the thing is, the estimates wouldn't even have to be particularly good as long as they were reasonably consistent for all of the same developer's projects. If CPU bound process #1 takes 10 seconds on the developer's laptop, and CPU bound process #2 takes 20 seconds, then the library could see how long the first takes on the user's hardware and then double it for the starting estimate of the second process.
I'd love so much for this to exist.
Edit: because of your comment I finally got around to writing this up at https://honeypot.net/post/smart-progress-bars/
Drawback: All that processing about how much to advance the progress bar under what circumstances on which hardware, etc. pp. takes so much CPU cycles that the actual task takes 3 times as long compared to a "stupid" progress bar.
I started implementing it last night, and the cost for a simple weighted average model was basically free.
How would that work exactly? Do you mean that you’d ship the monitoring code to all users in production, and it would monitor losing times, system attributes, etc. and phone home to your servers, where you’d use that to train a NN and ship that model back to all users?
The NN part is a bit tongue in cheek but yep, you got it. You could also just poll the cloud model without having to actually run it locally.
It's a somewhat silly idea, but actually what would really make it shine would be if the OS provided an api. You could give it some identification, and maybe a listing of tasks. That way it could pool learning data from all programs.
Yep, very silly...and yet...
If it wasn't clear, I completely agree that the data should be aggregated across all apps, all tasks.
These researchers presume that their goal is to make users think that an operation is happening quickly, even if it is slow.
I thought the goal of a progress bar was to report reality, not manipulate users into thinking that your slow code is faster than it actually is.
Since when have dark patterns infiltrated academic HCI?
My understanding (and I believe studies back this up) is that primary goal of a progress bar is to assure the user, in priority order: 1) the app has not crashed, 2) the app is busy doing something, 3) the app is busy doing something relevant to the user.
As a software developers things like % complete and estimated finish time are general far more useful (for debugging things like "what stage is taking too long", for instance), but those specific details are rather further down the list of priorities for most average users.
> My understanding (and I believe studies back this up) is that primary goal of a progress bar is to
Studies cannot "back up" a goal. The goal is defined by the designer, developer, or in this case, the researcher.
Users also want to know if the app is lying to them. Sometimes an app crashes but keeps showing a progress bar. Sometimes the app says that something will take less time than it does. The more that developers make progress bars that lie to them, the less that users can depend on progress bars to tell them the truth and make informed decisions about what to do with their lives. These computers are tools for them. You don't know better than your users.
The point is that studies back up the requested priorities/interests of the users. You stopped at the word "goal" without reading the rest of the sentence. (ETA: Also from a pure syntax diagramming perspective, that parenthetical was tied to "my understanding" not "the goal".)
To make my early point more explicit: average users don't care about Progress Bars with exact percentages and to the second/millisecond estimate times. Users want Progress Indicators that tell them the app hasn't crashed, is busy, and is busy with something relevant.
Progress Bars in general are just a bad way to tell users the information they want, whether they "lie" or not. I agree that in the case of an unrecoverable crash, an application should no longer show a progress indicator. I agree that users dislike it when an app suggests something will take less time than it does, but I think "build better estimates" is a Halting Problem trap and I think the answer has to be "show fewer estimates" and "build intentionally worse estimates". "32.5%" and "ETA: 3:21:59" shows far more implied accuracy that any system can actually deliver on than "Fooing the bar" and "This may take a couple hours" do.
The point is that it isn't "lies" versus "Truth", but "uncertainties" versus "implied lies". The application is always likely uncertain how much time things will exactly take, that's the nature of software (and the vagaries of hardware/internet conditions/weather, plus the Halting Problem). Specific percentages and too accurate estimates lie in their own way that the tasks being taken are all fungible and exactly linear in time/space, that the possible error bars are in parts of a percent and seconds rather than tens of percent and minutes or hours. There's always going to be "implied lies" in a progress bar, the question in this article, this thread, and others is how do you present how much that "you don't yet know" to the user that doesn't give them the wrong impression?
Again, developers certainly care about the raw percentage of work done or the raw estimate down to the actual second, but those sorts of details do more harm to the user's value of the system than good. They sometimes think they want to know those raw scores, but those raw scores don't actually tell them what they want to know or what they need to know. It's not a "lie" to just not give those raw data to the user. It's sometimes more of a "lie" to give that raw data to the user and then frustrate the user that the last 1% is different from the first 1%, that the exact-to-the-second ETA was wrong by hours.
Progress Bars are one of the best Progress Indicators we have, but they aren't perfect and they confuse and frustrate users sometimes as much as they help.
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.
> 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.
Display a progress bar for downloading, and then another one for processing. You can caption them, too.
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 principle as well as clues about whether they are on track. When reality differs from that it is ok, as long as the ETA is somewhat in the ballpark area of the actual time of arrival.
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.")
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?
Downloads can occupy some fuzzy middle ground between unknown and deterministic.
The normal case is that bandwidth throughput can be estimated well enough to make humans happy. But a broken network throws that out the window and will do its best to find ways to make your progress bar behave weirdly.
I can't remember what it was, but there was a Mac app a very long time ago (System 7 era, in the 90s) - maybe a news reader? - that would eventually hide the progress bar and show a message about bad networking when that happened.
There are browser APIs, as well. However, network performance may vary. Personally, I would add textual information, like an estimate of the time required.
I'm pretty sure in most systems I use, processing time is not deterministic and it depends on what else the system is doing at the time and it's temperature, among other factor of which the progress bar won't be aware.
A progress bar will usually present the "expected" duration of several operations, [almost] none of which have a deterministic duration, or a deterministic ratio from one to the other. The best we can do is put heuristics in place to estimate how long the operations will take. We have some choices, such as estimating the total time or estimating each sub-operation separately. We can even use AI for the estimation, if we want to get fancy. But the problem is not tractable, and we'd rather given estimates where we can that just use spinners everywhere.
And yet users prefer progress bars. You know the average duration of a data transfer and can show a progress bar even if it's not very accurate.
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.
I had great results using a circular progress bar instead of a linear one. If you allow the tail to "catch up" towards the head, but the head always moving forward (rotating clockwise) you can allow the progress bar to shrink without losing the illusion of forward progress. In the worst case where lots new tasks/sub-tasks are discovered on the fly, it acts directly as its own "spinner".
It's probably easier to visualize than describe, but I have longer descriptions on the thinking behind it on my blog/GitHub repo. Unfortunately, my demo site succumbed to JS CDN bit rot and I keep forgetting to update the demo to something more recent.
(ETA: Forgot the link: https://github.com/WorldMaker/compradprog Also thought I could point out that the idea mostly jives with the findings in the paper here.)
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.
That's fine if the progress bar is only indicating the progress of the download. As mentioned elsewhere in this thread, if the download operation is only one part of the overall process, things get quite a bit trickier -- what percentage of the overall progress do you assign to the download operation when external factors like network speed and system load come into play?
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.
It's only lying if your users are completely rational aliens that have linear perception of the passage of time.
By the way, people do really not expect progress bars to be correct. They may with they were, but not expect.
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 often can't get the timing to be smooth through all stages of an operation, at least they always move forward. In fact, I think you'd have to work extra hard to make them move backwards.
Oh I had forgotten about the going backwards ones! It was like the machine was personally taunting you.
I've seen that on the Windows 10 file copy dialog just yesterday... but yeah, they existed back in the 90's too.
> It's not harming people in any way, but the opposite.
Please explain how lying to your users is good for them.
Results:
Participants tended to prefer (i.e., perceive as faster) whichever function they saw first. Of the 990 paired com- parisons, the first function was preferred 376 times (38%), the second 262 times (26%), with no preference 352 times (36%).
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]
The best progress bars I see, are double ones, where there's one general bar, and one with a thinner bar for each item. That way I always know that there's progress. Perhas even some info text would be nice too, like it is in most games, for when the progress requires some CPU time.
Cool to see article by someone I know on here! Really liked this paper, something else I find tricky about them is how hard it often is to accurately measure/report/track progress when writing software. In my experience a lot of these bad behaviors in progress bars come from programmers not having good way to actually track the real progress and instead just have to aggregate or estimate progress from each "stage" or "step" or whatever your software abstraction for a unit or work ends up being
Good to see Chris Harrison doing good work after being fired from hosting the Bachelor.