Hacker News new | past | comments | ask | show | jobs | submit login
Transactional HTML Email Templates (mailgun.com)
271 points by twakefield on Aug 13, 2014 | hide | past | favorite | 32 comments

These are incredible. Thanks.

Elaboration: You can buy email templates on ThemeForest for ~$2 and they'll be prettier but it is very, very rare that they are actually as thoroughly tested as these are. Source: The guy who deals with bug reports like "It's unreadable on [insert a device that neither the designer nor the email sender owned]" way more often than he'd like to.

Fun story, which I'm telling you because it is a fun story and not because I want to scare you off using Themeforest designs: I once bought, and promptly shipped, a transactional email template. It happened to include a reproducible remote crash against at least three major versions of Outlook. (After finding this out the hard way, I reported it to Microsoft's security, which looked into it for a few months before deciding "That sucks but it doesn't look like remote code execution is actually exploitable so phew dodged a bullet there, didn't we.")

> "You can buy email templates on ThemeForest for ~$2 and they'll be prettier but it is very, very rare that they are actually as thoroughly tested as these are."

This is an amazing resource, but I don't want you to over generalize the templates at Themeforest. All the templates on that site clearly say what they have been tested in, and what clients they work in. (screenshot of the product detail sidebar: http://bluetide.pro/BU4q/1KDfhjBF). I've never ever found that info to be wrong when it says they work in the said applications. I think Themeforest does a great job with their vetting process to make sure the templates on the site are almost 100% accurate in the info.

(It may be worth reporting to Themeforest that wasn't the case on a template if you have been burned before.)

One thing that it's missing is which version of (e.g.) Outlook it's been tested in.

Hey there, Patrick! I work at ThemeForest/Envato and I'm happy to look into the issues here. Could you email me the link to the item in question? sid at envato dot com. Thanks!

These are great, and really simple to use. Already adapted for my latest project!

Also, if you didn't catch it in there: the [premailer][1] library is awesome, and helps make email templates more manageable (use CSS/LESS/SCSS styles like normal, then run your HTML email through premailer before shipping and it'll inline everything for you). I use the Python library with Django to preflight emails before sending. Works like a charm!

[1]: https://github.com/peterbe/premailer/tree/master

Also available in Ruby, Node, and PHP flavors

The original post and your comment both make it sounds like the various premailer libraries all share a common core, but I don't think that is true. Does the python premailer have anything to do with premailer.dialect.ca? I don't think it does.

Several months ago, when I was using Zurb Ink to design some emails, the python premailer would choke on some of the responsive CSS. I had to switch to the ruby premailer gem to get things to work. It looks like the python premailer has since been updated, so perhaps it works now.

Why is it better to use inline CSS here? Isn't inline CSS usually frowned-upon?

Email clients strip external css and often the style tag. Therefore you have to use inline css to style html emails.

> Isn't inline CSS usually frowned-upon?

Yes, but not in the 1990s, which is the era HTML email finds itself stuck in.

Most browser-based email clients (Gmail, Yahoo, etc.) strip out the head and body tags from HTML emails. You never really know what's going to be removed, so the safest thing is to inline all of your styles.

Yes. But generally when things are frowned-upon, it's because they have something going for them. (If everyone agrees that something is dumb, there's no point in belaboring it.) Inlining is the simplest and most fool-proof way to apply CSS, which helps explain why it works in email where all else fails.

Premailer is amazing. Saves me a huge amount of trouble regularly. For one thing you can just remove the external stylesheet reference to see how it degrades instead of s/style=/ignorestyle=/g or similar.

One of the core features of Sendwithus that we DON'T talk about is the fact that we inline css for you at send time.

Such a pain to build out a inlining and testing workflow for content that should be in some kind of cms.

Directly on the heels of "Open Source Email Templates (sendwithus.com)" https://news.ycombinator.com/item?id=8154646

Gotta love competition.

Seems more like complimentary rather than competition. We don't really have a dog in the fight as to which templates our customers use. Just trying to be helpful. Maybe we should do a pull request to get these templates on the sendwithus repo.

Absolutely, happy to join forces :) More excellent templates for everyone!

I love seeing essentially two competitors come together to deliver quality to their customers and not try to dog at each other.

SendWithUs (transactional email GUI for marketers) integrates with Mailgun (email delivery API) and are not competitive by and large.

That was just a few days ago posted on here. I don't imagine they threw all of this together that fast, probably have been working on it for a long time and knew people might say that the longer they waited to release.

I also wouldn't consider open source projects as competition, there is room for everyone to work together for a common goal and they compliment each other. Some like Bootstrap and some like Foundation. Some like Rails (Ruby) and some like Laravel (PHP). Overall it's better to have more resources than less or even none. Props to all.

For those who don't know, MailChimp also has a set of email templates available. https://github.com/mailchimp/Email-Blueprints

I just finished an app that uses the template system from mailchimp's email templates. Now there are other formats, with great quality templates, 3 and counting... Oh well.

Please don't forget to include text/plain multipart/alternative while you are at it.

These are great. I've been thinking a lot lately about HTML email vs Text. I used to snicker at people who wanted plaintext, thinking them luddites. But I've had some experience on the other side of this lately with our SaaS startup, Cronitor. I've learned that a plainly worded and concise plaintext email can be a very powerful tool.

For those of you, like me wondering what a transactional email is: http://blog.mailchimp.com/what-is-transactional-email/

    > So what is transactional email? Coming from a MailChimp 
    > state of mind, you might simply think of it as "anything 
    > that isn’t bulk". Basically, it is email sent to an
    > individual based on some action. It could be:
    >   * an action they took directly
    >   * an action they were the target of or,
    >   * perhaps even inaction on their part

For those that need more complex designs, there's also responsive email templates from Zurb[0].

[0] http://zurb.com/playground/responsive-email-templates

Here's an alternative[0] from Sendwithus worth checking out.

[0] https://github.com/sendwithus/templates

This is really awesome. Just needed this. 3 years ago. Sometimes I really think why things are so obvious but takes so long before someone realises and take action.

Thanks a lot for the resource!

These are really great.

If anyone is interested in collaborating, I'm thinking about converting these (and the SendWithUs ones) into ActionMailer layouts and views for use in Rails apps.

The MIT license worries me. Does that mean, if I use it, I have to embed the license somewhere in every email, as that's how the MIT license reads to me.

No, the MIT license is not viral, and even if it was, emails created from an MIT-licensed thing would be no less "derivative" than documents typed inside OpenOffice.

Thanks Mailgun! These are really awesome.

A side note: I really love Mailgun as a service :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact