Now that we’ve covered the foundational pieces of mobile-first email development, we need to consider analytics. Knowing where your subscribers are opening your emails gives you a huge advantage when it comes to developing emails that ask subscribers to perform an action you want from them.
Having insight into your own analytical data will help save time as you focus on email clients used by the majority of your subscribers. Looking at your analytics, take note of the email client in which the majority of your email opens occur.
Why look at your email data
Many of the popular email clients have relatively good support when it comes to CSS. At the very least, they have well-known and documented ways to work (hack) around common rendering issues. Things get a little more hectic in the not-as-popular email clients—like Lotus Notes or international clients like GMX.de. Many of these clients can require a good deal of extra development time to support.
That’s not to say you should completely ignore certain email clients. Rather, the data should help guide your decisions as to what the acceptable threshold is for the differences in rendering.
The CSS differences between email clients
As you know, there are a lot of email clients available. When starting to use the mobile-first-email-development technique, it’s helpful to separate the email clients into three groups to help you decide on the best approach to use.
I like to consider these groups as level 1, 2, or 3, with level 1 being the easiest to code for and level 3 being the most difficult. There are certainly many more email clients out there than what are listed below. If you don’t see one mentioned, then you may need to do a little research and testing to determine in which group that email client best fits.
Level 1: The top 10 email clients (coding level—easy)
Thanks to Litmus’ Email Client Market Share analytics, we have a good idea of some of the most popular email clients being used today. Luckily, these email clients are also some of the easier ones to code for when it comes to general email development.
While most of these clients have great HTML/CSS support, what actually makes them easier to code for is that they have well-documented workarounds for common development issues. When it comes to mobile-first, coding for this group is definitely the easiest.
Level 2: Weird and quirky email clients (coding level—intermediate)
Yahoo! Mail: The mobile Yahoo! Mail app on Android will also remove embedded styles when they are placed in the <head> of the email.
You may notice there are a few email clients from level 1 in here. In fact, the jump up to level 2 isn’t too big of a leap. These email clients generally have good support for HTML/CSS, but have a few oddball things happening behind the scenes.
GANGA is the main reason for mobile-first development due to its stripping of embedded styles. However, there is one other quirk for GANGA that can cause some headaches: it doesn’t support overflow hidden, which is problematic for trying to show/hide content.
Another big hurdle to overcome is certainly knowing how to code for Outlook. The good news is that this is one of the most documented email clients when it comes to development hacks. The reason for Outlook also making this list is mostly due to techniques needed for other email clients can cause issues in Outlook.
For example, a standard technique in email development is to use !important alongside the CSS property value to help override inlined styles. However, there are certain CSS properties that cause AOL, Freenet, and Yahoo to remove the !important if there is a space between the value and the !important. The “fix” is pretty simple—remove the space.
Unfortunately, this causes issues because removing the space now makes the property invalid in Outlook. Again, this “fix” is also simple. By targeting Outlook with conditional comments, we can add the space back in. This can get out of hand quickly when you start adding more complex styling to your emails.
Hopefully, now you can start to see why these email clients are a step up in difficulty.
Level 3: The most difficult email clients (coding level—advanced)
IBM Notes 9 and Lotus Notes 8.5 could arguably be considered level 2, just slightly more difficult. The majority of techniques that work for levels 1 and 2 generally do well with these email clients. However, more advanced techniques will most likely cause unexpected errors with both of them. If you are developing for earlier versions of Lotus Notes, then you should consider those versions level 3 due to a longer list of non-supported HTML/CSS.
Aside from IBM and Lotus Notes, the rest of the email clients all have one thing in common: they completely remove any !important in your CSS. There is currently no hack that will prevent the !important from being removed from these email clients.
As you can imagine, losing the ability to override inline styles makes mobile-first quite challenging. However, with a little patience and planning, it is possible to develop emails that render consistently across all three levels of email clients.
Breathe deep and take it slow
Admittedly, if you’ve gone through all three parts of this series, it was probably a lot to take in. The good news is we’ll be diving into code examples in the next post. The bad news is that you’ll have to wait just a little bit longer to read it.
At this point, you now have the foundational knowledge to begin testing out the mobile-first technique. However, I do have a couple pointers for you to think about should you decide to give it a try.
- Analytics, analytics, analytics.Yes, it really is that important and worth pointing out again. If the top 10 email clients, as reported by Litmus, are the bulk of your opens, then don’t stress out about your email rendering perfectly in some clients, like Lotus Notes.
- Going back into an existing email build and trying to retrofit this technique can be very frustrating for a beginner.Start out on new builds. Once you’ve mastered the technique, you can then update older builds if needed.
- I highly recommend you start out small with one or two things first before moving on to a full-blown mobile-first email.Like any other technique, it takes time and practice to get comfortable with it. Don’t overwhelm yourself by trying to do too much too fast.
- And, the core to every email development technique … TEST, TEST, TEST.But you already know that.
In coming posts, we’ll walk through some real-world code examples to help guide you along. We’ll look at ways to change font sizes, text alignment and dive into making hybrid coding more efficient for mobile-first emails. In the meantime, get a good grasp on the five principles for this technique and start playing around with it to see how it can help your email responsiveness.