7 reasons to avoid Flash when designing a website

Unfortunately, Flash technology is a poor choice for most commercial web sites. A proprietary technology, Flash breaks most web standards and conventions. While Flash sites are generally beautiful to look at, the fail to meet a number of minimum criteria for business-oriented websites.

1. Information embedded in Flash is often invisible to search engines.

Most Internet navigators begin a web session with a search engine. Even when they know a domain name, they start with Google or a similar search engine. With all the possible confusion of .com, .net, .eu, it’s better to trust Google to find the “right choice”. As search engines are the gatekeepers to the Internet, it is imperative that companies maximize their natural visibility in search engines.

Search engines work by scanning information on the web, processing it, and retrieving the best match for each user query. Search engines are fine-tuned to process text, semantically wrapped in tags. The markup in hypertext markup language is our specification of a document title, headings, paragraphs and links – structural meaning which helps search engines place appropriate importance on each text element.

Information hidden in graphics formats, such as Flash, is difficult, if not impossible, to find and process. While search engines such as Google try their best to extract links and textual content buried in Flash objects, the process is far from perfect. Sites constructed completely in Flash often offer very little textual information – consequently what information a search engine does find ranks poorly. Even sites partially constructed using Flash often “hide” their internal site links using Flash based site navigation.

2. Website reporting on Flash navigation is problematic and cumbersome.

Web analytics systems help marketing professionals evaluate website visitor behavior in and around a website, providing actionable information valuable in improving a website’s business performance.

Basic web analytics reporting tells marketers where their visitors came from, the pages visited and where in a site visitors abandon a site. One type of web analytics reporting uses web server based data – log files which track every page, image and download served to site visitors. A second type of reporting system relies on JavaScript tags that need to be inserted in every site page and on every downloadable object. While both types of web analytics systems have advantages and disadvantages, Flash based websites present real problems for both types of web analytics reporting tools.

Web server log based systems are able to track when a Flash object, typically a swf file, is viewed. They are not able to track navigation within a Flash object – so if a site is composed of one Flash object which contains multiple site sections, the web analytics system will see a swf download, but will have no idea which parts of the site a visitor viewed nor where the visitor abandoned the site.

JavaScript tag based solutions, such as Google Analytics, rely on web developers inserting a small piece of JavaScript code in each page, usually in the site header or footer. Most sites have a single shared header and footer meaning that the code just needs to be put in one file for an entire site. A basic installation then takes less than 30 minutes from account setup and configuration to page tagging.

As all or most of the navigation in a Flash based site occurs within the Flash object, page tagging solutions require that each user action (such as clicking on a button to view different “content”) be tagged with an ActionScript call to the web analytics JavaScript code, providing a pseudo page name which then appears as a virtual page in Web Analytics reports. While this sounds complicated, the Google Analytics on-line help system provides a good example.

In the real world, this approach breaks down very quickly. Web analytics tagging is often an after thought. Flash ActionScript coding adds extra implementation cost and complexity. Flash designer(s) are often unfamiliar with web analytics requirements and thus don’t consider Flash events tagging requirements during site design. Implemented tag verification is a tedious process as it requires waiting for data to appear in the reporting system – hours or days later. Flash does not provide referrer information, making it very difficult to track navigation paths.

3. Flash breaks web usability standards.

Flash sites might look great, but they start to fall apart when visitors try to use them. Consider a site for a professional services company. The site contains information about the company, its services, case studies and contact information. It is clear that the company invested a lot of time in planning and developing their web site. The site deserves an excellent rating for content and appearance.

• While navigating through the site, try to use the browser back button. Unfortunately, it is disabled.
• Try highlighting contact information to paste into your contact manger, such as Thunderbird or Outlook – you cannot.
• Try increasing the font size to make the text more readable (Firefox: Ctrl +; IE 7: “View -> Text Size”. You cannot.
• Try bookmarking a page within the site (or deep linking to a page from an external site). You cannot. Keep in mind that deep linking, the ability to link to a specific page in a site, affects a site’s visibility in search engines and the overall web ecosystem.

Ouch! These are all problems that could be avoided by using standard html and css instead of Flash. Sites that have these types of problems usually also have problems with web accessibility.

There are (too) many examples of Flash designed sites which present the same problems

4. Lack of consistent cross platform support.

One of the keystones of the web is that a website should work in any browser on any computer – it is openness and standardization which has made the Internet universal. Flash breaks the basic tenets of web design. While most Internet users have Flash installed – they don’t necessarily have the right version installed. Indeed version 8 wasn’t even released for the Linux platform, locking those users out of sites developed for Flash 8 and 9 (Flash 9 for Linux has finally been released, months after the Windows version).

5. Code embedding Flash objects doesn’t pass w3c validation.

The World Wide Web Consortium, the primary web standards organization, provides a free tool to ensure a page’s html is syntactically correct. While search engines and web browsers do tolerate bad html code, a business oriented site usually wants to minimize the risk that an improperly coded page won’t render correctly or will be rejected by a search engine’s parser. Validation of pages removes this risk.

Unfortunately, standard Flash object embedding in the current html version, xhtml, doesn’t validate correctly.

6. Some users disable Flash to avoid flash based advertising.

Savvier web users have learned to disable Flash in web pages to avoid animated advertising and / or to improve page-loading times on dial-up connections. Regardless of the reason, a disabled Flash website looks much like this:

Another reason to stick with html and css.

7. Website updates continually require Flash skills

One characteristic better performing websites share in common is fresh content – they are continually updated to reflect the latest company news and industry trends. Pure Flash and Flash navigation sites constantly need to use a Flash designer every time new content needs to be integrated into the existing site. If this skill-set doesn’t exit in-house, site maintenance becomes needlessly complicated.

So we’ve got a Flash based website. What now?

There are several strategies available for mitigating problems inherent in Flash usage. While a few have already been noted above, each situation presents its own unique issues which need to be balanced based on business requirements and website development resources. In all fairness, there are a few cases where judicious use of Flash may be appropriate.