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:

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)

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…

LeoMcA:

by far the biggest simplification which can be made is by not using tables.

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.

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?

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

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).

codinghorror:

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…

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.

LeoMcA:

By far the biggest simplification which can be made is by not using tables.

codinghorror:

so, about that…

This is an extremely high risk, low reward change.

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.

tophee:

discourse mails are among the worst in Outlook, especially the summary emails

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.

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

LeoMcA:

So without the header we have a table of one column and one row.

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:

LeoMcA:

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.

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.

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 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.

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.

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.

We are facing this in my community as well, but the approach we are taking is actually the opposite - the benefits of logging in are so great that we push back (gently, gently) to get people to log in more and more. We’ve found that explaining the benefits works. It’s better and more fun to participate in discussions by logging in, and it’s pretty easy to do so. On the other hand supporting email-in users by fixing their posts, answering questions and smoothing over frustrations are a real heada…

What happened to this option? I was just asked about precisely this issue by someone in my community and now see that the settings available changed at some point. We are in the process of trying to identify the “ideal settings” for email notifications for our community which we migrated to discourse from google groups. We are trying to encourage people to participate online but because we are a global network with people in “internet-remote” places, email remains key, and digests seem to be th…

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

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

sam:

Where I would recommend starting is with a plugin that allows users to select an email template as “minimal” or something along those lines.

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

sam:

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

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?