Creating a New Email Newsletter
I’ve been developing emails for the last 6 years, mostly for Pardot and Salesforce Marketing Cloud. As any email developer knows, developing for email means not relying on modern HTML and CSS, unless you’re using AMP for email. Plus, you have to develop for all of the quirks and inconsistencies amongst all of the email clients that you will be sent to. Sure, it’s easy to guess that most people are reading email in a modern email client like Apple Mail or Gmail, but there’s a fair number of people who are still holding on to their trusty Microsoft Outlook, so we still need to cater to those readers and add additional code to support those clients.
Recently, I was given the task to develop a newsletter from scratch based on a new branding campaign. I saw this as an opportunity to revamp our email templates in Marketing Cloud, which were created by someone else before I inherited them. Those templates had these issues:
- Using an old HTML Doctype
- Not optimized for mobile
- Not accessible
- Unnecessary and unused styles throughout
- Blocks that should be locked for editing were unlocked
Having completed the code audit, I thought about what was needed to improve and modernize the templates:
- Use the HTML5 Doctype
- Design for mobile-first and optimize for mobile
- Make all tables accessible
- Remove any unnecessary styles
- Create a flexible template but lock areas that shouldn’t be changed
Partnering with the design team, I presented these goals and impressed upon them the need to approach the newsletter with mobile-first top of mind. The design came in and the artboards depicted the layouts in mobile and desktop, giving me essentially two breakpoints, 480px for mobile and 640px for desktop. The 640px width is wider than the current newsletter with ample margins on the left and right. I had asked for more breathing room for the content.
The design included background images, which aren’t supported in Outlook, but I knew there were ways around that. Some sections had multiple background images. So how would I position them and would it still work?
I tried to implement the Bulletproof Backgrounds technique that uses old VML code with no luck. That code is intended for a background image that covers an entire area and not just part of it. So, I went to the emailgeeks Slack community and started a conversation there in the #email-code channel. Remi Parmetier took the code and changed a few things in the <v:fill> tag to make it work. Specifically, the origin, position, and size parameters.
<! — [if lt mso 16]>
<v:rect xmlns:v=”urn:schemas-microsoft-com:vml” fill=”true” stroke=”false” style=”width:640px; height:360px;”>
<v:fill origin=”0.5,-0.5" position=”0.5,-0.5" size=”90pt,90pt” type=”frame” src=”https://microsites.nielsen.com/web-assets/wp-content/uploads/sites/10/2020/12/top-corner-angle.png" />
<! — [if lt mso 16]>
One of the biggest problems with this code is having to declare a width and height in the <v:rect> tag. Notice that the width here is the desktop width of 640px and the height is a best guess, based on the content. That height could easily change.
One of the other things that I changed here was in the conditional code at the top. Instead of targeting all Microsoft Outlook clients, I decided to exclude MSO 2016 and Windows 10 Mail from having the background image. So instead of [if mso], I used [if lt mso 16], which targets any Microsoft Outlook clients below 16. The reason being is that background images don’t play well in Outlook when there is an image directly above it. So on Windows 10, I was losing the image that was above the background image. There’s no way to just target Windows 10 Mail, unfortunately, so I opted for taking out the background image for that client, which turns it off for Outlook 2016 too.
The new brand called for text links with animation on hover. Our primary color would animate a green underline across the bottom of a text link. This might work for email in desktop clients, but not on mobile or Outlook/Windows 10. We did some accessibility testing with the primary green color we chose and it failed on a white background, so I couldn’t use that as a consistent solid color for all text links. I also had to get a link solution that worked on three background colors; black, white and gray. It turns out that border-bottom and border-bottom-color don’t work in Outlook/Windows10, so I couldn’t use the correct styling for the links. I had to find another solution. So in the end, we decided to go with bold text with an underline.
The new design also included background colors that were black, white and gray colors. Initially, I didn’t see that as a problem, until I started testing. Then Dark Mode showed its ugly head and inverted colors and images in some clients, like the Gmail app for iOS. To be honest, I wasn’t completely prepared for what Dark Mode would do to the email template. In most cases, it didn’t negatively affect the overall appearance and readability of the email. I had read all about dark mode and implemented the proper code to allow it. The biggest offender ended up being the most important one. Since most of our organization is on the G-suite, we’re using Gmail as our email client. A good majority of users are also on iPhones. So when I looked at the email test on my iPhone in the Gmail app, I gasped at what I saw. Colors completely inverted and the background image looking horrible.
I reached out to the trusty emailgeeks community again only to find out that there’s no way to specifically target that client. If I utilize the media query for Dark Mode to turn off the background images and set colors, it will affect every Dark Mode client.
And this is the type of thing email developers face all the time. What is the expected ‘premium’ experience and what is the ‘acceptable’ experience? I created a checklist of all the clients I was testing against. Out of 30 clients, only the Gmail app in dark mode on iOS was presenting the greatest issues.
I tried a few different things with the dark mode media query, but every time the Gmail app rendered the same. I tried hiding all of the background images; I tried assigning background colors to the sections that were supposed to be black with an !important declaration in that query and still got the same results.
I spoke with a colleague about this and she has gotten so used to reading emails in dark mode and seeing all of the inverted colors and quirks that it’s become common to her and perhaps to other people who have also come to accept email in dark mode to be what it is and what the device is doing.
So one device, one client, out of 40,000. That’s actually not that bad, is it?
I’m using web fonts in this email, which only really render on iOS devices. That’s another example of the ‘premium’ experience. The rest of the email clients display Helvetica or Arial, readable fonts, but not the intended font.
If you have a Litmus account, then I strongly recommend that you get the Chrome extension. Sure, you can build and test within Litmus builder, but if you want to move quicker, you can open your HTML email in the browser and use the extension to test the email previews. Each time you make a change and save, the email previews refresh. This really helped me build each section of the template quickly and test constantly.
One odd thing that happened along the way was the email previews I was seeing in the browser were different than what I was seeing in Builder. Someone from Litmus told me that I should turn off the Inline CSS option in Builder and that did the trick. I was already inlining my code anyway.
Finally, I had to take the HTML code and develop blocks and a template for Marketing Cloud. Salesforce help on making templates is pretty minimal. Sure, they provide their own templates, some blank, and some that have dummy content with different layout blocks.
One thing that I discovered is that you can use your own HTML template but if you want to allow users to drop blocks into it, you’ll need to include a Content Area. In the HTML template, you can click on Insert Code Snippet and choose the Content Area option. This will generate a <div> that has a data-type=”slot” with a random data-key value and a data-label. The data-label can be whatever you want it to be. These content areas will appear in the editor view on the right and will be marked with their data-label. Since content areas can be locked, you can add more than one to define areas that are locked or unlocked.
Looking at the design, I identified all of the areas that were candidates for blocks and which ones would be locked or unlocked. I also had to decide what type of block each section would be. For the sections that are locked, those ended up being HTML blocks. Blocks that had to be edited ended up being text blocks or freeform blocks. Text blocks are pretty flexible in that you can still enter a lot of code in the HTML tab. The danger with text though is that if a user selects all of the text in the Content editor tab and deletes it, they also delete the code that formats it. So, you have to train your users how to copy & paste text and warn them about formatting. Ideally, every user would have some basic HTML skills, but that’s not the case in my organization.
I needed to use the Freeform blocks for the blocks that included the background images. I had to have the code in there but I also wanted to make the content editable.
I then started from the base HTML template I created with the Content Areas and added the blocks I developed in order from bottom to top, locking the content areas that needed to be locked and then testing with Litmus again. I was pleasantly surprised that all of the code work that I previously did held up.
With all of the major blocks developed and a tidy new modern HTML template in place, the next step is to test on actual devices. I have a small collection of physical devices and a few email accounts to test on: Gmail, Yahoo, Outlook.com, and others.
Once the template and the blocks are released and users start building their own emails, I’m sure I’ll have to handle other problems that might come up and create additional blocks and edit existing ones.
There are other things that I want to explore, like social sharing for content, interactive elements, and animation. Slowly, we’ll get there on email, but we’re way behind the modern web. I know the resilient email community will continue to champion new ways to deal with old problems. It’s a rewarding challenge.