Interactive Design Without Flash? Yes We Can!

Jeremy Pratte
November 04, 2010
User Experience Design

Remember the good ol’ days of the early 2000s? A few years after Macromedia acquired Flash (originally named FutureSplash) suddenly it was all the rage. Enterprising web developers saw its potential for cross-browser interactivity and did everything from making largely unnecessary introductory Flash splash pages to entire Flash websites. Beleaguered by and bemoaning about the cross-browser compatibility of their HTML and/or CSS code, they were hungry for something that would display precisely the same way in every browser (that had the Shockwave Flash plugin of course). And, to boot, it could do really cool stuff!! I got sucked in myself and made a few personal all-Flash websites. Boy, were they neat.

But they were also cumbersome.

Many users were wowed, yes, but a lot were turned off by the long loading times and memory-hogging, especially those on dial-up connections. The Flash splash page, while sometimes nifty, was just another obstacle, among many others, between users and the content they were seeking. And, actually, a lot of them weren’t nifty anyway. The all-Flash website just took a bad idea and brought it to its logical, awful conclusion. Sure, they were cool, some of them were Really Mind-Blowingly Awesome. And that was fine for sites that served as online games of a sort or to display cool web toys to play with. But if you wanted content, you had to sit and wait for it to load, sometimes even on fast connections, and then when it did it was often difficult to read or navigate. And it wasn’t only the human user who had this problem. Search engine bots also couldn’t read or navigate the content locked away in Flash movies, which was bad for SEO purposes.

Even though the complaints abounded scores of stubborn web developers plugged their fingers into their ears and said “BUT LOOK AT HOW COOL IT IS!” So Flash splash pages and all-Flash sites didn’t completely go away.

To its credit Flash improved some of its problems. Animations being done more and more in Actionscript, its object-oriented programming language, as opposed to lumbering heavy graphics around the stage, improved load times. And it has made some inroads with regards to being search-engine friendly. But just as Flash was trying to solve those, its biggest problem was just emerging: the mobile web. As any iPhone user knows, myself included, unless you jail-break them, or download some sort of VPN app like CloudBrowse, you’re not getting Flash content. Other phones require a stripped-down version of its browser plugin. This is especially annoying with sites that display video using Flash like YouTube or sports websites like NHL.com. Until HTML5 and its “video” tag came around there was practically no other way to display videos seamlessly right in the page. And that was actually one of the few useful and necessary functions for websites that Flash had fulfilled: seamless and interactive content on a page. But, forget about reaching iPhone users, or users who don’t have the plugin. So what’s a web developer to do in this age where content is king and users are increasingly using their phones to get web content?

The answer is Javascript, a front-end, client-side programming language that’s been around about as long as HTML. Why, if it’s been around so long, wasn’t it used a long time ago instead of Flash for interactive webpage content? Because it was too busy doing button roll-overs, hit counters and Y2K countdowns and the like, and competing with the more robust Java. And it didn’t help that the average web designer probably didn’t know programming extremely well so when the specifications called for Really Cool Stuff they turned to Flash, if they knew it. And plus Javascript’s potential for rich interactive – and streamlined and SEO-friendly – web content hadn’t been fully realized yet.

But all that has changed.

Now, virtually all the interactivity that used to be almost entirely the domain of the big bad Flash can be done using just HTML, CSS, and a javascript library and/or plugin. Javascript libraries consist of using one massive master JS file that will work in conjunction with other JS files that get more specific in their purpose. JQuery is arguably the most popular Javascript library with Moo Tools running a close second. There are out-of-the-box plugins all over the web that just need some modifications. And programming it is almost as easy as doing CSS. Indeed, it often looks a lot like CSS with its dynamic styling declarations, not to mention that it works closely with and sometimes alters CSS for the purposes of animation and interactivity. These new slick Javascript libraries can also be used to resolve CSS browser compatibility issues. Or, in other words, “fix stuff that’s broken in IE.” Or “make CSS3 work in IE.”

But, mostly, the libraries, like JQuery, are basically replacements for Flash when you need to create interactive menus, interactive photo and/or content galleries, video players, and even video games. And, to further add insult to Flash’s injury, there are rarely cross-browser compatibility problems. Most of the time even IE6 will render these components beautifully. Yes, that wasn’t a typo, IE6! JQuery, if done right of course, is also seamless and works great with content management systems, like Sitecore for example.

In this new era of the web, with the importance of accessible content, developing for dynamic content for content management software, SEO, interactivity, and the mobile web, Flash is the odd platform out. Javascript libraries and their plugins can do virtually anything Flash could do, and do it better. Animation, interactivity, cross-browser compatibility, CMS-ready, SEO-friendly, and pimping your CSS, JS libraries like JQuery can do it all.

And – bonus! – you can see the content on your phone. Halleluiah.

comments powered by Disqus

STRATEGIC PARTNERS