7 ms·

Progress bars are inherently difficult to create since you need to predict the future to provide an accurate status on progress. Let's just consider what would

Progress bars are inherently difficult to create since you need to predict the future to provide an accurate status on progress. Let's just consider what would factor into an accurate status bar. Gmail would need to know in advance: 1. the total payload size (which is different for everyone since some might have locally cached assets and everyones inbox size is different) 2. would need to know # of assets to be downloaded by the user (since # of assets, not just file size, affects load time) 3. how fast your computer will render the webpage (different processors, browsers, versions, etc all affect load time) 4. how fast is your internet connection and pack loss (more pack loss on mobile networks, etc) 5. is there any blocking content on the page that will affect delaying "first paint". (Why things like Lighthouse exists) And many more factors. This is unneeded complexity when instead, you can just display an animation to distract the user while the page loads. This is 100% a K.I.S.S.

alickz 5y ago
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.
- tshaddox 5y ago
  Probably because in the normal case where it does finish loading relatively quickly, the progress bar causes the perception of faster loading.
  - saalweachter 5y ago
    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."
capableweb 5y ago
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.
- chii 5y ago
  > 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?
  - xg15 5y ago
    > And is an "actual" progress bar any better for the user than the fake one? Absolutely.
  - capableweb 5y ago
    > 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.
    - zamadatix 5y ago
      > 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.
      - xg15 5y ago
        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.
Chris2048 5y ago
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.
- handrous 5y ago
  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.
taytus 5y ago
>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.
- Kiro 5y ago
  How can you from JavaScript see how much of an asset has loaded?
  - frosted-flakes 5y ago
    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.
    - still_grokking 5y ago
      You mean we should invent something like the HTTP Content-Length header?
- madeofpalk 5y ago
  > 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.
laurent92 5y ago
> 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 ;)
- still_grokking 5y ago
  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…
everyone 5y ago
K.I.S.S would be no loading bar at all. The least amount of work and also not baldface lying to users.
- jacurtis 5y ago
  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.
  - everyone 5y ago
    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.
  - xg15 5y ago
    > 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.
tomc1985 5y ago
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
- remus 5y ago
  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.
  - nacs 5y ago
    It would be for me. Anything is better than a fake progress bar that turns into a static image as though it's frozen.
  - sortskur 5y ago
    Depends on how you think of progress; as a function of total time or a function of total amount of elements on 'checklist'
  - xg15 5y ago
    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.
AnIdiotOnTheNet 5y ago
100% a K.I.S.S. is their old non-javascripted Gmail interface that never needed a loading bar.
- zamadatix 5y ago
  The old interface is still there https://mail.google.com/mail/?ui=html 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.
  - wintermutestwin 5y ago
    I don't want my email web client to live refresh. I check a given inbox when I have the energy to respond.
    - zamadatix 5y ago
      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.
      - AnIdiotOnTheNet 5y ago
        Is there a reason meta refresh isn't good enough?
      - fsckboy 5y ago
        pretty sure KISS is about removing some functionality to simplify, like "don't be over-ambitious"
- handrous 5y ago
  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.
wintermutestwin 5y ago
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.
- redwall_hp 5y ago
  > 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.
  - wintermutestwin 5y ago
    You're correct, but I was talking about the actual attitudes of coders, which were remarkably hostile towards users in the 90s.
ordiel 5y ago
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
xg15 5y ago
> 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.

alickz 5y ago

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.

tshaddox 5y ago
Probably because in the normal case where it does finish loading relatively quickly, the progress bar causes the perception of faster loading.
- saalweachter 5y ago
  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."

capableweb 5y ago

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.

chii 5y ago
> 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?
- xg15 5y ago
  > And is an "actual" progress bar any better for the user than the fake one? Absolutely.
- capableweb 5y ago
  > 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.
  - zamadatix 5y ago
    > 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.
    - xg15 5y ago
      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.

Chris2048 5y ago

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.

handrous 5y ago
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.

taytus 5y ago

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

Kiro 5y ago
How can you from JavaScript see how much of an asset has loaded?
- frosted-flakes 5y ago
  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.
  - still_grokking 5y ago
    You mean we should invent something like the HTTP Content-Length header?
madeofpalk 5y ago
> 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.

laurent92 5y ago

> 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 ;)

still_grokking 5y ago
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…

everyone 5y ago

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

jacurtis 5y ago
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.
- everyone 5y ago
  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.
- xg15 5y ago
  > 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.

tomc1985 5y ago

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

remus 5y ago
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.
- nacs 5y ago
  It would be for me. Anything is better than a fake progress bar that turns into a static image as though it's frozen.
- sortskur 5y ago
  Depends on how you think of progress; as a function of total time or a function of total amount of elements on 'checklist'
- xg15 5y ago
  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.

AnIdiotOnTheNet 5y ago

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

zamadatix 5y ago
The old interface is still there https://mail.google.com/mail/?ui=html 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.
- wintermutestwin 5y ago
  I don't want my email web client to live refresh. I check a given inbox when I have the energy to respond.
  - zamadatix 5y ago
    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.
    - AnIdiotOnTheNet 5y ago
      Is there a reason meta refresh isn't good enough?
    - fsckboy 5y ago
      pretty sure KISS is about removing some functionality to simplify, like "don't be over-ambitious"
handrous 5y ago
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.

wintermutestwin 5y ago

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.

redwall_hp 5y ago
> 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.
- wintermutestwin 5y ago
  You're correct, but I was talking about the actual attitudes of coders, which were remarkably hostile towards users in the 90s.

ordiel 5y ago

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

xg15 5y ago

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