The DIY Responsive Grid
Here there is also a Step by Step on how to use the grid system
The DIY Responsive Grid is a no-framework solution for building robust and very stylish responsive design grids for the web. @lbertenasco and I developed it briefly after reading grid concepts from Thinking with Type, so be warned of designerish slang. @lbertenasco and I are developers, not designers, so below I share the story of why, which is an important part of the rationale behind the DIY Responsive Grid. I think you may empathise with our rationale.
We focused our attention in this subject after several joint projects with Gonzalo Nogués, a designer friend of ours. These projects were based on original designs he did, so our framework of choice at the time (Bootstrap) was not an option. Or any framework, for that matter.
That said, it was kinda hard to find a reliable solution to web grids without using any frameworks. Twitter Bootstrap does such an amazing job that is easy to be tempted. Furthermore, for a developer, frameworks can easily provide not just a tool but also a much needed style guide to avoid design blunders, so frameworks tend to stick even if they are not appropriate. We dropped the frameworks anyway and started from scratch.
Once ported to web, the designs featured several deviations from the original and we got surprised on how much Gonzalo stressed the importance of correcting those deviations. We realised that we were unprepared to understand the importance of seemingly minor spacing mistakes. So we decided to get a little into design terrain and teach ourselves with the awesome tools in HackDesign.
We did. Then, we experimented.
We discussed these topics abundantly and came to the conclusion that existing solutions were unable to:
- Replicate the robustness and beauty of printed designs based on modular grids (mostly a flaw of proportional grids).
- Be sufficiently customized to produce organic results (mainly a flaw of grids with few breakpoints).
Furthermore, the available grid solutions are mostly frameworks, which impose on you the need to load another dependency into your projects and require from you to learn yet another API. Once the framework eventually falls out of favor, this knowledge is useless. This is even more detrimental for an organization, which needs to keep everyone up to date—and training can be a significantly time consuming activity.
In my view, avoiding frameworks whenever possible is the way to go.
The current approach (and why it does not work)
Very popular grid systems today usually employ one of two approaches:
Proportional spacings (for fluid grids)
Under this approach, both the columns and the spacing between them are determined by percentage points of the browser width, keeping little to no correlation with the vertical spacings—the baseline grid. In fact, this approach allows for no modular grid at all in the traditional sense.
Examples: Twitter Bootstrap, Foundation.
The main flaw of this approach is that horizontal spacing invariably gets broken. Traditionally, web interfaces gave less attention to the horizontal-vertical spacing relationship because of the fundamental flaw of CSS that makes proportional vertical spacing almost impossible to achieve. So developers can be excused. There is, however, that while managing to keep horizontal spacing consistent may be hard, inconsistent spacing simply breaks the design. More to come about this.
Fixed width (for static grids)
“One size does not, actually, fits all”, Common Sense Jr.
This approach is closer to the pre-responsive era of web design, when fluid layouts were almost inexistent. Fixed width grid systems usually derive from a static pixel width (one very popular being 960, due to its divisibility), and formulate a series of possible column widths to go with the total pixel size.
Examples: 960 grid system, Blueprint CSS
Fundamentally non-responsive, the resulting layouts are usually responsivised afterwards by falling back to a smaller, single column layout for smartphones—and if you are really lucky, a middle term tablet size.
This device driven approach of using sizes aimed at product categories is doomed due to inevitable shortcomings in support. Device manufacturers are not constrained to the approximate sizes taken for granted by the frameworks, and furthermore, innovations such a gigantic screens will not be addressed. A more appropriate name for this approach would be, not static, but statu quo.
Leave no user behind
Making a beautiful design piece is hard work, and is hard enough when only one size has to be considered. The designer needs to control many things: typography must be big enough to be legible but line widths should be large enough to accommodate at least 50 characters so the text is easy enough to read. Font size is hard to determine.
The thing is that, once determined, the design suffers rapidly if the line width varies. Most current frameworks allow for line width to vary from far too long to far too short, making the text hard to read in many devices. So, truly fluid grids are not really user friendly: they inevitably break the experience.
Try this: imagine that for some reason you want to read a wikipedia article in a 550px width window. There is a plausible context for this: imagine you are researching for a paper on Wikipedia, and you work side by side with your text editor occupying half the screen and your browser occupying the other half. Why should your experience degrade if you are resizing the browser to an unusual width? After all, browser resizing is a basic feature of the web. Your website should enable this power to the user.
I call this the “I just want a small window” test. As a matter of fact, Wikipedia fails it.
Note: I usually end up using the mobile version of Wikipedia in desktop just to be able to resize at will. Many people doesn’t even know Wikipedia has one.
The designer’s insistence
Along with the very widespread legibility issue on arbitrary browser sizes, we noticed that our friend’s insistence was also related to the care that he applied to positioning in Photoshop. He didn’t just throw things around: everything was carefully placed, pixel by pixel. We soon learned that the general effect relies entirely on the details getting properly executed. As the saying goes “is the little things”.
This meant to us that proportional width grids were not an option. Inter column spacings should be kept to a size equal to the line height size for good rhythm—but also column widths had to be kept as designed so to maintain the rhythm and legibility. What was for a developer to do?
We set out to build a from scratch solution.
Beyond layouts: grid and beauty
Usually, web designers use grids to align structural elements, not visual ones. Take a white background website: images in it with a large white background may be perfectly aligned from the technical point of view, but may also float awkwardly or unbalance the design from an aesthetic point of view. With this difference in mind, we set to build on the properties of grids that exist in order to benefit aesthetics, not just positioning.
One striking remark from our friend was: it doesn’t really matter if your column width plus the inter column spacing do not exactly sum up to the width of the container. That is not what is breaking your design. What is breaking your design is making columns of awkward sizes (for example, two columns size 3 and one column size 4 to sum up 10), because they look out of rhythm. Some space you can just buffer from the borders. Thinking about that and researching throughout the web I feel like there exists some sort of horror vacui in current web design: the layout fills every space, even when there is no need for that.
So that’s what we did—we buffered. And that was the eureka moment.
You see, there is no silver bullet for web grids as there is no silver bullet for the traditional grids on the printing media. The grid is a formative part of the design, and as such, cannot be added afterwards or imposed as a pre existing constraint to a design without making the final product suffer. Our initial grid stems from a 15px font size and a 18px line height, giving a traditional 1.2 ratio—all nice and efficient, but why should we impose that sizes and proportions to you? Why should we add you some constraints where none exist?
You must be able to tailor your grid to your needs. For this, you need not just a grid system but also a grid justification system: one that allows you to justify why are you using this grid, and not another. You need (and I can’t stress this enough) to be an active part of the design process.
The DIY Responsive Grid stems from a base font size and a base line height. Those two sizes set the em to line-height ratio, useful for defining sizes in CSS. The line height also serves as the reference for column widths, column spacings, container widths and the baseline grid. Similar to a musical composition where the ratio written close to the G-clef sets a base fabric for the piece, the ratio of font size over line height determines several key factors about the design. Once you have chosen these two values, the rest can be determined by simple mathematical formulae.
You will see that while the final values can be expressed in terms of pixels, we prefer using relative measurement units such as
ems andrems because of several clarity and accessibility advantages. We even do so for media queries.
So, what happens with breakpoints?
Well, we invite you to choose how many breakpoints you think you need. Obviously, three looks like a reasonable minimum: but don’t stop there, for your users sake, don’t stop there. Run the “I just want a small window” test on your website instead of using device size simulators. Adjust the amount of columns and the column size once per breakpoint. Bear in mind that while images may scale just fine, texts gets easily broken when resizing.
Besides that, is really up to you. The DIY Responsive philosophy boils down to:
- Make sure it looks great,
- ...on as many sizes as you can,
- ...while making the grid your ally.
True commitment
There is, of course, a more radical approach to web grids that is a true web innovation, and worth noting for its beauty: that is, tailor manually your content to each size, with as finer precision as possible. This can easily lead you to OCD, but the results are astounding: take Trent Walton’s website for example: he took the time to add an amazing amount of breakpoints which affect the content part by part as you resize the browser, and the effect is almost hypnotising.
A List Apart, which you may recognize as the magazine where the term responsive started to spread, features a similar grid concept, although not as detailed as Trent Walton’s.
This is what you may call “true commitment” to the aesthetics of the web. If you can find the time, if you can afford the therapy sessions afterwards, I sincerely recommend this approach, which lays closer to the “dao” of web design.
But for us which live in a world with less control of the content and harder constraints given by UI needs…
…it exists the DIY Responsive Grid.
Now go the the Step by Step to start using the grid or grab the Calculator
