HTML Emails: Improving workflow and process
With tens of stacked tables and Outlook conditionals, HTML email code can be hard to read. Plus with many complicated solutions to the varying obstacles email developers and designers face, our code can become inconsistent, and inevitably tough to debug.
Here are some top tips and tools that will improve your process and help you write clean, consistent and effective code:
1. Snippets
DRY. Don’t repeat yourself. The quirks and rules of HTML email development make this task tough, but by making good use of snippets you stand the best possible chance of not having to write the same code over and over again.
Snippets are chunks of code that you can save in your text editor and call upon whenever you need them using a trigger word. Most good text editors support this feature (Sublime, Dreamweaver, Coder, Notepad++ etc.).
Creating a boilerplate snippet is a great way to start using and realising the potential of snippets. This should include the doctype, metatags, title tags, style tags, media queries, opening & closing body and table tags etc. Basically all those initial elements that are easily forgettable and time consuming to type out should be called upon in one simple snippet.
However it doesn't have to stop there. A 2 column layout? Save it in a snippet. A 100% width feature box with CTA? Save it in a snippet. Bulletproof button mark-up? You’ve got it, save it in a snippet!
Even those pesky bits of code that you always have to google to remember, like hiding pre-header text properly, or ensuring that links of iPhone are not that horrible blue — save them all in snippets.
Aside from saving you tons of time, snippets also ensure that your code is consistent, tried and tested.
Top tip: the Litmus community has a forum dedicated to snippets. You can search and use useful, email specific chunks of code and share your own too.
2. Emmet and shorthand HTML & CSS
Tables within tables within tables. It’s both repetitive and time consuming.
Learn Emmet and you’re guaranteed to save time and put and end to :
<table><tr><td></td></tr></table> It takes a little time to get used to, but comes with comprehensive documentation and once the concept is grasped it is very intuitive. It also means that you are less likely to forget to close off a <td> or close an<a> with a </p> by mistake. It is compatible with all the major text editors.
There are alternatives if you like the idea of shorthand HTML but can’t get to grips with Emmet. Check out Jade or Zen.
3. Testing
The amount of email clients and more frustratingly the differing ways in which they render code can make testing difficult and not thorough. On top of this there an the ever growing list of devices that people use to read their emails which email designers need to accommodate.
Ensure that you know who is reading your email and through what client. There is no point in spending excess time ensuring your email renders correctly on Lotus Notes if your audience does not use it.
It would be almost impossible to have every email client and device to hand but luckily Litmus offers a brilliant service that allows you to test your email across as many or as few devices and clients as you like. It even has outdated versions of clients such as Outlook 2003 or early Android phone clients. What’s more, with the new Litmus Builder you can manipulate the code and get instant previews across all chosen clients. This makes debugging for a specific client extremely quick and easy and allows you to ensure any changes you make do not effect how your email will render in other clients.
Get an account and ensure that every email you create is put through a Litmus test – it’s quick, easy and impressively accurate.
This doesn't make physical device testing redundant though – especially when it comes to design aspects. On screen, your mobile font size might seem fine, but once actually viewed on an iPhone, <h1>’s can often seem unnecessarily large, or body fonts appear too small.
Always use Litmus and test physically on the most popular devices/ clients as a bare minimum. That way you avoid this feeling having sent an email:
4. Version control
Those emails that are a permanent feature on your scheduling will change and develop overtime and potentially pass through different hands. If you are constantly in and out of your code, mistakes are inevitable, and once overwritten an email that functioned perfectly moments ago can take hours to debug.
GitHub is perfect for this. Once you have come to terms with its language (pushing, pulling, merging, committing etc.) it should become an integral part of your email development process. By committing your changes in small chunks, you can quickly access previous incarnations of the email. Equally it’s great for testing out new or comparative ideas for A/B testing on separate branches without interfering with the master code. Also, if someone edits your code you can both identify who has done it and proof, accept or reject the work they have committed.
In short…
While coding emails differs so much from coding for the web, the goal is always to create efficient, consistent and bug-free code. The tools and processes above will help achieve this in a world where the most simple simple layout can require such complicated solutions.
If anyone has another tools, processes or tips that further help with coding HTML emails, be sure to share in the comments.
Jono is a Web & Email Designer — Find him on Twitter @jonomilnes and visit his site: www.jonomilnes.co.uk
