An Expert Roundtable Discussion on Responsive Grids

responsive_blogheader

While presenting information online is a design problem, the challenge of making it work is technical. Web designers use CSS frameworks to focus more on the former and worry less about the latter, just as grids — a staple of design — provide guidelines for layout.

But responsive design needs to do more than create columns and rows. When a medium changes, what happens to its tools? We talked to three experts about the issues and challenges facing grids for web design.

Nathan Ford is a Texan expat currently living in Wales. He is the creative director at Mark Boulton Design and creator of Gridset.

JD Graffam runs the award-winning web design firm Simple Focus, serves as president for AIGA Memphis and serves on the Editorial Review Board of Smashing Magazine. He is also the author of CSS for Print Designers.

Jonathan Smiley is a partner and design lead at ZURB, makers of the Foundation framework.

Treehouse: Grids in print design are not new. But increasingly web designers lay out pages that change based on available space. What design problems, if any, must grids for the web address that grids for print do not? Likewise, are grids for web design free of problems that grids for print faced?

Jonathan: The biggest challenge for grids on the Web is to work on the huge disparity of devices and screens out there. If you print a magazine, you don’t need to worry about that physical magazine being given to something in an 8×8 square, smashed down to fit on a watch, or blown up till it’s three feet wide. It will always be the size of the magazine.

Grids now need to not only work on a phone as well as a 30″ display (or hell, an 80″ TV) but they also need to help people understand that the way you show content on a TV might not be the same as a phone. Fluid grids help a little bit, and responsive grids (ones which reduce the column count either lower, or to zero, for smaller screens) help too, but still don’t solve everything. Navigation is different, content headings might be different, how images are shown or enlarged might be different… It’s a big, scary world and grids can help, but they don’t do it all for you.

JD: In my first job, I designed a billboard for the Mississippi Band of Choctaw Indians to promote the annual Choctaw Indian Fair. When I came up with the base design for approval with my creative director, I showed it in a single size, or proportion. But when I started preparing the files for distribution to the outdoor company, I found out that there were several different dimensions for the billboards in our ad buy. I had to slightly tweak the design I came up with. While I had a single design, it was executed with different proportions—some billboards were extremely horizontal, some were closer to a square.

As I see it, a grid is just a tool, so it shouldn’t be inflexible. It’s there to help us accomplish a visual harmony, not to direct us. I think web design works the same way as print design: Our grid should adapt to the context of our environment. Every different resolution needs a human eye to make the proper adjustments. In the end, the grid is just a guide for designers in any medium. We should never be slaves to a grid; our job as designers isn’t to define the grid, but to see it in our unique, current context and follow its lead to a certain extent, then follow our gut.

Nathan: I wouldn’t say achieving any grid on the web is more difficult than in print. In fact Gridset was designed to make it very easy!

The web is fluid by default, therefore grids on the web must also be fluid. Once you accept this, you no longer need to worry about every screen size that comes out, just whether your site works on a spectrum between the smallest to the largest.

Left-right grids on the web are well explored and well established. Web design thrives in systems and constraint, and grids give much needed structure to the myriad content types that may be added to a site. The major challenge with grids for web layouts is controlling the vertical grid. Where a vertical grid is easily applied to the established content of a print design, web sites usually have a content influx of new content and patterns, making it near impossible to bring any structure or balance to the vertical layout of elements.

“It’s a big, scary world and grids can help, but they don’t do it all for you.”

Treehouse: Years ago designers arranged pages with tables for lack of a better layout tool. Are current languages like HTML5 and components of CSS3 up to the task? Or will future designers remember classed divs the way we remember tables?

Jonathan: Good question. It’s certainly better than tables if only because a div doesn’t carry any layout baggage with it — a table row is a row, always a row. A div might be a row, or a column, or a panel, or a header block, or… etc, etc, etc. You make it as semantic as you want. That being said the work being done with Flexbox or some of what Adobe is pushing for content flow might make grids as we know them now less relevant.

The biggest change we’re likely to see will not be with what the underlying code is, but what our tools are showing it to us as. As the tools evolve, so will our concerns. Adobe Edge Reflow is a great example: It creates a bunch of divs but at some level, it doesn’t matter. It’s really creating Adobe Edge Reflow content blocks, which have their own properties and functions. Look to see the tools we use elevating our concerns away from the actual HTML elements we use day to day.

JD: I’m not an expert on this topic, but my short answer is this: Without a doubt, technology will change as smart people come up with better ways to do things. HTML5 and CSS3 do the job for now; in the future, we’ll have better tools. I’ve yet to see technology get worse as time marches on.

Nathan: I am a firm believer that we don’t need to move on until we master the tools we have. HTML5 and CSS3 are absolutely up to the task. Gridset CSS output, for example, is compatible back to IE7 and allows for more complicated grids than most people ever attempt.

Flexbox and Microsoft’s Grid Layout proposal both will make complex layouts easier to develop, but that does not mean that web designers will brave new frontiers of layout. The greatest growth for layout in our industry will be to shake people out of 12 columns at 960px wide, and educate them in deeper grid theory.

“HTML5 and CSS3 do the job for now; in the future, we’ll have better tools. I’ve yet to see technology get worse as time marches on.”

Treehouse: Some sites account for varying widths (e.g. 320-, 800- and 1280-pixel-wide browser windows) by designing different layouts for specific breakpoints. Other sites employ subdomains with mobile-friendly designs. What criteria might determine when each approach is best?

Jonathan: At ZURB we’ve doubled down pretty hard on responsive design, meaning we don’t create a separate mobile experience. That being said, the best way to look at this isn’t what is best for the user: They don’t care whether you have one codebase or 10, they want a good experience on their device. Look at it from the perspective of resources, focus, and time. We love responsive design because in most cases it makes a device-agnostic interface possible, albeit maybe not perfect every time. Something that works everywhere is better than something that doesn’t (generally).

JD: The most important decision is your content. If the content should be different, use a separate View. But this isn’t always the best case, you also want to consider performance and interaction design as well.

Nathan: At Mark Boulton Design, we design fully fluid layouts that adjust at certain breakpoints, allowing any page we design to be usable and comprehensive at any size. This is a good default given the myriad of screen sizes out there, and the growing behavior of users to not browse full-width.

On top of that foundation, the need to break out subdomain redirects to certain sizes is a strategic decision that usually has more to do with the site’s content than the design. I will generally let our clients tell us their needs and then work with the development team to find the right balance of each.

As Jeremy Keith always says: It depends.

Treehouse: For that matter, is there another way besides layouts per breakpoint and layouts per subdomain?

Jonathan: Layouts per device capability would be another — an interface for touch and one for click and soon, one for your glasses and one for your car and one for voice and one for… etc, etc.

JD: We sort of mooshed the two once, with oakhall.com. It’s an adaptive layout behind a modal overlay that serves up mobile-friendly contact info for phone visitors.

Nathan: You can always just use one fluid column. Lately, I have been approaching layouts with a mind towards limiting the need for breakpoints. By keeping the left-right positioning simplified, you can provide greater focus on your content, which will lead to a better reading/viewing experience.

Treehouse: Also related, prior to 2007, designing websites for screens at least 800 pixels wide was common practice. Designing for 320×480 screens was laughable. Are today’s common breakpoints (480px, 768px, 960px, 1280px, for example) likely to hold up in the future? If not, how should designers judge to which standards, if any, they should adhere?

Jonathan: Basing a design on pixels is a crutch we’ll outgrow soon. How many pixels are there on an iPhone 5? Well, 640px across, but it gets reported as 320 to the browser. My 15″ laptop screen is 2880 pixels wide, quite a bit more than my 55″ TV. It should come down to how much content comfortably fits on the physical size of the screen so that people can read it/use it. Ems are becoming a decent way to do this, and more will probably come up.

JD: Ultimately, these decisions should come down to readability, because the Web’s purpose is most often to serve content. As screns get larger or have higher resolution displays, font sizes should adjust accordingly. As those adjust, widths of columns need to adjust so that we have an ideal number of words and characters per line.

Nathan: Fluidity is the only answer to future-proofing a site. Building to common breakpoints will only lead to more work and broken experiences. Build a fluid layout, then adjust at the points where it breaks down, not at pre-defined screen sizes.

Treehouse: In 2011 web designer Chris Coyier suggested that designers should aim for popular browser widths rather than screen widths. Assuming users view sites with arbitrary browser widths, by what other criteria should designers decide to compose a web page?

Jonathan: Media queries already work based on browser size, so while I think Chris had a good point I don’t see it come up much. Design for your content. If your page is a single column blog it doesn’t matter if someone is on a 17″ laptop or a 5″ phone — there’s only so much horizontal reading people can comfortably do without losing their place.

JD: At Simple Focus, we usually design that original layout at 1000 pixels because it’s a good round number (easily divisible), it’s a comfortable width and a few pixels up or down won’t make a huge difference with a responsive layout. Then we accomodate smaller and larger resolutions accordingly.

Nathan: The content and user goals should take precedent over any perception of a canvas. Mark Boulton has been talking about a content-out approach for years now. Start by focusing on the experiences where you have the most material and goals, then work out from there. Sometimes it will be mobile first… it might also be prudent to worry about the lean-back experience on a 40″ TV first.

“Fluidity is the only answer to future-proofing a site. Building to common breakpoints will only lead to more work and broken experiences.”

Treehouse: CSS grid systems I’ve used often start with 8–16 columns, flex or shrink to fit certain widths, then drop to a single column for mobile-device-sized screens. Yet I would think that page layout on a mobile device could still benefit from a grid-based layout. Icons arranged 3×3, tabular data, two-column forms, for example. Can designers use a single responsive grid to lay out both mobile and desktop pages? Or does mobile design require a new set of rules?

Jonathan: They certainly can — if it’s the right grid. This is very self-serving but at ZURB in our framework Foundation we’ve implemented a large device grid, small device grid, and a mobile-first single column style all in one grid. That way if the device supports columns you can use a diminished (or not, for that matter) number of columns. Things like 3×3 grids are still available on mobile but can be turned off selectively, etc. If you’re not going to code it all up yourself, use a framework from someone who’s already considered the problems.

JD: Sure, we [use the same grid] all the time.… Example markup [provided by SimpleFocus developer Casey Zumwalt] would be:

<div class="container twelve mobile-four columns"></div>

So with Sass mixins we can define how many columns equal 100% on both desktop and mobile. In the case above, "mobile-four" is 100% width, as it’s defined as such by default, then we use media queries to trigger the two different grid systems. …We can define rows and columns. For example:

.container { @include outerRow(); }

That’s the equivalent of <div class="container row"></div>. But with clean includes, we only show <div class="container"></div>, which is much cleaner. And semantic. Granted, the semantics of “container” could probably be argued. But that’s another conversation.

Nathan: Gridset allows different grids per defined breakpoints. This is what I recommend. Think about the available space at each point and the needs of your content, then work out a grid to support it all. Repeat for each breakpoint.

Most grid systems tend to have two things in common: too many columns, all at the same width. The fewer columns you have, the more clear your content’s hierarchy (and therefore intent) will be. We are also not yet realizing the full possibilities afforded by using uneven column widths. Gridset gives us the ability to explore this frontier.

Treehouse: Most CSS grid frameworks embed layout instructions to content, usually as class attributes in HTML. A value of “col-6,” for example, implies a block six units in width. Does writing such instructions into HTML defeat the purpose of design that adapts to varying devices? If so, is there a better way?

Jonathan: It’s looked down on for being “unsemantic” which is a slightly incorrect way of saying the data and display aren’t separate. Newer systems that work with a preprocessor like Sass avoid this by allowing you to attach the grid sizes to the element at the CSS level, rather than the markup. Same syntax, though the separation is cleaner. The next way around this will be to use a tool that lets you not worry about the columns at all, just size your content to the right proportion element by element.

JD:Yes, it defeats the purpose. A better way would be to look at what ZURB did with Foundation. From memory, they have written the class names as such to handle layouts and grids, but they let you configure your classes with Sass using variables or something so that your HTML casses can remain semantic.

Nathan: I tend to agree with Nathan Smith (creator of 960.gs and unsemantic.gs) in thinking that classes are not necessarily semantic attributes. Tag names and IDs do a better job of defining the content. This leaves classes fairly open to do whatever the developer needs.

Classes allow speed, flexibility and focus when building prototypes, but can get cumbersome to maintain in production code. Therefore any system that requires the use of classes should also have a path to safely removing them without destroying the layout. In Gridset, we give you access to all your measurements via a Cheat Sheet so you can reverse-engineer your layout in your own custom CSS. Our new Sass output makes this even easier by calculating your grid measurements on each compile, removing the need for Gridset classes entirely.

Treehouse: I’ve worked with people (designers and clients alike) who have specific ideas for their sites’ layout, but I’ve rarely heard people ask for W3C-compliant HTML. How much emphasis do you think designers should give to semantics?

Jonathan: Enough that it works in modern browsers. Browsers are the all-star, unending champs of showing things written the wrong way, the right way. Sometimes we get a little spoiled thinking browsers are out to get us when really, they do miracles with crap markup all the time. Valid HTML will help your code look right more often than not, so that’s great, but there’s not a consumer in the world who cares if the page [he or she] is looking at is W3C valid. They just want it to look “right.”

JD: I think they should give the same care and concern as an architect does to his or her engineering. Although we’re not required to get certifications for safety, we should have standards. And follow them. Plain and simple.

Nathan: Semantics are only going to become more important as tools such as web consumption tools such as Readability and Twitter continue to get smarter about how they incorporate content. The intent of content must be clearly defined by the markup. That being said, I am not sure that classes necessarily fit into the semantic value of markup.

Designers need to be aware of these issues, but they only need to know it intrinsically if they also markup their designs.

Treehouse: Thanks for your insight on responsive layout practices.

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from HTML, CSS or WordPress.

Start Learning

Ben Gremillion

Ben Gremillion started playing with pixels in the mid-1980s and building websites circa 1997. When not hiking or stargazing, he crafts HTML and CSS, spends a lot of time debugging PHP and MySQL, ponders the details of user experience, and injects bits of personality into staid websites. He blogs about his lessons learned in web design at benthinkin.net.

Comments

Comments are closed.