Tutorial: Responsive Design & Web Typography by Jason Pamental
Today we’re very excited to have our Typography and Design expert, Jason Pamental, with us. Jason is the author of Responsive Typography with O’Reilly and will be an interactive discussion about typography and how to implement web fonts for performance and polish.
Thank you for having me! There are a bunch of great questions that people have sent in, so we will start off with some slides from presentations that I’ve given about typography at places like DrupalCon and Future of Web Design in London. I’ve pulled out some slides that are most relevant to the questions that people have been asking. That will hopefully spark some discussion, and then we can go straight into questions that people may have.
Who am I? I’ve been working on the web since 1994, and have worked as both Creative Lead and Technical Lead (.net development, server management, and infrastructure build-out). I’ve done design and technology a lot together, and that figures heavily into the approach that I take with type. I tinker with a lot of things, both on and off the web. I have an old car and I rebuild carburetors. I walk my dog around the reservoir a lot, so if you follow @jpamental on Instagram, pretty much all you’ll see are pictures from web conferences and the reservoir with my dog. My wife and I have been working together for 3.5 years, first at a startup and now with our own business for the last 1.5 years. We provide web strategy and design consulting for clients such as Yale University, UCLA, other higher education clients, and high-tech companies in the New England area.
I became interested in web fonts because, as a designer, it opened up the web to me in a way that wasn’t possible in the first 15 years or so. One thing that web fonts and responsive design really helped uncover was that we’re not very honest with ourselves in a lot of ways about how we work on the web, what we tell our clients, and what we can and can’t do. I’m going to go over what is Responsive Typography, about things that aren’t necessarily true and what we can do about them, which things we can control and which things we can’t, and how to prototype this stuff in a way that help you get the most out of web fonts, not only from an aesthetic point of view, but also from a performance one.
“Web” typography is an important qualifier, because the things that we have to do on the web are different. It’s not just understanding letter forms, what kind of a story they tell, and what kind of mood they bring to the design; but it’s how to get that to work in a way that doesn’t make us all cry and want to rip them out because it just kills the experience of loading a page. So, I think we have to accept that there’s both design aesthetics and design/technology considerations.
We can’t, necessarily, stop calling it that because of all these considerations. Furthermore, with responsive design, since our canvas is fluid and it’s constantly getting bigger and smaller, we can’t really rely upon our usual fixed units of measurement. So we have to figure out ways to convey meaning without being completely reliant upon how those fixed relationships are between one thing and another: a head and a body copy, a block quote, etc. Reading on screens is only going to increase. One of the things we have to remember is that Amazon has been selling more e-books than print ones since 2011, so it’s really critical that we get the reading experience right. It’s something we have to think about with all the web stuff that we work with, both apps and regular web.
It’s not the stuff we don’t know that’s going to kill us, because I’m going to teach you all this stuff and then you will know it. But it’s the stuff that we ignore that will really trip us up an come back to bite us. What do I mean by that?
It’s stuff like 960 pixels. That was always a fantasy. What you see above is the New York Times homepage, which was recently redesigned and went from 960 pixels to about 980. They didn’t really do much to take advantage of the screen real estate that we all have.
Another issue is pixel perfection. We can’t really do that either. We never really have been able to. It’s always been hit or miss. We can certainly try and we can get it right most of the time, but it’s kind of a fantasy and it really doesn’t belong here. We need to deliver great experiences that are appropriate for that particular platform. It doesn’t have to be exactly the same, because it never will be from size Android device to the next. So, why are we even going to try? That’s another thing we need to stop thinking about.
The third thing I wanted to bring up is the notion of a page in the first place. A lot of the things that we’re working on are a long one-page scrolling site, whether it be in Drupal or Wordpress or any number of systems, where we don’t know what the content will be tomorrow. No matter what we do when we bring this stuff to life, we don’t know the specifics of the actual content. We have to worry about the system that’s going to display it. One of the questions we got was about widows, leaving one word on the last line of a paragraph. You can’t rely upon going in and putting a non-breaking space between the last two words because you’re not going to do that with every paragraph on every page. The client is certainly not going to do it, either. So, we have to come up with other ways to make a system of great typography that helps convey all of this meaning and information in a sustainable way.
We take away the things we can’t know. We can’t know about screen size, device capabilities, concurrent activities, depth of focus, or even why they’re here. With all these things that complicate the whole experience and our understanding of somebody getting our content, one of the few things that we can hang onto, that we can know about and can deal with in an effective way, is type.
When you take away the type, there’s not a whole lot left to see. Here you’ve got the BBC News website with no type on it, and you can see that it doesn’t convey an awful lot until that type comes in.
When the screen gets smaller, that gets even more important.
This is an iOS simulator. This is the same website showing a bit of a story, but, unfortunately, one of the things we see here is that the only way we know that this is the BBC is the header bar saying that’s on BBC.com. That’s really unfortunate, because what they’ve given up is all of their own brand. They brought the story to the screen in an appropriate manner, but what they haven’t done is preserve their own identity through the process. What this points out is that the only thing left to do that is the type that’s on the screen.
This next screenshot is from the New Yorker Magazine website. It’s a really great, responsive design. If you know the New Yorker at all, you’ll recognize the typeface that they have throughout the sections immediately, because they’ve been using this typeface for decades. It’s something that everybody knows. It instantly conveys that this is the New Yorker. It’s very powerful to be able to convey that much of an identity just through the shapes of the letters, but that’s what we have to use when we’re designing for very small screens. That’s increasingly how people are consuming this content, or at least how they’re initially coming in contact with it. So, we really want to keep that stuff in mind. Type really is one of the most important elements because it’s one of the most prevalent on the screen in anything that we do.
I’m going to talk about the four things that I define as the heart of Responsive Typography. I’m being very careful about using Responsive Typography, because it’s not the type that’s responsive; that’s a whole different issue and a whole different technological nut that some people are trying to crack. Rather, it’s the use of that type. So we want to talk about performance, and make sure that you’re only loading what you need and we’re not blocking the page rendering. We want to make sure that it’s progressive, so that it works really well when the fonts are there or when they’re not. We’re going to talk about proportion, so we can think about how best to set type on small screens vs. large, because the scale changes are really quite different. And then we’ll talk a little bit about polish, because there are a lot of little details and I it was great to see some of these questions about things like widows, and how to use OpenType features like ligatures to get really fine typography into your design and your web application, because that is really what will set things apart, especially when that’s the only thing there to convey the true sense of what you’re trying to get across on a small screen.
Let’s get into performance. Performance is not, “I used everything.” That’s not what typography is all about. It’s about loading what you need, when you need it. In thinking about typefaces vs. fonts, you can think about the typeface as a family of styles of letters, and the font is a specific weight and variant of that; for example, bold, bold italic, or regular. That technically corresponds to a file, but for our purposes on the web, those things all get loaded individually. You have to make sure to manage that loading process, and only load the ones that you absolutely need. I want to show you what tends to happen if you’re not careful when you use some of these font services.
This is a screenshot from Typekit. They’re better at this now than they used to be, but what used to happen was when you added a font to use in your kit, it would add all of these weights and styles All of the checkboxes down the left side of the screen add up to 450K for two different fonts. That’s a whole lot to force somebody to download when, in all likelihood, you’re going to use maybe four weights and variants of one, and maybe only one weight of the other. Typically, for headings, you might use only one weight or style. For body copy, you might have regular, italic, bold, and bold italic.
When you scale it back to only those four variants, it goes down to 120K, and that gets cached so it’s not something that has to get loaded on every page. That really makes a drastic difference. I talked with somebody on Twitter whose experience internationally with very high-latency connections was that web fonts, when they’re not handled properly, can add minutes to the page load. When we only have about five seconds before mobile users will bail, that’s a complete failure. The way that browsers are handling that now is that they’re not showing any content at all while we’re waiting for these web fonts to load. That’s a real problem, but we can get around that. That’s what we want to make sure that we’re doing.
That brings me to FOUT, or Flash Of Unstyled Text. That is the sort of thing that crosses the boundary between performance and progressive enhancement. Typically, what you’ll see during the loading process is either a fallback font, like you see on the left, that’s completely not in keeping with the site design; or you’ll see nothing at all with some random underlines where the links should be, like you see on the right. That’s because the browsers are not showing you anything, or at least waiting until 3-5 seconds have gone by before they’re going to show anything if that web font hasn’t loaded. Again, that’s a critical issue if you only have a few seconds before mobile users are going to start to leave. What happens is you see nothing, and then a few seconds later…
…you see all the right typefaces come in, and the rest of the screen will draw. What’s happened there is not only have those web fonts held up showing the text content, in some cases they can even block rendering the rest of the page, so that you don’t even get some of the images either. It’s a huge issue, and when left unchecked, it can really ruin the experience of the site, especially on a slower connection. So, we want to make sure that we use the tools that we have, and these tools have been around for a number of years. We’re going to talk about the web font loader that Google developed with Typekit.
The way it works is by using the web font loader, and that is either by default with Typekit, or you can look it up on the Google Fonts website, and they’ll point you over to the place to find the code for it. Go to http://www.google.com/fonts and you can look at the fonts that they have. Load some, and there will be a link to get to the web font loader. It injects these classes in the page, .wf-inactive during the loading process and then .wf-active once those web fonts are loaded. Because we can rely upon those classes being present as long as javascript is working, we could add a line of CSS that during the loading process, when .wf-inactive is present, it loads typefaces that are only the fallback ones. That’s pretty fantastic because it gets your content on the screen right away without any of that delay. Then you can use that CSS class that’s there in order to adjust font size, line height, and letter spacing in order to avoid jumpiness when the web font does actually load. This has been around since 2010, so it’s not something that is brand new. It’s actually something that some of the browser vendors are starting to build in, so that you don’t have to use an external javascript library. That will make things even that much better. I know that Chrome is working on it, but I don’t think that it’s officially released in any of the browsers yet.
I’m going to show you a quick example of how this all works by adjusting the fallback font during the loading process. These are screenshots of a sample page that I made a while back. This is what it should look like with the web fonts fully loaded.
With this next one, things shift around a little bit. This is with no correction in the fallback font. So, we have loaded the fallback of Georgia and Helvetica in place of the web fonts.
With this one, we’ve adjusted the spacing ever so slightly. You can see things lining up a little bit better, so that when the web font finally loads…
…things don’t shift around all that much. You can see the horizontal and vertical spacing is roughly the same, you had very little change in line wrap, and your navigation doesn’t reflow. All the things that tend to be a big problem with FOUT can be alleviated by this simple technique for working with the web font loader and tuning up your fallback font. I wrote an article about that for fonts.com a few years ago. All the code sample is there, and it’s also in my book that’s just coming out now with O’Reilly. So, that’s progressive enhancement.
This is another aspect of using the code from the Google web font loader. This is actually loading it asynchronously, so that it’s not blocking the drawing of the page. It just issues the request; it doesn’t wait for it. Then it will load in the web font once it’s present. I’ve also added a noscript block in order to load it via CSS in case javascript doesn’t work. That way you can be sure that you give the best possible experience to the browsers that can handle it, but you’re not leaving anybody out in the cold. You can always serve those web fonts. Typekit is the only platform that won’t let you do this. All the rest of them will give you a CSS line to put in there, in addition to advanced methods that will allow you to load things through javascript.
Proportion is another area I’ve spent a lot of time with over the past year or so. I wrote an article for Typecast’s blog a while back, and really spent a lot of time trying to figure out how this proportion stuff would work well as screen sizes change. What I found was that while we have a known scale that’s been around for many, many years in print design that works pretty well to set headings in relation to body copy, it doesn’t hold up very well when the screen size starts to change. I wanted to be sure that we could address that in a meaningful way, so I set about trying to make a different scale. I spent some time on that, and I think it worked out pretty well. It gives people a good starting point to figure out how to set type on big and small screens, and how to tie into your media queries so that you can have things that look pleasing and in proportion on small screens as well as large ones. The link is here on the slides (http://bit.ly/jprwt). It’s also in the book and you can find it on the Typecast blog. There are plenty of places to see it. The whole scale is reproduced there.
I’m going to show you some of the examples of it.
Here’s an example of that same web page that has had the same scale applied for headings and body copy on the left and the right, from large screen and small. You’ll see, when you have that same proportion, it really looks a little ungainly, and you end up not seeing a whole lot of content. But on the smallest break point, if we end up tweaking that scale a bit, we can still get something that conveys the meaning, the importance of the name of the site and the title of the page, but…
…it gets so much more content on the screen. It has much better line wraps and you can see that this really holds up the integrity of the design much, much better. All we did, really, is across these break points, start tweaking the size of the heading in relation to the body copy. We left the body copy alone. That is one of the questions that came up. I tend to leave the type size for the body at 100%, so that the device manufacturer is really dictating what is a readable size type without my trying to second guess it. I find that that works really well most of the time. I will set that as my one EM, my one relative unit of type, and then headings will be some multiple of that. On the smallest screen, the H1 might be 2em, or twice the size of the body copy. On the desktop size, it might be 3em. That’s all subject to tweaking, where every typeface is going to look a little different, but it’s a good starting point. I find that this set of numbers seems to work pretty well. If you go to http://bit.ly/jprwt, that will take you to that article and you can see the whole scale there and play around with it. There’s a link for some sample code too.
There are a few more things about measure and scale. I mentioned relative units. Be sure that you don’t forget, EMs are really important, but it’s not just for setting your type, it’s also for your media queries. The reason I bring that up is if you don’t set your media queries with EMs, if you stick with pixels, what will end up happening on some devices that have very high-resolution screens but are a combination of both touch and pointer (various Samsung touchscreen laptops are a good example), you end up with your content and this tiny little stripe down the middle of the screen. That’s because it’s a super high-resolution screen, and it’s not respecting the artificial constraints that have been imposed upon these devices. Like phones, their resolution is much greater than 320 pixels across, but that’s what they report all the time. By setting your break points and EMs, you can make all this content render properly on all these different devices, even though you’re just picking an EM-equivalent of the pixel value. Play around with that if you can. I don’t know if anybody has one of those devices, but if you have a chance to look at some of those responsive sites that way, you’ll be in for a real shock. That’s definitely worth checking out. There are a couple more things from this slide here. Setting max-widths on your paragraph tags will help keep your line lengths from getting really, really long. 38em will probably be a little bit narrow; you can probably go a little bit wider than that, but essentially what that does is it keeps your line length at a length that is comfortable to read and is not too hard for your eye to follow back to the start of the next line. That’s just a basic little typographical design tip for you to take with you. You can set that max-width on a number of different elements in order to allow your design to scale, but have your type not get really hard to read. The last thing on this slide is don’t use Lorem Ipsum text when you’re working on your design. Grab some real copy from somewhere because the word lengths are so uniform with Lorem Ipsum that you’ll never get the true feeling of type as it’s going to reflow when you have real stuff to work with.
Here’s another little step in the journey, polish. Polish is really just getting the fit and finish. It’s getting all the nice little things that we can do. If you look at the way these letters come together in the heading up top and the main title, “A Whale of an Afflicted Tale,” and see what happens when I activate the OpenType features…
…you can see how everything tightened up. It has beautiful little connectors between some of the letters. The f, f, and l come together as a single unit. There’s a nice little connector between the c and the t. Everything kind of comes together and feels like more of a unit. Even in “1/2 Way to 19 Thousand Leagues,” you’ve got much nicer numerals here, and you’ve got a real fraction instead of a one-slash-two. That stuff sits together really nicely. That’s all part and parcel ofOpenType features. If you’re working with a typeface that supports it, the CSS is really easy and you can then not have to worry about the fallback because it just goes back to normal characters. There’s really no downside to including that, other than a slightly download, so you don’t want to do it on everything, but it really does add a nice level of polish if it is available.
Another little bit here about using columns in your CSS and a nice initial cap. Again, these are all nice little bits of CSS you can add into your page that don’t really have a downside, because if the browser doesn’t support it, it just doesn’t show. This is using CSS columns in the middle and an initial cap in that first paragraph.
You can see, looking at it on a phone, everything scales down proportionately. It collapses from two columns to one. The intial cap C scales down so that it stays in better proportion to the intro paragraph and it doesn’t look too ungainly on the small screen. All those things are pretty standard bits of CSS that don’t require too advanced a browser to support. Again, the fallback on those things is seamless. It just goes back to regular letters and no columns. It works just fine.
Another one of the questions that was asked is about widows and orphans, not wanting to leave a single word on the next line. This is a little screenshot from our website, and you can see that as I bring the screen in here…
…we end up with just “the world,” rather than “world,” on the last line. That using the module called Typogrify. That is a Django library that somebody adapted to make into a Drupal module. There is also a plugin for Wordpress that does it as well. This does a bunch of little things, but one of the neat things is that it inserts a non-breaking space between the last two words in every paragraph. That happens automatically, and it happens on the server side, which is really awesome. So, it doesn’t really matter if this is in a CMS; it’s not something the administrator has to do at all. It’s actually something that gets handled on the server side, so that when this page gets served to the end user, then it just automatically has all these little niceties in it. It can also handle a lot of character substitutions, so you can get good curly quotes and apostrophes rather than the straight up-and-down hash marks and stuff like that. That stuff is all really great. If you don’t have access to, or you’re not using, one of these content management systems, you can also search for Widow Tamer on GetHub. Nathan Ford created that library, and it works really well in order to add this as a javascript plugin. It’s a little jquery plugin that allows you to define how many characters you want to have on the last line. It will always make sure that you have at least that many that show up on this last line of text. So, you can make sure that it’s more than just two words. You might want to specify three or four. You can have a lot finer control over it, as long as you’re OK with that being javascript and happening on the client’s side. But, it does work really nicely. A lot of this stuff, I will also say, you can get if you go to my GetHub repository. Just search forjpalental on GetHub, and I have all of the sample code from the Responsive Design workshop that I teach. There are several units in there on typography, so that you can look at all that sample stuff and get a lot of these sample projects and code right out of that.
So, that’s Responsive Typography on the web. It’s making sure that we adapt; it’s making sure that we’re ready for what’s going to come next. That little tidbit there about go back to the last Winter Olympics and there was no iPad; go back one more and there was no iPhone. It’s kind of alarming to think how much has changed in just two Olympic cycles, but that’s what makes it so important for us to understand these basics, and then really be able to work with type effectively in a meaningful and systematic way, so that as our content grows and changes, our design and our system will hold up.
Performance, progression, proportion, and polish. We talked about all that stuff.
You can find out a lot more about it if you want to take a look at this. Anybody that’s participating here and wants to get in touch with me after the fact, there may be some discount codes hanging around if anyone wants to grab a copy of the book. It’s out as an early release right now, meaning it’s not fully edited yet, but it means you can get it a little bit cheaper, and then you’ll be notified when the full release is ready. That should be in the next month to month-and-a-half. That’s for the e-book version. The print version will be out in a little while.
So, those are the slides that I have. If you go to this bit.ly link, http://bit.ly/jpfiltype, that one will take you to a version of these slides that’s a little bit more complete from that Future Insights conference in Las Vegas a few weeks ago. With that, I will stop talking at you, and start talking with you. I hope that was helpful for everyone.
Other posts in this series with Jason Pamental:
- Introduction to Fonts for Developers
- Choosing & Pairing Typefaces
- Pros & Cons for Icon Fonts Like Font Awesome – Design Tips for Developers
- Using Modernizr to Detect HTML5 and CSS3 Classes in Browser
- Additional Resources About Responsive Typography
Need more design mentor help? Book an 1-on-1 session!
