Dive into Responsive Prototyping with Foundation
Issue № 348

Dive into Responsive Prototyping with Foundation

There are hundreds of devices out there right now that can access the full web, as Steve Jobs once put it. These devices come with different capabilities and constraints, things like input style or screen size, resolution, and form. With all these devices set to overtake traditional computers for web traffic next year we need tools to help us build responsively for these devices.

Article Continues Below

There are many tools to accelerate front-end design, such as Blueprint or 960.gs, but, until recently, the tools for responsive design—design and implementation that accounts for all these different devices and capabilities—were few and far between. There’s Andy Clarke and Keith Clarke’s 320 and Up, and Columnal, a responsive grid system. Recently, Twitter Bootstrap went responsive.

Today, we’ll take a look at how you can dive into responsive design using Foundation, a light front-end framework that helps you rapidly build prototypes and production sites. If you’ve avoided responsive design because it seemed difficult, or the tools weren’t there, or you weren’t sure of the need…then this is the perfect time to get started.

A “light” framework#section2

Foundation is a front-end framework that helps you build things quickly. At ZURB, we created it as a boilerplate and general starting point for our own client and internal projects. Not only does it include a 12-column, nestable, responsive grid that gives it much of its layout power, it has other common elements and constructs. Navigation, tabs, buttons, typography, forms, and more are pre-defined with simple styles so you can jump right into code without initially worrying about custom CSS.

You’ve almost certainly used or been exposed to frameworks before, but Foundation is a bit different—it’s designed to be overridden. With front-end frameworks we risk “samification,” sites that look the same because they were built with the same framework.

In our examples, we’ll use the base Foundation styles, but note that these styles don’t lend themselves to a final site design. This is intentional. Foundation will get you 90% of the way there, but the last 10% is where your creativity and design sense come into play.

You might also see that Foundation isn’t quite as idealistic as you might expect—it’s not completely semantic, it’s not mobile-first. We built Foundation to help people get going quickly, without the need for additional tools.

If a truly semantic grid system appeals to you, check out the aptly named Semantic Grid System which uses Less to generate a grid where the data is totally separate from the display. For a mobile-first approach, try 320 and up.

Prototyping for fun and profit#section3

Foundation really shines in rapid prototyping. Prototyping is a powerful and seldom practiced method that’s even more important now that we have so many types of devices, and so many ways people will interact with the things we design.

For our purposes, let’s assume that we’d like to create a book sharing service—not something we’d recommend actually pursuing, with the rise of Kindles and other eReaders, but this is a fun example. We’ll start by sketching out what we want, then we’ll quickly prototype the front-end to get an idea of what the experience is like on different devices.

Sketching out our book sharing service, BookImpart#section4

To get a feel for how our new service will work, and to evaluate the experience on different devices, we only need a few screens. Those are:

  • the homepage, where the user can select a book they’d like to read,
  • a book screen to show who has the book, where it is, and what they’d like to read in return,
  • a modal dialog that allows the user to pick one of their books to offer for trade, and
  • a homepage state that confirms that the trade went through.

Naturally, you can see the holes in this prototype (login, registration, adding books, edge cases like non-acceptance, etc.,) but we’ll look at just this one flow. We’ll begin, as we begin most any interface design, with sketching.

On BookImpart we start the homepage with the site name and some simple login actions (which we won’t hook up). Categories are on the left-hand side to encourage exploration on larger device screens, and we’ve featured three books we think the user is interested in. We’ve used tabs to show top swaps, popular books, and trending books.

Fig 1. Our fictional service’s homepage. Left-hand nav and a main content section.

On the book screen (in our prototype, we link every book to this page) we retain the nav and show the large book cover, title, and info. We also show a list of the books this user has that they can swap for the book they’re looking at, so they know if they have any options and what they are. We could partner our service with the Times to pull in reviews, too.

Fig 2. Our service’s single book page, featuring the book itself and what could be swapped for it.

Once the user selects the Swap action, we use Reveal (a modal dialog plugin built into Foundation) to show a modal with the books they can choose to swap for this one. The user picks, and we take them to the confirmation page.

Fig 3. Modals like this are simple using Reveal.

Here we show the user what they’re giving up and what they’re getting. We’d also probably want to say how the swap will happen (by mail, in person, etc.,) and give them a way back to the homepage.

Fig 4. One last page, the confirmation screen, and our prototype is good to go.

In a normal project, we might do several rounds of these sketches, getting feedback from the client or from colleagues, but we’ll bypass that here. From here on out, if you’d like to follow along in code, go ahead and download the Foundation code pack from foundation.zurb.com. You can work with the index.html file we provide, and duplicate that for the additional pages.

Coded wireframes#section5

One way to think of rapidly-built prototypes is as coded wireframes. This practice has been around for a while, but only recently has it been practical to create responsive coded wireframes.

The grid I mentioned earlier handles the lion’s share of our prototyping. It’s 12 columns across and completely fluid—everything is based on percentages, with specific media queries to adjust it for small devices. A simple layout might look like this:

<div class="container">
  <div class="row">
    <div class="eight columns">Main Content</div>
    <div class="four columns">Sidebar</div>

…where the container gives us some left and right padding, the row has an arbitrary max-width for readability, and the columns create a two thirds / one third page layout. We could also nest the columns like so, to build more complex layouts:

<div class="container">
  <div class="row">
    <div class="eight columns">
      <div class="row">
        <div class="two columns">Avatar</div>
        <div class="ten columns">Article Title</div>
      <div class="four columns">Sidebar</div>

Grid system enthusiasts will note that we’re not using a system like semantic.gs to fully separate the data from display, for a couple of reasons: using a system like that requires a preprocessor like Sass or Less, and we’re not crazy about the CSS you actually end up with using that approach. It’s a great idea, but thinking pragmatically, the traditional grid system syntax still seems like the best option.

Within this prototype, we’ll also use Foundation’s buttons and tabs, as well as some placeholder images courtesy of the excellent placehold.it service. Taking our homepage sketch, we’ve annotated it to show how we’d like to code it:

Fig 5. We’ve sketched in how we’ll break up the layout using the Foundation grid.

No more stalling. Here’s what the code looks like.

Our homepage is actually the most complicated page we’re prototyping, and it’s pretty simple to put together. The grid handles the majority of the layout. We’ve already seen examples of it, but let’s look at one more. Notice the section about Top Swaps, a tab toward the bottom?

Fig 6. By embedding rows within our tabs we can easily create this kind of layout.

We could use custom styles to create the layout in those entries, but with Foundation we can simply nest the grid. While that entire column is an .eight.column section, we can put additional rows inside the tab container, each of which can contain twelve more columns. So our list entries become two columns, seven columns, and three columns going from left to right.

The tabs themselves are fairly simple. Hooking them up to display different content requires no JavaScript (or CSS). The syntax for the tabs looks like this:

<dl class="nice contained tabs">
  <dd>Top Swaps</dd>
</dl><ul class="nice tabs-content contained">
  <li class="active" id="topTab">
    Books go here…
  <li class="active" id="popularTab">*changed indent here*
    Books go here…
  <li class="active" id="trendingTab">*and here*
    Books go here…

When we map the anchors in the tabs to specific IDs, as we’ve shown above, the built-in JavaScript will automatically switch tabs and apply the correct classes. We could also link to this page with a tab pre-selected, with index.html#trending, index.html#popular, etc.

Finally, let’s look at buttons. For this prototype we’ve kept everything clickable within our prototype as link color (blue) and scaled back everything else. To create the different buttons in the prototype, we simply create anchors with a class of “button.” We can then add a few classes to gussy them up:

  • “nice” gives them some depth and shine, purely for clickability,
  • “radius” gives them a slight border radius, and
  • “round” would make them completely rounded on the sides.

In our implementation:

  • “white” makes the button white, as opposed to the default electric blue. We used this in the header and sidebar.
  • “large” is used only on the Book page, but we also used “small” for the register button.

This is very human-readable and easy to write out. It’s easy to override for the eventual styling. Let’s look at the Book page—you can click on any of the book thumbnails on the homepage to proceed.

On the book page we’ve kept some pieces of the homepage, like the header and sidebar. In fact, the entire layout for this page is built using the grid, placeholder images, and buttons / text. What you might notice is that the images have pixel sizes (supplied by placehold.it) but we’re not too worried about that right now: by default, Foundation will not allow images to be larger than their grid container, so they’re all sized to the layout we want.

If you click on the large call to action “Swap for This” you’ll see the only new element on this page, a Reveal modal. Added after the .container close is this element:

<div id="swapModal" class="reveal-modal">
  <h5>Swap for Neverwhere:</h5>
  <h3>Jason M. is willing to swap Neverwhere for one of these:</h3>
  <ul class="block-grid four-up">
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <li><a href="confirm.html">
      <img src="http://placehold.it/120x160" alt="Book Title" /></a></li>
  <a href="book.html">Never Mind</a>
  <a class="close-reveal-modal">×</a>

There’s nothing outrageous about the content for our modal—it’s very simple, gridded out. What’s nice is how we call it—with an ID on the modal (#swapModal). We can call it by attaching a data attribute to any anchor on the page, in this case the Swap for This CTA button. It looks like this:

<a href="" class="nice large blue radius button">Swap for This</a>

Reveal, the modal plugin built into Foundation, tracks the data-reveal-id and attaches the right actions for us. We have one simple page to go: the confirmation screen. Click any of the thumbnails within the Swap modal to get to the last page in our prototype.

This is a very, very simple page explaining what we’ve done and how it will work with our fictional book swapping service. Since we have so little content, we’re constraining it to the center of the screen on larger devices using grid offset classes. It looks like this:

<div class="row">
  <div class="seven columns offset-by-two">
    <h3>All set!</h3>
    <p>We've started the swap between you and Jason…</p>

Any grid column can be offset by two to ten columns to shift them over, which is handy for creating space or indenting layout.

That wraps up the elements we’re using for this prototype, though it’s only a handful of what’s available. Now, that was all on larger devices (laptop, desktops). Seems like we’re missing something…

About those other devices…#section6

This isn’t an article about building mobile-first—if it was, we would have done our sketches on smartphone sketchsheets, or across several sizes at once. What we’re most familiar with, and we believe the easiest way to start thinking responsively, is to start from larger devices and go down. Now that we have our larger view, let’s look at what Foundation will do for us out of the box.

Fig 7. The prototype homepage seen on a desktop and a small mobile device.

As you can probably tell from the screenshot, Foundation’s default behavior is to “linearize” the page—stacking our grid vertically, with each column running 100% wide. In most cases, this takes care of a lot for us. People are extremely accustomed to and comfortable with a vertically scrolling page with a limited horizontal width. In a few cases, however, this may not be ideal, or least may be insufficient.

Fig 8. By default, we’re using far too much space up top for navigation.

If we’ve come to this page on our smartphone, we’re looking at a lot of navigation before we even reach a book. People are willing to explore a little on small devices, but more than anything they crave content. We can give them that up front through a couple of Foundation affordances: source ordering and mobile-visibility classes.

We want the books we show on the homepage to come first, then show the navigation afterward. Since the page is laid out the way it is, we wrote the navigation first. When the page switches to a small device layout, it’ll come first on the page. We need to write the navigation last, after the content, but have it on the left on large devices. We do this by writing the nav last, but “pulling” it to the left, and “pushing” the content to the right, like so:

<div class="row">
  <!-- pushes this three columns to the right -->
    <div class="nine columns push-three"> 
      Main Content…
  <!-- pulls this nine columns to the left -->
    <div class="three columns pull-nine"> 

Now we’ve got the main nav where we want it, but we may still have users who want to dive into a category right off the bat. To help them out, we’ll put a much slimmer nav construct (a simple select list, for our purposes here) right up front, like so:

Fig 9. With some simple changes to classes in the markup we can much better tailor the layout to small devices.

With the class .show-on-phones (also: .hide-on-desktops, .show-on-tablets, etc.,) we’ll only show that element on small devices, basically anything smaller than your average tablet. Device classes are obviously somewhat arbitrary (What size is a tablet? Are all phones the same?) but from a pragmatic perspective this is easy to handle.

One last thing we should look at is using Foundation’s four-column, small-device grid. In some instances, for example this entry on the homepage, we don’t really want to just “stack” everything, especially not a book cover in a list (which is likely very small). We’ll attach the four-column phone grid to the existing columns, like so:

<div class="row">
  <!-- this column will be 2 of the 4 small device columns wide -->
    <div class="four columns phone-two">
      <a href="book.html"><img src="http://placehold.it/300x400" /></a>
      <p><a href="book.html"><strong>Neverwhere</strong></a>
      <br />Neil Gaiman</p>
  <!-- this column will be 2 of the 4 small device columns wide -->
    <div class="four columns phone-two">
      <a href="book.html"><img src="http://placehold.it/300x400" /></a>
      <p><a href="book.html"><strong>Good Omens</strong></a>
      <br />Neil Gaiman and Terry Pratchett</p>

We implemented this in a few places within the complete code, which you can check out. Now our layout is more concise and representative of the display we’re looking for. Much better.

We’re only covering this in part here—ideally, we’d want to go through each of the screens in our prototype and make some adjustments for different device categories (we’ve done this in the downloadable code). Being able to make these quick changes is why prototyping in code (or prototyping in general) is so helpful. Our book sharing service is getting better with every rev, and we’re not just looking at static screens: we can see how it actually works, cross-device, before we commit and take our code into production.

When you’re working responsively, be sure you’re not just thinking about layout: there’s more to creating a responsive, future-friendly site or app. Optimize your media (loading images or videos). You can serve different files from the back-end or use something like Scott Jehl’s responsive images. Mat Marquis’ responsive images article is well worth a read.

Remember that touch devices have no hover state. Be mindful of the difference in user intention based on different devices. You’ve heard all this before, but it’s becoming more and more critical now.

Prototype early, and often, and everywhere#section7

Your products and sites will be better if you prototype sooner, and faster, and on as many devices as you can. Foundation was built to help do this, and the recent surge of similar tools is extremely heartening. In the next five years, devices will be the name of the game and that’s not just screen size or browser we’re talking about. Interfaces will change, input will change, the way we use the web will change. We need to start gearing up for that right now.

About the Author

Jonathan Smiley

Jonathan Smiley is a Partner and Design Lead at ZURB, a product design agency in Campbell, CA. He's the lead front-end developer for Foundation, and frequently contributes to the ZURB blog where he writes about responsive design and implementation. You might catch him speaking at meetups in the San Francisco Bay area, or you can just catch him on twitter @smiley to chat about web design (or video games).

28 Reader Comments

  1. That’s amazing! Clearly that service concept was floating in the ether and we both picked it up. Yours has the marked advantage of being a real thing. Nice work!

  2. This article is fantastic and I really like the approach you are taking with Foundation. This can really enhance the workflow for responsive web design and conceptualizing breakpoints is the hardest part not just for designers but clients as well.

    Also, semantic grid system looks really cool. I am working on a framework that does something similar but totally agree preprocessor output can get messy. Sass 3.2 with silent selectors and @extend makes things “much cleaner”:https://gist.github.com/2184518

  3. We’re actually planning to move Foundation’s core into an SCSS development environment. We’ve been talking to the guys behind Sass and we’re pretty confident we can implement this in a way that doesn’t have the mess. Foundation will always be available by default as vanilla CSS< but we should have new options soon for those who want a more customizable experience.

  4. I’ve been using Foundation for quite a few months now.

    I find it extremely easy to pick up quickly and be able to produce some clickable functional prototypes and only with a little more effort than drawing up the wireframes themselves.

    It’s currently powering a Facebook RWD Bookstore

  5. Foundation actually includes a number of elements of H5BP, as well as other open source tools and code like Eric Myer’s reset and Modernizr. Foundation builds on top of those to include a responsive grid system, common elements and objects to help build faster, and a lot of best practices code. H5BP is a great starting point to write everything yourself, while Foundation creates a framework in which much of the base code is taken care of.

  6. Mobile web design is quite different from the usual design for computers.
    Today, almost every site need a mobile version,
    Mobile version – is primarily a lightweight version of the most important information. You have to provide a link to the main site if the visitor would like more or all of your information

  7. I’m using this, for sure. What I’d like for future releases would be a few more mobile first helpers. But for now: great work!

  8. This seems like a great, easy to understand grid system. But am I the only one concerned about the seeming disregard for HTML5 semantic standards?

    I’ve been working hard on maintaining semantic discipline, and could probably incorporate it into the foundation framework, but worry it would get lost in all the divs. Semantic.gs almost has me, but LESS is a bigger commitment than I want to make right now.

    Will need to experiment with Foundation a bit more before moving to real life clients.

    Great, thought-provoker. Thanks!

  9. I’m slacking with updating my skills to the latest web standards including mobile and retina image considerations etc. This is the first article I read on responsive web design & it was easy to follow along. Thanks.

    I have a newbie question: Do you recommend using this for production as well, or just for prototyping? From what I can tell the downside is the extra HTML markup right, but the upside it is more intuitive to use. Someone please advise.

  10. Yes, this framework looks cool. However, accessibility was not really considered. And by not really considered, I mean this framework is inaccessible. As a front-end developer, ALA reader, etc. I don’t find this acceptable and don’t think you should either if you care about the web, the web’s content, and the web’s audience. Yes, that audience includes everyone. Accessibility inclusion within this framework would’ve been simple (nothing too complicated), but now, one more accessible thing put onto the web. We’re better than this…

  11. I always try to find a great prototyping tools for my job. I tried some apps before, it works but not perfect. Hope Foundation will boost my productivity. thank you for sharing.

  12. Am I the first to notice that “Dive Into” is Mark Pilgrim’s domain, if not actual domain?
    Good article though.

  13. Good article, and nice to see a framework explored in greater depth rather than the usual, we have these features and off you go.

    Most clients, even though they use their mobiles extensively, still don’t really get the need to have there content available for the mobile platform, and it’s structures like this which will allow mobile friendly content to be introduced easily and effectively.

    Good article.

  14. It’s great to see people finally getting the idea of using a fluid grid. I have been using one for about 4 years and never looked back. I occasionally came across a peer developer that refused to use it because it was “bloat” in CSS, or “class-itis”, or “not semantic HTML”. Then I would show them how it worked and they would be hooked as well.

    I actually think that the original developer of the fluid grid needs some credit. The first decent fluid grid was gold leaf fluid grid. This has been copied by all the current frameworks out there. I’m not sure what happened to that recently as I notice their site seems to be down at the moment.


  15. You said it as it’s been said before, don’t abuse the hover. Too many sites still depend on user awareness based on hover. A bias towards builders working on desktops and the luxury of having a mouse/hover. Ought we all disable hover behavior in our browsers?

  16. couple of questions:

    – the tabs are a definition list with

    s, but no

    s – I haven’t seen that before, what’s the story?

    – similar question on the popup swap modal window:

    for the generic title, and

    for the more conversational explanation of what the user is seeing. what’s the semantic / seo implication of weighting the headers that way?

  17. Very nice and instructive article!!

    I’m brushing my HTML5/CSS3 skills to start with responsive design and wonder how would this article look today (one year later) when there is Foundation 4 advertised as:

    Mobile First – Now you can build for small devices first. Then, as devices get larger and larger, layer in more complexity.


    Semantic – Everything is now semantic. Now you can have the cleanest markup without sacrificing the utility and speed of Foundation.

    Any hint?

    Another point: considering that Foundation-4 is now Sass/Compass-ready, how it compares with e.g. Susy (http://susy.oddbird.net/) semantically-wise?

  18. It would be extremely useful to see an updated version of this article using Mobile First in Foundation 5.

    While useful in itself, I’ve not been able to find a walk-though of sketching and initial development thoughts for a Mobile First site.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA