Hacker News Reader

Comment by fgdelcueto | Hacker News Reader

When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.

View on HN

Most users don't understand that making an accurate progress bar is incredibly hard, for most tasks. Is not very intuitive, but once you start looking in to it you realize that almost nothing in a computer is deterministic. Task switching, cashes, file system buffers, disk fragmentation, variable clock frequencies, and loads of other factors, make the speed of a computer very hard to estimate.

I do favor progress bars that say things like "you have downloaded 47% of file X", because its a statement of fact, not an estimation of future performance.

Progress Bars are the most user visible insight into The Halting Problem that our entire industry has. In so many cases, if we knew exactly how long things would take to compute we'd have already computed them or we'd have a world bending solution to The Halting Problem that would change everything. It's really hard to describe NP Complete/NP Hard to the average user, and it shouldn't be a surprise that the poor tool that keeps having to do it over and over again in so many places and ways, the lowly progress bar, keeps getting blamed for our industry having failed to solve (and unlikely to ever solve) The Halting Problem.

I often see the suggestion to display spin animations instead since estimation is often incredibly difficult if not impossible. I prefer progress bars because even if they aren't accurate, the relative directional growth shows me that something is actually executing. With a spin animation, for all I know, somethings caught in a loop.

This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve.

Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indication of true activity. After all, you still can't tell whether the progress bar kept moving, but the process is stuck in a loop.

>This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve.

The problem that people might assume the computer is stuck in a loop or at any rate that the animation is not going to stop is related to spinner animations on websites. Since the spinner is not a function of the browser, but is instead something implemented in the individual site's code, then stopping the spinner needs to be also coded for and many sites neglect to write the code for "when error happens stop spinner and tell them that things went wrong".

So over time people exposed to negligent website spinners start to suspect any spinner that takes too long.

That's because spinners used to show that the main thread was still responsive, but these days are used in different contexts where this isn't really something that it applies to anymore.

right, I guess that says it more succinctly.

In the old days of 68K Mac, it could be even worse. The spinning hourglass was often animated during a timer interrupt, while the main application might have died altogether.

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

It reminds me of the old (maybe it still does it, I dunno) windows install progress bars vs ones where multiple things are wrapped into one.

With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator.

Those old windows installers used two bars: the top one was basically a steps indicator (file N of M, for example) -- just like the single bar for multiple tasks. But the second bar was a per-file bar. So if step 99 took longer, you had a second bar showing you that steps/files progress.

Yeah, I think I remember those! If it were me, I would turn the segmented bar into a checklist, since you can add a description and I think it looks nicer. But the approach was a good one imo.

Sure, that top bar is a "steps completed" bar, so something other than a normal progress bar may be better. A checklist would work, unless space confined. Depends on the number of items. Maybe a segmented bar where it fills one segment for each item. If there are a lot of items, though, just an "X/Y steps completed" may work best: its simple and easy to understand.

I played with the idea of using a singular circular progress bar for composite progress notification. The basic idea was that if you keep the tail chasing the head, and the head always moving clockwise, the progress bar never gives the impression that it "shrinks backwards", it is always forward motion, but in the worst case when the tail catches up with the head (you discover more sub-tasks) it basically becomes a spinner until the tail starts to lag the head again. Tuning the animation parameters for that provided a lot of options to get a good feeling progress bar that reported a heterogeneous source of various tasks, some of which discovered/added while in progress of the overall whole.

My demo has unfortunately fallen to web bit rot and needs to be updated, but the code is here to explore: https://github.com/worldmaker/compradprog

Back in Windows 3.11 days, I noticed a patter with installers. Their progress bar would go steadily up for quite a while, and then suddenly spend 3x as long on just one or two percentage points.

It didn't take me long to realize that the progress bar measured bytes written to disk, but when it was seemingly "stuck", it was creating a lot of small files.

Instead of bytes written, what I really cared about is "how done are you?" and that would have been better represented by a function of both number of files created _and_ bytes written. I don't think the weighting of those two had to be very accurate to be a big improvement.

Exactly! The biggest problem with most progress bars is that they tie together multiple unrelated things that aren't even measured in the same way to a single indicator.

If there are multiple independent tasks, give me multiple independent indicators of their state. Multiple instances of the same class of task can of course be grouped, you don't need to list every file copy independently, but a file copy and an external dependency installer shouldn't be two stops on the same progress bar.

It would be nice if they were accurate, but with my limited experience making them, I don't expect them to be. I've actually had the fact they are there screw up rendering.

Whatever Apple is doing for iOS and MacOS updates isn’t cutting it...

Reply on news.ycombinator.com