Invite Email & Signup screen UI changes

[ErisDS]

https://github.com/TryGhost/Ghost-UI/issues/22 may introduce a new HTML email template, and there are likely to also be minor amendments to the signup screen to make it clearer that you're accepting an invite after #3081.

This issue is a placeholder for those changes.

[sebgie]

I would need some clarification on what fields are going to be editable by the user on the new signup screen?

• Password
• Username?
• email?

[ErisDS]

@sebgie As far as I know, the only changes @JohnONolan intends to make are purely visual - adding copy to make it clear that you are accepting an invite. The fields will remain the same.

[JohnONolan]

NB we also need to send a plaintext version as a fallback, also it probably wouldn't be a bad idea to have a grunt task to run something like Premailer on it when built:

https://github.com/premailer/premailer

[JohnONolan]

Unassigning myself cos my work here is done 🐵

[sebgie]

@JohnONolan I was under the assumption that you wanted to make changes to the signup screen to align it with how the new setup screen looks like?

[JohnONolan]

Dammit.

[JohnONolan]

Invitation email subject line:

[user.createdby] has invited you to join {{@blog.title}}

Invitation email body:

<h1>Welcome</h1>

<p><strong>{{@blog.title}}</strong> is using Ghost to publish things on the internet! [user.invitedby] has invited you to join. Please click on the link below to activate your account.<p>

<p>[activation link]<p>

<p><strong>No idea what Ghost is?</strong> It's a simple, beautiful platform for running an online blog or publication. Writers, businesses and individuals from all over the world use Ghost to publish their stories and ideas. <a href="http://ghost.org">Find out more</a>.<p>

<p>If you have trouble activating your {{@blog.title}} account, you can reach out to [user.invitedby] on [user.invitedby.email] for assistance.</p>

<p>Have fun, and good luck!</p>

[JohnONolan]

@todo: Replace "Welcome to Ghost" with "Welcome to {{@blog.title}}"

[JohnONolan]

MY WORK HERE IS DONE

swooosh

[morficus]

@JohnONolan are we only looking to send the invitation email's as HTML for now? Or should the same apply to all emails at this point? (welcome/setup, invitation and password reset)

[JohnONolan]

Should be all, ideally

[morficus]

For anyone who wants to take HTML emails for all the things for a spin, check out this branch: https://github.com/morficus/Ghost/tree/issue-3082

@ErisDS what I would like to talk to you about is related to this - specifically the use of this package

[ErisDS]

@morficus dos it not make sense up to write up your thoughts / reasoning here on the issue? I likely won't be the only person with an opinion ;)

[morficus]

@ErisDS good point. Figured it would be easier to discuss in real-time, but here is an explanation of my conundrum:

I've looked at couple packages to help creating and maintaining HTML emails with out the need to directly write in-line styles (because ain't no body got time fo dat).

To no surprise, there are some popular options out there (like juice2 and node-email-templates) but they all trace back to a common dependency: jsdom and contextify. Both which introduce additional dependencies that your average Windows user may not have - jsdom has a nice explanation as to why and what those dependencies are: https://github.com/tmpvar/jsdom#contextify

I played around with the 2 packages I mentioned above... and combining that with express3-hbs template magic... things are looking pretty nice. It could even open up the option of allowing the creation of 3rd party email templates, perhaps to match your custom theme? I'm getting a little giddy just thinking about it ;-)

So here is what I am seeking thoughts on:

• does the benefit of having clean, maintainable HTML email templates outweigh the extra steps it would introduce for Windows users to run Ghost?
• or does these additional windows-only dependencies totally suck and I'm being blinded by "development high"?

[JohnONolan]

Definitely not worth it IMO. The email template is simply not going to change very often. We can keep both unprocessed and processed versions in the repo and just process manually when needed, which I imagine will be once a year or less

[ErisDS]

Anything which introduces problems on Windows is a huge no-no. Lodash has a templating function which we use in the helpers, and I think should be good enough for this usecase?

[morficus]

@ErisDS The lodash template is analogous the hbs template system. But the templating engine/tool is not the issue. What introduces the additional dependencies is any tool (that runs on node) that takes CSS that was originally written inside a <style></style> tag and places it in-line with the markup.

@JohnONolan I'm fine with that. But even manually processing them would mean that if the person had a WIndows machine they would need the additional dependencies (tho we can list them as optionalDependencies in the package.json file or just document that you manually need to acquire the tools somehow)

[ErisDS]

@morficus ok, I'm totally lost. Why do we need to process anything at all?

[morficus]

@ErisDS when sending HTML emails, (because dealing with email clients is worst than dealing with IE6) the only way to guarantee that the styling and formatting are maintained is by using table-based layouts and putting styles directly in-line with the markup (ie: <p style="margin: 0; padding: 0 0 1.5em 0; color: #828282">Hello, world</p>) - so things inside a <style></style> tag in the head or external style sheets are out of the equation.

But no body in their right mind would want to manually write in-line styles... so for that there are a number of tools (some node-based, some ruby-based, others java-based) which allow you to write HTML + CSS as you normally would (separate), but then running a tool would generate the in-line version of it.

Here is an example

A developer would write this (/path/to/file.html)

<html>
<head>
  <style>
    p {color: red;  text-decoration: underline;}
    .container {  padding: 0 4%; }
  </style>
</head>
<body>
<div class="container">
    <p><strong>Hello!</strong></p>
    <p>Good news! You've successfully created a brand new Ghost blog</p>
</div>
</body>
</html>

after being processed by a tool like juice or premailer, it would output this:

<html>
<head>
</head>
<body>
<div style="padding: 0 4%;">
    <p style="color: red; text-decoration: underline;"><strong>Hello!</strong></p>
    <p style="color: red; text-decoration: underline;">Good news! You've successfully created a brand 
</div>
</body>
</html>

[ErisDS]

But no body in their right mind would want to manually write in-line styles

I know what you're getting at, but this email template is tiny!

If you really want to optimise this, then I think I would approach it differently. Moving the styles inline for the template itself shouldn't take long, as it's just these styles:

+    .wrapper {
 +        margin: 2%;
 +        padding: 5% 8%;
 +        border: #e5e3d8 1px solid;
 +        -webkit-border-radius: 3px;
 +        -moz-border-radius: 3px;
 +        border-radius: 3px;
 +    }
 +    .container {  padding: 0 4%; }
 +    .content img {  max-width: 100%; }
 +    .footer-cell {
 +        padding: 0 0 20px 0;
 +        color: #888888;
 +        font-size: 11px;
 +        line-height: 1.3;
 +        font-family: sans-serif;
 +    }
 +    body {
 +        width:100% !important;
 +        margin: 0;
 +        font-family: sans-serif;
 +        font-size: 15px;
 +        line-height: 1.5;
 +        color:#828282;
 +        background:#ffffff;
 +        -webkit-font-smoothing: antialiased;
 +        -webkit-text-size-adjust:none;
 +    }

Then, for the individual element styles for h1, h2, a, p, ul, and ol I think it should be possible to setup these as individual lodash templates with the inline styling, and then define the email body as a set of templates. Much of the content of email needs to have data substituted in anyway, so I think a hierarchy of lodash templates makes some sense?

[ErisDS]

That or, by all means produce the HTML email templates by processing them with the libraries you recommend, commit them to the codebase, and just write a wiki page with the steps. The number of times it will need adjusting should be minimal, and I don't see that we need to include the ability to process the templates in core.

[morficus]

@ErisDS so to summarize, basically what @JohnONolan said :-)

I'll have a PR for this in a few.

[morficus]

A companion wiki entry has also been created: https://github.com/TryGhost/Ghost/wiki/HTML-email-template-generation