Programmer, Development Manager in Toronto

Category Archives: Design Details

Lately I have been interviewing for jobs, and was sent a coding problem by one of my interviewers to solve. I thought I’d post my solution here, since it illustrates some aspects of my approach to coding.

The problem involves reading in a text file containing remote instructions for Rovers that are landing on Plateaus on Mars.

You can see my solution in Python 3, done with BDD using Mamba, on my public GitHub profile here: Mars Rovers Solution

I should probably mention that this is the first thing I’ve written in Python 3.x, and my first time using python at all in a couple of years. Writing this little app has reminded me how much I love python! What a language! 🙂

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.

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:

Is the DOM fully loaded?

Are the DOM and all style sheets fully loaded?

Are the DOM, all style sheets, and all images fully loaded?

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.

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.

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:

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.

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

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

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!