Page 1 of 1 Joe Balderson is a Flash developer living in Toronto, Ontario. He has been developing Flash based content and Flash sites for a number of clients and also teaches Flash through Humber College's School of Media Studies in Toronto. His web site is http://www.joeflash.ca.
In this series we are going to look at all the different kinds of flash loaders – what they're for, how to build them and when to use them, from simple to advanced. In this tutorial — Part 1 of this series — we will be looking at basic loader concepts and loader usability. In Part 2, we'll go over a variation on the classic frame-based loader, upgraded to ActionScript 2.0 syntax.
First off, let's get our terminology straight. Although the industry uses the two terms loader and preloader interchangeably, the terms "loader" and "preloader" are in fact two separate and distinct things. A loader is what most people call a "preloader" – it is the 'gateway into the flash application that ensures all relevant assets (including the main SWF itself) is ready to be displayed before the application begins.
A preloader is in fact the loader for the loader – it readies the assets to be used in the loader, such as an animation, a graphic or a component. Hence the use of the prefix: pre. Most preloaders are nothing more than the first frame of the movie where the loader assets appear, one frame before the loader logic itself is placed, so that when the loader begins, the assets it will be using are ready.
Why do we use a loader for a Flash application? If we did not have a loader in place, our application would simply play until a stop action on the timeline told the SWF's playhead to stop, or until it encountered a frame on the timeline where the frame's content had not fully loaded. Publishing a SWF without a loader is fine if you are authoring a simple linear animation and don't mind the playhead pausing every so often while a relevant frame loads, similar to streaming video playback.
A Flash application is, by definition, non-linear; they are not simple animations following a start-to-finish execution. This means we must ensure that all of the SWF is ready to be used before we start things off, because we won't know what part of the application the user will first need to access. We need a measure of control over how the application is first executed. A loader gives us that.
A good loader doesn't only function as a way for the SWF to properly initialize itself before starting. A good loader presents useful information to the user while he or she is waiting. Giving the user more information makes the loader friendlier, not so annoying and, one could even go so far as to say, "useful". This measure of "usefulness" is an indication of how easy it is to use an interface. We call this ease-of-use a measure of its "usability". Hence the term – the more easy to use or usable something is, the more it embodies what we call good usability, or adheres to usability standards. Here we will concern ourselves only with web usability. Most of the time web usability standards are simply a matter of common sense, and are changed and redefined as the technologies that make up the web evolve and grow. Let's look at a few web usability standards or rules regarding loaders.
The first "rule" to consider is an essential fact of internet life out there today: You have a matter of seconds when a user first clicks to go to your site before they decide whether or not to stick around and wait for the application to load.
This can be summed up nicely by the phrase, "DON'T MAKE ME WAIT!" Simple enough? Unfortunately we must make the user wait, because we don't all have federation-grade subspace transceivers attached to our computers, so the application must take some time, however short, to download and initialize before starting up in the user's browser.
The subtext of this is, of course, if we must make our users wait, tell them why they are waiting, and for how long they will be waiting. This can be achieved by telling the user :
This takes the form of something called a progress indicator. A progress indicator can be anything visually representing the data pertaining to the status of the loader. This can take the form of :
The second rule of thumb for loaders is, if you are going to make the user wait, make it interesting and visually appealing.
You don't have to go to the length of designing a game to amuse the user while they're waiting, but at least make it interesting and visually appealing. Make sure the colour scheme of the loader graphic and/or text matches the overall branding of the application. Your loader is the first thing a user will ever see related to your site. Use this as an opportunity to brand your site, to make a statement about the kind of experience your user can expect to have once the application starts.
Thirdly, Make sure your loader is as lightweight as possible.
This means placing most of your assets on the timeline after the loader, and not bogging it down with heavy bitmap graphics (no matter how badly you might want to show off your 3DS Max skills.). If your loader has a lot of assets, your SWF will be 'top-heavy', meaning the application will noticeably pause while your preloader prepares the loader elements. Every second counts here: if your user is faced with a blank screen for several seconds, you may loose them. So keep it simple, but attractive and interesting. Later in this series we will cover techniques to load fonts, components and dynamically linked assets. You will be able accomplish this without selecting the "Export in first frame" radio button found in the Flash Linkage properties dialog box. This dialog box opens when you right click on a Library item and select "Linkage" from the Context menu.
To ensure you're not loading too much in the first few frames of your SWF application, check "Generate size report" in the Flash tab under the File > Publishing Settings preferences. When you publish your SWF, this will give you a complete breakdown of exactly how many bytes are involved in your SWF, per frame and per asset. I cannot stress enough how useful the size report can be in building an effective loader.
The fourth and final usability guideline is: Never ever ever ever ever ever show the user a 'skip intro' button. Unless they are already in the application and have clicked on a link expecting to see just that. Never show the user a 'gateway animation' in the guise of a loader, delaying them from getting to the core application sooner rather than later. They will get bored, or worse feel cheated and their expectations thwarted. And they will click to another site before they have even seen your application.
Luckily most Flash developers out there have heard the cry of the frustrated user, and the 'skip intro' phenomenon that once branded flash as '99% bad' is no more. You may be really tempted to wrest control of the experience and show them some really cool thing or, even worse, show them what you want them to see before they can do what they want. All I can say is, don't do it. If you must display some sort of introductory animation or demonstration pitch, do so within the context of the main application, where the user has choices, not as a loader substitute.
Which reminds me, about the worst kind of loader you can ever build is embodied by the following tongue-in-cheek site: http://www.zombo.com. It's been around forever in internet time, but no matter how many times I see it, I always get a laugh, as it reminds me of the dot-boom halcyon days.
In the next part of this series we will go over a variation on the classic frame-based loader, upgraded to ActionScript 2.0 syntax.
Page 1 of 1 1
Keywords
flash,preload,preloader,load,loader
