Regardless of the social media networks that are popular at the time, email marketing will always be the number one way for a company or organization to connect with customers or clients. But, the average internet user has 2.3 email addresses and sends and receives an average of 112 emails a day.

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.

The Code

If you’ve done any work in HTML emails, you know that you should break out your old HTML book circa 2003 and brush up on your tables code. Tables are one of the most simplistic and structured code in the world, and with the unpredictability of HTML and CSS support (don’t even think about JavaScript) in email clients, tables are the way to go.

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;...

Here’s the situation:

You’ve written a program in C#. You’ve checked the flowcharts, examined your coding and developed your user interface.

You’re anticipating that everything will flow as smooth as silk. You’re ready to create a build of the program and, instead of seeing a beautiful, efficient result, you get several (often incomprehensible) error message. How did this happen?

Here are SOME ways that these errors occur:

#1 Undeclared Variables

C# throws an error message on undeclared variables. This most frequently happens in one of three ways:

1) The variable is not assigned a type. The code in a “for-next loop” that reads like this:

for (nextStep = 0; nextStep < 20; nextStep++) { // loop process }

should read like this:

for (int nextStep = 0; nextStep < 20; nextStep++) { // loop process }

2) The variable name is spelled differently. Variables are case sensitive in C#, which can lead to some careless errors:

for (int nextStep = 0; nextStep < 20; nextStep++) { int workerID = nextStep; Console.WriteLine("Worker ID #:" + WorkerId); }

The compiler will view “workerID” and “WorkerId” as two different variables and view “WorkerId” as undeclared.

3) The variable is declared in a different scope. In order to use variables both inside and outside a routine (such as a “for” loop or a “while “ loop), the variable must be declared outside the routine.

for (int nextStep = 0; nextStep < 20; nextStep++) { int workerID = nextStep; } Console.WriteLine("Worker ID #:" + workerID);

This code will not display the final number in the sequence, but will throw an error due to the workerID variable’s declaration sitting inside the for loop.

#2 Variable Conversion Errors

For developers new to C#, especially those coming from more intuitive platforms such as VB.Net or ASP.Net, the lack of flexibility with variable types can be a hurdle.

Here’s an example of a variable conversion that throws a build-time error:

class MyClass { static public float TripleFloat(float t) { float fResult = 3.0 * t; return fResult; } }

Since 3.0 is a “double”-type variable, the operation will return a “double”, not a “float”, and create a build-time error. The operation needs to recast the result as a “float” to avoid the conflict:

class MyClass { static public float TripleFloat(float t) { float fResult = (float)(3.0 * t); return fResult; } }

#3 Protection Level Conflicts

Some programmers may forget that the default protection level for a class is “internal” and the default level for any member in that class is “private”.

class MyFirstClass //default protection = internal { public void NameFunction(){ MySecondClass sc = new MySecondClass(); sc.strFirstName = "Harry"; sc.strLastName = "Potter"; Console.WriteLine("Name: " + sc.strFirstName...

Videos have been a great way to attract viewers to a website long before YouTube launched back in 2005.  But it wasn’t until the release of HTML5 that web developers have had a lightweight solution to playing the video.  In the past, displaying a video on your site meant your viewer was required to have a Flash or Java-based player installed on their system in order to watch the video.  This was one more thing that would weigh down your site, causing pages to load slower, and be one more thing you’d have to trust the viewer to download and install.

Handling a video with HTML5 can be as simple as this.

<video src=”videos/myMovie.mp4” controls></video>

You’ve got the source and have added the browsers native controls.  That’s approximately 41 less lines of code than a site I recently worked on that was using a Flash player, not to mention the player itself had a fairly bulky file size.

Flash and Java Video Players

One big advantage that Flash and Java video players have over the new HTML5 video element is that they’re able to stream live video.  The HTML5 video element is still in its infancy and as of now is not able to stream any sort of live video feed.  Another major advantage that a Flash of Java video player has over HTML5 is that they can handle 3D effects.  This could be a major factor in preventing HTML5 video players from taking away a large amount of market share from Flash and Java players.  As we’re seeing an influx of films coming out in 3D, as well as major sporting events being broadcast in 3D, the ability to handle 3D and streaming content is becoming a more crucial requirement for a video player.  Add the growing number of people who choose to stream movies or TV shows from sites like Netflix, Hulu, or YouTube, and the demand for a powerful, robust video player grows even more.

One of the downsides to having a Flash video player, aside from file sizes and it being an add-on that the viewer must install, is that Flash is not compatible with Apple tablets and mobile devices.  With Net Applications announcing iOS grew to owning 61.6% of the mobile market share in the month of October, that appears to be a big down side.  Especially when you consider more people opt to browse websites from their mobile device or tablets instead of using their computer.

Java players gain their biggest edge over Flash players by being compatible with the iPhone, iPad, and iPod touch. The reason behind Apple’s decision not to support Flash stems from Flash being a “closed” system, meaning that Adobe Flash products are only available from Adobe and Adobe controls the future of the product in regards to upgrades and pricing.  This is opposed to Java, which is an “open” programming language.  Downsides to a Java video player are very similar to that of Flash as well, larger file sizes, and the need for the viewer to install a plug-in for their browser to display the video.

HTML5 Video Element

We’ve already established that an HTML5 video player can mean you have a substantially smaller file size, but as with Flash and Java, HTML5 has its advantages and disadvantages.  An HTML5 video player will also be cross-browser friendly and work on Apple products.  However, just because you’ve implemented an HTML5 video player on your site does not mean that the video will play on an Apple product.  This is an issue I pointed out with a recent client; they wanted to switch their site from a Flash video player to HTML5 so that it would play on an iPhone or iPad.  It was at this point I had to point out that their video formats were in FLV, a video compressed with Flash.

To accommodate anyone who might be viewing your site from an Apple mobile device or tablet there are some video compression guidelines you will want to follow.  An iPhone will play MPEG-4 videos or QuickTime videos that were compressed with MPEG-4, meaning H.264 video and AAC audio.  It’s also worth noting that the iPhone does not support B-Frames.  If you’re given the option of encoding your video in a multi-pass or single-pass mode, choose single, even though you will most likely be encouraged to do multi-pass for best quality.  I’ve found that 480×360 dimensions is a nice median to accommodate full screen on a computer without distorting the image too much, and not ending up with a file so large it takes too long to load on an iPhone.

HTML5 will also allow you to name multiple video sources, OGG, MPEG-4, and WebM.  OGG is compatible with Firefox 3.5+, Opera 10.5+, and Chrome 5.0+, but not IE or Safari.  MPEG-4 is supported by IE 9.0+, Chrome 5.0+, and Safari 3.0+, but not Firefox, or Opera.  While WebM is supported by Firefox 4.0+, Opera 10.6+, and Chrome 6.0+, but not IE or Safari.  Being able to point to multiple sources will ensure that your video is able to play on any major browser, with the only downside being you to have multiple formats of your video.

Pointing to multiple video sources is as easy as one might think, “just include the source for each”.

<video controls> <source src=”videos/myMovie.mp4” type=”video/mp4” /> <source src=”videos/myMovie.ogg” type=”video/ogg” /> <source src=”videos/myMovie.webm” type=”video/webm” /> </video>

Moving Forward With <video>

Some might say that the <video> element is too little too late, but using HTML5 to display a simple static video on your site is a perfect way to ensure viewers to your site will be able to see it, whether it’s on a mobile device or a desktop computer.  It’s lightweight and requires no additional plug-in to work.  As with all new technologies you have to start somewhere, and from there you begin to see areas in which it can be improved.  Being someone who strives to develop as lightweight of sites as possible, I am excited to see what direction the new HTML5 video element goes.

...