Using Zurb Foundation’s grid for a responsive redesign, with three tweaks

This is the first in a series of articles about the Cook Smarts redesign.  Try their meal plan service to experience the redesign for yourself.

The key to responsive design is the grid. Arranging your content in a grid makes it easier to determine how it responds to various screen sizes.

The concept is pretty simple, but execution can get dicey.

It’s perfectly possible to roll your responsive grid, and everyone should learn how. However, developers have taken the time to create and share grid systems that work for most web sites.

Zurb Foundation is one of these pre-made grid systems that can save a lot of development time on responsive web projects. The Washington Post recently used it to revamp its online video site, Post TV.

We’ll step through Foundation’s grid, then apply it to the Cook Smarts responsive redesign.

Cook Smarts presents a week’s worth of meals on one page, with pictures and titles. Alongside the meals are notes for the week, such as what ingredients can be stretched across different recipes and what to sub for harder-to-find ingredients.

The previous, non-responsive site used a fixed grid.  It was great on desktop, but  not on a phone:

The Cook Smarts' web site on an iPhone, without responsive design

The text isn’t readable when it first comes up, so one has to scroll all around the page to get any use out of it. We’ll fix that using Zurb Foundation.

Meal plan on Cook Smarts, with responsive design

Above is the same page on a phone, once Foundation’s basic grid is applied. We had to do some legwork here to tell Foundation how our content should behave on small vs. large screens. For an overview of the basics, check out Foundation in 5 minutes.

In addition, we applied some tweaks that fall outside of Foundation’s default behavior.

Tweak 1: Distinguishable content boxes

The screenshot above has a single background color, making it difficult to distinguish different elements of the page. Google addresses this same issue by using white boxes with a gray background:

Google's mobile search screen, with a grey background and white boxes

Here’s how a similar effect looks on Cook Smarts:

Cook Smarts meal plan, with white content boxes added to the responsive design

The meals are easier to distinguish because they called out in white content boxes.

Here’s how the effect looks on desktop:

Cook Smarts meal plan on a desktop, with responsive design

We accomplished the gray/white effect by introducing our own class called cs-box.  It is simply a white box with a bit of shadow.  Because it is a block element (as div’s are by default), it stretches to the full width of its container. Its container is a Foundation column, so it behaves responsively without additional effort.

To recap, here’s how we coded the responsive grid above.

To contain the meals, we created a column that is 8/12th (2/3rd) the width of the page.

<div class="row">
<div class="large-8 columns">

Then we looped through each meal in Rails, outputting the following code for each. Notice that our class cs-box contains each meal, and each meal is presented in two columns of equal width – the picture and the meal description.

<div class="cs-box">
<div class=”large-6 columns meal-photo-wk”>
Image of meal
<div class=”large-6 columns day-info”>
Meal title and sub-title

Finally, we’ll put  some general information on the right side.  We’ll close out the 2/3rd-width column, and start a 1/3rd-width column.  Finally, we’ll close out the row altogether.

<div class=”large-4 columns>
<div class="cs-box">
<!-- Smarts from the team -->

<div class=”cs-box”>
<!-- Ideas for leftovers -->

Tweak 2: Take care of awkward screen sizes

We’re looking OK on a large desktop and a small phone, but the middle ground is looking a bit awkward. Maybe this is a smaller tablet or someone who prefers to keep a smaller browser window. In any case, we need to make sure Cook Smarts looks good on all screen sizes.

Here is a snapshot of a medium screen size:

Cook Smarts responsive meal plan looks a bit awkward on mid-size screens

Yikes! The image is huge! Foundation puts everything into one column for any screen width below 767px, but this just doesn’t look great with our content.

Ethan Marcotte said in a presentation that the trick to applying responsive design is deferring to your content. Well, our content is not loving our new grid at a middle screen size.

To fix this, we’ll put in some custom CSS to make the images look good on medium screen sizes.

@media only screen and (min-width: 30em) {
.meal-photo-wk, .day-info {
position: relative !important;
width: 50% !important;

This ensures that our image column remains at 50% width above 30em, a number we reached by experimentation (resizing the browser window to determine the range where things looked bad).

Now, our middle range looks much better:

A better mid-size view of a Cook Smarts meal plan

Tweak 3: Move stuff around on desktop vs. mobile

Back to working around our content.  We’ve used the Foundation grid on individual recipe pages, as well, and here’s how those are looking on desktop:

Cook Smarts responsive recipe

Here’s the problem.  The ingredients should appear before the Prep/Make/Review tabs when the screen is sized down. By default, Foundation will drop it below the tabs when the page becomes one column on a small screen.

Here’s where we can use Foundation’s source ordering, which can initially be confusing.

In the code, we will place ingredients first, which will make it appear on top of Prep/Make/Review on mobile. To make it appear after Prep/Make/Review on desktop, we will use push/pull as shown below.

<div class=”row”>
<div class=”large-4 columns push-8“>
<!– Ingredients –>
<div class=”large-8 columns pull-4“>
<!– Prep/Make/Review –>

The ingredients column is 4/12 columns wide, and appears first in the code. On a large screen, it should be pushed to the right side, instead of appearing on the left as it normally would.

The Prep/Make/Review column is 8/12 columns wide, appears second in the code. On a large screen, it should be pulled to the left, rather than appearing on the right as it normally would.

Responsive recipe on Cook Smarts, in mobile view

(Note: when source ordering doesn’t cut it, you can try AppendAround, by the web shop Filament Group. It can swap content pretty much anywhere when screen size changes.)

In closing

A common critique of frameworks like Foundation is that customization is hard. So far with the Cook Smarts redesign, we’ve found it easy, and the approaches above are complement the  solid base that the framework provides.

Next up, we’ll cover responsive images and video. Stay tuned! Subscribe by Twitter, RSS, or e-mail.

We’re making Cook Smarts responsive, and sharing the journey

Over the next month or so, I will be working to make the Cook Smarts meal planning service responsive. I’m going to share with you each phase of the project, challenges and all.

The Cook Smarts meal planning service has grown rapidly since its launch in May of this year. In a recent survey of its users, one of the most top-requested features was a mobile app.

Here’s a preview of what we’ll be addressing in this responsive redesign:

  1. Setting up the grid
  2. Exceptions to the grid, and how to handle them
  3. Responsive images (people love pictures of food, and they need to look good on every screen size)
  4. Responsive navigation
  5. Typography
  6. Integrating social
  7. Analytics

I have already begun the project, and am using the Zurb Foundation framework. There is a debate in the web community about when to use front-end frameworks. Many designers I greatly respect do not think they should be used at all.

There are a few reasons we’ll be trying Foundation on this project:

  • We want to deliver mobile-friendliness quickly, and reliably. Foundation allows for rapid development by handling boilerplate that applies to most use cases, and is tested across multiple browsers.
  • We will be rapidly adding new features as Cook Smarts’ user base grows. Foundation takes care of the basics and provides tools for implementing many of the features that are planned – for instance, responsive video.

There are other frameworks beside Foundation.  Here’s why I think Foundation is in the lead.

There are two important aspects of the tech community that also steer me toward a framework:

  • We share ideas, and use one another’s ideas in our projects. A framework that has been battle-tested on many sites, like Foundation, can also benefit Cook Smarts. We don’t need to reinvent the wheel.
  • Abstraction helps development move faster. On the back-end, Cook Smarts is built in Rails, which abstracts many common development tasks (database connectivity, basic security, etc.) so that we can focus on what’s unique about Cook Smarts. Front-end frameworks provide the same sort of abstraction for the user interface, allowing us to focus on value for users instead of reinventing a grid system that has been done thousands of times before.

Be back soon with an exploration of grids. We’ll talk about how Foundation’s grids work most of the time on their own, and how to customize them when they don’t quite fit.

Using Stripe for Gift Certificates and Gift Subscriptions

Stripe is a terrific platform for processing payments. However, it does not automatically handle some common e-commerce features like gift certificates and gift subscriptions.

So, when implementing gift subscriptions on Cook Smarts, a Rails app, I found myself doing a lot of research.

We tried to use Stripe coupons as makeshift gift certificates, but the logic quickly fell apart, particularly when thinking about how a gift customer would become a paid customer.

Instead, we track gift subscriptions in Cook Smarts’ database, and use Stripe’s trial period feature to redeem them.

The end results:

  • I buy my friend a gift subscription.

  • She redeems the gift subscription, with no credit card required, and has access to Cook Smarts for the length of the gift.

  • If she wants to continue using Cook Smarts past the gift period, she can provide billing information at any time during the gift period, and she will become a paying customer at the end of the gift period.

Here’s how we did it.

When I buy my friend a gift subscription, the app creates a record in a gift subscriptions table. It includes a randomly-generated gift code and the length of the gift subscription.

When my friend redeems the gift subscription, the app marks it redeemed in the gift subscriptions table. It activates her subscription in Stripe, and includes a trial_end date, which tells Stripe the length of the gift period. Stripe does not require billing information for a free trial (or what we call the gift period).

customer = Stripe::Customer.create(
:email =>,
:plan => 'monthly',
:trial_end => gift_subscription.end_date #end_date is a method in the GiftSubscription model that returns the end date of the gift period, based upon the length of the gift subscription and the date it was redeemed

If my friend loves Cook Smarts and wants to continue as a paid member, she can provide billing information at any time during her gift period.  The app will pass the credit card, and her subscription choice, to Stripe, along with the same trial_end date. This way, she will continue on a gift subscription, and become a paying member at the end of it.

customer.update_subscription(:plan=> params[:selected_plan], :trial_end=>gift_subscription.end_date, :card => params[:stripe_token])

Stripe’s support team offered the following caution, consistent with the process above:

When you’re updating the customer’s subscription, you’ll want to make sure you’re explicitly passing in the trial_end parameter:

This will ensure that the trial will end on the date you pass in, otherwise the API will shift the trial end date based on the new plan you’re moving them to.

Basically, when the customer provides billing information and chooses a plan, we need to pass the original trial_end date as we do above, so that the customer is not charged until the end of the gift period.

All in all, it was fairly straight-forward to implement gift subscriptions with Stripe. The biggest hurdle was allowing customers to provide billing information at any time, while holding any charges until the end of the gift period.

Testing Stripe

If your web app uses Stripe for online payments, you should test Stripe thoroughly. For growing apps, you need both manual and automated tests. I first learned about automated tests in an awesome EdX course about Ruby on Rails, and the concept was mind-blowing for me. Your app can tell you when the code you are adding to it is having unanticipated consequences, so you can feel secure that you are not breaking your app by adding new features.

Anyway, Stripe is a developer-focused payment processing service. It’s become a popular way to process online payments, particularly for subscription-based sites.

I’ve recently had the pleasure to work on Cook Smarts, a site that I originally featured in this blog and now have actually started helping with directly.

Cook Smarts uses Stripe to process payments. Cook Smarts’ meal plan service is subscription-based, and it is essential that Stripe function as expected, so we knew we’d have to test it well.

Here are some strategies that helped. This is written from a Ruby on Rails perspective, but the concepts would apply to any language.

Separate your API keys

Stripe provides two API keys for your site – a production key that can charge people real money, and a test key that cannot. When you are developing your app, you need to be careful not to accidentally use your production key, or you could do some real damage to your customers’ accounts.

In Rails, wherever an API key is used, I put in place logic to choose the production or test key based on the current environment, like so:

if Rails.env.production?
Stripe.api_key = "live_api_key_here"
Stripe.api_key = "test_api_key_here"

Update 2/17/2015: It’s advisable to keep API keys out of your code. Use environment variables instead. dotenv is a great way to specify environment variables on development.

Test manually

Once your API keys are separated, you can jump into your app on your development environment, and start playing with Stripe. Stripe offers test credit card numbers that you can plug into your dev environment to simulate successful transactions. You can play the role of a customer that is actually buying something, and then look at what happens on your Stripe test dashboard as a result.

Test operations and webhooks with RSpec

With RSpec, a popular testing tool that plays well with Rails, and another gem called stripe-ruby-mock, you can create a fake Stripe that your app interacts with in your tests. This way, your tests do not have to call out to Stripe at all, and run much faster.

Placing this in a test would create a fake customer in “Stripe”:

customer = Stripe::Customer.create(
:email => '[email protected]',
:card => 'valid_card_token'

You could then perform operations on the fake Stripe customer in your test, and it would never have to call out to the real Stripe site.

We handle various webhooks from Stripe, which is just a way for Stripe to tell Cook Smarts that something happened with a customer’s account. It is important to test these. One change I’ve made is placing more of the webhook response logic in the app’s models, where they are easier to test. I have not yet figured out how to simulate a webhook with RSpec in the development environment, but thoroughly testing the steps after the webhook is initiated gets us close to full coverage.  After that, keep an eye on your production Stripe event log (which shows which webhooks your app received and when), and confirm that your app is doing what it should in response to webhooks.

How to integrate RSS into a web site, nowadays

RSS isn’t going away, I hope. It places established and brand-new publishers on an equal playing field. If someone subscribes to me and Mashable, for instance, we both appear on their reading list. As bloggers, we should think about how to support RSS and gain more subscribers in the process.

It’s not easy. Current RSS clients – with one notable exception – are not giving publishers the tools they need.

For instance, I’d like you to subscribe to this blog’s RSS feed. How can I help you do that?

If I link to this RSS file, here’s what you see:

This site's RSS feed viewed in Google Chrome
This site’s RSS feed viewed in Google Chrome

If I send you to Feedburner, you can choose to subscribe via Google Reader (a sign that Feedburner is not being updated), some broken image, or My Yahoo. The Feedburner subscription landing page, in most cases, adds no value for the user.

FeedBurner's subscription landing page
FeedBurner’s subscription landing page

(Hang in there – there’s an answer at the end of this post, promise.)

Three of the top web-based readers are Feedly, Digg Reader, and AOL Reader. (Feedly is likely the top.)

From what I can see, there is no way to provide you with a Subscribe via Digg Reader or Subscribe via AOL Reader link. How is either reader supposed to create an ecosystem without providing tools for publishers? 

Alas, Feedly saves the day! I can give you this link:

Subscribe via Feedly

Whether or not you have a Feedly account, the link provides you with a description of the feed and the latest articles. If you click Add to My Feedly, Feedly asks you to login or register, and then helps you subscribe to this blog. This integrated experience serves publishers and consumers alike.

Feedly's subscription landing page
Feedly’s subscription landing page

Why don’t Feedly’s competitors provide such a smooth subscription experience?

I’m creating a new WordPress theme for this site that will include a Subscribe via RSS button. It will feature two options – Subscribe via Feedly or Other.  I hope to add Feedly’s competitors, once they provide the most basic of features for web publishers, a Subscribe button.

End Note:

Feedly’s integrated experience reminds me of It’s the Little Things from 52 Weeks of UX. Feedly seems to recognize that every interaction matters. You see it in other areas, too. Feedly is the only service of the three to show the number of readers for a feed, a helpful stat for publishers.

In fairness, I should note that AOL Reader has an API, but it is geared toward third-party app developers.

Oh, hey, subscribe to this site via Feedly or follow me on Twitter!

Update: Feedly even offers a tool that helps you make the subscription link pretty.

Can design be taught?

I was never the kid who could draw. My few attempts at arts and crafts were unmitigated disasters.

Throughout my career, I have had the privilege to work with designers. They can make a functional interface a joy to use by adding personality and meaning. I would bet that they could draw when they were kids.

When I worked on user interfaces for projects, I focused on usability, validating assumptions through user research. Even with a perfectly functional interface, I reached a point where only a designer’s touch could make the user experience extraordinary. “What is this designer juju,” I asked myself, “and how can I get it?”

I recently took Code School’s Fundamentals of Design, which emphasizes that design is “intentional.” A good designer can state the reasons for his or her choice of typography, layout, and color. In this way, design is both creative and logical. The logic can be taught, and Code School aims to impart creative intuition as well.


The course started with some basic theories of design. Here are some examples:

  • Color systems – Red/Green/Blue (used for web), CMYK (used for print), Hue/Light/Saturation (how the brain perceives colors)
  • Color and emotion – red means passion, yellow means optimism and creativity, green means serenity and health*

* Colors have different meanings in different cultures, the course notes.

Rules of thumb

Also covered are ground rules that designers know after spending some time in the field.

  • Try not to have orphan words hanging at the end of a line.
  • Use cool colors in the background and warm colors in the foreground, because warm colors appear closer to the human eye.
  • When putting type on top of an image, adjust the image (using an overlay pattern or transparency) to make the text stand out. Do not adjust the text with tacky effects such as drop shadows.


Here’s where it got interesting. The course taught creative intuition through exercises.

The course presents an actual web site and has you:

  1. Drag elements around into layout
  2. Apply a color scheme
  3. Choose fonts and font sizes

All the while, it validates that your selections match design principles such as symmetry (… or properly applied asymmetry) and contrast.

The fact that a computer can detect poor design choices hints that to some extent designer’s intuition can be learned.

How to learn basic design

Whether you have designed in mediums other than web or never designed at all, it is worth exploring these introductory resources.

Read a classic

Check out The Non-Designer’s Design Book for an introduction to the basics of design overall, not just the web.  These foundational principles carry through to all mediums.

Stay up to date

Sign up for, and go through its lessons.  You will learn from the top minds in the field.

Take an interactive course

I would recommend Code School’s Fundamentals of Design, particularly as a compliment to the two suggestions above.

Responsive navigation with Zurb Foundation, in 5 minutes

Correction: rather than interchange, I used Foundation’s visibility classes to show a different logo on smaller screens.  Interchange is a superior method for responsive images because it saves load time on mobile devices.

Zurb Foundation makes it easier to implement responsive, mobile-friendly navigation.  We’ll apply responsive navigation to an existing web site in just 5 minutes.

Many thanks to, the web site that taught me how to cook, for allowing me to feature it in these videos.

This is the final screencast in our Foundation series.

  1. Making a page responsive
  2. Responsive sections/tabs
  3. Responsive navigation

Follow me on Twitter @coreyITguy for more on modern web design.

Making tabs responsive in 5 minutes, with Zurb Foundation

To view in HD, click the gears icon at the bottom of the video.

In our last Zurb Foundation screencast, we made an existing page on responsive, in just 5 minutes.

But we’re not done!

Now, we’ll tackle tabs. Even with our new responsive layout, tabs on the page do not respond well to small screens. We’ll replace them Foundation‘s sections, which can auto-magically appear as tabs on a large screen and an accordion on a small screen.

Many thanks to, the web site that taught me how to cook, for allowing me to feature it in these videos.

This is the second of three screencasts in our Foundation series.

  1. Making a page responsive
  2. Responsive sections/tabs
  3. Responsive navigation

Making a page responsive in 5 minutes, with Zurb Foundation

To illustrate how much time is saved by a front-end framework like Zurb Foundation, I’d like to share a 5 minute screencast where I apply it to one of my favorite web sites.

Cooksmarts is a fantastic web site that has taught me how to cook. Its recipes are presented very well, but are not optimized for phone-size screens.

Many thanks to Jess Dang from Cooksmarts for allowing me to use the site in this demonstration. If you’re looking to cook at home more, their meal plans are fantastic.

This is the first of three screencasts in our Foundation series.

  1. Making a page responsive
  2. Responsive sections/tabs
  3. Responsive navigation

I recently wrote about the decision to use a front-end framework vs. writing CSS from scratch, then compared a couple of frameworks.