Live data from Hacker News

Ask HN: What tools do you use to build HTML emails?

news.ycombinator.com

11–20 of 25 posts

Re: Ask HN: What tools do you use to build HTML emails?

#11
I personally don't use HTML in emails. This is mostly fueled by a combination of my preference to receive text-only emails and my desire to follow the "Golden Rule".

That said, I can see why some folks would want HTML in emails, so it's sometimes worth making exceptions. To address your specific concerns:

> Inconsistency across email clients.

That's going to be a problem no matter what. My recommendation is to keep your HTML simple; the less complicated, the less of a chance for some MUA or other to screw it up.

> Is there a tool to inline CSS styles (since stylesheets are not allowed in gmail)?

Is there something in particular you're trying to achieve?

My approach would be to generate inline-styled HTML with templating (I use Ruby and Elixir mainly at the moment, so my approach would involve ERB or EEx (respectively); I don't know what equivalent(s) C# has). Like the above recommendation, though, keep your styling light; again, the fewer complexities, the fewer chances for the MUA to screw things up.

> Displaying bar graphs. I thinkg my options are either doing this with tables/divs or to generate an image of the graph to avoid inconsistent formatting.

Inline images are almost certainly your best bet here for maximum compatibility.

> The email reports will also be web pages. How do I avoid UI duplication?

By turning the email "reports" into emails with links to the actual (web page) report.

Part of your problem is that you're trying to treat email and web pages as equivalent media, when this isn't the case. Email is very much optimized for simple text-based communication; you should play to that strength instead of trying to mangle it into a role it's really not meant for.

Re: Ask HN: What tools do you use to build HTML emails?

#14
C3.js[0] has a built in image exporter[1] you can use from the command line if you want to generate chart images programatically. I use something similar that I wrote just before this became part of C3 to generate the chart and upload it to S3. Then my email links to that image. Works very nicely!

0: http://c3js.org/

1: https://github.com/masayuki0812/c3/blob/14e92c54f9286bf28ff4...

Re: Ask HN: What tools do you use to build HTML emails?

#15
I had the questionable pleasure of developing our first HTML emails at work this week, and found the following links helpful. I ended up working from the reference provided in the first (A list apart article) link post https://github.com/alistapart/salted .

http://alistapart.com/article/can-email-be-responsive

Which CSS is supported: https://www.campaignmonitor.com/css/

How to serve images: https://sendgrid.com/blog/embedding-images-emails-facts/

General guides and some templates:

https://www.campaignmonitor.com/guides/coding/guidelines/

http://templates.mailchimp.com/

Re: Ask HN: What tools do you use to build HTML emails?

#16
post #9

Email should not contain HTML. Not all mailtools are web browsers.

These customers would be opting-in for the HTML emails. They are not tech-savy customers, they just want the full info delivered to their inbox formatted nicely. I get that some people don't want HTML emails, but that's not what's happening here.

Re: Ask HN: What tools do you use to build HTML emails?

#17

I personally don't use HTML in emails. This is mostly fueled by a combination of my preference to receive text-only emails and my desire to follow the "Golden Rule". That said, I can see why some folks would want HTML in emails, so it's sometimes worth making exceptions. To address your specific concerns: > Inconsistency across email clients. That's going to be a problem no matter what. My recommendation is to keep y…

Good info, thanks.

> By turning the email "reports" into emails with links to the actual (web page) report.

The type of users I'm targeting here would rather have the info delivered to the inbox then follow a link. If you're familiar with Mint, think something like their end-of-week financial summary.

Re: Ask HN: What tools do you use to build HTML emails?

#18
You need to write html like it's 1999. Use tables for layouts, avoid divs. Be very cautious with CSS. See: https://www.campaignmonitor.com/css/

For testing, either use Campaign Monitor for $5/test (across all the clients) -- https://www.campaignmonitor.com/

They repackage Litmus testing which is ~ $80/mo -- https://litmus.com/

To inline CSS there are lots of options, but this is a nice, free utility: http://putsmail.com/

Overall designing HTML emails sucks. It will take 10x more time than you think.

Re: Ask HN: What tools do you use to build HTML emails?

#20
No specific tools, but addressing a few points you and others raise:

Provide a text-only option. It's backwards-compatible, and while the old-timer argument carries weight (console mail client support), many mobile devices offer what's little better than a console-equivalent email experience.

If you generate links, make them short. I'd recommend fewer than 40 characters, fewer than 20 if you can. They travel far better.

Email isn't the Web. Clients differ, and ultimately HTML is not universally supported. You're relying on an opt-in preference, which is to say, you're relying on a self-selected community which will progressively reinforce your initial biases toward content presentation regardless of its validity. Beware that.

My favourite illustration of this is the "Six o'clock on Tuesdays Club meeting time prefernce question". If you ask a group of people in a club meeting at 6:00 pm on Tuesdays what time they prefer to meet -- it will strongly tend to be "6:00 pm on Tuesday", as you've already self-selected for those who prefer and can accomodate that option.

Email clients are inconsistent. Web clients are inconsistent. Fucking text editors are inconsistent (character support, font support, kerning, foreground / background colors, ...). Basically: fucking deal with it.

I'd avoid use of inline CSS entirely -- the less explicit layout you perform the better and more future-proof you are. Limit formatting to bold and italics _only_, and realize that _that_ may not get conveyed reliably. Numeric and bulleted lists should be explicit, not HTML entities. Basically: pre-render absolutely everything if possible. Don't use tables for layout, I'd be leery about them even for tabular data presentation.

Especially: avoid use of contrasting text colors to convey meaning, they're frequently stripped from generated output, e.g., by Mobile email clients.

Graphs: include images. For now, PNG is preferred (best rendering of line graphics), though modestly compressed JPG will occupy less space. Keep an eye on SVG support though. It's an _excellent_ format for rendering data visualization (though you'll absolutely want to down-sample large datasets), and there are libraries which support graphics creation. Client support is still developing, but should be widespread within a few years. All current major desktop clients provide decent support. Legacy browsers and other HTML-enabled tools, not so much.

Email / Web UI duplication: as above for email, that's a fact of life. Fucking deal with it.

Though I generally dislike PDFs, if you're preparing reports to be delivered to users, dropping a PDF or link to same is probably your best bet. Many browsers will now present these natively, many mobile devices (though not all) have some level of PDF support.

If you do this, I strongly recommend:

1. Use generator tools which create the smallest possible PDF possible. Many bloat output to a staggering degree. Bandwidth, mailbox size limitations, and other factors all favor _small_ attachments, still.

2. Landscape layouts. That's generally preferable for desktop viewing. While mobile devices are frequently presented portrait, it's far easier to perform a 90° transform on a Smartphone or tablet than a laptop or desktop monitor.

3. Put the executive summary and highlights in the email itself, detail in the reports.

There are a few alternative forms of delivery you might consider, among them RSS, and ePub or other eBook formats (far more flexible presentation, especialy on mobile). My read is that these aren't universally acceptable, but choosing a tool or tools which supports these and offering the option(s) to users might help clarify your future direction.

Post reply on HN