Vector Art Primer
Although you can import some Illustrator files, my suggestion is to save yourself some heartache by transferring it to a Freehand file or making a bitmap equivalent in Photoshop. If this is not an option, write down your color values – sometimes things do not match up exactly. The same goes for PDF and EPS.

Method 1: The RAD Prototype
The quickest way to implement an interface is to simply import it using the methods previously mentioned and lay it out on the stage. It helps to sometimes import a screen-capped version and put it on a guide layer to help in your positioning. Then, you place your code on the objects. This will be very familiar to VB form developers.

Using the new Flash Pro features – the screens, the behaviors panel – and using databinding, you can knock out most interfaces that would take weeks, in days; day's in hours. The process is the same: lay out your interface on a series of forms that are reminiscent of PowerPoint (supporting nested forms), and then click on one of the form elements, click the behaviors panel, and apply your code.

Pros
This method is very fast. So fast, in fact, that this is where the multimedia author achieved fame in the Director days, as the process was very similar. The benefit is the media support in Flash; in addition, the flexibility and cross-product editing are superior in speed to other programming environments, save Director (which supports even more media types than Flash does). If something needs to be done in a hurry, this is the way to go. Behaviors created by programmers for the Behaviors panel can still allow very complex interactions and data handling to take place.

Cons
OOP? What's that? Although Flash's new data binding and components help you connect to external data sources of all types to keep your application dynamic, the structure of the application is pretty much stuck that way. From the placement of objects to the code placed on the objects, all are there to stay. If you wish to modify code, you must go to the object as well as edit an object's properties, properties, and it isn't always apparent what has code on it and what doesn't. For wizardtype applications, slide shows, or prototypes, this doesn't usually pose a problem, but for application design, it's not very flexible nor centralized from a coding standpoint.

Method 2: The Module Approach
Another way that holds much sway in the Web-developed Flash sites arena, as well as CD-ROM and application disciplines, is the use of loaded SWF files, otherwise known as loading movies. Each SWF forms a component, section, or module of the entire project. Flash movies have the ability to load each other either into themselves or one on top of the other, forming levels. As with colored acetate (transparent paper that allows you to write text and images upon it, which you then place on an overhead projector that shows the images on the screen or wall behind you), users have no idea as they are just seeing a bunch of elements on the screen like they usually would. However, this is a very powerful option that has a great many benefits (and pitfalls). I usually recommend this for CD-ROM-type projects, large Web sites, older Flash projects that use Flash video (whether a bitmapped generated sequence or FLV file imported into a blank FLA file, exported alone into a SWF), or projects that have a lot of media such as sounds, video, and large designs. Sites such as 2advanced (www.2advanced.com) pioneered this methodology into the limelight. It has a certain affinity for design types because they are used to compositing concepts, more so than programmers.

Pros
The first thing you'll notice is that your Flash files export a lot faster in a bunch of smaller files than in one big FLA file. This is especially valuable when you're trying to test some small coding functionality, but you were originally forced to wait for Flash to compress your sounds and video again, which could take many minutes. Another nice thing is that your application uses only the RAM it needs when the content is actually loaded. Although there are still other minutiae loaded in, performance is not compromised.

You can unload the levels you're no longer using, further helping performance. Since Flash still "renders" objects off-screen, this is a great technique for keeping performance in tip-top shape.

From an interface perspective, this allows you to separate out different pieces of the interface to be present only when needed, as well as the functionality of that interface and specific states. You can have many different SWF files with the same menu, but different data, or different colors, or different menu shapes, and so on. However, loading in that SWF will only change the level or current SWF being displayed, so it keeps things pretty flexible. You can also divide functionality in your application into movies instead of deeply nested components. You can still use components, mind you, as well as Branden Hall's Outlet component (www.waxpraxis.org) to allow your SWFs to act as independent components. One level can hold your sound, one can hold the Web service code, three can hold your interface and all its pieces and states, and one can act as the manager for all of the levels.

Videos, kept in their own respective SWF files, are easily loaded in and out. This helps in previewing just the videos as well as updating their compression levels without recompiling the entire application; compressing video takes a lot of time.

Web site wise, users have to download only Web site content they actually view. This also helps in showing dynamic pages without refreshing the page (or as some call it, causing a "postback").

Cons
Although levels are very flexible, each SWF file streams. You have to keep this in mind when expecting data from other SWFs. Trying to access a variable in SWF that you just loaded into a movie clip or _level will fail miserably. Even worse, it may work once in a blue moon because the file was cached and you got lucky, and then you're left wondering if something is wrong with your code, further deviating you from the true problem.

Web site wise, you need to provide a preloader for each SWF you load, or the user will be left wondering why the application is slow the first time around. However, the biggest pitfall is mismanagement. You need to micro-manage the heck out of your _level structure as well as your file structure. Even adding just one folder to the file path mix can get confusing when levels start loading each other. Constantly updating your structure on paper helps as does keeping track of who accesses who, when, etc. However, the real problem comes at crunch time. When you want to drastically change the application or site flow, especially when animations already time the loading of certain levels, it gets really difficult not only to modify, but also to keep track of those last-minute changes.

Although it's improved a little in 2004 (e.g., showing how a level can stream in when loaded) you can debug only one level at a time using Flash's debugger. The Flash Player is single threaded, but it's sometimes confusing to keep track of which movie does what and which movie you're currently debugging, causing you to play back the sequence of events in your mind. Overall, debugging is sometimes made more difficult.

Another con is not using shared libraries and having the same global asset duplicated in multiple movies like the FScrollBar. Although a background graphic can be in its own movie and remain in the back, a scrollbar is not so flexible. There may be multiple movies that need that, and this generally forces you to use a shared library and keep hard track of what uses that asset. Otherwise, you have 10K duplicated unnecessarily in all the SWFs that use the same scrollbar. Shared Fonts, however, have to be in _level0 to work this way. Another odd thing to note is that, contrary to the performance performance increase, _level0 has the maximum frame rate. If you're seriously trying to optimize your animations, nothing will be as fast as _level0.

Loading additional movies causes additional overhead, sometimes slowing your animations down. However, if they couldn't run as well, even without using levels (as the effect is marginal), then you better rethink your animation and not your assembly methodology. Finally, not being able to preview your animations as a whole unless you compile multiple files can sometimes slow things down in the long run. Having to go through points C, D, and E just to reach point B gets frustrating after awhile. Even though the user needs to, you sure as heck don't during development.

For more pros and cons, please see www.jessewarden.com/archives/000189.html as well as the chattyfig archives; many people have offered their opinions on the methodology.

• Source Code