The problem has riddled developers since the birth of Macromedia Flash: What happens when a site visitor doesn't have the version of Macromedia Flash Player needed for my content, or doesn't have one at all? Many answers have appeared over the years. And so far, the work has not been the result of developers trying to reinvent the wheel. Instead, it's been the result of developers trying to invent a wheel that actually works.

Can Flash detection be truly effective? Can it be seamless for site visitors and simple for you to implement? Can it make the player upgrade process friendlier?

In this article, I'll discuss the pros and cons of several approaches to Flash detection (and include a Flash Detection Experience Matrix). I also describe the new Flash 8 detection script, which, along with Flash Player Express Install, just might be the answer we've all been waiting for.

A Brief History of Why We Need Flash Detection
With new versions of Macromedia Flash Player appearing on the web roughly every 18 months for the last several years, the task of ensuring your site visitors' player versions are compatible with your content can be downright frustrating. On the flip side, nothing is a bigger turn-off than landing on a web page that points a finger at you and says, "Macromedia Flash Player is required to view the content on this page," leaving you without a way to continue your experience without upgrading your player. After all, it's the developer's job to make sure you can do what you want to do on his or her site. It's the developer's job to determine which version of Macromedia Flash Player is installed in your browser and to react accordingly.

User experience, as we all (should) know (by now), is vital to the success of a website or web application. Bad experiences are the equivalent of walking into a clothing store, asking a salesperson to see that fancy shirt hanging on the wall, and being told, flatly, "No." And telling me my system is somehow incompatible with your allegedly amazing website is like following up this experience by telling me to leave the store. Take a good look at the Flash detection experience implemented on your own website and try to see it the way your grandmother might see it. Does she have the plug-in she needs? If not, what does she see, if anything at all? What happens if she chooses not to upgrade? If she does upgrade, will she be able to quickly return to your page?

If you use Flash on your website, your only real option is to make sure you have an answer for all of the preceding questions, and implement a detection method that handles each situation.

So far, that's been much easier said than done.

So Many Solutions, So Little Success
Over the years, I've met hundreds of Flash developers, and many of them have their own way of handling Flash detection, but several approaches have risen to the top of the stack to become at least somewhat standard. These approaches vary wildly in features, compatibility, effectiveness, and user experience, but one thing stands true regardless: none of them works 100% of the time.

To make an informed decision about which approach is best for you and your site visitors, you need to know the facts. Lucky for you, I've done a lot of the legwork already and whipped up a fancy Flash Detection Experience Matrix for you, along with an overview of each of the tested approaches, and an introduction to the newest Flash detection script. Before you move on, however, it's important to understand what is needed to design a good Flash detection experience, for the simple act of displaying Flash content on your site presents several very key issues:

• Does the user have Macromedia Flash Player?
• If needed, does the user have JavaScript enabled?
• Does the user have the required version of Flash Player?

Detecting the Existence of Macromedia Flash Player
To create a good detection experience, you need first to be able to specify what happens when Flash Player is not installed on the user's browser. If you offer no alternate content, is the user going to sit there staring at a blank screen, hoping that his or her web-savvy neighbor will come along and save the day? Most likely, the answer is no. Instead, your visitor will head off to your competitor's site, cursing your name the whole time. See, not every person that visits your site is going to want to perform a software installation just to view your content, regardless of how simple it is. So you need to offer your site visitor a compelling reason to perform the installation. In other words, you need to tell your users what they will see or gain by installing the player, and make sure it's something that benefits them directly. If your Flash detection method is dependent on the use of JavaScript, you also need to plan what happens if the user has disabled the use of JavaScript in his or her browser. Ideally, you should be able to display alternate content, either asking the user (very nicely) to enable JavaScript and refresh the page, or offering HTML content in lieu of the Flash content.

Detecting the Required Flash Player Version
Next, you must handle old versions of Flash Player. If your content is designed for Flash Player 8, for example, and your site visitor has Flash Player 6 installed, he or she should see alternate content. Again, the alternate content can either ask very nicely for the visitor to upgrade or offer HTML content in place of Flash content.

Finally, you probably want the solution to be easy to implement, and so effective that you don't have to think about it ever again.

Now that you have a list of required elements for a good Flash detection experience, let's take a quick look at some common options currently in existence.

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
Introduced in an article on A List Apart, Flash Satay was intended as a standards-compliant way to embed SWF files into HTML pages. 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.

• Add playlist to flash player with custom settings via Moyea PlayerBox