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

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

#41

Post by WorldMaker » Thu, Mar 04, 2021, 6:51 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.

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

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

#42

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

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.

I've seen that on the Windows 10 file copy dialog just yesterday... but yeah, they existed back in the 90's too.

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

#43

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

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

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

#44

Post by _jal » Thu, Mar 04, 2021, 7:02 PM UTC

ancarda wrote: post #32

masswerk wrote: post #17

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

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.

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

#45

Post by jxy » Thu, Mar 04, 2021, 7:28 PM UTC

intrepidhero wrote: post #43

When 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 paus…

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.

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

#46

Post by kebman » Thu, Mar 04, 2021, 7:56 PM UTC

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.

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

#47

Post by cjaybo » Thu, Mar 04, 2021, 8:01 PM UTC

madsbuch wrote: post #38

atoav wrote: post #25

Earlier quoted context omitted.

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?

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

#48

Post by luhn » Thu, Mar 04, 2021, 10:41 PM UTC

randomstring wrote: post #29

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

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.

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

#49

Post by paulryanrogers » Thu, Mar 04, 2021, 11:21 PM UTC

randomstring wrote: post #29

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

Wouldn't it be more useful to just show a spinner?

Or have zombie spinners eliminated all trust that they indicate ongoing activity?

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

#50

Post by uneekname » Thu, Mar 04, 2021, 11:24 PM UTC

paulryanrogers wrote: post #49

randomstring wrote: post #29

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

Wouldn't it be more useful to just show a spinner? Or have zombie spinners eliminated all trust that they indicate ongoing activity?

I do not trust the spinners personally