I have made loads of progress on emails in the past weeks, and I have so much more to learn. Putting a pause here, though, I want to share what I have found because it took me a long time to get here.
1. Three emails per email
When you create an email that will be sent from your site, you need to produce three versions: plain text, watch text, and html.
Plain Text
Plain text is simple, it is content with no html or styling. The most exciting thing in it is the \n new line. :rofl:
Watch Text
Watch text is a little more complicated. You can include some styling, but it is very basic. Some paragraph tags and lists are about what you can manage. This is explicitly for the Apple Watch.
HTML
The pretty emails that are eye catching and styled to engage your audience. Not everyone can or chooses to recieve html email, so make sure that your message is not hidden in the images or styling of the html email.
2. Special email styling
An HTML email may sound like a regular html page, it is not. That is because there are about a bajillion different email clients and all of them treat the carefully crafted HTML that you made a little different. From what I have learned, there are three basic rules (I wrote a little about this in my post on newsletters:
Everything is a table
All styles must be inlined
A big ol’ 600 px table wrapper protects your content
With regard to the 600px wrapper, there is so much discussion about this, and I’m honestly not sure which email clients we still need to keep this for. You may be able to test the limits. For example, in this litmus community discussion, designers are suggesting that they are getting some emails > 900 px. However, email on acid shows more limits with an example of a three column layout common in Outlook. I’m no expert, so I’m sticking with the 600px recommendation for now.
protip: think ahead about forwarding. Forwarded HTML email messages get real ugly, real fast. If you think your users will forward your emails often, use very limited styling or add a “forward to a friend” button or link that will send a fresh new email or possibly archive a version on the web, so that they can click on “view this in your browser”.
3. Just like building a web page
While the styling is different, the considerations are the same as building a web page. At first, I thought that I needed to use a different engine because nearly all of the examples were for handlebars. I was losing my mind a little because it seemed silly for me to use yet another templating engine when I already built my site with .ejs. And it was silly, and unnecessary. I finally realized that I could just do it with .ejs and javascript.
snippets in api
The plain text and watch text are created right there in the controller, (they could be in separate functions, but I’m trying to keep this simple), but the html has to be rendered before it is sent. Here is an example of how the html file might look:
mailers/sendUserUpdate/html.ejs
^^ I actually split this up into several files, see the “includes”? This means that my header and footer, for example, can be reused across many different emails. Here is what it looks like in my application.
mailers/sendUserUpdate/html.ejs
Where, usergreeting.ejs is for example:
mailers/usergreeting.ejs
The result is something like this (code beside email):
Code in Atom with example email
4. Follow the Damn Law
You may have noticed that I did not have an unsubscribe in my email coded above. That is fine because my email was relational in nature and did not have to include one, but it should, just to keep recipients comfortable.
According to the CAN-SPAM ACT, you have to include your address and a way for people to unsubscribe when you send primarily commercial mail (when it is not relational or transactional).
So, how do you include unsubscribe? This is not a trivial exercise - unsubscribe will require three additional considerations.
Unsubscribe in your data
Each one of your customers/emails/whatevers needs to have an indicator for the email they want from you. For example, if you are using mongoose you can add a boolean or an enum to your user schema, like so:
api/models/user.js
Unsubscribe as an API endpoint
In order to adjust your unsubscribe, you will need to code an endpoint that makes a change. Here is a simple method for adjusting the boolean example above, assuming that the link used is something like, https://yoursite.com/users/:uid/unsubscribe.
snippets in api
Unsubscribe in the email
This might be the easiest part. When you create the email, you can populate an unsubscribe link with the :uid and just plop that in, like so:
To Be Continued
As I learn more, I hope to add new posts to add on this.
Note - it may be reasonable to start out with a ready made system like that from MailChimp (which I am just now trying out on this blog) instead of rolling your own system! <That MailChimp link is my personal one, so if you sign up to use it, I could get a reward>
Also..shout out to the Moms Can Code community for support while I worked on emails almost every day.