Some recent discussions have gotten me thinking about what is and isn't a good use of Flash. I thought I might illustrate what isn't a good use of Flash, as it's a bit easier to nail down. Mind you, some of these "rules" aren't specific to Flash. Some of them are just basic usability and UI. Without further ado, I give you the Flash Commandments:

Thou Shalt Not Get Between The User and Content

Yeah, you with the splash page - I'm looking at you. If you're trying to decide whether to give the user the option to skip anything on your site, you probably need to rethink whether to even have that element at all (Actually, this day and age you should be rethinking your career while your at it). It's obviously not necessary; otherwise why give the user the option to pass by it. Users come to a site to buy products, gather information, and enjoy content. Don't stand in their way. Don't waste their time. That one extra click you put in front of them could be the one that broke the camel's back and sent them back to the search page to look for a site that will give them what they want in a more straight forward way.

Google is Thy Search Engine, Thou Shalt Not Have Navigation Without Keeping It In Mind

Google might know and record the sordid details of your browsing history, but it can't read the contents of your swf. Flash navigation is usually a bad idea. If for some reason you find a good excuse for Flash navigation be smart about it. You can write your navigation as a bulleted list in standard html for instance, just like Google's mysterious algorithms supposedly like it. Then you can parse the navigation data and send  it to Flash via JavaScript, using a tehnique similiar to Mike Davidson's sIFR. This way the user gets the rich Flash experience and Google's spiders get exactly what they're looking for. You'll still want to make sure it degrades gracefully in case the user doesn't have Flash or JavaScript. You'll also want to offer the user the right-click functionality there are used to via Flash's context menu.

Thou Shalt Not Embarass The User

No one wants to unexpectedly announce what page they're looking at to the entire office or library. Don't surprise the user with blasts of sound. Allow the user to choose to hear your content, either with a volume control set automatically to mute, or by requiring them to actively choose to play your content. Exceptions can of course be made, especially in cases like children's sites, but always weigh the consequences. You can never know what type of sound output the user has. "Welcoming" users with loud, blaring noise will see your bounce rate skyrocket.

Honor Thy Father and Mother

This one is a general rule of thumb for all UI, but since Flash developers seem to be more guilty than most about breaking it, I've included it here. Designing a creative and fresh user interface is great, but before you start congratulating yourself for thinking so far outside the box, ask ol' Mom and Dad to give it a spin. Any user interface you design will always be intuitive to you - it better be, you made it. But even if you haven't personally designed it, as someone who lives and breathes the web you're full of thousands of UI assumptions that the average and not-so-average user simply won't see. That's why it's a good idea to sit down with the people that will actually be using your application. Sure, it might be frustrating. But it's even more frustrating to be made to feel dumb and useless by some designer or developer's poorly thought out UI. If the user can't figure out your UI, it's never their fault. It's yours. You're the one that wants them to use your application, after all.

Thou Shalt Take Advantage of Thy Medium

This is the sin of which the now infamous Dilbert.com is most glaringly guilty. For those who don't know, Dilbert raised the ire of the geek-o-sphere when they "updated" their simple and usable UI to a Flash-based kludge. In their example, what reason was there for using Flash that could not have been better filled by other technologies? The developer did not even taken advantage of the most basic of Flash benefits, the stateful nature of the framework. The entire page is reloaded when the user requests the next or previous strip. What's more, the strip is loaded twice each time. First a static .gif is loaded, then the container swf, which then requests the image again. Judging by the load time, the image doesn't appear to cache. So not only is there no benefit gained from choosing Flash, it's actually to the detriment of the experience. The only "advantage" of using Flash that I can see is some over-the-top rollover animations, that I personally find more distracting than engaging. The moral of the story is, use the right tool for the right job. Don't use Flash unless there's a reason to use Flash.

Thou Shalt Separate Thy Content From Thy Presentation

While this rule is obvious to other types of developers, I've met far too many Flash "developers" that don't understand this basic concept. The all too popular notion that Flash pieces are hard to maintain has nothing to do with Flash's capabilities, and everything to do with individual developer and designers' implementations. Arguably, Flash content can be the most dynamic content on the web. Flash can take a great variety of data and asset formats and display them in endless ways. The only limits are the imagination and the laziness of the person building the application. Yet, Flash's reputation as an unmaintainable platform persists thanks largely to designers masquerading as developers. If you're going to call yourself a developer, start acting like one. Keep your data elsewhere, be it images, text, path names, whatever. Over the long run, the major cost of applications isn't in their initial development, but in their maintenance. If you do your job right, you shouldn't ever have to open your authoring files after the project has been delivered.