Menu Search
Jump to the content X X
Smashing Conf San Francisco

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Rapid Prototyping For Any Device With Foundation

This article is the second piece in our new series introducing new, useful and freely available tools and techniques presented and released by active members of the Web design community (the first article covered PrefixFree1, a new tool be Lea Verou). ZURB are well-known for their wireframing and prototyping tools and in this post they present their recent tool, Foundation, a framework to help you build prototypes and production code that’s truly responsive.

You’ve probably already heard about responsive design, which is website design that responds to the device constraints of the person viewing it. It’s a hot topic right now, and with good reason: alternative devices outsell desktop PCs 4 to 1 already, and within three years more Internet traffic in the US will go through mobile devices2 than through laptops or desktops.

All of this is forcing a convergence on what Jeremy Keith calls the “one Web3”: a single Web that doesn’t care what device you’re on, how you’re viewing content or how you’re interacting with it.

What we found at ZURB was that while the concept of one Web is strong and the need for responsive websites great, the tools to help us quickly build that way just didn’t exist. That’s why we built Foundation4, a framework to help you build prototypes and production code that’s truly responsive.

The Problem with Global CSS Link

For years at ZURB, we used and refined a global CSS file that included a nice 960 grid, typography styles, buttons and other common elements. The trouble with our global CSS was that none of these pieces were written to be used by others, so they required a good deal of ramping up and training, with no great documentation.


Our CSS style guide had a lot of good global elements, but it wasn’t well documented, and it certainly wasn’t ready for other devices.

The bigger problem was that it wasn’t designed to be responsive or mobile-friendly in any way. We were stuck in the same rut that a lot of designers are in: creating a 1000-pixel-wide canvas, putting a 960 grid on it, and calling it a day. Our tools were built to support that workflow. So, we rewrote it into Foundation, a framework for everyone to be able to rapidly prototype in a responsive way.


Foundation is an MIT-licensed framework that includes a nestable arbitrary-width responsive grid; mobile styles, buttons and typography; layout affordances such as tabs and pagination; forms; and useful JavaScript plugins. We wrote or packaged all of these pieces to achieve a few goals:

  1. Quickly train new designers, inside and outside ZURB, to use a common framework;
  2. Rapidly prototype websites for desktops and any mobile device;
  3. Easily customize and complete the prototype to turn it into production code for particular projects or clients.

The first goal can’t be overstated; the value of having a single set of styles and best practices that the team can iterate on as a whole and communicate to our clients is tremendous. We can ramp up new designers much more quickly, build things faster and work together more easily. On one recent project, we even got a volunteer sufficiently up to speed on Foundation that we could collaborate on code — and it took only about 15 minutes.

So, How Does Foundation Work? Link

The core of Foundation can be summed up in a few points:

  • A 12-column, percentage-based grid with an arbitrary maximum width.
    The grid can be nested and used for quite complex layouts, and it works all the way back to IE 7. The grid reshuffles itself for smaller devices.
  • Image styles that disregard pixels.
    Images in Foundation are scaled by the grid to different widths.
  • UI and layout elements.
    Foundation includes common pieces such as typography and forms, as well as tabs, pagination, N-up grids and more.
  • Mobile visibility classes.
    Rapidly prototyping is partly about having built-in functionality to tailor the experience. Foundation lets you very quickly hide and show elements on desktops, tablets and phones.

We deliberately built Foundation as a starting point, not as a style guide. We’ve included some styles to help you rapidly build something clickable and usable, but not something stylistically complete. Everything in Foundation is meant to be customized, including button styles, form styles (even custom radio, checkbox and select elements), typography, and layout elements such as tabs.

The Grid Link

A lot of grids are floating around, including some very good ones right here on Smashing Coding6. Grid systems have a few issues, though, and we built Foundation to tackle them… well, some of them.

Fluidity Link

One of the critical pieces of device-agnostic design is having a fluid layout that conforms to the size (and orientation) of the device. Foundation’s grid is completely fluid, with percentage-based widths and margins, and it works all the way back to IE 7 (but not IE 6 — philosophically speaking, acting like IE 6 doesn’t exist makes sense at this point). The HTML markup is pretty simple. Here’s an example of the grid in use, where we nest it for a more complex layout:

<div class="row">
  <div class="eight columns">
	<div class="row">
	  <div class="six columns">
	    <h5>Another Section (.six.columns)</h5>
	  <div class="six columns">
	    <h5>Another Section (.six.columns)</h5>
    <p>Now the nested row has been closed, and we're back to the original eight-column section.</p>

You can check out the above code on this example page7.


Here are some of the built-in grid constructs, all of which scale with the browser window.

Responsiveness Link

The second critical piece is for the grid to be able to easily adapt to small devices and their unique constraints. We tackled this in three ways:

  • On small devices (such as phones), the grid simply stacks vertically, with every column running the full width.
  • We’ve also included block-grid classes, which are definitions for ULs that can be two-up through five-up and that remain a grid even on very small devices.
  • And we have mobile visibility classes. These are a group of styles that enable you to quickly try things out by hiding and showing elements on different kinds of devices. You can attach classes like so:
<div class="hide-on-phones">
	<p>This is a paragraph that we don't want to see on small devices.</p>
<div class="show-on-phones">
	<p>This paragraph will be shown only on phones, not on tablets or desktops.</p>

Another interesting use for the classes is to prototype a common mobile consideration: placing mobile navigation at the bottom, as opposed to its more common placement at the top. You could do this:

<nav class="hide-on-phones">
    <li><a href=#>…<a></li>
    <li><a href=#>…<a></li>
    <li><a href=#>…<a></li>
<nav class="show-on-phones">
  <dl class="mobile tabs">
    <dd><a href="#">…</a></dd>
    <dd><a href="#">…</a></dd>
    <dd><a href="#">…</a></dd>


Foundation lets you write code once and show it on different devices easily.

Semantics Link

This one is tricky. A very compelling case is to be made that grid systems are by nature not semantic. This is partly true; they’re still descriptive of their function, but they do break the separation of data and display.

We didn’t want to base the Foundation framework on another extension, such as LESS9. LESS is a great tool enabling you to use variables, shortcuts and more in your CSS, but we didn’t want to have to rely on it and add another barrier to using Foundation. The recent article we mentioned above actually fixed the data and display issue of grids by using LESS, which is awesome, but Foundation doesn’t fix that. Here’s why…

All of these methods are a stopgap. The replacement technique might come out next month or next year, but really all of these tools will change drastically in the very near future. Tools like LESS help us get a little closer to a very clean solution, but at a higher technology and learning cost. We wanted Foundation to be the fastest way to prototype for all kinds of devices, so we paid a small price for truly separated markup.

Rapid Prototyping Examples Link

Let’s look at a recent example for which Foundation was used. Every year, we do a 24-hour design marathon for a local non-profit, usually producing new marketing collateral and a new website. This year, we chose Rebekah Children’s Services, a great organization that helps with adoptions and takes care of disadvantaged kids.

This year, we wanted to build a website that was really responsive, and we had very little time to do it. Using just Foundation, we started prototyping the website based on some sketches we had done. In two hours, we managed to build this prototype10.


Using Foundation, we built the prototype on the left in two hours (including every screen), and then started modifying it until it became the final website on the right.

It’s not terribly pretty, but it did give us something we could click around in, add copy to and iterate on. In the prototype, we used only a bare minimum of custom styles to more accurately represent the intended visuals.

Once we completed the prototype, we were able to complete the visual design and apply it to the existing Foundation code base to produce the final website12. The final website retains all of Foundation’s framework, with the new styles applied on top of it.

How to Further Tailor the Experience Link

We recently launched an app through which to give traditional design feedback on mockups and websites. It’s called Spur13, and it has been great fun for us; not only is it in our wheelhouse (for design feedback), but building a responsive Web app was an awesome opportunity.

Spur has a number of tools and actions, as well as some simple forms and a fairly complex JavaScript- and HTML-loading animation. Adapting all of this to mobile devices could have been really painful, but by starting with Foundation, we cut down on that considerably and prototyped the app quickly.


Spur on a desktop is different than Spur on a mobile device such as an iPhone.

Spur helped us get more comfortable with the constraints of a given device, including screen size, orientation, tap target size and copy. Spur is simpler on smaller devices, but it’s not stripped down. You can still capture a page, view it through the various filters, and share it with someone else.

Rapid Prototyping Is Required Now Link

The days of creating a blank Photoshop canvas and laying down a 960 grid are over, even if some of us are still working in that shared fantasy world. Mobile devices — or, let’s just say, devices beyond just laptops and desktops — are already prevalent and will only become more ubiquitous.

Don’t build a desktop website that’s pixel-perfect before thinking about other devices; get used to designing for several different sizes, and then quickly prototype your design to get a feel for the flow, function and interaction.

We built Foundation to help us do this faster and to develop better websites and apps for us and our clients. We feel so strongly about the need for this that Foundation is MIT-licensed and completely free to use, forever. If you try it out and have success with it, let us know15. We’d love to hear about it, just as we’d love to hear about bugs or issues that you’ve run into.

We’re excited about this watershed moment in Web design (and in connectivity and data availability), and you should be, too: our industry will change more in the next three years than it has in its entire history. We hope this helps.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15

↑ Back to top Tweet itShare on Facebook


ZURB is a close-knit team of interaction designers and strategists that help companies design better products & services through consulting, products, education, books, training and events. Since 1998 ZURB has helped over 75+ clients including: Facebook, eBay, NYSE, Yahoo, Zazzle, Playlist, Britney Spears, among others.

  1. 1

    Great post and great framework but I don’t think it’s a great approach to hide elements via css, viewing it from a performance perspective.

    Responsive is great but still limited. Mobile must be faster and faster and hiding is not the solution.

    • 2

      Jonathan Smiley

      October 25, 2011 7:41 am

      Andrea, you’re correct that hiding elements via CSS isn’t ideal – however if you’re trying to build quickly the tradeoff is fairly minimal, the hit for pure text is pretty low (and you can avoid creating separate desktop and mobile sites).

      There’s a lot that can be done to make responsive design even faster, much of it back-end, server-side stuff that Foundation doesn’t touch on. Good point though and something everyone should be aware of – there’s no silver bullet :)

    • 3

      Also, images are just being scaled down, so on the mobile device you are still downloading the full size image which is a bit of a waste. You would definitely need to have a mobile version server side.

      • 4

        What you should try to do is deliver low quality images and a cut down version of the page by default. Use Javascript/CSS to then load in high quality images for large screen devices, and call in features of the page for larger screens.

        Progressive enhancement?

        • 5

          Delivering different quality images to match the screen size is totally the right way to do it, and Scott Jehl has a great backend solution for that here:

          Foundation just uses the provided image so that you can quickly create a responsive prototype without having to create different images sizes. When you are ready to go to production, you should absolutely be using something like Response Images to minimize image load time on mobile devices.

      • 6

        This may be an issue of prioritizing design and development. When prototyping, worrying about different size images will have a major effect on iteration timelines. Once actual development begins, this functionality can be baked into the site’s back-end. Most of my development is in Drupal, where it’s easy to set up processes for serving different images to the appropriate user type. It can be done for other major CMS, as well as custom solutions.

    • 7

      Nene Odonkor

      April 28, 2012 2:00 pm

      This is one issue I have with Responsive design. Downloading stuff onto your mobile phone only for it to be hidden from the user. So it means I wasted download time which will cost me. Why don’t you guys create a script that will determine what device is trying to access your website. Then if the script detects it is a mobile device then all the divs with the class ‘hide-on-phones’ will not load the associated content. Another way is to create two separate CSS sheets for the same content and have the script determine which one to load depending on the device requesting for the webpage.

      RESPONSIVE DESIGN SHOULD NOT ONLY TAKE INTO CONSIDERATION THE SCREEN SIZE BUT ALSO DOWNLOAD SPEED. Therefore, designs should know what to load and what not to load to fit into the device.

  2. 8

    Wow! I’ll soon start coding my revised portfolio, perfect timing team ZURB!!

  3. 9

    Really nice work. But now I’m in a big dilemma whether to go for bootstrap by twitter or foundation. Both are equally promising. Will try out foundation in my next project.

    Keep up the good work @zurb!

    • 10

      i left Twitter bootstrap and now I’m using Foundation in my new project, its awesome.

      • 11

        Bootstrap is still unbeatable for backend applications where you deal with a lot of forms and responsiveness is not so important.
        For the frontend I think that there is a lot of better frameworks than Bootstrap and Foundation seems to be one of them.

    • 12

      If you want something easier and simpler, use Foundation. You will get started in a small amount of time. IMO, Foundation is good for websites. I switched from Bootstrap to Foundation mainly for its flexibility and ease of use.

      If you think you need more functionality and your project has ‘app’ nature, go for Bootstrap. Bootstrap is more popular and you will find more resources online. Google ’20 resources bootstrap’. I wish Foundation had such articles, too. :D

  4. 13

    Nice to see. Not so nice after a weekend where I built responsiveness and nested responsive grid in Twitter Bootstrap (along with some other funky bits).. :(

    well, more inspiration on methodology I guess.. ;)

  5. 14

    A few questions, is the orbit plugin responsive? Also, am I going to be able to implement ajax content loading without any problems? Absolutely love this framework.

    • 15

      The version of Orbit in Foundation is responsive yes. We are currently working on porting those changes back into the stand alone Orbit plugin.

      Ajax content loading will work fine so long as you avoid using the new HTML5 tags (nav, section, etc.). We include the HTML5shiv in foundation to ensure that the new HTML5 tags work in older browsers, but that script does not work for content that is loaded dynamically. Nothing in Foundation requires using HTML5 tags, so just avoid them if you are loading dynamic content.

  6. 16

    I am learning about responsive design and think that this is pretty darn cool. Are there any tutorials to show me how to use this? This is new to me.

  7. 17

    “our industry will change more in the next three years than it has in its entire history”

    That, my friends, is a profound statement. Wow.

  8. 18

    taper roller bearings

    October 25, 2011 7:09 pm

    I going to be able to implement ajax content loading without any problems?

  9. 20

    Is it only me that is just not feeling the whole responsive thing that everyone is talking about? It’s always about easy and quick quick.

    It’s like buying a ferrari, but also want to go off-road with it. Sure you can put soms dirt-tyres on it, but it will still not perform as well as a car created for off-road.

    If a company or a person wants a good mobile version, then create a seperate, designed for mobile website.

    • 21

      @alex: a ‘good mobile version’ for what device? A Smartphone? Yeah, thats cool. What happens when someone with an iPad or a larger device views the website? Viewing the same ‘good mobile version’? Probably looks crap an a larger device then. Fluid designs are best because there are tons of devices out there, all with different screen sizes. Coding a page for every single device? Thats no fun!

      ok, maybe we could do this with a 4-paged-website. For desktop 4 pages, smartphone 4 pages, pad 4 pages (at least). So that’s 16 pages to code for now.
      If there’s a 20-pages-website, you would have to code 80 pages. Thats really no fun.

      With a fluid website you only have 1 html page – css and js do the rest for you. I rather prefer this way… ;)

      I’m currently working on a very complex website with 4 navigation levels etc. I’m so happy to see a nice boilerplate merged with a fluid grid system, well done ZURB, what a nice morning :)

      And yes, my question too dear ZURB-Team: what about ajax content loading?

      • 22

        @mono, i’m guessing you did not understand what i meant. But ofcourse: Ipad is a totaly different thing, but let’s put them into the tablet category.
        Yes different that a smartphone you’re correct! And exactly that my friend, is just my point.

        And yes! different things should be designed for tablets than for smarthphones!

        And coding is the least of the worries, just thinking about a good functional layout is the most work.

        But hey, if everyone wants to have all kinds of semi-semi-semi websites so they have to pay less and lazy coders have to work less just go ahead!

        Maybe i’m the only one, and the only one with clients that understand one should always have the best possible experience, so that if you have to go that extra mile: we GO that extra mile.

        Too expensive? Well OK you got me there! Go responsive, there you have it!

        • 23

          euhm.. responsive design is exactly that.. bringing the best experience to the device..

          and it’s certainly *not* for lazy coders.. au contraire..

          • 24

            Yes it is in a certain way, but definitely not the best, better.. but not the best. No mather how you bring it: NEVER the BEST possible experience.

      • 25

        @mono, I completely agree with you, coding close to a hundred pages when all you really need is one html page that handles all devices and screen sizes is definitely the way to go.

  10. 27

    Well, nobody forces us to optimize our work. Going that extra mile is fine, but why walk an extra mile when there’s only 200m on a different way?

    I think that has nothing to do with laziness. Coders who use LESS (yeah, even less!) or other tools that have been developed for our needs, as now this neat fluid grid, use it because they want to optimize their workflow. And of course, save some time. Good for the coder, good for the client. If you got more time, you can work at more projects. …or go out with the dog :)

  11. 29

    The same mold = the same design = poor and sad web.

  12. 30

    It was of common practice for me to write multiple css files for different devices (or in-file hide and show classes) but I just learned two or three new tricks that might solve some problems I encountered before in an easier way.

    Thanks for the post!!

  13. 31

    Matthew Votsikas

    October 26, 2011 3:04 am

    I like the idea, but have concerns about accessibility. A screen reader’s gonna have a nightmare deducing whether to read hide-on-phones or show-on-phones

    • 32

      Jonathan Smiley

      October 26, 2011 9:31 am

      Excellent point. I’ve created an issue on Github for us to investigate this and see if there’s a way we can resolve this. Thanks for mentioning this!

    • 33

      That’s a good point, we trade off accessibility and page size for rapid prototyping.

      The idea being you need to get to a solution quickly and see that solution on multiple devices. After some iteration when you have a mature solution you can replace hide-on-phones with server-side code that does not render these elements at all.

      • 34

        Jonathan Smiley

        October 26, 2011 9:55 pm

        One of our buddies on Github actually answered this for us: elements hidden either through display:none (like Foundation uses) or visibility:hidden are ignored by screen readers.

  14. 35

    I will give it a try. Also, it would be amazing to be able to see that “Zurb Style Guide” online as study materials.

  15. 36

    Have studied it some more last night.. and I wonder if there might be a followup article on this, explaining why they did what they did.

    Some things make sense, some I find odd.. e.g. the font-resize to 62.5%. Seeing a lot of good practices along with some that ‘I think’ are not, is a bit confusing..

    • 37

      Google “font 62.5” for an explanation of why that font resize is chosen; it has to do with making sure of a default font size where 1em is a known number of pixels.

      Here is a snippet from an A List Apart comment, “I’ve always followed the 62.5% method – setting your body to have a font size of 62.5% means that any browser where the user hasn’t deliberately* changed their default font settings will set 1em equal to 10px.”

      • 38

        Yeah, I know why and how it’s done, believe me, read my fair share articles.

        But I see a lot of people move away from that technique, leaving body at 100%, so wondering why Zurb still does it.. ? Cause, on the other hand, they use rem, a relatively new technique… It’s that kind of stuff that confuses me, and just want to know what reasoning was behind those choices..

  16. 39

    Mike Malphurs

    October 26, 2011 5:10 am

    Great post… This helps answer the biggest issue a business owner faces with responsive design: The time it takes to build a responsive site.

    In a perfect world, yes… We could build a site to scale to any and every device. But, as a business owner it is nearly impossible to do this when you have ten websites that clients are screaming to get out the door.

    From my perspective, the answer is either:
    1) Build a mobile version and a desktop version
    2) Charge more and do a responsive design
    3) Not worry about mobile users at all

    Again, #2 is best practice, but also a best-case scenario. Unfortunately, #1 or #3 is “the norm” for most clients who simply won’t be educated or don’t care to be.

  17. 40

    Why did you decide using pixels instead of em units? You aren’t responsive just because you are using a fluid grid.

    • 41

      Jonathan Smiley

      October 26, 2011 9:57 pm

      Are you referring to the typography? We’re actually using a combinations of pixel sizes for backwards-compatibility as well as rems, or root ems, which carry the benefit of ems without the cascading size issues they have.

  18. 42

    I’ve been looking for simple, straightforward frameworks (mainly ‘cos I hate styling forms) for a few days now, and I’m glad I found this one. Definitely using it in my next project.

  19. 43

    Is it me or the code in the first example (“Fluidity”) is not properly indented?

  20. 44

    Really cool, just downloaded it. I am impressed by this take on going back to fluid layout that can be used for all platforms and I saw the little note about IE on one of the CSS files lol.

    But it is not working properly on IE7,8. Now I am sure I can probably go in there and fix those layout issues when developing the site and of course I believe this is still a early version but let me say this. Zurb TYSFM! I am glad someone is making time out of their busy schedule to help standardize a universal workflow and this is one step closer.

    • 45

      Jonathan Smiley

      October 26, 2011 9:58 pm

      If you could, can you let us know what you’re seeing broken in IE7/8 on our Github issues page? Or just contact us through the contact address on the Foundation site. We’ve tested on those browsers (despite our distaste, which you noticed) and we’d like to get that fixed up. Thanks!

      • 46

        I have several issues with IE8 too, trying to figure out what’s the point there…


↑ Back to top