Emails. Yes Emails.
So recently I was tasked with building out a couple of email templates. Now I normally spend my day to day in the wonderful world of React. For me it's here that I enjoy the convenience of tools like auto prefixing for my styles and babel for compiling browser compatible javascript. So needless to say I was little apprehensive about going back to tables, inline styles and guessing what will work in which email client.
But with the initial apprehension out of the way, I started to look at it like any other project. I started to break it down into what the project should achieve outside of delivering just the finished email templates. So with that in mind I set out to create a workflow that would make working on emails easy, enjoyable even?
Framework
The first port of call was to see if there were any frameworks that could take the pain out of developing responsive emails. After a little research and a recommendation from a co-worker, the two front-runners were Foundation for Emails 2 and MJML. Both are open source and at the time of writing both have around 6,500 stars on GitHub.
After weighing up the pros and cons of each framework we went with MJML. There were many reasons that led to this decision. To name a few: it has some great documentation, editor plugins, an online editor, a CLI tool and a great community behind it. But the deciding vote was that it has a markup language that is semantic and straightforward to understand which later gets compiled into responsive HTML.
Goals
With choosing our framework out of the way, the next task was to bring it together into a project with the following goals:
- Works with multiple projects/brands
- Ease of use
- Rapid development
- Good developer experience
So let's assume we have a need to develop emails for Cuppas, a fictional coffee shop, and in the near future we know that one of the team will also need to develop emails for Frosty's a fictional ice cream shop. With that in mind, we will take a closer look at the goals.
Works with multiple projects/brands
The ability to work on individual brands/projects without needing to switch out of the overall emails workflow. This will allow one place for tooling, tests and publishing. It will also reduce context switching and make it easier to maintain.
Ease of use
A new developer tasked with creating a new email template should be exposed to as little as possible of the build tools, and the why/how of what goes on behind the scenes. Ideally, they can be up and running in a couple of minutes and only need to follow MJML documentation to learn the new markdown syntax along with a command or two to compile the emails. Ideally, the publishing would be an automated process.
Rapid Development
So this one speaks for itself! It is solved for the best part by the framework but is worthy of another mention as it was one of the main goals. I will go into more detail on this in my next post.
Good Developer Experience
This one is always a nice to have but I feel that this feeds back into the ease of use goal.
Testing
To test the emails visually in email clients there were two front-runners: Email on Acid and Litmus. Both are paid services but are well worth it as it saves you from trying to get access to a multitude of email clients. Both offer a 7 day free trial so it would be worth evaluating both of them for yourself. As I had previous experience with Litmus that was the one I went for. Another excellent tool is Putsmail it allows you to send a quick test email to any address, just make sure to not to tick the inline CSS option as MJML takes care of all this for you.
Conclusion
Putting all that together the end result was MJML Multi Project. A project that strives to meet these goals. In the next blog post, I will go into more detail on the code behind it and a look at some of the goals and whether or not they were achieved. In the mean time be sure to check out MJML Multi Project and also check out MJML on GitHub for the documentation and you will find a list of other cool plugins and applications to support MJML.