Last week at RIAPalooza a number of the presenters mentioned the use of animations in the design and development of RIAs. No one got very specific, but nearly everyone agreed that some amount of animation was helpful in assisting users with cues on how to use the application or letting them know that they have affected something. In general, I would agree. In my opinion, before you go off and idly start animating those widgets or state changes, though, it would pay off to think through the applications design and goals and make sure that those animations streamline the user experience, or in some other way ease the use of the application making it more pleasurable to work with. Read on for some helpful tips to consider.

Nearly every RIA development framework out there has some amount of built in or easy to employ animations, whether it be Flex’s effects, states and transitions, a JavaScript framework like JQuery Interface or Prototype with Script.aculo.us, or Silverlight’s XAML Storyboard animations and the Visualstate manager, you can find toolkits that will assist you in creating optimized animations, many complete with easing and callback functions. Additionally third party libraries like Tweener can often be integrated into the application as slightly more powerful or easy to use replacement for the built-in animation classes if needed.

Additionally, with today’s powerful CPUs, optimized playback virtual machines and JavaScript parsers, the processor load to display these relatively simple effects are usually inconsequential to the end users machine. Of course user experience design rules ultimately call the shots, so if moving a few dozen widgets, etc. on the screen is causing lag or slowdown, perhaps you should reconsider what you are doing to the user and scale back your aims.

Some simple stylistic things to consider for typical animation types or common transitions:

• Think about the message you are trying to get across. What are you trying to say? Use the message as the guiding force behind the choice of the animation type. Are you asking for confirmation of a choice? Are you displaying feedback? Each different case will point you down a different animation type, style or path.
• When displaying application progress: notification on progress during sign-up or an upload process may be signaled via a sliding bar across the menu/breadcrumb area. Or maybe the entire application canvas moves from left to right when you progress through steps. The direction of the animation matters.
• When needing the user’s immediate attention or scrutiny, perhaps a quick bouncing action or pulse is appropriate. Think about OSX’s Dock or the pulsing Aqua buttons. A bounce to illustrate a change in a datagrid’s cell value would probably not be best served by this sort of animation, likewise, a change in a label or textfield would probably be tacky if bounced. Like the blink tag of old, the yipping, jumping dog-like bouncing icon or butotn can get pretty annoying, so use this sparingly.
• Fade in/outs can be a subtle way to introduce new elements on the canvas. The subtlety can be lost in the UI noise sometimes with this, however, so combining this with container expansion animations or color changes can often enhance the effectiveness of this stylistic choice. One of my favorite ways to use the fade out is to flash a user message up the displays confirmation of a submit action, then after a predetermined amount of time, the message fades away.
• Blinds and wipes can often be used to supplant sliding movements, but I think a great way to use them is when you are revealing new information that is less about the “progress” that you are making through the application, but rather about the application designer choosing to reveal new information to the user via a distinct path or mechanism. Again, like the bouncing icon, this George Lucas like transition should be used sparingly.
• Shakes or wobbles can be used to let the user know they have failed at authentication or entry of specific data needs. OSX’s login window does this, but it could easily be applied to any number of other similar scenarios where the user is unsuccessful at adding an item to a shopping cart or the like.
• Shrinking and Expanding is often used to signal the addition or subtraction of elements from the user’s view. Dynamically populated lists may have backgrounds that expand or shrink behind them to direct attention of the user to area that is changing. Some things I keep in mind when shrinking and expanding areas is to respect the bounding area formed by the background or item container. I never add items to a list before the expansion is far enough along that no items will appear outside of the bounding box, conversely, I never shrink the container prior to removing list items so that they will not break the bounding area.
• When simple UI widget movement, scaling or color changes won’t do, sometimes actual animations must be made by the designer. Loading indicators, branded UI elements, spinners, etc may not be readily accessible in a environment like Flex Builder or Visual Studio, so it would behoove the developer to call on a proper animator or designer to create these custom elements. Let’s avoid the programmer art, ok?

Of course there are many many other types of metaphors and animations that could be employed, like use of 3D, or blurs, other graphic filters, etc. But each of those could probably fill an entire post themselves. Again, subtlety and a respect for the message and user experience should guide you in you design decisions.

Beyond proper aesthetics, of course, you know, what looks good, what feels right, etc., there is a fantastic white paper that was written in 1995 available at Sun’s developer center that every developer should read. Written by Bay-Wei Chang and David Ungar, “Animation: From Cartoons to the User Interface“. It’s definitely worth the read. Any paper that starts out with a quote from Chuck Jones, arguably one of the best pure animators that ever has lived is worth a read. Principles of animation like solidity, motion blur exaggeration and other common things you might see in the Saturday morning lineup are explored, with lots and lots of diagrams and storyboards.

The brilliant part of the paper is that in 1995 many of the things they spoke of simply weren’t possible due to the relatively low power of graphics cards and CPUs and the dearth of available animation libraries or user experience design toolkits that allowed for design of rich or graphically appealing UIs. Largely now, though, these obstacles have all been overcome, and the developer and designers can work together to create engaging immersive applications that inform the user on state changes and data retrievals in effective, user friendly ways.

Posted on June 7, 2008

Name (required)

Mail (will not be published) (required)

Website