5 ms·

You know talking about progress bars, it takes a lot of confidence to program a linear progress bar. You think you know when loading will be complete and think

You know talking about progress bars, it takes a lot of confidence to program a linear progress bar. You think you know when loading will be complete and think you know can break down the incremental progress made during loading. Instead we get these spinning wheels that are like "maybe in the future this wheel will stop and we will have a return value." No confidence whatsoever. I know this is true because Apple tries to implement progress bars in IOS like real chads. But their progress bars are just fake. They are a cheap animation all the way up to 90% and just stop moving until the progress is actually complete which could be 5 seconds of 90% and 40 seconds of the last 10%. So they think they are chad but lie.

bigstrat2003 1y ago
I would imagine that progress bars generally represent the progression of the task state and not time, for that very reason. Or is that not the case in practice?
- int_19h 1y ago
  It is, but traditionally progress bars were often paired with labels showing estimated remaining time. That said, back in DOS era, this kind of thing was much more straightforward because most operations that would warrant a progress bar involved some kind of disk I/O, which - if you amortize it - is fairly linear, so one can estimate the completion time relatively well. In more complicated cases - e.g. Win95 installer doing things like hardware detection - those estimates were often wildly off.
  - SoftTalker 1y ago
    And of course... https://xkcd.com/612/ https://xkcd.com/612/
rzzzt 1y ago
There's also the "Achilles and the tortoise" solution where the progress bar consumes the remaining 80% of unclaimed space in each iteration.
- kmoser 1y ago
  Also known as Zeno's Progress Bar
01HNNWZ0MV43FF 1y ago
I think the most common operations a user will see is stuff like CRUD, which means you're waiting on a remote database and a network round trip Hard drives and networks are both so fast that you rarely are waiting for data to stream, you're just waiting for the stream to begin
Hobadee 1y ago
Progress bars are very hard. I implemented a PowerShell progress bar in a script I wrote, and even that was hard. The script did a nested iteration, deleting objects and re-starting the iteration. I updated the progress bar based on completion of the outermost iteration, but because of how things processed, the progress bar would move more or less logarithmicly; super fast at the start, but slowing down significantly at the end. I'm sure I could have made the progress bar move more smoothly, but it would have required restructuring my entire program. (It probably needed it, but for a simple script I ran occasionally, not worth it.)
Lammy 1y ago
> I know this is true because Apple tries to implement progress bars in IOS like real chads. Back in The Day, Mac OS X Tiger just faked it by measuring how long it took to boot to LoginWindow, writing that number of seconds to a file, and displaying the next boot's progress indicator as a percentage of that time. Power words: `/usr/libexec/WaitingForLoginWindow` and `/var/db/loginwindow.boottime` - https://daringfireball.net/misc/2005/04/tiger_details#waitingforloginwindow https://daringfireball.net/misc/2005/04/tiger_details#waitin... - https://web.archive.org/web/20060427030025/http://www.macosxhints.com/article.php?story=20050614201205203 https://web.archive.org/web/20060427030025/http://www.macosx... - https://arstechnica.com/gadgets/2005/05/397/ https://arstechnica.com/gadgets/2005/05/397/ - https://web.archive.org/web/20060506092123/http://www.macosxhints.com/article.php?story=20050517121748796 https://web.archive.org/web/20060506092123/http://www.macosx...
- doubled112 1y ago
  Measuring the time it takes to complete a process and using that for the progress bar on the next run seems like the opposite of faking it to me.
  - Lammy 1y ago
    Calling it fake also doesn't mean I'm calling it poor engineering; in fact the opposite since it's very accurate for the common use case of a computer that's used on a day-to-day basis with no major hardware or software changes. It's fake in the same way that illusion magic like slight of hand is fake. Its not lying to anyone about what it is, because it prompts your senses in a particular way that causes your brain to lie to itself! The slight of hand is this: - Observable fact: Taking the computer from a fully-powered-off state to a usable state happens when the user presses the power button, involves loading the operating system from slower disk to faster memory, and takes some amount of time to complete. - Observable fact: `WaitForLoginWindow` is the first “Aqua” UI element one sees after powering their computer on, the first visible thing that's drawn by the operating system that's being loaded instead of drawn by OpenFirmware or by BootX. - Observable fact: Aqua has an `NSTabView` control used for grouping panes of related UI elements. In original 2001 Aqua, NSTabView looked like something that “stuck out” toward the user from a window. In Panther (2003) it was redesigned into something that looks “sunken in” to visually allow for nesting multiple layers of grouping. - Observable fact: Panther-style NSTabViews get progressively darker as they are nested, indicating controls which are “more related”. See here for an example of four layers of nested NSTabView: https://cdn.arstechnica.net/wp-content/uploads/archive/mac-os-x-10.3/nested-tabs.png https://cdn.arstechnica.net/wp-content/uploads/archive/mac-o... - Observable fact: Any OS X user will be familiar with `NSProgressIndicator` as the UI control they see when they tell their computer to do something and some aspect of the computer itself (like disk or network bandwidth) is the limiting factor causing their action to be non-instantaneous. - Observable fact: The progress indicator is the only part of `WaitForLoginWindow` that moves, and it's grouped with a text label reading “Starting Mac OS X…” in what looks to be a `noTabsBezelBorder`-styled `NSTabView` even though the grouping-box and even the “Starting” text are actually just a static image that the Wait window draws and overlays the progress indicator on, not really Aqua controls because the UI frameworks are still being loaded. - Illusion magic: Look at the Tiger boot screen, compare it to the previous link, and notice how the fake grouping pane is as dark as what four nested levels of real NSTabViews would be: https://cdn.arstechnica.net/wp-content/uploads/archive/journals/apple.media/thumb/200/200/starting_macosx.jpg https://cdn.arstechnica.net/wp-content/uploads/archive/journ... The coloration makes your own brain tell you that the progress indicator and the “Starting Mac OS X” text are as related as any two UI elements could possibly be, more related than any other pair of UI elements you will ever encounter in Mac OS X, because no reasonable application designer would ever nest four layers of NSTabView. Since the progress indicator is so strongly visually grouped with the “Starting Mac OS X” text, and every Macintosh going back to 1984 has displayed some form of “Welcome to Macintosh” text while the OS is loading from disk, and progress indicators are the UI element for long-duration user-initiated work, and the computer was fully off so pushing the power button was the only thing the user did, and the wording of “Starting” means it isn't fully “Started”, then the progress indicator must represent how much of the OS is loaded in the current session, right?
pcblues 1y ago
A CorelDraw version from the 1990s I used had an honest progress bar. Sometimes it went backwards, but by the time it got to the end, it was truly finished.

bigstrat2003 1y ago

I would imagine that progress bars generally represent the progression of the task state and not time, for that very reason. Or is that not the case in practice?

int_19h 1y ago
It is, but traditionally progress bars were often paired with labels showing estimated remaining time. That said, back in DOS era, this kind of thing was much more straightforward because most operations that would warrant a progress bar involved some kind of disk I/O, which - if you amortize it - is fairly linear, so one can estimate the completion time relatively well. In more complicated cases - e.g. Win95 installer doing things like hardware detection - those estimates were often wildly off.
- SoftTalker 1y ago
  And of course... https://xkcd.com/612/ https://xkcd.com/612/

rzzzt 1y ago

There's also the "Achilles and the tortoise" solution where the progress bar consumes the remaining 80% of unclaimed space in each iteration.

kmoser 1y ago
Also known as Zeno's Progress Bar

01HNNWZ0MV43FF 1y ago

I think the most common operations a user will see is stuff like CRUD, which means you're waiting on a remote database and a network round trip Hard drives and networks are both so fast that you rarely are waiting for data to stream, you're just waiting for the stream to begin

Hobadee 1y ago

Progress bars are very hard. I implemented a PowerShell progress bar in a script I wrote, and even that was hard. The script did a nested iteration, deleting objects and re-starting the iteration. I updated the progress bar based on completion of the outermost iteration, but because of how things processed, the progress bar would move more or less logarithmicly; super fast at the start, but slowing down significantly at the end. I'm sure I could have made the progress bar move more smoothly, but it would have required restructuring my entire program. (It probably needed it, but for a simple script I ran occasionally, not worth it.)

Lammy 1y ago

> I know this is true because Apple tries to implement progress bars in IOS like real chads. Back in The Day, Mac OS X Tiger just faked it by measuring how long it took to boot to LoginWindow, writing that number of seconds to a file, and displaying the next boot's progress indicator as a percentage of that time. Power words: `/usr/libexec/WaitingForLoginWindow` and `/var/db/loginwindow.boottime` - https://daringfireball.net/misc/2005/04/tiger_details#waitingforloginwindow https://daringfireball.net/misc/2005/04/tiger_details#waitin... - https://web.archive.org/web/20060427030025/http://www.macosxhints.com/article.php?story=20050614201205203 https://web.archive.org/web/20060427030025/http://www.macosx... - https://arstechnica.com/gadgets/2005/05/397/ https://arstechnica.com/gadgets/2005/05/397/ - https://web.archive.org/web/20060506092123/http://www.macosxhints.com/article.php?story=20050517121748796 https://web.archive.org/web/20060506092123/http://www.macosx...

doubled112 1y ago
Measuring the time it takes to complete a process and using that for the progress bar on the next run seems like the opposite of faking it to me.
- Lammy 1y ago
  Calling it fake also doesn't mean I'm calling it poor engineering; in fact the opposite since it's very accurate for the common use case of a computer that's used on a day-to-day basis with no major hardware or software changes. It's fake in the same way that illusion magic like slight of hand is fake. Its not lying to anyone about what it is, because it prompts your senses in a particular way that causes your brain to lie to itself! The slight of hand is this: - Observable fact: Taking the computer from a fully-powered-off state to a usable state happens when the user presses the power button, involves loading the operating system from slower disk to faster memory, and takes some amount of time to complete. - Observable fact: `WaitForLoginWindow` is the first “Aqua” UI element one sees after powering their computer on, the first visible thing that's drawn by the operating system that's being loaded instead of drawn by OpenFirmware or by BootX. - Observable fact: Aqua has an `NSTabView` control used for grouping panes of related UI elements. In original 2001 Aqua, NSTabView looked like something that “stuck out” toward the user from a window. In Panther (2003) it was redesigned into something that looks “sunken in” to visually allow for nesting multiple layers of grouping. - Observable fact: Panther-style NSTabViews get progressively darker as they are nested, indicating controls which are “more related”. See here for an example of four layers of nested NSTabView: https://cdn.arstechnica.net/wp-content/uploads/archive/mac-os-x-10.3/nested-tabs.png https://cdn.arstechnica.net/wp-content/uploads/archive/mac-o... - Observable fact: Any OS X user will be familiar with `NSProgressIndicator` as the UI control they see when they tell their computer to do something and some aspect of the computer itself (like disk or network bandwidth) is the limiting factor causing their action to be non-instantaneous. - Observable fact: The progress indicator is the only part of `WaitForLoginWindow` that moves, and it's grouped with a text label reading “Starting Mac OS X…” in what looks to be a `noTabsBezelBorder`-styled `NSTabView` even though the grouping-box and even the “Starting” text are actually just a static image that the Wait window draws and overlays the progress indicator on, not really Aqua controls because the UI frameworks are still being loaded. - Illusion magic: Look at the Tiger boot screen, compare it to the previous link, and notice how the fake grouping pane is as dark as what four nested levels of real NSTabViews would be: https://cdn.arstechnica.net/wp-content/uploads/archive/journals/apple.media/thumb/200/200/starting_macosx.jpg https://cdn.arstechnica.net/wp-content/uploads/archive/journ... The coloration makes your own brain tell you that the progress indicator and the “Starting Mac OS X” text are as related as any two UI elements could possibly be, more related than any other pair of UI elements you will ever encounter in Mac OS X, because no reasonable application designer would ever nest four layers of NSTabView. Since the progress indicator is so strongly visually grouped with the “Starting Mac OS X” text, and every Macintosh going back to 1984 has displayed some form of “Welcome to Macintosh” text while the OS is loading from disk, and progress indicators are the UI element for long-duration user-initiated work, and the computer was fully off so pushing the power button was the only thing the user did, and the wording of “Starting” means it isn't fully “Started”, then the progress indicator must represent how much of the OS is loaded in the current session, right?

pcblues 1y ago

A CorelDraw version from the 1990s I used had an honest progress bar. Sometimes it went backwards, but by the time it got to the end, it was truly finished.