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.

I'm now finished my first official project using Papervision. Even though there's been the expected learning curve while learning a new library, the project went smoothly. Prototyping and concepting were a breeze. I hit all my deadlines and milestones, with time to spare. The entire project schedule, I compiled, viewed the piece in Firefox, and saw something like this:

So you can imagine my surprise and dismay when, on a Friday afternoon a little before launch, we moved it over to the dev server and the page where it would live and saw this:

Now I've seen some weird behavior between browsers, but never anything like that - and especially not in Flash!

Then things started to get really strange. Trying to get some insight on what might have happened, I decided to check it out in Safari for the Mac. I soon wished I hadn't...

So, after I had a wee little cry, I started combing the Papervision forum over at Nabble. But no one had ever run into a similar problem. The basic gist behind the magic of Papervision - and most 3D libraries for that matter - is that it takes bitmaps and skews them along an imaginary surface using a matrix. I had the cubes in my pieces separated into 12 of these surfaces, two for each side. The first issue was clearly showing a gap where these surfaces were suppose to meet seamlessly, and the second was doing the opposite, only showing the content on the edges themselves. 

Panic was just starting to set in when Pavel, my partner in crime and Pivot and Levy's resident server-side guru, found something. When he changed the background color of the div where the second issue was occurring to black, the issue went away.

"Ok, it's a transparency issue. Now, where have I run into the most issues with transparency?" I said. "Hmm, I bet it's that pesky little attribute, wmode." I replied. Sure enough, I had copied and pasted a embed tag that had declared the wmode as transparent. So, I figured I'd just set it to the default and go about my weekend.

"Not so fast!" said Mr. wmode. That merely balanced out the rendering problem between browsers. Safari now had the milder, although still debilitating, first issue, instead of the mind-blowingly horrific second one. And Firefox and IE now always had it, no matter what color the background. It was progress, at least. Although at the time I didn't know in which direction

So I cried some more. But then I ran through my code some more as well, looked over every object and property, trying to find anything that might affect transparency. I paused over the MovieMaterial objects that I used to take the Flex components behind the app and populate them to surfaces of the cubes. One of the properties of the MovieMaterial Class is "transparency", but I had it set to false. After all, the surfaces of my cubes didn't need transparency, so why ask the player to try and render different opacities. But I was desperate, the same kind of desperate the makes you look for your keys in the freezer, so I switched it to true and pressed the Run button. 

Bam! Eureka! Bug fixed.

There are two morals to this story. One, even cocky Flash developers need to check their apps in other browsers. And two, always set your MovieMaterial to transparent when using the Papervision3D library.

2008 has been a year of both challenge and opportunity. The pace of technological change continues to accelerate. Markerters continue to feel the pressure to do more with their resources. And the very nature of marketing is evolving fast. At Pivot + Levy, we're constantly learning and exploring ways to help our clients' brands thrive in a world where they are no longer in complete control of the message. We invite you to take a look at our work and learn more about our "multidimensional" philosophy.