Best Practices for Flash Player Detection

Additional Requirements

Flash Basic 8

• Buy

or Flash Professional 8

• Try
• Buy

Flash Player Detection Kit

• Download the Flash Player Detection Kit

Note: The Flash Player Detection Kit has been updated to address changes that Microsoft has made in the Internet Explorer browser regarding the use of embedded ("active") content on websites, such as Macromedia Flash Player. For more information, please visit the Active Content Developer Center.

These files can be used as reference material for each type of Flash detection discussed in this article.

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.

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 work 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.

Detecting Whether JavaScript Is Enabled

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.

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.

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?

Well, folks, today is a good day: The search is over. The wheel has been invented. And tested. And taken on a nice, long road trip.

Say hello to the newest detection script, which you can implement easily using Macromedia Flash 8. Much like the Six Million Dollar Man, it's better, faster, and stronger. And as an added bonus, you can actually rely on it.

Included as an HTML template option in Flash 8, this new detection script solution is implemented by setting your Publish Settings to publish an HTML page for your SWF file, and activating the Detect Flash Version check box prior to publishing. After you've published your files, the resulting HTML file contains all the code necessary to run effective detection, display alternate content to people with older versions of Macromedia Flash Player installed, and show different alternate content to those with JavaScript disabled.

In Macromedia Flash MX 2004, the solution was purely ActionScript-based and did not meet the needs of developers who wanted more fine-grained control over the user experience. The required browser redirect caused user confusion and in the end did not meet all the needs of the developer community.

What is provided in Flash 8 is a huge improvement in that it takes the best ideas from scripts that have been in use for years and provides a solution that gets developers up and running quickly. Want to hear the best part? I personally tested the new script in several different browsers (the newest versions of Internet Explorer, Firefox, Netscape, Opera, and Safari) on Windows and Macintosh operating systems. Each method was tested with no plug-in installed, with an old version installed, and with JavaScript disabled. The new Flash 8 script is the only detection approach that performs correctly in every single case.

Check out the Flash Detection Experience Matrix:

• Launch printable document (PDF, 16K)

You have to do a little bit of work to implement the Flash 8 detection script, as the detection template is not meant as the final version of a web page. However, it's not complicated, and doing so will help ensure you can keep all of your site visitors happy. To make the code in the default HTML template useful in a real page, you need to do some copying and pasting, possibly modify the version number to detect, then go through the code and set what you'd like to display as alternate content when an old version of Flash Player (or no player at all) is found, or JavaScript is disabled. The detection script has generic, default alternate content specified already, but you should really customize this to your (users') needs.

Here's a synopsis of the implementation process:

1. After you've exported HTML with Flash detection from Flash 8, move the JavaScript code found within the template's <head> tag to the same location in your page along with the JavaScript include, AC_OETags.js.
2. In the Globals section of the JavaScript code, set the version number of the Flash version you'd like to detect.
3. Replace the value of the alternateContent variable in the second JavaScript snippet with HTML for your own, custom content.
4. Replace the HTML code found within the NOSCRIPT tag with appropriate alternate content.

As alternate content, consider what's actually needed for the user to continue his or her experience seamlessly. If the Flash content is nothing more than an ad banner, specify a GIF or JPEG image as alternate content and leave it at that. If the Flash content is required, consider using a teaser image (such as a screen shot of what the user would be seeing if the correct player was installed) in conjunction with asking the user nicely to upgrade and offering a link to the installer page. This way, you offer a compelling reason for the user to perform the installation.

If the user has JavaScript disabled (this is true in 10% of web browsers, on average), he or she will see the content specified by the NOSCRIPT tag in your page. This could be a teaser image or plain text as well.

Most important is that what you show is helpful to the user experience. If the Flash content is not required, don't force (or even request) the upgrade. If it is required, offer a good reason to upgrade. If JavaScript is disabled, offer a good reason to enable it and refresh the page, or show appropriate alternate content (such as a GIF or JPEG image).

Using the detection script discussed earlier, you will now be able to make sure that users have the correct player to view your content. If users do not have a version of Flash Player adequate to view your content, or they have browser scripting disabled, you will now have much greater control over the experience of upgrading users to the latest player.
 
In the past the installation of the player differed between browsers and platforms, but now Macromedia has made a seamless process for developers to upgrade users. This new method is called Flash Player Express Install. Express Install is available for users who already have Flash Player 6.0r65 and above. This new installation process prompts users to upgrade to Flash Player 8 if they do not have it already and, when installation is complete, returns the user back to the page that started the process. If you really want your users to see the latest Flash 8 features in your Flash content, this is a great new way to upgrade them without a lot of pain.

Macromedia has enabled the new Flash Player Express Install mechanism with the release of Flash Player 8. This mechanism means that by sticking another small bit of HTML into your page, you can use the player itself to prompt the user to upgrade (see Figure 1) and automatically return the user to your page upon successful completion of the installation. If the user chooses not to upgrade through the inline prompt, an event is fired that you can use to display alternate content. If you want to implement Flash Player Express Install, the full details and sample files are contained in the Flash Player Detection Kit.

So how can you implement the perfect Flash detection experience? Here's a quick synopsis, which combines the Flash 8 detection script and Flash Player Express Install.

1. In your HTML page, detect the player version required for your page by implementing Flash 8 detection script, as described previously.
2. Implement Flash Player Express Install, using the Flash Player Detection Kit and the tutorial in the next section.

   If version 6.0r65 or higher is found, but the player version is still not high enough for your content, the Flash Player Express Install will prompt the user to upgrade. If the user upgrades, the plug-in installs, the browser restarts, and the user is returned to your page automatically.

3. If the user chooses not to upgrade, capture the event (with a bit of ActionScript, detailed in the next section), and either display alternate Flash content, redirect the user to another page (through a getURL() call), or perform an inline replacement of your Flash content through JavaScript. Either way, the user's experience continues seamlessly, and you earn yourself another happy customer.

For instructions on how to see each of the approaches described above in action, refer to the Readme.txt file included with the sample files you downloaded at the beginning of this article. Several versions of the same HTML page are included in the download, each of which uses a different Flash detection approach. To see the Flash 8 script solution in action on a real website, visit www.rhjr.net/eReader (used for the sample page in the Captivate demo), which also includes examples of the new Flash Player 8 text rendering and drop shadow filters included with the Flash 8 authoring tool.

Finally, tell every web developer you know about this article. The sooner Flash Player Express Install becomes standard, the sooner we can stop frustrating users and start handling Flash experiences in an effective manner and improving user experiences on the web.

The following tutorial describes how to implement the Flash Player Express Install mechanism.

Note: Because users who have not installed the Flash 8 plug-in cannot see Flash 8 content, another SWF is used in place of your actual Flash content to handle the upgrade process. This SWF is named playerProductInstall.swf and is published for Flash plug-in version 6r65. Following these steps, you'll see how to modify the source file for this SWF and provide alternate content if the upgrade fails or is cancelled.

This tutorial assumes that you have already added the Flash 8 detection scripts to a web page (as explained in the synopsis of the implementation process) and have already downloaded the Flash Player Detection Kit:

1. Extract the Flash Player Detection Kit files from the ZIP file you downloaded and locate the "Express Installation" directory.
2. Copy the following files from "Express Installation" into a new folder on your hard drive: playerProductInstall.fla, playerProductInstall.html, playerProductInstall.as, and playerProductInstallCallback.as.
3. Open playerProductInstall.fla in the Flash authoring tool. This file creates the SWF that users see if they do not have Flash Player 8 but do have Flash Player 6r65 or higher. Change the dimensions and background color to something that works with your web page. Generally, it's best to use the same dimensions as your own Flash content so that page rendering isn't affected as a result of displaying playerProductInstall.swf.

   Note: The dimensions of playerProductInstall.swf must be at least 215 x 138 pixels, which is the minimum space required to display the Express Install prompt properly. Use the AutoUpdater symbol instance on the Stage as a guide.

4. In playerProductInstall.fla, delete the instructions text from the Stage. If you like, change the color of the AutoUpdater symbol—for example, to blend in with the background color.
5. Open playerProductInstallCallback.as. This file determines what the users see if the upgrade fails or is cancelled. The code in this ActionScript file looks like this:

6. Replace the comments within each part of the if/else statement with your ActionScript that determines what happens in each event. For example, if statusvalue (the variable that is tested in each part of the statement) is equal to Download.Cancelled, you might use a getURL() call to send the user to a different page on your site.

   Take a look at my eReader application (www.rhjr.net/eReader) to see some examples of how this is used (of course, you'll have to uninstall your copy of Flash Player and install an older version first, then be sure to cancel the upgrade when the Flash plug-in prompt displays).

   Save your work when you're done.

7. Republish playerProductInstall.fla to create your newer version of playerProductInstall.swf. Save playerProductInstall.fla, close both files, and then move playerProductInstall.swf into the same directory as your web page.
8. Open playerProductInstall.html in a text editor (such as Macromedia Dreamweaver 8) and locate the JavaScript within the BODY element of the page.

   This script is similar to the one you added to your own web page earlier, but it also checks to see whether the user's machine has Flash Player version 6r65 or higher installed. If so, it displays playerProductInstall.swf in place of your Flash content.

   Copy the entire script (excluding the NOSCRIPT element, which does not need to change). In a moment, you'll paste this script into your own page.

9. Open your own web page in a text editor (for the sake of the tutorial, we'll call it index.html). Highlight the script in the BODY element of index.html and paste the script you copied from playerProductInstall.html in its place.

   This script runs if the correct Flash plug-in version is found, so replace the highlighted values with the dimensions and name of the Flash movie you'd like to display.

10. Open index.html in a web browser and test it out. You'll need to uninstall Flash Player and install an older version to test it accurately.

If you followed the preceding steps, index.html should now show you the Express Install upgrade prompt when you come to the page using an older version of Flash Player.

Where to Go from Here

To learn how to leverage Flash Player Express Install, refer to the Flash Player Detection Kit. It also describes the other detection strategies mentioned in this article in more detail, including server-side and script-less approaches. You can see first-hand how the Flash 8 detection script works by creating a new Flash document in Flash 8, opening the Publish Settings, selecting the HTML tab, and selecting the Detect Flash Version check box. Click the Publish button and open the resulting HTML file in your favorite editor (such as Dreamweaver 8).

For a detailed description of the scripts used in the Flash 8 authoring tool, see Future-Proofing Flash Player Detection Scripts by Flash software engineer Michael Williams, the guru at Macromedia behind the Flash 8 detection script. Special thanks go to Michael for his incredible diligence in solving the continuing problem of effective Flash detection. He was a man on a mission, and users everywhere will benefit from his expertise.