Rethinking the Progress Bar (2007) [pdf] • Hacker News Board

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

#11

Post by keithwhor » Thu, Mar 04, 2021, 5:48 PM UTC

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  16) = 0.99

You can adjust this however you see fit but I find it gives a pleasant experience.

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

#12

Post by jayd16 » Thu, Mar 04, 2021, 5:53 PM UTC

tshaddox wrote: post #9

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…

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.

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

#13

Post by nahuel0x » Thu, Mar 04, 2021, 6:00 PM UTC

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.

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

#14

Post by reaperducer » Thu, Mar 04, 2021, 6:01 PM UTC

marcosdumay wrote: post #10

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?

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.

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

#15

Post by ravi-delia » Thu, Mar 04, 2021, 6:02 PM UTC

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.

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

#16

Post by reaperducer » Thu, Mar 04, 2021, 6:02 PM UTC

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.

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.

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

#17

Post by masswerk » Thu, Mar 04, 2021, 6:03 PM UTC

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.

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

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

#18

Post by marcosdumay » Thu, Mar 04, 2021, 6:04 PM UTC

reaperducer wrote: post #14

marcosdumay wrote: post #10

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

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.

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

#19

Post by [deleted] » Thu, Mar 04, 2021, 6:04 PM UTC

marcosdumay wrote: post #10

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?

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.

[deleted]

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

#20

Post by toomim » Thu, Mar 04, 2021, 6:05 PM UTC

marcosdumay wrote: post #10

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?

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.

> It's not harming people in any way, but the opposite.

Please explain how lying to your users is good for them.