Monthly Archives: July 2014

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: Close Button

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

In a previous post I discussed the derivation of some of the requirements for the Loading Screen, and now, in this and the next few posts, I will talk about how I satisfied these requirements in my implementation of the feature.

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

To satisfy this requirement, I decided to give the loading screen a close button. This addresses the user’s feeling of disempowerment, discussed during the previous post, in slow-loading conditions if they do not want to wait for the page to finish loading before, say, navigating away from it.

However, under normal conditions if the user is too quick to click the close button, then the screen gets dismissed too early, leading to the experience double-whammy of having an imposing loading screen in the way and seeing the ugly artifacts of sequential rendering getting displayed – the worst of both worlds!

Therefore, my implementation features a close button timeout period after which the close button appears. This means that in slow-loading conditions the user has an “out”, but under normal conditions the screen should appropriately mask the screen-rendering artifacts as intended, until such time as it is automatically dismissed. The length of the timeout is a code-configurable option of the LoadingScreen class, so if this feature is not desired by the client site the timeout can be set to 0 seconds for the close button to be always visible. The default timeout period is 3 seconds.

The timeout implementation uses the StopWatch class, a very simple class that you kick off using the start() method, and thereafter can retrieve the number of seconds elapsed using the secondsElapsed() method. By using the system clock (accessed with Date.getTime()) the timeout is guaranteed to still fire even if the page is loading slowly regardless of whether it is caused by a slow network or a slow processor. As long as any timeout event created by the startPolling() method of the LoadingScreen class can be processed, the button will appear after the timeout period.

There of course is still the danger of malfunction here. What happens, for example, if setTimeout() fails to create a timeout event, due to browser incompatibility or another reason? Or if the browser does not properly implement the styles that both hide and show the button? In such a case, it’s possible that not only will the close button fail to appear, but the loading screen will never get dismissed and will render your whole site completely unuseable! This is a real concern, and one that I will address in a future post.