A while ago I worked on a library [1] to help send out notifications for a Django site. The notifications could be in various forms, but email was the most common. After a few prototypes, I quickly realized:
1. People don't want to bother proof-reading both the HTML & text version, so if they're kept separate, people will just update the HTML version and the text verison will get stale.
2. People don't want to learn Markdown (or ReST/etc) to render HTML from text.
3. Even if they did, the result quickly becomes strange and difficult to read in-text if you want fancy formatting.
4. On top of that, templating is troublesome for anything not html/text. Escaping requires special support that Django doesn't have.
The only effective solutions I could think of are are a) don't provide a text version b) automatiatically generate the text version from the HTML version. I ended up picking b, and it worked okay, though it's still easy to fool it with bad HTML (like an image with a non-sensical alt value).
Your preference is likely not similar to that of their typical users. At this point, I'd expect many people receiving text only e-mail from a corporate mailing list or something like that to consider it broken and/or suspicious.
I would personally prefer this too, but there's a lot of people who don't, for good reasons and for bad ones.
I strongly prefer the UI on "Hacker News" to what you get on Twitter or new Reddit, but it's also pretty clear to me most other people don't. I think they ought to, but they don't.
Bulk senders overwhelmingly prioritize html email content correctness over plain text correctness. For the past 2 years I’ve been getting monthly emails from a major auto vendor financing company whose plaintext part begins:
Dear < Customer >,
This email is a reminder that your payment of $< Payment Amount >
is due in < Days Prior Reminder to Due Date > day(s).
> When code and comments disagree,
both are probably wrong.
Here it's worse-- there is a single source of truth copy-pasted into two different parts of the message, apparently synchronized by forcing a human to remember to do some work to synchronize the data.
Even worse, the implicit OR in displaying the data essentially guarantees that even someone trying to synchronize the data must go to the trouble of viewing both the HTML and the plain text to make sure it's correct.
And perhaps to a layperson, "plain text" means "I checked a test message in gmail, there were no images in the message, so I guess I just verified the plain text is correct."
This reminds me when I was documenting how an over-engineered UI widget works, and I suddenly noticed there were two member fields far apart from each other in the struct:
> So what do you do when the plain-text and html sections of an email disagree? I have no answer to that, it's entirely up to you to work out which section has the information you need or want.
I guess the best heuristic is probably to let the HTML section take precedence, as a lot of modern clients will display it as the default and it is therefore likely to be the tested/correct one. Text is usually only used as a fallback.
Disagree. There's nothing I hate more than having to downsize my browser window because some minimalist didn't restrict the characters per line in the body text.
Personally, I hate it when people put things in a column, deciding that they know best how I should use up my screen real-estate. I like to have control, and I use it without effort. With this design, I can choose. I like that, and I hate it when someone forces their choices on me.
I admit, though, that there are things I hate more than that.
Out of interest, how would you design a page that caters for both tastes? How would you decide on the number of words that should be in a line? How would you reply to someone who prefers a different answer, but then has no way of changing it?
> I'm not going to stop reading, and I'm probably going to make the occasional contribution.
And looking at the history of submissions for the domain of the OP article we find that he is still commenting too. Most recently about 18 minutes ago in fact. So I think there is a good chance that the author will see the comment of the person you responded to :)
So what do you do when the plain-text and html sections of an email disagree?
Tell the sender. If no one does, they won't know of this problem.
Of course, sometimes it happens that telling the sender is part of a reply to an angry sender who thinks you didn't read the email or read it wrong, in which case they will definitely be listening.
I've tried. Most people are using tools to construct the emails, and some have absolutely no idea that there are text and html components. None. Nada. Zip. They are completely ignorant of these issues.
In part that's because the tools they use deliberately and explicitly hide the details from them.
The same is true of browsers and email clients. The URL bar is disappearing from browsers, and when was the last time you tried an in-line reply to an email using GMail? It's hard. Really hard. The providers of interfaces are working to hide these details from you.
So "Tell the sender" is, in my direct personal experience, pretty pointless. I still try, though:
"God grant me the courage not to give up what I think is right even though I think it's hopeless. -- Chester W. Nimitz"
It’s also very cool when they send html and plain text in the email, but the plain text just says “your email client does not support html, please visit the following link in a browser to read”.
And by very cool I mean annoying and not cool.
And the reason that it’s annoying is because I do have the capability of reading both, it’s just that because I read my mail in mutt I would prefer to read the plain text version instead of the one that has been piped through elinks since in an ideal world the plain text version would be better formatted for that than what I get from elinks.
Unfortunately the world is far from ideal, so you get stuff like this instead. And I’m left with the option of dealing with it in basically one of a few ways
- Configure mutt to prefer html over plain text, meaning a slightly worse experience for mails that are actually better formatted in their plain text originals.
- Keep my current configuration and having to press a few extra buttons every so often in order to see the html attached version instead
- Making a convoluted system that is based either on associating preferred format with the sender address, sender mail server etc. Or one using heuristics to compare the text and html versions and choosing one based on that. Ultimately this either such type of system would be time consuming to make and probably fragile leading to more frustrations.
- Abandoning mutt. Truth be told mutt is not ideal, and at some point I will probably stop using it. But I’ve been using it for years and my setup is at a kind of local optimum, where even though there are frustrations with it it is never any one given point in time where it is worth the effort of making those sorts of changes. Even though in the long run, it would be better.
For a while I was toying with the idea of offering hosted email to others as a paid service. If I had say 25 paying customers that paid a real premium price then I could spend time on the setup and have the time being paid time and making it worth the effort. But truth be told I am fearful of doing this because with the way that email works it will be almost certain that mails of my customers end up wrongly seen as spam by some receiving systems. And I don’t want my paying customers to experience that with a service I provide to them for the kind of price that I would have to charge in order to offer hosted mail service in the first place.
For the record I would charge $100/month. Which for most people is crazy compared to either using a free mail service or paying for example Proton Mail but I believe that there exist 25 people in the world who earn enough and care about the things I care about with regards to email that it would make sense for them to pay this price for it, and because these few people would know that they are paying that price in return for being hosted by someone who only hosts a few people and therefore has time to properly provide in-depth customer service. But like I said because of the likelihood of mails sent by my server ending in spam, it is a no-go IMO.
1. People don't want to bother proof-reading both the HTML & text version, so if they're kept separate, people will just update the HTML version and the text verison will get stale.
2. People don't want to learn Markdown (or ReST/etc) to render HTML from text.
3. Even if they did, the result quickly becomes strange and difficult to read in-text if you want fancy formatting.
4. On top of that, templating is troublesome for anything not html/text. Escaping requires special support that Django doesn't have.
The only effective solutions I could think of are are a) don't provide a text version b) automatiatically generate the text version from the HTML version. I ended up picking b, and it worked okay, though it's still easy to fool it with bad HTML (like an image with a non-sensical alt value).
[1] https://pypi.org/project/django-vox/