Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rounding Percentages

tavianator.com

Post reply on HN
Print view View original

1–10 of 30 posts

Re: Rounding Percentages

#2

Post by pmw »

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.

Re: Rounding Percentages

#4

Post by kortex »

pmw wrote: post #2

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.

Many TUIs (text user interface) with multiple operations will show one bar reach 100% and move onto the next process (or show multiple in parallel).

If the UI automatically transitions to a totally new screen after completion, I'm never going to see 100% anyways, unless the app does the exact infuriating thing in TFA, which is render 100% (at 99.whatever) and then do some fsync/cleanup and actually be frozen showing 100% which is the contrapositive of oddly satisfying, it's unsurprisingly unsatisfying.

Re: Rounding Percentages

#5

Post by ajuc »

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

Re: Rounding Percentages

#7

Post by [deleted] »

ajuc wrote: post #5

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

[deleted]

Re: Rounding Percentages

#8

Post by threatripper »

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.

Re: Rounding Percentages

#9

Post by silvestrov »

ajuc wrote: post #5

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

Problem is the rounding in the text: 12.1 MB of 12.1 MB downloaded.

You can't see if this is 99% or not.

All digits even become difficult with large numbers: 175.464.272 of 175.484.272 downloaded (i.e. not 100%).

Re: Rounding Percentages

#10

Post by hunter2_ »

silvestrov wrote: post #9
ajuc wrote: post #5

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

Problem is the rounding in the text: 12.1 MB of 12.1 MB downloaded. You can't see if this is 99% or not. All digits even become difficult with large numbers: 175.464.272 of 175.484.272 downloaded (i.e. not 100%).

How about "N remaining"? Anything that isn't zero means it's still in progress or stalled. Only abbreviate (via thousands indicators like K, M, G, etc.) when it actually shortens the text meaningfully, so there will be no truncation or rounding toward the end.
Post reply on HN