Mark Robbins: Interview before WebExpo about Interactive E-mail

Can you imagine coding newsletters without using the <table> tag and inline CSS styles? Or using modern CSS3 technologies? Or using SVG’s? Sci-Fi!

Well, my friends, it is possible. It’s not always easy and straightforward and you also have to do at least one thing: go to see Mark Robbins’s lecture at this year’s WebExpo Prague. Mark spends a lot of time thinking about how to trick email clients using progressive enhancement techniques and how to shed some light onto the dark age of newsletter coding. The following interview is also an invitation to Mark’s lecture. And I bet I know where I will see you on September 23rd.

Hi, Mark! The first thought that came to my mind when I was going through your work was: I don’t believe it! :) It has been a long time since I coded the last newsletter template, but I remember people still use a lot of old-school clients such as Outlook or Gmail’s web version. And at the same time, you talk about interactivity, shops in newsletters, latest CSS3… What’s the trick? Could you sum it up in one thought?

Really it’s all about targeting the email clients where it works and adding a fallback for where it doesn’t. These things I talk about won’t work in Outlook and some won’t work in Gmail either but the vast majority of users will see them.

From a web point of view it’s like writing code for the latest version of Chrome while also considering that 6% of your visitors are using Netscape 4.

In your WebExpo’s presentation summary, I see that we can forget about the fact “that you have to code email like it’s 1999 and everything has to be styled inline and built with table layouts”. Is it really possible to remove inline styling and <table> tags when dealing with Outlook?

Since Gmail made an update last September, over 95% of emails opened now support embedded <style> block, including Outlook. It’s still best to include some basic inline styles to cover that other 5% but most of it can now be moved.

For <table>s it’s 94% that work without them. And only Outlook holding us back. Most email devs are using conditional comments in their code these days so the tables will only appear in the code for Outlook, and I’m working on a project currently that removes 100% of tables but still rendering fine in Outlook.

I like the idea of the API I saw in your product called Rebel. However, isn’t it a bit limiting for devs to choose from ready-made templates only? Most of the clients I know (and designers too) want to design their own custom templates.

Through our API we offer a huge amount of customisation, down to every individual element in the interactive components. We also allow custom HTML to be added by our customers. And we have a new update coming that will allow for basically any email layout to be created via nothing but JSON.

How does Rebel work together with existing newsletter workflows and tools like MailChimp?

We sit alongside the ESP’s, we generate the email code and export it as an HTML file. This can then be uploaded manually or in some cases passed automaticall into the ESP ready to be sent. Once the email is sent we collect analytics on every interaction in the email, these results can be viewed on our dashboard or integrated directly into your existing software.

And the last question: I’m glad you are talking about accessibility in e-mails. It is related to my ongoing WebExpo’s talk about accessibility code patterns. Will you have time to discuss this topic in your talk?

Last year was the first time I’d really heard any talk about accessibility in email, but now it’s a hot topic in the community. I’m doing my best to spread the word along with a few other great email developers. I will be covering it a little in this talk but I’m also working on a full talk about accessibility in email for another time.