Understanding the fluid grid: part one
I love designing with grids and I think the whole responsive design movement is pretty cool (if you haven’t already done so you should check out Ethan Marcotte’s Responsive Web Design for a comprehensive introduction to the area). However, I haven’t been totally clear in my head how the two things relate. Ok, I’ve read about the fluid grid but I’ve found it a bit tricky to pin down what this actually is.
With this in mind I thought it was time to move away from nailed-down desktop-favouring fixed width grid designs and venture into the slightly scarier world of responsive fluid grids. As I always learn better by doing than by just reading I decided to create a example website and go through the whole process from planning to coding, which I’ll share here in case you’re interested (of course you are!).
There’s quite a lot to this whole fluid grid business so I’ve broken up this post in to two sections: first we’ll consider how we might approach a responsive design conceptually and at the visual design stage; in the second part we’ll look at turning the design into HTML/CSS to see it in action.
Some definitions first…
I’m going to be concentrating on fluid grids in these posts rather than responsive design per se. So, what is a fluid grid? Well, let’s think about what we mean by grid first. Wikipedia defines the typographic grid as,
a two-dimensional structure made up of a series of intersecting vertical and horizontal axes used to structure content.
Sounds reasonable to me. In print (or fixed width web design terms) these intersecting axes combine to produce modules or units of a predictable fixed size with which to construct your layout and give it consistency and rhythm. When we go fluid the units–I’m going to use this term rather than “modules” to avoid confusion down the line–will still structure the content consistently and predictably but their size and positioning will change depending on the available size of the rendering device’s display.
We should be clear than fluid grids are not in themselves responsive web design. Responsive design is a combination of a number of elements, fluid grids being one, the others being the use of fluid images / media and the use of media queries to load in CSS depending on screen size.
Designing for responsive, er, design
You could use fluid grids in an old-fasioned fluid design where the grid units resize according to screen size, but in a true responsive layout it’s likely your grid will reflow when the screen size changes. For instance, a 16 unit wide grid may be fine on a desktop or laptop browser but an 8 unit wide grid may be more suited to a tablet (or a desktop browser at a smaller size) and a 4 unit grid to a mobile screen. Of course it’s not just a case of halving the amount of grid units on a screen and moving the remaining content on to the next line: it takes more thinking than this to ensure your desired content hierarchy is reflected at different resolutions. One of the reasons that true responsive design is pretty demanding; but that’s good, right?
Introducing our sample site
The site I’m going to be using is a real site for a project I’m currently working on for a basic HTML/CSS framework simple enough for designers to do rapid prototyping with but powerful enough to use for proper site builds. SPIL (simple powerful interface library) is written in HTML5 and uses OOCSS concepts to make code easy to get to grips with and maintain. But, more of that later. SPIL is due to be released under an open source (BSD) licence and will have its own website containing information about the project, a download link, documentation and a gallery of projects built with SPIL. Nothing too complex.
This is our Photoshop comp showing what the user will see on a desktop-size screen: a 16 unit grid taking up 960 pixels of screen width.
Before we launch off into fluid grid land we need to make some decisions about the kind of devices and screen resolutions we’re going to support and our audience. Well, luckily we can bypass a lot of the user research you might normally do at this stage as we know the users most interested in this are going to be designers and front-end developers. So we want to ensure we cater for our highly tech-savvy audience and make sure our site looks good on desktop, tablet and mobile.
Let’s consider the contexts in which people might be looking at our site. Again we’re going to make some assumptions here based on our own knowledge and experience. If you want to download a framework and play around with it, chances are you’re going to be on a desktop or laptop. However as we know that the web world will be all-abuzz about SPIL (yes, I know, just pretend ok?) let’s imagine (try hard now) that people will be sharing it with others at conferences and meetups. So our design should reflow to display clearly and usefully at the kind of resolutions we’d find on tablets and mobiles.
We’ll call our target layout sizes “desktop”, “tablet” and “mobile” but of course this is a little misleading as a desktop browser is capable of displaying all of them depending on its viewport size; likewise a tablet browser could also be resized to show the lower size.
Before we can make any design decisions we should think about our content hierarchy and what will be important to different users.
Let’s look at our comp again. We’ve got four rows with 3-4 groupings of information on our main “desktop” layout. Let’s categorise them below (leaving aside the header and footer).
Row “A” (About):
1. What is SPIL?
2. How does SPIL work?
3. Download button
Row “B” (Documentation):
1. Code example one
2. Code example two
3. Full list of tutorials
Row “C” (Examples carousel)
1. Screenshot one
2. Screenshot two
3. Screenshot three
3. We love (links to other sites)
As we’ve got less screen real estate on a tablet we need to think about structuring our content accordingly: we still want the most important information most prominent. We’re going to use a 8 unit wide grid for our tablet design, half the amount we’re using for the desktop.
Arguably the download button is not so useful for tablet users as they won’t be working with the framework in that environment. However, remember that this resolution is also available for desktop users and we don’t want to assume that tablet users definitely won’t want to download the files. So we’ll want the first row to display our initial row “A” information about SPIL but will move the “download” and “news” section to the row below thus:
We’ll handle the “documentation” section in a similar way:
Our initial row “C” is a carousel of three images. We’ll make this smaller for our tablet design, just showing two of the images at any one time:
Our initial row “D” can be reflowed thus:
Our mobile design
We need to think more carefully about our mobile design: we’ve obviously got even less space than for the tablet design so we want to be cautious about what we show.
We’ll be working with a 4 unit-wide grid for our mobile design. We’ll reflow our initial row “A” information accordingly:
For our initial row “B” information we’ll do some editing. We don’t want our page to appear too cluttered on a small screen so let’s dispense with the “teaser” code examples and just list out our tutorials:
In terms of example websites we could decide to edit these out entirely or just display one image:
For our initial row “D” information we’ll just stack these on top of each other but for the sake of a more concise page we’ll leave off the links to other sites.
So, would you bother creating Photoshop visuals for these design as it’s tripling the amount of work you need to do? I guess it would depend on the size and scope of your project and the client you were working for. But in our case we’ll just use our sketches to inform how our layout and content will reflow at lower screen sizes but will do all the work in-browser.
So, so far we’ve thought about what a fluid grid is and how it relates to the area of responsive design. We’ve also thought about our site’s content hierarchy and how we would want to present this at different screen sizes. With all this considered and documented it’s time to move on to the only place we can see responsiveness in action: the browser. But that’s for next time!