Rounding Percentages

A good rule is that showing progress or a stuck state appropriately at all stages takes precedence over other concerns in a progress bar.

So for a video upload from a photo app it's not at all unreasonable to make the first 50% the transcoding step and the second 50% the actual upload and show progress of each step within those percentages. Some people may read this with horror; the transcoding step might be much faster/slower! It's not accurate! But the point is the user can at least see progress/no progress. You aren't allowing an upload bar to sit at 0% because you prioritised a % accurate upload over a progress bar that represents all stages of progress. It's better the progress bar move faster/slower at various stages than a progress bar that simply misses stages.

This goes for loading screens that sit at 100% for a while too. I'd prefer if they reserved some percentage of the loading bar for those 'post 100%' steps and continued to show progress. End users won't care if it's not all the same speed as much as they'll care about stuck progress bars.

> Is it actually done? Or did it download 999/1000 bytes and then hang?

The label on the progress bar should be "12345 out of 23456 files copied" and not 53% for this reason.

That way you can see if it hanged even if the progress is very slow.

Besides - the percentage label is redundant - the bar shows it graphically anyway.

I just got reminded that round(0.5) is poorly defined across different languages and your results may vary if you use this algorithm without properly understanding what round() does in your language vs. what is expected by the algorithm.

How about "Pending" and "Complete" for 0% and 100%?

A little while ago, an article about a “plan-execute pattern” came up, feels like a clean fit to better progress bars to me! I think the most annoying thing is definitely when only 1 part of the process is represented in the progress bar, like a video upload that only shows upload progress, but not the transcoding that happens after.

Feels like having some standard plan + execution status interface would at least force you to consider a whole process even if that multistep plan is basically hardcoded.

https://news.ycombinator.com/item?id=40749401

Not sure how much I like this. With this algorithm, the user would never see 100% displayed, because at that point the UI would change to remove the progress bar entirely. Whereas seeing 100% feels oddly satisfying, even if inaccurate.

I agree with Tavian Barnes' arguments 110%.

> If your language has bad defaults, you may have to ask for the right rounding mode explicitly.

Is the author implying Rust's default rounding behavior is a bad default? In what world is "ties to even" a GOOD default?

And a really bad example - apps from a certain large search/email/ad company where the progress bar moves even when nothing is actually happening ;(

I'm afraid this introduces too much magic

Personally, "0%" doesn't mean "hasn't started" to me, it means "not enough progress has happened to reach 1%". Assuming I'm not alone with that, the rounding becomes a simple truncation `roundedPercent = int(percent)`

An implementation as simple as the concept, which is a good sign in my experience

To solve this problem recently, I just defined -1% as 'not at all' and 101% as 'all of it' .

But then, I'm a Unix hacker. ;)

> float

hm ...

  >>> def percent(progress, total):
  ...     return round(99 * progress / total + 0.5)
  ...
  >>> x = 9007199254740990.0
  >>> x - 1 < x
  True
  >>> percent(x - 1, x)
  100