BE Teck Notes Back to be-teck.com

4 min read

Capitals are a contrast, not a volume

One line of styling put a whole application into capital letters. It read as deliberate for about a week, and after that it just read as shouting.

Somebody asked for the interface in capitals. It is a reasonable thing to want. Capitals look decided; a screen of them looks like it means business.

It shipped as one line of styling on the page body, and that line inherits into everything inside it. So the application capitalised its labels, which was the idea, and it also capitalised task titles, descriptions, comments people had typed themselves, names, error messages and empty states, which was not.

For about a week it looked deliberate. Then it just looked loud.

What it cost#

Capitals work as emphasis only while most of the screen is not capitalised. Emphasis is a difference, not a property. Spend it on everything and there is none left over for the four labels that genuinely needed it, and the screen arrives at a strange place: every element is shouting and nothing stands out.

The second cost is not a matter of taste. We read words by their shape. The tall letters and the ones that hang below the line give every word an outline your eye recognises before you have finished looking at it. Capitals are all the same height with flat sides, so the outlines collapse into rectangles and a capitalised sentence is read closer to letter by letter. That is measurably slower, and it is worst in bad conditions: on a phone, outdoors, in sunlight, which is where a great deal of this particular application is used.

How it was noticed, which is the interesting part#

Not by a complaint. Nobody in the building said "the type is tiring". People almost never say that, because nobody experiences reading as a task they could have an opinion about.

It was noticed by comparison. Two screens were put side by side, built in the same palette, and one of them looked expensive and the other did not. The difference was assumed to be the typeface. It was not the typeface. It was case.

That is the usual route for this class of problem. It does not arrive as a report. It arrives as a vague preference for one thing over another, and the work is turning the preference into a sentence somebody can act on.

Writing the rule down as data#

The repair could have been a comment in the code saying what capitals are for. A comment agrees with itself for ever and stops nothing.

Instead there are now two lists: what capitals are for, and what may never be capitalised. The second list is the one that matters — a person's name, a proper noun, anything a human being typed. Written as data rather than prose, a checker can execute it and refuse a change that breaks it. Written as a paragraph, it would have survived exactly as long as the memory of the argument that produced it.

Then the blanket rules were separated by what they actually govern:

  • A chip and a field label keep their capitals. Both are short names for a slot, not sentences.
  • A button lost them. A button's text is a verb somebody reads and then acts on.
  • Navigation labels lost them, which is why the menu had been shouting the name of every page even though those names were written in ordinary case in the code.
  • A section heading lost them, because a heading is a phrase.

The catch that nearly shipped a regression#

Of the application's table header cells, 129 out of 138 carried no case rule of their own. For as long as the blanket rule existed they never needed one. So deleting the blanket would have quietly un-capitalised every column heading in the application, which the newly written rule says should be capitalised: a column heading is a short name for a slot, the clearest case there is.

This is worth generalising. A blanket rule does not only apply a thing. It hides which places were depending on it. Every site that stopped declaring its own intention because the blanket was covering it becomes invisible, and stays invisible right up until the blanket comes off. Removing one is a survey, not a deletion, and the survey is the whole job.

Where we deliberately did nothing#

The screens at the gate were left exactly as they were. Their signage is pictograms, very large tabular numerals and Devanagari, none of which capitalisation touches at all. They were built to be usable by somebody who reads neither English nor the interface language, so they never leaned on capitals in the first place and had nothing to lose.

It is worth checking for that before a sweep. The screens that need protecting from a change are rarely the ones you expect, and some of them turn out to have been immune the whole time, for reasons that were good ones when they were built.

The shape#

The instruction was right. The implementation was one line too broad, and the whole cost sat in the scope rather than the intent.

The wider lesson about blanket rules — that removing one is a survey rather than a deletion — is in a default is a decision somebody made once. And the gate screens that were immune to all of this are the subject of a gate register somebody will actually keep.

That is a very common way for a small change to become a problem nobody can name. Everyone agrees with what was asked for. Everyone can see the result is somehow worse. Because the request was granted, there is nothing obvious to complain about, so nobody does, and the screen stays tiring for a year.

Have a gap worth closing?

If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear.

Write to hello@be-teck.com

More notes