gmg tutorials - reusable flash preloader

Yet another Flash MX loader

An in depth look at building a reusable preloader for Flash MX.

01 Introduction
02 What should the loader do?
03 How should the preloader work? / What should it look like?
04 Useful reading / Designing the loader movie
05 What have we got so far? / Getting it to stop and play its parent
06 Setting a preload amount / Sync the loader movie with the download amount / Adding text feedback
07 Setting a maximum loader play rate / Setting a maximum load rate
08 Using the loader
09 Conclusion / About the authors / Copyright

Previous << Introduction

What should the loader do?

Okay. Here's the easy part. Get out a pen and paper and write down the things that you would like your loader to do and be. Go on. I'll wait.

Done that? Good. Now sort them in order of importance. This is so that you get the most pressing things designed, coded and tested first, leaving the cute bits for a later revision.

Here's my list:

Be small.
So that we don't wait forever for the preloader to load, requiring its own loader. (Which would then require another preloader for that, and... aargh – where are my pills?)
Display a progress bar to let the user know how the download is going.
This is why we are here. Since Flash MX is a visual tool, let's use it. A progress bar gives the quickest indication of the status of a command.
Give them details (downloaded amount and the total bytes).
This is good for your more advanced surfers. It lets them guesstimate progress for themselves. As a bonus, newbies can also learn how long things take.
Provide a loading animation.
Loading animations are especially good for long tasks like loading large files because they let the user know that something is happening and their computer hasn't crashed.
Be easy to reuse in several SFW files.
We don't want all our good efforts to be wasted, do we?
Stops the file from playing until the content is loaded.
Let's try to make the loader do all the work for us.
Be quick to add to a file.
Because I'm busy.
Be simple to add to a file.
Because I forget stuff.
Not have to be downloaded every time.
So that we don't clog our bandwidth with loaders!
Detects if a file has already been loaded.
Giving us a chance to take action if this is the case.
Gives an estimated time to completion.
Another method of giving the progress. Use it depending on the target audience. In my humble opinion this is not as reliable as bytes downloaded, progress bars or percent downloaded because it may be affected by other bandwidth hogs that may be on the machine. If your loader estimates that the file will be down in 2 minutes, but actually takes 4 minutes because email starts downloading as well, then the user's expectations of 2 minutes aren't met. They get grumpy and start looking for other faults.
Waits for a certain percentage to load before playing.
This lets us download an appropriate amount of content before playing the file, giving us a capacity to stream our content (playing the file before all of it is loaded – one of the best features of Flash MX).
Plays a quick animation even if the file has already been loaded.
This will give a consistent feel to loading content. Why do some things have loaders while others don't? Users have expectations of interacting with software. If users see a loader the first time, then they should see it every time. (Just make it quick so that it doesn't irritate them.)
Be easy to change the loading animation.
So that we can change the feel of a loader for a new situation, client, or project. If it is hard, we will probably try to not do it.

The requirements for a particular loader that you build will have differing priorities depending on client, anticipated user groups, style, and budget. But this list should give you a feel for what we are going to do.

Next >> How should the preloader work? / What should it look like?