Do I need to paint a <_picture_>?

Recently at TEDC14 we had many discussions with lots of other like-minded email folk about a number of different things and added to our big ol’list of stuff to blog about. “Responsive images” was one of them, so here goes:

What’s the deal with responsive images?
When an email changes up its layout to become optimised for smaller screen sizes, a lot of things can happen and one of the main visual and structural elements for most* emails is imagery of the <img src=”” kind.

The main principles are like the forces in physics: we can shrink, expand, hide, and show images.

What sort of images should I be using? Jpeg? Png? Gifs? Jifs?
Responsive images are no different from regular images used in email. So .jpg for richly textured imagery such as a photo, a .gif for simpler images with fewer colours or an animation, .png for when transparency is called for e.g. when image will overlap a background or require an easily updatable colour scheme. We refuse to acknowledge the existence of Jifs (just a little joke there). Litmus have a nice in depth article on this here.

How do I make “retina” ready images?
Retina ready images are high resolution images which look noticeably crisper and cleaner on higher resolution screens. This is achieved quite simply by inserting a double size original image and proportionally scaling it down in HTML img attributes.

Won’t that break somewhere? I heard resizing images in code was bad?
No, it wont break, it’s fine**, but you need to take care to resize proportionally and sensibly to avoid skew, stretch or blur.

Why is this deemed not to be “best practice” then?
“Best practice” is a misnomer, a set of arbitrary rules that is created to make life easier for non-technicals to communicate with each other and facilitate work flow.

However, it is clearly not a good idea to make all of your images “retina ready” as the file size (email weight) becomes heavier the more images that are oversized (interestingly an article recently published says that doesn’t really impact upon deliverability) however, there are other negative implications for heavy emails. We recommend just the logo and perhaps some icons, but as with everything in an ideal world, each project should be evaluated on a case-by-case basis.

What about background images? Do they work with responsive email designs?
With the new wave revolution in email code – driven by mobile – background images appear to have made something of a resurgence. There are well known ways to make background images work or at least degrade in tricky email clients and mobile devices tend to handle more advanced CSS promoting the use of background images for mobile.

What is the <picture> tag all about and should I be using it in email?
The picture tag is HTML 5 and it’s progressive web. Web and email are inextricably linked where we can share ideas, theory and principles – see a really neat analysis of this here. However, one of the big differences as discussed before, is that email is self serving; the email goes out into the world with its pocket full of CSS and backpack of images and the poor thing could end up anywhere.

The <picture> tag is great for reducing load times on a website, but this advantage is diminished somewhat in email where 1. the support is going to be erratic and 2. in principle all the images are called for anyway so instead of being minimal, you are actually bloating. However, the notion of swapping out images in order to maintain the aesthetic of the email is sound, when done sparingly.

What do you mean when you say “art direction” in mobile email?
As the layout changes, the focus of the email may also need to shift. This is something can can be achieved through implication of sound design principles. The most common approach is to scale images down and stack them vertically, but sometimes the imagery doesn’t scale well or becomes disconnected from the copy and we may want to use a redesigned version of that image. A really great example of this in full effect is here where as the screen becomes smaller a progressively enhanced logo design is shown.

We can use media-queries to activate image swapping at predetermined breakpoints (see hide and show if you missed it earlier in the post), giving the designer control over how the look and feel of the creative can be optimised as well as the code.

As with most things email, there’s so much more to add – SVGs are “the future of the web” are they the future of email? Drawing stuff with CSS? What’s this pixel art stuff all about? What cool things can you do with background images? – to name a few, and some things we describe above people will do differently. Let us know in the comments below.

* For example this email uses imagery, but thems ain’t actual images, they are code. And incidentally it is responsive, which adds a whole other layer of insanity and awesome.

** As ever – test first! This needs to be evaluated dependent upon the specific email platform used, as a small number of them have been know to do weird and not wonderful things to the code… Oh yes…