w3blog

Macromedia’s Flash Player is a remarkable piece of software. It is widely deployed, features a full ECMAScript implementation, an XML parser, audio and video capabilities and an advanced vector rendering engine, and many more. If used appropriately, it can provide visitors of your website with a better, richer and unique browsing experience.

However, there are chances that visitors of your Flash enabled website can’t or don’t want to see Flash content (SWF).

They can’t

As i mentioned above, the Flash Player is widely deployed. According to surveys commissioned by Macromedia, 98.2% of the WWW users are capable of viewing SWF Version 2 today, and around 85% can view the latest SWF Version 7 . Even though this seems impressive (it certainly is), it means that if you publish SWF Version 7 content, 15% of your website’s visitors won’t be able to see it. We also have to take into account that those numbers are a result of a statistical survey and do always vary depending on your website’s audience (Slashdot’s statistics are most likely to show way lower numbers whereas websites targeting Flash developers probably experience a higher percentage), so there are chances that even fewer people are able to see what you have to offer. Furthermore, statistics always have to be questioned. Is the survey really representative? Did it include people with disabilities? People browsing with mobile phones, PDAs or similar devices? Search engine spiders? We can’t be sure. Macromedia says: “2,000 participants, comprising a representative Internet sample responded to this survey. The study was evaluated at a 95% significance confidence level, (5% risk). The same survey was also conducted with various International samples, including Canada, Europe, Asia, Japan, and South America (not a representative Internet sample - English speaking respondents only)“. I’ll leave it up to you to believe if those 2,000 participants (around 0.0004% of today’s WWW users) are a representative sample.

They don’t want to

No matter how much effort you put into your Flash site, visitors that are both physically and technically able to view SWF may still prefer not to see it. They may prefer a simple text-only rendering of your website, because they are browsing with a PDA or a mobile phone on the road. Maybe they just are not comfortable with your Flash design. There are numerous reasons.

Special guests

A significant percentage of your website’s visitors is not human, but important nonetheless. All sorts of programs are visiting your website, search engine spiders being the most frequent ones. Although some of those spiders are able to index your binary SWF content, results often are not satisfying. State-of-the-art Flash sites usually pull their content dynamically, making it difficult and most of the time impossible for search engine spiders to get to it, resulting in only a insignificant fraction of your site’s content being indexed - and less human visitors for your site.

Conclusion

The number of visitors (human as well as non-human) not being able to, having difficulties to or not willing to see your Flash site is bigger than you might think.

Deploy SWF

Although Flash developers often put lots of effort in their Flash sites, a critical part is often neglected: The way the Flash content is deployed. Usually, a SWF requires a HTML container document with <object> and <embed> tags to be deployed. Developers using the Flash IDE to develop their sites are given the default option to let the IDE create such a container automatically. Templates that ship with the IDE are available for different deployment scenarios, including basic Flash Plugin detection. There are also many third party solutions available.

Some Flash deployment methods (including the one offered by Macromedia) use a dummy SWF embedded in your site’s index HTML, that includes code to redirect visitors to different subpages depending on the version of the installed Flash Player. Visitors not capable of viewing SWF content get an empty page and are redirected to an alternative HTML page via <meta> refresh after a short delay. For users of Internet Explorer without Flash Player, the ActiveX version of the plugin is transparently downloaded.

Other methods use JavaScript to check if the Flash Player is installed. Visitors not capable of viewing SWF content either get redirected to an alternative HTML page via location.href or alternative content is displayed via <noscript> tag.

All of the above methods are problematic. You have to provide alternative content for visitors who can’t view SWF. Way too often this is just a note that the Flash Player is required to view the site’s content along with a link to the Flash Player Download page, or, worse, just a screenshot of the things you would have seen. Budgets are small, deadlines tight, developers lazy. Visitors are left in the dark, can’t find the information they are searching for, or getting annoyed by potentially undesirable Flash content/sound, ActiveX authentification dialogs and long plugin downloads where they may expect to get simple text content. Search engine spiders index your site’s content and rank it low because all they can find are some out of context links, if any.

The SEFFS Method: Content first

My advice for anyone planning to develop a Flash enabled website (and you will also get this advice from any ethically correct “Search Engine Optimizer”) is: Structure your site’s content well and create a simple XHTML version before you even touch Flash. Follow best practices for authoring the XHTML.

That XHTML site can serve as alternative content for all non-Flash visitors including search engine spiders, and it can as well serve as the content for your Flash site. XHTML is an XML dialect, and can easily be loaded and parsed by Flash. You may chose any backend, scripting language, content management software (as long as they output valid XHTML), or just publish static pages. The choice is yours.

Deploy SWF on top of XHTML

Now that we already have a simple, but functional XHTML site, we have to find a way to unobtrusively integrate your Flash site. A very good technique to achieve exactly that does already exist and is called sIFR (Scalable Inman Flash Replacement), developed by Shaun Inman, Mike Davidson and Tomas Jogin.

From the sIFR Wiki:

“sIFR is a technology that allows you to replace text elements on screen with Flash equivalents [..] The technique will work as long as the user has JavaScript enabled and the Flash plugin installed. If one or other is not available, the browser will fall back to traditional CSS based styling”
(http://wiki.novemberborn.net/sifr/show/What+is+sIFR)