3 ms·

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

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

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.