Every Flashback has a Silver LiningFeb 24, 2009 In Design By Nishant Kothary
We recently moved to a new building on campus that doesn’t have its own cafeteria. As blasphemous as that is, we’ve learned to deal with the situation and have gotten into a cadence of walking to a neighboring cafeteria with a teammate for lunch. Lunch conversations – what a concept!
Joshua and I went to lunch last week and ended up talking about the web development experience, specifically, how far it’s come in a decade, yet how much it’s remained the same. The last couple of decades we’ve been using text editors to write markup and scripts. And today, despite the advent of IDEs with all sorts of bells and whistles, we’re still using simple text editors to write markup and scripts. A recent poll by Smashing Magazine revealed NotePad++ to be the top web developer code editor (with 23% of the market share), and Vim and TextMate coming in second sporting 11% each. Most of us revert back to good ol’ handwritten markup and scripting and generally, productivity features such as code completion and coloring are sufficient to make us happy. But hold that thought for a minute, and let’s change the topic to Flash.
Flash 5 introduced ActionScript 1.0 – true scripting, procedural programming,and for the brave of heart,object-orientation through the prototype chain. There were a few of interesting things that I remember about that period:
- Flash broke away from being just a designer thing. It was predominantly an animation tool before AS 1.0 but with a decent scripting language in place, developers entered the Flash scene.
- A unique community was born: one made up of developers, designers and everyone in between.
In hindsight, the steady trickle of developers entering the Flash world upon the introduction of AS 1.0 wasn’t a surprise. Here was a time where your only other build-once-run-everywhere option aside from HTML/CSS was basically Java. And, if you wanted to build a powerful GUI using Java, you either started from scratch or extended Swing. While it was powerful, you needed to be a Computer Scientist to do the simplest of things. Compared to that, Flash and AS 1.0 were approachable – extremely approachable, actually. The birth of a community around AS 1.0, too, was a natural phenomenon. After all, the web is the biggest democracy and historically, the most approachable technologies have garnered a strong following (sure, some campaigning, i.e. bundling a plug-in into the operating system, never hurts adoption).
Despite its ubiquity and popularity amongst creative developers, Flash got its share of beatings once it went mainstream. Among the notable gripes – flash content wasn’t search-engine friendly, flash sites broke established browser metaphors (back/forward button, etc.), accessibility issues and my personal favorite (I paraphrase, of course) – Dear Flash, you’ve now armed the world of web monkeys with guns, and I hate you for that. Signed, Irate User Who Just Clicked "Skip Intro." Some of you may remember the issues published in a flaming summary destined for immortality by Jakob Nielsen in his Alertbox article: Flash: 99% Bad.
Looking at the complaints across the board, the source of the issue in my mind has always been at an architectural level. The Flash movie (i.e. the compiled swf that you embedded into the page) was effectively a black box that sat smugly on the page and it put up quite a fight if you tried to get it to talk to the rest of the page and vice versa. Here was this awesome thing sitting in the middle of the web page, but it just didn’t care to be a first-class citizen of it. Admittedly, I’d place some of the blame on the browser plug-in model that doesn’t have any requirement for how the plug-in integrates with the page DOM. Not to mention, Flash was never meant to be a something that extended the capabilities of the HTML DOM or even integrated with it; it was a way to embed animations in a web page. But, still.
This little architectural nuance has had far-reaching and deep implications on the workflow for us – the creators and keepers of the Web. If you are setting out to build a site that has a few instances of Flash on a page, you have to piece together interactions and UI in the Flash IDE, compile to a .swf file, embed the .swf in a web page and repeat; looks pretty neat and clean on the surface, but anyone who’s lived it knows otherwise. It breaks the typical workflow where you may simply create more code files in your text editor, or embed some scripts inline. And getting that .swf to pretend like its just another HTML tag is generally beyond the scope of most projects. This has resulted in the development of the RIA trend that has become commonplace today – most RIAs are either clumsily hosted apps within an HTML page or they take over the entire page without rhyme or reason. Granted, there are many cases where this makes sense, but a vast majority of the cases you come across are simply gratuitous. More so, instead of improving the experience for a user, they hijack established design patterns in the name of "rich" experiences.
This is not a Flash-bashing marathon (in the spirit of full disclosure, I’m a former Flash junkie and author), and to set the record straight, Macromedia and Adobe have addressed many of the concerns Mr. Nielsen complained about a few years ago. In fact, the stuff I’ve written above is hardly unique to Flash; Silverlight shares most of its characteristics from a development experience perspective. For instance, you need Visual Studio to make the magic happen, it’s all compiled down to a .xap that you have to embed, and so on. Silverlight requires you to leave the comfort of you text editor just as Flash does.
Interestingly, Silverlight retired the v1 programming model and developer experience in favor of the round-trip, write-compile-embed-repeat workflow. If you buy that one of the key uses of a rich element on a page is to enhance the overall experience of the page, then the programming model we currently use to develop Silverlight (and Flash) applications is counter-intuitive. Period. It doesn’t promote thinking about Silverlight (or Flash) as first-class elements of the page. Not to mention, the overhead for building these little islands of extended functionality is substantial and too tedious for most of us to bother ourselves with.
Let’s face it, for better or for worse, HTML/CSS form the backbone of the Web. History has repeatedly shown that any web technology that attempts to muscle its way into the browser without paying nice with HTML and CSS eventually finds itself deprecated or pushed into a niche. Maybe we’ll be proven wrong one day, but I don’t see any serious contenders for the top spot occupied by the democratically elected HTML+CSS duo right now. I’ve alluded to why approachability is one factor that determines the success of a web technology, but compatibility with HTML and CSS is equally important. And you don’t have to look very far for evidence – take the examples of jQuery and PHP, two broadly adopted technologies that are built on the premise of enhancing the most familiar programming model for web developers.
Are we going about it backwards? Is our collective vision for the web developer experience as it relates to RIAs myopic because of the precedent Java set back in the day? It’s not like we haven’t been wrong before on such a grand scale. I’m looking at you, WYSIWYG.