SWFObject, née FlashObject 1.4 released

New version is out! The new version is 1.4, and there are only a few small changes/additions:

Go get it!

Changes:

  1. [updated] SWFObject.write() now returns true or false depending on whether the SWF content was written to the page or not (true if it is, false if it is not)
  2. [changed] The ‘com’ namespace has been removed, now everything lives in the ‘deconcept’ namespace only, instead of ‘com.deconcept’ namespace
  3. [updated] I made a couple of very small changes to get rid of warnings in the mozilla script debugger when the debugger was in strict mode
  4. added ‘the mark of the web’ to the examples pages to (hopefully) prevent the ActiveX bar from appearing at the top of the page when viewing these files locally in IE on Windows.
  5. [changed] And last, but certainly not least: FlashObject is now known as SWFObject because of legal reasons

The namespace change is significant if you are directly accessing any of the internal functions inside SWFObject, like the getPlayerVersion() call. This should be easy enough to modify. I’ve also left in the reference to ‘FlashObject’ so if you want to upgrade, but don’t want to update your HTML pages just yet, you should be able to just drop in the new swfobject.js file, update the references to that script, and your SWF files will still show up.

As for the name change: Yes, it has been a pain in the ass, but not as painful as I thought it would be. So far the renaming of the functions / documentations has only consumed a few hours. Changing the mailing list from FlashObject to SWFObject was a bit trickier, and I’m considering just moving it to Google groups instead of the current mailman setup I’m using now.

As for the overall effect of the renaming, I’ve come to think that it may actually be a good thing for SWFObject once the dust settles. There was a small blog blitz about the subject, which caused a small spike in traffic to the blog, which will probably just end up informing more people about the script. Current users will have a few small changes when they want to upgrade to the newest version, but it’s nothing that will take a huge amount of time. And since I was in Toronto at FITC when it happened, I had the chance to hang out with a few Adobe people and discuss the issue with them. They all agreed that it wasn’t really a good thing, but that there’s no reasoning with that feral beast that is the Adobe Legal Team®™.

I do, however, have concerns for other open source projects out there with the word “Flash” in the name. For them, changing names may not be so easy.

As for an update on the entire “using the word Flash” situation, Adobe (I’m told) is working on a response to everything, so hopefully in the next couple of weeks we’ll get a more comprehensive official statement from them that will clarify any outstanding questions.

Download SWFObject now.

UPDATE: As always, you’ll probably get a faster response to your support questions if you join and mail the SWFObject mailing list instead of mailing me directly.

FlashObject Breeze presentation

I gave a presentation to the Minnesota Flash Users Group last night all about FlashObject and the benefits of using it. It went really well aside from my technical issues – When I first logged in, it worked fine, but after I adjusted my microphone, my browser crashed and then wouldn’t work at all after that. Firefox and Safari both would just hang when I tried to log in to the breeze room.

I ended up switching to my new Intel Mac Mini at the list minute and presented on that. But I guess Adobe hasn’t updated the Breeze screen sharing plugin to support the Intel macs yet, so I was stuck copy/pasting code into the whiteboard. I think it still turned out pretty well, so if you are new to FlashObject, this presentation might be a good overview of the advantages of using it.

You can view the presentation here. Enjoy! And thanks to the Minnesota User Group for asking me to present.

Today is ActiveX Black Tuesday

Today Microsoft will release their ‘Active Content’ patch for Internet Explorer 6. From a recent blog post on the MS Security Response Center:

The second issue is that we have a number of security vulnerabilities in IE that are scheduled to be addressed in our next release of security bulletins on Tuesday April 11, 2006. As you know, in order to reduce the complexity of updates and to improve quality, we ship all IE updates as cumulative updates. As a result, the April security updates will include the non-security ActiveX change to respond to the Eolas case.

If you’ve been following this at all since back in December, you’ll already know that you can use FlashObject to get around these changes and your users won’t need to ‘activate’ anything. But for those of you who are new to this issue, you can read an old blog post of mine that covers all the details and links out to all the important sites you might need to check out. It also covers a small bug in the update that I’m hoping has been fixed in this latest release (the script debugging issue).

Hope everyone enjoys the update!

A modern approach to Flash SEO

Search engine optimization is one of the most popular subjects when nerds sit around and talk about Flash. “Does Google index your swf files?” seems to be the most popular question, usually garnering plenty of ‘yes‘ and ‘no’ and ‘maybe’ answers. The real answer to this question, once and for all, is this:

It doesn’t matter.

To understand this answer, you need to understand what Flash is. And to do that, you need to understand modern web development philosophy. First off, you need to embrace web standards. Semantic markup and separating content from style and behavior is the only way you should be building your sites. Many web standardistas have been recommending this method of web development for years, and rightly so. However, this post isn’t the place to go into the whys of this type of development, so I’ll skip that part and just say this about how it’s done: There are three areas of front-end web development: Content, Style, and Behavior. You should always keep these three things separated as much as possible.

That brings up the question: “Where does Flash fit into this three pillar method of web development?” Is it content? Is it behavior? Is it style? While it could be considered all three, most professional Flash developers will remove the content from their Flash movies and load it in using Flash remoting or XML files. That leaves us with style and behavior.

Style is added using CSS. Generally when you add images to your HTML that are purely presentational (no text or required content in them) you should add them in using CSS. In most cases you don’t want Google to index them because people don’t search the web for ‘top left rounded corner gif.” They search for content. Even if Google upgrades their crawler someday to read CSS files and index the images, they probably wouldn’t use the information for more than statistical analysis because of this.

Behavior is generally added using Javascript. Maybe you want a new window to open set to a certain size, or you want to use some fancy Ajax to let users rate something without refreshing the page. This should all be added unobtrusively, and if the browser doesn’t support Javascript, it will hopefully still work. Unfortunately, not everyone considers this, and these days Javascript is becoming more and more of a requirement to use most websites. So you should always provide some sort of alternative for non-Javascript users. When it comes to indexing behavior, Google will for the most part not index your Javascript files. Even if it did, most web users would have no idea what the .js file they are looking at actually does. When using Javascript to change your document, Google will not read the ‘final’ page, but only the raw HTML file. Google does not render Javascript 1.

Now that you know all of this, it’s time to look at how to treat your Flash content. Since we’ve determined we don’t want Google to index our swf files, but we do want it to index the content displayed inside them, what is the best way to go about this?

As stated before, if you are building Flash sites professionally, you probably move all your content out of your Flash movie and into an XML file or keep it in a database. This makes it much easier to allow Google to index this content by using progressive enhancement.

Progressive enhancement is a method of web development that goes hand in hand with Web Standards. You start with your HTML (your content), then add CSS (your look and feel), then add in additional behavior (Javascript, Ajax, Flash, any other interactivity that isn’t handled automatically by the browser).

The best way to add Flash progressively is by using Javascript, or more specifically, a script like FlashObject. First you lay out your page as if you aren’t using Flash. If you are using a database for your content, you can spit out that data as HTML where the Flash movie will go on the page (or maybe just a preview of the content, it’s up to you to show Google the content you would like indexed). Then you use FlashObject to replace this content only if the user has Javascript enabled and the required Flash plugin version.

Here’s a small example of what that might look like:

<div id="flashcontent">
    This is replaced by the Flash content if the user has the correct version of the Flash plugin installed.
    Place your HTML content in here and Google will index it just as it would normal HTML content (because it is HTML content!)
    Use HTML, embed images, anything you would normally place on an HTML page is fine.
</div>
<script type="text/javascript">
    // <![CDATA[
    var fo = new FlashObject("flashmovie.swf", "flashmovie", "300", "300", "8", "#FF6600");
    fo.write("flashcontent");
    // ]]>
</script>

This causes Google to skip the Flash swf files and only index the HTML (the content!) you place on the page. You can place links to other pages, images, whatever you want Google to index, and when a viewer with a browser that supports Flash visits your site, they will then see the Flash content. This gives you full control and much greater predictability over what content Google will index. And if your content is pulled from a database that is editor controlled, your pages will update and be re-indexed as the content changes without the need to re-publish all your swf files.

1 Currently Google does not render the Javascript on a page, but there are rumors that they are developing a new crawler based on Firefox (they employ a number of Mozilla foundation members) that will index pages based on how the browser sees them, instead of the raw HTML content. This means HTML hidden by CSS may not be indexed, and pages that are altered by Javascript after they load will be indexed how they appear to the user. However, this is all rumors and until it happens Google will ignore your Javascript content.

Note: In this article I use the ‘Google’ name often, but it can be interchanged with any search engine, as they all work roughly the same way.

Using alternate content as content in Flash

I’ve been going on and on about using progressive enhancement on your pages that use Flash ever since I released FlashObject. The idea is that you build your pages without Flash, then add in the Flash parts later using Javascript if the user has the correct version of the Flash player. One of the really cool side effects of doing this is that Google will then index your alternate content (Google doesn’t know Javascript).

Today I saw somone taking this a bit further: They were using sIFR to embed a Flash movie on the page, and then passing in the replaced HTML content into the Flash movie as a flashvar.

Now this is nothing new – Claus Wahlers created SEFFS a while back that does just this (I think in his example he loaded the entire XHTML document), and sIFR does this but on a very small scale.

Up until today I never really saw much of a benefit to doing something like this. Usually your site would be run from a database anyway, so you could output your navigation and page content from your database as alternate content, and then use that same data again for the XML file that your Flash movies would read. But today I think I finally realized how cool this might be: Imagine removing all the server calls from your Flash movies when they request their XML configuration files, or imagine saving the user’s bandwidth by not loading all that content twice.

So I came up with a proof of concept of this technique using FlashObject:

How it works

First, embed your Flash movie just as you normally would using FlashObject. Then, to pass the data into you Flash movie, you just need to add one line of code. The whole thing looks like this:

var fo = new FlashObject("passdata.swf", "passdata", "300", "300", "8", "#ffffff");
fo.addVariable("xmlData", encodeURIComponent(document.getElementById("flashcontent").innerHTML));
fo.write("flashcontent");

You can see that I’m simply taking the same element that I target with FlashObject, grabbing the innerHTML of that element, URL encoding it* and then passing it into Flash as the variable xmlData.

Once the data is in the Flash movie – It’s available on the first frame as _root.xmlData, we take that string, and create an XML object out of it. That code is very simple, and looks like this:

var xml = new XML();
xml.ignoreWhite = true;
xml.parseXML(unescape(_root.xmlData));

That’s it! You now have a nice and tidy XML object you can use to generate your Flash content, and it will always match your alternate content perfectly. Your users don’t have to download the content twice (once in the HTML, once in the XML file Flash would load, or duplicated in the swf) and you saved your server an extra call from the Flash movie.

View a working example here, and you can download all the files in the example here.

* Using encodeURIComponent to support double byte characters.