Some thoughts on software and animation

During my recent Firefox adventures ([1]), I stumbled upon an old (2009) page ill-advisedly suggesting a project to add animations to Firefox.

Considering the horror that animation is, it is disturbing with what seemingly sane and insightful attitude the project set out:

Animation in the browser is a tool, but not a goal unto itself. Wherever animation is used, it should be with a purpose and benefit to the user.

Like many web technologies, animation is a useful but easily abused tool. The early web and the dawn of the .gif format saw animation heinously overused websites, with blinking, spinning, and scrolling animations thrown in because they “looked cool.” As the web stopped foaming at the mouth and begin the transition to what could be done to what should be done, animation became used more successfully as a tool. Some ways in which animation can be useful include:

o Making browsing feel faster
o Adding visual affordances to makes tasks more understandable
o Making the browser and tasks more visually appealing

To bring animation to Firefox, we decided to first focus on three key areas that we felt would give users the most benefit by adding animation. Out of many possibilities, we looked for places where animation would make interactions feel faster and help users perform tasks.

The first paragraph is dead on—but exactly this is where seemingly every modern software and every modern website that uses animations fails. This includes Firefox. If the developers had actually lived this paragraph, Firefox would have had no or only minimal animations today. (I cannot quite shake the suspicion that this was an alibi-paragraph, so that the developers could establish “common sense on animation” credibility before going on to actually display a lack of common sense.)

The second is half right, as it describes a horror of old, but it then mistakenly assumes that things would be significantly better in the page’s now (i.e. 2009). This was not the case: Animation then, just as before, and just as in my now (i.e. 2022) was/is excessive and usually done more for the purpose of having animations than anything else.

(The list is discussed below.)

The final paragraph points to three areas where animations in Firefox would be an alleged good. As can be deduced from the rest of the page, these are “Tab tearoff”, “Text search on page”, “Movement of toolbar items within rows (UI elements, bookmarks, tabs)”. None of these, however, have added value as implemented. On the contrary, they are among exactly the type of things not to animate, because the result is annoying and distracting, often delays the action, and adds no value.

Looking at the list:

o Making browsing feel faster

In the case of e.g. a progress indicator, an hour glass, or similar, this might work to the degree that the user sees that the browser (more generally, application) is still working. Other than that, I have never seen a positive effect. On the contrary, I have often seen cases where the application has been made objectively slower by the introduction of animations, because continued work is not possible until the animation is ended. One example is the CTRL-F issue discussed in [1]. The maybe paramount example, and one of my own first major contacts with animation, was the slow-as-molasses menus of Windows 2000 and/or Windows XP.* This was at a time when gaining a usable command line in Windows was virtually impossible and programs had to be started by clicking through multi-level menus. I often “knew the way” and could have reached my goal with a reasonably rapid click-click-click-click. Instead, I had to click on the main menu, wait for an animated menu to slowly unfold, click on the right sub-menu, wait for an animated menu to slowly unfold, click on the next sub-menu, wait for an animated menu to slowly unfold, and then click on the finally visible program.

*This was long ago and I am vague on the details. I do remember that I soon found some type of setting to disable this shit—but this anti-feature should have been off per default or entirely non-existent to begin with. (As I repeatedly noted in those old days of heavy Windows use: if Windows has a toggable feature, the default value will be poorly chosen in two-thirds of the cases. This while a coin-toss would have been at just half the cases.)

o Adding visual affordances to makes tasks more understandable

(An “affordance” is “Any interactive control or component serving as a cue to the user to take some action.” according to Wiktionary. I have no recollection of hearing the term before yesterday.)

There might be some limited room for this, but not much, certainly none that applies to what I have seen in Firefox or what was suggested in the final paragraph of the initial quote, and I can think of few situations where non-animated hints would not be better, if in doubt due to the annoyance factor. Take e.g. a field to input a mandatory text combined with a save button. In a non-animated case, the button might be greyed out as long as the field is empty, and the field carry a note like “mandatory field”. In an animated case, we might end up with an animated paper-clip bouncing around the screen, with a speech-bubble “You must enter text in this field!!!”. (Or, in a less extreme example, there might be a big flashing arrow pointing to the text field.)

However, I suspect that a faulty application of this idea explains the CTRL-F issue: Some nitwit assumed that, without the animation, too many users would be permanently confused as to what to do after pressing CTRL-F, while the animation would provide them the insight that “Hey! There is a search field!”. In reality, this would apply only to a small minority of highly unskilled computer users,* who additionally are too unobservant to spot the fact that a search field has just appeared (as opposed to being slowly blended in through an animation), and would, even for them, likely only be relevant the first few times. Correspondingly, the benefit is minimal. The delay and the annoyance, on the other hand, hits everyone for the duration. Even if an animation were beneficial, this is a poor way to do it. A better way would be to just show the field and have the already present field flash briefly. The annoyance from the animation, per se, remains, but work can begin at once and the annoyance from the delay through the animation is gone.

*Effectively, someone who has minimal experiences with virtually any computer application, including other browsers, and simultaneously has minimal experiences with Windows/Mac without being a sufficiently proficient user to have moved to a more adult OS, like a typical Linux distribution. Of course, someone like that might be unlikely to try CTRL-F to begin with…

For a highly proficient user, however, any animation in this case is likely to be harmful as he is likely to (otherwise) just tip in the search phrase immediately after CTRL-F (resp. / or ? in Vim, resp. whatever keys the application at hand requires), without looking for a search field. Even without a delay, the animation can be problematic, as it screams “Look at me!” and might cause an artificial interruption as the user does exactly that. With a delay, depending on exactly how the delay is implemented, it might well be that the user is now tipping in vain, as the keystrokes are not registered by the search…

o Making the browser and tasks more visually appealing

I have no recollection of seeing this done successfully, anywhere, at any time, in any product with “everyday animations”.* On the contrary, this comes very close to using animations as “a goal unto itself”. When it has worked, it has been with more spectacular “major effect animations”,** as with the classic bouncing-card animation after solving a solitaire in Windows. However, even these grow old fast, and they are certainly not to recommended for frequent use in an everyday tool like a browser.

*Here I find myself lacking in terminology, but consider e.g. the CTRL-F animation or a tab-movement animation.

**Again, I am lacking in terminology, but the example given is likely to be explanation enough.

For my part, I used to work with the following informal rules (in the days that I had to implement occasional GUI-functionality):

1. Only add animations when they bring a tangible benefit.
2. If you believe that an animation will bring a tangible benefit, you are wrong in nine cases out of ten.

   (Where “benefit” is to be seen over the entire user base—not just the first one or two uses of a newbie. Note in particular the potential damage through delays and annoyances, as mentioned above.)

3. If in doubt, do not animate.

These rules served me so well that I cannot recall ever adding an animation (although I probably have—if in doubt because some product manager or whatnot was more naive and insisted).

If giving rules for someone else (which I implicitly am), I might add e.g.:

1. The main effect of animation, whether intended or unintended, is to call attention to something, with possible side-effects including interrupted work-flows, interrupted thoughts, attention diverted from where it really belongs, etc. Therefore, be very certain that you actually do want to call attention to whatever is animated.

   Corollary 1: Never have more than one animation in the same page at the same time.

   Corollary 2: Keep animations short. Once the purpose of getting attention can reasonably be assumed to have been reached, the animation must be stopped so that work can continue without distraction.

2. Beware the annoyance factor, especially during prolonged use. Remember that there might be some who use your product for hours every day.

   (See the earlier discussion for more detail.)

3. Keep the different proficiencies of different users in mind, and that the more proficient are more likely to be intense users and/or that intense users are more likely to become proficient. Do not tailor your application to your grand-mother. (Unless, of course, the intended target demographics is old ladies.)

   More generally, a good application might well make allowances for weak[er] users, but not in a manner that hinders strong[er] users. For instance, looking back at [1], making it trivial to connect the TorBrowser to Tor is good, but making it hard to by-pass Tor is bad. For instance, reasoning that “we do not need any keyboard short-cuts, because everything can be done by mouse” is hopelessly narrow-minded. For instance, to return to Firefox/TorBrowser, providing many ready-made keyboard short-cuts is good; making them near impossible to change is bad. An attitude of “A user should not need expert knowledge to use our application.” is laudable; an attitude of “If a user does have expert knowledge, we must prevent him from using it.” is despicable.

4. Any and all animations, without exception, must have an easy-to-find* switch to turn them off. In most cases, the default value should be “off”.**

   *The obscure, well-hidden, poorly documented, and often functionless settings in Firefox’s about:config are a negative example.

   **A problem with this rule is that many naive decision makers will reason that “The users would LOVE the animations, if they knew about them! If the animations are off, they will never find out; ergo, animations must be on!”. The premise of “LOVE”, however, is very dubious. As a compromise, an application might provide a “first use” dialogue where a few meta-decisions can be made, e.g. whether to have all animations “on” or “off” until a more fine-grained decision is made. (Similar meta-decisions might include whether to allow “phone home” functionality, whether (on Linux) to prefer Vi- or Emacs-style key-bindings, and similar.)

5. Clippy is the devil.

Clarification of terminology:
Note that I do not consider any and all change of a display to be an animation. For instance, if a menu immediately goes from a folded to an unfolded stage and then remains static until the next user action, this is a change in the display, but it is not an animation. Ditto a search window that immediately appears and then remains static. Ditto a link which immediately changes looks when focused or unfocused and then remains static. Ditto e.g. a mouse cursor that moves from point A to point B as the result of a continuous user action. In contrast, the Windows folders discussed above suffered from an animation. Ditto CTRL-F in [1]. An hour glass that turns for two minutes while the program is working is also an example of animation, but one much more legitimate.

Advertisement