3 ms·

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

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

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

josteink 5y ago

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