Live data from Hacker News

Why does email development have to suck? – Explaining all the 's and 's

dodov.dev

91–100 of 183 posts

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#91

Last time I had to deal with emails, I've used https://mjml.io/ and was very happy with it. You can version the templates, compile them as part of your build pipeline and it seems to do produce very _adequate_ HTML full of tables that looks good on all clients that we tested.

How’s responsive design with mjml?

Creating precise multi column responsive designs that work both in outlook and sane email clients is a nightmare.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#92
post #62

Earlier quoted context omitted.

The clients also need to focus on this. Apple Mail on iOS uses plain text variant to show snippets, but if you try to expand the email, it only supports HTML, without a fallback to plain text. This is often the case on slow internet.

That isn’t true: Apple Mail is perfectly capable of showing plain-text-only messages.

The post you're responding to probably meant in the event of alternative HTML+text emails. Obviously if the email is plain text-only it won't invent HTML to show the user...

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#93

Text. Just use damn text. Nobody wants to look at your logo. Why biz people have to ruin everything.

Sticker Mule sends marketing newsletter emails in plain text ONLY. I love it. They’re just:

> Hey ${name},

> Our custom holographic stickers are on for on for ${deal}.

And that’s it. I bet they have awesome deliverability because it’s… just email.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#94
post #52

Earlier quoted context omitted.

There is nothing in the average internal email that requires HTML, much less CSS. There is nothing in the average external email that requires HTML or CSS. There is no useful content in any email that requires JavaScript. "looks unprofessional" is cultural, and of the same significance as green vs blue text bubbles in your SMS messaging system.

This is an absurdly wrong, yet characteristically HN take. Transactional mail typically requires some hyperlink for the average user.

You can certainly put urls into a text/plain email. It helps if your urls aren't terribly long and don't have characters that are questionable in urls.

w3c suggests surrounding them with angle brackets [1], but I can't find a source that makes more than a suggestion. By reports, some mail user agents, and some users will include the trailing > in the url they provide to their web user-agent, so that's something to consider and make sure the destination of the link can handle.

Putting links on a line by themselves works well too.

If you don't know what a user prefers, it makes sense to send a text/plain with links as I've described, as well as a text/html with links in tags, because tagged links may be friendlier to some users and some mail user-agents are tragically bad at their job.

[1] https://www.w3.org/Addressing/URL/5.1_Wrappers.html

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#95

Earlier quoted context omitted.

The data I've seen suggests the opposite?

All of our internal tests have confirmed this, and even the email providers have more or less confirmed the same thing: https://blog.hubspot.com/marketing/plain-text-vs-html-emails...

That's HTML emails _pretending_ to be plain text.

Meaning the 'plain' text is Html-formatted to look plain and there are tracker links and probably tracking pixels too.

Real plain text should be just like something a human being typed.

Also, ignoring the general scamminess of hubspot, the linked article says html mail is MORE likely to be flagged as commercial. The article, in fact, is entirely pro plain text.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#96

Earlier quoted context omitted.

OK. So what, I'm not going to complete my password reset notification because the page isn't beautiful? If you are tracking response rates it is because people aren't expecting an email, because they didn't ask for one (i.e. it isn't a password reset notification). GP is right - I want information I /need/ to be in an email in a succinct format, and I don't want emails I don't need.

1. Yes, normal people who don’t read HN have less trust in a plaintext email. 2. Yes, abandonment will be higher if the user can’t click the password reset link in the email.

> less trust in a plaintext email

What a remarkable idea! "HTML mail = useless bullshit" is such a strong correlation in my mind that it had never occurred to me other people might see it the opposite way.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#97
As an ABAP developer, I thought "that doesn't sound too bad".

I definitely need to get out of there before my brain rots further.

And for anyone curious: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/a... Those are the keywords, about a third of that list is obsolete and you usually need multiple of them to make a valid statement. And that's just the tip of the iceberg.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#98

As an ABAP developer, I thought "that doesn't sound too bad". I definitely need to get out of there before my brain rots further. And for anyone curious: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/a... Those are the keywords, about a third of that list is obsolete and you usually need multiple of them to make a valid statement. And that's just the tip of the iceberg.

Hah, that takes me back!! MY first internship was at SAP and I foolishly didn't even ask which technologies I would work with... ABAP is literally the worst lol. This was 2018 btw

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#99
post #94

Earlier quoted context omitted.

This is an absurdly wrong, yet characteristically HN take. Transactional mail typically requires some hyperlink for the average user.

You can certainly put urls into a text/plain email. It helps if your urls aren't terribly long and don't have characters that are questionable in urls. w3c suggests surrounding them with angle brackets [1], but I can't find a source that makes more than a suggestion. By reports, some mail user agents, and some users will include the trailing > in the url they provide to their web user-agent, so that's something to co…

Yes, you can put them in there, but then you're relying on the recipient's client to turn that plaintext url into a link the recipient can actually click on, as opposed to having to copy and paste the url into their browser address bar.

Right? Or do I have something wrong?

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#100
post #67

Earlier quoted context omitted.

Low response rates are used as a spam signal by major email providers, whatever the type of email.

How does that make any sense when those are often sent from no-reply addresses that are routed nowhere?

I think response rate is meant more generally in this context. It doesn't necessarily literally mean an email in response. I think more typically it means the recipient following the call to action link in the email.
Post reply on HN