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

Alpine, Message-IDs, and error handling / Follow-up: Undue checks of values

In an earlier text, I wrote of Alpine mishandling a default email address, resulting in

But what happens? If I begin to compose an email, the “From” field is just filled with INVALID_ADDRESS@”.SYNTAX-ERROR.” (quote signs present in the original), presumably to indicate its dissatisfaction with the missing user name. The actual value entered by me is neither visible nor retrievable and there is no reasonable world in which this is a good reaction.

While I have long ago removed this configuration (which Alpine should have been able to handle, but was not), the issue was reintroduced during my various notebook adventures and reinstalls earlier this year. (I do not know how.) Until now, I had not taken the time to re-correct this annoyance—but was, today, met with an unexpected email rejection when I tried to send an email to my father, who unwisely* uses a gmail account.

*He has to be forgiven, being simultaneously (a) a non-techie and (b) in his 70s. Most other gmail users have too few excuses for choosing this user hostile spy tool. (However, note that gmail, to my great surprise, was not the guilty party with the current issue and/or not the primarily guilty party, depending on how strict and what checks of Message-ID format are recommendable, which is a matter of debate.)

Doing some searches based on the error message led me to [1] and the claim:

Google.com mailservers check whether messages contain the Message-ID parameter and whether it has correct syntax. Otherwise messages can be rejected with the error “550-5.7.1 Messages missing a valid messageId header are not accepted.”

Inspecting the actual headers of the email that I sent, I found a Message-ID, looked closer, and spotted a @”.SYNTAX-ERROR.” … Speculating on the cause, I re-altered the configuration field—and a second attempt was successful. (And now the Message-ID did contain my actual domain.*)

*In my impression, specifically a domain is not needed; however, it is an easy way to ensure consistency and to reduce the risk of collisions with automatically generated Message-IDs from other senders, and it makes sense to use specifically the domain of the sending address for this purpose.

This is another inexcusable mishandling on at least three counts:

Firstly, all that the Message-ID needed was the domain, and the domain was most definitely present.

Secondly, Alpine failed to give any meaningful notification that there was an issue.

Thirdly, Alpine should have used the domain of the actual eventual sender address (per “From:”), not the pre-configured default, as a manual edit (of even a correct and correctly displayed address) might have brought on a change of domain, say because a user has several domains (I do). Moreover, if (!) the domain is read from configuration instead of actual value, then the separate configured value for the domain would have been a more natural choice.

In addition, one might argue a “Fourthly”: Alpine should have detected any syntax or other error in the Message-ID on its own and notified the user.

Amateur hour!

Excursion on the underlying issue:
In my original text, I speculated that

[…] this is not so much a deliberate choice as poor programming, that there is an internal consistency check when retrieving the [configured] value, that this check gives an unnecessary error message, and that the error message is blindly taken over as the value.

The above issue strongly indicates that this is indeed the explanation. Again: Amateur hour!

Undue checks of values

A common annoyance with poor software is undue intolerance against values that are, in some sense, faulty. (And, no, this is not a post about the political Left …)

Checks for correctness and consistency can be a great aid, as can automatic warnings of errors. However, often, the baby is thrown out with the bath water.

Consider e.g. Alpine, an email client that I use extensively: It has a field in the configuration to specify the default sender address. Here I have simply specified “@” and my domain because I use a great number* of different user names for different tasks (mostly to reduce the damage when one address falls victim to spammers). The idea is that I have this string pre-filled in the “From” field and then just need to add the right user name.

*Too many for a solution using e.g. Alpine’s role system to be a good alternative.

But what happens? If I begin to compose an email, the “From” field is just filled* with INVALID_ADDRESS@”.SYNTAX-ERROR.” (quote signs present in the original), presumably to indicate its dissatisfaction with the missing user name. The actual value entered by me is neither visible nor retrievable and there is no reasonable world in which this is a good reaction. A check when the user attempts to send, by all means, but not when a default value is retrieved or entered. If there are objections to the default value, they should be uttered when and where the default value is configured;** however, here such objections are not reasonable, as use cases like the above are quite common.

*The actual field. Contrast this with keeping the “faulty” value and displaying a warning message next to it. (Which also would have been acceptable.) Writing this, I begin to suspect that this is not so much a deliberate choice as poor programming, that there is an internal consistency check when retrieving the value, that this check gives an unnecessary error message, and that the error message is blindly taken over as the value.

**This is not the case with Alpine. The explanation might be that the the entry mask deliberately has a tolerance that is later arbitrarily removed, or that this config value is part of a larger string, which is not parsed or verified at the time of entry.

The result is that I have to delete the error message, write the user name, and copy the remainder of the address from elsewhere, i.e. one step more than without this configuration and two steps more than if it had worked reasonably. Time to remove it …

Of course, these extra steps occasionally lead to errors. For instance, when I use post-by-email with WordPress, I usually just “reply” to the last post, switch out Subject and Body, and re-enter* the email address. But today, with the three steps needed for the email address, I forgot the Subject and published a text under the same title as the previous (entirely unrelated) text …

*No, Alpine is not smart enough to handle replies to own messages correctly, i.e. that the old address is kept. Instead, the configured one is used (if present, else the field is, probably, empty).

Other examples include e.g. applications that prevent any entry of faulty information, even without saving*, e.g. that a numerical value using a decimal point is not allowed in a German application expecting a decimal comma. Then, instead of copying a (read-only) value from a PDF file or output from a calculator into the field, changing the point to a comma, and then continuing, the user is forced to copy the value, paste it in an editor, edit the point to a comma, re-copy it, and then paste it in the field.** Or consider fields that allow entry of most, but not all, legal values or makes normally optional parts mandatory.***

*In many cases, even the saving of faulty values can be beneficial, e.g. that a numeric field can be filled with a “TODO”, and that the application merely gives a warning that the input is faulty. However, this is not always trivial and rarely worth the benefit, as it might require switching a numeric internal data type to a string data type or similar.

**Yes, this could be solved e.g. by some type of keyboard macro, but it is not a sufficiently common scenario to be worth the trouble—in stark contrast to writing a better functioning field that e.g. allows entry of any value and just shows a warning message or allows entry but not saving.

***I do not remember any of the specific cases off the top of my head, but consider, again, email addresses: These can be quite complicated, and e.g. a simplistic name-plus-@-plus-domain parser would disqualify many legitimate versions. Vice versa, an idiotic tool could make the idiotic display name idiotically mandatory.

Poor user interfaces / gkrellm and battery notifications

Even the world of software development, even in the Linux and “open source” areas, often shows such signs of incompetence that it boggles the mind. This in particular where usability and workflows are concerned.

Take what I just observed: I tried to activate the low-battery notifications in the monitoring tool gkrellm.* These are activated through a checkbox on one config page, with the actual configuration (what to do when) on another, in a pop-up—it self disputable, considering that there were ample space to put both parts on the same page. I opened the other page, filled in appropriate values, closed the pop-up, and checked the check box to activate the settings. What happens? I am alerted that the settings have changed and that I must now open the pop-up to enter information (I do not recall the exact formulation). As I re-open the pop-up, I see that the settings just manually entered have been arbitrarily restored to empty default values!!!

*I run my notebook attached to an electric socket almost without exception and normally have no need for notifications. However, recently, some type of glitch in the connection at the notebook-side has led to a temporary interruption on several occasions—and today I awoke to find that my notebook had ran its battery down and shut off during the night.

Not only is this an extremely user-hostile restriction on the workflow, it is also not communicated in advance, the reset of the values borders on the inexcusable per se,* and (with some reservations for the detail implementation) this could prevent one of the most obvious uses of the settings—to keep a constant set of detail settings that are activated or deactivated as the situation fits.**

*With few exceptions, values explicitly set by a user should never be changed automatically or as an unexpected side-effect of a manual action. A similar example is the cookie settings in Firefox: If someone allows cookies per the main option, chooses the sub-option to disallow third-party cookies (as he should!), and later deactivates cookies per the main option, then a later reactivation of cookies will also change the sub-option to allow third-party cookies, which is counter-intuitive, against the stated will of the user, and to boot a poor default setting. (Disclaimer: I have not verified that this mis-behavior is still present in recently re-vamped Firefox.)

**E.g. in that someone using a notebook on a daily commute might have them off (as an unnecessary disturbance, because he knows that he will arrive before the battery runs down), but have them on when otherwise working without external power.

Generally, gkrellm has a very odd and unexpected user interface, be it in the main product, the various plug-ins individually, or the various plug-ins compared to another. (The F1-key opens the configuration, not the help. Sometimes a mere click on a plug-in activates or deactivates a feature; sometimes it does not. Extra information is sometimes displayed when clicking minuscule squares with no functional identification. The configuration is usually poorly though-through. Etc.)