Loading Screen: Wrap-up

Well it’s been awhile since my last post for the reason that I have become involved with a start-up company in Toronto, and my free time for writing blog posts has dwindled. But perhaps more importantly, I felt that while I was writing about the Loading Screen for the purposes of showcasing some of my thinking about software, few were interested in reading about it, and as a result I lost interest in writing about it.

So just for completeness let me here finish off my descriptions my WordPress theme implementation, so I can get on to things more exciting for everyone involved.


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.

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.

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!

The Devil In The Details

Because this site is about the art and science of Software Development, it’s not enough for me to just publish the fruits of my labours without analyzing every little implementation detail to a disturbing degree.

So with that goal in mind, here are some of the technical artifacts from my development of “A New Dawn”, my WordPress theme, for those among you with an inclination to explore such things.

The two main modules I created while making this theme were The Loading Screen module itself and The CSS Notification module, a cross-browser module for invoking a javascript callback when a linked CSS file has finished loading. A cleaner source listing for both files is available under the HTML documentation link below. These source files constitute part of the code for the theme and can be re-used or extended in other contexts by themselves.

Artifact Loading Screen CSS Notification
API Documentation (YUIDoc)
Notes from Test-Driven Development (FreeMind)
Test Harness (QUnit)
Unit test listings
Changelist descriptions (Mercurial)

A New Dawn (WordPress Theme)

Hi and welcome to the first post of my new blog!  Glad to have you come visit, I hope you find something interesting to read here.

Although for years I’ve been making web pages for personal use and volunteer organizations, as you can see from my work history (found at the Résumé link to the side of this post) I’ve haven’t worked professionally as a pure Web Developer.  But over the years my interests have been drifting ever more towards the Web, and now I find the jobs that most interest me tend to be centred around Web technologies.

And since a part of my reason for creating this site was to use it as a home for development projects of personal interest, why not make my first project the site itself?  So as a result I created a WordPress theme – a child theme of the “Dusk To Dawn” theme by Automattic.

You can download the theme I made here:

Loading Screen

In addition to a fresh new design and feel (that you are basking in as we speak), the new theme features a loading screen to hide the gradual display of the site by the browser as it loads.  This ensures a nice, clean transition when browsing pages of the site.

The loading screen came about because I found that due to the way the browsers were rendering the parent theme, you’d see elements of the parent theme flash on-screen before the child theme would get drawn over it whenever you loaded a new page.  While this could have been corrected by tweaking the parent theme, I wanted my child theme to be easily laid over a fresh installation of the parent theme, without requiring special configuration that would need to get repeated after every theme update.  So being a control freak and objecting to the impact this would have on readers’ impressions of my sleek, clean site, I implemented a loading screen feature.

What do you think?  Is it an improvement or just as much of an eyesore?  I like it, and definitely think it looks preferable to randomly flashing elements during every page transition.  Also it was an interesting development challenge getting it to work properly across browsers with consideration for the experience in legacy browsers.  Hopefully it works well in your browser, but if not, please let me know by leaving a comment below!

Theme Installation

  1. In the admin panel for your WordPress site, go to “Add Themes” and install the “Dusk to Dawn” theme, OR
  2. Download the parent theme from this link (http://wordpress.org/themes/dusk-to-dawn) , and use the “Upload theme” feature to add it to your site (Found in the Admin panel under Appearance>Themes) .
  3. Download the child theme from the link above and use the “Upload theme” feature to add it to your WordPress site.
  4. Then under the Themes area of the Admin panel, find the theme called “A New Dawn” and click to activate it.
  5. Modify the file <WordPress themes root>/new-dawn/js/theme_globals.js to reference the theme’s root directory.