In defense of Flash 4
When discussing Adobe Flash, it’s important to separate out Flash, the IDE, from Flash Player, the vilified web runtime. The former I’ll forever have a soft spot for, as it arguably influenced my becoming the programmer I am today.
When people talk about hating Flash, they typically mean the runtime, and all the baggage that goes along with it: its fan-inducing, CPU-devouring ineffectiveness, its perky installer windows that always seems to appear whenever you least expect it, etc. We’ve come to expect better of our runtimes in this day and age. Steve Jobs’ Flash letter spells out clearly why we don’t have Flash on iOS today: its proprietary nature, its security record, performance, battery life, and the fact that it wasn’t designed for touch input. Except for the final issue, these are all failings of the virtual machine. Flash, as a platform, has failed to meet the expectations of its consumers, and rather than supporting this sub-par experience, Apple chose to kill it off. That’s that.
But with the eventual demise of the Flash ecosystem, let us not forget Flash, the editor, especially in its early forms. It was and is one of the most successful multimedia creation tools for the web. It’s interesting to think about why this was. I suspect it was partially because it enabled those without any traditional programming experience to create quite sophisticated web sites and animations. Arguably, this was ultimately because it had an intuitively designed user interface.
I confess: when I was in elementary school, I had an obsession with Pokémon. I had basically memorized the official guidebook to the series – I had read it so many times the cover had come clear off. Of course, I wasn’t alone in my fascination with this Nintendo cash cow. All of the best Pokémon fan pages on the Internet had these over-the-top animated fight sequences as their splash intros, which I thought was the coolest thing ever. Along the way, I eventually acquired a copy of Flash 4 when I realized this was the software everyone had used to make these great scenes. Before I knew it, or knew that programming even existed as a profession for that matter, I was animating my meticulously hand-drawn vector Squirtles across timelines with only the most cursory knowledge of how animation software actually worked. Mind you, at that time, you were encouraged to do everything using a GUI interface, and for most part it handled things quite well. Over the course of a year, I got more ambitious: minute-long action sequences with sound; dancing Pikachus set to the music of Saturday Night Fever; parallax shoot-em-ups made without any real working knowledge of variables. Did I know the inheritence hierarchy of buttons or movie objects, or care about the difference between bitmap or vector graphics? No. All I knew was that I had a vision, and this was giving me some pretty convincing results.
Eventually, I started using event-handlers, learning for the first time how to assign commands to mouse events using Actionscript. I remember this being by far the most frustrating part of the process, as I didn’t ever take the time to read documentation for the thing (as if that should ever be a problem). To me, Actionscript was a band-aid, a set of indecipherable hieroglyphics grafted onto this amazing playground of visual fun. I remember painfully learning what a compilation step was, and wondering if the thing I had just typed up was actually going to do what I wanted it to. I remember cryptic errors leading to abandoned ideas. I remember solving the second hardest problem in computer science: naming things, because you needed to script objects on screen. I remember it wasn’t as fun, more than anything else.
I was realizing the possibilities and the frustrations caused by using an abstract, textual form when interacting with my graphics. With subsequent versions of Flash, it was as if this style had taken over. Best practices now recommended reading the spec for this new, adult Actionscript: a gargantuan, unholy Javascript and XML lovechild, filled with serious object-oriented programming constructs, and all sort of other paradigms completely foreign to me. To make a button before, you had to add actions to its ‘click’ marker on a timeline. With Actionscript, I had to think of my button as a living, breathing object, with event handlers for each of the possible touch states I wanted to work with. I had to straddle two mental models of the thing before I was even allowed to think of doing the kind of animation work I once had. Frankly, I was lost in this world. While others found the challenge of a blank text field exhilarating, my young self found better things to do. With the maturation of Actionscript, the role of the programmer was emphasized over the graphic artist and animator. Flash, the IDE, had effectively said I was no longer its target consumer.
Flash 4 was the beginning for me. I think back to how formative this was in my later thinking about computers; how it gave me the confidence to know that I was indeed capable of making complex animations, and how creating on a computer could be as, if not more, rewarding than any pen-to-paper drawing experience. All this without needing to type a single line of code. As I read back on the history of Flash, it’s interesting to see its evolution from a seemingly trivial drawing application to the highly-advanced development environment it is today. Somewhere along the way Macromedia set its sights on a more serious customer. Did their developers realize what they had created in the first place?
More features does not a better product make. When I see a dearth of simple creational software today, and especially with the iPad in the hands of so many children, I wonder why where there isn’t a more concerted effort in making products that even children can be productive with, like Flash 4. Flash’s focus on simplifying animation and interactions got an elementary school kid to make some awesome stuff, some of which would still be difficult for your run-of-the-mill college hire to do in other mediums – and all because there was a tool with the right abstractions. How shortsighted are we to assume that that we should be teaching everyone “real” programming à la Codecademy or Lua via the iPad app Codea, as if typing programming languages into a terminal was the only valid way to create on a computer. Let’s spend some time thinking about how to re-imagine our own tools and languages to serve the jobs of a diverse set of people, even if it means underserving the most technical for a change. In the process, maybe we give some other kids a glimpse at their potential future selves.