Archive for March, 2012 :

Worth gambling on hi-res?

Wednesday, March 28th, 2012 by Anna Yeaman

An ongoing tug of war between Graeme and I is performance vs. aesthetics. Is it worth quadrupling the image weight for iPhone 4, when a 320px image looks OK? Graeme thinks not, I begrudgingly agree. So I was keen to see how images fare on the iPad 3, with it’s 2048×1536 retina display.

See a difference?

Here’s screenshots of a 710px wide email (816KB images) on the iPad 2 and 3. The difference in resolution (1024×768 v 2048×1536) makes it hard to do a side-by-side comparison. So I took some photos you can eyeball. Can you tell which is which? I couldn’t at first.

On closer inspection HTML text is sharper on the iPad3, and small image-based text slightly more pixelated. I doubt the average user would notice though. Especially as email read times are in the seconds.

{ HTML text  - purple section is an image - iPad 2 top and iPad 3 below }

iPad 3 retina

I’m not saying your images wouldn’t look sharper if you used hi-res. Of course they would. But that 710px image looks no worse than it ever did on the iPad 2.

 

Media queries

If you did want image quality on par with native apps there are a few options. Using @media you can switch between different res images based on viewport size or pixel density. Though setting an image to display:none doesn’t prevent all the assets from being downloaded. You could end up forcing a 1.3MB download on mobile users (1MB iPad 3 + 250k desktop + 50K mobile).

 

Fluid

Instead of sending all viewports the smallest res image e.g. 320px, with fluid you’d do the reverse. Prepare the image at the highest res, set the width to 100% and let the browser resize it. Problem is, you’d still be forcing a hi-res image on mobile users.

{ Play with fluid email }

iPad 3 retina

 

Server-side

Server-side solutions like DIS detect the device via the UA string then serve up an appropriate sized image. Working from a low-res default you don’t have to maintain a list of every device/client, just a representative selection. Though it’s too fundamental a feature for a third party solution.

{ iPod User agent readout via DIS. Frowning at laptop webcam, with Graeme taking screenshot }

iPad 3 retina

 

Connection speed

Some users are on 3G or 4G, others WiFi. How do you differentiate?  Historically most iPad sales are WiFi. But WiFi reception at a busy conference isn’t the same as at home over broadband, which isn’t always optimal anyway. If you increase file size, load times increase by the same factor, and who wants to download a 2.0MB file at 64k a second…

{ Slow download times impact sales }

iPad 3 retina

With our dynamic video, we calculated the available bandwidth based on the previous group of frames. So we were always monitoring and adjusting the compression/fps/res. You can’t use this technique with a single image though, and there’s no JavaScript support in email.

So even using @media or DIS, we’d be making broad assumptions about bandwidth. Looking at 50 retail emails, 258k was the average image weight (17k-973k range). Worse case, you’d be taking a 2MB gamble by targeting the iPad 3’s resolution.

 

Alternatives to images

We’ve been saying use more HTML text for years, and more recently CSS3 for buttons ect. Though less time and budget spent coding, and increased creative freedom with images, make this a difficult sell. Especially on a daily send.

Do what you can. Make any reusable components HTML, like navigation and footers. In the Crate&Barrel example, body text within a simple rect was HTML, the more complex areas image-based. One old UK trend, used HTML text at the top of the email, then it would drop off to images. You could also just make your logo hi-res, as it’s usually only a small file. It doesn’t have to be all or nothing.

{ View Next email }

iPad 3 retina

 

One big image

We use the term “One big image”, though it’s rarely the case. Going back to those 50 retail emails, half of the hero images were sliced up. It’s the only reliable way to add multiple URLs. This means a mosaic of images to prepare and swap, rather than just one. It’s not a show stopper, but it does add to the complexity.

As does asking a designer to create a 1400px layout. Sure we can do it, but it’s an adjustment. One that would also require access to hi-res assets.

 

ROI of crisper images?

With popular viewports now ranging from 320px-1536px a one-size-image fits all approach is sloppy. With the adoption of Smart TV’s and even cars with on-board email, the problem is just going to get more acute. If we’re not going to wean ourselves off print mag layouts, the least we can do is optimize image downloads.

But until there’s a reliable way of conditionally serving images - that doesn’t make a truckload of assumptions - I’m reluctant to gamble on hi-res.