3.1 Million Pixels Are Heavy

As everyone in the world knows by now, Apple bumped the iPad’s screen to retina-display density, quadrupling the number of pixels to a whopping 3.1 million. That’s fantastic news for iPad owners—the display will be gorgeous—but it also means more headaches for designers and a potential blight on your bandwidth bill and download speed.

In bandwidth terms, pixels are heavy, and four times the pixels means four times the image size for bitmap images, give or take. If you want to take advantage of this gorgeous screen, every image you push down the wire is about to put on a ton of weight. That has implications in lots of places.

Trouble for magazine publishers

For utterly understandable business and workflow reasons, a vast number of publishers have adopted platforms like Woodwing and Adobe’s Digital Publishing Suite.¹ Trouble is, these tools publish images of pages, not actual text-and-image layouts. They’re giant bitmaps.

These big bundles of pixels already make for mammoth file sizes for individual issues, and downloads can take a long time. (Apple’s Newsstand does its best to make this invisible by downloading issues in the background for you.) For publishers who want to take advantage of the new iPad display—that is, all of them—they’re gonna see these already giant files quadruple in size. As David Sleight wrote this morning:

Now apply the volumetric increase in pixels that’s upon us, and it’s easy to see why the size of an average iPad magazine issue is about to go through the roof. Very roughly speaking, a single page of text built this way and saved using light JPG compression weighs in at around 150–350kB. At the new Retina dimensions these same app platforms will generate pages on the order of 2MB. That’s per page.

This isn’t just a question of the bandwidth these apps will devour while downloading issues, it’s also a question of whether or not a user can actually store these things anywhere. The screen volume may have quadrupled, but the new iPad still ships with the same three memory options: 16, 32, and 64GB. As I noted on Twitter, the growth rate of the potential payload size just outgrew the growth rate of device storage exponentially.

This is obviously untenable, and publishers either have to start thinking (and fast) about new tools and workflows, or toolmakers need to start thinking about generating these app magazines in leaner formats. A recent briefing from Condé Nast hinted that Adobe is starting to move to HTML5 layouts for its tools. That would be good news for file sizes and would almost certainly benefit the reading experience, too. Readers would finally be able to select text, copy it, resize it, and so on.

But that still won’t get us completely out of the woods. Web technologies like HTML5 are going to have issues to manage with a retina-display iPad, too.

Trouble for responsive designers

Building just one website for all devices and platforms should be the ideal for every webslinger, the starting point for every project. Ask yourself: can we create just one base set of HTML and then use responsive design and progressive enhancement to gracefully adapt that HTML to any screen? (This one-web approach isn’t always practical, and as always, it depends on the project.)

As an industry, we’re still learning the right way to do responsive design, and one of the big sticking points is how to cope with images. While it’s easy enough to make the browser resize a big image to fit a tiny display, bandwidth concerns suggest we shouldn’t send that big file to devices that can’t use the extra pixels. The new iPad only magnifies this problem. Sending a full-screen iPad image (1536x2048) to an iPod Touch browser (320x480) is overkill to the tune of 25 times the file size. Over a wireless connection, that’s gonna smart.

This isn’t a new problem. Folks at the forefront of mobile web design have been wrestling with this responsive-image problem for the past year. How do we nudge the server to send a properly sized image instead of sending a giant one-size-fits-all file?

We don’t have a good answer yet. Jason Grigsby has outlined a slew of techniques (and more and more), none of them perfect, and Matt “Wilto” Marquis suggests a way forward by extending HTML itself. Whatever the ultimate solution, though, that means image editors will have to start adding more and more cut sizes to their server-side arsenal. And yep, that means:

Trouble for content creators

I recently did some work for a magazine website. Over the years, their various image contexts had sprawled so that they were doing as many as ten different crops and sizes for any one photo. Thumbnail images, gallery images, primary and secondary article images, you get the idea. Lots of image sizes to accommodate various layouts. This had all evolved in a single-platform environment—the desktop—and didn’t even begin to contemplate the varied screen resolutions of the desknot devices of recent years.

Here’s the kicker: for all those image sizes, almost all were too small for mobile. You heard me right. Max image dimensions of 600x600 have, until recently, been plenty big for a website. On the desktop, that’s pleasingly large, even for a magnified view. But that won’t even fill the screen of a retina-display iPhone. The physical dimensions of the latest phones might be small, but the screen resolutions of some desknots are much higher than the desktop. Cut sizes have to adapt to match those resolutions.

To accommodate the iPhone and iPad, the magazine created a new cut size, up to 768x1024. But now they’ll have to consider adding at least another cut size, perhaps several. Some of this work can be automated, sure, but in many cases, adding new sizes means adding new crops, and that’s necessarily manual editorial work. So the growing variety and size of screen resolutions means more work, more disk space, more database management.

Trouble for iOS designers

And finally, of course, we’ve got more work for iOS designers. As they did for iPhone 4 and 4S, designers will have to generate yet more image sizes for icons, app graphics, and so on. The already large list of icon sizes for a universal app has just grown. Louie Mantia kindly shared a Photoshop template cheatsheet to help you keep track of your icon efforts.

Don’t be glum: this is awesome

Look, this is hard work. We have tons of devices to support, and we have to create designs and assets that not only fit their new screens, but also fit the new interaction models of each. Our job is getting harder, and this is only the beginning of it.

But man, it’s in the service of something really incredible. The proliferation of devices is all in the service of creating technologies that adapt to our specific contexts. Beautiful tablet screens, speech interfaces, gestural interactions—all of these things are going to tax us as designers and content creators. But wow, such creative opportunities! As both a user and a designer, I for one welcome my new 3.1-million-pixel overlord.