Typography tips for software developers
Type is what meaning looks like
Max Phillips
In the beginning, there was the HTML code. Whiteness was over the surface of the browser window, and some black characters hovering over it. And the web developer said, “Let there be CSS,” and there was color, shape, and size for the characters. The web developer saw that CSS was good, but that was because he wasn’t aware of all the implications linked to each one of the typography choices.
Because typography is not only about fonts that look nice. It’s about aesthetics, legibility, accessibility, and semantics. An only bad typographic choice may spoil all the work on a website, while a carefully planned typographic design will make it shine.
But, let’s settle some definitions first to establish a common soil:
According to Wikipedia, Typography is the art and technique of arranging type to make written language legible, readable, and appealing when displayed.
Some of the elements involved in the typographic design of a website are:
- Typefaces: font families, size, and weight of each glyph (character).
- Color: of glyphs and also the background against which are rendered.
- Leading: space between lines.
- Tracking: uniformly adjust the space between all characters.
- Alignment: usually left, right, justified, or centered.
- Length (number of characters) of paragraphs lines
Those elements correspond to specific CSS properties that have default values set by the user agent stylesheet, or a combination of them.
Why developers must care about typography?
Software developers create digital products that, in most cases, have a GUI (if we are creating an application) or content presentation (if we are crafting a corporate or informative website). In both cases, text will be used, that must be perfectly legible, accessible, pleasant to read, and coherent with the overall design.
“But in my corporation we have a designer that takes care of this kind of things”. Well, congratulations, because not all developers have that privilege, and some of them have to take their own design-related decisions. And even having a designer, he probably won’t deal with CSS definitions and accessibility requirements. As front-end developers, we may not be responsible for specific design choices (although is advisable to at least know the reasoning behind those choices), but we do are for implementing them in a graceful and user-respectful way, and we need some typography knowledge to do it successfully.
How to make good typography choices
When the developer starts giving specific values to those properties to apply the desired design (that maybe doesn’t even exist, but emerges iteratively with trial-and-error), every decision (a change in the font family, make a text bigger, some color adjustment…) should comply with the following rules, sorted from more to less important:
- Legibility: the choice won’t reduce the general legibility of the text.
- Accessibility: the choice won’t reduce the legibility of the text for specific users with some disability.
- Coherency: the choice will preserve the semantic, functional, and aesthetic coherence of the text with the rest of the UI.
- Aesthetic: the font won’t make the overall perception of the website unbalanced, unpleasant or annoying.
It is not difficult to see what those rules are based upon: communication. Glyphs are the vessels used to send our message, and typographic choices may affect directly their capacity for fulfilling this goal.
Let’s review in detail some specific choices and which details and parameters we could pay attention to:
A good font family
In short, a font family, or typeset is a collection of fonts that share some geometric and stylistic attributes. Helvetica is a font family, whereas Helvetica Back Condensed Oblique would be a particular font within that family.
There are thousands of criteria that can be used to choose between the myriad of commercial and free available font families out there, but there are some that have a great impact on the legibility and clearness of your paragraphs:
- Legible in a large size range. Don’t forget to test your font of choice in mobile devices, using the smaller size you are going to use. The text must be still completely legible.
- Distinguishable characters. What about “i” (the vowel), “l” (the consonant), and “1” (the number)? Do they look the same in your font? Then, maybe you must reconsider it, or you may sacrifice legibility in some words like “Illusion” or “Illustration”. In some cases like codes (“level l1”), it can be even worse.
- Available in all needed weights and variants. If you are going to use different weights (light, normal, bold, black…), ensure that are supported by your font, and although most browsers can convert any font to italics (faux italic), it will look much better if is supported by a specific font variant.
- Undisturbing, discrete and pleasant. Fancy fonts may look great on certain designs and placements, but paragraphs must use “boring” fonts that are comfortable to read.
Of course, most of those requirements can be relaxed on titles and heading, but be careful with large bodies of text.
Serif vs. Sans-Serif
There is a traditional discussion on the legibility of the two great categories of font families: Serif and Sans-Serif. Many designers dogmatically state that you must use serifs for printed media, and sans-serif for digital screens (that is, web and apps UIs)
Although it would have sense in the times of crappy CRT monitors that didn’t render properly the serifs (and even at that time, that was relative) the quality of current visualization hardware removes that criterium, as explains the guru of usability Jakob Nielsen. Actually, his UX research group made a study of the fastest to read fonts (that is, more legible), and both families can be seen at the top.
So, don’t worry about serif and sans-serif: you will find excellent and very legible fonts for your website in both families.
The perfect line length
According to this study by the Maynard Institute, the ideal number of characters in a line is between 50 and 75. There are objective reasons for those numbers:
- Lines with lots of characters make it harder for the user to focus on the text, and also may difficult positioning rightly to the next line.
- Lines with few characters force the user to “jump” from one line to the other more times than he/she is used to doing, breaking the reading rhythm.
In the case of mobile versions, probably it will be limited to the number of characters that fit the reduced width of the viewport.
The perfect font size
It’s not easy to set the right font size for an application. Many authors suggest using 16px but, of course, this may result in different optical sizes depending on the screen density and the device (in smartphones, a pixel is not a pixel), and, moreover, two fonts may have apparent different size for the same size value. Maybe that’s why accessibility and study groups like the WCAG group or ADA don’t explicitly ask for a particular font size value.
But always think that, in addition to visually impaired users (that may be more than what you think), sight gets worse with age, and seniors must be able to comfortably use your application.
My personal suggestion is that, in general, do not make them look smaller than the default font size of your target device. If you want to make it bigger than this, please do, but always follow the good old common sense.
About CSS font size units
There is an endless discussion between designers and developers about what unit to use when setting a font size in a CSS declaration.
Let’s review the most typical size units:
pt is an absolute unit based on typographic points (72pt = 1 inch)
px is an absolute unit based on screen pixels.
em is a relative unit based on the font-size of the current element (i.e its div). 2em means double what the regular font size in this element would be.
rem is a relative unit based on the font size of the root HTML element.
To guarantee a minimum level of accessibility, it is suggested to avoid absolute units as much as possible, to make it easy for users and devices to make fonts larger gracefully, for example, for visually impaired users.
Many front-end developers rely on the browser’s default font size and they just adjust this size between layout elements using rem units. This makes it very easy to create themes with different font sizes, and is considered a good accessibility practice.
You can read more about accessibility and font size units in this article.
Do we really need to justify it?
Can you please justify it? It’s more elegant that way. I heard that a lot of times from costumers applied to paragraphs of text.
Let’s remember what we are talking about:
Putting personal preferences aside, there is a clear reason to choose left-aligned text (or right-aligned in the case of RTL languages): to justify a text, the text rendering engine (that part of the software that actually paints the characters on the screen) must add extra space between words. In some extreme cases, that space can make the text really weird:
Those artifacts can be minimized using hyphens (the dash with which we split words), but apart from the fact that some people are annoyed by it, it could be difficult for the rendering engine to properly split the words.
A game of fonts
We have reviewed several typographic criteria to choose a font and some of its attributes within a text body. But, what about combining fonts?
Hierarchy
The level of importance between the headings of the document must be reflected by the typography. First level headings font must be more prominent than second or third level headings. The obvious resource is the font size (highest font size for the first level headings), but be careful with other attributes of the fonts: if a second level heading is only slightly smaller, and its weight is way bigger, we could have a confusing hierarchy in which we are not sure about the levels of the headings.
Contrast
A nice way to imprint style and some eye-catching to our document or design piece is to assure that the different fonts have some degree of contrast. For example, we can use Serif fonts in first level headings or the document title, and sans-serif in second level or the subtitle. We can also combine different fonts of our font family, introducing variations in font weight or other parameters.
Font count
In general, unless we are doing some kind of complex piece of graphic design, it’s not a good idea to use more than 3 fonts in a document: two for the titles or headings, and the paragraphs font.
Fonts and bytes: file formats and what to use
There are three typical file formats in which font files are usually distributed:
- True Type (.ttf)
- Open Type (.otf)
- Postscript (.pfb, .pfm, .afm and others)
Most fonts are distributed using TTF, OTF, or both. They are very similar and have better compatibility than Postscript. Open Type, however, has some additional advantages over True Type:
- Has better cross-platform and weird characters support,
- Generally has less size
- Can be digitally signed
So go for this file format whenever possible.
Putting all together
As we have seen, typography is way more than nice fonts. It’s one of the pillars for successful user interaction with our product. Even when the specifications are provided by a designer, we are the ones that will transform their prototypes into a living product, and in this process, our knowledge about how a textual message is transmitted and perceived by the user will be crucial.
To summarize everything, let’s not forget that, as in all the decisions we make when designing and implementing our product, the user, its intentions, and his/her satisfaction when using it must be our priority. Every designer and front-end developer can have their own approach to this goal, but, as a suggestion, those are my guidelines to achieve a nice typographic design:
- Adjust sizes to make sure that all text is legible for all of our users.
- Adjust spaces and alignments to make sure that all paragraphs are pleasant to read.
- Choose font families to make sure that all glyphs are beautiful
