So what does that mean?
That means your emails need to be clean, lean and quick to digest. With that in mind, I’m going to show you a great button replacement technique that will limit the number of images your email uses, and provide great calls to action regardless of whether images are downloaded.
Let’s Back Up and Talk About Images
By default, nearly every email client blocks images when a user opens an email. The only ones that don’t block images include Apple’s Mail and iOS Mail client. But a large majority of internet users use web based clients such as Gmail, Hotmail, Yahoo! Mail or AOL, or they use desktop clients such as Outlook (00, 03, 07, 10), Lotus Notes, or others. One of the most difficult aspects of coding HTML emails is the variance in support for basic HTML and CSS properties across a multitude of email clients.
As of February 24, 2012, Litmus shows that 43% of users use some version Outlook, while no other client even came close. Hotmail came in second at 17% followed by Yahoo! Mail (13%) and Gmail (8%). Apple products came in with a total of 8% split between iOS (4%) and Apple Mail (4%).
So if a large majority of your customers or clients are using email clients other than iOS (and let’s be honest – they are), you’ll need to make sure that you can provide a clear cut call to action regardless of whether or not the user chooses to download images.
That’s where our bulletproof buttons come in.
The concept behind bulletproof buttons in emails is to provide the user with a compelling, attractive and inticing call to action without the use of images. Granted, this might not be possible with your particular design, but I’d highly recommend looking into it if you can.
Another concept to keep in mind as we look at the code for our button is you won’t want to use padding and margin. Support varies widely and you’ll get a lot of funky looking results. Stick with nested tables. Just try and keep them straight – it can get complicated quickly.
Our bullet proof buttons are a nested table with one table row and one table cell. The CSS is declared inline for a lot of reasons, but mainly for web based browsers that strip out embedded styles, and I utilize some CSS3 effects that will render in some clients, but will degrade gracefully in other clients.
Take a look at the code, try and break it down, then we’ll go through each part.
<table> <tr> <td align="center" width="300" bgcolor="#cf142b" style="background: #cf142b; padding-top: 6px; padding-right: 10px; padding-bottom: 6px; padding-left: 10px; -webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px; color: #fff; font-weight: bold; text-decoration: none; font-family: Helvetica, Arial, sans-serif; display: block;"><a href="" style="color: #fff; text-decoration: none;"></a></td> </tr> </table>
Simple, right? Yeah, I know that is a lot of code in the <td> tag, but let’s break it down.
First off, you will most likely want the text of the button centered within the button, so we add the align=”center” to the <td> to kick things off. Next we add in a width for the <td> and a solid background color. This creates the appearance of a button, using the table cell as the box. Then we jump into our inline style tag and make some magic happen.
All styles for HTML emails should be done inline, so thus, you get a long, not very clean line of code there. But for the most part it’s self explanatory. I’ll clean it up and show you how it looks non-inline below:
background: #cf142b; padding-top: 6px; padding-right: 10px; padding-bottom: 6px; padding-left: 10px; -webkit-border-radius: 4px; -moz-border-radius: 4px; border-radius: 4px; color: #fff; font-weight: bold; text-decoration: none; font-family: Helvetica, Arial, sans-serif; display: block;
That makes it easier to read, right? So again, we declare a background color via CSS. This is a good practice to get into because some email clients won’t read the CSS background, and other clients won’t read the bgcolor=”” in the <td> tag.
Next, we add padding to the button. It is important here that you declare the padding individually, and not using the shorthand. Again, email clients are fairly rudimentary when reading CSS, so the best practice is to separate them out when styling them.
Moving on, I’ve added some CSS3 properties to create a nice rounded border look on the button. Border-radius will only come into play on a certain number of email clients, including iOS, Gmail, Yahoo! Mail, and Hotmail on Firefox, Safari, Chrome or Opera (basically, not Internet Explorer). But this doesn’t break the design of the email, unless your email absolutely must have a rounded button. For me, this is a perfect example of graceful degradation.
The rest of the CSS is pretty self explanatory, setting the color, font-weight, font-family and text-decoration.
How Do They Look?
Great question! Let’s take a look at the following screenshots from an email campaign I used this technique on for a work email. This was a sales email offering up tickets to a hockey game in Washington, D.C. during December. The screenshots are annotated, but shown are Outlook 2010 with images on and off, and Gmail in Firefox with images on and off. Take a look below.
Have you used bulletproof buttons in any of your HTML email campaigns? How have they worked for you? Let us know in the comments below.