Flash Player Detection Techniques Unearthed

Which Version Do I Target?

The release of each new Flash Player typically offers attributes that aren't found in previous versions (see the Flash Player 7 link at the end of this article). Features such as dynamic loading of Jpegs, the XML object, LoadVars and movie clip event handlers are just some of these.

Which version of the Flash Payer you should target will depend on your target audience. If your audience is Flash developers, it's most likely they will have the very latest (or near to that) Player installed. On the flip side, the general public tends to be wary of downloading plugins and ActiveX controls -- they tend to lag behind by a version. In this case, it might be good to use Flash Player 5 ActionScript to ensure maximum playability, with a view to upgrading as your user base grows more accepting of the technology.

I generally don't develop for version 4 or less, as at Flash Player 5 the transition to dot syntax took place and ActionScript grew immensely. Designers, though, may want to deploy for Flash Player 4 if they're using simple motion tweens and very basic ActionScript. Bear in mind, though, that doing this will only increase the impact of your movie by a few percent.

At the time of writing, Flash Player 5 is by far the best version to target in order to reach the widest possible audience -- although Flash Player 6 is growing at a considerable rate.

Handling the Flash Player Download

For the average Website visitor, being prompted to download and install anything on their machine so they can view content can be a hair-raising affair. Many site visitors are extremely wary of installing anything on their machine that they think could cause harm to it, and wisely so.

It's our job then to make the download and install a seamless, friendly process. What we want to avoid are any ActiveX pop-up windows or automatic redirections to Macromedia's Flash Player download page. User experience tells us that these can turn visitors away in droves.

An ActiveX warning: scary, isn't it?

The Opera7 version -- less intimidating, but still pretty uninformative for the non-Web savvy user (that ‘click' button is the Flash movie).

What we want to achieve is a more sensible method of ensuring download of the Player if it is required -- one that matches our site design and leaves the user in complete control of the download process.

The first thing to do is employ some standards-compliant markup -- which you'll see in use throughout the code in this article. The advantage of writing markup like this is that it allows us to deploy a consistent download experience to all compliant browsers.

Here's what we need to do:

• Remove the Netscape specific Embed tags -- Mozilla , Safari, IE5+Mac and Opera7 will still run your movie just fine with a few tweaks.
• Change the codebase tag from the default Internet Explorer specific attribute to the W3C recommended attribute.
• Place alternate, descriptive content within the object tags, after the optional param tags -- as specified by the W3c recommendation.

Note that, for users of Internet Explorer on Windows who have no Flash Player, changing the codebase attribute like this will cause their browser to do one of three things (depending on the user's ActiveX security settings for “unsigned" controls):

• Prompt: A pop-up window will appear with selections of Yes, No, and More Info.
• Enable: The browser will attempt to render the Flash object, fail, then display the alternate content as noted above.
• Disable: The browser will fire a warning saying it can't render the object due to security settings, then render the alternate content within the object tags.

These responses are occur as a result of the way IE for Windows supports the object tag, not the W3C recommendation, and it should be noted that in all cases alternate content would be displayed.

If you don't want this to happen, I suggest you leave the codebase attribute as default -- you will need to reference your movie absolutely in both the data attribute and the movie <param> tag when doing this, so that all browsers can find it.

On the flipside, now that the embed tag has been removed from the equation, Mozilla, Opera7 and other compliant browsers will render the alternate content within the object tags if they can't run the designated file. No annoying jigsaw pieces or popup windows will appear for these browsers -- just your specified alternate content.

So there we have it -- a reasonably robust way to maintain control over the Flash Player download process -- in a transparent fashion. Moving forward, we can employ this code in all the detection scenarios to be discussed, starting with the “Manyana" method.

Do Nothing – The ‘Manyana' Method

This, the Cosmo Kramer of detection methods, is a reflection of the impact that Flash Player has in the market -- it's such a prevalent third party plugin that, when used correctly, this method will have a good success rate. Current statistics put the population of Web browsers capable of handling Flash Player 5 content (the best player to target for general sites) at about 96%. At the time of writing, Flash Player 6 has an audience of about 80% and growing.

This method is the simplest to employ of all those described here. Use the Publish Settings (File>Publish Settings…) in Macromedia Flash to generate the required markup, then make any changes to the (X)HTML -- your title tags, head tags, and CSS file linkages, for instance. All that's required now is to put the files on the Web server.

You can also employ Flash publishing templates tailored to your project, as discussed in the Online Flash Help files.

That's the biggest advantage -- ease of implementation.

Major disadvantages include that there are no control methods in place to assist a site visitor when something inevitably goes wrong, and the fact that we're assuming that most site visitors will be using Flash Player 5 and above. Things can go wrong if you serve Flash Player 6 content, for instance, to Flash Player 3, and there's no support structure in place for the user. It's good programming practice to ensure that we have appropriate fallback methods when something does go wrong, which means this is not the best method to implement for a general audience.

Code example

Below is the markup described in the section “Handling the Flash Player download". The browser will attempt to run the file, or display the alternate content if it can't.

Note that there is no version detection inherent in this method.

<object  
  data="manyana.swf"  
  type="application/x-shockwave-flash"  
  codebase="http://www.example.com/"  
  width="550"  
  height="400">  
        <param name="movie" value="manyana.swf" />  
        <param name="menu" value="false" />  
        <param name="quality" value="high" />  
        <param name="bgcolor" value="#ededed" />  
 
        <p>  
          Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.  
          <br />  
          This text will be rendered if the user-agent cannot render the file specified in the object tag.  
        </p>  
 
  </object>

When should this method be employed?

When you know accurately what Flash Player version is installed on your users' computers. Examples include:

• Intranets with standardised settings.
• Sites for active Flash developers, who will generally have Flash Player 5 or later installed.
• When you are employing simple animations that are Flash Player 2 compatible.

When should this method be avoided?

• When you are building a site for an anonymous audience with unknown Flash Player versions -- basically anything on the Web for the general public.
• When you are serving version-specific Flash content.

Of course, you can use this markup just as well when employing client side scripting detection…