Send HTML email notification for more compact presentation

I don't see this as a launch blocker, retagging.

Personally, I'd like (simple) HTML emails with regular links, but that's a separate issue.

I agree that the current list of links is overly verbose.

Further, I agree that a simple HTML email makes a lot of sense. What do others think about this? I promise that an HTML email would not contain images and tracking beacons and al that nonsense.

This HTML email template has 1500+ stars on Github. It is responsive - https://github.com/leemunroe/html-email-template

Looks pretty good from:
https://github.com/leemunroe/html-email-template/blob/master/email.html

So if we wanted to implement this, what is the next step?

Certainly, we're all using more mobile devices these days. If we made Drupal & Drupal communications more mobile friendly that could only be a good thing, right?

I think an HTML mockup of an email notification would be a good next step. It should include comments, attachments, etc. Presumably an HTML notification from Jira/Bugzilla/etc. would be a good starting point.

How many people are getting regular emails from Drupal.org?

Thoughts on how to implement it?
https://drupal.org/node/900794

Any thoughts on the smtp module:
https://drupal.org/project/smtp

I'm trying to see if I can get some sample text tow work with.

I don't see much point in using SMTP module. Lets just send one (much improved) HTML email to everyone. It isn't like we have lots of different email newsletters to send.

So how does this look?

Crazy to go back to tables. Lowest common denominator I assume.

Thanks for moving this ahead.

I've attached a notification from Jira. Key enhancements include a user picture and a red/green diff when issue values change. This is done for persistent text values as well, like Issue Summary.

Specifically about the HTML mockup you presented; I would personally like it if all the values in the table are hyperlinked to Searches in the current project. So, this issue would hyperlink component 'Mail' to https://drupal.org/project/issues/project_issue?component=Mail. Also, the date looks too prominent there, IMO.

For mockup purposes, it makes sense to use a comment (like this one) that also changes a couple Fields.

I had a play around with the visual hierarchy, trying de-emphasise the less important information.

It would be interesting to see how many people click on the update issue link but, like with the profile pictures, it's better to leave the new features and content to a separate issue.

We should be able to do A/B testing based on user ID to evaluate new designs and look at how changes like this affect behavior.

I don't know if the #7 should stand out on it's own. It's not useful without context.

Agreed. I don't like the #7 either. I was just looking to bring the styling closer to the comment styling on the site.

We should be tracking clicks right now :) I have no idea how important all these links are.

"We should be tracking clicks right now" - Yes, but how?

Neither of these is going to work:
https://drupal.org/project/pop_links
https://drupal.org/project/click

Would be nice to track uid, message id & link.

Not sure there is an easy way to do that.

Adding Tags

Oh right, I was thinking the old fashioned way with Google Analytics, example here.

Something like:
http://www.drupal.org/node/[nid]?utm_campaign=issue-notification&utm_medium=email&utm_source=[uid]

Let's limit the scope of this issue to removing calls to drupal_html_to_text() and making sure the basic HTML is an improvement over text in many mail clients.

Further improvements can be followups.

Adding meta, tagging.

So I don't think we've talked about how to actually send these HTML emails.

On sites where we've wanted to deliver this sort of thing for our clients, we've used a combination of:

• HTML Mail to actually get the email wrapped in an HTML template
• Emogrifier to rewrite the CSS into inline styles (basically for gmail).
• Mime Mail to provide a non-HTML fallback and embed the images inline.

We've not really used the whole 'hey you can send emails with your site's theme thing' because we haven't really wanted our emails to look too much like our site, and we need to do tables in emails etc.

But anyway, this is all certainly possible, but kinda hinges on what d.o maintainers are happy about installing I guess, certainly we're going to need quite a few modules to get going with.

FWIW, a strong -1 to HTML email notifications. — They're substantially larger in size (many more KB, negatively affecting your mobile traffic volume), HTML text is harder to read, the wrapping HTML template adds unnecessary noise + spacing, and a HTML representation very often hides away originally intended text formatting (which is lost on d.o, too, but the email notification currently shows the originally intended formatting/meaning). Lastly, a proper MIME text/html email design dictates that an alternative text/plain presentation is contained in each mail, further increasing their size - not every email client is capable of rendering HTML, and omitting text/plain can trigger spam filters (as that has become a detection rule, since many spam mails only include a text/html body).

In turn, "more compact" makes a questionable claim about the visual presentation (most often not true) and ignores the data/traffic size compactness altogether.

+1 to the original problem statement in the issue summary though; running dhtt() separately for each contained content fragment would improve the text email notifications.

I don't think we should do heavyweight HTML emails. Instead of footnotes for links, use <a href="">. Use appropriate headings and/or <strong> to make sections of the email easy to pick out.

Personally, I have no desire to have any CSS. That would be hard to get right and QA, and isn't necessary.

They're substantially larger in size

A broad generalisation

HTML text is harder to read, the wrapping HTML template adds unnecessary noise + spacing

Another broad generalisation and commonly untrue. Is all typographical design worse than default browser styling?

not every email client is capable of rendering HTML

Sure, but what is the market share of these clients (with a tech savvy audience) in 2014? isn't this the same argument as supporting IE5?

HTML representation very often hides away originally intended text formatting

Another generalisation, why not raise all of these as objectives of the HTML implementation instead of reasons not to do it at all? It's certainly possible to avoid all of these problems with a correct implementation.

@drumm: Sounds like the only reason for investigating HTML mails is to get rid of links as footnotes? (Whereas I and probably many others like the footnotes, because they massively aid in speed-reading.)

@LewisNyman:

broad generalisation

All of the examples shown here (mockups, JIRA, etc) are running into the exact same trap. — Just because you have rich formatting available doesn't mean you should use it.

The art of communication is to transfer information as quickly, intelligently, and as concisely as possible.

Having to scroll down to see the actual comment? Ugh.
Three lines of wrapped text just to communicate the context/issue-title? Ugh.
Reducing available display width just to insert a fancy background/border? Ugh.
…

Notifications are about communication, not about looking fancy. Some people need to read + process more than a hundred of these emails on every single day.

In any case, let's please make this an opt-in and retain pure text/plain mails for everyone who cares about traffic and speed.

@sun How do footnotes enable you to read faster? Do you skip over the [1] when reading in a way that you wouldn't if the text was a different colour/underlined.

For sake of comparison with something very minimal in terms of HTML. I put the issue summary and comment #22 through Redmine and then took some screenshots of the original email from d.o and the Redmine one in gmail. Now I know that not everyone uses gmail, and we should totally test anything in as many mail clients as possible, but this is mainly just to give an example of 'minimal' html emails, also I'm fully aware that there are other flaws/limitations with this.

Current Drupal.org

Redmine replica

(If there's scaling on the embedded images here, you might want to open separately to see and compare)

Comments

• Note how both use the subject of the email to give context, rather than putting that at the top of the email.
• When reading @sun's comment in the d.o email I totally missed the response to @drumm at first, because it's squashed up next to the preamble.
• The whole footnotes thing is weird for me. I don't have to do that on any other website/email, if there's a link, I just click/tap. I don't have to attempt to find it in a massive list, although it is nice that I know exactly where that link will take me.
• The 'complex' formatting of the blockquote just looks a bit pants in the plain-text email, whereas the HTML email has kept the formatting here.

On my phone they look broadly the same, except that the text wrapping is weird on the plain-text one. I guess because the plain text one can't distinguish between an intentional and a forced line-break. I think the readability of the HTML one wins here?

Plain text

HTML

So I converted my dev site to use HTML email notifications, a quick list of what I did was:

1. Installed the Mimemail module.
2. Installed the Mail System module.
3. Configured the mailsystem module to use the Mimemail module when sending just the Project issue notifications.
4. Configured MimeMail to not send along the site's CSS.
5. Added a new filter format that just replaces line breaks, and nothing else, and then configured MimeMail to use it.

I get emails that look like this:

Or this (more complex comments):

or this:

Note that in those examples above the visual changes are actually quite minimal, and essentially they boil down to two major things:

1. No footnotes.
2. Wrapping is now at the viewport width.

Mimemail allows a user to say that they still want to receive emails in plain text, which seems to revert the mails to the current behavior.

Now, the emails need a little work for sure, just to tidy them up, we are sending the file attachment images for one, which probably isn't required.

If anyone else wants to have a play with this testing site: https://steven-drupal.redesign.devdrupal.org/ message me via my contact form, and I'll reset your password on the site so you can input an email address for testing.

See #2128907: Remove fileicons from file upload views for removing those file icons from HTML for web browsers.

Yeah, really close for a first try. I'd like to see the first three links turned into hyperlinks which will take up less vertical space.

@moshe weitzman Yeah, I totally agree. However...

Those links at the top of the email are deliberately not links at the moment (I think) because then they don't get replaced out with footnotes, but rather provide an easy way to get to the link and the edit form for the issue, without having to go to the footnotes and finding the one you want.

So while we can replace them with something more compact for HTML people, it will affect people who stick to plain-text emails, because they'll get footnotes for those links.

So...I guess we need to decide if plaintext people should get some nice links at the top of their emails, or if they should be forced into using footnotes, or if we have a hybrid, where maybe just the main link to the issue is printed as a URL, so that plaintext emails viewers still make it a link, but HTML emails are more compact elsewhere.

So, a first pass of the 'hybrid' looks like this:

Rich text

Plain text

Added an issue summary.

Could we ditch the direct link in the header to the issue edit page? Do people use that a lot? Do we have any stats available on d.o that would allow us to see?

Could we ditch the direct link in the header to the issue edit page?

Let's remove it because editing an issue is done directly on issue pages now. And there is a prominent "Update this issue" link usually above the fold.

Do we have any stats available on d.o that would allow us to see?

Google Analytics does say 0.05% of sessions were referred by email site-wide. I'm not sure how readily this can be dug into, since our paths are node/*. Since there is no personally-identifying information in Google Analytics, I'm okay with handing out access, I need your email associated with a Google account.

After a quick poke around in GA, it looks like people have arrived directly to a node/nnn/edit page about 160 times in the past month, and of those 8 were from emails.

So, with the usual caveats about Javascript based tracking etc. this doesn't look like the most used feature of these emails does it?

Remove it, then wait to see if anyone complains ;-)

The plain text email in #29 manages to show the first link AND duplicate it again as a footnote. This is somewhat sloppy IMO. I'd be OK with expecting plain text recipients to use footnote links.

@moshe weitzman well, actually I think that isn't really a link, but my email software (gmail) decides that it looks like a link and makes it one for me.

Is the 'Remaining tasks' list up to date? Should we have a 'Done tasks' list also?

Have we done anything yet? Should we concentrate on one task at the time and maybe change this to a META issue?

@jiv_e yeah I think that list is still broadly accurate. I don't think any of the tasks have been done, so I don't think we need a done tasks section yet, and when we do we can probably just use strikethrough to indicate that.

Do you have any thoughts about the format of the emails that I was working on in #29?

(Aside: I looked at the email that I got from d.o notifying me of your comment in #37 and frankly, it was terrible, I had to scan it multiple times to see where your comment began. We can, and should, do better!)

Updating the issue has been on the same page as viewing this issue for some time. I went ahead and removed that link to simplify the email a tiny bit.

I plan to deploy this next time we need to update project_issue module on Drupal.org.

Merging issue summary and proposed resolution status with suggestions from @andy-blum who posted in them in #3200239: Make system emails more legible with HTML emails