The Uzanto team has been hammering away at an awesome new social web app that we will be releasing into the wild “real soon now”. One of the things we’ve learned while building it is that Flash is an absolutely essential component of the modern web.
Sure, it can be abused (boy have I seen some bad Flash websites). And yes, it isn’t the easiest technology to work with, and yes it’s hard to hire developers who know this stuff. But at some point, a web app you are building will need one or more of the following
-vector graphics (we needed this)
-audio output (we will need this)
-decent-sized (by which I mean “massive”) cookies
-audio input (we will need this)
Unfortunately, most experiences that end-users have with Flash are when someone tries to build an ENTIRE site (or sub-site) with flash. This is almost never a good idea. It violates the central metaphor of the web, which is:
-Web sites consist of “pages”
-Each page is a text document
-Content and source code from the document can be easily copied
When you build an entire website in Flash, you end up with something that is definitely not a “page”. It’s more like a mini-application, running inside a browser.
This causes all sorts of problems. The biggest is that you can’t make a design that goes
“below the fold” without having TWO scroll bars (one for the browser, and one for the flash app). As a result, most flash sites are shaped like rectangles, and thus feel really constrained and cramped..
-Not being able to copy text from the site
-Various text display problems
-Subtle differences in the standard UI widgets (drop-downs, radio buttons, etc)
Fortunately, you don’t need to use Flash everywhere on your site. The evolving best practice (pioneered by companies like YouTube and Yahoo) is to use little nuggets of flash where it is suitable, in a “harness” of HTML, with DHTML / AJAX handling any sections of the app that involve text display. The html harness evokes the comfortable “page” metaphor, and Flash can be used for what it is really good for.