The Responsive Unknown: Typography and Layout

Posted

In the process of building responsive sites, designers are inevitably confronted with the most difficult decisions up front. Unless you don’t spend any time planning, wireframing, and re-planning your project, a big chuck of your project concern is going to be how your content scales. Scaling content can mean two things here and I’m really talking about both. First is layout between devices. Before you build any media queries you need to understand what kind of content you have and how it will react when the available screen real estate changes. Second, how does your design handle the addition, deletion and modification of that content? Does your blog handle new posts and pages gracefully? How does that page respond to images or video being added when they weren’t a part of the initial project scope?

These kinds of questions are hard to solve well for any design project but when you throw in the context of this series of posts things get more difficult still. How do we make these considerations for those projects that don’t exist yet? Do we have methods in the bank for scaling content when we don’t even know what the content is? All of this is going to boil down to a couple of very important elements that make up the crucial foundation of a design project: typography and layout.

Typography

It wasn’t long ago that typography on the web was supposed to have a watershed moment. Services like TypeKit and Google Fonts and the growing support for the @font-face property were going to usher in the typographic renaissance for the web. To a degree they did; compared to just a few years ago, our options with type have expanded exponentially. But at the same time things have also gotten more complicated, as they are wont to do on the internet. Now we need to figure out what to do with our typography at different screen sizes and different resolutions to boot.

Fluid containers are great things, its part of what makes the web a wonderfully flexible medium. But fluid containers alone don’t render a great reading experience. As we adapt the web to make better use of the flexibility it thrives on we need to adapt our content too. This is the most important piece of any website and it’s important that no matter how our users access our content, they find it effortless to consume.

So that’s the goal. However, in order to understand how we can get there we need to first explore the close relationship that typography has with the layout it lives within.

Layout

Orbital content is awesome. If it’s a concept that you haven’t made yourself familiar with yet be sure to get on that ASAP (after you get done reading this, of course). Allowing our content to be lifted and transposed to other environments without any disruption to the message and readability is an ideal and achievable situation. However, when our content is not being transposed to other places the relationship it has with the layout it was born into is undeniable.

Your site structure and layout plays the role of a parent to your content and typography. As long as that content lives under this structure the layout must provide the best environment for it to represent itself well and be respectable while at the same time providing the ability to grow and let the personality of the content take center stage. Like any good parents, a site layout must work itself out of a job, fade into the background and go unnoticed but always be there for support. The harmony between these things is a crucial component to the foundation of an awesome user experience.

So how do we achieve this? What process can we take to ensure that we kick off a responsive design project the right way with a solid layout and crisp typography? And even beyond that, what measures can be taken in the context of building resources that will help us save time on these problems in the future?

The Ideal Solution

Let’s take a minute to talk about the ideal solution here. In this dance, someone needs to take the lead and in the hierarchy of design content lands on top, so it makes sense to allow our content to control our layout as much as possible. But how? This is the part where I point to smarter people who have done the hard bit for me. Trent Walton addressed this method previously on his blog. It’s there that Trent discusses his method for laying out type, which is to take measures to ensure that the average line length of a paragraph lands between 45 and 75 characters.

Achieving this requires a balance of adjusting font-size and controlling your containers to keep line lengths in check. That 20 character cushion should be gracious enough to ensure you have wiggle room between breakpoints and it’s a pretty easy thing to measure. Of course this can’t apply everywhere, an aside comment, narrow sidebar, supporting content, image captions and other situational elements will likely be exempt to the rule. The important thing to keep in mind is that the primary content on the visible page should represent an ideal reading experience at all resolutions and building your grid around that will force an answer to some layout coin tosses.

Furthermore this is a pretty simple goal to achieve (relatively). Generally speaking, as your available real estate expands and you work your way from small screen to really large screen (because we love mobile-first design) you’ll increase your font size on the html element to scale your primary content region up to maintain the character-to-line ratio. There will naturally be a point where sizing text alone to achieve this gets a little ridiculous. Here, we use our sharpened designer skills to restrict our layout containers and make sure we can see more than 2 lines of our paragraph without scrolling.

So that’s it… easy, right? No. Don’t be dumb.

The Part Where Things Break

There are two reasons why that isn’t the end of our problem. First, if it was I wouldn’t have written anything about it. I already explained to you that Trent did an awesome job explaining this stuff so I would just tweet his article and call it a day. Second, we haven’t solved anything I’m trying to get at here on this blog. Our goal is to build long-term solutions. We want patterns to execute responsive designs and we want new thought processes and exercises that will help us become more efficient designers.

There is a reason I started with typography and grids. They’re incredibly hard to nail down and build patterns for. And it’s not for a lack of trying. There are plenty of solutions out there when it comes to fluid grids and even responsive grids. By now you should be familiar with things like the fluid 960 grid system and there have been some clever solutions put together for a responsive version of this. The bootstrap project has a take on it and other projects dedicated entirely to a responsive grid system. I think these projects rock and I would encourage anyone to get their hands dirty and use them. With that said, I always arrive at the same conclusion.

These efforts don’t lead us to a reliable solution. Yes, it’s a column-based layout system that shifts to fit on different devices and for the most part they do a great job at that. But this still leads us short of creating an ideal solution for our content. No matter what sort of pre-made responsive grid system you may implement there’s going to be a lot of tweaking required. In a lot of cases that tweaking and overriding can lead to more work than it would have been to build the container reflow pattern on your own.

The truth is that there are too many variables involved in a responsive grid system to build a perfect one. The more I foiled with other solutions and even tried to develop my own the more I came to my overall answer for this problem.

I Don’t Even Want This

What comes off initially as a childish reaction (“I can’t figure this out? Fine! I don’t even want to figure it out; I never cared about this at all. It’s stupid.”) is the right answer. I don’t want a pre-made responsive grid framework I can plug into my site because it simply can’t work. That pre-made solution doesn’t know anything about my content and until I know something about my content I don’t really know how I want it structured. We already decided that content takes the lead in the foundation of a design which, by nature, makes the layout a reactionary element.

Containers must be crafted around their precious possessions and adapted to all of the unique problems a responsive design presents. This is a hands-on task and really our job as designers. It’s also one of the beautiful things about being a designer. This part of the job can’t be outsourced and it can’t be automated. There is no pattern for the process a professional designer takes in understanding content and shaping it to allow its purpose to shine through. We should be happy about that, its job security.

So where the hell does that leave us? 1,600 words of pointlessness where we go around this big circle and decide to screw it all we still need to do this by hand? Thankfully no, I actually thought about this post before I wrote it so I won’t leave you at that.

Something Real to Take Away

There are some real lessons here. First, when it comes to typography we have a precedent to follow. Maintain readability across devices, build your typography to allow your primary content to flow at 45-75 characters per line and build out from there. Second, this should drive your layout as well and decisions about design elements that live around your primary content should fall in queue with that order of importance, making it easier to figure out how they flow through various resolutions.

Finally, when it comes to grids not all hope is lost. When it comes to individual designs and solutions on a small or medium scale a custom grid is almost always the best option. However, if you’re designing for a framework or a solution that will be applied to multiple sites or a very large project w can still use pre-made grid solutions. There is nothing wrong with using one of the dozens of fluid grid systems and frameworks out there. Any system that builds layouts based on class structures can save a lot of time in the design process. However, when it comes to reflowing this layout and getting responsive it’s best to stay hand crafted.

As I continue to experiment with this one method that has become increasingly reliable is the media query ladder as I’ve come to call it. I may expand on this in another post, but when it comes to working with grid systems they tend to be constructed for larger resolutions. This doesn’t play nice with our mobile-first responsive design approach so what’s a designer to do? In the media query ladder I start with max-width statements and work my way down from widest screen to smallest, making adjustments to my grid as I go. Then, once done with max-width queries I start on my min-width queries for all of my CSS properties not related to the grid and work my way back up. The max-width and min-width values need to match for a smooth sizing experience.

So layout and typography don’t hold a silver bullet solution when it comes to responsive design but that’s hardly surprising. These are some of the most important pieces of any design and require a lot of planning, execution and tweaking to get right. It’s part of what separates great designers and will likely continue to be. The good news is that there are ways to speed up this part of the process and work we can complete towards the future.

The Big Picture

This post is a part of a series I am piecing together to explore methods, patterns and techniques designers can utilize to improve efficiency in the responsive design process. Other parts:

  • Introduction
  • Typography & Layout
  • Navigation
  • Tabbed Page Structures
  • Images / Video/ Multimedia
  • Tables
  • Popups / Modals
  • Smaller Components (buttons, form fields, asides, etc.)

Leave a Reply

XHTML: You can use these tags: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>