Sometimes applications can benefit from animations in the UI.
- What tips do you have for determining when you should use animation?
- How can you maximize the usefulness of animations and avoid misuse?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this communitySometimes applications can benefit from animations in the UI.
Think cause and effect. If I hover over a button, I'd like feedback of some sort. If I can drag something, indicate that somehow. If there is an alert or notification, unobtrusively draw my attention to it. Beyond that, unless you have a very specific reason for the animation, don't use one. Try to avoid anything that can get annoying if it continues. If the animation isn't important and it distracts from the main purpose of the page, eliminate it.
Some locations where animation can be appropriate:
Animation (change/motion) catches the eye more than most other things, so it's great when you want to draw attention to an action that might have slipped the user's attention otherwise.
However, even for the items above, it might be worth while to do it just the first few times - since the eye is automatically drawn to it, it serves as a distraction and hence should be avoided after the initial "guidance" has been completed.
You should always have some sort of busy/working animation to keep your user from thinking the app has stopped working (especially important for ajax apps).
Simple quick transitions are OK if they add to the overall user experience, but don't put too much.
Have you ever used an app where you thought that "I wish the developer would have put as much time into planning the actual features as he did planning the cool UI effects"? Keep this in mind when you add animations.
Great question. As usual, it depends on the app (games should probably use a lot more UI animation than productivity apps, for example), but there are some general principles.
Back when the iThings were new and hot, everything had to be animated, but it's interesting looking at VS2010 and Office 2010 and seeing how much is not animated. In particular, in Office 2010 fade-in hover/button rollover (while Office 2007 did). IMO, it feels more responsive. Menus still fade in/out (though it's worth noting that menus take about twice as long to fade out as they do to fade in, which may increase perceived responsiveness).
In general, animation should be used when components of the UI move around without the user explicitly dragging/scrolling them. If the user is dragging an icon into place, "scootching" other icons out of the way conveys the effects of the user action (though sometimes an insertion-point line is enough). The "information bar" on IE/Firefox pushes other stuff downwards to reduce the jumpiness and attract user attention. Accordion and tree menus have tested better with animation since the user sees where the other elements go.
I saw a study once that showed that users of all levels are less inclined to interact with a UI element that's animating (if I find the link I'll update this). So if you light a button up over 2 seconds when the user hovers over it, even if the button will work during animation, users will subconsciously wait for the animation to finish. To get a feel for this, check out the WPF Themes sample. Some themes have longer hover animations than others, and you can determine immediately which ones feel sluggish. The slow fade effects may also have contributed to users saying Vista felt slow - on Win7, all the same animations are there (so it's just as slow on the processor/graphics card), but many are shorter.
OTOH, the new google.com features things fading in, and google image search now features lightboxes. So the trend is going both ways.
To summarize, animations have two strong effects on brain that you can use :
Reduce cognitive load : They allow the user to see what happened between two states, so it's brain don't have to "fill the gap". This make the user feel everything is more clear and easy to use --> Make extensive use of animations for transitions (cf Apple software)
Catch user attention : Human are really good to detect movement at a place they are not directly looking at. This is done thanks to our rod cells, the cells used to detect movement, which are really dense at the outer edges of the retina (must have something to do with survival in hostile environment) --> Use animation if something really important happened at a distant location.
This effect are very strong because they are directly connected to our reptilian brain. Powerfull and dangerous at the same time.
You have to ask: does this animation help the user figure out what's happening? I turned OS X's genie effect off immediately, but I appreciate the simple minimise/restore animation because it's fast and gives an extra clue to what just happened. Likewise with Spaces/Exposé. Or maybe it's a short, simple, soft fade transition that makes something appear less abrupt and more human.
Then again, a little flair can be your trademark, like the 'Lucas wipe' from Star Wars.
When making animations for a web/native app, I always take the github approach, of sort of almost "distracting the user" for half a second, while the content is loading. Find the slowest parts of the application (esp. the parts where you push a button and for a good half second, it seems like nothing is happening, and find some way to do an animation, this is to minimize frustration for the user ("I pushed the button but nothing is happening"), please note that I don't mean a rotating loading wheel, or some kind of loading animation, I mean like a sliding animation or something of the like, to create the illusion of a slick, fast UI, (see: https://github.com/github/linguist any time you click something there is this slide animation that makes github seem super quick and smooth), please note do not overdo this (using this technique on parts of your apps that take >500 ms) I feel like 500 ms, is the magic number, but experiment and find yours.
Animation has a purpose, and that purpose is visualing changes in state.
It's easier to grok when you think about declarative animation such as the kind present in modern CSS as put forth by webkit. In this context, you specify how elements look in a certain state, and then tell CSS how they look in a different state. How do you specify states? With CSS rules, such as class names and id's. So for instance (and forgive me for using code here!):
.myBox { width: 100px; height: 100px; border: solid 1px red; -webkit-transition: linear .3s; }
.myBox.open { width: 100px; height: 120px; border: solid 3px red; }
What we're describing here is a box that opens, and we're telling the code how to animate between the two CSS rules. This makes them states, and when you realise that, applying animation to your app suddenly becomes much more logical. Instead of thinking in terms of what animation goes where, you're seeing animation as a byproduct of state changes; an indicator that something has happened or feedback to the user that a change is taking place.
When I learned to differentiate between pure "animation" (from a programming standpoint) and "state changing" (from a declarative standpoint), it made all my UI designs much more solid and logical.
If the competing app uses animation, you need to use animation. If the competing app does not have animations, the need is left as an exercise to the reader.