Article

Home » Design and Layout » Flash Tutorials » Co-ordinate Your Flash Site

About the Author

Steven Maclin

author_steveM Steve’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.

View all articles by Steven Maclin...

Co-ordinate Your Flash Site

By Steven Maclin

November 27th, 2002

Reader Rating: 9

Page: 1 2 3 4 Next

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?"

If you liked this article, share the love:
Print-Friendly Version Suggest an Article

Sponsored Links