Make notification emails beautiful

[Feld0]

HTML emails in IP.Board were an excellent addition, but they are still little more than the traditional plaintext emails wrapped in an HTML template. A great next step would be to make HTML emails beautiful... really beautiful - and by that, I mean overhauling them to be generated in a different manner that can really take advantage of the formatting and styling potential of HTML. Look at the emails Twitter, Facebook, and various other huge websites to get an idea of what I'm talking about.

Because a picture speaks a thousand words, let me leave some comparison shots of two equivalent IP.Board and XenForo notification emails (edited to look like it's from a fictitious site and from an identical topic, for the purpose of demonstration):

Things like quote blocks and other elements can all carry across into an HTML email. In a perfect world, there would even be a relatively straightforward way to get the notification emails to match your site's look and feel (perhaps they need a full-blown templating system like the site itself?), but merely getting them to match even the default IPS skin would be fantastic.

[Dmacleo]

you can edit your email templates to act however you want right?

[Ryan Ashbrook]

HTML emails in IP.Board were an excellent addition, but they are still little more than the traditional plaintext emails wrapped in an HTML template. A great next step would be to make HTML emails beautiful...

really beautiful

- and by that, I mean overhauling them to be generated in a different manner that can really take advantage of the formatting and styling potential of HTML. Look at the emails Twitter, Facebook, and various other huge websites to get an idea of what I'm talking about.

Because a picture speaks a thousand words, let me leave some comparison shots of two equivalent IP.Board and XenForo notification emails (edited to look like it's from a fictitious site and from an identical topic, for the purpose of demonstration):

Beautiful Email.png IP.Board Email.png

Things like quote blocks and other elements can all carry across into an HTML email. In a perfect world, there would even be a relatively straightforward way to get the notification emails to match your site's look and feel (perhaps they need a full-blown templating system like the site itself?), but merely getting them to match even the default IPS skin would be fantastic.

That's a plaintext email from IP.Board, not HTML. If it is HTML... your clients stripping the CSS.

This is an HTML Email from IP.Board

.

And yes, you can edit the HTML Email Wrapper to your liking in 3.2, 3.3, and 3.4. (3.2 & 3.3 required you to edit a file, 3.4 allows it via the ACP).

[Wolfie]

I think what Feld0 is saying is it would be nice to have HTML templates for the various email notifications, pre-designed and such, so that all an admin has to do is customize for their community.

I think this would be a great idea, but would need to be more intensive to make it what it should be. So for IPS 4.0, a new template area for emails, where you can edit both the HTML and plaintext styles in a template editor like interface. Put in the language bits where needed, so you can make a uniform look that stays the same regardless of what skin is default, language settings, etc.

I think it would be a vast improvement, but should definitely wait for 4.0 to be added.

[Feld0]

you can edit your email templates to act however you want right?

That's a plaintext email from IP.Board, not HTML. If it is HTML... your clients stripping the CSS.

This is an HTML Email from IP.Board

2012-12-12_0016.png

.

Well... my "client" is Gmail, one of the largest webmail services on the planet. :tongue: HTML emails from most places appear with all their formatting intact, so there must be something in IPB's default template that Gmail doesn't like. Might be worth taking a look at, considering the ubiquity of the service. For reference, Ryan, it appears like your screenshot on my iPhone.

But anyway... I'm getting off track. The main issue is that the HTML email "template" is, in its current implementation, a simple wrapper around a $content variable which contains the contents of the entire email, and that we have no control over.

The output that is inserted there is eerily reminiscent of a plaintext email. While smileys and line breaks are rendered as images and <hr /> tags, respectively, HTML emails can be so much more. Quotes can, for example, be placed in <blockquote> tags that are styled to look like the on-site ones. Avatars can be displayed beside post authors. More adventurous formatting could be used to make each element of the email stand out. Some of the (very long) links can be replaced with simple, friendly buttons. I'd look to the XenForo email I attached a screenshot of in this topic's first post for some inspiration, but here are some more notification emails that I would classify as "beautiful":

Here are a couple of Nintendo marketing newsletters as well. Though they are not exactly automated notifications, their primary purpose is to draw a user's attention to Nintendo's and their partners' content, and I think they succeed well in that regard, so there are a few lessons to learn there. In particular, note the personal summary of my Club Nintendo account in the first email.

Note the use of colour, font sizes, "call to action" buttons, avatars, and link anchor text in all four of these. The small unsubscribe links in all of these emails look much friendlier and more aesthetically pleasing than IP.Board's massive You can unsubscribe at any time here: http://mysite.com/unsubscribe/Zm9ydW1zO2ZvcnVtczs3OzE5MTtmZWxkMEBmZWxkMC5jb20,/ link which draws an awful lot of attention to itself. When sending an HTML email, it is not necessary to render out the entire URL as the anchor when a simple href attribute will suffice. :smile:

These changes cannot be made by editing the email wrapper; they require fundamental changes to the way that apps themselves render HTML emails (a plaintext fallback may need to be provided separately, instead of the current setup which appears to "wrap" the plaintext message in a bit of HTML). With more and more services adopting "beautiful" HTML emails like that, adopting them good and proper in the IPS suite will be a great way to call more attention to our boards' emails in users' inboxes and to stay current with the times.

[Marcher Technologies]

These changes cannot be made by editing the email wrapper; they require fundamental changes to the way that apps themselves render HTML emails (a plaintext fallback may need to be provided separately, instead of the current setup which appears to "wrap" the plaintext message in a bit of HTML). With more and more services adopting "beautiful" HTML emails like that, adopting them good and proper in the IPS suite will be a great way to call more attention to our boards' emails in users' inboxes and to stay current with the times.

Incorrect.

The {$content} of every message in any app or core should directly correspond to a language bit, you not only have full control of it, you have control of it by message type and user language.

The actual posted content, however, I am wondering what happened to the quote styling. :unsure: It was there.

[Ryan H.]

I pity the soul that put those two marketing emails together.

e: Marcher... totally correct, actually. Yes, you can edit notification emails with the lang system... but it's still inherently plaintext and lacking any form of styling. You could change them to HTML, but then you have no plain text equivalent.

[Wolfie]

Incorrect.

The {$content} of

every

message in any app or core should directly correspond to a language bit, you not only have full control of it, you have control of it by user language.

The actual posted content, however, I am wondering

what

happened to the quote styling. :unsure: It was there.

I think he means in the sense of having a true HTML version vs a plain text version, but each being different instead of the HTML version being a wrapper to the text version.

[Marcher Technologies]

ok... so... basically allow said strings to be defined separately for html, if they exist, use them?

basically the exact same key, just prepend it with html__ or something.... would allow said customizations without an insane recode of the way apps handle it.

[Wolfie]

ok... so... basically allow said strings to be defined separately for html, if they exist, use them?

basically the exact same key, just prepend it with html__ or something.... would allow said customizations without an insane recode of the way apps handle it.

What I was thinking was something like the template editor, except instead of templates/css buttons, would have html/plain text buttons. The different groups would be based on applications (Core/Forums/Members/etc) so it would be easy to navigate. Things like {$content} would be things like an actual message, such as a copy of a post when getting notified of a new post. Would give more room to format the email instead of a cramped area that you have in the language editor.

[Marcher Technologies]

What I was thinking was something like the template editor, except instead of templates/css buttons, would have html/plain text buttons. The different groups would be based on applications (Core/Forums/Members/etc) so it would be easy to navigate. Things like {$content} would be things like an actual message, such as a copy of a post when getting notified of a new post. Would give more room to format the email instead of a cramped area that you have in the language editor.

would need, necessarily, to have a language abstraction system if it gets moved out of the Language bits fully, or one should at minimum be able to use them(language strings).

[Wolfie]

would need,

necessarily

, to have a language abstraction system if it gets moved out of the Language bits.

Well of course, but the idea would be make editing HTML vs plain text easier and also having completely custom content.

Could be worse, could have a copy for each language... Although I think that would be overkill.

[Marcher Technologies]

shrugs.

FYI Feld, style .eQuote however you like. :smile:

[thompsone]

Can anyone share what files the email templates are in and where are they?

Thanks.

[Rikki]

I agree, and this is an area we'll be working on in due course.

thompsone - you'll find them in /cache/skin_cache/system/emailWrapper.php in your forum root.

[Wolfie]

Thinking on this some more, what about an editor that is a cross between the skin/template editor and the ccs/page editor? Left would have the different email templates (one tab for html, other for plain text). On the right have a collapsible box that has various email related language bits available under one tab and possible user related values under another tab. As you design things, you click on the (+) icon to add the item and then click on another button to 'preview' the template.

:D

[Dmacleo]

I agree, and this is an area we'll be working on in due course.

thompsone - you'll find them in /cache/skin_cache/system/emailWrapper.php in your forum root.

done yet?

:P

[Wolfie]

done yet?

:tongue:

[Dmacleo]

LOL :)

[Andrej]

I agree, and this is an area we'll be working on in due course.

thompsone - you'll find them in /cache/skin_cache/system/emailWrapper.php in your forum root.

Good news. :)

[citrixws]

is there a way to completely customize the look and feel of email notifications

[teraßyte]

Personally I hope they totally remove plain-text notifications from 4.0 and just make HTML notifications look better. There is really NO point in keeping them both around in 2013. How many clients can't read HTML emails nowadays? It would make coding notifications much easier too, right now there are a lot of "hacks/tricks" in the code to handle special situations converting code from plain to html and vice-versa.

[ADKGamers]

Personally I hope they totally remove plain-text notifications from 4.0 and just make HTML notifications look better. There is really NO point in keeping them both around in 2013. How many clients can't read HTML emails nowadays? It would make coding notifications much easier too, right now there are a lot of "hacks/tricks" in the code to handle special situations converting code from plain to html and vice-versa.

Yeah It seems like almost every email besides spam email is in HTML these days. (ok that's a little bit of an exaggeration but still. . )

[Wolfie]

How many clients can't read HTML emails nowadays?

There are still a few who can't see HTML in emails. Of course, I don't believe that the plain text versions should get any special treatment, other than getting right to the point. Minimize any effort needed to edit the plain text versions but keep them available. Focus on making it easier to fully edit HTML versions without just plopping the plain text version inside a template.

[Ryan Ashbrook]

is there a way to completely customize the look and feel of email notifications

Yes, you can do the by editing the System Templates in Look and Feel.