New media has met its match.

If you’re a Flash developer, at some point in time you’ve had to build and optimize rich media banners for your clients.

Establishing a consistent workflow and following some simple guidelines is the key to success in banner optimization. Most of these techniques are basic and common knowledge to seasoned developers, but should be a great starting point for novice to advanced programmers.

Although not meant to be a definitive list, I’ve found the following steps work well when optimizing rich media banner units:

1. Always request specs for file size before development begins:

• Banner dimensions
• File sizes
• Frame rate
• Player version

2. Polite downloads (when available): is 30-40k initial, 70-100k additional (client specs may vary)

• Base .swf should be the 30-40k max, and the additional content should load in via a second .swf

3. If you are doing simple animation, use TweenNano instead of TweenMax when programming dynamically to save a few k

4. Recreate assets in vector whenever possible, unless it is a complex vector, then it may make sense to import the asset as a bitmap

5. Combine images whenever possible

6. Remove all complex bitmap filters from bitmaps in Photoshop, and replicate them with Flash’s filters using the Properties menu (you’ll need to convert all bitmaps to MovieClips before you can apply a Flash filter)

7. Only include the text characters you are using when embedding fonts in dynamic text fields

• Occasionally it makes sense to flatten text into bitmaps (even though this is bad practice) to get the files under spec

8. Under publish settings, do the following:

• Set the target Flash player to the version spec’d out by the client
• Change bitmap compression settings as needed (individual bitmap settings may need to be enforced as necessary)
• Check Omit trace actions (occasionally knocks off a few k)
• Check Generate size report to review asset weight in your .fla and allow you to locate and resolve problem areas contributing to file size overages

Following these guidelines should keep you out of trouble. If you’ve found any other tips that have worked well for you, please let me know and I’ll update the list. Enjoy.

Becoming proficient in programming ActionScript in Flash takes more than spewing object-oriented buzzwords and writing complex classes only decipherable to elite Flash geeks. In my opinion, there are three lost arts in Flash programming; in this article we’ll talk briefly about commenting.

How could such fundamental techniques as these actually be on the verge of extinction, you ask? The answer is obvious: Amidst the daily whirlwind of demanding clients and looming project deadlines, it’s easier (and faster) to code projects without taking the time to include explanations for each line of code you type.

The reality however, is this: The time you take up front to properly comment your code and add meaningful trace statements within your ActionScript, the more time that will be saved when you revisit this file in 2 weeks, 2 months or 2 years. It also serves as the key to other developers who may need to jump in on your project or make updates in your absence. If you’re already commenting your code, I applaud you and grant you the permission to skip the rest of this article and spread the gospel.

Commenting Your Code
Commenting your ActionScript should be second-nature. It’s probably the easiest element you can contribute to your Flash application. There are countless techniques and preferences on how commenting should be formatted. The most important aspect of commenting is that you are clear and concise, so that your functionality will make sense to someone else (and even yourself) later down the road. Comment every variable, function and loop in your application so it reads fluently as a step-by-step guide to how your brain works. Also make sure you use variable and function names that make sense (one of the ‘lost arts’ to be covered in a subsequent article).

While programming your app, it’s helpful to keep the following in mind:

• Will someone else be able to understand how I programmed this app?
• In 2 weeks (months, years), will I be able to understand how I programmed this app?

Wow, that’s a short list. That’s because commenting should be an integral part of your workflow. Taking the extra time to type a few comments will save you (or someone else) their time and their sanity, and make you look like a well-balanced, ‘big picture’ oriented Flash programmer.

The following article assumes you have a solid understanding of Flash AS3 and the Flash interface and skips all basic Flash setup instructions and explanations in effort to provide you with quick, concise information.

When using flashvars locally, I used to create a temporary variable that holds the information needed to run the application offline. That way I could test it locally, and comment it out when it was ready to be pushed live. Here’s my original approach:

The problem with this technique is that it’s extremely easy to forget to comment/uncomment the testing/live variables before handing it off to your technical lead or publishing it to your site. Forgetting to reset the values obviously leads to broken flash files and angry techies.

Let’s avoid all of that by taking an extra step and setting up a conditional statement that checks to see if a flashvar exists; if it doesn’t exist, use the default value. The new approach looks like this:

Copy and paste the above into a blank AS3 document, then publish it and you’ll see it runs off of the default value (output in the trace). Using this approach when flashvars are correctly configured in the HTML saves time, confusion and sanity. If you’re wondering why I’ve encapsulated the conditionals into the checkForFlashVars() function, it’s mainly for personal preferences. This way, if I need something else to happen before the flashvars calls (or more likely, after the flashvar values have been pulled in), I can place checkForFlashVars() anywhere I need to ensure nothing in my application fires until the values (or lack of values) have been detected and stored.

If you need to handle the values of multiple flashvars, a similar approach can be taken using an object to load and store the parameters (flashvars) passed in from the HTML:

If you copy and paste this code into a blank AS3 document, you’ll notice no trace codes in the Output Panel. That result means no flashvars are present, and the default values for testing are being used. If you need to grab additional flashvars, duplicate the variables/conditionals above. Based on your programming preferences, a great way to organize multiple conditionals is to use a switch() statement. Either one of the above flashvars techniques can be customized and extended as needed.

Lee Brimelow outlines a simple approach on his Flash website:

…where “isLive” is a flashvar set in the swfObject in the HTML.

As with all programming techniques, there are many approaches that can be applied so solve the similar problems. For me, these are the most comprehensive and most reliable methods I’ve found.