A History of Flash Detection Methods

Now, I’d like to give you a brief history of some of the methods developers have used to perform Flash detection to date.

Flash Satay

The side-effect, however, is that it allows for the display of alternate content in the event Flash Player is not found, so it qualifies as a method of Flash detection. The idea is that, using valid XHTML, a browser with no Flash Player installed runs across an <object> tag trying to create a Flash object, realizes it can’t do so, and simply skips to the next node, which can be a text node or an <img> tag specifying alternate content. In short, if the browser can’t create the object it needs, it displays the content in the next child node.

One issue with this solution is that it doesn’t account for older plug-in versions. If the browser recognizes the object type, which it will if any version of Flash Player exists in the browser, it will create the Flash object. If your content uses Flash Player 7–specific features, and the user has Flash Player 6, she may see nothing but a white box on the HTML page.

This method also has the disadvantage of not streaming the SWF file when using Microsoft Internet Explorer. For large SWF files this can be reason enough not to use this method. Flash Satay is great for small movies, but once your content exceeds 100K you should look into alternative detection methods. They might not validate as standards-compliant XHTML, but they will provide a much better user experience, and that is what really counts in the end.

The Redirect Method

Implemented in the Flash MX 2004 HTML templates and used as part of the old version of the Macromedia Flash Detection Kit, the redirect method involves running Flash detection on one page and redirecting the user to one of two other pages based on the result of the test. If the plug-in is installed and is the right version, the user lands on the page with the Flash content. If not, he or she lands on a page featuring alternate content. By default, this approach uses three HTML files and two SWF files (one is used as part of the detection process, and the other is for your content).

Using the approach is not only messy (requiring five files for one piece of content), but it also puts the user into a Back button loop. Clicking the Back button sends the user back to the detection script, which promptly returns him to a content page, rendering the Back button useless.

The No-Detection Approach

This is really a non-approach. By using no Flash detection whatsoever, developers simply assume that every person visiting a site either already has the Flash plug-in installed, or the browser will attempt to handle the installation for the user. (Many modern browsers have a built-in prompt for starting the installation process, but not all of them.) And while this works fine in many cases, the browser prompt is a little scary. If you choose to install the plug-in, some browsers show you a dialog box titled “Security Warning.”

Do you really want to put that in front of your users?

The “Other” Approaches

Several common detection approaches were not even tested for the purposes of this article, but there’s good reason for excluding each. Server-side detection, for example, is dependent on the server technology being used. Since this can change from project to project, it’s not the ideal solution. And although Flash Player can handle version detection itself with a little bit of ActionScript, an inherent flaw with this approach, as you may realize, is that it can’t possibly work if some version of Flash Player is not already installed. Users with no plug-in are left out in the cold.

Finally, the Moock FPI (created by renowned Flash developer Colin Moock and used often by developers) is no longer even recommended by Moock himself. It also failed on at least one major Mac browser, so it didn’t make the cut. Colin now recommends the Flash Player Detection Kit as a replacement for his previous solution. As an alternative to detection, Moock recommends offering two entry points to your site, one for the HTML version and one for the Flash version. Of course, you’d have to do this for every major piece of Flash content on your site (and have an HTML version of it), and all along the way, you’d be assuming users know the difference between HTML and Flash. In many cases, they don’t.

So what’s a geek to do? If no solution is perfect, what can you do to create a good experience and ensure the visitor doesn’t leave your site at the first sign of trouble?