The Most Frustrating Debugging Experience I've Had All Year
Read this tale of woe and 57 iterations when debugging an email build. Maybe it can help you avoid the same fate.
Join the DZone community and get the full member experience.Join For Free
Building emails sucks.
Last week, I was tasked with a project. “We’re rebranding, our emails were built 3 years ago and they look janky. Let’s rebuild!”
“OK, I can do that. But emails suck so I’m def not building that sh*t from scratch.”
Our designer built an email template in BeePro. Visual email builder, exports to HTML, promises that everything will work on all email clients, on both web and mobile, and look good no matter what you do.
Wonderful. Look at us being a responsible team and avoiding all the hard finicky stuff.
I look at the template and think “OK, central body area, some optional pre_body stuff, some optional post_body stuff. Body made out of a few basic widgets.”
What we built in BeePro.
To avoid bloating up our codebase and make it easier to build many different emails that look just like this, I cut it up into a few Ruby on Rails partials. A basic layout for the email with hooks for pre and post body stuff, a header partial, a title partial, an information row partial, stuff like that.
All my partials were built through careful copy and paste. Inspect the exported HTML, cut out a relevant section, fill dynamic info with ERB. Easy peasy.
Here’s what the emails looked like in my test environment. Opening as a browser tab instead of sending via SMTP.
How the email looked in test.
And here’s what that same email looked like in Gmail when my QA team tried it out.
Same code, but in GMail.
OK, breathe, zennnnn. We can fix this.
The problem is that BeePro builds weird HTML that I had to tweak a little and that email clients take out some of your CSS. Sometimes they tweak HTML to make it more correcter.
You see, BeePro doesn’t think in boxes like you and I do. It thinks in full-width divs and fakes containers.
BeePro fakes containers.
Tweaked a few things, moved some CSS around, copy pasta'd some more HTML. Fixed the email, yay!
Looks great in Gmail on the desktop. Surely it’s fine everywhere.
Now here’s the thing, you can’t inspect elements in the Gmail app on your phone. You can’t even tell what’s rendering, why things are doing what they’re doing, or where any of the elements are.
A-ha! I’ll open Gmail on my computer, set my viewport to iPhone size, and debug that way! Modern web development tools to the rescue. Huzzah.
Luckily, I’m an old skool web developer. We didn’t have tools when I started. I know how it goes! Back when PHP scripts returned a blank screen if you had an error. Because showing errors on the web leads to security issues, you see. Back when browsers didn’t come with developer tools until someone built FireBug for FireFox.
Those arcane skills came useful once more.
In a nutshell:
- Guess which element is a problem
- Add a border
- Send email
- Check on phone
- Refine guess, go to 1
1px solid red is always my first try. Then I move on to blue and green and dotted and dashed and all sorts of things until I understand how things are rendering and why. Each time you tweak some CSS, some HTML, and move things around.
When you’re inspecting paddings and margins, you opt for pink and blue and white backgrounds. Background for the big div, background for the small div, hey presto margins and paddings show up. yay
Sometimes you take things out to see if they’re pushing stuff around. Binary search through the HTML tree to see which line is causing problems.
It took me 57 iterations. Here’s a gif. Enjoy
57 debugging iterations.
I may have lost my sanity, I may have begged on Twitter for a bullet to the head, but by Joe, I got it done. The email is damn well perfect.
Now watch as I walk into work this morning and QA says it doesn’t work.
Published at DZone with permission of Swizec Teller, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.