Reflections on my relationship with Flash

February 14, 2014

Someone recently asked me why I liked Flash so much and have been a loyal advocate for so long. Even though HTML5 and modern browsers have allegedly (according to web design enthusiasts) rung the death knell for Flash, my affection for Flash lives on. But why? Well, I had to do some soul-searching to answer that, and my answer may surprise you with it’s simplicity that (perhaps rightly, perhaps blindly, depending on your perspective) ignores nearly all the technical pros/cons, tell-tale marketplace warnings, and standards-based arguments in the Flash vs. HTML5 debate. But hear me out….

I loved Flash because the products I created with it… just… worked. By “worked,” I mean my creations, designed once by me, were experienced by all end users how I meant for the experience to be “played back.”  Flash worked because the creation software and player/plugin were all offered and controlled by the same company. By having everything from creation to playback owned under one roof, you can expect it ought to have worked flawlessly. And nearly all of the time, it did. It’s not to say creating and deploying Flash-based projects was always easy or as clear to achieve as it could have been. But, from my designer’s point of view, once I validated that my creation worked, I could be confident it would work almost universally, for everyone. I could depend on it — rely on it to be close enough to “fact” that I didn’t have to worry about my creation being presented as anything other than intended to the end user. There’s something that feels “right” about that — something inside that says, “Yeah, it shouldn’t have to be any harder than this.”

Contrast that to the web browsers of Macromedia Flash’s hayday, all from different vendors, all with different features, all with incompatibilities, standardization largely lacking. As I’m fond of saying, no one won the browser war, but the consumers definitely lost. (And in some ways, perhaps us designers did, too.) Faced with those browsers — a “playback” mechanism that I could never be guaranteed would present a creation consistently or faithfully — it’s still not hard for me to look back and validate my affection for Flash. Imagine being a major motion picture studio, releasing a film to theaters around the world, and never knowing if each moviegoer in each theater will have the same experience. Imagine an experience where, in some theaters’ presentation of your film, an actor mysteriously (or perhaps magically) simply doesn’t show up in a scene or two of the completed film. That’s what trying to create rich web experiences felt like during the browser wars without Flash. And while HTML5 standards seem to be heading the right direction now, it still feels that way to a certain extent. It feels like creating a single experience shouldn’t be as hard as it still is.

I understand all the pros/cons of standards, innovation, monopolies, software life-cycles, etc. My mind knows all that. But I can’t help feeling that those of us who love designing digital experiences for others to consume continue to spend more time on technical nuances of the presentation/playback product (out of unfortunate necessity) than on the part of the craft we enjoy. It’s that part of me that loves Flash. In a relatively easy-to-understand interface, it allowed creators to produce relatively rich experiences for the masses to consume, without the mess of sifting the browser vendors’ junk. So Flash or no Flash, I hope those days I remember so fondly will return in the future — for the good of all of us who love creation of the experience more than the gritty technical details.

UPDATE: Three days after posting this, Lars Doucet shared some similar feelings on Flash development in his post: Flash is dead; long live OpenFL!

When a Web page is no longer a page

September 5, 2008

With Google’s announcement and release this week of their own Web browser, Chrome, a lot of discussion has taken place amongst my colleagues about the potential impact of yet another Web browsing option. Based on Google’s track record, reputation, and the description of Chrome’s features, I have no doubt that this new Web browser will eventually make its mark on the Internet world. But what fascinated me more than Chrome’s features and benefits was Google’s statement on why they chose to make a browser. Contained in their rationale was an observation I’ve also claimed for years — that the use of the Web and Web “sites” has changed significantly. Google sums it up this way:

“We realized that the web had evolved from mainly simple text pages to rich, interactive applications…”

Indeed, when I first hit the World Wide Web in early 1995, the WWW was almost entirely static pages of textual information. Explaining the Web to new PC users wasn’t terribly difficult. I framed my descriptions of the WWW as “pages” of content — like a page from a magazine, book, flier, or catalog — all viewed through a piece of software — the browser.

Of course, as the web evolved, we continued to push the original medium to its limits, adding primitive interactivity via forms coupled with server-side technologies for data processing. That’s where the line started to blur. Today, we’ve somewhat reinvented the Web to allow for more sophisticated imitation of traditional* programs/applications within the browser, gaining the benefit of transmitting both the “program” and the program’s data across the Internet/network. With the more recent push toward completely distributed applications and mobile capabilities, a good many sites are looking and performing like entire software apps or suites running right in the browser. The odd thing about this rapid evolution is that these new tools are all still being developed and accessed on top of the original Web framework… individual pages accessed one at a time with a browser program. Our “Web software” still relies on the Web browser and what it can provide.

Now think about all of this from the newer PC user’s perspective. Understanding software programs is one hurdle. Understanding the Internet and the Web is yet another. Once the distinctions between the two have been blurred, in some cases to the point of the latter replacing the former, how can the technology teacher adequately explain — and the new user grasp — all the finer differences? After all, while many Web sites have pushed toward application-level interfaces, “old-fashioned” Web pages on sites still abound. For PC users most familiar with old-fashioned (non-networked, non-distributed) software, how will they perceive and make sense of the shift?

To provide a case in point, I recently had the opportunity to observe some pre-release user testing of an upgrade to an existing Web-based application. The largest “ah-ha” moment for me was when I realized the concept older users most struggled with was that their “software” — the application running via the Web browser — could and would be changed without them taking any action (e.g.: user-initiated installation.) With careful questioning, it became obvious to me that the users viewed the application like any locally-installed software application rather than a Web site. They couldn’t understand (let alone articulate) the difference.

This subtle but increasingly commonplace difference was a challenge to deal with as I wrote the introduction to the Internet/Web chapter in my forthcoming book, The Ultimate PC Primer. I’m still not sure I’ve adequately communicated the differences, but there’s only so much one can write in the attempt to explain it. My lingering and somewhat fearful thought today is: how will Google change this even more considering their claim that Chrome will “power the next generation of web applications that aren’t even possible in today’s browsers.” Perhaps Chrome will become the long-anticipated “platform” for fully-distributed applications, setting that concept apart from simple Web page browsing. If not, my hope is that whatever Chrome evolves into doesn’t make the Web much more confusing for new users than it has already become.

* By “traditional,” I mean “installed” software, which many in the IT industry would call a thick client or fat client. Pardon my informality, but I’m not usually concerned about the exact industry terms…”insider speak” doesn’t help much when attempting to explain concepts to new users.