Remix.run Logo
cons0le 2 days ago

MrBeast is a hack, but its worth pointing out that all "progress bars" are bad design. You could make the same complaint against most of the progress bars in MsDOS. There was never a consistency in timing so you can never really use them to gauge how much time is left.

Vegenoid 2 days ago | parent | next [-]

We’re not talking about a measure of computational progress here. We’re talking about visually representing how much time has elapsed out of a fixed duration. This is exactly where progress indicators shine, the total time for the thing to happen is perfectly specified in advance.

dspillett 2 days ago | parent | prev | next [-]

The difference between a lot of OS/app progress bars for IO (and sometimes CPU) operations and these timers, is that the total length of time for a lot of IO operations is often unknown with any accuracy so you have to use a heuristic to guess the current % done.

For instance: when reading/writing/both many files of differing sizes on traditional drives there is an amount of latency per file which is significant and not always predictable. Whether you base progress on total size or number of files or some more complicated calc based on both, it will be inaccurate in most cases, sometimes badly so. Even when copying a single large file on a shared drive, or just on a dedicated system with multiple tasks running, the progress is inherently a bit random, the same for any network transfer. Worse are many database requests: you don't get any progress often because there is no progress output until the query processing is complete, and the last byte of the result might arrive in the same fraction of a second the first does¹. The same for network requests, though IE (at least as early as v3) and early versions of Edge did outright lie² there to try make themselves look faster than the competition.

The progress bars in videos are a different beast (ahem): the total time is absolutely known, any inaccuracy is either a deliberate lie or gross incompetence.

--------

[1] I once worked on a system that kept logs of certain types of query so it could display a guess of how long things were going to take and a progress bar to go with it, but this was actually more irritating to the users than no progress display as it would sometime jump from a few % directly to done or sit at 99% for ages (in the end the overly complicated guessing method was replaced by a simple spinner).

[2] It would creep up, getting as far as 80%, before the first byte of response is received. This also confused users who thought that something was actually happening when the action was in fact stalled and just going to time-out.

JadeNB 2 days ago | parent [-]

> [1] I once worked on a system that kept logs of certain types of query so it could display a guess of how long things were going to take and a progress bar to go with it, but this was actually more irritating to the users than no progress display as it would sometime jump from a few % directly to done or sit at 99% for ages (in the end the overly complicated guessing method was replaced by a simple spinner).

In the Tiger era, the OS X start-up progress bar worked this way—it kept track of how long boot-ups would take, and then displayed its best guess based on that.

andy99 2 days ago | parent | prev [-]

Many progress bars or other indicators lie, and the incentive is always to make it look good at the beginning, so that’s what we end up seeing most, whether it’s these ad ones (which thankfully I’ve never seen) or installers or especially something like Uber that always lies about how quickly someone is coming to make it appealing and then stretches it out. Even the thing in your car that tells you how much range you have left before refuelling (except it starts showing more than you actually have). I think in all cases it’s probably possible to give a more realistic estimate but it’s counter to the goals of whoever designed it.