Hey guys,
We started designing our E-Mail Master Template in Stripo a while ago and after exporting the HTML we added the "Marketo Syntax", so all the modules and elements inside the template can be picked and edited by our staff inside Marketo.
We ran into multiple issues while designing, but most of it could be handled effectively (thanks to the Marketo community here we could fix some of the issues where we didn't have a fitting solution!). Now where the Master Template is set up and most issues were supposedly fixed (especially Outlook Buttons!!), we are designing new mail campaigns inside Marketo.
While doing so, we had another rendering issue that we found in Litmus. This time the culprit is not Outlook, but moreover Gmail on iOS Devices: The rendered screenshots is looking like the elements are way off and we can't find the reason for this.
When testing on my own device (iPhone 11 Pro, iOS 17) i couldn't recreate this issue though – then I found out that Litmus is using an older iPhone for its "G-Mail iOS" rendering (I think it was an iPhone SE on an old iOS Version ... 13 or sth ... so an old Device running on old software). We have also noticed that on Android devices, some elements like the Logo in the header section is aligned centered on Gmail, where it should be left-aligned (ironically that was an issue with our old template on Outlook before and one of the reasons we switched over to Stripo for E-Mail designs). In our previous E-Mails we created with the new template none of these issues occured.
The questions I've asked myself after finding this out:
- What could be the reasons for this rendering issue and other rendering issues we might have in Gmail? Do we have an error in the code? Is something inside the code breaking the visuals for Gmail?
- How do you handle rendering issues in general? Especially if these are not major ones, but only occur on specific devices or E-Mail Clients? I guess Gmail is too big to ignore, but in this case I'm not even sure if this affects more iPhone users or only iPhone SE users (with an outdated iOS) are affected by this. It seems like an edge case to me, but I still wanted to ask the community about how they are handling rendering issues on their side. Maybe you can share some tips or best practices with us - and if there already are discussions about this that I might have missed, you can also link them here 🙂
I've attached to code for the e-Mail here (just switched out the CTA links to google):
https://privatebin.auxaws.de/?f960fde75a643a50#CmiWhvReLEjnYrPaotYgmVbDc1yHgyfTHmvrcNwNGm7H
Thank you and best regards
Artur
The questions I've asked myself after finding this out:
- What could be the reasons for this rendering issue and other rendering issues we might have in Gmail? Do we have an error in the code? Is something inside the code breaking the visuals for Gmail?
Answer
I think this might have something to do with missing "min-width: 100%" on a few of your tables. I see in the code that there are a lot of "width:100%" and "width:600px", but no "min-width: 100%;". I might look for places where you've got the width set to 100% and also set a min-width of 100% b/c it looks like the issue that you're having here is that the modules aren't filling up the screen. Look to add this style inline on any <table> that you'd like to display full-size. I'd normally put it on the table just inside the modules but the architecture of the container/modules I use is a little different than yours - here's a snapshot for context:
- How do you handle rendering issues in general? Especially if these are not major ones, but only occur on specific devices or E-Mail Clients? I guess Gmail is too big to ignore, but in this case I'm not even sure if this affects more iPhone users or only iPhone SE users (with an outdated iOS) are affected by this. It seems like an edge case to me, but I still wanted to ask the community about how they are handling rendering issues on their side. Maybe you can share some tips or best practices with us - and if there already are discussions about this that I might have missed, you can also link them here 🙂
Answer
I think this question deserves some context, so pardon my short rant on this topic - I hope it's helpful 😀
To handle rendering issues, we use a rendering service (Litmus or Email on Acid are pretty popular). Both allow you to create a HTML-based version of a sent email to do some troubleshooting/rendering to the overall code inside the tool to help identify the issues in a way that you can make a change and see the result without sending a bunch of new emails. This makes the discovery process a little more streamlined and then once we've identified a fix, we'll figure out how to migrate that back into the HTML (usually updating the template HTML in some way to update modules/css/architecture).
That's the straight-forward answer -- the more elaborate answer involves answering the question "why are we needing to troubleshoot in the first place?". Enter the rant....
Like most things that anyone builds, foundation plays a key role in downstream success or failure -- my favorite term for this is "future proofing". There's only so much you can do to "fix" an email (or a building or a car ...) that's not built right in the first place. The story usually sounds similar to yours - "when we started things worked fine, but then we made some changes and everything went sideways fast and we can't understand the 'ghost in the machine' that's causing the issue(s)". In my experience, this is the kind of story that suggests a good look at the foundation as a place to start troubleshooting. In this case, after having a look at the code you shared, there's lots of room for improvement compared to how industry-leading emails are built in Marketo (and I'd venture to say anywhere else as well). I haven't seen an "easy to use" Email Builder tool like Stripo that actually puts out good "future-proof" code. Generally the trade-off with these kinds of tools is that they're easy to use but they're rigid and the output does exactly what you ask it to and nothing more. You can also get some email development work done cheaply using this approach, but again it starts to fall apart as soon as the future starts to happen.
In my experience coding Marketo emails over the last 10 years, the solution that's done me the most good in the long run is to blow it all up and start over again rather than trying to fix what's broken. Email is a really fickle beast and small errors or cracks at the foundational level make their way upstream in really unpredictable ways. Also the nature of email is that it's ever-changing and little updates to ESPs constantly test code that was written at-a-time for-a-purpose and generally lead to some kind of failure anyway. In short, I really can't emphasize enough -- you get what you pay for in email code -- that's been true over the last 10 years and I think it'll continue to be true for the next 10 as well.
I do understand the business case for spending on a tool like Stripo (or any of the other ones out there) but all too often I've seen here in the community how those end up creating problems that the team can't figure out how to solve and just creates a liability for the sake of ease-of-use for the end users (your team). I think these tools portray themselves as "easy-to-use" (and they are) but what they don't tell you is that under the hood they aren't that good -- but then again if you had a great email developer to work with you wouldn't be looking for an "easy to use" tool in the first place, and that is how they get cha' hooked. Not my favorite tactic, but the plus side of it is that I get to have conversations like this with folks in the community more often than I would in the absence of these tools and we get hired pretty often to fix these problems so it's job security is a way 😉
A better future (aka "the intervention"): I write this part not specifically for you, but more broadly for anyone who finds themselves in your shoes in the future --
Audience: "We bought an 'easy-to-use' 3rd party email tool and now we can't use it b/c everything breaks and we can't fix it
Step One: Be willing to learn from your mistakes and start over. "There is no sense in throwing good money after bad" as the saying goes and sometimes you've got to take your lumps and be willing to stop the bleeding. It usually seems like alot more budget/time up-front to get things done the right way, but in the long-run you'll usually end up paying less in maintenance and additions when you hire an experienced professional. Make the harder choice now with the budget and save your future-self the trouble, time and money.
Step Two: Start over. Find an experienced Marketo-specific email designer and hire them. Don't fall for a team that does "all the things" or a creative agency that "designs email". What you need is a time-tested Marketo expert who can anticipate and advise you along the way to identify all the things that you might not be seeing "in this use-case or that one". You want something built for the future, you want someone who has been-there-done-that and has a proven track record. I know it sounds like a high-bar, but that's the reality of it with Email, and more specifically with Marketo Email. It's maybe counter-intuitive to think that the more you pay for email development, the better it is, but it's certainly a place where cheaping out now will get you running back to the bank to pay someone to fix it later. @Jo_Pitts comes to mind as that kind of person here in the Marketo Community. Have a look around and see who is volunteering to help folks solve these kinds of things in the Community and reach out to one of those folks, trust me, your future self will thank you!
Step Three: Make sure you've got appropriate lead-time to get something in play and set yourself up for the future. Most times this looks like getting ready well before you need to crank something out for the next big thing. It can be helpful for an expert consultant / email SME to audit your current inventory of emails and look at a way of bringing those all together in one "easy-to-use, Marketo-native" solution and perhaps even one who is willing to work with your team to facilitate training and enablement for your users. Most times it's just a matter of learning the tool and Marketo isn't the most intuitive to figure out when you don't have someone with experience leading the charge. With a little help and good documentation, I've seen teams go thru this process and use the exact same "universal template" for years to come (our longest-standing client setup runs 7+ years to date on one template!).
I hope that some of this was helpful for context, please let me know if you have any questions or if you run into any issues with the "min-width:100%" thing - I'd be happy to have another look at your setup once you're able to get that into play and do some testing. And if you made it this far -- long-distance-high-five!
-Dave
Hi Dave,
first of all thank you for your detailed reply 🙂
Regarding the issue we have in Gmail:
I've tried the setting you have suggested: Wherever we put a width:100% inside a table, I've added a min-width:100% inside the <style> tag. On the first sight everything looks good and it seems that the issue has been fixed, but if compare it to the other versions in Litmus, it seems that Gmail isn't making the E-Mail responsive anymore.
So whether on iOS or Android, it looks like in Gmail the Mail is rendered as the desktop version:
I've attached the edited code here:
https://privatebin.auxaws.de/?1a3ec39ca427ef74#DJbBHzV4ae55kpdcaC4D4qftYWdNK4BLyHfzQpRzDaqg
Regarding your answer on how to handle rendering issues/ email design & development in general
Thanks again for your valuable input! I really appreciate the useful tips and sharing the experiences you've made and also the ones you've seen others have made. To be honest, while reading your answer I've resembled many of the things you mentioned from our own experiences ... another thing is, that even if there is a professional Marketo Designer supporting us in creating templates, there can still occur technical issues making E-Mail Designs barely unusable on specific ESPs . For example I know that there are issues with sending E-Mails to T-Online – if you do some research you'll quickly find out that there is currently no solution for this, as neither T-Online nor Marketo are taking the blame, usually saying the other party is responible for the E-Mail Code breaking while being delivered (my final conclusion was that it has sth to do with T-Online's anti-spam filters btw).
I guess we will have to really think this through and should think if an E-Mail Builder is really the right choice - or maybe if it would be better to have a professional take care of the whole e-mail design aspect. What i have learned in any case: In E-Mail development there seems to be no 100% solution for almost anything 😄
Best regards
Artur
.png)