However, the landscape has changed. Googlebot now indexes BOTH the Flash AND the HTML in SWFObject. The big problem this causes is that Google now gives results with direct links to your SWFs, which can completely mess everything up — I wrote a post that explores the problems presented by Google’s ability to index Flash if you want to read more. In a nutshell, however, I personally have come to the conclusion that although the method I describe below is not IDEAL, it still offers the best way to build all-Flash sites that will get properly indexed and will most often present the correct links in Google results.

So without further ado, here’s how to go about building a SEO-friendly Flash site using SWFObject and SWFAddress.

1. Use SWFObject
   If you’re not already using the latest version of SWFObject, you should be. Adobe has now announced that it is supporting SWFObject specifically. The beauty of SWFObject is that it allows you to serve Flash to people who can support it and (X)HTML to people who can’t. Also, search engine crawlers index the (X)HTML alternate content you serve, meaning that if you put your content in there, it will get indexed.
2. Create HTML pages for each of your flash pages
   For each of your Flash pages (home, about us, contact us, etc.), create an HTML page that mirrors its content. That means all the text, all the links, all the pictures, etc. The HTML page doesn’t need to be pretty, but it should semantically reflect the importance of the content on your Flash page (that means have headings, have lists, have paragraphs, use proper links, etc. This will allow search engine crawlers to make proper sense of the content on the site. Also, if you want to make your Flash site mobile-friendly, then make these HTML pages pretty
3. Use SWFObject and multiple Flash files to hide the content
   So you have all these pages, but you don’t want anyone who can support Flash to SEE them – only search engines. That’s where SWFObject comes in. On each of these HTML pages, you will use SWFObject to embed the same Flash file, but have the non-Flash content reflect the HTML you built.
4. Use SWFAddress and deep linking to direct Flash users to the proper content
   Like SWFObject, if you’re not using SWFAddress, you probably should be. SWFAddress allows you to read information from the URL and then use that within your Flash. The most common reason for doing this is to be able to do deep linking in Flash. I will write some tutorials on how to use SWFAddress in the future, but for now you should download the example files and work through them. Using SWFAddress, you can use #anchors to define where in your Flash you want to go. So if you go to “www.mysite.com/index.html#aboutUs”, you can have SWFAddress load up your “About Us” section. The beauty of this is that search engines ignore #anchors so they won’t get confused and mess up indexing on your site.
5. Add a JavaScript call using SWFAddress to direct your Flash to the right section
   At this point you’ve got multiple HTML pages and the ability to deep link in Flash. Now you need to direct users who come from a search engine to the right content within your Flash. All you need to do is call SWFAddress from JavaScript and update the page URL. Since your Flash is set up to use SWFAddress, it will read the update and take the user to the proper section.

All those steps are a little abstract, so here’s a more solid example:

Let’s say I’ve got a website with three pages: a “Home” page, an “About Us” page , and a “Contact Us” page. I’ve built this website in Flash with only one Flash file called “main.swf”. Now I want to make sure that this site is search engine optimized.

First thing I do is make sure that I embed the page using SWFObject. Since this first page will be my “Home” or index page, I create a page called “index.html”. At this point, my index.html code will look like:

<!-- Start swfobject code -->
<script src="swfobject.js" type="text/javascript"></script>
 <script type="text/javascript"><!--

var flashvars = {};

var params = {};
params.wmode = "transparent";

var attributes = {};

swfobject.embedSWF("main.swf", "flashContent1", "760", "420", "9.0.0", "expressInstall.swf", flashvars, params, attributes);

// --></script>
<!-- end swfobject code -->
<div id="flashContent1"></div>

<!-- Start swfobject code -->
<script src="swfobject.js" type="text/javascript"></script>
 <script type="text/javascript"><!--

var flashvars = {};

var params = {};
params.wmode = "transparent";

var attributes = {};

swfobject.embedSWF("main.swf", "flashContent1", "760", "420", "9.0.0", "expressInstall.swf", flashvars, params, attributes);

// --></script>
<!-- end swfobject code -->
<div id="flashContent1">
<h1>About Us</h1>
Here is a bunch of information that I've copied and pasted from my Flash file. It's all the content from my About Us page.
<ul>
  <li><a href="home.html">Home</a></li>
  <li><a href="aboutUs.html">Home</a></li>
  <li><a href="contactUs.html">Home</a></li>
</ul>
</div>

I’ve now got three files with HTML content within them that mirrors my Flash. This means that Googlebot can now see my content. However if someone searches for an item that appears on my About Us page and clicks on the link in Google, they’ll be taken to “www.mysite.com/aboutUs.html” and will see my Flash. The only problem is they’ll see my HOME page in Flash, not my About Us page. That’s where SWFAddress comes in.

First, I have to set up SWFAddress in my Flash file. NOTE: You should always build your site from the beginning using SWFAddress to navigate your Flash. It’s a HUGE pain to try to go back and retrofit your site to work with SWFAddress, but it’s pretty easy to build your site to use SWFAddress from the beginning. Either way you go, you will add ActionScript which looks similar to this:

// SWFAddress handling
import com.asual.swfaddress.*;
function handleSWFAddress(e:SWFAddressEvent) {
try {
if (currentFrame == 2 && e.value == '/') {
play();
} else {
gotoAndStop('$' + e.value);
}
} catch(err) {
gotoAndStop('$/error/');
}
}
SWFAddress.addEventListener(SWFAddressEvent.CHANGE, handleSWFAddress);

However, what happens if a person goes to “www.mysite.com/aboutUs.html”? SWFAddress looks for information following the “#” so it doesn’t know that it has to go to the About Us section. You do this by adding updating SWFAddress using a call to it in your javascript. The code for this is really simple:

SWFAddress.setValue([link value]);

So your About Us page code becomes:

<!-- Start swfobject code -->
<script src="swfobject.js" type="text/javascript"></script>
 <script type="text/javascript"><!--

var flashvars = {};

var params = {};
params.wmode = "transparent";

var attributes = {};

swfobject.embedSWF("main.swf", "flashContent1", "760", "420", "9.0.0", "expressInstall.swf", flashvars, params, attributes);

SWFAddress.setValue("/aboutUs");

// --></script>
<!-- end swfobject code -->
<div id="flashContent1">
<h1>About Us</h1>
Here is a bunch of information that I've copied and pasted from my Flash file. It's all the content from my About Us page.
<ul>
  <li><a href="home.html">Home</a></li>
  <li><a href="aboutUs.html">Home</a></li>
  <li><a href="contactUs.html">Home</a></li>
</ul>
</div>

All you need to do is build a movie clip with at least two frames, one which holds all the art for the “pre-launch” message and one which holds all the art for the “post-launch” message. Then you have a simple script which takes the cutoff date, checks it against the current date, and if it’s after launch, go to the “post-launch” frame. Here’s the script that I use:

// Remember months start from 0 (january=0, feb=1, etc.)
var launchDate:Date = new Date(2008,10,18);

function checkDate()
{
  // Check to see if this after the launch date
  var thisDate:Date = new Date();
  if (thisDate >= launchDate)
  {
    gotoAndStop("launch");
  }
}

checkDate();

It’s as easy as that! The only trick is to remember that in Flash, months start at 0. So November is number 10, instead of 11 (seems simple but it’s funny how ingrained month numbers are in ones mind!).

Here’s an example FLA which shows how the code above functions: dateSelector.zip

In my last posting on Flash indexing by Google, I said that we should watch and wait because thorough testing and standards will begin to emerge over time. Well, the wait is over: Brian Ussery has published the first (so I’ve found) set of case studies on how Google indexes Flash. The results confirm much of what we already suspected.

Ussery conducted four case studies, studying different aspects of how Googlebot interacts with Flash. Here’s the upshot of his studies:

• CASE STUDY #1: Does Googlebot correctly associate text inside a Flash file with the parent URL (the page that the Flash is embedded in)?
  RESULTS: No. Usually Googlebot indexes the parent URL and the Flash separately.
• CASE STUDY #2: Can Flash files accrue PageRank?
  RESULTS: Yes. Flash files accrue PageRank independently of their own parent URLs.
• CASE STUDY #3: Does Googlebot follow URLs containing #anchors?
  RESULTS: No. Googlebot ignores #anchors and only extracts URLs preceding the #anchor.
• CASE STUDY #4: Can Google translate text inside of a Flash file?
  RESULTS: No. Googlebot can not translate text inside of a Flash file.

All these case studies seem to support the conclusion I came to earlier: Google’s indexing support of Flash is meager at best, and at its worst, could possibly hurt your placement on search engines. So what should we, as Flash developers, do if we want to have a search engine optimized Flash site?

In the past, you could use SWFObject to embed your Flash and it would present the Flash file to people who could support it (people with the correct Flash plugin) and it would present alternate (X)HTML to people who COULDN’T support Flash. In the past, this also included Googlebot. So if you set up alternate (X)HTML, Googlebot would index that and if you built it right, your Flash pages could have nearly the same ranking as regular HTML pages (because Google was seeing HTML). This allowed you to build Flash sites normally, then build a bunch of alternate HTML pages that had the same Flash embedded, write out their content in HTML, use deep linking to have each individual page go to the correct “page” within Flash, and nobody was the wiser — Google indexed your content and people clicking on Google’s links would see the correct Flash. You can click here to see my tutorial on how to build a site this way.

However, that’s no longer the case. Brian Ussery and Bobby van der Sluis in their testing have found that Google now indexes BOTH the (X)HTML content AND the Flash content in SWFObject. You might say “So what? Now Google is guaranteed to find my content — great news!” The problem is that Google, in the search results, could present a link DIRECTLY to your Flash file which may or may not be the correct “page” reflected in your (X)HTML. So now in your Google search results you can have a bunch of (X)HTML pages show up AS WELL AS a bunch of Flash files. There’s no way for you to dictate which page Google puts at the top of the list, so you could have people clicking through to Flash files that you don’t want.

So what do we do? Well, for my two cents I think we should still build sites using the original method for building SEO-friendly websites. While it you may get multiple results, I think that the benefits outweigh the negatives. Here’s why:

• Not all search engines can index Flash, so the other search engines will index your (X)HTML content and serve up the intended pages as you intended.
• Google still indexes the (X)HTML pages. Since most (X)HTML pages will be more SEO friendly than the Flash, chances are that the (X)HTML pages will be ranked higher in the results, and since people are more inclined to click higher results, chances are you’ll still get the intended results. I know that “chances are” is contrary to most practices in SEO, but it’s the best we’ve got at this juncture
• It’s the only option we’ve got. Googlebot is indexing Flash now, whether we like it or not. Given that Googlebot’s ability to index Flash files is not as good as its ability to index (X)HTML files, the only option I can think of to help people find the content they’re looking for is to make sure that we’ve got (X)HTML content that WILL be correctly indexed (alongside the Flash that WON’T).

I sincerely hope that Googlebot’s ability to index Flash sites will continue to get better so that we can simply build Flash sites as Flash sites. I also hope that the entire Flash community continues to do research and testing to help this process. I recognize that the process that I endorse carries with it some problems and I welcome suggestions for better ways to optimize Flash for search engines. But from my current vantage point, this looks like the best way to do it to me.

The solution lay in this well-hidden article on Adobe’s site. In essence, the article states that they’ve made Flash’s security settings even more strict, and that means that in some situations, you need to change things around in order to make sure that Flash will accept your policy file. I set my computer up with Flash 9 debugger version, set it up to log policy errors, and then looked at my policy file log which revealed the problem: Server B was returning the crossdomain xml file as Content-Type “application/x-httpd-php5-source”. With Flash 9′s newer, stricter settings, Flash 9 will only accept policy files of the following content-types:

1. text/* (any text type)
2. application/xml or application/xhtml+xml

As soon as we changed the crossdomain’s content-type, the Error #2048 went away and the form processed correctly!

So the upshot is that if you’re getting Error #2048 notices and you can’t get them to go away no matter what you try, follow the steps outlined on this page at Adobe. Once you’ve set your computer up to debug and log your policy files, you’ll be able to check and see if a policy file content-type problem is causing your troubles.

Hello,
We have a project that requires free falling snow flakes. When the cursor enters the stage we need the flakes to ‘rush’ toward the pointer and follow it. When the cursor leaves the stage the flakes drift away and down.

Can anyone point me toward an FLA or tutorial?

Many thanks

Well, for some reason I got all obsessed with this question and I wrote the following tutorial:
I did a rough version that emulates this effect. You can probably fine-tune it to be nicer, but this will get you started. Here’s what you need to do:

1. You need some sort of snowflake effect. Rather than start from scratch, you can download one. I downloaded the SnowFlakes class from Pixelfumes: http://pixelfumes.blogspot.com/2006/11/actionscript-3-snow-storm-class.html and I’m using the snowFlake.fla for the example (which you can also download from that link).

2. This class now needs to be modified to do what you were talking about. So first step is to make it so that the movie can register clicks. I created an invisible button called btnClick that was 450 x 450 (covering the whole movie).

3. We want to make sure that the snowflakes are underneath the button, or the user’s click won’t be registered. So in the actions frame of snowFlake.fla, I changed the createFlakes function to:

[[code]]czoxMDY6XCJmdW5jdGlvbiBjcmVhdGVGbGFrZXMoKTp2b2lkew0KICAgICB2YXIgc0ZsYWtlOlNub3dGbGFrZSA9IG5ldyBTbm93Rmx7WyYqJl19YWtlKCk7DQogICAgIGFkZENoaWxkQXQoc0ZsYWtlLDApOw0KfVwiO3tbJiomXX0=[[/code]]

This adds the new snowflake underneath everything else.

4. Now we want to have something happen when the user clicks on the movie. So we add the following code:

[[code]]czo1ODpcImJ0bkNsaWNrLmFkZEV2ZW50TGlzdGVuZXIoTW91c2VFdmVudC5DTElDSywgdG9nZ2xlRmxha2VzKTtcIjt7WyYqJl19[[/code]]

5. The toggleFlakes function needs to do a couple of things. First, check to see if it’s snowing. Then, if it IS snowing, it needs to stop snowing and have all the snowflakes go to the mouse. If it’s NOT snowing, it needs to have all the snowflakes go away from the mouse and start moving again. To do this, I added the following code:

[[code]]czozNjk6XCJ2YXIgaXNTbm93aW5nOkJvb2xlYW4gPSB0cnVlOw0KZnVuY3Rpb24gdG9nZ2xlRmxha2VzKGU6RXZlbnQpOnZvaWQgew17WyYqJl19CiAgICAgaWYgKGlzU25vd2luZykgew0KICAgICAgICAgIHN0b3BGbGFrZXMoKTsNCiAgICAgICAgICBpc1Nub3dpbmcgPSBmYWxzZXtbJiomXX07DQogICAgIH0gZWxzZSB7DQogICAgICAgICAgc3RhcnRGbGFrZXMoKTsNCiAgICAgICAgICBpc1Nub3dpbmcgPSB0cnVlOw0KICAge1smKiZdfSAgfQ0KfQ0KDQpmdW5jdGlvbiBzdG9wRmxha2VzKCk6dm9pZCB7DQogICAgIHRyYWNlKFwic3RvcEZsYWtlcyBjbGlja2VkXCIpOw0KfXtbJiomXX0NCg0KZnVuY3Rpb24gc3RhcnRGbGFrZXMoKTp2b2lkIHsNCiAgICAgdHJhY2UoXCJzdGFydEZsYWtlcyBjbGlja2VkXCIpOw0KfVwiO3tbJiomXX0=[[/code]]

6. So now we know we need to stop the flakes somehow… enter the stopFlakes function. Without identifying what that function IS, just yet, let’s assume that it will be a function that we’ll add to the SnowFlake class that will stop an instance of the snowflake from animating and cause it to move to the mouse. If we’re going to do it that way, we should create an array which will store references to all the snowflakes so we can trigger them at will. We do this by adding the following code:

[[code]]czozNTpcInZhciBmbGFrZUFycmF5OkFycmF5ID0gbmV3IEFycmF5KCk7XCI7e1smKiZdfQ==[[/code]]

And by modifying the createFlakes function to be:

[[code]]czoxMzc6XCJmdW5jdGlvbiBjcmVhdGVGbGFrZXMoKTp2b2lkew0KICAgICB2YXIgc0ZsYWtlOlNub3dGbGFrZSA9IG5ldyBTbm93Rmx7WyYqJl19YWtlKCk7DQogICAgIGFkZENoaWxkQXQoc0ZsYWtlLDApOw0KICAgICBmbGFrZUFycmF5LnB1c2goc0ZsYWtlKTsNCn1cIjt7WyYqJl19[[/code]]

Now we can reference all the created snowflakes, let’s make it so that by running stopFlakes, you run “gotoMouse” on all the flake instances:

[[code]]czoxNTQ6XCJmdW5jdGlvbiBzdG9wRmxha2VzKCk6dm9pZCB7DQogICAgIHRyYWNlKFwic3RvcEZsYWtlcyBjbGlja2VkXCIpOw0KICAgIHtbJiomXX0gZm9yICh2YXIgaTppbnQ7IGk8bnVtRmxha2VzOyBpKyspIHsNCiAgICAgICAgICBmbGFrZUFycmF5W2ldLmdvdG9Nb3VzZSgpOw0Ke1smKiZdfSAgICAgfQ0KfVwiO3tbJiomXX0=[[/code]]

7. Now we’ll need to start the flakes once again… so this is the startFlakes function. Let’s assume the function we’ll build in the SnowFlake class is called “restoreFlakes”. So our startFlakes function becomes:

[[code]]czoxNjA6XCJmdW5jdGlvbiBzdGFydEZsYWtlcygpOnZvaWQgew0KICAgICB0cmFjZShcInN0YXJ0Rmxha2VzIGNsaWNrZWRcIik7DQogIHtbJiomXX0gICBmb3IgKHZhciBpOmludDsgaTxudW1GbGFrZXM7IGkrKykgew0KICAgICAgICAgIGZsYWtlQXJyYXlbaV0ucmVzdG9yZUZsYWtle1smKiZdfXMoKTsNCiAgICAgfQ0KfVwiO3tbJiomXX0=[[/code]]

8. OK — now we’re ready to start editing the SnowFlakes class and add the real functions. First let’s do “gotoMouse”. Open up the SnowFlake class. Let’s think about what the gotoMouse function needs to be and needs to do:
* It needs to be referenced by things OUTSIDE of the class
* It needs to stop the snowflake from moving
* It needs to move the snowflake to the mouse position

9. The first task: It needs to be referenced by things OUTSIDE of the class. This means it needs to be a public function, so add this to the class:

[[code]]czozNjpcInB1YmxpYyBmdW5jdGlvbiBnb3RvTW91c2UoKTp2b2lkew0KfVwiO3tbJiomXX0=[[/code]]

10. The second task: It needs to stop the snowflake from moving. OK, well if we look at the class, we can see that the following code is causing the snowflake to move:

[[code]]czo5MzpcInByaXZhdGUgZnVuY3Rpb24gbW92ZU1lKCk6dm9pZHsNCiAgICAgdGhpcy5hZGRFdmVudExpc3RlbmVyKEV2ZW50LkVOVEV7WyYqJl19Ul9GUkFNRSxldmVyeUZyYW1lKTsNCn1cIjt7WyYqJl19[[/code]]

Easy enough to counter:

[[code]]czo5OTpcInB1YmxpYyBmdW5jdGlvbiBnb3RvTW91c2UoKTp2b2lkew0KICAgICB0aGlzLnJlbW92ZUV2ZW50TGlzdGVuZXIoRXZlbnR7WyYqJl19LkVOVEVSX0ZSQU1FLCBldmVyeUZyYW1lKTsNCn1cIjt7WyYqJl19[[/code]]

11. The third task: it needs to move the snowflake to the mouse position. We’re dealing with movement, so I personally always use Tweener to handle movement (http://code.google.com/p/tweener/). Download Tweener, put it in the same folder as the FLA, and add the following import command to the top of the class with all the other imports:

[[code]]czozNTpcImltcG9ydCBjYXVyaW5hLnRyYW5zaXRpb25zLlR3ZWVuZXI7XCI7e1smKiZdfQ==[[/code]]

We also need to move it to the mouse position, so let’s pass the mouse position from the original call to this function. So the call in the snowFlake.fla becomes:

[[code]]czoxNjc6XCJmdW5jdGlvbiBzdG9wRmxha2VzKCk6dm9pZCB7DQogICAgIHRyYWNlKFwic3RvcEZsYWtlcyBjbGlja2VkXCIpOw0KICAgIHtbJiomXX0gZm9yICh2YXIgaTppbnQ7IGk8bnVtRmxha2VzOyBpKyspIHsNCiAgICAgICAgICBmbGFrZUFycmF5W2ldLmdvdG9Nb3VzZShtb3Vze1smKiZdfWVYLG1vdXNlWSk7DQogICAgIH0NCn1cIjt7WyYqJl19[[/code]]

[[code]]czoxMjM6XCJwdWJsaWMgZnVuY3Rpb24gZ290b01vdXNlKHhQb3M6TnVtYmVyLCB5UG9zOk51bWJlcik6dm9pZHsNCiAgICAgdGhpcy57WyYqJl19cmVtb3ZlRXZlbnRMaXN0ZW5lcihFdmVudC5FTlRFUl9GUkFNRSwgZXZlcnlGcmFtZSk7DQp9XCI7e1smKiZdfQ==[[/code]]

Now we need to add the tween, so add the Tweener code and the function becomes:

[[code]]czoyMDc6XCJwdWJsaWMgZnVuY3Rpb24gZ290b01vdXNlKHhQb3M6TnVtYmVyLCB5UG9zOk51bWJlcik6dm9pZHsNCiAgICAgdGhpcy57WyYqJl19cmVtb3ZlRXZlbnRMaXN0ZW5lcihFdmVudC5FTlRFUl9GUkFNRSwgZXZlcnlGcmFtZSk7DQogICAgIFR3ZWVuZXIuYWRkVHdlZW4odHtbJiomXX1oaXMsIHt4OnhQb3MsIHk6eVBvcywgdGltZTowLjUsIHRyYW5zaXRpb246XCJlYXNlT3V0U2luZVwifSk7DQp9XCI7e1smKiZdfQ==[[/code]]

12. OK, now we need to create the function that will start the flakes once again. We’re calling this restoreFlakes. What does it need to do?
* It needs to be referenced by things OUTSIDE of the class
* It needs to move the snowflake back to its original position
* It needs to start the snowflakes moving again.

13. The first task is easy — it needs to be a public function:

[[code]]czo0MDpcInB1YmxpYyBmdW5jdGlvbiByZXN0b3JlRmxha2VzKCk6dm9pZHsNCn1cIjt7WyYqJl19[[/code]]

14. The second task — move back to the original position. This means we need to track where the snowflake was when it got paused, so we need to modify the gotoMouse function to record where the snowflakes were. To do this we add the following variables to the class:

[[code]]czo2MDpcInByaXZhdGUgdmFyIHRoaXNYOk51bWJlciA9IDA7DQpwcml2YXRlIHZhciB0aGlzWTpOdW1iZXIgPSAwO1wiO3tbJiomXX0=[[/code]]

We then modify the gotoMouse function:

[[code]]czoyNTE6XCJwdWJsaWMgZnVuY3Rpb24gZ290b01vdXNlKHhQb3M6TnVtYmVyLCB5UG9zOk51bWJlcik6dm9pZHsNCiAgICAgdGhpcy57WyYqJl19cmVtb3ZlRXZlbnRMaXN0ZW5lcihFdmVudC5FTlRFUl9GUkFNRSwgZXZlcnlGcmFtZSk7DQogICAgIHRoaXNYID0gdGhpcy54Ow0KIHtbJiomXX0gICAgdGhpc1kgPSB0aGlzLnk7DQogICAgIFR3ZWVuZXIuYWRkVHdlZW4odGhpcywge3g6eFBvcywgeTp5UG9zLCB0aW1lOjAuNSwge1smKiZdfXRyYW5zaXRpb246XCJlYXNlT3V0U2luZVwifSk7DQp9XCI7e1smKiZdfQ==[[/code]]

Then we modify the restoreFlakes function to move the snowflakes back:

[[code]]czoxMjY6XCJwdWJsaWMgZnVuY3Rpb24gcmVzdG9yZUZsYWtlcygpOnZvaWR7DQogICAgIFR3ZWVuZXIuYWRkVHdlZW4odGhpcywge3h7WyYqJl19OnRoaXNYLCB5OnRoaXNZLCB0aW1lOjAuNSwgdHJhbnNpdGlvbjpcImVhc2VPdXRTaW5lXCJ9KTsNCn1cIjt7WyYqJl19[[/code]]

15. The third task — make them start moving. Well, just add the listener back in and the function becomes

[[code]]czoxODY6XCJwdWJsaWMgZnVuY3Rpb24gcmVzdG9yZUZsYWtlcygpOnZvaWR7DQogICAgIFR3ZWVuZXIuYWRkVHdlZW4odGhpcywge3h7WyYqJl19OnRoaXNYLCB5OnRoaXNZLCB0aW1lOjAuNSwgdHJhbnNpdGlvbjpcImVhc2VPdXRTaW5lXCJ9KTsNCiAgICAgdGhpcy5hZGRFdmVudExpe1smKiZdfXN0ZW5lcihFdmVudC5FTlRFUl9GUkFNRSwgZXZlcnlGcmFtZSk7DQp9XCI7e1smKiZdfQ==[[/code]]

Now we’re done! The revised SnowFlake class becomes this:

[[code]]czoyNTkwOlwicGFja2FnZSB7DQoNCiAgICAgaW1wb3J0IGZsYXNoLmRpc3BsYXkuTW92aWVDbGlwOw0KICAgICBpbXBvcnQgZmxhc2h7WyYqJl19LmV2ZW50cy4qOw0KICAgICBpbXBvcnQgZmxhc2guZmlsdGVycy5CbHVyRmlsdGVyOw0KICAgICBpbXBvcnQgY2F1cmluYS50cmFuc3tbJiomXX1pdGlvbnMuVHdlZW5lcjsNCg0KICAgICBwdWJsaWMgY2xhc3MgU25vd0ZsYWtlIGV4dGVuZHMgTW92aWVDbGlwew0KDQogICAgICAge1smKiZdfSAgIHByaXZhdGUgdmFyIHNwZWVkTXVsdGlwbGllcjppbnQgPSA1Ow0KICAgICAgICAgIHByaXZhdGUgdmFyIHNwZWVkVmFyaU11bHR7WyYqJl19aXBsaWVyOmludCA9IDEwOw0KICAgICANCiAgICAgICAgICBwcml2YXRlIHZhciBzcGVlZDp1aW50ID0gTWF0aC5yYW5kb20oKSpzcHtbJiomXX1lZWRNdWx0aXBsaWVyOw0KICAgICAgICAgIHByaXZhdGUgdmFyIHNwZWVkVmFyaWF0aW9uID0gTWF0aC5yYW5kb20oKSpzcGVlZFZhe1smKiZdfXJpTXVsdGlwbGllcisxOw0KDQogICAgICAgICAgcHJpdmF0ZSB2YXIgdmlld1dpZHRoOmludCA9IDQ1MDsNCiAgICAgICAgICBwcml7WyYqJl19dmF0ZSB2YXIgdmlld0hlaWdodDppbnQgPSA0NTA7DQoNCiAgICAgICAgICBwcml2YXRlIHZhciB0aGlzWDpOdW1iZXIgPSAwOw0KIHtbJiomXX0gICAgICAgICBwcml2YXRlIHZhciB0aGlzWTpOdW1iZXIgPSAwOw0KDQogICAgICAgICAgcHJpdmF0ZSB2YXIgZHJpZnQ6aW50Ow0Ke1smKiZdfQ0KICAgICAgICAgIGZ1bmN0aW9uIFNub3dGbGFrZSgpew0KICAgICAgICAgICAgICAgc2V0U3BlZWQoc3BlZWQpOw0KICAgICAgICB7WyYqJl19ICAgICAgIHJlYWR5Rmxha2UoKTsNCiAgICAgICAgICAgICAgIG1vdmVNZSgpOw0KICAgICAgICAgIH0NCg0KICAgICAgICAgIHByaXtbJiomXX12YXRlIGZ1bmN0aW9uIHNldFNwZWVkKG46dWludCk6dm9pZHsNCiAgICAgICAgICAgICAgIHRoaXMuc3BlZWQgPSAobiAqIHNwZWVke1smKiZdfVZhcmlhdGlvbikrMTsNCiAgICAgICAgICB9DQoNCiAgICAgICAgICBwcml2YXRlIGZ1bmN0aW9uIHJlYWR5Rmxha2UoKTp2b2lkew17WyYqJl19CiAgICAgICAgICAgICAgIGdldERyaWZ0KCk7DQogICAgICAgICAgICAgICB0aGlzLnkgPSBNYXRoLnJhbmRvbSgpKnZpZXdIZWlnaHtbJiomXX10Ki0xOw0KICAgICAgICAgICAgICAgdGhpcy54ID0gTWF0aC5yYW5kb20oKSp2aWV3V2lkdGg7DQogICAgICAgICAgDQogICAgICAge1smKiZdfSAgICAgICAgdmFyIGJmOkJsdXJGaWx0ZXIgPSBuZXcgQmx1ckZpbHRlcihkcmlmdCoyLHNwZWVkLzIsMik7DQogICAgICAgICAgICB7WyYqJl19ICAgdGhpcy5maWx0ZXJzID0gW2JmXTsNCg0KICAgICAgICAgICAgICAgaWYoc3BlZWQvMiAmbHQ7IHNwZWVkVmFyaWF0aW9uKXsNCntbJiomXX0gICAgICAgICAgICAgICAgICAgIHRoaXMuc2NhbGVYID0gdGhpcy5zY2FsZVkgPSAuNTsNCiAgICAgICAgICAgICAgIH0NCg0KICAge1smKiZdfSAgICAgICB9DQoNCiAgICAgICAgICBwcml2YXRlIGZ1bmN0aW9uIGdldERyaWZ0KCk6dm9pZHsNCiAgICAgICAgICAgICAgIGRyaWZ7WyYqJl19dCA9IE1hdGgucmFuZG9tKCkqMzsNCiAgICAgICAgICAgICAgIHZhciBkcmlmdERpcmVjdGlvbjppbnQgPSBNYXRoLnJhbmRvbSgpKntbJiomXX0xMDsNCiAgICAgICAgICAgICAgIGlmKGRyaWZ0RGlyZWN0aW9uICZsdDsgNSl7DQogICAgICAgICAgICAgICAgICAgIGRyaWZ0ICo9e1smKiZdfSAtMTsNCiAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgIH0NCg0KICAgICAgICAgIHByaXZhdGUgZnVuY3Rpb24gbW92ZU1lKCl7WyYqJl19OnZvaWR7DQogICAgICAgICAgICAgICB0aGlzLmFkZEV2ZW50TGlzdGVuZXIoRXZlbnQuRU5URVJfRlJBTUUsZXZlcnlGcmFtZSk7DXtbJiomXX0KICAgICAgICAgIH0NCg0KICAgICAgICAgIHByaXZhdGUgZnVuY3Rpb24gZXZlcnlGcmFtZShlOkV2ZW50KTp2b2lkew0KICAgICAge1smKiZdfSAgICAgICAgIHRoaXMueSArPSBzcGVlZDsNCiAgICAgICAgICAgICAgIHRoaXMueCArPSBkcmlmdDsNCiAgICAgICAgICAgICAgIGl7WyYqJl19Zih0aGlzLnkgJmd0OyB2aWV3SGVpZ2h0IHx8IHRoaXMueCAmbHQ7IDAgfHwgdGhpcy54ICZndDsgdmlld1dpZHRoKXsNCiAgICAgIHtbJiomXX0gICAgICAgICAgICAgIHJlYWR5Rmxha2UoKTsNCiAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgIH0NCg0KICAgICAgICAgIHB1e1smKiZdfWJsaWMgZnVuY3Rpb24gZ290b01vdXNlKHhQb3M6TnVtYmVyLCB5UG9zOk51bWJlcik6dm9pZHsNCiAgICAgICAgICAgICAgIHRoaXN7WyYqJl19LnJlbW92ZUV2ZW50TGlzdGVuZXIoRXZlbnQuRU5URVJfRlJBTUUsIGV2ZXJ5RnJhbWUpOw0KICAgICAgICAgICAgICAgdGhpc1ggPXtbJiomXX0gdGhpcy54Ow0KICAgICAgICAgICAgICAgdGhpc1kgPSB0aGlzLnk7DQogICAgICAgICAgICAgICBUd2VlbmVyLmFkZFR3ZWVuKHRoe1smKiZdfWlzLCB7eDp4UG9zLCB5OnlQb3MsIHRpbWU6MC41LCB0cmFuc2l0aW9uOlwiZWFzZU91dFNpbmVcIn0pOw0KICAgICAgICAgIH0NCg0KIHtbJiomXX0gICAgICAgICBwdWJsaWMgZnVuY3Rpb24gcmVzdG9yZUZsYWtlcygpOnZvaWR7DQogICAgICAgICAgICAgICBUd2VlbmVyLmFkZFR3e1smKiZdfWVlbih0aGlzLCB7eDp0aGlzWCwgeTp0aGlzWSwgdGltZTowLjUsIHRyYW5zaXRpb246XCJlYXNlT3V0U2luZVwifSk7DQogICAgICAgIHtbJiomXX0gICAgICAgdGhpcy5hZGRFdmVudExpc3RlbmVyKEV2ZW50LkVOVEVSX0ZSQU1FLCBldmVyeUZyYW1lKTsNCiAgICAgICAgICB9DQoNe1smKiZdfQogICAgIH0NCg0KfQ0KXCI7e1smKiZdfQ==[[/code]]

[[code]]czo4Nzc6XCJ2YXIgZmxha2VBcnJheTpBcnJheSA9IG5ldyBBcnJheSgpOw0KdmFyIGlzU25vd2luZzpCb29sZWFuID0gdHJ1ZTsNCg17WyYqJl19CmZ1bmN0aW9uIGNyZWF0ZUZsYWtlcygpOnZvaWR7DQogICAgIHZhciBzRmxha2U6U25vd0ZsYWtlID0gbmV3IFNub3dGbGFrZSgpO3tbJiomXX0NCiAgICAgYWRkQ2hpbGRBdChzRmxha2UsMCk7DQogICAgIGZsYWtlQXJyYXkucHVzaChzRmxha2UpOw0KfQ0KDQp2YXIgbnVtRmxhe1smKiZdfWtlczppbnQgPSAxMDAwOw0KDQpmb3IodmFyIGk6aW50O2kNCiAgICAgY3JlYXRlRmxha2VzKCk7DQp9DQoNCmJ0bkNsaWNrLmFkZEV7WyYqJl19dmVudExpc3RlbmVyKE1vdXNlRXZlbnQuQ0xJQ0ssIHRvZ2dsZUZsYWtlcyk7DQoNCmZ1bmN0aW9uIHRvZ2dsZUZsYWtlcyhlOkV2ZXtbJiomXX1udCk6dm9pZCB7DQogICAgIGlmIChpc1Nub3dpbmcpIHsNCiAgICAgICAgICBzdG9wRmxha2VzKCk7DQogICAgICAgICAgaXNTbm93e1smKiZdfWluZyA9IGZhbHNlOw0KICAgICB9IGVsc2Ugew0KICAgICAgICAgIHN0YXJ0Rmxha2VzKCk7DQogICAgICAgICAgaXNTbm93aW5nID17WyYqJl19IHRydWU7DQogICAgIH0NCn0NCg0KZnVuY3Rpb24gc3RvcEZsYWtlcygpOnZvaWQgew0KICAgICB0cmFjZShcInN0b3BGbGFrZXMgY2x7WyYqJl19aWNrZWRcIik7DQogICAgIGZvciAodmFyIGk6aW50OyBpPG51bUZsYWtlczsgaSsrKSB7DQogICAgICAgICAgZmxha2VBcnJheVtpXS57WyYqJl19Z290b01vdXNlKG1vdXNlWCxtb3VzZVkpOw0KICAgICB9DQp9DQoNCmZ1bmN0aW9uIHN0YXJ0Rmxha2VzKCk6dm9pZCB7DQogICAgIHtbJiomXX10cmFjZShcInN0YXJ0Rmxha2VzIGNsaWNrZWRcIik7DQogICAgIGZvciAodmFyIGk6aW50OyBpPG51bUZsYWtlczsgaSsrKSB7DQogICB7WyYqJl19ICAgICAgIGZsYWtlQXJyYXlbaV0ucmVzdG9yZUZsYWtlcygpOw0KICAgICB9DQp9XCI7e1smKiZdfQ==[[/code]]

And you can download the source files here:
snowflake.zip

The short answer is: Not much. While it’s fantastic that Google is now able to read the text on Flash sites now, they face significant challenges in making sense of the text that they read. The reason is that Flash technology is much different from HTML pages in a couple of key areas:

• Markup: HTML has tags which mark bits of text and code on the site. Google uses a variety of these tags in order to make sense of the page (what’s a link, what’s a title, what’s an important bit of text). Flash has no such markup — the code you use to register a “click” can vary widely from programmer to programmer. While it’s true that this code is eventually compiled into a movie that the Flash Player plays, there are still significant challenges in being able to interpret the text that lies within a Flash movie.
• Standardization: Flash code varies dramatically from developer to developer. For example, Flash designates certain movie clips as “buttons” but many developers (including myself) never actually use technical “buttons” because other movie clips offer much more flexible ways of animating and handling user interaction. As a result, code and the structural elements that make up a Flash site vary widely. In contrast, HTML and the manner in which pages are displayed is very standardized — there’s only one way to indicate that you’ve got a link. Even if you use a dynamic language like PHP, the PHP will eventually spit out HTML that is widely standardized. Granted, AJAX and use of JavaScript can yield less standardized results, but for most HTML sites, the code is much more standardized than Flash. The end result is that HTML offers Google a much more standard framework for interpreting the meaning of pages than Flash does.

I’m sure that there are numerous other factors that go into it as well. As Google themselves point out, there are additional things which present problems for interpreting Flash content:

• Images (and video): Google points out that they are not able to index images that feature text or any video that features text. Nor do they mention way to tag images and/or video in order to make it even partially visible (like you could with the “alt” attribute in HTML).
• Potential problems with javascript: Google does not execute some types of JavaScript and therefore won’t be able to read some Flash files which are embedded via JavaScript. Since pretty much every developer worth his/her salt uses JavaScript to embed their Flash files, this could be a problem for sites.
• Externally-loaded content: Any content that is loaded by Flash (via XML or an additional SWF) will be considered a separate page. Depending on how your site is structured, this could present significant interpretation problems for Google.

The reality of the situation is that since Google is now indexing Flash sites, the content it gets back could be even more confusing for Google and could adversely affect your search engine ranking (see John Andrews’ blog entry on why you might want to block Flash from search engines).

In my opinion, all this boils down to the following strategy: watch and wait. No doubt standards for search engine optimization inside Flash will begin to emerge as Flash developers start experimenting with code and SEO, as Google continues to tweak algorithms on their end, and as Adobe keeps working on its Searchable SWF API. Until solid standards start emerging, Flash should still be treated as a system which requires additional work and solid strategies in order to be properly optimized for search engines.

The idea here is to have mouse movement which creates drips or paint splatters which then reveals text on the page. The challenge is that if you’re dropping bitmaps onto the stage with each mouse movement, the SWF very quickly becomes overfull of bitmaps and your CPU will slow to a crawl. So I used the Flash bitmapData.draw method to basically take a “snapshot” of the drip layer after 10 bitmaps have been added and then toss the bitmaps after the snapshot has been taken. That way the flash doesn’t have to keep track of a huge number of bitmaps and the SWF takes it very easy on the CPU.

You can download the source files here.