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

51–60 of 63 posts

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

#51

Post by [deleted] »

luhn wrote: post #48
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.

[deleted]

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

#52

Post by ashishb »

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?

Spinners are terrible since many devs forgot to implement error state

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

#53

Post by kstrauser »

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…

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/

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

#54

Post by dpatterbee »

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?

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.

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

#55

Post by bromuro »

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…

Destination file: C:\Windows\FONTS\GARAIT.ttf

loved reading this taking ages while installing from the floppy disk

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

#56

Post by toomim »

WorldMaker wrote: post #30
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", fo…

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

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

#57

Post by junon »

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 would leave a site that had a bar like that. It would piss me off way too much.

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

#58

Post by skocznymroczny »

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…

Most progress bars I know travel from 0% to 99% in a minute, and then take 10 minutes for the last percent.

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

#59

Post by mbirth »

kstrauser wrote: post #53
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…

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('…

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.

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

#60

Post by kstrauser »

mbirth wrote: post #59
kstrauser wrote: post #53

Earlier quoted context omitted.

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('…

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.
Post reply on HN