Now that we know the major issues with using Flash for a "website" from Part 1, we can get to the good part. If we MUST use Flash then here are some things in no particular order my team and I have found to help.

1.) The "back" button doesn't work

Beating this one involves making the browser think we went to a new page even though we didn't. People often forget about "anchor"tags. The perfect example of how to change what's in the URL of the browser without actually refreshing the page. The reason the browser doesn't refresh is that anchor tags were originally used to scroll the page down to the corresponding content, without a refresh of the page.

Say we start at the home page, I'll use a site we made as an example:

As you can see it's actually impossible to get a pure URL, the /#home is added by our framework. If you then click to any other part of the site you can see the result as such:

Now, by clicking the "back" button it should take us back to http://www.nicolebyopi.com/#home and as far as the browser is concerned we haven't really left the page, we're just going to a new anchor.

We trap this event of the anchor changing using Flash's "external interface" (javascript tie-in) object. When our framework gets this event, we just look at where we're going and deal with it appropriately.

2.) Your users can't link to specific content on your site

To me this is HUGE, without the ability to send a user to a specific part or page of a website you are losing way too much expected usability. By implementing the above mentioned "state" or "history" concepts, we should now have unique URLs (anchors) for every page in the site people could want to link to. I'll use our own site as an example here. If I want to send you to a specific Flash game we created I can just like you to http://www.catalyststudios.com/#/portfolio/80-games/242-gamestrashblasters/

As you can see, the site is going to figure out what page you want by looking at the "anchor" after the # in the URL. It was also our prerogative to make that URL somewhat readable as well. For the sake of having shorter URLs you can always just do something like http://www.website.com/#/2/4/340 and as long as your framework knows what to get you're fine. We just liked the idea of people knowing what they might be getting into prior to clicking, or being able to tell one link from another.

3.) You can't track your visitors

When you tie into Flash's "external interface" object you will have the ability to make javascript calls on page level function. The nice thing here is that if you are both tracking state (history) of your site and updating the URL it should be a simple task to then send out that new anchor URL to a analytics system. In our case we send out to Google Analytics, this allows us to see right down to which Nail Polish gets clicked the most.



Google Analytics allows you to filter out first part of your URL http://mysite/com/#/ to help you see just what the pages being visited are.

3.) Search engines don't see your content

Out of the box, Flash only helps you index text you use in your Flash movies. If your site is driven by databases and XML this will likely not help you. For now, we are having the best luck just creating redundant HTML in pages that represent the site tree. Embedded in each page is the proper indexable content in a DIV that gets replaced by the Flash movie. To see this in action you could download the Developers Toolbar for Firefox and turn off all javascript (used to load Flash) and see that the site is navigable even without Flash. Obviously this is what a search bot sees, they don't have Flash either (yet).

Lastly it's worth pointing out that although a site framework can be handy for dealing with URL changes, and sending out Analytics calls, a core tool in the mix we have found helpful is a wonderful gadget called SWFObject and along with that SWFAddress for the external interface tie-in.