Targeting Mobile Users Through Google AdWords

“Know your audience” has stood as a fundamental marketing principle since long before the web. When advertising online, you need to take into account one of the most basic factors of the audience you are reaching: what devices they are using.
The most popular online advertising platform, in use by marketers of all sizes, is Google AdWords. Up until early 2013, AdWords allowed advertisers to set up separate campaigns to target mobile devices. Best practice generally entailed targeting mobile, desktop and sometimes tablet users in unique campaigns.
Then, in a bold move to push the importance of mobile usability (some would say to drive up its own revenue), Google announced it would no longer allow campaigns to target by device, as part of what it called “enhanced” campaigns. Pay-per-click (PPC) managers made outcries about Google’s forced decision to remove control from advertisers, even cautioning people against upgrading immediately as the option became available to do so.
A year later, the dust has settled somewhat as advertisers have adapted to the new campaign format. With the ability create device-specific campaigns gone, they’ve modified tactics with their campaign structure and bidding strategy to best reach people across multiple devices.
Why should you care about who’s using a mobile device and who’s not? First of all, people often behave differently when browsing on a phone versus a desktop. In reviewing data from a site that received just over three million sessions over the past year, users spent an average of 2:42 when coming from desktop and 1:16 from mobile. That shows mobile sessions dropping off after about half as long as desktop sessions. A smartphone user might not care to spend time sifting through an extensive product inventory, instead just wanting a number to call or immediate directions to a location.
Secondly, costs can vary widely by device. A study by Marin Software shows that the average cost per click on mobile was 26% lower than the desktop average in 2013. Also, the average cost per lead or sale might be more or less on mobile. Advertisers who take this information into account will see the need to control bids by device in order to maintain their target costs for leads.
Thirdly, visits from mobile might provide more or less value to a particular advertiser. For example, the owner of an e-commerce website might find that desktop users put more items in their carts and spend more on average.
Fourthly, you might want to drive mobile users to different pages than desktop users. Especially if your website is not responsive, you might have separate URLs for mobile. While a responsive website is ideal, your agency might be forced to work with a client’s existing website when running an ad campaign.
So, how do you build a campaign that targets only mobile devices via AdWords? The short answer is you can’t. However, a number of workarounds are available.
First, let’s look at a couple of AdWords features that focus spending on mobile: bid modifiers and mobile-preferred ads.

AdWords Features To Target Mobile

Use Bid Modifiers

Enhanced campaigns introduced a feature called bid modifiers, which allow you to increase or decrease bids by a percentage for ads appearing on mobile devices. A number of PPC professionals have suggested using bid modifiers to focus a campaign’s spend on mobile placement. You could set a low general bid and increase the mobile bid modifier to 300%, the maximum percentage allowed.
To set a bid modifier, go to the “Settings” tab in your desired campaign and select “Devices.” You’ll then see statistics broken down by device and the option to change the percentage for mobile.
However, this technique will not completely exclude desktop searches. In a test across multiple accounts, Brad Geddes found that about 19% of searches still end up occurring on desktop.

Create Mobile-Preferred Ads

Another option is to create mobile-preferred ads. When you build an ad in AdWords’ interface, selecting a check box enables you to mark the ad as mobile-preferred. Such ads are an opportunity to customize messaging specifically to people on mobile devices. We’ve improved both clickthrough rates and conversion rates by using phrases like “Call now” in mobile-specific ads, because searchers can click-to-call from a phone.
To create a mobile-preferred ad, just click the check box for “Mobile” under “Device preference” when making an ad via the web interface.
However, even these ads are not guaranteed to appear only on mobile or to prevent standard ads in the same ad groups from showing up on mobile. PPC Hero put this to the test and found that a number of desktop impressions still occurred with mobile-preferred ads.

Use Smartphone-Specific Ad Sizes

When running display campaigns, the 320 × 50-pixel mobile leaderboard ad size will appear specifically in a smartphone browser or app. You can even create animated ads in this format to get more attention. If you want to run them on mobile devices that don’t support Flash, AdWords offers an option to convert the Flash files to HTML5 when uploading them.
This ad size is great for driving branding, because it takes up an extremely visible portion of a mobile screen, often on top. Clickthrough rate tends to be high. In one campaign, I saw an average of a 0.5% higher clickthrough rate on these mobile ads than the standard desktop sizes (a pretty significant difference for display ads). Be aware, however, that people often unintentionally tap these ads on a touch device, especially while playing games. If you are encountering a high bounce rate from these ads, then consider excluding mobile apps. Bryant Garvin has written about a quick and easy way to do this.
We’ve looked at some options available in AdWords to focus on mobile. Next, let’s consider another platform that allows for more granular targeting at the device level than AdWords.

Direct People To Proper Pages

While a responsive website is the ideal option, if you do have a separate mobile website, make sure that users who are coming from mobile devices will see the proper page. One of the worst mistakes you could make is to forward all mobile visitors to a generic home page. I’ve audited campaigns whose ads were set up to very carefully link to very specific inventory items, only to completely lose all of that value because no equivalent pages existed on mobile. Make sure that individual product and service pages forward to their respective mobile versions.
AdWords also lets you use ValueTrack parameters in ad-destination URLs to specify mobile and desktop versions. People who click on ads will be directed to the proper page based on the device being used.

Try Bing Ads

While Google might have removed the capability to target separate campaigns at mobile devices or tablets, Bing still allows you to segment by device; you can still create a mobile-only campaign to reach searchers on Bing and Yahoo. While Bing-powered search accounts for a much smaller volume than Google, I’ve found that allotting a portion of spend to Bing Ads to be valuable for many clients, with less competition, as well as a generally lower cost for leads. For one particular client with a limited budget, we found that the cost per lead averaged about $20 less in Bing Ads than AdWords; so, we shifted money over, resulting in a stronger return on investment from their ad spend.
To set a Bing Ads campaign to serve only on mobile, go to the “Campaign Settings” tab. Under “Advanced Targeting Options,” select “Device” to choose the devices on which to run your campaign. You can also set bid modifiers here, as in AdWords.

Don’t Forget The Experience After The Ad!

Getting the right people to click on your ad is only the first step. Their experience on your website after the click is crucial to whether they actually contact you or make a purchase. Also, realize that landing-page quality contributes to AdWords’ quality score, a factor that affects how high you have to bid for clicks and where your ads show up in search results.
A responsive design will adapt your website’s size to mobile devices and is, in fact, Google’s stated preference. Make sure that your website’s design takes into account which devices users are on, how they arrived on a particular page and what paths they need to take to convert.

Start Reaching Your Audience On Mobile

By using the techniques mentioned, I’ve succeeded in keeping costs per lead down, as well as focusing spend on areas where a campaign is seeing the best results. While we do live in a cross-device world, paying attention to the results from different devices leads to smarter PPC campaign management. For example, in the same AdWords account, I’ve seen campaigns in which mobile costs per lead average higher than on desktop, along with other campaigns in which mobile costs per lead average lower. Taking this information into account, we can customize the bid modifiers for mobile by campaign, instead of keeping them at a generic number across the board, to help control spend.
Working with businesses that provide local services, I’ve also seen immense success both in including a click-to-call extension as well as using mobile-preferred ads to focus messaging on calls. Some clients I’ve worked with see just as many leads come from phone calls directly from ads as through website form submissions. Again, the fact that a user on a phone is likely to take advantage of a simple click-to-call option gives us the option to customize an ad campaign targeted at mobile searchers.
Ultimately, there is no one-size-fits-all solution to targeting your audience by device. But whether you’re just starting to advertise online or are a veteran AdWords user, you can likely do more to reach the ever-growing pool of mobile users. Take the time to segment messaging, and target with the knowledge that people behave differently on different devices. Keep track of the value of leads received based on device to determine how much spend to allot to mobile and how much to desktop. Of course, test these tactics to see what works best for you and your brand, and tailor advertising to your users when they visit from mobile devices.

Additional Resources

• “Google’s Mobile Movement: Enhanced Campaigns and the Rising Cost of Mobile,” Marin Software
• “5 Google AdWords Enhanced Campaign Tips for Efficiency and Better Performance,” Crystal Santos, Search Engine Watch
• “How to Determine Your Mobile and Geo Bid Multipliers for Enhanced Campaigns,” Benjamin Vigneron, Search Engine Land
• “Optimizing Bid Adjustments for Mobile Ads,” Scott Yacko, Levers blog
• “Why You Can’t Manage AdWords Without a Multi-Device Strategy in 2013,” Andrew Lolk, PPC Hero

If you’ve developed mobile applications or have just started building one, then you probably realize that marketing should be as much of an ongoing concern as the product’s design and development. After all, what’s the point in creating a beautiful, valuable app if no one knows about it?
Assuming that promotion on Google Play or Apple’s App Store will take your app from beta to bestseller is… well, magical thinking. In reality, most successful developers kick off their marketing efforts months before release.
In this post, we’ll focus on how to get a head start with email marketing, not only by wrangling testers and staying in touch with users, but by successfully building hype for your app. Then, we’ll move on to how to announce the launch and measure results. Along the way, we’ll share techniques and code snippets from solid marketing campaigns, spanning different stages of an app’s lifecycle.
While this article isn’t heavy on coding and development, you’ll find an assortment of practical suggestions that you can apply to your projects. But if all you get is a little perspective on how important it is to actively work on getting the word out about your app from the get-go, then still consider this time well spent!

Why Email Marketing?

First, why focus on email and not, say, social media or word of mouth? Simply put, email gives you the most bang for your buck. With a return of $40 for every $1 spent, email marketing stands head and shoulders above other methods, such as keyword advertising ($17 for every $1) or banner advertising ($2). Email also generates superior conversion rates, while giving you full control over your message. And we haven’t even mentioned the big-picture goals, such as using it to keep your most valuable users in the loop — for example, when recruiting testers, announcing launch day or requesting feedback.

But HTML Email Is Hard, Right?

To be fair, creating and sending HTML email has always been a tricky sport. If your background is Web design and development (as it is for many app creators), then you’re likely aware that designing, coding and testing for the inbox is significantly different from doing that for the Web. A skim of Campaign Monitor’s “CSS Support” chart quickly reveals that providing a consistent experience across multiple email clients is truly a minefield.
Yet feel consoled that, if you’re primarily targeting mobile users (for example, by encouraging them to download an app directly to their phones), mobile email clients such as iOS Mail are powered by WebKit. This offers the luxury of a browser-like experience — including solid HTML5 and CSS3 support — in the inbox. Secondly, a number of email service providers, including Campaign Monitor and MailChimp, offer HTML email builders that not only whip up campaigns quickly and painlessly, but produce templates that make the most of mobile email clients, with media query support. In the email marketing business, we call these responsive email templates.
While we’ll touch on some of the code that goes into tailoring a better mobile email experience, we won’t dive too deep into responsive email design.
But before all that exciting stuff, let’s start with the fundamentals: building a mailing list of email addresses (i.e. subscribers). Without this, you’ll have no one to email — and let’s be clear, buying a list is never the right option.

An App Marketing War Plan

When you’re elbow-deep in designing or coding a mobile app, it’s hard to step back, change tack and focus on the equally important yet arguably less fun tasks of putting together a promotional website, a trailer and, yes, email campaigns. That’s why it’s best to make a marketing plan and execute it early on, instead of waiting until App Store approval anxiety has kicked in.
A marketing plan doesn’t have to be complex. For email, it could be something as informal as the following.

Pre-Launch

1. Choose an email service provider, and create a subscription list.
2. Build a pre-launch page with an email sign-up form.
3. Encourage people to visit the pre-launch page and subscribe for email updates.
4. Build an email subscription form into the app.

Beta Testing

• One week prior to beta testing
  Create an email campaign, inviting subscribers to a first look at the app in beta. Explain how they can download the app and provide feedback.
• Three days after beta launching
  Email your beta testers to request feedback.

Launch

• One week before launch
  Email subscribers to let them know the app is close to launching. Include positive reviews and encourage subscribers to spread the word.
• Launch day
  Email subscribers to announce the launch, and link to the app’s download page in the App Store, Google Play, Windows Store, etc.

Post-Launch

• One week after launch
  Thank your subscribers, and encourage them to leave feedback on the app’s download page.
• After major updates
  Email a summary of what’s new and improved, and encourage subscribers to spread the word.

It’s that straightforward — just jot down a rough outline of what you plan to do, on a napkin if need be. You can be as creative as you like with your email marketing strategy. Just make sure to make good on it!

Choose An Email Service Provider

If you’ve never fooled around with email marketing, choosing the right provider will likely be a touch confounding. Many services are out there for creating and running email campaigns, from Web-based ones such as MailChimp and Campaign Monitor, to self-hosted apps such as Sendy. My advice is to talk to other designers and app creators about what they’ve tried, and then open free accounts with some of the Web-based DIY services. The differences in the experiences (not to mention the features and pricing) between apps will soon become clear. Cheapest doesn’t mean best in this game, so shop around and run a few trial campaigns.
The benefit of a Web-based email marketing app is that getting started is generally quick and easy. Remember that if your needs change, you should be able to migrate your lists to another service.

Pull Together A Pre-Launch Page

Even when your project is in an early stage, it really pays to create a simple pre-launch, or landing, page with a few details about the app, perhaps some concept art and, of course, an email subscription form. After all, if visitors to your website like the concept, they’ll be keen to sign up for email updates and find out when your app is launching. These will also likely be your most valuable, passionate users for giving feedback and spreading the word when you launch. Below is the pre-launch page for the upcoming mobile game The Drowning, by DeNA:

I like The Drowning’s pre-launch page for its sophistication yet simplicity. The artwork and trailer for this ominous first-person shooter are polished and persuasive. There’s even a nice incentive to sign up to the mailing list: email updates and a free wallpaper. Above all, the entire page is geared to getting visitors to subscribe, and the subscription form is unmissable. You’ll find a couple of other great examples in the post “Building An Effective ‘Coming Soon’ Page For Your Product.”
Now back to your page. One thing your email service provider should be able to do is generate a snippet of code with which you can add a subscription form to your website and automatically push new email addresses to a list. Alternatively, a number of simple services and plugins not only enable you to build good-looking pre-launch pages, but integrate with some of the major email service providers. Popular ones include out-of-the-box apps like LaunchRock and Unbounce; if you’re already running a CMS such as WordPress, then the Launchpad plugin for WordPress is worth a look. Or you could create your own self-hosted launch page using a template such as Launching.me.
With a pre-launch page up and running, you can get back to focusing on your app for a while. Or you could start communicating with your new subscribers, using autoresponders.

Add An Email Subscription Form To Your App

While it might sound a bit odd, nothing is wrong with boosting your ongoing marketing efforts by adding a subscription form to your mobile app itself. You could collect email addresses from early adopters to inform them of updates. Or perhaps you’re planning a really great newsletter for your audience and feel that in-app sign-ups would give the app a real boost.
If Cocoa is your language of choice and you are using Mailchimp, then check an unofficial Objective-C wrapper for Mailchimp and Mad Mimi. If you are using CampaignMonitor, make sure to check the Objective-C wrapper on GitHub which can be used to create in-app subscription forms. With an extensive API, it’s also well documented and comes with usage examples. Just something to think about.

Experiment With Other List-Building Tactics

Creating a pre-launch page and adding an email sign-up form to your app are both great ways to bring more people into the loop with your current mobile app and future ones. While these tactics tend to be rather set-and-forget, you could try other things to actively build interest in your title:

• Collect email addresses at events.
  Do you attend developer meetups or conferences? If you’re going to be talking about your upcoming app, you might as well give attendees a way to track its progress. Pretty much every email service provider comes with a customizable mobile app to collect email addresses and push them to your lists. Campaign Monitor’s is Enlist, and MailChimp’s is Chimpadeedoo.
• Offer something valuable.
  One effective tactic is to offer teaser content via a blog, such as concept art or even posts on what you’ve learned during development. Smack a subscription form onto your blog posts or even in your videos (using a service such as Wistia), with the promise of useful content and updates via your email newsletter.
• Offer a discount on the app.
  If you’re building a paid app, offering a generous discount to early adopters wouldn’t hurt — if they agree to sign up to your email newsletter, that is. Slipping in an incentive is always a reliable tactic, especially when it demands very little effort.

Now that new subscribers are rolling in, let’s look at what it takes to send out emails.

Create Your First Email Campaign

Some time has passed and, after a little promotion, your pre-launch page has collected quite a few email addresses. You might have some cool teaser artwork to share now, or you might feel it’s time to invite some subscribers to join the beta phase — heaven forbid, you might be a week out from launch! Scary stuff.
At this stage, you might be tempted to obsess over the technical details of creating HTML email campaigns (which are important), but, ultimately, this is a marketing exercise. What matters above all is your message and ensuring that readers are hooked at first glance.
Another thing that folks regularly obsess over is figuring out the best time to launch a campaign. While some (albeit conflicting) evidence shows that the hour or day of the week you choose does make some difference, I think the advantages of emailing at 7:00 pm over, say, 10:00 am are marginal, especially if your subscribers are international. Even public holidays seem to work for some creators, so relax and follow a schedule that suits you. Your content will make the big difference, after all.
Having gone through all of this heavy stuff, let’s take an inspiration break and look at a couple of email newsletters from app developers, sent at certain milestones prior to launch. Click on each design to see the large version and to view the source code.

“Visit Our Pre-Launch Page”

The Drowning, by DeNA.
Now that you’ve got a shiny new promotional website, what better way to drive visitors to it than by running a campaign for your existing email lists? As an established mobile game developer, DeNa is in the fortunate position of having an established community of dedicated gamers, many of whom would probably be interested in this title. This email’s narrow format makes it comfortable to read on mobile devices, too.

“Invitation to Beta Test”

Echograph, by Clear Media.
I like this invitation to beta test Echograph because it’s as clear as it gets. There’s no waffling about this awesome animated GIF builder for the iPad — just a couple images that show beta testers what they need, a sample GIF and step-by-step instructions for installing the app during the beta phase.

“Thank You for Beta Testing”

Dropmark, by Oak.
Once beta testing has wrapped up, it’s nice to say “Thank you” and offer a little something for the effort and feedback your audience has volunteered. Dropmark’s thoughtful email campaign does this with class, by providing a discounted upgrade for beta testers. It’s a great way to ensure that they keep using the service.
I hope you’ve enjoyed that visual interlude. Now, let’s discuss how to announce your app’s launch. Hold tight!

Launch Your App With Email

So, the big reveal is imminent. You’ve probably just submitted your app to the App Store or published it on Google Play. Either way, it’s time to focus on getting the word out.
Whether you announce the launch in a newsletter or via a standalone email announcement, you need to do two things: first, make an impact, and secondly, make it very easy to download the app from the newsletter itself. To achieve both, you’ll need to get the logo and branding for your app store of choice, as well as the link to the download page and, of course, some compelling content to get subscribers excited about the app.
At our company we announced the release of our subscription form app for the iPad, Enlist, via our monthly newsletter:

The images are crisp and inviting. But the real magic happens when you view the newsletter on an iPad. A “Get it from the App Store” link appears, allowing users to download the app to their device in two taps.

As you might have guessed, we are using media queries to reveal the App Store link when the email is viewed on an iPad. While I don’t want to go too deep into code, this neat trick is worth sharing. Below is an abridged version of the HTML and CSS.

CSS

p.ipad {
    font-size: 0px;
}
…
@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) {

    a[id="reveal"] {
        display: block !important;
        background: url('http://yourdomain.com/images/appstore.png') no-repeat center center !important;
        background-size: 232px 49px !important;
        width: 232px !important;
        height: 49px !important;
    }   
}

HTML

<p class="ipad"><a id="reveal" href="http://campaignmonitor.createsend1.com/t/y-l-jidkuht-l-p/" title="Get Enlist from the App Store"></a></p>

You might be curious why we use font-size: 0px to hide the App Store link when the email is viewed on anything other than an iPad. This strange choice is explained in the blog post “How to Display Content on Mobile Devices Only.” It gives a taste of the quirkiness involved in designing HTML emails.
On to the content. Let’s go to the second launch campaign for Echograph, which features a prominent download link, plus a video and animated GIF that walk viewers through the app:

Second launch campaign for Echograph.
Nicely done. Overall, the best thing you can do with your launch email is have fun and be creative — while staying concise. And before any of you mentions it in the comments, TechCrunch reckons that Sunday is the best day to launch an app.

So, What Next?

Once your app has launched, you might be tempted to take a break from campaigns, but then you’d miss out on a big opportunity. By continuing to grow your email lists and stay in touch with subscribers — whether to collect feedback, announce updates or simply share your successes — you’ll find email to be a valuable tool in your marketing arsenal. If this sounds like work, consider going on autopilot with autoresponders, which are email campaigns that are automatically run when set off by certain triggers, such as a date (“send two weeks after visitor signs up”) or an action (“send whenever a user upgrades”). To learn more, of course, talk to your fellow developers.
This post hasn’t been code-heavy, but it could have been — designing for mobile, let alone email, is a surprisingly demanding process, regardless of your aptitude as a designer or coder. However, I wanted to focus on helping you make the most of your marketing milestones by engaging with users via email.
If you walk away from this post with one thing, it should be a desire to get your planning in the bag as soon as possible. Otherwise, you risk missing out on the opportunity to build an audience that is as committed to your project as you are. Best of luck with your email marketing journey. We’d love to hear from you in the comments.

Improve Your Email Workflow With Modular Design

Whether you’re in a Fortune 500 company or part a two-person team launching your first web app, email is one of the most important tools for reaching your customer base. But with the ever-growing number of emails to send, getting them all out the door can seem a little overwhelming. By putting in place a solid email design workflow, you’ll be able to regularly ship engaging and mobile-friendly emails with ease.

Complexity Meets Adaptation

In addition to the increasing number of emails, the need for personalization and high quality and the introduction of responsive design have turned what was once a simple process of writing HTML and CSS in your favorite text editor into something seemingly more complex. A number of customizable templates, editors, tools and even full-fledged email frameworks have popped up to deal with this newfound complexity.
All of these new tools have their advantages, and many can be combined into a workflow that best fits you and your team. But even with a great set of new tools at your disposal, how do you structure your workflow to allow for continual iteration and quick turnaround?

Enter Modular Design

Modular design is the method of creating a system of self-contained components that can be stacked, rearranged and used or not used, case by case. The goal is to be able to easily change or adapt individual design patterns without altering the system as a whole. Adopting modular design and reusable patterns into your email design workflow can improve the quality and consistency of what you send, while speeding up your daily output.
Setting up a modular email design workflow involves three basic steps:

1. Create the design system.
2. Set up a reusable framework.
3. Test and iterate on what you send.

Let’s look in depth at how we can accomplish each step in the process.

1. Create A Design System

The easiest way to streamline iteration is to break down each of your common design use cases into a system of self-contained components, each one a LEGO block, made up of content and media, that you can snap together into numerous configurations. Doing this will enable you to build a nearly infinite number of emails with ease.

Think of your designs as LEGO blocks, made up of content and media.

Anticipate Use Cases

When designing your modular email system, the first step is to anticipate your use cases. Ask yourself what type of emails you typically send. Are they mostly transactional? Promotional? Informational? While all emails will likely have the same basic elements, such as a header and footer, a transactional email might need shipment information, ordering details, payment details, a contact section, and product upsells or similar products.
A newsletter might have simpler needs, such as introductory copy, a featured story, a hero image and secondary stories. Defining the content needs of the emails that you send will enable you to anticipate the common use cases that you’ll need to plan for along the way.

Design A Pattern Library

Once you determine common use cases, you can start to design individual components according to your needs. Whether you use Photoshop or jump right into the browser, remember to keep each component as self-contained as possible. Designing several variations of each use case might also be helpful.
Having several options for a “featured story” component, for instance, allows for flexibility and keeps things from getting stagnant over time. The patterns in your library will eventually become partials within your framework, easily referred to and called upon when needed.

Turn your use cases into modular patterns.

Keep Your Pattern Library Up To Date

As new use cases arise, use your existing patterns as necessary. However, unexpected use cases will probably arise; one benefit of the modular system is that you need to design only a single component to address this situation. As you create and add patterns, make sure to keep the entire design system up to date and organized. Leaving components scattered or out of sync will make the system difficult to use. The easiest way to keep everything in sync is to turn your system into a framework.

2. Set Up A Framework

From here, incorporating your design patterns into an out-of-the-box templating system or framework is possible. And if you’re not interested in navigating the chaotic world of Outlook or Gmail, with all of their quirks, or if you need to get something out the door with minimal configuration, then options like Zurb’s Ink will do a lot of the heavy lifting for you.
But if you send a decent volume of email, then creating your own custom framework could lead to huge gains. By creating your own framework, you can add in time-saving custom helpers, keep the markup light and easy to work with, and even hook directly into your email service provider. Not to mention that you can create more customized layouts to complement all-in-one solutions. The long-term gains in quality and efficiency from setting up your own framework can be huge.

Build on Top of a Static Website Generator

Adding features and tools such as Sass, YAML data and localization to your framework could also be beneficial. The easiest way to do this is by integrating your framework with a static website generator. The building blocks that are common to email and the web will enable you to repurpose almost any website generator for your email workflow.
Middleman is a great option and one that I’ve found ticks all of the major boxes:

• The structure of projects as layouts, partials and pages perfectly fits our mental model of modular email.
• Sass is already integrated. Sass is an amazing addition to any responsive email workflow. Common workarounds such as the one for Yahoo Mail’s attribute selector become an afterthought through the clever use of selector inheritance. Sass also provides powerful features such as variables, mixins and CSS minification to cut down on file size.
• YAML data and front matter allow you to fully separate content from design and loop through data for easy prototyping.
• If you’re sending to a large and diverse audience in multiple languages, then localization can dynamically generate that diverse set of data relatively painlessly.
• A myriad of hooks enable us to easily create custom helpers for email platform-specific needs.
• Middleman is Ruby-based, making it easily extensible.

Set Up A Boilerplate

Once you’ve chosen a static website generator that meets your needs, then it’s time to set up your base boilerplate. A boilerplate includes such things as a reset file, the CSS or Sass structure, an optional custom grid system and a base template.
Base Layout Template
A basic template will serve as your base layout structure and will allow global elements to be shared across all emails. Preheaders, headers and footers will usually stay consistent across emails. If this is the case with your designs, then you can safely build these into your layout’s template. The safer approach is either to build out and include these elements as partials or, if these elements will likely move or change in particular emails, to wrap the markup in conditional statements.
Your base email template should include at least the following:

• DOCTYPE
  HTML5 is the friendliest for designing responsive emails. Remember that certain clients will either strip out or change your DOCTYPE.
• head
  A lot is important to include here: meta tags for proper character encoding, title tags for anyone viewing the standalone version of your email in a browser, reset styles, embedded media query styles, any styles to be inlined and the viewport meta tag to set the viewport’s width.
• body
  In addition to the standard body tag, wrap your entire email in a 100%-width table and cell structure, as shown below. The table with the body class will act as the body, thereby overcoming the drawback of certain clients removing the body tag.
• yield
  This is from where all of your modules for individual emails will be pulled.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="viewport" content="width=device-width">
  <title><%= data.page.title %></title>

  <%= inline_stylesheet 'template/inline' %>
  <%= stylesheet_link_tag 'template/mq' %>
</head>

<body>
  <table class="body">
    <tr>
      <td class="header" >
        [Header content]
      </td>
    </tr>
    <tr>
      <td class="main" >
        <%= yield %>
      </td>
    </tr>
    <tr>
      <td class="footer" >
        [Footer content]
      </td>
    </tr>
  </table>
</body>
</html>

Partials Based on Modules

Keep the markup of your individual design patterns inside of partials, to keep the design system truly modular. This will allow the markup for each module to be self-contained. Taking a modular approach with both your designs and your markup becomes truly powerful. Once it’s built, you should be able to move each design pattern around to different areas of the template without breaking the module, the template or any other modules surrounding it. When you’re setting up the framework, build out each module that you’ve planned for in this way.
Taking the use case from our last example, the modular markup for a featured story would look like this:

<table class="featured-story">
  <tr>
    <td class="col">
      <img src="#" alt="" />
    </td>
    <td class="col">
      <table>
        <tr>
          <td class="title">
            [Story Title]
          </td>
        </tr>
        <tr>
          <td class="abstract">
            [Story Abstract]
          </td>
        </tr>
        <tr>
          <td class="cta">
            <a href="#">CTA</a>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Sass Structure

Following OOCSS or SMACSS will maintain the modularity of your Sass. In general, keep your styles as modular as possible, just like your designs and markup.
One caveat when writing CSS or Sass in an email framework is that all media query-based styles must begin with an attribute selector (such as td[class=example]{}) in order to avoid rendering issues in Yahoo Mail. An easy workaround is Sass’ ability to nest styles. Nesting all media queries in a single attribute-based selector will prevent them from being applied to each individual style. Writing your Sass in this way will increase both readability and speed while maintaining visual consistency across clients.
Following this method, the basic media queries for optimizing the template and content area above for mobile would be this:

td[class=body] {
  @media only screen and (max-width: 600px) {
    .col { 
      display: block; 
      width: 100%; 
    }
    .title { 
      font-size: 22px !important; 
    }
    .abstract { 
      font-size: 16px !important; 
    }
    .cta a { 
      display: block;
      width: 100%;
    }
  }
}

Put It All Together

With a base framework and modular design patterns in place, it’s now time to snap all of the LEGO blocks together. Create a page for each email that you’re building for your framework. This page should be wrapped with your base template and should call any modular patterns that you need.

Thinking in a modular way will enable you to build emails like LEGO blocks. (View large version)

---
title: Example Email
layout: template
---

<%= partial "featured-story" %>
<%= partial "responsive-image" %>
<%= partial "social-callout" %>

Automate Common Tasks

One of the greatest efficiencies you can gain in your workflow is to automate frequent tasks. This typically means inlining CSS, optimizing images, sending tests, and integrating templates and modules with your email service provider. Most common tasks can be easily integrated with Rake tasks, Ruby Gems and/or Grunt.
CSS Inlining
The safest method is to inline styles whenever possible because certain email clients strip out styles from the head of documents. If you’re used to the common web workflow of writing styles in a separate sheet, then getting used to this will be hard. It can become a hindrance to modularity, and if you’re trying to use Sass to style, then this obviously becomes impossible to do manually.
Luckily, we have several options to automatically inline styles at build time. If you’re using a Ruby-based tempting engine, then the best option is to include the Premailer Gem in your project. Premailer automatically runs through your style sheet and inlines styles while preserving any existing styles when called. This is a huge time-saver, and it keeps markup manageable.
Testing
There are several ways to test how your email looks. The first stage in my process is to design and check the rendering in Chrome. Once the designs are completed, it’s time to jump into a more automated tool to check rendering across the board. Litmus is a web application, like BrowserStack but focused on delivering screenshots of your email across a wide variety of clients.
You can send your emails to Litmus in a variety of ways, but if you’re using Grunt in the framework, then the easiest way is by using Grunt-Litmus. Grunt-Litmus automates the process of getting tests to your account and lets you check rendering in clients of your choice.

module.exports = {
  test: {
    src: ['email.html'],
    options: {
      clients: ['android22', 'android4'...]
      username: "username",
      password: "password",
      url: "https://yourcompany.litmus.com"            
    }
  }
};

Testing on real devices is another common approach, especially vital with things like CSS animation and embedded video. If you have a device lab set up with a common email address, an easy way to trigger an email delivery directly from your framework is to use the Ruby Mail Gem.
Hook Into Your Email Service Provider
If you’re using an email platform that provides access (such as ExactTarget or MailChimp), then you can set up your project to hook directly into the API and push your template along with individual modules into the system on command. Doing this allows you to build locally in the framework, keeping everything modular and under source control, and still push to your email service provider quickly and easily as you iterate. How you hook into your provider will obviously vary by platform, but definitely keep this in mind when setting up a modular framework.

3. Iterate On Your Designs

The periodical nature of email lends itself well to design iteration. If you’re sending emails daily or weekly, then you have ample room to A/B test your design decisions. No matter what workflow options you adopt, make sure to track important email metrics and use available data to improve your core design, remembering that a better experience is usually more important than any single data point.

The periodical nature of email makes for easy testing and iteration.

Don’t reinvent the wheel every time you send an email; rather, make continual incremental changes as warranted by your metrics. The benefits of a modular design workflow should make these incremental changes fairly painless as you swap components in and out. The important thing is not to let your designs stagnate.

Conclusion

Incorporating a modular approach and a custom framework into your email workflow can lead to increased productivity and make it easier for you to iterate on your designs. You will have to make an initial investment of time to get everything up and running, but if you send a decent volume of email and can afford the initial investment, then the result will improve your designs, the customer experience and your engagement rates, leading to happier customers and increased revenue.

Links

• Ink, Zurb
  A framework for rapid development of responsive emails.
• “A Workflow for Responsive Emails Using Ink and Grunt,” Victor Garcia, Medium
• Middleman Email Template, DEG
  A Middleman project template customized for building emails.
• Middleman 3.0.x Project Template: HTML Email Boilerplate HAML, Danny Prose
  A Middleman template for HTML Email Boilerplate, converted to HAML.

Design Responsive Websites In The Browser With Webflow

New tools have emerged to address the challenges of responsive web design — tools such as Adobe Reflow and the recently released Macaw. Today, we’ll look at one that I have tested extensively in the last few months. Though not perfect, it’s been a leap forward in productivity for the team that I work with. Its name is Webflow, and it could be the solution to the problems you face with static design comps produced in Photoshop and Fireworks.

This article will take you step by step through the process of creating a responsive website layout for a real project. As we go along, we’ll also identify Webflow’s advantages and where it comes up short.

Getting Started

Getting started in Webflow is a relatively simple. Head over to the website, create an account, and give the free trial a go. Make sure to open the interface in the latest version of Google Chrome because it is currently the only browser that is fully supported.
Before beginning a design, decide whether to start it from scratch or to work with one of the many templates. For this tutorial, we’ll choose the blank website template.

Take a minute to mouse over the tooltips in Webflow’s interface to become familiar. There are no shape tools or layers in the traditional sense. There are also no filters or effects or even brushes. Webflow keeps everything focused on what the browser can do; so, knowing the basics of HTML and CSS is enough to get up and running.

Toolbar Overview

The left toolbar handles various functions, such as publishing your website to be shared with a live link and switching between device views (using the laptop and phone icons). You’ll use this toolbar mostly for the latter and for entering preview mode, which hides Webflow’s interface and shows what your website will look like when published.

(View the entire toolbar)

The right toolbar (shown below) consists of six tabs. The first tab (“+”) lets you add structure and HTML content elements to the page. Each item you add to the body of the page comes with default styles that you may overwrite. Whenever you need to add content, you’ll come back here. I always start with a section, a container and columns because they all have predefined behavior that changes according to the breakpoint.
A section is a div set to the full width of the viewport. A container sits centered within a section and constrains the widths of elements such as headings and paragraphs, while columns divide containers evenly in percentages.

(View the large version)

Next is the CSS tab, where we’ll spend most of our time. Here, we can assign classes to the element that is currently selected and then style it as we see fit. All of the CSS that you would normally write by hand is shown here. As soon as you change a class, the CSS will update immediately without your having to refresh. Be sure to examine the advanced toggles, which allow for control of other things such as positioning and the behavior of background images in their div.

CSS options (View large version)

The third tab is for settings of the element that you select. Here, you can control things like the visibility of content at certain screen sizes, and you can add link elements to other pages in your project. This panel has to do mainly with non-style-related aspects and is especially handy when you’re working on complicated elements, such as the navigation menu.

Control visibility and even add links.

Fourth from the left is a useful structure navigator that visually displays the contents of your website in a folder-like tree. If you need a heading to sit in a different div or container, just click and drag it to where you want it to be. I often refer to this panel as I go to make sure that certain items are in the right divs and that my styles cascade appropriately. It’s also useful for selecting content that might be hard to click with the mouse because it is behind other elements.

These elements will be represented by the class names that you assign to them, so give everything a straightforward name.

Next up is the class manager, which shows all of your CSS classes at once. You can use it to edit a particular class (see the small wrench icon) and to quickly remove any class that isn’t being used. It’s handy, but you will usually just use it to clean up classes that you’ve discarded or to quickly change a class that’s used multiple times in different places.

A quick view of all of your CSS classes.

Last is the symbol library. Complex items, such as the primary navigation and the footer, can be created as symbols, which can be reused on other pages in your Webflow website. This is a great time-saver, but know that symbols are usable only in the project they were created in.

Regarding Web Fonts

Before we begin with the project, it’s worth mentioning that Webflow supports web fonts to a certain extent. All of the usual standbys, including Arial and Verdana, are available, and you can use any font in Google’s library, as well as any you have in TypeKit. However, any font not provided by either Google or Typekit cannot be integrated in Webflow’s design view (an obstacle that my team faced).
Applying your own font using Webflow’s custom code area is possible. Do this by linking to it in the head of your website and then using a style tag to specify where to use it. However, the font will appear only after you’ve published the website, making it frustrating to refine your typography for different breakpoints.

An example of how to apply your own hosted web font.

Designing In The Browser

For this tutorial, we’ll work from the desktop view down to mobile. This is deliberate: In Webflow, every style that you create in the desktop view will cascade down. It’s weird at first, but you do get used it. The rationale is that when you change a style in the tablet view, it will change for everything below. This saves time when something is broken in one media query because it will often be broken in the narrower views.
We’ll find what we need to begin in the “+” icon (the tab to add elements). First, add a section, and then drag and drop a “navbar” into that section. Then, select the image element under “Media,” and drag it over to the logo area of the navbar. Once it’s highlighted, let go of the mouse, and Webflow will drop in a placeholder image. I’ve replaced the default image with my company’s logo. Essentially, what we’re doing here is using divs and HTML pieces that have a predefined behavior in Webflow; while empty and lacking any notable styles, they will form the basic structure of the website.

Now, let’s add the rest of the navigation, give it a background color, and change the fonts. My company uses a standard gray for the background of its navigation. Add a background color easily by selecting the navbar section with your mouse and then going down to the background area in the style tab. Once you’ve chosen a color, click “OK” to confirm.

Next, we need to add a section that sits above the navbar. This will have a link and some copy. Click and drag the section so that it sits above the navbar, and then add a container so that our new content stays centered in the browser window, like the navigation below it.

Above, I’ve added a plain-text block for the deadline copy, as well as a text link for our call to action. Both are assigned separate classes, set to display as inline-block and with the text aligned right. I’ve also adjusted the padding by dragging with the mouse on the arrows under “Position,” so that they both appear vertically centered. Finally, I’ve given this new section a background gradient.
Notice under “Position” how the padding values are blue. This lets us know that we’ve changed the default styling of 0. If it were a yellow number or a label, this would mean that the selected element’s style is inherited.

The font and line-height fields have yellow labels, letting you know that their styles are inherited.

With the styling done for the header, let’s set the structure of the main body. Our website needs copy on the left and an image on the right for tablet and desktop views. Again, add a section and a container, and define a grid by adding the column element to that container. By default, we’re given two columns. You can change this to a different number at any time by tweaking the column’s setting.

I’ve gone ahead and added a large placeholder image to the right column and paragraph copy to the left. I’ve also added two buttons. Working with long copy in Webflow gets tedious because each paragraph has to be added as its own element. It would be nice just to work with one text-box element, in which you can paste all of the copy at once and proceed to style it, as in Macaw.
For now, let’s adjust the paragraph’s line height, add style to the buttons and add the remaining content.

Last, we’ll add the footer by adding a section to the bottom of the page. We’ll apply a background color and throw in one last container to house our new text links and copyright. Another annoyance is that Webflow doesn’t yet allow for descendant selectors. I’d much a prefer a visual way to target links in the footer section with styles akin to the following:

.footer a {
   text-decoration: none;
   font-size: 12px; }

Webflow currently requires everything to be assigned a class, even if it’s already in a div that has a class that you could reference. While not a deal-breaker, a little more finesse would be nice.

Every styled element requires its own class in Webflow.

With the footer done, our desktop layout is in pretty good shape. Now it’s time to tackle any presentation issues that we find at the other breakpoints.

Fixing Breakpoints In Webflow’s Responsive Views

One of the main differences between Webflow and its competition is that you cannot define your own breakpoints. Webflow is a custom framework based heavily on Bootstrap, so a lot of the automatic behavior for content elements derives from that. You could view this as a hindrance or an advantage, depending on your situation and your project’s needs. Our current e-commerce website leverages Bootstrap, so using Webflow to prototype makes sense for us. If your website requires unique breakpoints or you already use another framework, such as Foundation, then you might have to try something else.
Let’s look at the tablet view first. Nothing completely breaks, as you can see below, although we might want to add more space between the footer and the rest of the page.

Webflow’s custom Bootstrap framework does most of the work to resize our content.

Next up is the phone view in landscape mode or, as I like to think of it, a very wide phone breakpoint. As you can see in the first screenshot below, things are getting messy. Our image in “Column 2” collides with our callout box. Also, that image is pretty large for mobile phones, so let’s shrink it by changing its width to 40%, leaving the height set to auto. For our last change, I’d prefer that our buttons appear on small screens as block elements, with widths of 100%. Check out the before and after:

Webflow makes it easy to fix a broken layout.

The same breakpoint with our changes applied.

That’s a bit better. As you become familiar with Webflow, you might decide to abandon columns altogether in certain instances because they dictate the order of your page. Suppose we wanted the image to be the first visible item below the primary navigation on phones. Because we’ve used columns and thrown the image into the righthand column, we cannot reorder it on mobile; the left column will always be stacked on top.
If we used our own divs with our own CSS rules, we could easily circumvent this order with some floats. So, even though columns are easy to work with and they come with predefined padding and their widths switch to 100% at low breakpoints, they can also be limiting.
Before moving on, let’s look at the default styles for the navigation menu when expanded. We get there by selecting the navbar and going to the settings tab. Once you’re in settings, click “Open Menu,” and you should see something like this:

Menu before

That’s a lot of dark gray, with no indication of the boundary between menu items for users of touch devices. Select a link and proceed to change the style. Let’s also separate the links with a bottom border. Other options are available to play with animation, but I’m happy with the defaults for now.

Menu after

Much better. I’ve inverted the colors somewhat to make the menu items stand out more, and I’ve added a box shadow to give a sense of depth in case it overlaps with elements like buttons. Of course, you can refine it further, specifying hover states and pressed states, but for now let’s look at the smallest breakpoint and see how our changes cascade down.

Not bad but the header takes up a lot of space. Considering that browser chrome will take up space, too, let’s shrink it a bit.

There we go. You can view the result on the demo page. If you’re on a desktop machine, resize your browser to see how the layout changes. One of the last items we’ll look at is Webflow’s code-exporting feature.

Exporting The Code

In the left toolbar is an icon that allows you to export your work as a full ZIP file, with the HTML, CSS and all images that you’ve used. At this time, there are no options to tweak how your website gets exported. Having the option to choose between LESS files and one master style sheet would be nice in future, as would an option to point to the paths where images are publicly hosted.

Webflow’s code is relatively clear and straightforward enough. Being design-focused, it does throw just about anything it can into a div, and you’ll see a lot of custom classes that look akin to Bootstrap 3. It also includes a separate style sheet for various fixes, so your website should work in most browsers. Your mileage with the exported code may vary, depending on what you need to do with it. The developers on our team found it easier just to replicate my interactive mockup in Bootstrap 3, rather than try to build on top of the code.
We did this for two reasons. First, our website is a Backbone application that needs functionality such as timed user sessions, Google Analytics and an administrative back end. Secondly, Webflow’s code does not support Internet Explorer 8, which is a requirement for our user base, unfortunately.

Conclusion: A New Tool For Designers

Webflow is a tool targeted at designers who are looking for an alternative to Photoshop and Fireworks for responsive web design. It’s not an all-encompassing solution for creating websites — at least not yet — but by enabling me to focus on layout, interaction and content behavior without having to code, it sped up our team’s design phase immensely.
And while we didn’t use the code that Webflow generated, we still found it to be more collaborative, allowing the developers who I work with to see the work I was doing on their actual phone, tablet and desktop browsers. They could ask questions any time, and I was able to iterate on the fly. Sitting down to actually build the website was easier because we had an interactive prototype to refer to.
I still use Photoshop as I believe it was intended — to crop and retouch images — but when I’m asked to make a new page or a new website, I’ll start working in Webflow. And I’ll continue to refine and expand the visual prototype until we feel we’ve taken it as far as we need to. Then, we’ll move into development, still using Webflow to prototype or test ideas if needed.
On today’s responsive web, a static comp raises more questions than it answers. Sure, you’ll be able to convey the look and feel, but so many questions remain that both designers and developers can get frustrated. As designers, we try to resolve these questions by creating accompanying documentation, such as a web style guide or even sometimes by building a basic page ourselves.
Developers who receive static comps to build from either have to infer missing details or go back to the designer. How does the navigation adjust? What are we envisioning for hover states or for pressed states for buttons? How will the typography change to accommodate different screens? How do we denote an active page? The list goes on and on.
Webflow fills this gap. Details can be inferred because they’ve been realized and are viewable in the browser. It enables you as the designer to experiment and prototype interactive ideas on the fly. How the tool fits in your process will depend on you and the needs of the project. However, I strongly recommend giving it a shot. It might surprise you.

Other Resources

• “Video Tutorials,” Webflow Help
  This free series of videos walks you through the UI and how to build websites in Webflow.
• “Forums” Webflow Community
  An active and knowledgeable community of people already use Webflow.