FOUJI, similar to FOUC, occurs when:
When an user loads a page that meets these conditions, they briefly see a version of your site that doesn't look correct, as if it hasn't been fully loaded. Styles will be applied, but the UI will look incomplete.
Then, after the site initialization scripts ran and the Kendo UI widgets rendered, users would see the final (proper) site interface:
Quite a difference! The uninitialized view is usually only visible for a split second (sometimes longer on slower device browsers), so you could easily dismiss this as an ignorable inconvenience. But we want to give our users a better experience. We want to eliminate the FOUJUI.
<img src="styles/BlueOpal/loading-image.gif" alt="Loading Image" style="width:48px;" />
Now, when the Feed Reader app loads, rather than seeing the uninitialized HTML (or any of the app, for that matter), users will see my simple loading screen:
Cool. That's better. Users understand loading screens, and it's a lot less jarring than seeing the FOUJUI effect.
Simple enough. In the "init" event for my app (see the source), I add this single line of code that is executed after all initialization steps are complete (including the initialization of my Kendo UI widgets):
//Trigger event indicating init is complete
And then, to handle this event when it's triggered, I wire-up a binding in my main page that will hide my loading screen:
And that's that. Now users will always see the loading screen while my app is initializing, and when the UI is ready, the loading screen will fade out to reveal a ready-to-work application. No FOUJUI!
We can improve this effect and make it buttery smooth on all devices by leveraging CSS3 Transitions. Browsers hardware accelerate CSS animations/transitions, giving CSS3 the power to speed-up any app (especially on mobile devices).
Browser support for CSS3 transitions is strong, but even browsers that don't support transitions will gracefully degrade to a functional, "direct" transition. So there's no reason not to use this technique.
The first step in this refactoring is to add the cross-browser CSS3 rules that define my transition. To achieve the same "fade out" effect, I will use the CSS opacity and visibility settings to hide my loading screen.
-moz-transition: visibility 0s linear 1s, opacity 1s ease-in-out 0s;
-webkit-transition: visibility 0s linear 1s, opacity 1s ease-in-out 0s;
-o-transition: visibility 0s linear 1s, opacity 1s ease-in-out 0s;
transition: visibility 0s linear 1s, opacity 1s ease-in-out 0s;
This code basically says:
If opacity is used without visibility, then the entire app would remain "blocked" by the an invisible element after the loading screen fades out (opacity=0). By combining with visibility, the loading screen will fade out and be properly hidden. The delay ensures the opacity change animation will complete before the element is hidden.
How do we trigger the CSS3 fade out transition? By simply changing the CSS opacity and visibility properties to their desired target values on our loading screen element:
When these values change, the browser will calculate the necessary animated transition to get from the original values to the new values, using the specified timing function ("ease-in-out") to shape the animation path.
The result: a fade out transition that looks smooth on desktop and mobile browsers.
With these simple techniques applied, our user experience is now much better. When the application loads, users briefly see a loading screen, hiding the uninitialized HTML UI, and then a smooth, animated transition presents the app when it's ready.
You can try the updated Kendo UI Feed Reader demo for yourself to see this in action.
For those of you using a version of Internet Explorer less than 10 (the first from Microsoft to support CSS3 Transitions), here is a quick animated example showing what other browsers are seeing (in rough animated GIF format):
Subscribe to be the first to get our expert-written articles and tutorials for developers!