Last week we told you about Microsoft’s jump into the mobile email landscape with their release of apps for both iOS and Android that have a fresh look and a sharp focus on important emails.
But how do these new releases stack up when it comes to rendering? We decided to dive a little deeper into the clients and find out how their rendering engines might affect email design. We ran both the iOS and Android version of the app through a series of tests to see how they handled some of email design’s most common challenges.
Everyone who’s built an email knows that it’s difficult to write markup that follows modern web standards and get it to render well across all of the commonly used clients. For years, one of the main culprits forcing us to stick with table-based layouts has been Outlook. So we were interested to see what was possible with these newly minted mobile versions of the Microsoft email client. We tested two different types of standards-based layout, one using HTML5 semantic elements and another utilizing divs.
First through the battery was a basic layout consisting of the HTML5 semantic elements <header>, <section>, and <footer>. In every case of this test Outlook didn’t recognize these elements as being block level, nor did it correctly apply basic styles, such as background and font color. For the next set of tests we scaled back expectations a bit and simply used divs to try and achieve the same basic layout. This time around Outlook successfully rendered the divs as intended.
While it’s disappointing that semantic elements don’t render correctly, it is a step in the right direction that there’s now a version of Outlook in which a non-table-based layout can successfully be achieved.
When writing the tests for responsive layouts, there were two things we thought it was important for Outlook to be able to handle: the first being the ability to successfully understand and render media queries, and the second being the ability to rearrange the layout using display types. Both worked in every case tested. We were able to do things as simple as stack items using display: block; and as complex as completely rearranging them using table-caption, table-header-group, and table-footer group.
Both media queries and rearranging the layout using different display types worked as intended in the most common-use cases. As part of this test, we also tested how well internal stylesheets worked. In all test case scenarios they performed flawlessly, leaving Gmail as the sole client requiring us to continue the use of inline styles.
One of the big differences between this new version of Outlook and older Office-based versions is that images display by default. This is also a departure from how the native Android client functions. In every case we tested, Outlook successfully displayed the email with images displayed on open. While this is a positive for email designers, it will also be interesting to see if this affects Android usage numbers, the same way it did Gmail, if Outlook mobile usage picks up.
Animation & Video
Also differing from other versions of Outlook, animated GIFs displayed perfectly in this new mobile version of the client. Whereas in Office-based versions only the first frame of a GIF is displayed, in Outlook mobile the entire animation ran without any noticeable issues.
Not to be held to just animated GIFs, we wanted to test some newer techniques of delivering animation and rich content. So in addition to GIFs, we tested CSS animations and HTML5 video.
Our tests of CSS animation included both standardized and -webkit prefixed versions of animation and @keyframes. While the standards version of neither property worked, the -webkit prefixed version worked across all clients, in tests ranging from opacity changes to moving objects with translate.
While CSS animations worked without issue, HTML5 video was an entirely different story. We tested HTML5 videos with autoplay both on and off and in both cases the video didn’t even appear to render on screen. HTML5 video seems to be a non-starter with this client, and due to not being able to separate Outlook mobile from other webkit clients, it may rule video out entirely if Outlook mobile becomes widely used.
The ability to show images on open and the added ability to display animations using both GIFs and CSS is a huge net gain for Outlook. However, the lack of support for HTML5 video may render that type of rich content unusable should Outlook gain a large percentage of market share.
By using progressive enhancement, we can bring many of the newer capabilities of HTML5 and CSS3, including video and interactive elements, to the world of email design. Doing so does however require the ability to differentiate the less capable clients from the more capable. The two most common approaches used to make this distinction are MSO conditional comments and -webkit prefixed media queries.
Webkit Media Queries
For this test we applied alternate styling by targeting the client with -webkit-min-device-pixel-ratio:0. This is a commonly used tactic to distinguish webkit from non-webkit clients. In our testing, Outlook rendered the styles within these media queries, and confirming that this targeting can be used to successfully lump this client in with other capable mobile clients.
<!- -[if mso]>
Although not surprising due to the obvious difference in rendering engines, one of the most interesting findings of our testing was that this version of Outlook doesn’t recognize itself as Outlook. Content that was placed inside of <!–[if mso]> conditional comments was not displayed and content placed within <!–[if !mso]> was displayed.
Outlook Mobile seems to recognize itself as a webkit client but not an mso one. While in most cases, due to its consistencies with the iOS and Android native clients, this doesn’t seem to be an issue. But there are a few cases where this may cause concern, the biggest of which is being unable to distinguish this client when using HTML5 video.
One of the newer methods for improving typography, web fonts allow you to include branded and custom fonts in email clients that support it. For our tests we applied web fonts using both the @import method and using @font-face, and in both cases the web fonts rendered without issue.
Much like its desktop counterpart, on all platforms tested, form elements were rendered as unusable text elements, making them a no-go if you have a high percentage of Outlook users on mobile devices.
We tested four versions of Outlook across iOS 8.0, Android 4.4.2 Stock, Android 4.4.2 Stock over Exchange, and Android 4.4.2 on a Samsung Galaxy. Although there were a few exceptions, all in all the rendering capabilities seem to be a vast improvement from what we typically see and expect from Outlook. If this is a hint at the direction Microsoft is looking to head, it seems to be a generally positive one.