HTML Emails in Rails 3

Post on 08-May-2015

1.906 views 2 download

description

A talk on sane html email development in rails that I prepared for Melbourne Ruby Group... but never actually presented.

Transcript of HTML Emails in Rails 3

HTML Emails in Rails 3

@johnbartonhttp://goodfil.ms : http://whoisjohnbarton.com

What do I want to do?

Design, and implement, and deploy a good looking HTML email that works across all common desktop, web, and mobile clients with a fall back to text.

What do I know?

Writing HTML emails is painfulLots of mail clients broken in lots of ways. CSS support is neither CSS, nor support.

Tables for layout, inline css for colours and shit

Testing HTML emails is painful

I literally have to send emails to a whole bunch of clients and look at them and if I got a single bloody thing wrong do the whole thing over from scratch.

...and it got even more painful

iPhones, iPad, and Android mail clients are popular now.They are still broken AND have tiny screens.

...and I don’t even own an iPhone.

What don’t I know?

Is there a good way to do this in Rails 3?

... everything else is shiny and rad so I’d assume so.

Surely it’s as simple as:

gem install incredibly_useful_but_confusingly_named_email_thing

Let’s Google This Shit

Lots of “getting started” guides

Not a lot of “here’s a good way to do the whole thing”

So over two weeks of TRY ALL THE THINGS I’ve settled on a decent toolchain and process.

YMMV.

Step 1: Find a base to work on

This is important

A lot of people have put in a lot of effort working out the “generic” kinks in all the different email clients and there is NO NEED for you to replicate the effort

You can use an off the shelf template

http://themeforest.net/category/marketing/email-templatesor

http://www.campaignmonitor.com/templates/

Or use boilerplate

http://htmlemailboilerplate.com/

Pro-tip #1: mix haml & erbStick with ERB for your outermost layout, as it’s the smaller diff from your

boilerplate, and you’ll want to update that as the boilerplate evolves.

Use haml for everything inside there as it makes all the nested tables easier to manage

Step 2: Use sane tool for inlining your CSS

Premailer

Pros: auto generates text part, popular, has “mail” in the nameCons: Inlines everything, about 6 million forks with different shit

Roadie

Pros: Inline some stuff, leaves some alone, can use asset pipelineCons: Our build segfaults

Slide intentionallyleft blank

Protip #2: Take advantage of the asset pipeline

You often have to “pointlessly” repeat style info on different elements, SASS with mixins makes that not eye bleedingly painful

Step 3: Keep templates simple

The tables make shit hard enough as is, don’t put any logic in there

Protip #3: Use Presenters

Push logic in there, it’s easy to test. Push copy in there, makes keeping HTML + Text parts in sync easier.

Protip #4: Use partials as layouts

Isolate your tables from your content for more smiles and less swears.

Step 4: Smooth out your feedback loop

TDD & F5DD

Either works well in Rails for web stuff, but no one has nailed it for email yet

This is the tricky bit.You want to work in layers.

Do 90% of the work in the browser

Where you are held in the warm embrace of the web inspector.

Then email to yourself

This catches a bunch of “I have a fundamentally wrong assumption about something that works in the browser will work in at least 1 mail client”

You will have lots of those.

Then use one of the “magic” testing apps

I use http://litmus.com, but http://emailonacid.com looks good too and has a name that suggests what happened on the Office 2007 team

Only move up a layer when you’ve 100% nailed it

And when you screw up, go back to level one.

Step 5: Profit?

SIGN UP TO GOODFILMS