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?
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.
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.
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.
I am having that exact problem in an application I am developing.
You have one progress bar showing progress for this floppy, and another showing progress for the entire operation.
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.
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.
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.
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.")
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?
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.
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.)
Display a progress bar for downloading, and then another one for processing. You can caption them, too.
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.
By the way, people do really not expect progress bars to be correct. They may with they were, but not expect.
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.
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.
Please explain how lying to your users is good for them.