Animation isn't equally appropriate everywhere

One of the most recurring arguments against the use of Flash for animation was its plug-in nature, which meant that the designer couldn't be sure that his creation will be seen by the user. Another argument was the waste of CPU cycles, which could quickly drain a battery on a mobile device. But what is often forgotten and may not seem apparent at first is that Flash was disliked by many mostly because of the way designers used it. It was used for animation effects in the web site's navigation; for ads that grew over the content; for games in which the mouse cursor had the role of a missile-upgraded battleship; for beautifully animated, sound-rich Christmas cards; for video compression with Sorenson Squeeze. Entire websites were Flash-based, and to some extent still are. There wasn't any question that Flash can do that and much more. Its power made it quite flexible, but also more likely to be misused.

Now we see CSS transitions and CSS animations coming and they are also starting to appear on more and more websites and devices. The good thing with transitions is that thanks to very knowledgeable people, they can be executed on the graphics card thus freeing the CPU for more general-purpose computations. But the fundamental question still remains the same: "Do we really know how to apply animation on the web properly? When is the turning point that marks its usefulness zenith?" Can animation be decorative, like a normal image without being of any particular purpose at all?

The author of an article that grabbed my attention with its skillful animations wrote that animation is all about timing and that it can prevent jarring. As an example, he presented a list of block-level elements, sitting on top of each other. He then applied animation effects like fade to add or remove new elements between the existing ones. The new elements were appearing and disappearing smoothly; there were almost no sudden movements or "jarring". What made an obvious impression is what happened at the bottom of the list once the new element was inserted or removed and the list height expanded or collapsed. The "jarring" has moved there and took the form of reflow and repaint! This is because no matter how smoothly an element on a list appears, it has to take its space on the screen, and the browser has to repaint all the new positions for all elements below it (which is why it is better to make DOM changes as late as possible in the layout of a page). If we wanted to completely eliminate jarring, then we would need to keep screen space reserved for that element before it even appears, but that would leave a hole in the list. Sounds very similar to how the CSS properties display and visibility work. display: none discards the space an element has previously occupied (leading to what is here "jarring"), visibility: hidden preserves it. If we aren't careful, we can easily introduce "jarring" in our designs—for instance when applying border only on a :hover pseudo-class of an element. We could animate the appearing of the border, but that wouldn't change the fact that it should occupy some pixels according to the box model.

Something else that caught my attention was the statement that "animation can be made functional". I do not entirely agree with that, even though I like animation too. If we think of something in motion that should be useful in some way, it will quickly become clear how tedious it can be for the end user to point with his mouse to something he doesn't know how it will behave two seconds later. Animation stands in the way of predictability in web design, which is a very strong argument against its random use. Very often, interface elements become almost unusable at the time their state changes. Correct, timing is important, but also for usability.

bit.ly/ZPGqCH