If you missed out on the first post, you can check it out here. In the first post, we discuss common problems that occur when creating HTML emails and their solutions. In this post, we will look at interesting problems that were more unique to our new email designs at Rigor.
Note: This article is Part 2 of a 2-part series
Uncommon problems and our solutions
Rigor’s web application is built on Rails, and we send our emails via SendGrid’s API. This combination allows us to write our emails within the app and render variables before SendGrid delivers the email. We send reports with data tables, alerts that rely on instant communication with our app, and notices containing links that are dynamically created for our users.
This all sounds great (and it is!), but it complicates the typical method for testing HTML emails both locally and on web platforms like Pardot, Litmus and MailChimp. Here’s some of the unique problems we ran into and how we solved them:
Modern web browsers are not a good test environment
To preview our emails as we go, we use the letter_opener gem combined with some pre-generated dummy data JSON files (for emails that include data tables). This process allows us to render emails in our local browser that rely on application logic. The problem? The latest version of Chrome is not a good representation of how our emails will render for our users.
To combat this problem, we use Pardot’s email preview engine provided by Litmus. Here’s where the process gets a bit tedious. Since we can’t copy + paste the raw code from Sublime (due to reliance on application logic), we use letter_opener to render it locally. We can then view the page source and drop that into Pardot to test it across clients. This gives us a good representation of how all different email clients display our email markup.
After some testing in Pardot, we push the emails into our staging environment and test them there. We send staging emails to a variety of clients, including multiple Gmail accounts, Outlook.com, Outlook for Mac, Apple Mail, Mail on iOS, and Outlook on iOS. For one more layer of tests, we view the emails in Gmail in different browsers (since each browser will render them differently).
As you can see, it’s a rather long process. But it helps guarantee a smooth deployment for these new emails so that every user views them how they are intended to be viewed.
Outlook adds margin-bottom: 20px to
Our new redesign for alerts and reports includes a large failed indicator. It’s a single line of text that is vertically centered in the circle, but in Outlook and Yahoo the vertical-align was being ignored. Here’s what our FAILED Alert should look like and how it appeared in Outlook and Yahoo:
Outlook & Yahoo’s rendering
Instead of using<p> , we tried placing “FAILED” inside a<span> so that we could style it, but that led to another issue. Outlook wouldn’t recognize the<span> tag for vertical alignment within the<td> and the<p> tag added margins that we didn’t want. So, we decided to use a<strong> tag, which was recognized by all email clients and got the proper vertical alignment. Here’s what the nesting code looks like for the finished product:
table > tr> td > span[ring styles] > table > tr > td[valign middle] > strong
Anchor tags don’t make great buttons
So, I lied when I said to put inline styles everywhere. The one exception is when you are trying to create a button with pure CSS and not an image. Outlook 2007, 2010, and 2013 can’t handle padding on an anchor tag. Your button text starts to look like Indiana Jones when those spiked walls are closing in around him (except in this story Willie doesn’t save the day).
Outlook padding removed on anchor tag
Outlook forces left-align on
text-align: center on a<p> tag was the biggest waste of time. We initially used<p> tags for text because we wanted to add a media query (to adjust thefont-size to 14px on mobile devices), but we ended up using<span> tags for text and centering on the parent<td> . This guaranteed the center alignment we wanted on all email clients.
Slim parsing error adding random letter spaces
Avoid SLIM and stick with ERB: We use slim-lang to make writing our HTML less tedious and much faster, but we quickly learned that SLIM should be avoided with emails. Our Set Password and Reset Password emails were written in SLIM for convenience, and they were the only two emails in this redesign that continued to have complications. Random spaces were rendered between letters throughout the email. The spaces were not there in the code, and not even there when rendered locally in Chrome, but appeared when testing emails through our staging environment. See if you can spot the spaces (*hint: there’s 2):
It turns out that there was a SLIM parsing error, so a quick conversion to ERB fixed the issue.
Long URL breaking the layout
Test long URLs. It’s rare, but some of the URLs that get sent can be pretty long. If a URL gets too long for the width of the body, it will increase the width of its containing cell, making the email look something like this:
To fix this issue and handle any length URL, we need a couple of CSS properties and some basic math. The body of the email is 600px wide with 20px of padding on each side. Then, the grey well that houses the URL has 15px padding on each side. That’s 70px of total padding. First, we set amax-width: 530px (600px – 70px) to the containing<td> of the URL. Then, we handle the word wrapping with the CSS propertyword-wrap: break-word . This technique can be applied anywhere you anticipate long strings of text without spaces.
Some final thoughts
We came across many issues during our redesign process, but we’ve highlighted those that we found uncommon or particularly quirky. Hopefully email clients will continue working to support modern CSS and coding standards, but in the meantime we offer our discoveries and debugging tools to save others some effort.
We’re excited to be releasing these newly designed emails, and we look forward to more feedback to continue improving our users’ experience.