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

1. HTML Emails in Rails 3
@johnbarton
http://goodfil.ms : http://whoisjohnbarton.com

2. 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.

3. What do I know?

4. Writing HTML emails is painful
Lots of mail clients broken in lots of ways.
CSS support is neither CSS, nor support.
Tables for layout, inline css for colours and shit

5. 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.

6. ...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.

7. What don’t I know?

8. Is there a good way to do this in
Rails 3?
... everything else is shiny and rad so I’d assume so.

9. Surely it’s as simple as:
gem install incredibly_useful_but_confusingly_named_email_thing

10. Let’s Google This Shit

12. Lots of “getting started” guides
Not a lot of “here’s a good way to do the whole thing”

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

14. Step 1: Find a base to work on

15. 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

16. You can use an off the shelf
template
http://themeforest.net/category/marketing/email-templates
or
http://www.campaignmonitor.com/templates/

17. Or use boilerplate
http://htmlemailboilerplate.com/

18. Pro-tip #1: mix haml & erb
Stick 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

19. Step 2: Use sane tool for inlining
your CSS

21. Premailer
Pros: auto generates text part, popular, has “mail” in the name
Cons: Inlines everything, about 6 million forks with different shit

22. Roadie
Pros: Inline some stuff, leaves some alone, can use asset pipeline
Cons: Our build segfaults

23. Slide intentionally
left blank

24. 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

25. Step 3: Keep templates simple
The tables make shit hard enough as is, don’t put any logic in there

26. 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.

29. Protip #4: Use partials as
layouts
Isolate your tables from your content for more smiles and less swears.

31. Step 4: Smooth out your
feedback loop

32. TDD & F5DD
Either works well in Rails for web stuff, but no one has nailed it for email yet

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

35. Do 90% of the work in the
browser
Where you are held in the warm embrace of the web inspector.

36. 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.

37. 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

38. Only move up a layer when
you’ve 100% nailed it
And when you screw up, go back to level one.

39. Step 5: Profit?

40. SIGN UP TO
GOODFILMS