Pet Theory

Flash can do at least 2 things better than HTML: 1) create interactive experiences, and 2) create moving pictures (tweens, animations, video).

That's great. Now let me point out that Flash's two great powers are more than not antagonists, and their clash distorts and cripples many a swf.

The example of 1st-person shooters is misleading here, because the experience of ACTING and the experience of SPECTATING are fused in the intensity of 3D immersion into life-and-death scenarios.

Off this peak, spectating and acting are often at cross-purposes. It can be hard to "do" while you "watch," and to "watch" while you "do." Watching a movie while you play racquetball is a bad idea.

Of course, we multi-task all the time, and I believe there are literally infinite ways to fashion experiences that mix the two so that they complement each other…but I don't believe that designers blind to this elemental conflict will be the ones who create these new experiences.

Here's an example of an appropriate use of animation:

Let's say you're designing a list of items (an item including a picture, a price and whatnot), and users can delete from or add to the vertical list.

Obviously, the list starts at the top. But let's say the user deletes the top element…what should happen? Should all the elements of the list simply be shifted?

Here, animating the shifting makes sense, to make it obvious that 1) the format remains the same, but 2) the items have shifted places.

The alternative is to leave the user confused: did I make a change? Is the list the same, or different?

Most transitions should be handled in Flash without animation, because most transitions are driven by perusals and not commitments, and for perusals, animation is laborious.

Let's say I'm mousing over a menu; why not have text or images come up immediately, on rollover? If your design is logical (where does the material come up?) and your programming suave (you've loaded in the background), this immediacy will free users to look around (focusing here and there, backing out with ease) without having to commit.

But let's suppose the user commits and selects; even then, the question should be asked: why animate? It's useful, because at least if know why you're animating, you'll have an idea how to animate.

Let's say the content that loads is melancholy, perhaps a slow blur tween can calm the user and prepare him to squeeze out copious tears…for comic content, perhaps bounciness, elasticity…for corporate efficiency, exact, efficient motion.

Of course, the meaning of transitions often resides in the logic of the interface itself rather than any content per se. Transitions can orient the user. An event happens, the state of the interface changes, and the user is supplied with a visual correlative of this change.

Let's ignore the fact that 95% of the time, designers use this visual correlative just because they can (animations for the hell of it, dude!), and focus on a few ways that animations can orient users.

1) They can make emerging graphics less (not more) prominent. (As thumbnails load, the user might already be looking at a thumbnail…so the currently loading thumbnail should materialize like a docile child waiting to speak, fading in rather than popping in).

2) Morphing shapes can retain references to consistent layout elements while changing according to state. (The back button used to be on the green square…now it's on the green rectangle…the shape is different, but the same).

3) To anticipate content before the content is loaded. (Preloaders should combine standardized and custom elements, if you ask me.)

There are other reasons–though not so many as "LA Flash" designers assume–to use animated transitions.

Keep in mind that these animations should play quickly if they are intended to be an integral part of the user's interface experience. A plurality of our neurons are devoted to processing visual information, which we do faster than PlayStation to the power of xBox. If you are using an animation to orient the user, the user is probably going to be oriented (or not) in milliseconds.

A rule of thumb: since we see before we verbalize, the visual cueing we give users should be accomplished in less time than it would take them to internally articulate it ("oh…that's still the back button"). Otherwise, the normally slow verbal part of the brain gets to the finish line, has some gatorade and takes a squat before the normally speedy visual component of the brain finishes up. And that's perverse.

I was watching the season finale of 24 and it noticed the titles use linear motion…words come in a steady velocity, hit their mark, and with a resounding thump, stop dead in their tracks. It's exactly what homo-sapien physics would predict: an object comes to a sudden stop, and its energy is released as sound.

Recently I was plotting bitmaps in 3D space, trying out various kinds of motion: linear, curved, inertial…and it got me thinking about how motion was integrated into interfaces.

Take the simplest, most common example: the sliding-out motion of a drop-down or fly-out menu…

Even though I now turn this effect off when I can (it's too slooooow), I was captivated the first time I saw it. Why?

Basically, motion implies weight, and weight implies thingness…and the sliding felt right because the menu is a thing I'm handling. So the motion functions like a kind of drop shadow for user interaction.

Inertial motion–easing in, a Flash staple–feels especially right in this context, because objects with inertial motion are more natural–on earth at least, things with weight come to a stop. It also nicely combines an intitial burst of speed with an ultimate delicate accuracy (the easing in).

When I was working with 3D, I was surprised to find linear motion fetching too…even as an object recedes and its 2D speed slows, your mind knows its 3D speed is constant. It vibrates with sustainable energy, like Stereo Lab, or Bach, or whatever your working music is.

Linear motion is great in 2001, but it clearly wouldn't work in an interface. An object in constant motion isn't an object you handle…and if it stops, where does that energy go? Our minds would add a clank and a shake if a menu slid out in linear fashion and just stopped.

Motion is a powerful tool to orient users…and disorient them, of course. Does motion makes "things" on the screen separate, self-propelled things, or things we can handle, tools?

Obviously, both…the trick is to separate or mix them for the particular experience you are trying to create, right?

If you work at a company with an intranet, I'll bet you remember the first time you called the IT guy for help and he (smirking?) started using remote desktop and wagging the cursor around on the screen and telling you how to fix the problem. It's a creepy moment, and a feeling of disembodiment, when your motion, your cursor and your power, is transferred abruptly to him.

Flash makes me feel that way, a lot.