Simplified HTML emails

Feature
1

A common complaint I’ve heard about Discourse within Mozilla is the HTML emails.

I had always somewhat dismissed this complaint as coming from an irrational fear of HTML in emails (if it doesn’t belong in emails, does it really belong in phone operating systems?) and, after all, Discourse sends multi-part emails so you can just opt to read the plaintext part. Right?

That’s been the proposed solution in topics here, of varying levels of amusement.

I now realise I was a bit quick to dismiss this complaint. The issue isn’t so much an inherent dislike of HTML in emails, but rather its overuse. Users want the simplicity of plaintext, but to keep inline links and bullet points.

Hence this proposal for simplified HTML emails, behind a global pref, because I completely recognise this is a pretty specific problem to Mozilla and other communities wanting to use Discourse as a mailing list replacement.

By far the biggest simplification which can be made is by not using tables. They may make layout easier, but make responding inline really rather awkward:

Removing the header would also simplify things, since the most necessary information will already be displayed by any decent email client:

And the footer shouldn’t put so much emphasis on visiting the topic to respond:

When serving as a mailing list replacement, the primary method of responding should be by replying to the email. I’m envisioning a footer a lot more like how Google Groups does it:

Screenshot from 2017-05-12 17-09-54.png764×135 26.4 KB

Indeed, Google Groups doesn’t even tell you you can respond by replying because, well, it’s email! What else would you do?

I would see an ideal simplified footer being something like:

You received this message because you are watching the Mozilla Discourse “Participation Systems” category.
To unsubscribe from these emails, click here.
Reply to this email to respond, or visit the topic.
To post to this category, send email to parsys@mozilla.discourse.

TL;DR

  • No tables
  • No header
  • Google Groups-esque footer

This is something we’re willing to put development resources into, but want to get feedback from other mailing list communities on, and co-ordinate with you upstream.

9 Likes
2

Responding inline is quite evil and should be avoided regardless…

1 Like
3

Definitely not a fan of inline replies in emails (no email client seems to treat that the same way) but I’m certainly in favor of this for all the other reasons mentioned. The simpler our email HTML is the better. Newer apps like Google Inbox treat our emails quite oddly sometimes (this is probably something I should be reporting on more)

1 Like
4

You have to realize, though, that many email clients have what can charitably be called “nightmarish” support for HTML. MS Outlook is one of the worst offenders and actually went backwards in HTML support in latest releases.

That is, for email you are often better off pretending it is 1999 and no HTML features after that point were ever invented or even used, including a lot of CSS…

so, about that…

This is an extremely high risk, low reward change.

3 Likes
5

I’m not sure I understand how this is an argument against the proposed changes. I am one of those Outlook users routinely annoyed by its bad HTML support and discourse mails are among the worst in Outlook, especially the summary emails. So my thought while reading this thread was that things might improve with simplifier HTML. But maybe I’m just not grasping the proposed change?

6

I’m a bit of a fan, which I think shows itself by how much I quote on Discourse :wink:

But joking aside, it’s always been a common and popular practice within Mozilla, and is far easier to do with Mailman or Google Groups (because they don’t wrap content in a table).

Right, but this is exactly what I’m wanting to achieve with simplified HTML. Not to replace tables with flexboxes, but rather good ol’ fashioned <br>'s.

Once you’ve removed the header, is there any risk at all here? This is the table as it currently stands:

So without the header we have a table of one column and one row. That seems like rather an unnecessary table to me.

Summary emails are one of the places I wouldn’t support removing tables. I’m only proposing we remove them because they break responding inline, and where they break responding inline, and the summary email isn’t a respondable-to email. In fact, I’m not sure the layout of the summary email would be possible without the use of tables.

4 Likes
7

Maybe, if you can prove it by running it through https://litmus.com for the top 10 email clients, then I’ll believe you!

3 Likes
8

10? How about 24?

lol.png1816×1932 677 KB

Looks pretty good to me :wink:

9

That’s just a blockquote; where is the table bit at the top with the author info?

10

Maybe I wasn’t clear enough: by header I meant that table bit at the top with the author info.

Enough author info already appears in the From and Date email headers to make this header unnecessary, when trying to create a mailing list style experience.

This is why I thought you were joking…

I think this also bears repeating, and emphasising:

If anything here can be more generally applied, that’s great, but the primary goal of the proposal isn’t to change default behaviour, but rather add an option for simpler, more mailing list-esque, emails out.

2 Likes
11

Strongly disagree, username, full name, avatar and title would all be missing.

I suggest you try rebuilding that without tables, as you proposed.

1 Like
12

It strikes me that you could start with Step Zero:

image.png927×215 14.9 KB

Make just the header a table, the part in the top <tr> row pictured ↓

image.png1418×294 55.3 KB

… and move the rest of the email, the bottom <tr> row ↑ , outside that table.

4 Likes
13

That’s sort-of the point, though. Putting all that metadata at the top of the email clutters it up, and I’m aiming for simplicity here.

GitHub does this, dropping its avatar, username and title:

Screenshot from 2017-05-16 01-31-43.png1471×298 53.4 KB

14

Not the same, github does not have title or full name, plus it lacks optional group overlays on avatars too.

15

I think there is a huge divide here, which is why you are having trouble parsing this:

On one side of the :mountain: you have users who use “email” as a “trigger” to get them to visit forums.

On the other side you have users who want to do the majority of interaction via email, they do not care that a forum exist, all the want is MAILMAN foreva ™

For the mailman users:

  • They do not care about titles and avatars, email is enough, when they see all this duplication they have an internal fit.

image.png699×116 9.25 KB

  • They also do not care about all the emphasis to visit the site, large footers and big blue buttons turn them off.

  • They hate the way titles are full of [XXXX] [YYYY] before they see actual title.

I do not see us being able to make both “groups” of users happy out of the box that easily.

What I would prefer to see done here is to provide the extensibility to override these templates.

Where I would recommend starting is with a plugin that allows users to select an email template as “minimal” or something along those lines. Then @LeoMcA can have all the Mailman ninjas :necktie: simply select a different “minimal” template.

I think it is incorrect to look for a solutions that works for two groups that have almost nothing in common. We will just end up making everyone unhappy.

15 Likes
16

This sums it up nicely. Here on meta, we’ve been through this conversation several times already through the years, and I’ve resigned myself to look to the future and think of discourse more as a self-hosted facebook equivalent than an upgrade to mailman or google groups.

Here are two readily available examples:

17

Right, this was what I was trying to get at by proposing putting this behind a global pref, thanks for putting it more clearly.

I hadn’t considered that even within Mozilla there may be people who want to use email as a “trigger”, rather than for interaction - so a user preference makes more sense. We’d probably be wanting to set it to “MAILMAN foreva ™” mode by default, though :wink:

This is required, I can’t see a way of managing to change the template used from a plugin without doing something horrific like monkey patching ActionView::Helpers::RenderingHelper#render.

And I think it makes sense to place these custom templates in a plugin - it allows individual Discourse instances to use whatever custom templates they want.

But I’m not sure between those two points what should be in core, and what should live in a plugin. Would you see this extensibility in core take care of the user preferences side of things, simply enabling a plugin to specify a template and name?

Or would you see the piece in core being more general, allowing any plugin to override any template, with this specific plugin hooking into that and handling the user preferences side? How would we decide, in core, which plugin gets the final say on what template gets rendered?

18

Yes this is my preference.

I think that is imagining a problem that will, in practice, never exist

1 Like
19

I disagree; I think the HTML email was in a giant table for … zero good reasons.

image.png1015×415 50.8 KB

De-table-izing this in the HTML emails, which is currently active as you can see ↑ above, is worthwhile in the name of simplicity alone, putting aside every single other issue.

KISS! :kiss:

3 Likes
20

Has this helped things now that this change shipped in 1.8?