Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking the Progress Bar (2007) [pdf]

chrisharrison.net

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Rethinking the Progress Bar (2007) [pdf]

#21

Post by jayd16 »

ravi-delia wrote: post #15
jayd16 wrote: post #5

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 scal…

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#22

Post by elcomet »

masswerk wrote: post #17
madsbuch wrote: post #8

Earlier 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.)

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#23

Post by Fargren »

masswerk wrote: post #17
madsbuch wrote: post #8

Earlier 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.)

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#24

Post by nullserver »

marcosdumay wrote: post #18
reaperducer wrote: post #14

Earlier quoted context omitted.

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#25

Post by atoav »

madsbuch wrote: post #8
toomim wrote: post #4

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?

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#26

Post by cldellow »

nullserver wrote: post #24
marcosdumay wrote: post #18

Earlier quoted context omitted.

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#27

Post by [deleted] »

nahuel0x wrote: post #13
jayd16 wrote: post #5

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 scal…

Inside this concept there is a Douglas Adams like short-history about a self-conscious progress bar.

[deleted]

Re: Rethinking the Progress Bar (2007) [pdf]

#28

Post by atoav »

masswerk wrote: post #17
madsbuch wrote: post #8

Earlier 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.)

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.

Re: Rethinking the Progress Bar (2007) [pdf]

#29

Post by randomstring »

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/

Re: Rethinking the Progress Bar (2007) [pdf]

#30

Post by WorldMaker »

toomim wrote: post #4

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.

Post reply on HN