AHA before components
Components are useful for avoiding repetition while drawing a typeface—particularly once you are far along, are in an “execution” stage of the project. If not, they can also be a distraction, where incomplete ideas are abstracted too soon.
I think type designers face this question fairly often, but software developers certainly talk about it more. Managing abstractions is a big part of what software development “is,” so there are many terms and acronyms in the field to discuss this topic, like:
- DRY (Don’t Repeat Yourself)
- WET (Write Everything Twice), considered the opposite of DRY, often used as a criticism for not “being DRY”
Almost all typeface design programs offers some concept of “components,” with the intent that a single vector drawing can be maintained in one location, and reproduced in multiple locations.
In Latin typefaces, the most common use case is for diacritical marks. In most typefaces, the diaeresis drawing is going to be the same for the ë and the ÿ. To make this DRY, a single diaeresis drawing would be in both glyphs.
Immediately, you are into questions of abstractions: is the diaeresis simply two diacritic combining dot above marks, like in ė? Should the diaeresis component actually be two dot marks? Is that actually the same as the tittle over the i and the j, and should those also be made up of components?
These are useful questions to be asking—as long as you are at the right point in your project.
Some programs, like Glyphs, have an even more advanced concept of components, which have their own sub-settings. Glyphs calls these Smart Components.
They are powerful, and the promise of them is also enticing, because you get the impression that you can build out your entire typeface, with even less surface area.
But now, you have (even more) questions of when to abstract things. These two crossbars are the same thickness—shouldn’t they be a Smart Component with an adjustable width?
You don’t have to go that far down this path until everything is nested, and few glyphs are a single drawing.
I was falling into this component trap around the time I attended TypeParis. There, lead instructor Jean François Porchez more-or-less told me to pretend this feature did not exist during the course.
It was good advice: in a ~5 week program where you are iterating rapidly, there is no need to make these kind of abstractions. I needed to “Optimize for change first,” as Kent C. Dodds puts it in his article on this topic for software developers. Instead of DRY or WET, he suggests considering AHA:
AHA (pronounced “Aha!” like you just made a discovery) is an acronym I got from Cher Scarlett which stands for
Avoid Hasty Abstractions
The way I think of this principle is beautifully described by Sandi Metz who wrote:
prefer duplication over the wrong abstraction
While components might be amazing for, say, a CJK typeface with a firm design and maintenance concerns, they might be a distraction for a Latin typeface still in the conceptual stages.
Until next time,
Kenneth