Improve Your Web Typography with This One Plug-in
An Interview with Bram Stein, Senior Computer Scientist at Typekit and creator of the Typography Inspector
Bram talks about the philosophy behind his latest project “The Typography Inspector” and how he want’s to make it easier for people to make better choices when designing for the web.
Make new friends who love type just as much as you do.
Monthly meet-ups around the world where you discuss projects that focus on letterforms.
Los Angeles
New York City
London
San Francisco
Chicago
Seattle
Philadelphia
Combining Code and Type — Getting Involved with Typography
Ulrik Hogrebe: Bram, first of all I really appreciate you taking the time! I want to ask you about ‘type inspector’, and in that way get in to a broader conversation about type on the web — but first I’d like to ask you a little bit about your background and how you got in to the world of typography?
Bram Stein: You’re welcome, glad to be talking to you. My background is in software development, but I’ve long had an interest in type and typography. I started looking into typography about 12 years ago when I wanted to build a web-based eBook reader. My first attempt looked nothing like a real book. Browsers were very basic back then and had poor quality typesetting and limited layout capabilities. Browsers improved a lot in the last couple years, but they’re still far behind in typesetting.
So, I started implementing functionality in JavaScript. First I implemented the line breaking algorithm used in TeX and InDesign, then a hyphenation engine. Afterward, I realized I needed high-quality typefaces, so I started working on web font loading. At that point, the people at Typekit reached out to me and offered me a job. I’ve been working on web fonts since then.
UH: Amazing. And your job now is Senior Computer Scientist at Typekit. Is that right?
BS: That’s my job title, yes. I primarily work on making Typekit’s web font service quick and reliable. I’m also involved with web standards, as a member of the WOFF2 working group. It’s quite a fun job: I get to work on client side JavaScript, the backend, web performance, standards, and talk about type all day.
Ideally, you want to show the typeface, but you also have take into account that there is a cost associated with using web fonts.
Fonts, Performance and Why It Matters
UH: Sounds cool indeed! It’s always slightly mind-boggling to me how central you and people like you are to how we view the web today. Type is a huge part of any web experience and you guys are basically driving that development. For our readers, can you give a quick peek in to what the WOFF2 standard is?
BS: Haha, thanks. However, all credit should go to my amazing colleagues and friends at Adobe, Google, Apple, and Microsoft who work hard to make type and typography on the web better.
WOFF2 is a successor to WOFF, which stands for the “Web Open Font Format.” WOFF takes a regular OpenType or TrueType font and compresses it, so the font becomes smaller and downloads quicker. The WOFF2 standard improves the compression rate so that fonts download even faster. Google did a great job working on the compression algorithms so that on average WOFF2 files are 20–30% smaller than WOFF files.
UH: And that’s a huge deal really. Serving fonts on a browser; I guess we tend to take it for granted that fonts just load, but say you are on a dodgy connection, on your phone, trying to view a webpage — then performance really does matter?
BS: Making fonts smaller is a huge deal, but it’s only part of the solution. Most browsers hide text while web fonts are loading. In these browsers, text can be hidden for up to three seconds, even though the content is already there. So let’s say you’re browsing the web on your phone; in some cases you might have to wait up till three seconds before you can read the text. It’s just that you’re waiting for the web fonts to load. That’s crazy. As much as I like type, I visit most websites because I want to read the content.
And that’s on a reasonably fast mobile network connection I have here in Denmark; there are many areas in the world where people’s only access to the internet is over slow (and expensive) mobile network connections. So yea, there are a lot of challenges there. Ideally, you want to show the typeface, but you also have take into account that there is a cost associated with using web fonts.
Text is the smallest indivisible part of design. A design “atom” if you will. [Typography Inspector] will show you how body text reacts to changes in the viewport.
The Typography Inspector
UH: I guess the other part of the equation is display and how text looks on a screen. I was wondering if you can talk a bit about some of your projects in that space? Like Typography Inspector which you recently launched?
BS: Sure. Like you said, I recently launched the Typography Inspector. It’s very much an experiment. I don’t know yet if it will be a successful experiment or a failed one. The problem I’m trying to solve is how to design for the web. That’s a bit of a grand statement, but I’ll try and explain what I mean.
I’m not a designer, but I like to design things every now and then. When I do, I open up one of the many (web) design applications, and the first thing it asks me is to create a canvas. I always struggle with that. It’s the web; there is no canvas. We have a viewport, and it is fluid. I try to work around this limitation by creating multiple canvasses of varying widths, and then adapt my design for each. I suspect a lot of people do something similar.
This bothers me though. What happens in between these static snapshots of a fluid responsive design? I can try to create more canvasses to fill in the gaps, but that is more work than I’m willing to do, and it still doesn’t solve the problem.
I’ve been thinking about this for a while and often talk about these problems with my friend and colleague Tim Brown. At some point, we realized that text is the smallest indivisible part of design. A design “atom” if you will.
You can put text in columns of varying length, but at some point, it break downs. The text becomes unreadable if the lines are either too short or too long.
In between these two extremes, there is a range of line lengths that range from acceptable to good.
So I started looking for a way to visualize that, so I could try and build a canvas-less design tool. One where you design from the text out, instead of from the canvas inwards. The Typography Inspector is a small part of that. It’ll show you how body text reacts to changes in the viewport.
The inspector assigns a “score” to the line length and line-height of a paragraph. I’m hoping that these scores will provide hints that the text is under pressure: either stretched or squashed too much. Then you can go in and fix the pressure, for example, by adding a media query and limiting the column length, increasing the font size, or adjusting the line-height. Because the scores update live, you can see how the paragraph behaves at each width of the viewport by resizing your browser window.
UH: So it’s a tool that analyses your text at different breakpoints and helps you gauge if it’s legible? And do I detect elements of Bringhurst in your approach to type design in here?
BS: You can use the Typography Inspector to analyze text at different breakpoints, but I’m hoping people will also use it to find breakpoints. So, you can start off with a “mobile” viewport by resizing your browser window to the smallest possible size, and then gradually make the window larger until the inspector tells you there is something off with your typesetting (i.e. when one of the bars turns orange or red). That’s where you place a breakpoint.
There is definitely a “Bringhurstian” influence to the Typography Inspector. I’m not sure if that’s good or bad, but it appeals to me as an engineer. I have this theory about the science behind typesetting, and the Typography Inspector is an attempt to figure out if my theory is correct or not.
A paragraph consists of five properties: typeface, font size, line length, line-height, and hyphenation & justification. All of these properties are related; change one, and you probably also have to modify the others.
UH: Can you expand a bit on that theory? And how it relates to your background as a programmer?
BS: I’m glad you asked! I think most programmers enjoy finding logic and structure in something. I’m looking at typesetting the same way (which, again, may be a terrible idea — time will tell).
So, my theory is that the typesetting of a paragraph consists of five properties: typeface, font size, line length, line-height, and hyphenation & justification. All of these properties are related; change one, and you probably also have to modify the others.
But for now, let’s talk about line length. I think I can explain this best with an experiment. Let’s say you set the same text at different line lengths (see figure 1). Now, rate each of these paragraphs with a score of 1 to 10 (where 1 is bad, and 10 is excellent).
Make sure you view the picture at 100% zoom and try to ignore all other properties (such as the line-height, choice of typeface, etc.). You will probably end up with something like the following table and chart (See figure 2 below).
At the extremes, you have low scores, and somewhere in the middle, you have a nice curve. For some people, the curve may be a bit more to the left or the right, but it’ll still be a curve.
Of course, the location of the curve also depends on the width of the typeface. Wider or condensed typefaces will have the curve in a different place. My theory is that if you normalize the scores of different typefaces based on their width, you end up with a generic line length vs. score curve.
This generic curve is what the Typography Inspector shows. It visualizes the normalized line length score of your paragraphs as a range from red to green. Red means the paragraph has a low score, and green means it has a high score. However, instead of basing the curve on user input, it is centered around 66 (normalized) characters per line, which is what Bringhurst recommends for average paragraphs. But it still follows the same generic curve. You can clearly see the curve when I enable the Typography Inspector on the sample paragraphs from earlier. The inspector does something very similar for line-height, except the score is based on the x-height of the typeface instead of its width. It also takes a couple of other factors into account such as the line length, but it’s the same idea: a score calculated based on a normalized line-height curve.
UH: Fantastic! I like that it’s a curve and not an absolute value — that seems to me where the designer’s own interpretation can come in. The art in the science if you will?
BS: Exactly! I tried very hard to show the scores as a gradual change. I get a lot of requests for displaying the scores as numbers instead of colors, but I’m very worried that people will use those numbers to try and achieve a “perfect” score. That’s not the intent of the tool. There should be room for interpretation and breaking the rules. For example, on my website, the inspector highlights some of the line lengths as yellow-ish. But I think that’s OK. As long as they’re not red, it’s fine.
UH: So the tool is helping the designer make better decisions, not the “right” decision?
BS: Yes. There are no “right” decisions, but there is a whole range of good decisions. I’m hoping the ideas behind the Typography Inspector will be built into other tools so it can help less experienced designers (and developers) avoid bad decisions.
UH: Ok, last question just to wrap up. I think there is a red thread here about helping designers and developers make better decisions and create better designs. What are the things on the horizon that you are excited about in terms of tools and type on the web?
BS: I think that’s a great conclusion: I’m trying to figure out how typesetting works so that I can become a better designer, and I’m sharing the ideas in the hopes that it will help someone else.
I have a lot of other ideas for the Typography Inspector. It could do a lot more, like highlighting problems with color contrast, font size (based on the viewing distance), etc. Apart from that, I’m very excited about variable fonts, which I believe will totally change the way we think about typesetting on the web.
UH: Amazing. That is a whole new kettle of fish though! I know that both you and Tim Brown have a lot to say on that subject. Maybe I can have you both back for a 3-way interview at some point?
BS: That would be great. There is so much to variable fonts: from performance optimizations to how it affects responsive design.
I’d like to close by asking for feedback on the ideas behind the Typography Inspector. I’d love to hear what people use it for, what works, and what doesn’t. And I especially want to hear from people if they think it is a horrible idea.
UH: Bram, thank you so much for taking the time. Best of luck in the future.
Want to know more about what Bram does? Bram’s website is a treasure trove of articles and links to his various projects and tools for designing on the web.
Enjoy these interviews? Sign up to the TypeThursday mailing list to be the first to know about our next interview.
Was this article interesting to you? Click the Recommend button below
