Hacker News Reader

Comment by wibbily | Hacker News Reader

Man nothing drives me further up the wall than when a nice progress indicator with discrete segments gets animated with a lazy `to { rotate(360deg); }` etc[1]. It is my molehill to die on

[1] https://cdn.dribbble.com/userupload/41647820/file/original-8...

View on HN

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.

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

- https://web.archive.org/web/20060427030025/http://www.macosx...

- https://arstechnica.com/gadgets/2005/05/397/

- https://web.archive.org/web/20060506092123/http://www.macosx...

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.

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

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

Also known as Zeno's Progress Bar

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

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?

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.

And of course...

https://xkcd.com/612/

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

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.

The irony of progress indicators like the sunburst here is that everything okd is new again

In the Before Times your UNIX would have a progress bar that was basically the same spinning icon: overwrite - \ | / - \ | / in the same character location in quick succession.

It was as useless then as the spinning sunburst is now.

The linear indicator provides two bits of information: that something is happening, and that progress is being made towards completion. The sunburst only provides one.

you just don't like how it looks, or is there something else wrong with it?

I second everyone talking about fake progress bars, but yeah I was just talking aesthetics. Having a progress indicator with obvious segments and animating it with a smooth tween looks wrong. Compare the above with [1], which is how Apple does it -

[1]: https://cdn.dribbble.com/userupload/20351752/file/original-b...

It's just moving, it gives no actual indication of progress.

Back in the dark ages, "idiot dots" or "idiot marks" was a phrase I heard for the various text terminal equivalents.

It would cycle through a small number of text values with some kind of backspace/overwrite to keep things localized to where the cursor ought to be.

One version was a variable length ellipses: . .. ... that would grow and reset in place.

Another was an expanding "dot": . o O that would cycle in place as one character.

And the early "spinner" was: - \ | / that would cycle in place as one character. Hmm, not sure this will render properly on HN but it is hyphen, backslash, pipe, forward slash.

The latter is known as a "twiddle" in BSD land.

(c.f: https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/sys/...)

Also back then the movement of the symbols was kind of proof that the program was still running properly and not crashed because it had to be updating the symbols. But nowadays, waiting animations are independent of the thing they're waiting for and their movement isn't a sign of life but just a puppet made from a corpse.

this reminds me of a tool at work that uses a progress bar but the software doesn't calculate the job size so it just fills up quickly and then goes back down again, and repeats endlessly.

I don't have the time to research where I heard this, but I recall a UI focus group study that found pretty much equal user satisfaction between accurate linear progress bars and random progress bars, but universal dissatisfaction with progress bars that "reset". My own feelings mirror this finding.

I called those Congress bars, con being the antonym of pro.

Reply on news.ycombinator.com