Pros and cons of animations in user interfaces

by Karel Thönissen

Use of colors, sounds, animations and sometimes even transparency give user interfaces a slick appearance. However, many applications use these techniques for no apparent reason. In our Tarn-project we live by our mantra 'Powerful. Simple. Robust.' So if these techniques make the application more user-friendly, then we will not avoid them. This is simplicity for the user. However, we will never use these techniques if it does not bring the user anything. That keeps the code simple and helps us to achieve the desired level of robustness. This way everything in the user interface has a function. It is the software equivalent of 'less is more' and 'form follows function'.

Let us look at the use of animation in user interfaces in detail and see what the pros and cons are. Color, sound and transparency will be dealt with in a future posting.

Use of animations has a large number of drawbacks. Animations take considerable CPU-power, which is a problem on loaded systems. Running animations over a network connection is even greater fun. We want our applications to be performant whenever possible. Animations are tightly connected with the display system, and are, therefore, platform-dependent. This makes it difficult to port this code to other platforms, or even to older versions of the same platform. Another problem is that animations sometimes take time from the user. Fade-ins, fade-outs, half a second here, half a second there, the overall effect is that the system is no longer snappy. Even if summed over a life time this probably does not add up, but the slightly too slow response makes it impossible to enter commands and key taps at a natural rate. Instead of being able to interact with the system at full speed, flow is interrupted and the user must pace his commands. Psychologically, this makes it much harder to internalise command sequences. That is an important loss, because once commands are internalised, the user can issue the commands unconsciously and use his mental efforts for higher-level tasks.

The most important drawback is, however, that animations are hard to program. They take valuable resources from the development organisation that could have been spent elsewhere in the project. I am not suggesting that animations are harder than certain algorithms one may have to use for the application, but certainly harder than the alternative: no animation at all. And code that is harder than strictly necessary, also contains more bugs than strictly necessary.

With these strong points against it, we use animations only when they add to the user experience. Now it is time to see under which circumstances that can be the case.

Animations attract attention. This can be a good thing or a bad thing. An excellent example of very simple animation done right is the blinking cursor. It catches the eye, so that the user can easily find the insertion point in a text editor. However, for the same reason, animations are a bad idea if they are shown by windows that do not currently have the users focus.

Another place where animations really add something is animated moves. Some user commands make that objects automatically go to other locations in the user interface. Without the animated move of the object, the novice user would not understand where his object has gone. An fine example of this is when minimising a window to the task bar or restoring it to its original position. The animation instantly tells the user where the window has gone without the need for additional user interaction. The animation helps the user to build his mental model of the application. It is an experience lifter.

Similar to this is the use of animations to show time-outs. Fade-outs, for example, can be used to show the user that his time to interact with the widget is running out. Time-outs are a good option for simple dialogs that have a reasonable default. This way questions that would otherwise halt an unattended session can continue. Another very useful application of timed-out dialogs is for providing transient feedback, i.e. feedback that is only relevant when given to the user immediately after an event, not later. Such a transient dialog can be used for telling the user about certain input errors. For example, if a user enters the wrong password in a log-on screen there is no point in providing a dialog that must be clicked away by the user. Tell him instantly, and let him continue immediately without having to click away anything. What is the point of telling the user that his previous attempts failed a day earlier? Since the user by now will have forgotten what he did in the log-on screen the day before, the modal dialog is just an inconvenience. Just let the user re-enter the password and forget about the past.

Animation is often used to provide progress information. If the application is busy with a computation, then an animated egg timer or something similar is a good idea. It attracts the attention and tells the user that he does not have to look for the blinker. Unfortunately, some progress indicators are over the top. Progress indicators should do just that, not entertain the user. If the command takes really long, the user will entertain himself by petting the cat, reading a book, or or doing some administration. A large animation on front of his eyes now is very distracting. The same thing applies to progress indications for side tasks: keep them to a minimum, because they distract the user from his current main task. Beware than blinking animations are much more distracting then simple linear progress bars.

In the Tarn-project we try to keep complexity to a minimum and we only add fancy UI-techniques when they make the application better from a usability point of view. Animations for actions that do not last substantial time, animations for widgets that are positioned in the focal area of the user already, and animations that tell the user that he just issued a command himself, do not belong in this view.

Next time I will explain our position regarding the use of color, sound and transparency.