Live data from Hacker News

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

dodov.dev

31–40 of 183 posts

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

#31

I don't understand the insistence on building "beautiful" emails. I'm not the kind of person to insist on text-only e-mail, but I do think it's ridiculous to spend lots of time and money making e-mails that look like fully-fledged Web documents. Either your message does have some useful information for the reader, in which case say that and then get out of my way, or it doesn't , in which case you're a spammer. There…

There's no chance a business today can work with plain text documents at scale.

Virtually all email clients support html since a decade and the expectations user have todays have changed.

To put it differently, it looks unprofessional.

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

#32

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

Ironically, plain text emails actually do better for us - the problem is that plaintext emails are often more likely to be caught up by spam filters.

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

#33

How do I make gmail automatically scan every incoming email for "unsubscribe" links and click them?

You can't get the end result by automation alone but you could automate half of it. 1) Use AppScript from google to find those. 2) Save all the links. 3) Go through them manually (because each service will want you to confirm you did not click by mistake).

Virus scanners and other tools like google will fetch any urls in emails to check their target. So having a direct unsubscribe action behind GET of a link breaks your email list as Gmail will unsubscribe everyone

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

#34
post #10

Earlier quoted context omitted.

Perhaps that is your response, but it’s not true of everybody. I’ve done a lot of experiments with different types of email, and beautiful emails always get significantly better response rates.

Ah. I think the difference is that when I send emails, I do so to communicate information, rather than to elicit people to buy a product.

Are you relying on the user's email client to convert plaintext URIs into interactive hyperlinks in transactional mail?

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

#35
post #27
post #16

Earlier quoted context omitted.

I'm pleasantly surprised that amazon actually sends plain text emails. Pretty much every other corporation insists on HTML mails.

I just checked, and they don't. It's certainly plain looking and without fancy styling/formatting, but they do send content-type text/html. The links and tracking pixel images are why they need HTML, I guess.

There's an account setting somewhere to always send plain text emails and do not send HTML. I don't know where the setting is, I enabled it many years ago. Been happy with that.

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

#36
post #10

Earlier quoted context omitted.

Perhaps that is your response, but it’s not true of everybody. I’ve done a lot of experiments with different types of email, and beautiful emails always get significantly better response rates.

So, spam.

Is transactional email spam?

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

#37
post #3

> An email is essentially just an HTML document, like a web page, except it's visualized in an email client, rather than a web browser. However, both are capable of rendering, which is the process of turning HTML code into text, rectangles, and images, i.e. the visualization of the content. No, it is not. An email is a text document. That document might be HTML, but it doesn't have to be. And if such email is sent to…

> The only time I get HTML through email is when it's spam or commercial email, and screw them.

Heaven help any friends/coworkers who tried to send you an email with color, embedded pictures, or bullet point lists.

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

#38

I don't understand the insistence on building "beautiful" emails. I'm not the kind of person to insist on text-only e-mail, but I do think it's ridiculous to spend lots of time and money making e-mails that look like fully-fledged Web documents. Either your message does have some useful information for the reader, in which case say that and then get out of my way, or it doesn't , in which case you're a spammer. There…

There's no chance a business today can work with plain text documents at scale. Virtually all email clients support html since a decade and the expectations user have todays have changed. To put it differently, it looks unprofessional.

[deleted]

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

#39
post #27
post #16

Earlier quoted context omitted.

I'm pleasantly surprised that amazon actually sends plain text emails. Pretty much every other corporation insists on HTML mails.

I just checked, and they don't. It's certainly plain looking and without fancy styling/formatting, but they do send content-type text/html. The links and tracking pixel images are why they need HTML, I guess.

This appears to be untrue. I looked at all the amazon emails in my inbox and they are all:

  Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: quoted-printable

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

#40

While we are at it, what is the most surefire way to include images into email? How do I make sure that simple images, like logos, are shown in most common email clients?

You don't. Common email clients block images by default, because advertisers used them for tracking. Or you make ASCII art of the logo.

Or you include a base64-encoded version of the image. Doing it in-line in HTML should work; I believe tags can also reference an email attachment containing the image (email attachments are base64-encoded anyway...).
Post reply on HN