Show HN: Responsive Email Templates
zurb.comAm I the only one who is far less likely to read an HTML email? If I see that I need to click to allow external images for my email to load, I'm probably just going to delete it. It's amazing to me that HTML email can be effective for marketing.
If you send me a paragraph of text, I'm going to read it on my mobile. If you send me an HTML email, I'm going to archive it right away on my mobile. If you send me too many HTML emails, I'm going to eventually be motivated enough to find your 'unsubscribe' button.
I did some A/B testing on this a few years ago and found that HTML email had a better response rate for me. My methodology wasn't perfect, but I shared the results on my blog anyway: http://www.onlineaspect.com/2008/01/25/the-value-of-split-te...
That was 4 years ago. Things change way too fast for your sampling to remain relevant for this long.
It's been what I see in tests too. A well designed HTML mail will generally beat a plain text mail in response rates... including the one we did for $client last week ;)
troll elsewhere
Am I the only one who is far less likely to read an HTML email? If I see that I need to click to allow external images for my email to load, I'm probably just going to delete it. It's amazing to me that HTML email can be effective for marketing.
You're not alone - but you are in a minority (well - apart from here probably ;-). Most people don't really understand that there is even a difference between HTML and plain text mails.
The difference that most people act on is a well designed vs a poorly designed email - whether that be plain text or HTML. A badly designed text mail will lose to a well designed HTML one. A well designed text mail will beat a poorly designed HTML one.
Since you have more design options for HTML you can normally make the HTML mail be the most effective option.
I think it all depends on what type of email you're getting. I send Hacker Newsletter (http://hackernewsletter.com) out every week, and I based on past feedback and some testing, a rather large percentage of my 12k+ subscribers like the HTML version. Why? Well, I include a LOT of links in each issue (one to the article and one to the HN comment for each of the ~35 stories I include), and HTML is way easier to scan in this case.
If however you're getting an transaction type email just to update you on something, then yeah, text might be better.
Not all HTML emails are image heavy monstrosities. There is a lot you can do with HTML/CSS that makes the message easier to consume and more impactual without using a single image.
I feel like HTML email design lags about 5-10 years behind website design. Some of that is the limited feature set, but I think more of it is the lack of design attention its given. It seems like most of it gets generated by a marketing department using some crappy marketing campaign templating software from a decade ago with little to no thought to how the output is consumed.
I disagree with your argument that email lags behind web design due to pack of effort. Have you ever tried to code a HTML email like you would code a website and looked at the result in email clients? Do this once and you'll see what I mean.
Email clients are definitely to blame.
Actually I agree with this, perhaps we're just debating cause and effect. Developers in my experience do hate putting together html email due to the wonky client constraints and as a result often say to marketing "its a mess, I don't want to touch it, find a e-mail making program / service to do it".
But is that the cause or the effect?
Rather, are email clients still a mess because developers don't have much interest in topic? Even gmail has strange html/css rules, if google pulled that with chrome there would be pages of developer outrage here on HN, almost no one seems to care about gmail's html rendering, or enforcing a spec/compliance for email clients, developers are apathetic about it.
What I'm saying is, developers don't like working with html email because its a mess, but its a mess because the development community as a collective doesn't seem to care about it, at least not enough that there is a concerted effort to fix it.
"almost no one seems to care about gmail's html rendering"
Addressing that specifically, a couple years ago when Gmail's HTML rendering was even worse than it is now, the Email Standards Project started this http://www.email-standards.org/blog/entry/getting-some-gmail... to try to embarrass Google into improving the rendering. It sorta worked.
And why is it generated by the marketing department's crappy software and not the engineering department? Because no-one in the engineering department wants to program like it's 1999!
I work for a large company, we send millions of emails a month (completely opt-in) and I can say without any shadow of a doubt, html emails get more reads and convert better than plain text emails.
I've done email marketing for some pretty big companies over the last 3-4 years, as well as a few smaller ventures. When it comes to generating revenue, HTML wins across the board in my experience with general goods' EC, daily deal, education and food.
The users of this board aren't exactly the type of people who impulse buy.
I'm exactly the same way unless it's an email I am interested in or if it's from a sender I care to hear from. However, if it's an html email from a sender I care to hear from, but I open it and I have to scroll sideways just to see parts of the image... I will delete it immediately, and won't download images from that sender in the future...
Responsive emails probably won't help with emails you don't care about...But, emails you are interested in, it can make all the difference.
I prefer HTML emails in many cases. However, most aren't responsive and for the longest time Gmail for Android hasn't supported pinch-to-zoom (I think it does in 4.2).
Doesn't seem to in 4.2 either...
A well designed email should be multi-part and contain a text/plain part so anyone who views their mail text-only can ignore the text/html part.
e.g. http://www.enewsletterpro.com/articles/multi_part_mime_messa...
When I see an email that's just a bunch of unloaded images, I immediately weigh the benefit of loading the images (so I can see it the way the sender intended me to see it) versus the cost (loading images = telling the sender, “I just opened your email!”). The former often loses.
Downloading images is the default on iOS devices. I suspect that has contributed to their success.
If you're designing email HTML from scratch, Campaign Monitor's guide to CSS is incredibly helpful for knowing what to use and what to avoid.
http://www.campaignmonitor.com/css/
I've also found Litmus to be an incredible resource for cross-client test (Outlook vs Gmail vs Yahoo! vs ....). If you send a lot of emails as a part of your user retention strateg it's vital that you test this. You'll be amazed at how different they look and how a few hours of tweaking can optimize things across a large number of clients.
Also useful, automatic CSS inlining: http://premailer.dialect.ca/ & https://github.com/alexdunae/premailer/
I'll second Litmus. It's one of the few tools that I've really felt were worth paying for. It's just tons better than try to test emails ad-hoc.
If you are sending emails to business clients support for Outlook 2000-2003 & Outlook 2007 is still essential. I'm afraid you need to code them like it's 1999. MailChimp have a guide on how to do it right: http://mailchimp.com/resources/guides/email-jitsu/
Fortunately a <table> is (and always has been) responsive.
For non-business clients (who would be unlikely to use Outlook at all) these look great.
100% agree. Outlook doesn't support responsive CSS... but doesn't it support conditional comments? I think Zurb might be missing an opportunity here.
Outlook is the IE6 of the email design world.
I'd actually say it's more like the IE5 for Mac of the email world.
From the accompanying blog post: "Here at ZURB, we believe that everything we do has to consider the mobile experience."
You might want to consider making the project page responsive.
Also, the tweet box is way off to the side, I had to resize my window to fully see it.
http://www.zurb.com/playground serves a separate mobile optimized page, but the link to the responsive email templates points to http://www.zurb.com/responsive-email-templates, which doesn't exist.
I am new to having HTML email sent.
What do folks do with the large (large in this case anyway) stylesheet, that actually works with actual email clients?
Link it with a <link> tag? Plop it all into a <style> tag? (where?) Something else?
What are current best practices for sending html email that needs a non-trivial stylesheet like this? Googling around, i'm still left not sure; many pages I find make recommendations that would make using these templates tricky (although some of them are a couple years old or more).
Here are some resources I have found useful regarding email newsletters. Some of these seem to have some nice advice about how to test, how to aid user interaction too:
- http://www.htmlemailgallery.com/
- http://www.campaignmonitor.com/blog/tips-resources
- http://www.campaignmonitor.com/css/
- http://www.emailonacid.com/blog
Basically, avoid floats, use tables, use inline styles.
Also, on OS X, if you can save the source of email newsletters sent to you as an html file (Cmd-Opt-U -- select the html portion), edit it to your liking, open it in Safari, then Cmd-I Cmd-Shift-T (Format - Make Rich Text if plain text is default) to send it as an unmodified HTML email from Mail app.
> Basically, avoid floats, use tables, use inline styles.
Yeah, that's what I was finding too -- and that advice is pretty much incompatible with the "responsive email templates" offered in the OP, no? That's what I'm wondering about.
Use the CSS Inliner Tool:
http://beaker.mailchimp.com/inline-css
Also, read MailChimp's study on responsive emails:
http://mailchimp.com/resources/guides/html/email-on-mobile-d...
To add to Sam's comment, if you're using Rails, try:
https://github.com/fphilipe/premailer-rails3
There are a few gotcha's with the gem but overall it works pretty smoothly!
When developing a HTML email it's best to have style tags at the top and not link to them using <link rel> because the way HTML email works and various clients, you have to bring the CSS inline for it to work properly across different email clients anyway.
It's a trial and error process. Build HTML emails using tables for as much as possible, you can't use background images just background colours, don't rely on floats or other common CSS properties (even using height or width in your CSS isn't as supported as well as you'd think) and the number one thing to remember is: the day a client complains it doesn't look good in Lotus Notes, you will want to throw your computer out the window and become a farmer because it's never going to work in Lotus Notes.
Always make sure your images are set to display block to fix issues with various email services like Windows Mail and Yahoo! Mail. If you need to set them side-by-side, add in another td inside of your table row.
Always make sure you write alternative text for images. Most email clients are set to not to display images in emails unless told otherwise. Another convenient feature not many know about is that you can style the alt text that shows. <img src="ourlogo.png" alt="Acme Company" style="color:#000;font-size:20px;" /> — doing this ensures even if someone without images still sees something that doesn't look like hideous empty squares.
With later versions of Outlook, Microsoft also stripped back support for various CSS attributes and HTML tags compared to previous version so you'll find you will encounter a lot of frustration with that as well.
Linking it may work in some clients, the style tag works in more, but if you want your css to show up in most clients (like outlook), inline it.
So if you had `p { color: red; }` in your style sheet, then all your `p` tags should read: `<p style="color: red;">`. It sounds horrid, and it is, but you can automate the process with a preprocessor.
When it comes to email, you unfortunately need to throw out the last 10 years of advances.
I work with HTML emails all day long and it's awful. The short answer is this: remember, it's an email, not a full blown website. You should not have as much CSS as you're describing in your emails to begin with. The more CSS the more chances there are for it to break. Images and tables are the way to go and you'd be surprised at how creative you can get under those constraints and how beautiful the result can be.
Most web based email clients will rip out your <head> so link tags aren't a good idea. You'll need to inline 90%+ of your CSS. I usually create the table layout then add the inline style later. You can use the Mailchimp CSS inliner tool for quicker results.
I usually inline it all and leave some bits in a style tag. That's really the best you can do because of the crazy inconsistencies between email clients. Email clients render HTML and CSS like it's the 90's. Check out Campaign Monitor's blog. They have a big chart that shows you what HTML/CSS is compatible in each client. It's a life saver. I have it posted in my cube and I use it every day.
So, as someone who works with HTML emails all day long, do you have an evaluation of the "responsive email templates" in the OP?
They seem to conflict with much of your advice to me. That's what I'm wondering about.
HTML emails in general are full of contradictions. I plan to use the templates myself and I'm really excited about them. To answer your question though, it's just important to realize that much of these techniques won't work in the majority of email clients. iOS and some Android built-in email clients are the ones that this will be great for. But at the same time you still have to inline the vast majority of your CSS to get a consistent result in webmail clients.
In the end you have to know your audience. At my job, we have a lot of corporate types who are checking their emails in Outlook and also webmail so the emails I create have only two style rules in the head of the document with the rest inlined. Email is just really fragile and I personally believe you have to resign yourself to the fact that your email will break for some of your readers. When I create a website I expect it to work beautifully for over 95% of people. With email, I expect it to work 3/4 of the time. Maybe more if I'm lucky. That of course depends on the complexity of the email's design of course.
I've never come across a website that I felt needed a responsive layout, though I regularly think emails are a pain to read on a phone if they use html.
However, most html emails are marketing emails, so I'm still not sold of the idea of responsive templates. The emails I really care about are plaintext (the best type of responsive design---so simple!)
Here's their technical writeup on the process, http://www.zurb.com/article/1119/create-emails-for-any-devic...
Curious, they use the <table> element to get around the lack of media queries!
And what about real e-mail, e.g. text-based? An e-mail is not a webpage, for me it’s nonsense to put HTML in it.
If you receive a book from Amazon via snail mail, do you expect the entire book to be in Courier 10pt with no use of images, color, or other fonts, even for the cover? Do you expect ASCII illustrations in the book? Why would you expect something different for email then?
You could set 2 versions: text and html. Email clients that do not support html will fallback to displaying text.
As a web developer who does at the very least one HTML newsletter per month for a client, this is a breath of fresh air. Developing a HTML email is like developing a website in 1995. No Javascript, flaky support for most CSS attributes, the fact you have to use tables for layout, the fact you have to use a premailing tool to bring all CSS inline to work correctly (especially for clients using Lotus Notes 6...) they're a pain in the ass.
I will definitely considering integrating these into my workflow.
I find it very nostalgic since 1995 was around the time I started making websites. Now, email templates are the only place I get to show off my mad table-making skills. No one else seems to appreciate them.
If you spend time in direct response circles, the matra is A.B.T. - always be testing.
An addendum to that might read "ABV" - always be valuing (visitor value, that is).
I've personally tested both. It really depends on how html vs. text affects: a) your open rates b) your clickthrough rates c) your sales conversion rates d) your long term lifetime value and visitor value.
It's very dangerous to make decisions about "html vs. text" based upon one's own personal preference - or even HN readers (unless that's your target audience).
What do you know about your audience? That's what I always say when chatting with friends and colleagues.
As an example, are the majority of your users using gmail, hotmail, yahoo, aol? Or, are they using personal and/or academic addresses?
These different mailing providers treat html vs text quite differently.
The style of your email can affect whether or not you get inboxed (hence every action step from open rates, to ctr rates to sales will be affected).
What's the demo of your audience? If one has an older crowd, perhaps plain text may be easier to read.
A younger crowd? Perhaps xyz percentage more of them are reading via mobile devices. This would also affect the decision.
The Email Experience Council at the DMA has some great research on this topic - check their Youtube channel.
But above all I'm a big fan of making data-driven decisions based on a clear awareness of what your audience's behavior suggests - not on personal preferences or HN likes - IHMO.
Also HTML may be more appealing but text may drive more goal conversions.
Has anyone else seen better overall ROI with text, even though they personally have more of a preference for HTML?
added: http://www.emailexperience.org/ http://www.youtube.com/user/EmailExperience
I just don't see the point in responsive emails at the moment, all of our smart phones have the technology to support big beautiful newsletters that you can get on desktop/web email clients.
If I receive a 600px wide email on my iPhone I can zoom and pan around it. I feel the same way about websites, I don't want my mobile browser to redirect me to a crippled mobile website with half the content. Especially when I have a browser designed to view desktop websites on a smaller screen.
I think we should wait and see if responsive emails are just a fad or is going to become the mainstream.
That being said, this is a fantastic tool for creating responsive emails.
Shameless plug: I made https://www.mailrox.com/
It's easier to just scroll rather than pan and zoom.
Which emails clients have you had these tested in?
We just updated the post with a list of email clients we tested! http://zurb.com/article/1119/create-emails-for-any-device-in...
I have developed a number of HTML newsletter templates over the years and when I checked their Supported Email Clients table I found that they claim to have not tested these against Outlook 2007.
Personally, I bet they DID test them against Outlook 2007 and when they saw the amount of work that would be involved in making them render at least somewhat correctly they held a staff meeting and decided it would be more effective to just put a big red "X" in that column and I don't blame them for it one bit.
Agreed, the use of the word "untested" is a little off-putting. Just call it "unsupported".
These are great, thanks for sharing!
It'd be fantastic to get something like this for app-based communications (sign-up, notifications, PW change, etc), and there may be just as much of a reach as with campaign marketers.
Tons of people try to build responsive/multi-platform apps these days, but responsiveness in the communication to their users is a gaping hole. Every app we build, I feel like we start from scratch in putting together notification/communication emails (outside of campaigns).
These are awesome, but how is the backwards compatibility? I know I've seen coworkers having to deal with old versions of Outlook and Mail.app using terribly outdated rendering engines, not to mention strange-ass quirks that are even harder to test for than browsers. Web based clients are their own mess. Some escape certain things, some don't.
The final conclusion was to stick to table layouts for a few more years. Has this changed?
According to campaign monitor(http://www.campaignmonitor.com/resources/will-it-work/email-...), that is 15% not tested 'so far'(support dropped?) Is it worth it? Nonetheless it does look very interesting. Would be much more convincing if the preview can be sent to an email address though.
I currently use a modified version of https://github.com/philwareham/responsive-email as the template for http://coderweekly.com, but may move to these.
As you can see, I'm already using Foundation on the main website. I've found it excellent.
Little ironic that the project's page isn't responsive, especially considering their Foundation framework is a fantastic tool for such tasks (I like it more than bootstrap). Anyway, it looks great, and thank you Zurb for making such great tools for all of us to use!
Looks nice, but the page (or blog post) really needs to list which email clients are supported.
We just updated the post with a QA chart of the email clients we tested on! http://zurb.com/article/1119/create-emails-for-any-device-in...
Perfect, thanks!
I like Zurb. I like using Foundation. I dislike this. If I'm reading an email I want text.
Perhaps on your homepage you can have an option like "email me a demo now".
Looking in the browser doesnt actually help me test the 'email responsiveness'.
I'd like an example emailed to me, so I can test on my iPhone, my computer, my ipad etc.
Is there anywhere else that I can send HTML emails from? It sounds very limited and difficult to do, based on your description on your site!
At PostageApp.com we focus on transactional emails, which these days are moving heavily towards HTML email as a standard now that deliverability is much more focused on IP reputation than content.
We provide a templating system which allows you to build and preview with separate HTML and CSS, and we compile to inline CSS at runtime to ensure compatibility with the majority of email clients.
The painful thing to remember is that html/css for email is a weird mix of HTML3 and HTML5 - meaning some major providers only allow for basic functionality, but other platforms support the bleeding edge while omitting some of the simpler aspects. In the end your demographics will strongly influence where you focus your efforts.
The templates from Zurb here are a great basis - as a start on a responsive email boilerplate this will be great value to the community - individuals using this for customization will hopefully push the development of these bases further.
I highly recommend MailChimp. I use them for my newsletter and the fact you can start using them for free with up to 2000 subscribers is very nice.
I'm curious more along the lines of personalized emails to users of a service. As far as I know, MailChimp is more about blasting one message to lots of people. Unless I'm mistaken :)
Oh, okay. In that case you want to look at transactional email services. MailChimp offers that as well with https://mandrill.com, but there are a ton of other offerings as well like http://sendgrid.com.
That mandrill site is slick! Thanks for the links
So how does these look on Outlook 2000 - 2007? Love the initiative but it's impossible to use a template that doesn't work with Outlook.
These look really nice! Thanks :) Would you consider putting them on GitHub? It would be much easier to keep track of them this way.
Props to the zurb team for referencing Asimov. (Elijah Bailey was the detective protagonist in the fantastic early Robot series.)
Thanks! We're very big fans of Asimov's work. We reference it all the time, especially Foundation. :)
Also the Foundation Series (Hari Seldon).
Hard to read. Sorry. Chrome 18 android gnexua.
This came at a perfect time for me as I've spent the last week working on designing newsletter templates.
I'm pretty glad I saw this on the day that I learn I'm undertaking the project of implementing an email newsletter system :)
Obviously most of the clients that don't support this are built by Microsoft. Nice job, btw.
<!-- If you delete this meta tag, Half Life 3 will never be released. -->
HTML email is wrong. Period.
go Zurb! I use Foundation http://foundation.zurb.com/, playground's joyride and icon fonts, I hope these email templates are as good :)
Thanks for the kudos! Our team has been hard at work on these, and are so excited to share them with the community. :)
keep up the good work. btw you forgot to tweet it on @foundationzurb, only on @zurb.
Done as well! Thanks for the heads-up.
I will use them as minimalist/simple website templates lol :)
commenting here so i can find this later.
If you upvote the story it will be bookedmarked in your profile automatically.
In theory. Not always in practice.
what do you mean? it's all in 'saved'.
btw try https://bitbucket.org/zalew/hackernews if you want to crawl it to save elsewhere.
If you click on your own name and then click on "saved stories", in theory it shows you stories you upvoted. Mine is currently blank: http://news.ycombinator.com/saved?id=Mz I have seen others report problems as well. So I don't rely on that supposed feature.
I noticed today that my submitted stories page shows upvote arrows for my older submissions (as if I hadn't upvoted/submitted them). Only the 20 first ones have the red asterisk. And my saved stories page does not show old stories.
So it's not just me. Just to make sure, you know that link only works for yourself, each user can only see his own saved stories page.
Thanks.
I wish HN supported saving other stories too (links submitted by other users) instead of saving just your own upvoted links.
Well, keep praying. Perhaps you will get a christmas miracle. (Though I wouldn't recommend holding your breathe.)