To Flash, or Not to Flash?

Two weeks ago, Macromedia’s Flash, a core technology in Web development, became a verb in our company, in the same way “Google” has become a household term. As a powerful and flexible tool for creating rich online experiences, Flash gives marketers equal portions of opportunity and responsibility.

In one of our regular internal email threads about what constitutes an exceptional online experience, a designer flagged a new automotive site because a significant part of it is built in Flash. The internal debate turned into one of “to Flash or not to Flash?” Our entire staff, from graphic designers to Flash coders, information architects to copywriters, other technology engineers to client service people, all chimed in on Flash compared to other implementation methods. What does Flash offer other methods don’t?

We debated whether some combination of other implementation methods could work equally as well, and whether there’s a business case to be made for using Flash instead of some competing set of technologies.

Highlights from the debate clearly articulate the tradeoffs marketers must address among form, function, and accessibility when crafting online experiences. Flash enables very rich and compelling online experiences, with sound and dynamic moving images, which engage users intimately with a brand. The intention is more engaged; users spend more quality time with the brand. That, in turn, increases preference and, hopefully, revenue.

Many argued Flash experiences are measurably better in a few critical ways. Flash can present highly complex data in innovative ways that are only now being explored. It’s a powerful tool to create efficient and user-friendly applications that help customers retrieve and interact with information, solve problems, and make decisions (especially with elegant product configurators or comparison engines). It has become more robust and is now used more extensively and successfully for complex Web application development.

We marketers must provide our customers with the right information within the context of a useful framework. We must evaluate the appropriateness of using Flash for particular projects, considering a number of practical and technical matters: Flash penetration in the target market, file size and available bandwidth for downloading ever-increasing amounts of data (and images, sounds, and animations), and whether these constraints would present a business case against a Flash implementation.

Given Flash’s penetration rate, the growth of broadband to the home, and the increasing strength of computing power, who is really Flash-challenged? Consider:

  • Most of the U.S. population have computers that can deliver an optimal Flash experience.

  • Half of the U.S. population has a broadband connection. According to Nielsen//NetRatings, broadband penetration, including ISDN, cable modems, and DSL, jumped from 38 percent in July 2003 to 51 percent in July 2004. And these are just home numbers. Fat pipes are commonplace at work.
  • Nearly all users have the Flash plug-in. According to Macromedia and NPD Online, the plug-in, necessary to display Flash sites, currently enjoys 98.2 percent penetration globally. Also, the plug-in penetration (as standard with browsers since IE 3.0 and Netscape 3.0) has cemented Flash as a prominent and potentially permanent fixture among Web users.

Note, however, these numbers apply to the general population and might not apply to your target demographic. For example, 18-20 year olds have a higher broadband penetration than the general population, with 59 percent connecting to the Internet via a high-speed connection.

Finally, consider the return on investment (ROI) on a Flash implementation compared to that of competing technology sets. If a dynamic HTML (DHTML) solution can be found, why would a business choose Flash? The obvious reasons against DHTML solutions come to mind, such as cross-browser and cross-platform compatibility. But as a client recently observed, many traditional IT organizations can more readily adapt to DHTML than the proprietary language of Flash, which requires highly specialized and well-trained (or experienced) resources that may be expensive to retain.

Let me leave you with a few last thoughts. Start with the user. Do your homework so you can make an informed decision. Understand how, when, and why users access the experience and design accordingly. Many marketers maintain two versions of a site (Flash- and non-Flash-based sites) to side step this problem. Track results closely, and validate whatever decision you make.

Undeniably, Flash will continue to play a major role creating increasingly more sophisticated Web applications and brand experiences that will ultimately propel online marketing further. So when your market is ready, you may want to Flash, too.

Related reading