Fargo email development — walkthrough and my own learning.
I thought I’d write about a little bit of the approach and the learning curve for the build of this, especially as I’d previously done some blogs on background images, and a lot has changed since those were done, and I never really got around to updating them fully.
I’ll cover how with this email I approached this build and why, and some of the changes that I could have made after it had gone out, which are pretty useful.
NOTE: the background VML method used in the link above isn’t the one discussed further down the blog
UPDATE: FEB 2018
I’ve been using a similar premise in this email which is a little different, but has similar features.
The Build and the Design
One of the things that really led to this build being possible was the brilliant design that @Stephhh created. We definitely wanted to do something different, and we also didn’t have that many assets to work with either, so working closely with the great folks at Channel 4 to put this together and come out with something interesting was definitely key.
We were going for simple, bold, different, accessible, progressive, and for the build to remain lightweight. It was designed at up-to 960px wide. (I did experiment with up-to 100%, however, the size of the header image was quite jarring and a bit too big).
A big thing for me was taking that common bullet list of email myths and busting them all in one email - 600px, backgrounds, web-fonts, animation, and ‘has to look the same everywhere’.
Because of the background use and the audience involved (thinking in terms of progressive enhancement approaches) my baseline became the IMAP Gmail accounts/Android gmail app/GANGA inboxes that don’t support background images, or embedded style sheets, which is something we had both been considering in the design, that it was still striking without images, and in many ways, didn’t require them, and I think we succeeded in that. In some ways what would generally be considered content images became closer to being layout images due to how we used them.
So I built the inline version of the email, in Litmus Builder… while continuing to refresh the Gmail IMAP test screen as I went along, and sending the email to my Yahoo account in my Gmail app as well.
At the end of the build we added the individual image of the cop car in the snow and then turned that off elsewhere in the embedded style with a bit of display none, and the Gmail U+Body hack as well.
From there I figured that if I used the embedded style sheet for above and below 640px, I should be ok…If I adjust the font-sizes and the padding/heights around them as required, and largely that’s all I used that for. (I could probably have put more break-points but I didn’t seem too necessary and I was happy with the result).
One thing I’ve always liked is the flexibility you get from using background-size:cover; and simply using % top padding, especially on your mobile media queries. It’s a simple thing to suggest, but I think with email it’s something I don’t see too much of…. saves a lot of messing about.
I was going to put the backgrounds in the embedded style, or at least my CSS style backgrounds, but in the end I didn’t. I went for a more standard inline approach:
<table role=”presentation” width=”100%” border=”0" cellspacing=”0" cellpadding=”0" style=”max-width: 960px; background-position:center center; background-size:cover; background-repeat:no-repeat; background-image:url(fargo_image.jpg);" background=”fargo_image.jpg">
We didn’t use retina for backgrounds simply for saving weight. They looked great at 960px, and on mobile they were really striking by the time they had shrunk down.
Channel 4 haves several of their own fonts, but tend to use Trebuchet and Verdana in their emails. We were able to access their webfonts as base64, and as the email was lightweight, I decided we had some room to put the base64 fonts in. To do this I needed 4 of them though.
Bold (uppercase and lowercase) and Normal (uppercase and lowercase).
A base64 font is around 5kb per font style, which is a lot for email to deal with (20kb in this instance), so I kept it at just the one for the ‘FARGO IS BACK’, and it works really well.
By adding a base64 font in to an email, you are essentially sending the font, with the the email, is my understanding of it.
We played around with animation quite a bit. The one thing that stayed is the simple hero font entrance, however, we went back a forth with the speed and timing of the entrance.
The animations we removed or played around with were the images entering, appearing, expanding etc. etc… too much.
The third image, we had a played around with animation that using an external style sheet, which I liked messing about with, and have been for a while now. There were mixed responses to it, and because of that it was a bit of a case of ‘just because you can…’ and looking at it now it was the right choice to ditch it, it’s distracting. I still have an early mock-up of that, which targets Webkit to take over an image tag (image becomes invisible but the shape remains, and therefore shows the backgrounds behind it), but when I made the later version it became a background gallery — but I appear to have deleted it.
I didn’t focus masses of attention on Outlook and the many terrible iterations of it, but did on the PC inboxes — so included VML for each one, and forced it to be 700px wide rather 960px. Other than that the only thing I did was to control the size and line heights of the H1.
Coming back to Outlook I knew there were other ways of doing backgrounds in VML that people have been using. To support Windows 10 etc… and just a day or two ago Wilbert Heinen messaged me to show me how it the VML could be changed to better support Windows 10 and Outlook DPI. Which was really great and very kind of him. The method was different to the usual, and used points instead of pixels to help the DPI. Works beautifully. He tells me it comes from an old post somewhere on Campaign Monitor.
As usual the Email community being awesome. Cheers Wilbert.
<! — [if gte mso 9]>
<v:image xmlns:v=”urn:schemas-microsoft-com:vml” id=”theImage” style=”behavior: url(#default#VML); display: inline-block; width:525pt; height:348.75pt; top: 0; left: 0; border: 0; z-index: 1;” src=”image.jpg" />
<v:rect xmlns:v=”urn:schemas-microsoft-com:vml” fill=”true” stroke=”false” style=”display: inline-block; position: relative; width:525pt; height: 161.25pt; top: 187.5pt; left: 0; border: 0; z-index: 2;”>
<v:fill opacity=”0%” style=”z-index: 1;”/>
So myself and Matt had a look at it to see what we could take of that code, reduce it a bit, and this is what we ended up with, with a few adjustments.
<! — [if gte mso 9]>
<v:image xmlns:v=”urn:schemas-microsoft-com:vml” style=”width:525pt; height:348.75pt;” src=”image.jpg" />
<v:rect xmlns:v=”urn:schemas-microsoft-com:vml” fill=”false” stroke=”false” style=”position: relative; width:525pt; height: 161.25pt; top: 187.5pt;”>
So I’ll definitely be using this method in future for my VML going forward.
Hope you find this useful and interesting.
It was a good process to go through for the build. Just a shame I couldn’t use DIVs as I needed to use the HTML background element.
(NOTE: FEB 2018 as far as I’m aware the HTML background element is no longer needed, so this if built almost a year on it could have been DIV based if I felt like it was worth it)
Thanks for all the positive feedback.