Tag Archives: detail

by

Loading Screen: Opening and Closing

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

So following right along on the discussion I started last time of the Loading Screen requirements from a few posts ago, let’s get stuck into the next two…

Requirement #2: The screen must be displayed as close as possible to the start of the page-rendering by the browser.

This requirement is pretty straightforward to achieve. I just placed the script that adds the loading screen <div> element as close as possible to the beginning of the page’s rendered elements, that is, just under the opening <body> tag.

Requirement #3: The screen must be removed as soon as the important page elements have been rendered, but not before.

This one is much trickier to get right. First off, it’s unclear what “the important page elements” are, so how do we detect whether they are loaded or not? Depending on the page, we could dismiss the loading screen after any one of the following tests pass:

  1. Is the DOM fully loaded?
  2. Are the DOM and all style sheets fully loaded?
  3. Are the DOM, all style sheets, and all images fully loaded?
  4. Are the DOM, certain style sheets, and certain images fully loaded?

The first test is not really sufficient since all sorts of rendering magic can be done by the browser after it has finished loading the DOM, as it continues to apply cascading styles to the DOM elements, and renders them.

The second test is OK, but if your website’s appearance relies on images then using this test may present the user with a half-rendered site, fully styled but not properly laid out, and not looking as the designers intended due to the lack of graphics.

The third test would guarantee that the site looks totally as intended before the loading screen was dismissed, but it goes too far and so has the opposite problem: rather than the loading screen being dismissed too early, relying on this test could cause it to be dismissed much too late. For example, if the site content contains many images, the user would have to wait for them all to load before seeing anything at all (ignoring the fact here that there is an ultimate timeout after which the loading screen is always cleared).

So therefore the last test is what I used for this site: the loading screen should obscure the loading of any images which are part of the theme before clearing, but it shouldn’t wait for all the content images to finish loading.

The question of which style sheets should be tested is made simpler by the WordPress framework’s handling of parent and child themes. The child theme style sheet is automatically loaded after any styles used by the parent, so based on that I decided that just monitoring the one resource should give a good enough indicator of when the important styles have been loaded.

Now that we know what test we need to implement in order to smartly dismiss the loading screen at an appropriate time, the question becomes how to do it, especially taking browser differences into account? In the next post I’ll get into some more detail of how the theme accomplishes this.

by

Loading Screen: Design Considerations

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.

Problem To Solve

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.

Problems To Avoid

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.

Putting It All Together

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!