I built my first responsive email template in 2014 when I was just coming into the MOPs/Salesforce Admin portion of our programming and realized that my company’s marketing emails were NOT responsive.
Me being me, I ended up sitting through a free webinar put on by Litmus to gain the basic understanding of how responsive emails worked, and from there I was the go-to on the team for all things HTML and CSS. I fumbled my way through enough to ensure that our emails and custom landing pages would look good on mobile.
Side note: I did all of this because I had reviewed the open rates based on device and found that approximately 30-40% of our emails were being opened on mobile. That’s a pretty sizable chunk of people having to squint at tiny print on a small screen.
I am not an expert on this stuff at all, so I’m not about to sit here and break down how to do this – there are much better resources out there for that. All you need to really understand about this is that responsive emails are based on tables, as in:
That at least I understood having been big into building strangely elaborate personal webpages when in school. I wish I had screenshots of some of the work I did back then – it wasn’t terrible, all things considered.
For responsive emails these are important because you end up with nested tables – tables inside of table cells inside of tables. Tableception, if you will. (Is that joke still a thing? I use it a lot.)
And then on top of that, there are some special little tweaks you can make to the CSS itself to ensure that when the size of the screen shrinks, those tables all shift around into place, so instead of squished, you get stacked.
<– Like that.
So what does this have to do with Pardot??
In a few implementations clients have used one of the prebuilt responsive templates in Pardot and found that instead of stacking, their template just shrank down into a smaller version of the same layout.
For whatever reason this didn’t seem to happen in previews or even with all template layouts, but for this client it did, and I wanted to fix it. It took some digging. And by digging, I mean rewriting the code almost line-by-line to find the issue, but when I did find it, it seemed a little silly.
The key to that fancy table action above working is in the CSS that exists for that email, so before we even start adding our tables and rows and cells and tables inside of cells…we have our CSS classes defined. Think of those classes as references; later in the HTML tables, I can reference my CSS via the class name, and that is used to display the info according to that reference.
But what I found was a table referencing a class that wasn’t there. Simple mistake and simple solution – we just had to drop the appropriate class name (reference) in the CSS, and BOOM! We had a nice, stacked template.
So what happened??
It’s possible that the client made some small change during editing that removed that class. It’s possible that on that particular layout, the class just wasn’t included. I don’t know, but what I took away from that was to just check.
This is true no matter the platform. Any time you are using work or designs created by another source for mass consumption and reuse, just take a minute and review it. Become familiar with it. In a way, the HTML/CSS of your email templates is like a manual for a new gadget you’re putting together. It’s tedious to go through it, and wouldn’t we rather just slap the thing together and be done? Sure. But if you take that time at the beginning to introduce yourself, you’re more likely to find little hiccups. You know, before you start putting any real weight on the thing.