Testing Interactive Email

Cyrill Gross

Presentation held at “The Email Design Conference” by Litmus, London 07/26/2016. This post is written in English, same language as the presentation itself was held. Simple screenshots are not sufficient when testing interactive email. Do popups open after clicking buttons? Are forms properly submitted? Is it possible to browse an image gallery? Testing of complex email including cutting edge features requires a new approach – without your budget skyrocketing. And it starts before the first line of code is written: by analyzing your audience and popular email clients among them. View and download the slides of my speech on SlideShare.
Testing of “classic” marketing email is comparably simple. Services like Litmus or Email on Acid help us to easily validate the correct rendering on all major email clients. But with the dawn of interactive (or kinetic) email, a new problem arises: Testing them. Daily changing content, image galleries with zoom view, live data feeds, animations and (pre filled) forms requires far more testing than just the review screenshots of its rendering. Keeping limited campaign budgets in mind, the challenge gets even bigger. We need a new approach. Something like… Chuck Norris! But wait – Chuck Norris does not do email marketing. Knowing your audience is key for building and testing interactive email. So we need another way. One that starts far before the first line of code is even written: By knowing our audience. We need to know who is reading our emails. And especially on which clients. If we have a share of 75% Outlook, what is not unusual in a B2B environment, we can’t simply forget about going interactive. But in a B2C market with Apple devices (iPhone, iPad, Apple Mail) reaching a share of 50% and more, our innovative features will reach the majority of our readers. Go for it then – just don’t forget a proper fallback for anybody using static clients.  

A Generic 5-Step Testing Approach

For testing interactive emails, like the interactive advent calendar, I follow a 5-step approach:
  1. Use a support matrix
Know what feature is supported by which client. This helps you to decide which features you can use for your audience. A good support matrix is provided and maintained by Fresh Inbox here.
  1. Write testable code
Keep testing in mind when you write the HTML code for your campaign. Your code will be tested and that bugs will be found is inevitable – there is no such thing as bug free software. The better you structure your code – indentation, comments, grouping elements – the easier testing and especially bug fixing will be. Let alone looking at your code again half a year later.
  1. Test in a browser first
Before you upload the code to your ESP, test it in a browser. Code inspector tools allows to directly try out changes in the HTML if you find something that does not works as intended – just don’t forget to copy it back to your source file before refreshing the browser. Tip: Use a WebKit based browser (Chrome or Safari) as most email clients use the WebKit engine to render HTML email.
  1. Use Litmus Builder
Once your code works as you want in the browser, copy it to Litmus Builder. Its instant preview function allows you to easily test and validate the elements of your interactive email. You can easily check / uncheck your punch card checkboxes / radio buttons, delay an animation or start it at a certain keyframe in the source code and immediately validate it in the instantly generated screenshots.
  1. Do real device testing
As if a fragmented bunch of email clients wasn’t enough, the rendering and support of HTML/CSS varies even among platforms, vendors and versions. Especially in the Android ecosystem, the vendors tend to modify or completely replace the native Android email app. And even the native one is far from being consistent over the versions. If you do not have a stack of devices available for testing, check if there is an Open Device Lab nearby. ODLs provides devices for testing on site. If there isn’t one in your city, you’ll probably find partners to set up one and share the resources required. One more really helpful resource to consider: Friends & Family. Your (grand-) mother might be the best person to test your email. If she is able to understand how to interact with your interactive email, probably everybody does.[1] And usually not everyone around you is using the same type of device.  

Additional, Specific Approaches

Use JavaScript Yes, seriously. But only in the browser view of your email! The browser view of your email provides a fallback for static clients that almost comes for free. The popup that opens in the email on interactive clients can be triggered by an anchor tag target passed through to the browser view of the email in the URL. Use JavaScript to detect if the anchor tag is there (by using document.location.href) and trigger the checkbox or radio button that controls the popup. The same approach can be used to test the interaction by using the browser console. Simulate klicks, trigger checkboxes and manipulate animations easily directly in the browser. This is especially helpful to find potential impact of your ESP (some ESP modify your code when sending the email or delivering the browser view). But be careful: Make sure the JavaScript block is included in the browser view ONLY. And ONLY there. Use the condition syntax of your ESP, something like this: [IF isBrowserView()] <script type=”text/javascript”> … </script> [END IF]  Otherwise you risk to trigger spam and phishing filter on a large scale. Compress Time If you need to test an email that includes time dependent elements, especially daily or weekly changing content that is dynamically loaded, you are most likely in a situation where you won’t have the time to test in “real time”. In this case, compress time in scales. Compress days to hours and hours to minutes. For example, the day of the month can be represented by the minute of the hour: Test 31 days in 31 minutes. Another way is to use the anchor tag in the URL of the browser view as described above. For example, add “#day02” and load the elements of this day by JavaScript. A simple yet efficient way to test the changing content.  

Takeaways

Testing interactive email - takeaways   View and download the slides of my speech on SlideShare.   [1] Your father, grandfather, sister or brother might be as valuable. As well as most of your friends outside your organisation. Just make sure it’s somebody with little to no knowledge of marketing email and without your business insights. But somebody but with a true end user perspective.
Zurück zur Übersicht