Flash Websites load more quickly when they’re broken into smaller movies (i.e. “modularized”). While the idea seems obvious enough, it’s still worth mentioning! But what’s less obvious is that, once you’ve started along that road, issues of “coordination” take precedent; and, whether the developer is a seasoned professional or a relative newbie (like me), they’d do well to recognize these issues up front.
This article hopes to accomplish three things: first, to underscore the value of modularization. Second, to clarify some of its important, though previously underreported, repercussions. Finally, to offer remedy to these repercussions by explaining how the task of “coordination” can be accomplished systematically.
References are made to a few Websites I’ve designed for others and to a bulleted check list of questions that Flash developers (particularly those hoping to decrease load times) should consider before they break up their Websites into little bitty pieces.
Case Study
I had previously broken up a few sections of one of my favorite Websites into smaller swfs and loaded them into different levels of the main movie. In fact, this seemed pretty logical for things like MP3 or music selectors, clocks and such. And I’d grown accustomed to the inordinate size that my main movie had grown to. So, when I came across a recent SitePoint article on modularizing the main movie (otherwise known as putting it on a diet), I studied it with great interest.
Indeed, it worked! In fact, it worked so seamlessly, I went through my entire Website and modularized 6-8 additional sections! Great, I thought! Now, the main movie was much smaller in size — at least, it was after I deleted all remaining unused items from its library. With that, I noticed the site took less time to load, and that I could more easily isolate any remaining areas of concern. Unexpectedly, by breaking up the main movie into smaller pieces, it became easier to identify those sections of the Website that could be re-used!
For instance, when the Website initially loads, a set of doors open to reveal an image centered on the screen, which sits right above four main navigational buttons. Before modularization, this “door-opening routine” would occur only once — the first time the site was loaded. This was the first thing I modularized, and, after I did, it became obvious to me that I could re-use or “coordinate” the door-opening routine to execute every time my users clicked on one of the main navigation buttons! All I had to do was call the door-opening routine from inside each one of the buttons. Simple!
What I had not yet realized was that the task of coordination would eventually become anything but simple. Try coordinating anywhere from 25-50 different sub-movies so that they interact as users expect, both with the main movie and with one another! Let me tell you, it can get a little unwieldy!
Just how Unwieldy Can it Be?
Well, let me just say that, despite its obvious benefits, modularization raises important questions of coordination (which, in turn, raise questions of time and effort — e.g. how much time do you have and how much effort are you willing to expend?). However, the first question asks: “how much modularization is enough, and how much is too much?” Is there a point of optimality? Consider this.
You’ve got four navigational buttons, all programmed into your main .swf. Each is associated with a different sub-menu item or selection, and each has a different background image (see Image 1). Modularize these four buttons into four smaller, faster-loading .swfs and you’ve got problems. Check this:
- the sub-menu selections and/or background image for the first button need to be turned off when any other main navigational buttons is selected;
- the same for the second button the user selects — its related information needs to be turned on; and, while all of this is happening,
- the first button is not supposed to disappear or become inoperative.
- the background music should not be affected by the button selection, but the images of musicians that appear when the music begins should disappear when certain buttons (but not all) are selected.
For a seasoned Flash designer or developer, none of this is particularly disturbing; everything is as it should be. But for the rest of us, aspiring to become a seasoned Flash “something or other,” this all comes from out of the blue.
It means we need to program each of the navigational buttons to issue a series of commands that will make certain characteristics of the remaining buttons roll-up, slide out, or otherwise disappear — to allow the other buttons to display their information without interfering with one another. In plain English, the buttons need to evaluate and interact with their “environment” before they execute.
This, then, raises a second question: “how do I get the smaller .swfs to exchange commands between one another, as well as to and from the main movie?“
The Coordinative Task
Say, for instance, the Website loads and the user clicks one of the main navigation buttons. As they expect, the button displays its submenus:
And, as the user rolls over each one of the submenu items, the text for that item highlights and an image is displayed in the main “display area” — an image that visually conveys the main idea of the current (rolled-over) item.
Then (since we’ve all got these really intelligent users) — with the first menu still in its “down” position, but without selecting anything from its submenu — the user decides to click a second navigation button, one which comes with its own menus and (you guessed it) an image that would effectively cover the same display area:
Well, if the two buttons are modularized (which is to say they exist as separate .swfs) — and are not coordinated — both sub-menus and/or background images will be displayed on top of one another, rendering both buttons ineffective:
Enough!
For some projects, this may produce the desired effect(s). But, if that’s not quite what you had in mind, you may want to read further.
Though I’ve learned a lot about Flash by modularizing my Website, I’ve learned twice as much by taking the time to coordinate the buttons and other routines I had so happily dismantled. After all, what good is a movie that loads quickly and is easy to repair if it doesn’t operate as expected? Not much.
Anyway, to give you an idea of the kind of interactivity involved in coordinating your buttons with one another, here’s a list of the commands that are now issued from my “Home” button:
on(release) {
\ 1. these commands turn off the music, if it's already been turned on.
_root.music_holder. unloadMovie("miles_and_john.swf");
_root.music_holder. unloadMovie("love_supreme.swf");
_root.music_holder. unloadMovie("cannonball_adderley.swf");
_root.music_holder. unloadMovie("finding_forrester.swf");
_root.music_holder. unloadMovie("tribute_to_miles.swf");
_root.music_holder.music.gotoAndStop("back");
\ 2. these commands make the images, which are designed to automatically
\ pop-up for certain songs (above), invisible.
_root.music_holder.music.miles._visible = false;
_root.music_holder.music.herbie._visible = false;
_root.music_holder.music.john._visible = false;
_root.music_holder.music.jazzfestival._visible = false;
_root.music_holder.music.sax._visible = false;
\ 3. if any of the navigational buttons are currently in their "display"
\ positions, these commands will bring them back to their
\ original positions.
_root.movieholder.button_rack.gotoAndStop("start");
_root.movieholder.button_rack.teaching.gotoAndStop("start");
_root.movieholder.button_rack.research.gotoAndStop("start");
_root.movieholder.button_rack.info.gotoAndStop("start");
_root.movieholder.button_rack.contact.textAnimation.gotoAndStop("start");
\ 4. these commands turn off the background images that are associated
\ with each one of the (above) navigational buttons.
_root.movieholder.mc_button_1_holder.unloadMovie();
_root.movieholder.mc_button_2_holder.unloadMovie();
_root.movieholder.mc_button_3_holder.unloadMovie();
_root.movieholder.mc_button_4_holder.unloadMovie();
\ 5. this command turns on the background image that comes up
\ when the website initially loads.
_root.movieholder.mc_picture_base._visible = true;
\ 6. in case the user had previously clicked "credits," this command
\ makes the credits display go to its initial (off) position.
_root.clock_holder.credits.gotoAndStop("off");
\ 7. this command unloads any previously loaded movie, in case it
\ had been displayed.
_root.wipe1_holder.unloadMovie();
\ 8. this command unloads yet another sub-movie, in case it
\ had been displayed.
_root.movieholder._level1.unloadMovie();
\ 9. finally, this command loads a very small movie that appears
\ when the website initially loaded, telling the user that
\ they are now "back home."
loadMovie("wipe1.swf", "wipe1_holder");
}As you can see, there’s a lot going on — at least potentially — which is why you have to issue so many commands. Keep in mind that a similar slate of commands will need to be issued to other buttons so that they are similarly informed on how they should operate in a given situation. Again, the buttons need to interact with their “environment” — however that environment might be configured when the user decides to do whatever it is they do.
As you might imagine, several of the above commands will probably go nowhere, but that’s alright. Effective coordination is all about thinking through, and addressing up-front, the various possible interactions. You constantly need to ask yourself “what if?”
While several commands will probably go “unused,” it’s important that they’re there so the user can do what they want to do, when they want to do it, “without the water going on every time they turn on the gas.”
Before You Modularize
That said, here are a few instructions that may be of benefit to other newbies. These are things that should be determined before you modularize your Website.
- Make a list of all the intended interactions that could take place between the buttons/routines that you plan to modularize and their “environment.” For navigation buttons, you might want to consider whether their (intended) operation should be constrained by, or subject to the operation of other buttons.
Bottom line: modularization is worthwhile, and should be done more often. But, since it’s only half the equation — you should know what it costs!
Steven MaclinSteve’s been a university professor since 1994, but for the past 5 years he’s been living and working with American military troops in Japan, South Korea, and Hawai’i. He has previously edited and published dozens of articles in professional administrative journals and recently, in his ‘spare time,’ he’s been building Flash Websites for distributing materials to his graduate students. Visit him at SteveMaclin.com.
