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.

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.

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.

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.

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.

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>
  </div>
</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>
    </div>
      <div class="four columns">Sidebar</div>
  </div>
</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:

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?

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>
  <dd>Popular</dd>
  <dd>Trending</dd>
</dl><ul class="nice tabs-content contained">
  <li class="active" id="topTab">
    Books go here…
  </li>
  <li class="active" id="popularTab">*changed indent here*
    Books go here…
  </li>
  <li class="active" id="trendingTab">*and here*
    Books go here…
  </li>
</ul>

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>
  </ul>
  <a href="book.html">Never Mind</a>
  <a class="close-reveal-modal">×</a>
</div>

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>
  </div>
</div>

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.

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.

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…
    </div>
  <!-- pulls this nine columns to the left -->
    <div class="three columns pull-nine"> 
      Sidebar…
    </div>
</div>

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:

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>
    </div>
  <!-- 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>
    </div>
</div>

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.