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.

Advertisement