The Limitations of Interactivity and the Importance of Testing
For those of you who know me, have seen me speak at a conference or read any of the articles I’ve published you’ll know I’m a BIG fan of interactive email and I’m always encouraging others to give it a try. I’ve talked extensively about the benefits (driving conversion, more insightful analytics etc.) but what are the limitations?
Not every email client supports interactive email. At Rebelmail we class all email in clients in three buckets: Interactive, Limited and Static. ‘Interactive’ clients have full support of interactive email, ‘Limited’ clients have some limited support and ‘Static’ has no support.
This means 3 possible experiences could be had from one email, so design and UX need to be properly considered for each case. We create fallbacks for the interactivity, so whether a subscriber is viewing the email on an interactive, limited or static email client he or she will have a seamless experience. The differences between interactive, limited or static are often minor but still need to be as carefully considered as the rest of your email.
Each version should be a complete experience in itself.
Things like image galleries, tabbed and accordion layouts allow you to offer a lot more information in a much cleaner layout. Visually this means more information in less space, but it’s still contributing to the total file size you’re sending.
A couple of years ago Mallory Mongeon, Digital Marketing Manager at Email on Acid, wrote a great post titled How does email file size affect deliverability? In this post she advises keeping your HTML file size under 100KB, and we stick to that rule. Going much over this limit can mean your email gets cropped in some email clients and is more likely to end up in the spam folder.
Unfortunately, you won’t fit a full website into 100kb (I’ve tried) but you can still get a lot of content in there. If you optimize your code well, avoid duplicate content and reuse CSS it is possible to keep files sizes down.
If you’re skirting close to the 100kb limit, it’s wise to double check your files size after you’ve uploaded your code to your ESP, some may add extra code that will bloat your files size and push you over the 100kb limit.
Similar to file size, load times can go up sharply with interactive email.
The biggest offenders here are images. People will often use a large animated gif as a fallback to the interactivity. This may look good, but it’s also adding a lot to the load weight. Hiding an image tag will not stop the file from downloading, the user may not see it but the file will still download.
So, if you have a 500kb fallback gif which you hide and replace with 5 100kb images in a gallery, the user will actually be downloading 1000kb of images every time.
Think about trying to reuse content rather than replacing it.
There is a really good throttling tool built into Google Chrome to test load times. If you open your email in Chrome and enable this tool you can emulate the load time of a 2G, 3G 4G or any custom connection you can think of. There’s a good article on the google developers site to tell you more.
Probably the biggest limitation holding people back from experimenting with interactive email is time. It takes longer to design interactive email and much longer to code and to test. I’m afraid there are no shortcuts here, you have to put in the hours.
I know, because it’s what I do, all day, every day.