The Infinite Grid

Grid systems are a key component of graphic design, but they’ve always been designed for canvases with fixed dimensions. Until now. Today we’re designing for a medium that has no fixed dimensions, a medium that can and will shape-shift to better suit its environment—a medium capable of displaying a single layout on a smartphone, a billboard in Times Square, and everything in between.

We’re designing for an infinite canvas—and for that, we need an infinite grid system.

It’s common to think of responsive design as multiple layouts: mobile, tablet, desktop, etc. The problem is the “in-between” sizes tend to suffer, so we end up with layouts that look great at specific dimensions (320, 720, 960), but less than great for everything else. So while a site may look perfect on your 640×960 iPhone 4, it’s going to be a bit off on a visitor’s Nokia Lumia (480×800), or the 685×308 browser window you have open on your desktop. It might even look a little off on that shiny new iPhone 5 (640×1136) your cousin just bought, not to mention the countless other older or less-popular devices out there.

As the spectrum of device resolutions gets wider and smoother, focusing all our attention on “key dimensions” for each page is going to result in a subpar experience for more and more users. Instead, we need to create a grid system that embraces the medium’s lack of fixed dimensions, resulting in a single layout with multiple states that transition seamlessly from one to another, and bring structure to our content whatever the screen size.

What is an infinite grid system?

Grids are simply a tool for visual problem solving. Creating a layout is like doing a jigsaw puzzle; you have a bunch of pieces and you have to figure out how they should fit together. When we construct a grid, we’re creating layout boundaries: known relationships and constraints that define an environment wherein an appropriate solution can occur. But when we construct an infinite grid, we’re not just setting the boundaries for a layout, but a layout system, with too many variables for us to nail everything down. If we define the important relationships, the blanks will fill in themselves.

For a grid to be useful, it has to be based on the things we know. In traditional media, canvas dimensions are a known constraint, so it makes sense that we start with the edges and define a grid’s relationships relative to them. With digital, however, the canvas is an unknown, making it a poor foundation to base a layout on.

Instead, we need to build on what we do know: content.

In order to embrace designing native layouts for the web—whatever the device—we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

— Mark Boulton, “A Richer Canvas”

When designing from the canvas in, the canvas dimensions are the constant on which the whole grid is anchored. Everything is sized and positioned relative to them. Designing from the content out means finding a constant in your content—be it the ideal measure of a paragraph or the dimensions of an ad unit—and building your grid out from there to fill the space available.

Now, layouts that expand to fill the space available are nothing new—after all, fluid layouts are basically the web’s default—but very few layouts can be stretched or squashed indefinitely without the relationships between components breaking down, and that’s where states come in.

STATES

Fluid layouts are often compared to water, but water isn’t always fluid. H₂O has three different states, and depending on the temperature can be a solid, liquid, or gas, transitioning seamlessly from one to another at specific points (0ºC, 100ºC). An infinite grid also has multiple states (single column, multi-column, etc.), and should transition as seamlessly as possible between them at specific breakpoints as well. For example, just as ice is an appropriate state for water when the temperature is low, a single-column layout may be the appropriate state for an infinite grid on smaller devices.

Water’s state change is caused by the rearrangement of its molecules. When an infinite grid changes state, we rearrange its components.

COMPONENTS

Each state in a responsive layout tends to be made up of the same components, such as an image gallery or navigation menu. However, as Ethan Marcotte recently outlined, the form these components take can vary dramatically between one state and another, usually involving a change in one or more of the following attributes:

1. Hierarchy: What’s its order and prominence in the layout?
2. Density: How much detail do you show?
3. Interaction: Should it be a list of links or a dropdown? A carousel or a group of images?
4. Width: Is it fixed (a specific width), flexible (set with max-width), or fractional (set with percentages)?

Considering how each component’s attributes may change between states helps ensure that the grid system produces the right layout for the space available. In this example, watch how the different components adjust their width (between fixed and flexible) and position between states.

Designing an infinite grid system

Though we’re only beginning to scratch the surface of designing infinite grids, a few techniques are already proving useful. To get started, here are a few guidelines:

1. USE PROPORTIONAL UNITS

Designing a grid is about deciding what should be proportional to what. When you choose a unit, you bind a dimension to a particular variable:

• Pixels size an element relative to a particular resolution
• Ems size an element relative to its font size; large rems size it relative to the document’s base font size
• Percentages size an element relative to its container
• VH and VW units size an element relative to the viewport

Absolute units like pixels effectively give a layout a sell-by date, locking it to a finite resolution range in which it will “work.” Proportional units (ems, rems, and percentages) enable you to define the important relationships between elements, and are a crucial first step on the road to resolution independence.

2. START WITH THE EXTREMES, THEN WORK OUT THE IN-BETWEENS

Every layout has a natural “optimum” range for its content. How wide can you stretch it before it starts to break? How small can you squish it before it starts to collapse? For example, if the width available is less than 45 characters per line, your layout starts to feel cramped; if there’s more than a column’s worth of white space on either side of your layout, the content starts to feel dwarfed. Where these extremes occur differs for every design, and depends largely on your content.

Designing for the extremes first forces you to consider how best to present your content at either end of the spectrum. Consider the hierarchy, density, interaction, and width of each component at the smallest state, then do the same for the largest state.

For example, lets say my largest state is 75em wide (any larger and the white space starts to dwarf the content), and my smallest is 34em (any smaller and the measure is less than optimal). In the largest state it makes sense for my navigation to be a horizontal list (interaction) at the top (hierarchy), but in the smallest state it might make more sense to move it to the bottom of the layout (hierarchy), or collapse it into a show/hide list (interaction). Designing these independently of one another helps you be more objective about what is best for each state, rather than stretching a one-size-fits-all solution across every state.

3. CHANGE STATE WHERE RELATIONSHIPS BREAK DOWN

Once you’ve worked out the extremes, it’s time to consider how and where one state should transition to another. Just like water changes to steam when its molecules get too far apart, one state should change to another when the relationships between its components begin to break down, such as when the measure is getting too wide, or the left-aligned logo is getting so far from the right-aligned menu that the visual connection between them is broken.

This is where live prototypes come in handy. It’s incredibly difficult to predict exactly at what width (in relation to the content) a layout needs to change from one state to another. A prototype allows you to easily resize your browser to find the exact point at which relationships break down, so you can add a breakpoint there. New tools (likeGridset and Responsive.is) are making it easier than ever to create and test responsive prototypes, so there’s no excuse not to.

The number of states you require will depend on how much your layout changes from one extreme to the other. For example, my smallest state has a single column with a collapsed menu, and my largest state has three columns and an expanded menu. However neither state looks quite right between 34em and 53em, so I’ve added an “in-between” state which maintains the smallest state’s single column article, but expands the menu and divides the footer into three columns to make the most of the space available. This smooths out the transition from one extreme to another quite nicely.

With each state change, remember to reconsider the hierarchy, density, interaction, and width of each component. Perhaps your main content column should be fixed width now to ensure the measure doesn’t get too wide, or maybe you have room to add more information (density) to your navigation?

4. GO BEYOND THE EXTREMES

So we now have a responsive layout with multiple states, that transitions smoothly from the smallest state to the largest. But that’s only a range of 34 to 75em. What about when the available space is smaller or greater than those states? How do we get a layout that truly goes from zero to ??

At the smaller end of the scale space is precious, so we need to make the most of what we have. For under 20em, I’ve reduced (but not removed) margins, decreased line height, and indented bulleted lists. Basically, I’ve done what I can to optimize readability, even though I have a less-than-optimum amount of space available.

At the other end of the scale, the problem is too much space, specifically whitespace. This makes content feel dwarfed, so we need to find ways to balance it out. Unfortunately, simply scaling up a layout indiscriminately doesn’t always work, as we start to come up against reading distance. If you scale up your text size to maintain approximately sixty characters per line, but the type is so big that I have to physically turn my head to read it, that’s not a good experience.

Instead, look for elements such as headers, dividers, or images that you can scale up with the canvas, which helps anchor a layout visually without ruining readability. In myexample, the ruler element that stretches full-width helps “anchor” the design in the whitespace, and at 75em I start scaling up the elements relative to the viewport size using VW units. The body text starts to get uncomfortably large at 90em so I use rem units to keep it at a comfortable reading size while the other elements scale around it.

Either way, the goal is to make the most of the space available, relative to your content, to maximize readability and presentation.