Like we tell our clients – just because you’ve redesigned your site doesn’t mean you’re done. You’ve simply launched your MVP (minimum viable product), and now it’s time to iterate and optimize.
With the Imarc website redesign this year, we had to take our own medicine. After we launched the new site, we stepped back and looked at our new blog. It was attractive and nicely proportioned, but we discovered that actually reading the posts felt slow and awkward.
Great typography is notoriously hard. Worse, it’s often subjective, despite attempts to quantify some elements of it. But we can break it down. Here are some issues we identified and how we fixed them.
1. Font Sizes
Our brand typeface, Gibson, is beautiful, but it isn’t optimized for the low-resolution displays most PCs still use. It has a small x-height, very tight eyes (the little spaces inside "e", "a", "g" and such), tall ascenders (like the top of a lowercase h), and minimal descenders (like the bottom of a lowercase g). These all combine to make the type look smaller than “font-size” numbers would make you expect.
Consequently, we found the new blog body text was small and not easy to read – despite what seemed like a perfectly generous type size of 18 pixels!
Since a CSS pixel (px) is defined as 1/96th of an inch, and there are 72 points per inch, our type size of 18px would be 13.5 point font. By the numbers, that should work, but it was skirting the edge of readability.
What we changed:
- Bigger text size. We increased from 18px to 22px (13.5pt to 16.5pt)
To learn more, see What’s the best font size for any device?
2. Vertical Rhythm, Line Heights & Inter-Paragraph Spacing
The subtle art of vertical rhythm plays a surprisingly large factor in keeping the reader moving down the page.
The spacing from line to line and paragraph to paragraph in our new blog felt … weird. For example, each line was 18px tall, the line-to-line distance was 37px, and there was 55px between paragraphs. Both our ordered and unordered lists also had extremely close spacing.
While you can go crazy defining a system of vertical rhythm, that's overkill. It's actually pretty easy to devise a simple system. And some variation can be nice, as Robert Bringhurst writes in The Elements of Typographic Style:
Headings, subheads, block quotations, footnotes, illustrations, captions and other intrusions into the text create syncopations and variations against the base rhythm of regularly [spaced] lines. These variations can and should add life to the page, but the main text should also return after each variation precisely on beat and in phase.
What we changed:
- More tightly leaded lines
- Consistent margins above and below section headers
- Consistent margins above and below lists
- Consistent margins between blocks of different media types
3. Line Lengths
Line lengths are often seen as subjective, but they’re not. We can measure reading effort by counting how many saccades (quick, short eye movements) are needed to read a paragraph:
- Longer lines make it harder to find the beginning of the next line. Researchers count an increase in saccades as the eye tries to orient at the next line.
- Shorter lines require tracking back to the next line more often. Again, researchers find more saccades.
Basically, very narrow and very wide lines both cause actual muscle fatigue. How neat is that?
So how do we find the optimal minimum of effort? Science! We have data from people who have measured it.
Recommended line lengths for ease of reading vary based on media, type size, and the reader themselves. Robert Bringhurst’s seminal (but print-centric) The Elements of Typographic Style advises 45–75 characters per line (cpl). The “average” English word is 5.1 characters long, so another way to measure it is 7–12 words per line (including spaces).
Novice readers benefit from shorter lines of 35–60 cpl. Expert readers more easily manage wider lines up to 80 cpl.
The Web Content Accessibility Guidelines are another widely referenced source. In their guide to Visual Presentation best practices, WCAG recommends that text widths be “no more than 80 characters”. Using the “average” English word again, WCAG recommends a maximum of 16 words per line. That’s much wider than the 10–12 words per line that typographers and book designers have long used, but closely tracks the US letter size paper. We’ll take that as the far outer limit on line widths.
Numbers now firmly in hand, we proceeded to measure the copy from a few of our blog posts:
We found they averaged 110–120 characters per line. Wow! No wonder we were finding them hard to read.
What we changed:
- We initially specified the body text column be 720px wide. (Had we not enlarged the text earlier, this would have needed to be even narrower. Everything in proportion.)
- We found in the browser that 750px gave the text a little more room, while still giving us a comfortable average line length of 75–80 characters (12–13 words).
4. Header Sizes
We had designed our section headers to contrast sharply in size with body copy across the site. This works very well for short text blocks. But in the blog this backfired. The level 2 and 3 headers were very similar in size. Unless the headers were near enough to each other to compare, it was hard to tell which was which. That made it harder to intuit the content’s structure.
We also found the headers to be distractingly large, and they felt disconnected from the content around them.
We realized we needed to reconsider the header sizes relative to the main blog body copy size, and to each other.
What we changed:
- More contrast in size between h2 and h3 headers
- More margin above headers
- Less margin after headers
Putting it all together
One of our designers took our findings and not only provided an updated design comp, but expanded it to include many kinds of additional content that weren’t in the original design.
Then we huddled up with a front-end engineer to fine-tune the in-browser design. For fun, see if you can spot the changes between the design excerpts above and the page you’re reading now.
The total time to address everything wasn’t small. It took three days of effort, with contributions from the UX, Engineering and Design teams.
The blog is a lot easier to read now. We hope you like it.
