State of the Flash: Overcoming Platform Confusion

I started this series of articles last week with a wandering post touching on what I thought are some of the core aspects of the evolution of Adobe Flash technology over the past four-plus years. Particularly:

  1. The Adobe acquisition
  2. The introduction of ActionScript 3
  3. The explosion of video-in-Flash

Of course, while I believe these are the most significant events in this period of the history of Flash, these three items alone do not cover the full picture of what’s happened.

When I last gave my ‘The State of the Flash’ talk in 2006, I included a section entitled a “What is Flash?”. Even when giving this talk to users of Flash, I found it surprising how core users of this technology were unable to answer this deceptively-simple question. It’s one thing when a potential client doesn’t understand what Flash actually is — it’s entirely another when your Flash guy doesn’t really understand what Flash actually is. And for years, this was, by and large, the case.

In broad strokes, the answer in 2011 is the same as it was in 2006:

  • Flash is a technology platform that enables the creation and execution of rich interactive experiences on a large number of digital devices
  • That platform consists of three main elements:
    • The Flash File Format: The data file (for general purposes, we will call these .SWF files) that defines Flash experiences. SWF is an open-format — which is why so many other software firms can export Flash files.
    • The Flash Player: The piece of software that resides on the machines of people who want to view SWF files. The Flash Player remains the most widely distributed software in history.
    • The Creation Tools: The set of software tools that users exploit to create SWF files.

That is the magic of Flash. The authoring tools enable a massive degree of flexibility and creativity with media, data and interactivity. And the players (aka, ‘runtimes’), like Flash Player and AIR, enable you to show that work to almost anyone in the world. The authoring tools without a player are useless; and the player without the authoring tools is similarly useless. This is why Flash has power as a Platform.

In the course of the past four years, we’ve seen significant strides across all of these areas. And in the process, I believe that Adobe has executed vitally important clarifications, simplifying the Flash Platform ecosystem.

What's the Confusion?

It is said that Steve Jobs, upon his return to Apple in the late 90s, was asked by a friend to recommend which Mac model he should purchase. Jobs, recently back to the company, took the opportunity to look through his hardware catalog from the perspective of a customer, and he realized something — he couldn’t figure out which model was right for his friend, either. When Jobs realized that the chief executive of the firm couldn’t determine which model to purchase, he knew it was hopeless for the average customers to do so.

And that’s when we got the iMac — and today Apple has an incredibly simple line of hardware, with a clear role, purpose and benefit for each model. Want a desktop? If you’re a pro, get a tower; if you’re a standard user, get an iMac; if you’re a budget user, get a mini. Or, if you’re on the move and want a laptop, if you’re a pro get a Pro, otherwise, get the regular MacBook (or, if you’re a fancy-pants show-off, who doesn’t need to actually get any real work done, you get the Air); or if you just want a portable device, for simple things like web browsing and email, get an iPad. Wham boom bam, thank you ma’am. It’s that simple. Try executing an equivalently simple description of, say, Dell’s or Sony’s lines of computers.

In this (somewhat imperfect) metaphor, by 2008, the Flash Platform was, in the minds of potential customers and users, akin to Apple’s hardware offering in the late 90s. And this was largely due to how Macromedia introduced the technologies called Flex.

It’s important to understand the context of the release.

In 2005, Flash was still considered a ‘weak’, ‘immature’ technology — a ‘joke’ in comparison to real programming languages (none of which actually ran in a browser, but that’s another story). Still, from around 2000 through 2005, power users of Flash built some amazing experiences — yes, we had the purely useless and intoxicating eye-candy exemplified by Pray-station.com, but there was a whole class of projects that were being released, that were effectively full-on applications, that ran in a browser over the internet. And since these applications were made with Flash, and could easily include all sorts of media, they were called rich. And so around 2005, we started hearing this term Rich Internet Application (or RIA for short — an initialism that now sounds as dated as ‘PDA’).

At around this time, I considered myself one of the power users of Flash, and was able to single-handedly execute enterprise-scale RIAs for clients including Medtronic and IKEA. And, of course, because Macromedia Flash was the only real tool you could use to create Flash experiences at the time, that was the tool that I used (along with a simple external code editor).

It was around this time, that Macromedia introduced Flex. Flex then is not the same as Flex now. Flex 1 and 1.5 were built on ActionScript 2 — not AS3, which is the only version of ActionScript that you can now code with for Flex — and required and expensive server module to run. So, to execute Flex projects, you had to get your clients to agree to purchase a $20,000+ piece of server software for the app to function.

To explain the role of this new tool called Flex to the marketplace, Macromedia tried to make it simple. Flex is for RIAs. Flash is for everything else done in Flash.

This turned off quite a few users of Flash, such as myself, who had been building RIAs in Flash, without Flex. Now, Macromedia was trying to move the market away from us. You do RIAs? Well, you’d better learn Flex, and you’d better be able to sell your clients on the server component (hard as that would still be today, at the time, none of my clients were the sort who had an extra $20,000 laying around.

Fortunately, Macromedia didn’t have all that much success penetrating the market with these early versions of Flex. Only a small portion of the work of the industry moved over to Flex, while the majority of RIAs were still executed in Flash.

But with this product launch, Macromedia introduced the first bit of confusion over Flash Platform tools that would grow over the coming years.

As computer hardware, internet bandwidth, and the Flash Player all continued to improve, the number of RIAs continued to grow. More and more websites started including product configurators, design tools — even full on word processors. And eventually, Macromedia decided that the messaging they had been telling customers (that RIAs required a minimum $20,000 investment in server software, before you begin any custom development on top of that) was both misleading and self-defeating.

At around this same time, Macromedia had been developing ActionScript 3. And so, with the new engineering of Flash Player 9, built around AS3, Macromedia decided to re-design what Flex was.

Flex 2 was released as a completely different tool. Now it was based around AS3. Gone was the server component (and with it, the $20,000 overhead with any decision to use Flex). Instead of a custom IDE, as we’d seen with Flex 1 and 1.5, Flex 2 was built around Eclipse (opening up a wide range of Eclipse-compatible developer plugins, like Subclipse).

And we were introduced to the Flex Framework. The Flex Framework is a set of ActionScript 3 code libraries that have been designed to facilitate, standardize and accelerate the development of applications built in Flash. (What’s an application? Well, that’s subjective, but, as a rule of thumb, the more GUI components you are placing in your project, the more likely it is that you are building an application.)

With this shift, Flex began to pick up many new users — including many programmers (such as C and Java) who had never touched Flash before. And it did really help people standardize and build larger scale applications in Flash.

But, this release expanded the confusion that had been introduced with the earlier versions of Flex. Flex was now two things: first, an AS3 framework; and second, an IDE for building Flash experiences with that framework.

So, while this release of Flex was vastly improved, and created the foundation for the current versions of Flex, Macromedia’s messaging was still somewhat frustrating, because of the intermingling of the branding of the framework and the IDE.

  • What if you wanted to code larger apps for Flash, but without using the Flex Framework? There are hard-core developers who prefer to use other frameworks, or no frameworks, in their work.
  • What if you wanted to use the Flex Framework, but have another tool that you prefer to code in (like FDT)?
  • What if you like to build applications in the much more visually expressive Flash tool?

The answers weren’t clear to anyone except those with intimate familiarity with the Flash Platform.

What was the impact of this confusion? I believe that this lack of product clarity dampened the adoption of Flash technology among developers and agencies — decision makers didn’t know whom to hire, there weren’t many available resources with decent Flex skills, most Flash users were intimidated by Flex.

Users of Flash were implicitly told, “if you can’t handle Flex, stick to the timeline” — there was no middle-ground. This division was exacerbated by Macromedia’s (and now Adobe’s) decision to maintain the same limited functionality in the AS editor in Flash Pro — meaning, if you couldn’t handle Flex, you couldn’t even get access to the tools to allow more powerful coding.

Potential users of Flash asked “what tool should I learn?”

Existing Flash users asked “Do I have to learn AS3? Do I have to learn Flex at the same time? What is Flex, anyway? Is it the same as Flash or different than Flash? Should I just stick to animations, banners and simple websites?”

Decision makers at agencies asked “what skills do I need on my team? Whom do I hire? Can I migrate my existing Flash guys to Flex? Can they do both? What’s actually the difference between Flash and Flex, anyway? Do I really want to invest in building a new team built around this new Flex technology, when I already have a great Flash team? What part of this do I need to communicate to clients?”

And clients demanded “Do viewers need a different player to view Flex work? If Flex is Flash, why can't my existing agency/team just work in Flex? Why do I care about any of this? Get me my damn app!”

We still work with clients today, in 2011, who have internal Flash teams (that is developers who use the Flash Professional authoring tool on a daily basis), that have almost no understanding of the nature and purpose of the Flex Framework.

This has also contributed to the continued persistence of AS2 developers in the Flash world. AS2 is, in definite, objective terms, a vastly inferior language to AS3. And AS3 isn’t any harder than AS2 — it’s just different. But the confusing messaging from Macromedia (and then Adobe) contributed a fair amount to the hesitation among existing users of AS2, to migrate to the newer and more powerful version of the language.

Flex 2, by the way, was the final authoring tool launched under the ‘Macromedia’ name.

Where Are We Now?

It’s now 2011, and Adobe has done a great deal to address this confusion. The biggest clarification to the Flash Platform tools came with the release of Adobe CS5 in 2010.

With CS5, Adobe renamed Flex Builder into Flash Builder. This simple product renaming greatly helped to clarify the platform. Flash Builder is for coding Flash experiences (whereas Flash Professional is for designing and animating them). Period. You can create work Flash Builder with or without the Flex Framework — since that is a framework, separate from an IDE. (That Flash Pro CS5 and Flash Builder CS5 also included enhancements enabling a more integrated workflow is an added bonus; more on that in the next post in this series).

With this single move, Adobe removed a massive amount of market confusion, surrounding the Flash Platform, clearing the way for increased rates of adoption in the market. But, of course, that single move did not occur in a vacuum.

Integrated Development Environments, or IDEs

With the release of CS5, Adobe launched a new tool to help create Flash experiences: Flash Catalyst. So we now have three primary Flash Platform authoring tools from Adobe, each with a clear purpose and role in the creation of Flash experiences. A complete, contemporary authoring workflow for the Flash Platform spans all three tools.

  • Flash Professional CS5: this is the evolution of what Macromedia used to call Flash. It is a design and animation-centric IDE. You can to code ActionScript in Flash Professional, but it is not recommended for industry-standard production practices — it’s simply an inferior coding tool.
  • Flash Builder 4: this is the evolution of what Macromedia and Adobe used to (regretfully) call Flex Builder. Built around Eclipse, Flash Builder 4 is now a relatively mature engineering tool, designed to enable people to code ActionScript 3 for Flash experiences. Flash Builder has absolutely no design or animation capabilities, and the graphical editing capabilities are quite limited.
  • Flash Catalyst CS5: this is a brand-new tool from Adobe with CS5. And so, true, it is a bit limited (it is v1 technology, after all). But I believe Flash Catalyst is a very significant addition to the Flash Platform, filling an important need. In essence, Flash Catalyst allows designers to turn their Photoshop or Illustrator designs into functioning Flash experiences, without any code. Pretty impressive stuff. But, at Almer/Blank we don’t even use it for that purpose — we, instead use it as a way for production designers to prep all visual assets from designers, for the engineering team. It makes the process of porting designs into functioning Flash experiences, much faster and more accurate.


Since 2006, we’ve seen the role of ActionScript 3 coding frameworks, grow to become an increasingly important aspect of the Flash Platform. Frameworks, like Flex, are libraries of AS3 code designed to standardize and expedite development.

What is a framework? A set of coding libraries that you can use to accelerate development (make it faster to create things) and standardize development (make those things more like other things, which means that the code is much more readable, even to those who did not write it).

Frameworks are not authoring tools — frameworks are used in conjunction with authoring tools (and included in your file at compile-time), to create your experiences.

With Flex, Macromedia released the first official framework for ActionScript 3. As I’ve described above, the Flex Framework is designed for the creation of applications in AS3.

More recently, Adobe has released its second official AS3 framework, the Open Source Media Framework (OSMF), which you can see at http://osmf.org. Just as Flex is designed to accelerate the development of application GUIs, OSMF is designed to accelerate the process of working with media — audio, video, images, and all supported-types of media — in Flash.

I believe that the process of working with media is so fundamental to so many Flash experiences, that Macromedia should have focused on building a media framework (like OSMF), before an application framework (like Flex), but fortunately now we have both.

Of course, throughout the history of Flash, there have been plenty of other AS3 frameworks from third parties. Frameworks such as:

If you are interested, spend a little time on the Google to learn more about these and the plenty of other frameworks that are available to you if you are working in ActionScript 3.


As amazing as Adobe’s Flash creation tools are, they would be useless if people couldn’t actually view them. That’s what the runtimes do. And, by and large, they do this almost invisibly to the viewer (many of whom do not even know that they are looking at and enjoying Flash technology).

It’s impossible to understand or appreciate the nature and importance of Flash, without understanding this fact: what makes Flash really amazing, is not it’s capabilities, but the fact that those capabilities exist on almost every computer in the world!

Flash could be the most amazing creative technology in the world, but no one would care at all, if no one could see it (*cough* — Processing — *cough*).

The runtimes are core to the Flash Platform. And Adobe intentionally uses the plural of ‘runtimeS’ because there are more than one.

One, of course, is the Flash Player, which is an engineering marvel. Sure, it’s come a long way, but even back in Flash 4 it was stunning. First, Flash Player has long been the most widely distributed software in history. No other technology even comes close.

You may not fully appreciate some of the other ramifications of this; for example, Flash Player is the most widely-distributed MP3 player, and the most widely-distributed video player, in history. With each new version of Flash, Adobe adds in significant new powers — two ActionScript virtual machines (or AVMs, which is why you can write & run AS1, 2 or 3), three video codecs, three audio codecs, software and hardware-level processing and rendering, dynamic audio rendering, live and recorded streaming, support for PixelBender (for mesmerizing visual effects), and upcoming support for powerful 3D.

And, with the latest release of Flash Player 10.1, we have a significantly more powerful player, optimized to run on handsets and other devices. As one Flash Player engineer said, “we had to take Flash Player 10, and get it to run well on computers 10 years old” — which they did. And because the regular Flash Player is designed for mobile, the separate FlashLite Player is now just a bit more than a memory.

As well, in the past few years, Adobe introduced another runtime, AIR, which is designed for device-level execution — running from the desktop as a native application, instead of in the browser. AIR uses the same version of ActionScript 3 that you would use when coding for the regular Flash Player, and with the recent update of AIR, you can now create native applications for mobile devices.

Because of the engineering effort Adobe has placed into improving the Flash Player performance, and with the addition of AIR, users of Flash can now really create experiences that will run, in or outside of the browser, on any number of devices, from desktop Macs and PCs, to the dozens of Android phones and tablets already on the market, to the new GoogleTV.


And so, while the Flash Platform continues to mature, and the number of tools, frameworks, and runtimes continues to expand and increase in power, I believe that Adobe has successfully re-positioned the tools in such a manner as to overcome the confusion that has surrounded these tools, their roles and the overall skills and workflow required to create awesome Flash experiences.

And, along those lines, the next article in this series will be about Flash Platform Design Workflows.

Share and enjoy!


Category: General Posts


4 Responses

  1. [...] Next in the series: Flash Platform Confusion… [...]

  2. [...] Almer/Blank Labs. It's not short, but if you've got a few and you're interested, you can check out Overcoming Flash Platform Confusion. When I last gave my ‘The State of the Flash’ talk in 2006, I included a section entitled a [...]

  3. [...] This post was mentioned on Twitter by RichMediaInstitute. RichMediaInstitute said: More thoughts on the State of the Flash, Flash Platform Confusion, on A/B labs http://is.gd/hzozGi [...]

  4. [...] the prior post, I wrote about Adobe’s effort to clarify the role of the individual tools that comprise much of [...]

Leave a Reply