[HN Gopher] Rounding Percentages
___________________________________________________________________
Rounding Percentages
Author : tavianator
Score : 29 points
Date : 2024-06-27 21:04 UTC (4 days ago)
(HTM) web link (tavianator.com)
(TXT) w3m dump (tavianator.com)
| pmw wrote:
| 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.
| kortex wrote:
| 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.
| chriscjcj wrote:
| I agree with Tavian Barnes' arguments 110%.
| ajuc wrote:
| > 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.
| silvestrov wrote:
| 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%).
| hunter2_ wrote:
| 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.
| nritchie wrote:
| How about "Pending" and "Complete" for 0% and 100%?
| threatripper wrote:
| 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.
| shhsshs wrote:
| > 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?
| alkonaut wrote:
| The motivation for the seemingly strange rounding is that a set
| of numbers can be rounded before summing without biasing the
| sum. It has good use cases but so do all rounding modes.
| AnotherGoodName wrote:
| 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.
| chatmasta wrote:
| If you can cleanly segment the loading progress into multiple
| steps, you may as well render a label above the loading bar
| that says what it's currently doing.
| AnotherGoodName wrote:
| We're often limited to showing progress on a percentage bar
| UX wise for various reasons, particularly on mobile devices.
| I'd also give thought that each technical step may as well
| read something similar to 'reticulating splines' as far as an
| end user is concerned.
| mewpmewp2 wrote:
| Usually even technical terms are interesting since you have
| to wait anyway. Makes your imagination go.
|
| Unfortunately it is much rarer nowadays and everything is
| hidden away.
| fourteenfour wrote:
| The time a user will read it is when the program stalls
| unexpectedly on a particular step. A support ticket or
| forum post which includes the step it stopped at will be
| easier to troubleshoot.
___________________________________________________________________
(page generated 2024-07-01 23:01 UTC)