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.