Posts About Foundation
Posts About Foundation
Update: We released 2.2.1 shortly after this release to add in more Ruby scaffolding
We're stoked to announce that Foundation for Emails 2.2 - codename Bismarck, has been released into the wild! There's so much about this release to highlight so we'll focus on the biggest parts. We've got new implementations, juicy features, and time saving bug fixes. Since we launched Foundation for Emails 2.1, we've seen a huge jump in excitement and involvement on GitHub with contributions. We were going to release a 2.1.1 with bug fixes but instead we skipped ahead to 2.2 from 2.1 because there were so many great features jammed into this release!
The most important part of your email is not the code, it's crafting the right message that connects and engages people. The less you have to worry about coding your emails, the more you can focus on your messaging.
A Gem of a Workflow
The highlight of this release is the Ruby versions of Foundation for Emails and Inky. So many people have told us they love the concept of using Inky markup in their workflow but couldn't because they're in a Ruby environment. Well, now you can! Inky-rb and the Foundation for Emails gem now easily integrates into your Rails Asset Pipeline. Now you can use Foundation for Emails CSS along with clean Inky markup to build emails in your environment. Maybe it's just our bias, but we think combining Inky-rb with Premailer might just create the best email development environment for apps ever. ;)
New Features from the Sea of Contributors
There are tons of other great features in this release from over 30 contributors. Most of the features and fixes will help make emails less of pain, saving you from throwing your laptop across the room and flipping your table. There's too many to list here so here's some of our favorites:
- Get that visual treatment you're looking for by vertically aligning content in columns and source ordering columns. HTML attributes can now be passed to rows and columns thanks to Brandon Barringer - commit
- Create more controlled and compelling layouts across devices with different height spacers for the large and small breakpoints. Awesome update from Ethan May - commit
- Raise your open rates, click thrus and reduce spam complaints by including a preheader. This capability has been added to the default layout along with styles to visually hide it - commit and commit
- In case your audience opens your emails in browsers, Buttons and Menu Items can now get attributes thanks to Clement Paris - commit and commit
<hr>'s are notoriously hard to style in most versions of Outlooks. Now
<hr>'s can be styled across every email client thanks to Brandon Barringer - commit
- Hugo Giraudel and Rafal Proszowski simplified Sass code across 10 different files making it easier to read and contribute!
These are just a few of the awesome updates to 2.2 - check out the release notes to see more the of the changes!
From the conversations on Twitter, the Forum, and GitHub, it's obvious there's a ton of energy and excitement about where Foundations for Emails is going. We hope you see the potential here: how much it helps us spend less time coding the emails and more time on messaging and connecting with our audience. So go grab Foundation for Emails 2.2 and if you're in a Ruby environment, get the new gem. If you're working on something you're proud of or have any suggestions for Foundation for Emails, let us know in the comments below!
Foundation for Emails Meetup on July 14th
On July 14th, 2016 at 6:30PM, we're having people over our place to have some pizza, drinks and geek out about emails. We'll be sharing how to code up an email scaffold in just 10 minutes and talk a little about how you can use Foundation for Emails in your Rails asset pipeline. If you're in the area, come meet the team and be sure to bring your laptop!RSVP FOR THE FOUNDATION FOR EMAILS MEETUP
Let's be honest. People are messy. Organizations are incredibly dumb. Code can look like spaghetti. Given those facts, it's absolutely amazing that anything of significance (or even functioning) can be built by people from around the world that have never met. Yet here we are, almost five years into this Foundation product, today releasing Foundation for Sites 6.2.2. It's incredible to see over 12000 commits by 1000+ contributors. How in the world does this all work?
Given that we were not professional open source coders, the whole thing was a tad intimidating when we embarked on this journey in 2011. But we've learned a lot these past 5 years, and we're more excited than ever about the ways the community is contributing to Foundation's future. We've examined what's helped grow Foundation and narrowed it down to three things.
Here are the elements of success:
Have A Strong Opinion
This may sound counter intuitive, but the way you keep a vibrant open source project is by saying 'no' more than you say 'yes.' How can that be? Because strong opinions guide the growth of a project, attract like minded contributors and keep the quality level high. Foundation has always been more than a tool for us, it's a philosophy, a point of view. We have a clear mission here at ZURB, to change the way people design connected products and services, and Foundation is one the ways we're helping transform organizations.
Our vision for Foundation is not simply to create tools for implementation, but rather to create a shared language for designers and developers to communicate about what they are creating. This vision helps shape which contributions we accept and which we don't. As a product design company, we're constantly dreaming of new ways to push the limits of what the web can do, and we use Foundation day in and day out to make those dreams a reality.
Tools Matter Less Than Collaboration
As a technical product, we're selective about the tools and services we use to develop Foundation. The development process all flows through Git, a revision control tool that was created by Linus Torvalds, the creator of Linux, and specifically optimized for the problems that arise when managing a large software project with hundreds or thousands of contributors. Building on top of that, we use Github, giving us a web-based hub for our source code.
But the really important part is the collaboration these tools enable. Github helps us issue reports and have conversations that are rooted in the code. Slack and email help us have bigger conversations and involve the whole team. And the Foundation Forums put us in direct contact with users around the world. There's a misconception that software development is carried about by isolated nerds wearing headphones, eyes fixed on screens, and saying little to each other. The nerd part is true, granted, but development of something as big as Foundation is a very communication intensive endeavor and requires all kinds of interactions to be a success. While tools are important, it's the interactions that they foster that carry the most value.
Project Inspired (Not Project Managed)
Foundation has it's roots in our internal styleguide, and is used every single day in all of our client work. We absolutely depend on it, it has to work. You can imagine how hard it was for us to let go and open it up to the world. But you know what it? It made Foundation better! This is not to say we didn't have a few bumps in the road.
When we started opening up the Foundation development process more to the community, quite bluntly we had no idea how to update our processes to facilitate community development. We accepted pull requests on a rather haphazard basis, but mostly we continued to manage development and issue fixing mostly in-house. And you know what? Project managing sucks!
We realized that instead of project managing, we needed to share our goals with the community, provide a few guidelines, and let these brilliant developers run with it. We set up some contributing guidelines to get us all on the same page and christened a new team of superhero devs, the Yetinauts, to lead the way. We're proud to be able to say that our last 2 releases have been over 80% community driven.
Five years into this, and Foundation remains the leader of the pack, advancing not just frameworks forward but the web as a whole. It was difficult to 'let it all hang out', but moving development out into the open was the best decision we could have made. With your help, we're upping the ante even further. You can start by talking in the Foundation Forum, dig into the Foundation for Sites outstanding issues, or get involved with Foundation for Emails 2. This is your chance to help change the future of the web.
Foundation for Emails 2 has already changed the email workflow for thousands of people with a revamped CSS codebase, Inky markup to ditch tables, and a powerful workflow to stay D.R.Y. It makes coding HTML emails, well, easy. Today we are releasing Foundation for Emails 2.1 which further optimizes your workflow and speeds up coding. There are a couple new Inky components and more ZURB Stack magic to simplify your HTML email development and make you an email pro.
Beefing Up the ZURB Stack
Testing is a very necessary but time consuming process. Tools like Litmus exist to speed testing up so you can test many devices and email clients at once, but you still have to zip your images and send your email to Litmus for testing. But, what if you don't use an email service provider? How would you send the email to Litmus? Not to mention your images still need to be hosted.
To solve these problems, Foundation for Emails 2.1 introduces loads of helpful new features. The ZURB stack can now tie into your existing Litmus account and with a single command inline your code, optimize it (compress your HTML and images) and send it off to Litmus for testing. If you have an Amazon S3 account, the ZURB stack will replace your images with hosted ones so that they can be tested on Litmus. Foundation for Emails 2.1 helps you save even more time testing and preparing your emails so you can spend more time improving your product. Whether you have no email workflow or want to upgrade your existing one, Foundation for Emails has your back.
Huge, huge shoutout to Dan Van Brunt, @iDVB on GitHub and Twitter for setting this up and getting it across the line for this release! Give him a shoutout!
Just want to say thanks again for allowing me to help contribute foundations for email. I loved working with ink in the past so being able shape future of email development is pretty awesome.- Dan Van Brunt
Expanding Inky's Features
Everyone we've talked to has had wonderful things to say about Inky and Foundation for Emails 2. Coding a responsive email template in ten minutes is no longer wishful thinking, but full blown reality! Foundation for Emails 2.1 brings two much needed new Inky components that speed up coding even more.
New Spacer Inky component: Vertical spacing between email clients is not as simple as it sounds, in fact, it's consistently inconsistent. Versions of Outlook don't respect margin and padding the same and
<br>'s are different all over the place. Plus who wants to see
<br><br><br> all over the place?
<spacer> component takes care of this. It works the same on all devices and email clients saving you time and headaches down the road!
The size is the height in pixels of vertical spacing you need.
Thanks to Antonin Cezard, @acezard on GitHub for the Pull Request to add this into Inky!
At first I had a custom jade+gulp workflow but when I saw you released V2 I switched to your stack. This type of tool is too hard to maintain alone so, glad to contribute in a long lasting project. I definitely look forward to make some more PR's in the future.- Antonin Cezard
New Wrapper Inky component: The
<wrapper> component was also added to allow the creation of full width rows, targeting elements in section and adding background colors. These new components save you time not only coding but also in testing.
Making beautiful fluid width headers is now a reality:
All the starter templates have been refreshed with these new components.
In addition to developing the framework, the Foundation team has spent the last several months crafting our ZURB Responsive Email Masterclass. It's loaded with everything we've learned on responsive email design and development so our students can approach any email design challenge. We're continuing to add content to the course so our students keep up with the latest best practices, techniques and workflows.
The Big Picture
We're super excited about the reception that Foundation for Emails and Inky have gotten, and want to talk a little bit about where they are going. We see a future where Inky becomes the standard for how emails get written, anywhere and everywhere. This involves integration into all of the different environments where people are sending emails (the much-requested rails integration is coming soon), and making it easy to extend Inky so that everyone can build their own custom open source and proprietary email components.
Email development should be just as simple as web development, where you can easily integrate open source components, extend those components with your own custom styles, and create your own custom pluggable elements. Just like a company builds up a library of custom, pluggable modules of code and components, they should be able to create a set of custom, pluggable inky tags that make generating brand-coherent, beautiful emails as easy as can be.
We're starting the discussion of what that should look like today: Please join the conversation in the Foundation Forum
It's time. Foundation for Emails 2, the successor to Ink, has landed ashore! When Ink first launched in 2013, it made HTML email development suck less by giving developers a full responsive grid and set of components that worked right in any email client - even Outlook. Ink was the first product to take email best practices and create a framework out of them. Since then, companies of all shapes and sizes - Airbnb, Vice, Express, the Golden State Warriors - have been using Ink to easily produce great email campaigns. Now, with Foundation for Emails 2, we're streamlining email development workflow even more.
We've put a lot of work into making Foundation for Emails feel familiar to the millions of designers and developers who already use Foundation for Sites. Whether it's building with the grid, using Sass variables, or developing in our ZURB Template-inspired email developer, you'll feel right at home.
Here's what's hot in version 2:
A Sass codebase. Fans of Sass can now access a full settings file, giving you complete control over the visual styles of the framework. The component and variable names all have direct analogues to ones in Foundation for Sites, making it feel instantly familiar.
A full email development workflow. When Foundation for Sites 6 launched, we unveiled the ZURB Template, an all-in-one workflow for making static sites. We've done the same for HTML emails now with the ZURB Email Stack. Write HTML and Sass, compress images, and inline emails all in one starter template!
Inky, a simpler way to write HTML emails. Ink streamlined the process of writing HTML code for emails, but you still had all those tables to deal with. Who needs 'em? The ZURB Email Stack includes Inky, a new templating language that converts simple HTML tags like
<columns> into full table syntax.
Get Started Now
Much like with Foundation for Sites, we've got two ways to get started writing HTML emails with Foundation for Emails. The basic CSS download includes everything you need to get started right away: a boilerplate HTML file, the Foundation CSS, and twelve pre-made email templates to get you going. We've got a full tutorial that covers the whole process, from downloading to making a grid to inlining.
For fans of Sass, the ZURB Email Stack gives you access to a powerful build system with everything you need to develop HTML emails. And if you have the Foundation CLI on your computer, you can already install Emails projects! Like with the CSS version, we've got a full tutorial for the Sass version that explains how the ZURB Email Stack works.
Foundation is a community effort'we couldn't do it without viewers like you. If you run into a bug with the framework, report it on GitHub so we can help you out. Or, if you're not afraid to sail the stormy seas of HTML email yourself, submit a pull request and make your mark on the codebase!
We've also got a milestone for version 2.0.1, so you can see what's next for Foundation for Emails. Hope to see you around!
New ZURB Master Class: Responsive Email
We've compiled all of our knowledge and insights on responsive HTML emails in a new online video course! Master responsive email by learning how to rapidly design and develop responsive emails that are on-message and display well on just about every screen, browser, and email client out there ' even Outlook.
If you've been following the ZURB Blog over the past few months, you've no doubt read some of our writing on email design. We send out thousands of emails every day at ZURB, whether it's newsletters to our Foundation and University fans, or transactional emails to Notable users.
For years, the experience of coding up those responsive emails was nothing but pure pain. Because of our growing frustration and with no solutions on the market, we developed Ink in 2013. Ink streamlined HTML email development by creating a framework around email best practices. It was a huge step in the right direction, taking some of the sting out of coding HTML emails.
We've taken HTML email design and development to a whole new level with the successor to Ink, Foundation for Emails 2. Foundation for Emails 2.0 builds on Ink by adding new components and better workflow tools, so you can write HTML emails faster than ever. Ink took some of the pain out of HTML emails, and Foundation for Emails 2 finishes the job and even makes it, dare we say, fun.
Foundation for Emails 2 launches in less than 24 hours! Let's look back at what we've been saying here at ZURB about email design.
We started the year out writing about the numbers behind transactional emails. At the end of January, we did a deep dive on some of the mechanics behind coding HTML emails, and showed how Foundation for Emails 2 will help you conquer the beast of HTML email. As it turns out, Outlook is still a threat'but Foundation is here to help you ensure your designs look great in even the oldest email clients.
Over the course of the past month, we published a two-part series on an internal experiment we ran on the emails sent by the Foundation Forum. We reviewed the transactional email sent to notify users of new posts, and looked for ways to improve it. Would streamlining the design improve the click rate? The results were surprising.
Lastly, we published TestSubject on the ZURB Playground, a web-based tool to preview how subject lines render on mobile email clients. With half of all emails opened on mobile devices, it's important to ensure that your subject line, preheader text and sender name are working together to influence that open. You also need to make sure those small screens don't truncate your subject lines in comical ways.
And that brings us to today. Foundation for Emails 2 is rocketing towards a stable 2.0 launch the morning of Wednesday, March 23. If you haven't already, sign up below to be notified exactly when Foundation for Emails 2 is available.
On February 16th, we started an open experiment on the transactional emails we send within our Foundation Forum. We changed a number of things, cleaned up the emails, *made them more personal, all with the goal of improving our click through rates and increasing engagement within the Foundation Forum. With our current focus on improving the way the world builds emails, we decided to do this experiment in public so that we both share our learnings and learn from the community about how to improve our emails. We received some really interesting, in-depth feedback on how we could have better set up the experiment and a number of unknowns that might throw things for a loop. Even so, we decided to let it ride as it stood and see how things turned out.
Now that we've let the experiment run for a couple of weeks, let's dive in and see what happened.
Overview of the Results
From Feb 18 to March 3, we sent 989 emails to the experimental group, with a 60.8% open rate and 19.2% clickthrough rate. We also sent 573 emails to the control group, with an 62.3% open rate and 31.9% clickthrough rate.
Whoa, What Just Happened!?!
We certainly weren't expecting that! We were expecting the new emails to get a better clickthrough rate than the old!
Digging deeper, let's look at the distribution of emails that got sent. There were significantly more emails sent to the experimental group (989) than the old group (573)' but we were supposed to be testing a random equal distribution. What happened?
When setting up an experiment like this, you have to make a decision about how you're going to distribute who gets what. You could do it completely randomly on a per email basis, vary it by post, or vary it by person. We chose the last, with the thought that each individual user should get a consistent experience. And on a per-user basis, things were pretty balanced, with 152 users in the experimental group and 154 users in the control group. The problem with this approach is that we have some power users in our system.
Let's look at some histograms of how many emails a particular user received for each of these conditions:
As you can see, the majority of users in either condition received between 1 and 3 emails, but in both cases have a long tail. In the experimental case, we had a power user to the extent where a single user received 204 emails within the 2 week period of the test! No wonder our numbers sent were a bit skewed' and it is easy to imagine that a user like that probably isn't clicking on as high a percentage of emails as user just receiving one or two - they may just live in the forum and see the responses in real time!
What happens if we factor out the impact of power users, perhaps only looking at users who received 5 emails or less? In the experimental case, this trims us to 217 emails, with a 54% open rate and a 19.3% clickthrough rate. In the control case, we're at 235 emails a 64.6% open rate, and a 37.8% clickthrough rate. Even more extreme!
So What's Going On?
Based on our data we can pretty definitively conclude that click through rates are lower with the new version of the emails. That wasn't what we were expecting, but in retrospect this comes back to something that Ethan asked in response to our first blog post:
'... what problem are you trying to solve and how will you know you've fixed it?'
The thing that we're trying to accomplish is to get more folks engaged in and replying in the forum, but the data that we're measuring is click through rate, which is only an imperfect proxy for that. One of the most visible changes we made in the email was we started showing much more of the message directly in the email - we shifted from showing up to 75 characters to up to 400 characters directly in line. What if a fair number of people were just clicking in order to be able to read the whole message? Lets look at a quick distribution of the text sizes of the emails sent in our experiment time period.
As you can see, expanding the limit from 75 characters to 400 characters dramatically increased the number of comments that were completely visible from within the email. At 75 characters, 10% of the comments were completely visible from within the email, while at 400 characters that number goes up to 65%.
Unfortunately, we didn't set up the data in a way that we can easily dig into clickthroughs at different comment sizes, but this seems like an extremely plausible answer as to why our outcome wasn't exactly what we were expecting.
This experience highlights how important it is to be careful and precise in what we're measuring in an experiment. We need to carefully ask 'What is the question we're answering?', and 'What data will accurately convey an answer to that question?'. As we saw here - we thought we were asking one question 'Can we get more people to respond to forum posts?' and instead ended up getting an answer to 'Do people click less if they can see all of the content within their email?'.
It also highlights how experimentation is a process, not a single activity. The outcome of an experiment is an insight, not a perfect result. We can move forward, asking new questions, optimizing for new things, and keep the process rolling. As we wrap up development on Foundation for Emails 2.0, we're excited to make the creation of emails quick and easy so that your organization can do similar experiments to optimize your content. When the pain is taken out of HTML emails, it frees up time and resources to dedicate to improving engagement, helping us reach our goals and move our organizations forward.
We'd like to understand if the new emails are actually creating a better experience - and more value - for the users of Foundation Forum. We've seen that they generate fewer clicks, but have a new hypothesis that this is because people are more able to see an entire response without clicking. How can we measure if this is a better experience?
Our thought is to identify a list of users who have received both emails (i.e. were receiving the old emails before, and are receiving the new emails now), and send them a quick survey using Notable Tests to ask their thoughts. The reason for this is we now believe the difference is more qualitative rather than quantitative, and a survey might capture that more. But it's not immediately clear this is our best way to get at this. What do you think? How would you test for this? See you in the comments!
When Foundation 6.0 was launched last November, designers and developers were introduced to new tools built from the latest web technology that enabled them to build responsive sites faster and easier than ever before. Whether it's the ZURB Stack, which uses the latest in front-end tools, or the flexbox grid, which puts Foundation on the cutting edge of web standards, Foundation continues to be the most forward thinking front-end framework.
The way you use Foundation plugins hasn't changed at all, but users of the ZURB Template will need to make some quick changes to compile the new codebase'we cover this in the 6.2 Upgrade Guide. We'll also be collecting feedback on the upgrade process in the Foundation Forum, so be sure to join the rest of the Foundation community in the conversation!
More Flexbox components! With Foundation 6.0, we introduced an optional flexbox grid, for developers building sites with more cutting-edge browser support. In 6.2, we've now added an optional flexbox mode which supercharges existing components with flexbox, replacing old hacks like floats and table cell display.
If you've never used flexbox in your CSS before, you're in for a treat. Flexbox solves many problems with web layouts that have plagued web developers for nearly fifteen years. With the display: flex property, it's now much, much easier to automatically size elements based on their contents, or how many items are in a row. Both horizontal and vertical alignment are also dead simple, no more weird transform hacks to center things! And there's even more: automatic right-to-left support, built-in source ordering, and vertical orientation.
If you're just getting started with flexbox, the article A Complete Guide to Flexbox on CSS Tricks is a great place to start.
More native elements! We borrowed the styles for
<meter> from Foundation for Apps and brought them into Foundation for Sites. These are newer HTML elements which can replace our built-in components for range sliders and progress bars, if you have the browser support.
We couldn't have turned around Foundation 6.2 as quickly as we did without hard work of our awesome community. Nearly two dozen community members contributed code to this release. We'd like to call out a few folks in particular:
- Andy Cochran reworked button groups to fix multiple issues with responsive stacking and borders. (Pull request #7933)
- Marius Olbertz added right-to-left language support to the Slider plugin. (Pull request #7684)
We also have some great discussions happening over on the Foundation Forum! Over the past few weeks, we've been collecting feedback on the functionality of Reveal and the Responsive Menu patterns. We took some of the feedback from those discussions and put together some bug fixes for each in 6.2.
- We fixed a number of issues with dropdown menus, including positioning and arrow bugs. (Pull request #8200)
- We reworked Reveal's positioning logic, fixing over a dozen open issues in one fell swoop. (Commit 884b10)
Foundation 6.2 introduces some significant changes to the codebase that make your workflow even easier and keep you on the bleeding edge of the web. Many of these changes are designed to bring the code more in alignment with the next version of Foundation for Apps 2, which we'll have more to say about soon.
We're also looking to invest in the awesome Foundation community in a big way. We'll soon be publishing a Contributions Guide that details how you can get involved with the Foundation ecosystem.
In the meantime, dive Foundation for Sites 6.2 by reviewing the changelog and the upgrade guide. We're collecting feedback on the upgrade process in the Foundation Forum. We're anxious to hear what you think of Foundation's latest leap forward!
Even more than websites, emails give you a chance to run all kinds of experiments. Every email you send is a chance to test out ideas and gather data. Earlier, Brandon wrote about the importance of transactional emails, and how Foundation for Emails 2 will enable you to more easily create rich, responsive layouts for those emails. But another great thing about transactional emails is that, because of their frequency and volume, they can provide you with a massive amount of data to play with, becoming an ideal playground for experiments.
Best practices can take you a long way, but every email is different, and without running experiments it is easy to end up doing a lot of work that doesn't actually move you in the right direction. As a product design company we care deeply about the qualitative experience we create, but we're also always looking for numbers to back up our decisions and show us that we're moving in the right direction.
Choosing a Target
As we've been working on Foundation for Emails 2, we've been realizing how many places we could improve upon our own use of transactional emails throughout the business. Email has come a long way, and with such a powerful tool now in our toolbox, the problem becomes less about 'how do we improve these' and 'what do we do first'? With two decades of history as a company, we have hundreds of different email templates we *could* attack, but as a small team with limited resources, we need to aggressively prioritize.
Once we started having these conversations, opportunities for improvement seemed to jump out at us. It almost seemed like some of our old systems started to misbehave just to try to get our attention - Our older version of Notable REALLY seems to want Peep from ConversionXL to join:
However, to maximize our leverage and rate of learning, we decided to start in the places we send the most emails, and gradually work down into the less common emails. This led us to our Foundation Forum, where we've had over a million visitors in the last year and send thousands of emails a month.
We're doing this experiment out in the open, both to share our process and get your feedback so we can continue to improve. Today, we'll go through the changes we made, and next week we'll check back in with the results. Full disclosure: These changes went live today, so we don't actually know if the results will be positive. We think we're moving things in the right direction, but data is where the rubber hits the road.
What We're Optimizing
The emails we're working on optimizing this week are for our Foundation Forum. Every time someone replies to a post in a forum, a set of transactional emails are triggered to the author of the post, anyone else in the thread, or folks who have been @mentioned. This is a great opportunity to increase engagement - getting folks back to the forum helps us build community and keep the amazing project that is Foundation growing. We get pretty good click rates on these emails - ranging from 59% for a post owner getting notified to 24% for notifications about a post you follow - but looking at the email content we still see plenty of opportunity to improve. Let's see if making those improvements result in better click rates.
Our old emails get a pretty good click through, but had a lot of areas that we highlighted for improvement. Below is an image of what we used to send. As you can see, there's a lot of room for improvement, with weird layout issues and a lack of personalization. To figure out what to target, we threw a screenshot into a Notable Notebook and started marking it up, highlighting issues like impersonal feel and funky spacing.
Click on the image for an interactive view of all the items we highlighted to address:
Post redesign, we have a much cleaner email format with much more personal feeling content. The call to action is more relevant, and the lesson content is now customized based on the topic of your post.
See the screenshot below and click on it for an in-depth dive on what we improved.
And the two side by side:
With this rework, we have a cleaner, more personal email. But will it help? We think this will improve our click-through rates, but we won't know the results until we check in next week. What's your prediction? Will this improve our click-through rates? Why or why not? What have we missed?
Ahh, HTML emails. One of the most dreaded parts of product design. For the uninitiated, designing and developing HTML emails is notoriously difficult. It results in a sea of tr's th's td's in your HTML code. Your styles also need to be inlined so some email clients can even render the styles in your email. Finally, much like a wild beast, Outlook will do whatever it wants sometimes ... Seriously.
In 2013, we released our responsive email framework - Foundation for Emails (originally known as Ink). Ink was an awesome contribution into the world of responsive email design. It was the first of its kind! Designers could now code up an email that would look great in everything - even Outlook. We began to tame the beast that is HTML email, but we could further domesticate it.
We set our course to conquer the beast that is HTML email with the upcoming Foundation for Emails 2. Our main goals were to:
- Include a small grid - just like in Foundation for Sites
- Create handy templating language - letting you use simple tags to spit out the numerous table tags
- Flat file generator (Panini) - Lets us use partials and handlebars to get your email off the ground.
And...We did it! But the journey wasn't easy, and we still have our work cut out for us. However, for our sanity, and to maintain yours, we've documented some of our best battles while building Foundation for Emails 2. Here were some of our favorites:
The Missing Link to Patching the Leaks.
It all started trying to solve, what was thought as, a simple problem. We wanted to create a menu element. Simple enough - just some basic inline-block elements and anchor tags for the links. We coded it up and things were lookin great. Here's what the syntax looked like:
Easy peasy! We fired up Litmus to test it out. Things were lookin hot - even in Outlook 2000. But wait! Something was completely off for Outlook.com and Office 365. Like waaaay off.
Ok. Maybe the css rules weren't specific enough? Maybe I just need to !important something? No dice.
Alright, this is a little weird. Maybe it's because we used a td, not a th. Nope.
Hmm. Ok now this is confusing. It works in literally everything but the Outlook.com and Office 365. What the heck? Let's just start applying different color properties to the tag to see if anything is applied. Let's make the font color blue for table.menu, purple for the td, and pink for the a tag. Everything should be pink right?
What?! How is this even possible?? Ok, let's wrap each menu-item with a table and give it it's own class Hold on ...
It's injecting HTML now?! Looks like I accidently added menu-link class in the href attribute. Wait a second, let's just see if it needs an actual href ...
Yes! Holy. Smokes. Outlook.com and Office 365 need your anchor tags to actually have a proper link to render. 15 iterations later, and we've finally narrowed down this painfully simple bug. Emails are hard sometimes.
Reeling in the inline with Inky and the ZURB Stack.
HTML emails can also be smooth sailing sometimes. We were flirting with the idea of inlining our own CSS. It was actually pretty simple! In the past there were several steps just to prep an email ready to test. First, we had to insert ink.css and our custom styles into our HTML file. Then we copied and pasted that email to our handy inliner. Finally we had an email to begin testing.
This would take the wind right out of our sails.
We harnessed the power of Gulp and a CSS inliner. We just inlined everything but the media queries and kept those in the style tag. It just kind of worked! Not too shabby.
Ok, not too bad. But we took it a step farther. We heard some issues on our github around some file size limitations with ESPs. As we started building with components like the block-grid, we realized that white space can still mess up designs - particularly in Firefox web clients. We decided to collapse the whitespace for production.
We realized there were two states of an email developer ... either building or debugging. We created two tasks for this! We have `npm test` that does cool things like fire up BrowserSync to instantly update your changes with every save. Then, we have `npm run production` which inlines and minifies everything, getting your email prepped for the debugging and production world.
This seems to work awesome in everything, except one minor bug in outlook.com in Firefox
Inky to the rescue - introducing the new and improved grid!
Ink was a good first pass, but we weren't able to tackle the small grid for some devices, specifically, android 4.4 default mail client. Luckily, we had the help of a killer community on Github. We did a little research and discovered that we could simply change TD tags to use TH's. And it just magically works!
We also took a stab at creating an easier to understand format for the grid. Mainly removing those pesky wrapper classes. We've updated the syntax to look like this:
We've now got this crazy awesome templating language that magically converts custom tags like
<column> and spits out the numerous tags needed for an HTML email. Checkout the code difference below!
The Calm After the Storm
All in all, we've had quite a journey! We've had some serious horror stories battling the beast that can be email, but our struggles have resulted in a rock solid responsive email framework that will save you time coding and testing your emails. Foundation for Emails 2 is coming out soon, so be sure to sign up below to get the latest updates. In the meantime, we'd love to hear some of your email battles. Feel free to share them in the comments!
Email is a ubiquitous part of our everyday routine, from our personal lives to our professional. In fact, the average mobile internet user spends 42% of their time on email, that's email for correspondence, task management, marketing and notifications. Transactional emails come in tons of different forms including Welcome emails, Password resets, Receipts/invoices and tons of other types. These transactional emails are the lifeblood of your product and can be used to drive up to 6 times more revenue than the average marketing email.
Through our studios work ZURB gets the opportunity to work on tons of amazing product every year and we've seen a huge rise in email within those products. Emails aren't afterthoughts, but an integral part of your product's life cycle. Let's take a look at a high level flow from Notable, one of the products we build internally here at ZURB.
In this instance we can see tons of emails being sent with huge opportunities to bring users back into the app and increase touch points with our userbase. There's a fine line between just enough email and too much, so it's important to remember that just because you can send an email doesn't mean you should.
Rapidly producing, testing and tweaking
We recently announced the upcoming release of Foundation for Emails 2 and opened our private release candidate to some great community members. We're having really valuable conversations on our Github repo and we continue to hear about companies and individuals working to maximize the efficiencies of their workflows. With so many emails being sent out, opened and clicked we have tons of opportunities to iterate through ideal solutions. In many campaigns the difference between a 20% click through and an 30% clickthrough can be 10's of thousands of people. This is why segmentation and A/B testing are such big business in the email world and why making email syntax much more simple was so important to us here at ZURB.
Quickly scanning and modifying a layout becomes easier, so when you want to A/B test a layout it's simpler than it's ever been. We hope this means more testing, more data and more money from your user base.
In addition to rapid creation and quicker changes, well tested emails can positively affect your brand's image. Broken layouts, images and links can impede the trust your user base has for your product and lead to a drop in overall sales. This is why testing in the email world has become such a huge business and why we find it important to crowdsource as much of this testing as possible. One of the main benefits of using any framework is that you've benefited from every person who used this framework before you. Going on V2 of Foundation for Emails we've taken what we've learned from our own emails and our users' emails to make sure you spend less time testing and more time creating your product.
We're so excited to add even more to the amazing email community and are continuing to build, test, build and test the next version of Foundation for Email. If you'd like to keep up with the development of Foundation for Emails, please sign up below!