There. I said it. That feels better.

But why am I not a fan of what they’ve done? Quite frankly, in the process of trying to build a mobile application with Flash Builder 4.5, I’m finding myself either engineering components from scratch, or reengineering the default “mobile-optimized” components to get them to do what I want/need. Plus, I’m finding that in an application of even a decent size (more than just a “hello world” app with a couple simple views like Adobe likes to show off to get Flash developers excited about mobile apps), the optimization and performance are still lacking.

Maybe I’m just being pessimistic. And maybe I’m not doing everything correctly to get things optimized for the mobile app. Honestly, I hope that I am missing something that I’ll catch soon and have a light bulb-over-the-head moment. But my experience thus far has taught me that Steve Jobs was right in bashing Adobe’s ability to create mobile-optimized content.

Here’s a snippet from a blog post from Steve Jobs, dated April 2010:

As you probably noticed, this post was from April of 2010. Yeah, that’s over a year and a half ago. And guess what? Adobe still doesn’t have it right. They’re close. But not there. And with the news of Adobe dropping mobile support for Flash Player a couple weeks ago, I’m guessing they never will be there. They may try to really hone in on the mobile application side, rather than just the Flash Player plugin for mobile, and they may get close. But like Jobs eluded to, Adobe holds all of its developers at the mercy of when they choose to adopt new features, whereas developing a mobile application natively gives immediate access to the full spectrum of features.

Don’t get me wrong. I’m not completely agreeing with the Flash haters out there who think that all Flash needs to go away—there is definitely still a time and place for Flash on the web. I’m just agreeing that Adobe needs to realize what their strengths are, and really concentrate on them rather than trying to get a foot into every single realm and telling developers that the Adobe solution will change their lives and work seamlessly.

Lucky for you, Flash comes well-equipped with providing tools for developers to use when coding their Flash applications.  My three most-used Flash methods for clean lines and exact placement are listed below, and are all part of Flash’s Math class.  If you use them, you’ll be sure clean up the lines and sizes of your site in no time.  (It may not help poorly-drawn shapes that you draw by hand, but for dynamically-drawn, code-generated items, or code-based asset placement, it’s golden.)

A Few of My Favorites

Math.ceil()
This function returns the ceiling of the specified number or expression, which equates to the closest integer that is greater than or equal to the number.

Math.floor()
This function returns the floor of the specified number or expression, which equates to the closest integer that is less than or equal to the number.

Math.round()
This function rounds the value of the passed-in parameter to the nearest closest integer. If the passed-in value is exactly in the middle, it rounds up.

How and When to Use the Math Functions

Let’s say you have a square MovieClip that’s sitting on your stage with an x coordinates of 133.  You want to tween it with ActionScript to a point 50% of the way to the left edge of your application from it’s original point of 133.  You’ll need to have the x coordinate change for the move, obviously.  But if you simply figure out what point to tween to without somehow finding the nearest integer value, you’ll be left with a non-integer value (66.5), and your horizontal and vertical lines will get fuzzy.  However, if you use the Math.round() method, for instance, you’ll get an integer value (67), which will keep your horizontal and vertical lines crisp and clean.

In the example SWF below, there are two square MovieClips, both placed at an x coordinate of 133, as in the example above.  The top one does not use the Math class to get the integer-based pixel value it will end on.  The bottom one, on the other hand, does use the Math class, and rounds the target value to the nearest integer, thus resulting in a final x coordinate that is an integer.  Click on each box to tween it, and notice the end result of the boxes side by side.  You’ll quite obviously notice the top box having fuzzy edges when compared the the clean lines of the bottom box.

Know, Love, and Understand Integers

The important part to note about all three of these methods is that they all calculate the closest “integer” — or whole number.  This is immensely helpful, because if you base your width, height, x, or y values on any of these methods, you’ll always get back a whole-pixel value, which will give you the crisp edges that we all know and love.  With that said, there is one important exception….

Even though these methods return integers, there is still one more “gotcha” that you’ll need to keep in mind when developing your Flash application.  If you have a MovieClip of a square shape, for instance, and you have it centered to the registration point of the MovieClip, you may still get fuzzy pixels.  How, you ask?  If your square has a width and/or height whose value is an odd number (57, for example), its x and y coordinates will be half-pixels within the MovieClip (-28.5, -28.5 for a width of 57).  And if you place this MovieClip on the stage and put it at coordinates whose values are integers, the edges will be fuzzy, because of the coordinates of the object within the MovieClip.

To combat this, there are a couple of options:

• If you center your object(s) in your MovieClips (or other display objects), make sure they have dimensions that are even numbers.  If this isn’t doable, at least make the x and y coordinates integer values, even if it means your assets won’t be “exactly” centered in the MovieClip.
• Instead of centering your object(s) in your MovieClips, use corner-based orientation, so, for example, your object(s) will have an x and y value of 0.  This way, you’ll be guaranteed to have crisp lines when the MovieClip is placed at coordinates whose values are integers.

Other Best Practices for Clean Lines

• When drawing shapes with horizontal and/or vertical lines in Flash, make sure that the x and y coordinates are integer values in your Properties panel.  Also, make sure the width and height are also integer values.  Every so often, Flash will want to add/subtract a random 0.05 from your typed-in values, so you may need to re-type in a value now and again.
• If you’re nudging objects around on your stage, turn on “Snap to Pixels”.  To do this, select the “View” menu, and select “Snapping > Snap to Pixels”.  Doing this will always snap your objects to integer (pixel) values.

Wrapping Up

So there you have it.  With a little careful planning and knowhow, and with a little help from the Math class, you can ensure your Flash applications have vertical and horizontal lines that are crisp and exact, creating a much stronger, cleaner design.

Until next time, happy coding!

Step 1: Add PHP Functions for Setting/Resetting Variables

In the last post, we set the form up so the value for each form field is set to a corresponding PHP variable. Now we need to make sure that when the form field changes and a user action (like submitting the form) takes place, the PHP variables get set to the newly updated form field values.  This is a simple process, as we just have to create a function to set the PHP variables.  And while we’re at it, we can create another function to reset the PHP variables for our ‘Clear Form’ button.  Here are the functions we’ll use.  Note that we need to use the ‘global’ keyword inside the functions to access and successfully update the variables.

function setVariables() {
   global $user_name;
   $user_name = $_POST["user_name"];
   global $user_email;
   $user_email = $_POST["user_email"];
   global $user_message;
   $user_message = $_POST["user_message"];
}
function resetVariables() {
   global $user_name;
   $user_name = "";
   global $user_email;
   $user_email = "";
   global $user_message;
   $user_message = "";
}

Again, these functions will eventually get called when a user clicks on the Submit or Reset button, respectively.

Step 2: Add PHP Functions for Form Field Validation

Now it’s time to write out the validation functions for the form.  In our example, we have three fields.  The name and message fields will be a simple character count for their validation.  In the email validation, we will use one of the well known regular expressions that will check the email value for correct syntax.

For the simple text input, we’ll create a function that accepts two arguments.  The first argument will be the value to get validated, and the second will be the minimum number of characters that need to be present in the first value.  Inside the function, there will be some simple conditional logic that will check the string length of the first value to the minimum number of characters.  We’ll also set a return value of ‘y’ or ‘n’ so we’ll know whether or not our value is valid.  Here’s what our simple text input validation function will look like:

function validateTextInput($str, $minLength=1) {
   if (strlen($str) < $minLength) {
      $lValid = 'n';
   } else {
      $lValid = 'y';
   }
   return $lValid;
}

For the email validation function, we’ll simply pass in the value to check as the one and only argument.  Inside the function, the conditional logic checks the value against the aforementioned regular expression.  And, like the text input validation function above, this one also returns a ‘y’ or ‘n’ value telling us whether or not the value is valid.  Here’s what our email validation function will look like:

function validateEmail($str) {
   if (!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$", $str)) {
      $lValid = 'n';
   } else {
      $lValid = 'y';
   }
   return $lValid;
}

Step 3: Add PHP Function for Overall Form Validation

Now that we have set up the individual form field validation functions, we’ll need a master function that will be called when the user clicks the Submit button.  It will validate all of our fields, and will hold logic to either show an error or send the form.  Here’s what the function will look like.  An explanation of the function is below the function.

function validateForm() {
   $default_error = "There was a problem with your entry. Please correct the following fields.";
   $error = "";

   // Set up global variables to check
   global $user_name;
   global $user_email;
   global $user_message;

   // Perform validation for fields
   $valid_user_name = validateTextInput($user_name, 1);
   $valid_user_email = validateEmail($user_email);
   $valid_user_message = validateTextInput($user_message, 5);

   if ($valid_user_name != 'y') {
      $error .= "<li>Your Name</li>";
   }
   if ($valid_user_email != 'y') {
      $error .= "<li>Your Email</li>";
   }
   if ($valid_user_message != 'y') {
      $error .= "<li>Message</li>";
   }

   // Return error value or send form
   if ($error) {
      echo "<div class=\"error\">";
      echo "<label>" . $default_error . "</label>";
      echo "<ul>";
      echo $error;
      echo "</ul>";
      echo "</div>";
   } else {
      sendForm();
   }
}

First, the function will have two variables: $default_error and $error.  As you noticed, the $default_error has the general text calling out that there’s an error, and the $error variable is blank by default.

Next, we set up the global variables that we need to check.

Third, we set up a unique variable that will be set to the return value of our individual field validation functions.  After these variables are set up, we put in conditional logic that appends the $error variable with <li> tags if the variable isn’t set to ‘y’.

Finally, there is conditional logic that checks the $error variable.  If this variable is set to anything other than its default blank value, we echo out some HTML markup that writes out our $default_error message, and then lists out each individual form field that is invalid.  If the variable is still blank, we call the sendForm() function (not included in this article – you can write that out depending on the needs of your project).

Step 4: Add Markup and Logic for Submit and Reset Button Actions

Now that we have everything set up, we obviously need to be able to call our validation and reset functions, based on what button the user clicks.  I am a fan of putting this logic inside of a <div> tag at the top of the form.  Since the validation function echos out a message if invalid, it will thus echo out to a div tag that we can style however we want.  Same with the reset logic, as we will first display a “are you sure you want to reset?” message with a ‘Yes’ and ‘No’ button.  Here’s the markup we’ll insert for this logic, that we’ll place between the opening <form> tag and the first <label>.

<!-- Error Message -->
<div id="error-message">
   <?php
   if ($_POST["submit"]) {
      setVariables();
      validateForm();
   }
   ?>
</div>

<!-- Reset Confirmation Message -->
<div id="confirm-reset">
   <?php
   if (isset($_POST['reset'])) {
      setVariables();
      echo "<div class=\"confirm\">";
      echo "<label>Are you sure you want to reset?</label>";
      echo "<div class=\"hidden\"><br /></div>";
      echo "<input type=\"submit\" class=\"button\" name=\"reset-yes\" value=\"Yes\" />";
      echo "<div style=\"display:inline; width:16px;\">&nbsp;&nbsp;</div>";
      echo "<input type=\"submit\" class=\"button\" name=\"reset-no\" value=\"No\" />";
      echo "</div>";
   } else if (isset($_POST['reset-no'])) {
      setVariables();
   } else if (isset($_POST['reset-yes'])) {
      resetVariables();
   }
   ?>
</div>

As you see, the error message <div> tag has conditional logic that checks for $_POST["submit"].  If our submit button is clicked, the two functions inside this conditional statement are fired off.  First, we call the setVariables() function, which as outlined above, sets all of our global PHP variables to the value of the form fields.  After we have called this function, we call our validateForm() function that validates each field and checks whether to display an error message or send the form.

The reset <div> tag is a bit more detailed.  Our form ‘Reset’ button is set up with name ‘reset’, which is equivalent to $_POST['reset'].  This is the first check of our conditional logic here, which calls the setVariables(), and echos out a <div> tag with the reset confirmation message and accompanying ‘Yes’ and ‘No’ buttons.

The second and third checks of the reset conditional logic check for the ‘Yes’ and ‘No’ button clicks.  If the ‘No’ button is clicked, we simply call the setVariables() function.  If the ‘Yes’ button is clicked, we call the resetVariables() function which as outlined above, resets all variables and therefore erases the form field values.

Wrapping It Up

As I mentioned at the beginning of the article, this is useful because all of the logic is done with PHP, and can thus be used on any browser and device, regardless of how the settings are configured.  What I like to do is to put all of the logic in its own file, and then include it in the page wherever I need it.  That way, if I have a completely separate set of files for full web vs. mobile, for instance, I can still use the same one file that contains the form, and style it with CSS depending on what version of the site the user is seeing.

Also, at this point, feel free to add in your own CSS and/or other HTML markup for how the form is set up and will be displayed.

Also, since there’s A LOT of code and logic here, I have gone ahead and packaged up the files in a zip file that you can download for your convenience.  The zip file includes some sample CSS styles that I have set up to customize the look of the form.

Until next time, happy coding!

With that said, here’s part 1 of how to build a bulletproof form using only HTML, PHP and CSS.

Step 1: Plan Your Form

This first step is important when building out a form.  Rather than just jumping in and starting to throw together a form, it’s helpful (and a big time-saver) to plan out what fields your form will have, and what types of fields they will be.  I find it helpful to either jot this info down on a piece of paper, or write it in pseudo-code inside of a comment block in my working file.  Either way, plan your form fields first.  It will make life much easier as you build out the form, and eventually its validation and processing.

For this tutorial, we’ll build out a form with three fields: Name, Email, and Message.  The form will also have a Submit and Reset button for form processing and resetting.

Step 2: Create PHP Variables for Each Form Field Value

Now that we have the form architecture figured out, we need to assign a PHP variable to each form field.  In our example, this means we’ll need 3 variables.  So at the very top of our file, inside of the PHP wrapper tags (<?php ?>), create a variable for each.  In our example, it will look like this:

<?php
$user_name = "";
$user_email = "";
$user_message = "";
?>

Note: This step could be swapped with step #3 below, but for the sake of brevity in this tutorial, I’m putting it here so we can plug these variable values directly in the form fields when we build out the form in step #3.

Step 3: Build Out the Form

This step is simple, as we just need to put together the pure HTML code for our form.  Our form will have two input fields and one textarea (for the message).  While assembling the code, I’m going to insert some extra <div> and <span> tags that are inserted to break up the form into containers in the absence of CSS.  This is done as a precaution for mobile devices that are not set up to enable CSS.  Many times the default is okay, but I’ve noticed that here and there, you need to hammer it down a little bit.

Another important thing that we’ll do here is to set the value of each form field to its accompanying PHP variable.  This is a setup step that will ensure that our form will “remember” its values, should any of the form fields fail in the validation process (still to come).  You know what I mean here – we’ve all been there – you fill out a long form, submit, and find out that the form is somehow invalid, and all of the form fields are blank again, forcing you to refill the entire thing all over again.  Frustrating, isn’t it?

This is actually much easier than you might think using PHP.  For the input fields, it’s a simple matter of echoing out the PHP variable inside of the ‘value’ attribute of the tag.  For the textarea, you’ll need to echo out the PHP variable between the opening and closing tags.  And don’t worry – since our PHP variables are set as empty strings by default, the fields will also be empty when the form initially loads.  But as the form and validation logic get built out, our PHP variables are set to match the form fields, and thus the form fields will be populated with the “remembered” value of the field (stored in the variables) rather than being blank.

In our example, our form looks a little something like this:

<form action="" method="post" name="contact_form" id="contact_form">
   <div>
      <label for="user_name">Your Name:</label>
         <span class="hidden"><br /></span>
      <input type="text" name="user_name" value="<?php echo $user_name; ?>" autocomplete="off" tabindex="1" />
   </div>
   <div>
      <label for="user_email">Your Email:</label>
         <span class="hidden"><br /></span>
      <input type="text" name="user_email" value="<?php echo $user_email; ?>" autocomplete="off" tabindex="2" />
   </div>
   <div>
      <label for="user_message">Message:</label>
         <span class="hidden"><br /></span>
      <textarea name="user_message" autocomplete="off" wrap="physical" tabindex="3"><?php echo $user_message; ?></textarea>
   </div>
   <div class="centered">
      <input type="submit" name="submit" value="Submit &raquo;" />
      <input type="submit" name="reset" value="Reset Form" />
   </div>
</form>

A few important notes about the form setup:

• We didn’t include any value in the action attribute for the form tag.  This is because we’re going to house all of the form logic within the same file to reduce page-to-page navigation, and the amount of external files we need to concern ourselves with.  There are different schools of thought about this, but this is the method we’ll use for this tutorial.
• As discussed above, PHP markup has been inserted into the form fields as their values.
• Each form field tag has a unique name.  This will be necessary when we start to set/reset variables and validate the form later on down the road.
• Each form field is set up here with the autocomplete attribute set to “off”. This is just more of a security precaution that I like on contact forms, that makes it so the browser doesn’t remember previous values you’ve typed in other forms, in the case that you’re using a public computer that doesn’t delete private browsing history.  (Note: This doesn’t have anything to do with the method we’re using to echo out our PHP variables into the form, as our PHP variable method will simply keep our values in the form upon unsuccessful form submission, whereas the autocomplete attribute would have a dropdown of “remembered” values of past forms when the user starts typing.)
• Overall, I’ve included a number of ids and classes in the form that will be later used to style it with CSS for browsers and mobile devices that have CSS enabled.

What’s Next

We now have the framework for our form, and have set up some of the initial PHP logic to help us populate and store form values.  In the next segment, we’ll work on adding in the variable setting/resetting functionality, as well as the validation functions.  Also, and most importantly, we’ll tie in the Submit and Reset buttons with the correct functionality to make the form do what it’s supposed to do.

Until the next part of this tutorial, happy coding!

Why, you ask?

As time goes on, I’m finding myself drawing closer and closer to sticking close to pure HTML/CSS code, with other standards-compliant languages like PHP/MySQL and JavaScript.  Not to say Flash and it’s programming language (ActionScript) isn’t compliant with anything.  I had simply found myself doing things in Flash by default because it’s what I was most comfortable with, and could do with the least amount of technical issues.

But, now that I’ve been exploring more uses for JavaScript in place of what would normally be Flash code, it’s easier and easier to pull myself away from Flash.  Plus, as I’ve been doing more and more dynamic code content with PHP, I’m finding myself a lot more excited about using PHP than I am about using Flash.  I still enjoy Flash, and don’t get me wrong — there are definitely times and places for Flash.  But for where I’m at now, I am finding that my own site doesn’t currently need to rely on Flash so much.

Outside of the programming techniques used for the most recent release of the site, I felt like it was definitely the time for a change regarding the design of the site.  The new design has a much more sophisticated simplicity and clean look than the old version. It’s focus is more on the projects and artwork, as they take a very prominent position on the Work page with only the project details to accompany them.  No fluff content just to fill in space and give users something else to read.  Only the necessities.

With that all said, I hope you enjoy the newest iteration of HesslerDesign.com.  If you haven’t already, check out the Work page, which has a few new projects listed that I’ve completed recently.  I hope you like what you see.

Until next time, happy coding!

SEOmoz is a popular provider of SEO software.  It’s website is dedicated to all things SEO, including a blog, helpful articles and user guides, and best of all, a set of tools that webmasters can use to help their site’s SEO.  Some of the tools are only available to “Pro” members, which costs money.  But a little over half of them (at the writing of this entry) are completely free to use (some with daily restrictions on use).

One of the coolest free tools available to anyone is the SEO Toolbar for Firefox.  With the toolbar, you can access any of the SEOmoz tools right from the toolbar, without having to go to the actual site first.  It’s incredibly handy, and also includes stats like Page Authority and Domain Authority, which give real-time stats on the site you’re currently on.

So next time you get the question, “How can I improve my search rankings?”, look to SEOmoz.org as your first (and likely, only) stop for resources and tools to help guide you on your road to SEO success.

Until next time, happy coding!

1. Use XML files to set content framework

On nearly every Flash site I work on, I use at least some XML. The great thing about XML files is they are a great way to structure blocks of your site.  For instance, if you want a slideshow on your site, you could have an XML file that contains the title, url, and other image-specific information you want to include for each image. Then, just import the XML into Flash and store the XML data in arrays to organize the information to use later.  (More on arrays below.)

Another great thing about using XML in Flash is that if you want to stream an RSS feed into a Flash site, you can, because RSS feeds are set up as XML.  (For more info on RSS feeds, see the post on Streaming RSS feeds into Your Flash Applications.)

Additionally, XML is easy to change without having to republish your site.  Say you have that slideshow I mentioned above, but want to swap out an image.  With XML, you just point to the new url, update the title, and save. Your Flash site will automatically update with the new info, and you won’t have to republish every time. Trust me, you’ll thank yourself for using XML when you build your Flash site.

2. Use arrays to organize assets used in your code

For me, using arrays is quite possibly one of the smartest and most powerful things you can do to optimize your code.  Not necessarily from a file weight perspective, but because with arrays, you can reference an object stored in an array by name, number, id, etc. For instance, say you have 20 thumbnail images you want to make clickable to open a larger image. You could attach individual event listeners to each image.  Or, you could set up a couple of arrays — one for the instance names of each image, and one for the reference to the larger image to load when clicked — and run “for” loops to set the event listeners all at once. While you’re in the “for” loop, set an ID number for each image that you can then reference in your “click” function that will fire on mouse click, and call up that ID number slot in the large image array.  With only a few lines of code, you’ll have a powerful way to batch chunks of your code with minimal effort. (For more info on arrays, see my post on Utilizing the Power of Arrays in Adobe Flash.)

3. Only import and embed absolutely necessary image files into your file.

If you’ve been on the Web at all…and judging by you reading this, I’m guessing you have…you know doubt know that a lot of people don’t like Flash sites.  The main reason seems to be they take way too long to load.  To get around this, I highly suggest importing and embedding ONLY the images you absolutely need.  If you have a lot of image assets, I suggest loading them dynamically via code, and placing them in the appropriate places.  This not only makes the file size considerably smaller, but it also opens the door to be able to update an image, replace it, and have Flash automatically read in the updated file without the need to republish the entire site.  (Sorta sounds like one of the key perks of using XML, doesn’t it?)  And trust me, users will thank you for having a site that loads (or at least shows up with a short preloader) in 5 seconds, rather than a beefy site that doesn’t show up until the entire thing loads.

4. Load assets in an orderly fashion, not all at once

Along with #3 above, when you load assets into your Flash site dynamically, it’s best to set up a structure and order in which to load them. For instance, load all of the home/landing page assets first. Once those are loaded, proceed with the next set of assets that you think will be needed/viewed by your users.  Not using a certain set of images until later in the site?  Don’t load them up front. Wait until the rest of the assets before it have been loaded first. Think about it.  Would you rather try to have 20 images load all at once?  Or load them in the order of which they’ll be seen? Loading them one at a time will speed up the individual image load time because there is only one image needing attention while it is being loaded, not all 20?

5. Cool it with the videos

Okay, this sounds harsh, but hear me out. Video is great. It’s everywhere, and it’s getting more popular by the day.  (YouTube, anyone?)  But when you’re making a Flash site, video can also be a beast to work with, specifically video that needs to stream without a playback bar.  The worst thing about video is file size. I’ll admit, video has come a long way in optimizing file weights and all, but at the end of the day, even a small video is still going to be around 1-2MB.  When you are using video, make sure you utilize the “loading assets in an orderly fashion” advice from above.  If you try to start streaming a video when 20 images are loading while it’s trying to play, you’ll no doubt get choppy playback.

6. Use TweenMax or TweenLite for code-based tweening and animating

I’m a big fan of keeping my Flash sites on one frame of the timeline, and doing as much as I possibly can with code, rather than with the timeline.  The reason for this is simply less time making changes later on down the road.  Want to make every tween of an image fading out half as long across the entire site?  Pretty laborious if you’re using the timeline.  But if you’re using code, it’s a matter of updating a couple of numbers.

This is where TweenMax and TweenLite come in.  In a nutshell, they’re the best tweening engine out there.  Using it, you can call one function that can alter many facets of an object at once (x and y position, alpha, tint, etc.).  You can also attach event listeners like onComplete, onStart, etc., that call functions to run at specific times during the tween.  In short, these tweening engines will make you wonder why you ever used timeline-based animations.  And best of all, they’re extremely light in file weight, unlike a lot of timeline-based animations.  And it’s a one-time file weight addition, not a per-tween sort of thing.

7. Simulate downloading on slower connections

Not everyone has a cable-speed connection. Believe it or not, there are still a lot of people out there using DSL or slower connections.  And as unfortunate as it may be, those are the people you need to build the site for.  Don’t ever assume that your audience is going to have the latest and greatest computers.

To simulate downloads in Flash, export your movie and select “View > Simulate Download”.  To set different connection speed settings, select “View > Download Settings”, and select your desired speed (or create your own custom speed).  Flash can be deceiving. When you test out a movie, it always runs lightning fast. But by testing it using the “Simulate Download” method, you’ll get a much better idea of how your site will behave on the Web.

8. Build buttons and other UI components as vector artwork in Flash

One of my biggest pet peeves is using raster images for buttons that could easily be made as vector art in Flash.  Not only does this make having to update the button a multi-step process, but it also beefs up the size of the file.  It may not be much, but if you get a dozen different image buttons, you could easily have just added 100+ kb to your file weight.  Might not seem by much, but as people’s attention spans are getting shorter and shorter, that added 2 seconds of load time you just added might be costly, and you may see an increase in the number of dropped users.

My motto is this: “If it can be made in Flash, make it in Flash”.  Vector art is not only easily editable, but also a huge file weight saver.  Plus, you don’t get any degradation of quality that you’d get if you used images.  All of your lines, colors, gradients, etc. are crystal clear.  Pair that with the almost non-existent file weight they carry, and what’s not to love?

9. Write custom Classes for reusable code

If you write Actionscript code, you use Classes.  You might not know it, but you do.  Every time you use a property of a MovieClip instance (i.e. myClip_mc.y to get the “y” position), you’re calling the MovieClip class.  Same with Sprites, Buttons, UI Components, etc.  Classes are a staple in object-oriented programming, and allow you to read or set properties, call functions (methods), and respond to events.  It’s a great way to reuse the same code over and over again, by simply importing the classes into your site file.

One of my personal favorite classes that I have written is for an Email Validator, which contains the logic to check whether a string is a valid email address or not.  You can check it out in my previous post on Building a Better Email Validator in Flash.  Each time I need to use this, I simply import it into my file (which is 1 line of code), make an instance of the validator (1 line of code), then call the validate function and pass in the string to validate (1 line of code).  In all, for me to validate an email address, it takes 3 lines of code.  Much better than rewriting all of the validation logic in a dozen different files, eh?

10. Use FlashVars to set important global variables

Every so often, you’ll run into an issue where you’ll want to change a variable from outside of your Flash file. An easy way to do this is to use the FlashVars parameter when embedding your Flash file in HTML.  I find that I mostly use FlashVars for variables that will change from a “staging” site to the final “production” site.  The most often used variable that I personally encounter is the account name for Omniture tracking. The bulk of sites I develop have different staging and production Omniture account names, so the metrics don’t get skewed while testing.  But if I embed that account name into the Flash file, I suddenly need 2 different versions of the Flash file — one for staging, one for production.  But if I have a FlashVar set up for this account name, I can just change the variable in the HTML code, and have Flash read it in.  Trust me, it’s a handy way to avoid having multiple versions of the same file for different environments.

In Conclusion…

So there you have it.  10 easy ways to optimize your Flash sites.  There are many more ways to optimize Flash sites, and I’m sure I’ll get into them in later posts.  But these are some of the main culprits.  And trust me, individual posts could be written about each one of these (and some already have).  If you want to see posts that dive deeper into any of these, just let me know and I’ll write it up.  Until next time, happy coding!