The Demented Ravings of Frank W. Zammetti Visit www.zammetti.com for all things me

Animation in user interfaces: not just for coolness anymore!

A question that gets raised a fair bit in my line of work is that of animations in UIs.  Nowadays, most UIs have some sort of animation going on in them: windows expanding and contracting, menus fading in and out, comboboxes that slide open, that sort of thing.  As someone who spends a great deal of his work day, and beyond, thinking about and dealing with UI design issues, more than once I've had someone suggest such animations are superfluous and ask my thoughts on the matter.

I have to admit, for a very long time, I whole-heatedly agreed that animation was pointless.  That was until I did some research and began to understand the reasoning behind why people were starting to do more and more of it.  Contrary to what you may think (and what I frankly thought), it's not just about a "coolness" factor (although that undoubtedly plays a role sometimes).  No, there is some very good reasons for doing it.

It all comes down to some interesting facts about cognitive science, that is, understanding of how the human brain processes information.  You see, the human brain, more specifically, how it deals with visual input (although it's true to some extent of your other senses too), doesn't react too well to sudden changes in the environment.  You can of course convince yourself of this pretty easily just by thinking about what happens when someone sneaks up behind you and throws a hand in front of your face suddenly.  You get startled, most of the time at least, right?  There is of course some basic survival instinct at play here: it stems from the fact that sudden changes in the environment are interpreted immediately as being potentially life-threatening and steal your attention suddenly, jarringly.

However, the more interesting fact is that your brain has trouble believing itself, in a sense, when things just suddenly appear, once it determines there's no actual danger (which, unless you're working on a nuclear submarine is usually true of computer interfaces!).  You see, your intellect knows that things, generally, don't happen that way.  Things don't usually appear out of nowhere (unless they appear suddenly on the periphery, which is expected, but here we're talking about things suddenly appearing in your primary field of focus, i.e., right in front of your face).  So, when your brain receives such a signal from your vision subsystem, it basically goes "WTF?!?"  And, it's jarring, which is the problem.  Your brain has to do a massive context-switch at that point, and context-switching is bad, m'kay?

Now, imagine sitting at your desk and thinking to yourself, "Self, I gotta write a note, so go pick up the pencil".  Your hand moves, grabs the pencil, and it gradually moves into your field of view (we'll assume you grabbed it without having to look at it).  There is a gradual motion here, the pencil moving from the position in space it occupied before you moved it, to the position it ends up occupying when it's in position to write.

Your brain has no problem with that, you see, because it happened over time and your brain was able to track it.  Or, to put it in a way that fits the context of the post: its position in space was animated!  It moved, gradually over some period of time that was above the minimum threshold at which your brain has that "where the hell did that pencil come from?!?" reaction.

Now, going back to UIs... if a window just suddenly appears, even if you don't perceive it, your brain will be taken aback a little bit by that.  True enough, working on a UI that works that way long enough will minimize the effect to the point where it's more or less irrelevant, but it's always there.

That's why animation is a helpful thing and not superfluous eye candy: it effectively helps your brain comprehend what's happening in the UI faster, easier and with less cognitive dissonance, which is a term that refers to the mental gymnastics your mind has to do when confronted with two seemingly contradictory ideas (in this case, the fact that the window wasn't there one moment and now suddenly is).

The other important factor here is that animation actually helps you use the UI more effectively.  When something happens in an animated way, your brain can track the change far more effectively and your reaction times improve.  It's pretty easy to understand really: the amount of time it takes your brain to overcome the cognitive dissonance of a non-animated change can often times be greater than the amount of time the animation itself would have taken if implemented, plus the time it takes you to literally react to the change, thus you respond faster.

To boil this all down to something succinct: animations in UIs help the user to experience less cognitive dissonance, comprehend and even notice changes more effectively and ultimately lead to faster, smoother UI interaction responses.  They are by no means superfluous and aren't just something pretty to impress your friends with!

We have seen over the past few years a lot more animation in UIs.  Partly this is because the necessary hardware power became available to support it, but also because the basic understanding of its benefit were realized.  Apple has probably done more than most others to demonstrate this.  Virtually every UI Apple has done for some time has some form of animation, from the iPod to the Mac to the iPhone, they all have it.  Very often it's so subtle that you barely notice it, but that's exactly the point.  And isn't it true that most people agree Apple produces some "smooth" UIs?  Guess what?  Animation plays a key role in that judgement!

Now, all that being said, it's also 100% true that you can royally screw up animations and wind up with a large negative impact.  Animations need to be quick, in fact just quick enough to be perceivable, and also need to be fairly mundane, in a way, or you might even say realistic in some way.  Those windows that explode in a million pieces when minimized may look hella-cool for instance, but they aren't really helping the user any, certainly not as much as a simple shrink-to-the-taskbar kind of animation, because it's not something anyone typically expects a window in any context to do!  So, it can do a lot more harm than good in the end.

Also keep in mind that the term "animation" isn't limited to motion.  For instance, you can animate the color of an element across some range, say highlighting a message in yellow briefly and then fading gradually back to the standard background color.  This is a very common UI trick referred to as the Yellow Fade Effect, and it is also a form of animation!  Animation just means a gradual change of some property of an object over time (usually a visual property, but not necessarily).

So, the next time you're working on a UI design, and you want to impress your boss by putting in some cool-looking animations, you can sell her on the fact that it's not just something cool and isn't just pointless work to make your little programmer heart be into the project.  No, there are legitimate, scientific principals at work there that, when done right, will have a positive impact on the human-machine interactions you're building.

But yeah, they can *still* be cool too!

Zammetti.com redesign done

Well, it took me long enough, that's for sure, but I finally got around to redesigning Zammetti.com.  Now, all things me can be found there.

Check it out

(Yes, that's really the entirety of this blog post!)

Software Engineering == Marriage … sort of

You know, programmers love to build layers, especially us (primarily) Java guys. For some reason, a language named after a caffeine-heavy beverage brings out the need to abstract away everything from everything else, to extend this and that, to build parts on top of parts on top of yet other parts.

The CIA uses layers to hide the truth. They tend to "abstract out", so to speak, the field agents from the analysts, make it so that the truth is at least ten levels of indirection away. I guess the spooks are developers at heart!

I've known people who take the simplest of programming tasks and turn it into a monumental task, complete with implementation of 10 different patterns, 20 different interfaces because God knows we might need to implement a whole other way to add two integers together some day, and build delegates and DAOs and DTOs and VOs and Cheeri-o's and O-rings and O MY GOD JUST STOP ALREADY!!

You know, layer cake is good. It's real damned good actually. Look at my gut these days and that fact becomes obvious. But too much will clog your arteries and make your heart explode at age 35. Thus it is with software engineering (I'm not really sure what that means, but it sounded good as I typed it).

Then there's loose coupling. It's great to have small parts with very fine-meshed interfaces that can be connected in new and exciting ways to do all sorts of whiz-bang things. I'm all for that.

And then, there's love and marriage.

You see, love, and most especially marriage, is a WHOLE lot software architecture, at least the type I've described here:

• Of course, there's the KISS principal in software design (Keep It Simple Stupid, for those living under the proverbial rock, a principal more and more developers and architects seem to either forget or just don't get these days). There's of course a "kiss" in marriage, but unlike the KISS principal, which can lead to elegant, easy-to-maintain software, the "kiss" in marriage usually leads to a creation that sucks the life out of you, is anything but elegant, and is a bitch to maintain.

• Marriage is an exercise in bad SOA (Service-Oriented Architecture): the interface between the two entities is highly unknown, constantly changing and very confusing. I'm not talking about the PHYSICAL interface of course. No, that's pretty simple for most people. Trying to get the two objects in a marriage to communicate however is an exercise in frustration under the best of circumstances. A wife's interface changes constantly, is prone to blow up if you feed it the wrong information, and is unusable for about a week out of every month. A husband's interface is usually easily distracted by anything that can be thrown, or can be shown on television, tends to not remember values from one request to the next (which is how HTTP works, but men don't remotely as well as the protocol does) and usually have too simple a data type collection (grunt, groan, hmrph, that's about it). No, husbands and wives, like a client calling a service with a poorly-documented external interface don't communicate very well on most occasions.

• In a marriage, as in a poorly-designed system, there isn't enough separation of layers. Now, of course above I was saying how too many layers is a bad thing, but on the other hand, if there's not quite enough abstraction between layers, that's just as bad. Components that know too much about each other are difficult to maintain separately. Translation for the married crowd: no time apart from one another leads to nothing good. There has to be some degree of separation, some degree of space, some degree of personal freedom, or things won't work, much like a change in one function can break an entire system if not abstracted quite enough.

• Like in a lot of software written today, love and marriage has terrible error handling. When something goes wrong, it isn't usually handled gracefully, the whole system just falls apart. Statistics say that 50%+ of all marriage ends in divorce, which means the system couldn't be rebooted. I suppose modern computers have an edge there because a reboot tends to fix just about anything, at least in the Windows world.

• Marriage in general, like so much software written today, is an exercise in anti-patterns. The whole point of sex is to perpetuate the species. As such, the seeds should be spread around as much as possible (this isn't an argument for being promiscuous; it's just a statement of biologic imperative and evolutionary truth). So whose bright idea was it exactly for two people to stick themselves together and never do right by their species by ensuring genetic diversity?!? I submit that's an anti-pattern! Love, and certainly marriage, is exercises in two people giving things up to be together. That's an anti-pattern! Of course, software engineering isn't ENTIRELY like marriage:

• The user interface of most software stays pretty static over the years. There are tweaks, sure, but most UI's don't change drastically over time, barring a complete rewrite of the application (which you can liken to getting divorced and then re-married). Husbands and wives, on the other hand, have interfaces that change drastically over time, and unlike software that can be re-written to have a prettier look for the marketing folks, married people don't have it so easy. You got what you got, that's the simple way to put it. When the hair, when the teeth fall out, when the fat hangs and the smells get more stringent, sorry, that's the software you bought all those years ago, be happy with it!

• When big development projects fail, lots of money is lost. There's always plenty of blame to go around too. When a marriage fails though, it tends to be a lot less fair on one party or the other, and it tends to be the fault of one person or another. It's nice to know where the blame should go I suppose, but not if you're that target!

• A successful development effort usually leads to someone wanting you to do more, better projects. With marriage, once you have that first success, so to speak, that tends to be it, no more come down the pipe. Not without running into the last point at least!

• Aside from TurboTax, not many software projects will help you get more money back from taxes. Marriage does.

So you see, software development, love and marriage are all different sides of the same coin... a weird-ass three-sided coin I grant you, but the same coin none the less. So the next time you're writing some software, think to yourself "hey, if I can do this, I can be in love and have a good marriage!" And always remember as you work through your marriage: "this is no harder than that trend analysis algorithm I wrote last week!” I think you'll be a happier person for it.

(Disclaimer: I am a happily-married man, and a happily-employed software developer... any relation to your job or marriage, or anything resembling sanity here, is strictly a coincidence)