Full-screen "loading" overlay in desktop browsers

Question

We've recently introduced a full-screen modal for loading operations in our web app to provide better UX for small screens. The problem was that the loading spinner we had before was sometimes out of screen on small screens.

Our solution just displays a semi-transparent overlay with a spinner in it for operations that take a moment for the server to process it - usually this is fast, but on slower connections it can take a few seconds. I think the overlay provides a good UX on mobile devices.

We now tried to use the same overlay for large screens, too. While some of our team members like it, others think that it is very distracting. Especially when server-side operations complete quickly, the semi-transparent modal appears in just a quick flash, leaving the user wondering what just happened.

Are there any best practices or guidelines about full-screen "loading" overlays in web applications? Are they good, or should they be avoided?

Note that the quick flash can happen on mobile devices too, but there it is less distracting because the screen is smaller and users are more used to full-screen loading modals on such devices.

Answer 1

"Loading" screens, progress bars, spinners, or the like are necessary for operations which take enough time that the user needs reassurance that the program hasn't crashed or become unresponsive. For shorter-duration operations, a spinner or loading screen can actually increase the perceived duration (if not the actual duration) of the delay.

There has been a fair amount of research on perceived performance, including how the design of a progress bar can affect the perceived delay (a "backwards moving and decelerating ribbed progress bar" was perceived in this study as 11% faster than actual time, for example) -- but in general Jakob Nielsen's rule of thumb is still a fine one: at 1s the user may start to wonder if something has gone wrong; at 10s they are likely to abandon the task. Therefore don't show any sort of loading or progress bar for <1s, and blocking the UI for more than 10s should be avoided if at all possible.

(That said, 10 seconds is a long time; if there's any way to push a lengthy operation into the background rather than blocking the UI, do so: let the user continue with their work and notify them when the operation is complete, instead of forcing them to stare at a spinner for the full duration. The exact amount of time at which this becomes worthwhile depends on the specific task and how long the user would expect it to take, and on implementation details: for example single-page-app frameworks make it relatively painless to background operations via XHR and notify when ready, compared to more "traditionally" structured applications.)

If the implementation of your loading screen overlay is such that it would be difficult to introduce a delay before it appears, a near-trivial solution is simply to add a CSS transition to the overlay that keeps it transparent and offscreen for the first 1s (using for example animation-delay, or @keyframeing the opacity from 0 only after a second has elapsed). For short operations, the element will still be drawn, but will be invisible to the user until it's been kept around long enough to be necessary.

Mobile vs Desktop

You assert a couple of times that the user experience of a loading screen is different on mobile devices:

...the quick flash can happen on mobile devices too, but there is less distracting because the screen is smaller and users are more used to full-screen loading modals on such devices

I'd be very wary of your conclusions here: a distraction is a distraction, regardless of the size of the screen; and "users are more used to it" is tantamount to saying "Others give mobile a substandard experience, so we can get away with doing that too". The distinction between mobile and desktop devices is getting smaller over time; the form factor is different, but the capabilities of the device are at about parity, at least as far as the average web app is concerned.

Answer 2

There are guidelines about keeping your user adequately informed about system response and delays:

Response Times: The 3 important Limits by Jakob Nielsen

This article was originally written in 1993 but was updated in 2014.

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

• 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

• 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

So while this does not specifically mention "how" you implement your delay responses, it does re-iterate the reasoning behind it. So whether you use overlays, etc, the point is it should work effectively and efficiently. You need to design and build in the intelligence to deliver the correct level of system response, e.g. if something happens very quickly then there is no need to present anything to the user.