Monday, June 02, 2008

Animated interfaces

Lately I've been writing a lot about frameworks, today I want to take a step back and talk about a "technique". "Drunken master"/"Praying Mantis" kind of foo pertaining to animations.

Over the years of writing animated user interfaces I've developed a set of rules that I follow when writing animations. It's been a checklist that I've been following almost religiously. Much like my morning list of "1) Open eyes, 2) Check for dead bodies in the bed, 3) Around the bed, 4) if 2 and 3 are negative brush teeth and take a shower, otherwise prepare for a very bad day", which is the main reason why I never had a bad day in my life. Which is another good lesson to learn - very low expectations make for a very fulfilling life.

I've realized that those rules might be useful to others so I'll write a bit about them today. I guarantee you that if you'll follow them the animations that you'll add to any user interface will not make any of your users want to stab you, which again, following the low expectations lesson from the above, is a making of a great day. In fact following these rules will make your UI rock, which even if you have high expectations is a desirable quality.

So without further ado, here are my rules:

  1. Anger rule:
    Creating animations is a lot of fun. Which in turn makes the act of adding animations to a user interface a happy activity. When we're happy we're willing to endure a lot more abuse. In particular ignore or not even notice something that is very irritating. Unfortunately computer UIs are usually used by people who are not happy at all (e.g. they're at work) and their perception of what seemed like a neat animation to you when you were in a great mood will be vastly different. So always, always make sure you've experienced all of your animations when being angry. If they haven't irritated the hell out of you, congratulations you are on to something.


  2. Blind interpolator rule
    Find someone who has never seen the animation you're designing, tell them to close their eyes as soon as the animation starts. Ask them how they think it ended. If their brain isn't able to fill in the blanks and figure out how the animation ends then the animation does something unexpected that will force your users to learn it. For a user interface to be intuitive you have to avoid forcing users to learn its behavior. It has to come naturally.


  3. The timing rule
    This one is tricky. Timing your animation correctly is one of the hardest things to do. I use a two step approach to figure this one out:

    • follow physics - so follow timings from a real world, e.g. if something is falling let it lasts as long as it would if you had dropped something in real world,

    • make it fast - if animation lasts too long people try to stop it by hitting any random key on the keyboard. From user-interface perspective what you definitely want to avoid is having your users hitting random keys while the application is running.
    Animations in user-interfaces need to be very, very short. The point of them is to give subtle hints as to where things are coming from. They're an aid in understanding computers, not a graphical effect that is meant to impress. I tend to violate this rule because if I spend 2 hours writing a really neat animation I'll be damned if everyone won't be forced to look at it. But that is wrong! Very wrong. Subtlety is the key here. If the animation is running on a desktop a good rule of thumb is the "escape key rule" - if your animation is longer than the time required to move a hand from the mouse and hit the escape key, the animation is too long.

  4. No sci-fi rule.
    Also known as the 'avoid goofy and crazy things rule'. Effects grounded in reality will make sure your interface is easier to learn and more intuitive. For user interfaces wacky and cool don't imply "good", in fact it's usually just the opposite. These are not games where "wacky" and "cool" are desirable qualities.

  5. The refresh rule

    Make your animation run at the number of frames per second equal to the refresh rate of the output device and synchronize the updates with vertical retrace.

    Lately I got obsessed with trying to automatically figure out what is an optimal number of frames per second for animations in user interfaces. I can obsess with the craziest of them so last week I added this rule.

    What do you think, how many frames per second should an animation be running at? 15? 24? 30? 40? 60? Coincidentally those are also this weeks winning lottery numbers. The answer is "it depends". It is highly dependent on the refresh rate of the output device. The "you need 24fps (or 30fps or even 60fps) to achieve smoothness" is a myth. No one knows how many frames per second humans can actually perceive but pilots were able to decipher kinds of planes shown for 1/220th of a second. So it seems that we could actually recognize objects at 220fps. How many would we require to not notice any frames is a question without an answer right now but it's likely that you'd need more than 400fps to do it. None of the commercially available display devices can refresh at that speed. So ideally what you want to do is synchronize the number of frames per second to a refresh rate of your output device. Here's an example you can play with: http://byte.kde.org/~zrusin/animsync.tar.bz2. You'll see a square moving back and forth in a window like this:

    You can specify the number of frames per second on the command line and passing "-s" option will sync the animation to the vertical retrace of your output device (assuming your GL driver supports it, which, unless you're running DRM head or the closed NVIDIA driver is unlikely). Experiment with it a bit.

So, these are my rules. They're not laws so in certain situations you might need to break one of them but if you do, you better have a very good explanation that you can back up with some facts for why you're doing so.

11 comments:

clavicymbel said...

Sorry, but the argument that pilots recognize stuff with a stimulus duration of 1/220s is totally bogus.
It's about the contrast regime you work in. The presentations you mention are sharp transients, but animations are not.
I suggest you might want to read about »flicker fusion frequency« and »beta motion«.

Anonymous said...

I can see a huge difference from 30 to 60, however going from there it's less of a difference. almost a bit of a dissaapointment that there wasn't but there ya go :)

clavicymbel said...

This is a compact WP page reasonably dissociating beta motion and flicker
http://en.wikipedia.org/wiki/Persistence_of_vision

Zack said...

@towolf: i wasn't talking about persistence at all, i was talking about our ability to perceive a lot more frames per second than generally thought and in this aspect the the quoted study is a right on.

@anonymous: that's because your output device refreshes at 60hz so 60fps is the optimal number of frames per second.

clavicymbel said...

zack, the study you mention (and not quote) doesn't pertain to motion perception at all.
to make it easier to see for you, imagine that after the 5 ms presentation you backward mask the airplane with another airplane.

I don't now whether you have access to an oscilloscope. If you do, make the test, it's not bound to vertical blanks. I'd be amazed to see that you can discriminate 100Hz from 200Hz even at maximum contrast. But you'd need fast decaying phosphors.

Anonymous said...

Hi Zack! Thanks a lot for this example. I wrote a framework over GraphicsView over OpenGL for highly animated/super-cool interfaces.
I strongly agree with tips 1-4.. (and keep animations under 0.2-0.3s as a rule of thumb).

But the refresh one really makes my day! Currently I drive items animations/screen updates manually at an arbitrary rate of 50Hz unsynced (with all that puking artifacts!!) but after playing with your example I'm going to sync to the screen refresh rate; first thing tomorrow. Already drooling..
Thanks a lot; I just forgot about that old 'demoscene-style' VSync tip ;-)

Zack said...

@towolf: correct, but it is a very good indicator of our sensitivity to visual changes. as to implying that it's hard to notice difference between 100hz to 200hz, that's very possible, but the difference is there, and if the animation happens to be moving colors from one spectrum to the other it will be /very/ noticable. there's tons of articles on how many frames per second would be needed to actually fool human eye. some good examples include:
http://www.100fps.com/how_many_frames_can_humans_see.htm
and
http://amo.net/NT/02-21-01FPS.html

But the bottom line is that the actual result has absolutely no effect on that rule because our physical capabilities in this area go far and beyond what our current display technology can do.

Anonymous said...

Zack++

Anonymous said...

Seem like good rules to me! I tried animsync -s with my Nvidia Quadro NVS 140M (nvidia driver) and it detects 30 FPS but flickers. If I set it to 60, it is smooth. Do you have an idea what's wrong here?

Alex Fuller said...

Yeah another thing to consider is using motion blur. 24fps is enough to fool the eye with motion blur, but for GUI interfaces it is probably not ideal at all. I've played some games at locked 30fps with motion blur vs 60fps w/o motion blur and both look fluid.

Something sort of related, whenever I see a movie which has been made to NTSC 60hz, 30fps (or 29.someshitnumber for those playing at home) it always gives me that "gee this movie is dodgy and cheap" syndrome vs film framerate of 24fps and I'm not sure why. High-budget TV shows must be made at 24fps film quality then as they don't look bad.

Unknown said...

About the shitty 30fps ntsc, see http://en.wikipedia.org/wiki/Telecine#2:3_pulldown