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?#section2
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#section3
Fluid layouts are often compared to water, but water isn’t always fluid. H2O 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#section4
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:
- Hierarchy: What’s its order and prominence in the layout?
- Density: How much detail do you show?
- Interaction: Should it be a list of links or a dropdown? A carousel or a group of images?
- 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#section5
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#section6
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#section7
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#section8
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 (like Gridset 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#section9
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 my example, 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.
To infinity, and beyo—#section10
Actually, infinity would be enough.
Using a predefined grid seems to make as much sense as using a predefined colour scheme.
I’ve tried to stay away from specifics here, because there are none. Each layout is different, and there are no magic numbers that will work every time.
Instead, we have to nail down the relationships between elements, and then let the specifics take care of themselves. We don’t have all the answers yet, but doing this will help us ask the right questions.
This is a problem worth solving. And we’re not just solving it for ourselves, but for everyone who designs for digital media in the future—and that could be a lot of people. An infinite number, even.
A fluid grid works well for a specific type of layout – a simple two or three column structure – but it starts to fall apart when more complex layouts are required.
One simple example – a fluid container in which thumbnail images are placed in a grid pattern. You have three choices, either the thumbnail images increase/decrease in size along with the container or the margins between them increase, or they simply don’t always fit neatly into the available space.
This is just one example of where fluid grids aren’t always the optimal solution – there are plenty more.
A good designer will spend a great deal of time ensuring a design fits within specific constraints, because, quite simply, canvas matters. White space matters. It brings legibility and order which in turn improves the overall user experience.
This is why fixed pixel width grids are often preferred by designers – having a fixed step change between resolutions, rather than a fluid change, allows complete control over the design.
Is it such a big deal that a window resized to 1023px will display a 800px version? Absolutely not.
When it comes to mobile resolutions below, say 480px, at this point, it may be easier to then resort to percentages rather than pixel widths, as generally, we end up with a one column layout.
Both fluid grids and flexible grids have their place. A media intensive site – for instance, photography – may be better suited to a fixed pixel width grid. A Blog, on the other hand, could be better suited to fluid grids.
“Design is a relationship between form and content.” —Paul Rand
Paul Rand is one of my [many] design heroes. I think that quote best sums up the visual problem solving that we have before us with The Web as a medium. I am on board with much (if not all) of what was written here. I’ve been working on a rem-based grid system for the last month. Obviously, it will not work as a solution for a client site (see also: IE), but it _is_ fun to experiment with and exploit the malleable qualities of the medium.
Kudos to you for this article. And the demos. We’re getting closer 🙂
Cheers!
matthewtrow is missing the point here. If your design is dependent on a fixed viewport, then you are designing around layout instead of content. Why can’t the layout of photo thumbnails be designed to reflow or change completely to suit the viewport?
Photographic sites should focus on the photos, not how the photos are laid out. The key is how the user is viewing or interacting with the photos. If you only want users to view photos from a desktop, then you are ignoring a growing audience of mobile device users.
@Matthew some good points there. I think the answer isn’t fluid OR fixed, but both.
It’s something that needs to be decided for every component in every state. In my example (in the larger states) the ‘other article’ thumbnails are fluid, but the main article content is fixed. Keeping the article to a readable measure was important, so I sized it relative to the content (fixed), but since the thumbnails weren’t so width-sensitive I sized them relative to the canvas (fluid).
There are definitely still a few cases where it makes sense to use pixels as units (when sizing bitmap-based images for example), I think we just need to be mindful of the connections we’re making when we choose units.
@Leban yeah I’m a big fan of Paul Rand, isn’t it funny how a lot of his principals still hold true in a medium he never designed for? I wonder what the likes of Rand, Muller-Brockmann and Tschichold would have made of the web…
Taking the infinite grid design and full hierarchical design concept to its “mathematical limit,” we’re creating relationships that applied across design/css brings function to “1.0” and style to “0.”
This is the difficult compromise found in design, where style (take color) essentially is either to reinforce function with contrast or promote emotion with branding.
Thanks, Chris.
I think what this article is trying to say is that we should do away with common breakpoints. I’m curious to see how quickly this happens. Today, when so many are dependent on frameworks (which, don’t get me wrong, are a great starting point) to get the job done and front-end design work is further commoditized the space for innovation is less and less. I don’t think this or any other ubiquitous solution is perfect and so much depends on the client, the budget and what their content needs are.
@Michael – perhaps I didn’t make myself clear.
I very much advocate a responsive solution for *all* websites.
Non-fluid responsive layouts have step-changes – 1280 / 1024 / 768 / 480 / 320
They are pixel based. In other words, they are *still* responsive, but work at set resolutions.
This method allows more control over the design.
So that photo gallery *will* re-flow to suit specific resolutions.
The author of this article points out the problems with that – the many resolutions ‘in-between’ the step changes. I’m of the opinion this isn’t much of an issue for Desktop users, but I’d agree with it for mobile.
Therefore, a hybrid solution may be the way forward.
The design looks to have failed. I saved the page to test it locally. When I saw it on a maximized screen, the horizontal scroll bar shows its ugly head.
The basic purpose of a perfect design is it should never display scroll bar and the margins should be same everywhere.
What is missing here?
Can I get un-minified js source (goes with 267a1bd9-70b5-4df2-a142-052b3377ac07.js on local HDD) so that I can work on it further?
Very good concept though.
@Derek I totally agree, every project is different. Even something as simple as changing the font means reconsidering the ideal column width, which has a huge knock-on effect on a layout.
Frameworks with specific dimensions are like sums (1 + 1 = 2), they have a finite number of outcomes. What we need are frameworks that are like formulas (x + y = z), they define important relationships but get you to adjust the variables to be right for your project. This is what we tried to do with the “Goldilocks Approach”:http://goldilocksapproach.com
@Chris Armstrong – I’ve often pondered that myself. It makes it tough when our heroes are dead. The best we can do is embrace their teachings and _try_ to apply their principles to our work.
If only… 🙂
I am running Chrome and Firefox on Ubuntu.
On Chrome, the bottom, section five through section seven, expands to the whole page. On Firefox, the bottom only shows up below content … I call our world Flatland …
How can we trust the article? The author has not even answered my earlier comment.
Responsive design has a certain responsibility and it must be taken into the right consideration while even writing articles, esp. if you’re on AlistApart. A lot of people are following you for the advice and you can’t just deliver pre-alpha articles.
I would like the author responds to my comment. Please write to nitin.nanivadekar@gmail.com if you want to keep it private.
@Nitan thanks for your comments 🙂 As I mentioned in the source code, the examples were built to visually demonstrate the article’s ideas, and I’m sure there are far more effective ways to execute them.
I’ll fire you an email to discuss further, rather than getting too technical here 🙂
The page scrolling in your webpage should be fluid but its not in my windows phone!!
You should check it out. Otherwise is just a perfect concept itself.
Like every project the answer is … it depends. We’ll use total fluid and infinite grid layout when designing a content oriented website targeted for a full range of devices.
When images are part of the design and not only in the content. Pourcentages heights of images can become hard to manage and maintain. But clearly future proofed 😉
For simply and scalable grids design check “boxesPhi”. A simply grid system for jquery & javascript at http://www.cheflecode.com/boxesPhi
I always find it rather patronising when promoters responsive design see the subject as a must because it is never backed up by user research. Where can I find user research on responsive design? I do build fluid sites (£££) but personally when I browse I prefer a fixed site. For example as you get smaller content is often moved around making it hard to find and often removed all together. This is typical when going to desk top to mobile on both the FT and the BBC websites. Also having to scroll and scroll and scroll homepages can be a pain when you can move left to right as well as up and down and pinch zoom on a mobile more efficiently.
Still dipping my toes into the responsive way of web building but this is fantastic food for through. Great work Chris!
Great question! I guess the theory is that designs which take your particular environment into consideration will produce better experiences than one-size-fits-all solutions.
Imagine if pocket novels simply scaled down text size and layout, and came with magnifying glasses to help you read them? Giving the user a layout that’s better suited to their canvas size may result in them having to turn more pages (or scroll more), but if done right it should make the content more accessible and pleasant to consume.
Thankfully, some cold hard data is starting to come to light to support this theory. Here are a few recent examples where RWD has had a successful impact:
• http://gravitydept.com/blog/skinny-ties-and-responsive-ecommerce/
• http://www.bostonglobe.com/business/2012/10/30/the-boston-globe-circulation-rises-nearly-percent-herald-falls-nearly-percent/OSqacPxh1L0kQycUnBP1oM/story.html
This does raise another valid issue though: user preference. When we make responsive design choices, we’re making assumptions about the context in which a user is viewing content. For example, you might assume that because a user’s canvas width is <400px that they're on a mobile device, probably with a touch interface. However they could simply have their browser window at a narrow width in the corner of their desktop.
It's our job as designers to make the best assumptions we can with the data we have available, but we're not always going to get it right, and that's when giving users options to customise their experience could be helpful (if done in a way that does't impede the experience for everyone else).
Something we need to think more about, I reckon.
@Derek I totally agree, every project is different. Even something as simple as changing the font means reconsidering the ideal column width, which has a huge knock-on effect on a layout.
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
I am all for content-first strategies. The problem with this approach though, is it seems all the tools and libraries available are optimised for layout-first grids. Right now it seems like each developer is on their own, having to read generic advice and apply it on a case-by-case basis.
I wonder if it is possible to distill a finite number of content types from the wide spectrum of content in the wild? It would seem like this is a necessary step towards being able to offer advice, tools and libraries that are both practical and specific.
PS. after authenticating with Twitter, I was sent back to the home-page: not very convenient. 😛
The examples currently appear to be broken. Thought provoking article and the water analogy is a good one.
@Rob Wood Strange, the links are working for me. Perhaps it was a temporary hiccup.
@Rose Weisburd They work fine now. I think it was a problem with http://responsive.is so not the article at all.
Apologies to the author!
Thanks for the article.
After reading a number of articles on responsive and fluid web design I’d like to offer my own quirky perspective.
I can see the benefits of setting up mathematical routines that serve to rearrange a set of visual elements within any number different rectangles but, for me, the benefits seem to be primarily in speeding up productivity.
However, it seems to me that a number of the articles in ALA’s “Responsive Design” category are casting fixed designs/layouts in an unflattering way.
The wish for that which might be called Eternity is seen as a foolish wish.
In contrast, the wish to ‘let go of control’ is associated with an outlook that would be held by a Buddhist sage.
I wouldn’t have such a difficult time accepting the premise of setting up an automated layout routine if this premise was being presented as a solution to certain economic and time constraints. Instead, these automated layout routines are endowed with an air of mysticism which, to me, seems unnecessary and misleading.
I would prefer to let myself fall under the influenced of a design (e.g. building, website,…) of a human being who was engaged in an inner process of observing how a set of spatial relationships influenced his/her being, and who was then able to recognize in him/herself, and communicate (via stone, glass, wood, pixels, etc.) something of a universal idea or feeling.
The alternative would be to let myself be influenced by a mechanism that calculates how far a wall should move away from me when I walk into a room (responsive architecture), or how my column widths distribute themselves (responsive web page).
If the current economy was able to support a scenario where a strong designer actually designed (manually) twelve different fixed layouts, each for different devices, I would get more pleasure in looking at how she or he tried to communicate the same feeling/idea in twelve different ways.
In this world where “content is king”, apparently aesthetics is the lowly serf. Visual relationships are demoted to the level of “style”.
Sorry to be such a contrarian.
I have started using Gridset recently, it is incredibly simple to use and allows for much more flexibility than responsive frameworks. it is easy to amend and integrate new grids, which I think possibly solves the layout sell-by date problem.
James,
I took a look at a couple of the Gridset demos, and I think it’s pretty amazing that the developers have come as far as they have with this goal of aiding designers in organizing visual elements.
The one thing that I still wish to see is an approach to design where two-dimensional areas are related to one another. In the article above Chris mentions the notion of “important relationships”, and I think that strong 2D design is based on these relationships.
As far as I can tell, Gridset (and I haven’t yet looked into other tools) seems to take the ratios that we wish to establish — for example, the ratio between column width and gutter width — and maintains that proportion when I alter my browser width. So, this tool gives me a scalable harmony in the horizontal dimension.
Next, I see that the CSS handles the ratios between font-size and line-heights so that even as I change my browser’s width these ratios are preserved in the vertical dimension.
What would be great is if the horizontal relationships could be “synchronized” with the vertical relationships. This would bring true 2D design to web layouts. In his book, The Elements of Dynamic Symmetry, Jay Hambidge writes about Ancient Greek design (p. 18), and mentions that their great achievement was to think in terms of area relationships rather than linear relationships.
It really seems like a challenge to invent an automatic grid system.
Incidentally — and I’m reading the Jeremy Keith quote above out of context —once I learn from the client what it is that they wish to communicate (through conversations, and by looking at the text and images that they provide) I think that a predefined grid system and a predefined color scheme make a good deal of sense … and, until I come across a grid system that marries the vertical to the horizontal I’ll keep working off of my old hand-made grids.