In the two weeks or so following the launch of Canvas, we’ve had a bit of time to reflect on creating the layouts and elements that allow you to create robust, mobile-friendly email newsletters. One thing that particularly stood out was how important it is to have the right tools and processes in place – especially when working in a team.
As an email coder, I was particularly interested in the waterfall model used to develop each of the Canvas layouts – each of which consist of multiple layouts and a selection of elements (text fields, buttons etc). Each of these pieces required close collaboration between both our email code and design teams – which even amongst the most well-behaved of us, can be fraught with danger.
So, here’s a look at the 6 steps, from kickoff, PSD handover to testing, that our team worked through to create the templates. Hopefully our workflow will help with your next project, no matter if it’s 10 unique templates, or one.
Step 1: Choose the best tools for communicating in teams
First of all, it was really important that we found a means to collaborate and share between design, email coding and whoever wanted to jump into the project. We tried a number of approaches to discussing and clarifying issues, including the use of Shipment, LayerVault and a HipChat room. At the end of the day, we selected Basecamp – not only were its todo lists already familiar to many within Campaign Monitor, but are pretty good for sorting through coding tasks and facilitating deeper discussions around each of them.
For template issues (for example, VML code not working as expected in Outlook), JIRA was selected – again, a tool that is very familiar to the team. Using JIRA allowed us to also loop in our testing team, without forcing them to use tools outside of their existing workflow.
Step 2: Get to know the template
Once everyone was settled on collaboration tools, it was time to receive the Photoshop mocks in PSD format from the design team. This was a bit of a discovery phase, requiring the email developers to have a good look through PSDs of both the desktop and mobile versions of a template.
Things that we focused on included identifying standard layouts (one, two, and three columns) that email coders are generally familiar with, vs non-standard, more adventurous ones. Seeing how the same layout or element looks translated between desktop and mobile is always very interesting; thankfully our designers are pretty used to working with responsive emails (and their quirks), so aren’t prone to making outrageous demands as far as layouts go!
Step 3: Identify tricky layouts and elements; code and test them
Anyone who has coded an email template from scratch knows that often, finding out what works and what doesn’t across many email clients can be quite an exploratory process. With our templates, some of the elements had to be coded and tested aside from the template-in-progress, to ensure they could be incorporated into the design. As always, some things may not look exactly the same across all email clients, but they should at least degrade gracefully – and look good.
Also, if something in an email design turns out to be actually impossible, it’s good to give that feedback early, since design changes can often have ripple effects.
Step 4: Create assets
Now that we’re fairly confident that the template mocks can be turned into a rock-solid email template, it’s time to slice away and create assets. This includes both graphic elements in the template itself, and placeholder photos from the mockup.
To ensure images are optimized for Retina displays, we exported them from the PSDs provided at 2x size, and then resized down to 1x using the image’s width and height attributes.
The exception to this were background images (for example, those used in bulletproof buttons), which we usually exported at both 1x and 2x sizes.
Step 5: Start coding!
While each Canvas template is designed to be fairly dynamic as far as combining layouts and elements goes, we found that coding a long, static HTML file with placeholder content helped us envision the final product. A modified LESS framework was developed during this stage, with each template’s styles.less file containing a number of variables for basic styles and calculations, followed by styles which are specific to the template. CodeKit was used to process the LESS files and speed up browser testing.
As an aside, the ever-helpful Stig on our team created a Chrome extension for overlaying the PSD designs over HTML pages. Called Blueprint, this extension allowed the team to achieve an unprecedented degree of pixel-perfection.
Hopefully, we can get Stig to open up more about it in a later post!
Step 6: Test IRL – not just virtually
Once a template looks and acts as desired (in the browser at least), it’s time to test. At this stage, we usually imported the campaign into Campaign Monitor to run a quick Design and Spam test and/or tested in Litmus. If some clients looked off, we’d progress to live device tests. In addition to a few Windows and Outlook email client versions in VMware, we also stocked up a few different devices – particularly, mobile handsets – to test on.
Of course, more often than not these steps would bleed into one another, or be repeated – email coding and testing is seldom quick, clean or without incident. However, end results speak for themselves – a first batch of 10 robust templates, delivered on time and now ready to use in your account. Jump on in and try your hand at creating a unique email design – if we hadn’t mentioned it here, the coding and testing behind the templates would likely never have crossed your mind.