Note: This post discusses “A New Dawn”, my WordPress theme. More detail on the theme implementation is available here.

The loading screen feature is a handy fix to a troublesome presentation issue – the way that browsers gradually render visual elements in real-time on the screen as they read them in from the source HTML.

This browser feature makes a lot of sense in slow loading conditions, for example allowing you to navigate away from an intermediate page without having to twiddle your thumbs while the whole thing downloads at a snail’s pace. But under regular conditions, it means that pages display in a piecemeal fashion, flashing their ugly under-bellies to the user before finally settling upon their final, meticulously-designed appearances. To a programmer’s brain, this violates encapsulation! And it obviously presents a problem from an experience perspective, but what can you do? The browser’s rendering engine is outside of our control as web developers.

The loading screen presents one solution to this problem. It isn’t perfect, but it at least allows a visually-controlled transition between web pages, even in slow-loading conditions. This ability, however, comes at a cost. For one thing, it may be jarring to a user to have a new screen that they aren’t expecting thrown in their faces, even if only for a short time. Also you lose the benefits the browser was designed to provide in the first place eg. the ability to short-circuit the loading of an un-needed page that was discussed earlier. If the page is taking a ridiculously long time to load, your user may be sitting staring at a blank screen for a small eternity. The user may be next to powerless to improve their experience in the face of a slow connection, but even worse than being powerless is feeling powerless, and the loading screen may contribute to that feeling.

Moreover, as with any software feature you need to think about the user’s experience if it malfunctions. In the best case, if the loading screen is dismissed before the page finishes rendering, you now have two annoying transition artifacts instead of one: flashing page elements AND a flashing temporary screen. And in the worst-case, if the loading screen does not get dismissed as planned, your whole website is fatally broken! That’s a serious risk to incur for a little polish in your presentation layer.

So the consideration of all these issues gives rise to the following requirements of the loading screen:

1. There must be a way to manually dismiss the loading screen if the page is taking a long time to load, or if the automatic dismissal mechanism fails.
2. The screen must be displayed as close as possible to the start of the page-rendering by the browser.
3. The screen must be removed as soon as the important page elements have been rendered, but not before.
4. The loading screen display logic should be more likely (or at least, as likely) to fail than the logic controlling the availability of the dismissal capability.

And so, as is often the case, turning over a feature which seems at face-value to be about as straightforward as a stone reveals some not-quite-so-simple requirements lying underneath.

More on how these were addressed in the Loading Screen module in a later post!