Hacker News Reader

Huh... loading bars do not have to move evenly and smoothly. You reduce all your loading activity to a checklist, scale that to 100%, and update the progress bar with the number of checklists completed as soon as you are able

The bars themselves only have a couple of important fields... total items and items completed. I'm not understanding all this other complexity you are specifying

If you're just counting 'x of y things done' is that really a helpful measure of progress? Say the first 100 items on the list take 1ms except for the last item which takes 30s. your progress bar will be stuck at basically complete waiting for the last item to complete which doesn't feel like you're really communicating anything useful about progress.

It would be for me.

Anything is better than a fake progress bar that turns into a static image as though it's frozen.

Depends on how you think of progress; as a function of total time or a function of total amount of elements on 'checklist'

It actually is, as with some time, you learn which phases take what amounts of time in a normal situation. This lets you judge pretty quickly how long loading should take - or if something goes wrong.

> Say the first 100 items on the list take 1ms except for the last item which takes 30s.

Yes, in your worst-case scenario, this would be the case - but when would that scenario occur. If each state of the progress bar represents a different operation (as in the gmail scenario), you can structure the different states in such a wy that this doesn't happen.

If different states represent different slices of same operation (e.g. copying files), it's not really likely that ine slice of the same operation always takes a disproportionate amount of time, compared to the other slices.

Progress bars measure progress, not time remaining. I don't understand all these other rules people have come up with about them, maybe we need to stop making it so complex

There is a set amount of HTTP requests happening when you load gmail. When I just tried it out now, it seems to be about 200 before the page has fully loaded. Instead of doing all of what you wrote, figure out which request is the last one, and a couple of the ones in the middle and make the progressbar incrementally go up as the browser finishes the requests.

This is typically how games handle it, since the loading is split into "components"/"groups" anyways, so each "group" acts as a checkpoint, maybe around 20% of the total loading time. If you're loading assets, you could just animate the progress between loading those assets, within the group as well, otherwise just animating the bar moving between the groups.

Tada, you have a progress bar that actually bars progress, and it's still simple.

> you have a progress bar that actually bars progress, and it's still simple.

but is it simpler than an animation? And is an "actual" progress bar any better for the user than the fake one?

> And is an "actual" progress bar any better for the user than the fake one?

In the best case, no, because the progress bar disappears so quickly you hardly notice it.

But in the worst case scenario, yes, it's useful to see that your connection dropped, rather than finding it out after waiting for something that is not even actually waiting.

> But in the worst case scenario, yes, it's useful to see that your connection dropped, rather than finding it out after waiting for something that is not even actually waiting.

Gmail handles failed connections separately from the loading bar animation code. If network connection fails during the initial page you get an error page instead of a hung loader. If loading fails during use of the page you get an offline indicator. If you have network but it's performing horribly you'll get a suggestion to use the basic static interface.

None of that logic is dependent on how the progress bar is moved.

Ok, so instead showing an actual loading indicator, you show a fake loading indicator and then put in additional complexity to detect loading timeouts.

How is this simpler than just showing a real loading indicator and let the user react to timeouts?

The user has more knowledge about their internet connection than gmail, so they will likely have better knowledge how long the page usually takes to load.

> Ok, so instead showing an actual loading indicator, you show a fake loading indicator

Yes, this is the part that is simplified

> and then put in additional complexity to detect loading timeouts.

No, there is no "additional complexity" to put in. Even if the page had no loading bar at all these functions are needed, exactly as implemented, to let the user know if their mailbox is having trouble synchronizing while the tab remains open.

These functions however don't tell loaded percentage (as it's a continuously synchronizing page) they just tell connectivity status. The additional complexity would be special functions to tell initial page loaded percentage just to move the loading bar exactly instead of falsely.

> The user has more knowledge about their internet connection than gmail, so they will likely have better knowledge how long the page usually takes to load.

Not sure what this part was in response to but I'd say it makes a great argument as to why the loading splash screen shouldn't actually try to estimate how much of the initial loading has passed.

> And is an "actual" progress bar any better for the user than the fake one?

Absolutely.

> When I just tried it out now, it seems to be about 200 before the page has fully loaded.

Gmail was ready long before that. Most of those requests are just pre-loading the immediately visible email threads in the background.

Disclaimer: not associated with Google, but have reverse-engineered the Gmail XHR-format for (non black-hat) web-extension purposes.

> 2. would need to know # of assets to be downloaded by the user (since # of assets, not just file size, affects load time)

Progress bars are typically where AI would excell. After a while, the algo looks like this:

- “I know that at 34/93 items, there are generally 3 seconds left.”

- “I know that in 5% of situation, instead of going smoothly at 64/93, it takes 7 minutes more”

- “So I’ll show a progress bar that goes smoothly.”

It would be great because it would benefit from other people’s install/loading experience, and we could stop trying to make it smooth as a developer by typing “x3 weight for files, x7 weight for dependencies…”.

Please don’t download TensorFlow as a JS dependency, though ;)

Sounds like a great idea! And in the future we would need to dedicate at least one discrete GPU exclusively to AI progress bars, right? Would drive sales. So seems legit, doesn't it? ;-)

But maybe, just maybe, AI isn't the right answer for everything. Especially loading indicators…

I get it, this is a hard problem to solve. BUT it is a terrible user experience to:

a) not even have an estimate of how long something will take.

b) not know if your damn process has frozen due to an error.

c) not know what actions are actually happening.

>unneeded complexity when instead, you can just display an animation to distract the user while the page loads

Blatant disrespect of your users is so 1995. If respecting your users is seen as simply adding complexity then you have failed to respect the mantra of "delight your customers." Or, more likely, your incentives are misaligned due to predatory business models.

> Blatant disrespect of your users is so 1995

I think that's more apt for 2021, the era of fake loading bars, lying to the user, hiding functionality, sacrificing performance for labor costs and harvesting private information.

Back in the 90s, UIs were more likely to give you statistics you might or might not care about instead of vacuous animations, and they were fast as hell.

You're correct, but I was talking about the actual attitudes of coders, which were remarkably hostile towards users in the 90s.

100% a K.I.S.S. is their old non-javascripted Gmail interface that never needed a loading bar.

The old interface is still there https://mail.google.com/mail/?ui=html and will be recommended if the client is underperforming during loading the new interface.

I wouldn't call it having JS a simple matter of KISS though, features like live refresh seem to be core to an email portal not an over complication.

I don't want my email web client to live refresh. I check a given inbox when I have the energy to respond.

And some people like a car with a manual transmission but in either case it has nothing to do with KISS when talking about an automatic car. KISS is about removing unnecessary complexity from a design not removing functionality from the design to simplify it.

Is there a reason meta refresh isn't good enough?

pretty sure KISS is about removing some functionality to simplify, like "don't be over-ambitious"

The entire page loads faster than most "AJAX" interactions on full-fat Gmail. Plus it doesn't use more memory than my first three Web-connected computers had combined, for a single tab.

Only way Gmail's tolerable.

Their worst version isn't full-fat Gmail, though, but their lite mobile version. They've done something idiotic with touch & scrolling on there that causes "stop the scroll" touches to register as taps on elements, making it damn near unusable. You fling-to-scroll, tap-and-hold to stop, but it takes the tap-and-hold as a touch on whatever's under your finger. Also triggers tap-events it when you're making multiple scrolling swipes. I dunno what it is about Google and fucking up mobile web interfaces for no reason. AMP pages also had inexplicable make-scrolling-shitty code in them, which was part of why I hated them. Why put in more work to make mobile suck? It makes no sense.

AMP scrolling was broken on iOS because of an iframe scrolling bug in Safari that, like any Safari bug, wasn't fixed for ages. I never experienced any issues on Firefox or Chrome on Android. https://medium.com/@dvoytenko/amp-ios-scrolling-redo-2-the-s...

Why even show a (falsely) determinate progress bar over an indeterminate one then?

An indeterminate circular progress bar would distract the user just as much but with less lying.

Probably because in the normal case where it does finish loading relatively quickly, the progress bar causes the perception of faster loading.

If the "loading bar" moves everyone once in a while, it acts as a "did the page freeze" indicator. "Should I reload the page... oh, it just moved up a little."

K.I.S.S would be no loading bar at all. The least amount of work and also not baldface lying to users.

I agree, but want to add to this by saying there should still be some indicator that a background process is happening.

This is effectively done via a "spinner".

While a loading bar would be better than a spinner in most cases, that is only the case if the loading bar is actually indicative of progress. If a dev team doesn't (or can't) produce a semi-accurate loading bar, then just throw a spinner up and call it a day.

But it is still nice to have a spinner to let the user know that something is happening in the background that you can't see. Just displaying a blank screen or a fancy envelope icon can confuse users and cause them to refresh the page or click the back button in a panic to get to what they are expecting (a screen of their inbox).

Progress bars are ideal. But they need to actually work if you have them. But table stakes for modern software is at least a spinner to inform the user that something is happening in the background.

ye totally agree with that. Spinner + some sort of semantic explanation. Like simply the text "loading gmail" or whatever. Tell the user what is happening.

> I agree, but want to add to this by saying there should still be some indicator that a background process is happening.

This is effectively done via a "spinner".

If spinners actually indicated that, it would be useful.

Unfortunately, most spinners in web apps - like this one - are simply static animations replayed by the browser, without any actual involvement by the app's code. All they indicate is that the browser didn't freeze - something I usually already know if I have another tab open.

They don't give me any information about the actual application: The browser will happily keep the animation running even if the app's JavaScript is already brain-dead or if the app has long lost all connectivity.

> This is unneeded complexity when instead, you can just display an animation to distract the user while the page loads.

But that's exactly it - a distraction. It doesn't give any information to the user, not even if the page is actually loading. This thing will happily keep on spinning even if there is a network outage.

Or you know, set a maximum payload size to load the main page then load the rest of the needed content (when it is actually needed). Set a well known header on the contents and use that header (and the time it took to retrieve it) as a way to detemine the aprox time it would take to retrieve your well known payload size... I know I am over simplifying it but... Its Google and they hire some of the most brilliant minds in the wolrd and put them to do unit tests... I think many of them would be happy to be put up to a problem of this type

All difficult, but no need to reinvent the wheel - these could also be standard(ised) widgets/libraries/services; possibly build into the OS/browser.

If any(one) is in a position to provide that, it's goog.

I think it would also be neat to have standardised conventions for progress bars, that possibly encode more complex information e.g. uncertainty, which bar sections are io/net bound etc. Again, low level standardisation would help.

Helpful, built-in browser UI elements are being left to rot rather than improved, so I doubt that'll happen. See, for example, the HTTP auth login prompt. That could have been improved into something actually desirable to use for authentication on most sites, and saved god knows how many developer hours across the globe that go into making login screens & flows. Browsers should have started building in payment input screens a decade ago, for similar reasons. It'd give us better security, better compatibility, better accessibility, and save huge amounts of duplicated effort. Many millions of dollars saved across the economy, every year, with something like that.

But no.

>Progress bars are inherently difficult to create since you need to predict the future to provide an accurate status on progress.

No. You just need to display the progress.

If you need to load X KB in assets, and you have loaded Y KB in assets, that's all you need.

You don't have to add time estimations. You could, but you don't have to.

How can you from JavaScript see how much of an asset has loaded?

Presumably this can be calculated server-side. So you could send the full size right away which the JS could use to calculate loading progress.

You mean we should invent something like the HTTP Content-Length header?

> If you need to load X KB in assets,

How do you know what you need to load in the first place? For sufficiently advanced applications this might be harder than you think.