Blog

Or search support forum

What's Global Moxie?

Global Moxie specializes in mobile design strategy and user experience for a multiscreen world. We offer consulting services, training, and product-invention workshops to help creative organizations build tapworthy mobile apps and effective websites. We're based in Brooklyn, NY. Learn more.

On Shelves

Books by Josh Clark

Tapworthy: Designing Great iPhone Apps

Best iPhone Apps: The Guide for Discriminating Downloaders

iWork ’09: The Mising Manual

Moxiemail

Enter your e-mail to receive occasional updates:

3.1 Million Pixels Are Heavy

Posted Mar 8, 2012

New iPad

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

Louie Mantia's Photoshop template for iOS icons-2

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.

  1. Woodwing and Digital Publishing Suite tools are essentially plugins for Adobe InDesign. They let you convert print issues into reasonably interactive iPad editions. That lets publishers use the same essential designs, workflow, and staff to sling print content onto the iPad platform. The process has tons of disadvantages from a UX perspective, but I'm sympathetic to the decision to use them. These tools represent a transitional stage that allowed publishers get on the iPad (relatively) quickly and (relatively) cheaply. The next phase is about figuring out how to create experiences that feel more native to tablets, or whatever platform publishers choose to target. First-generation tools like Woodwing and Digital Publishing Suite are a necessary evil. 

Tags: , , , , ,

Want more? Recent blog entries...

Comments

8 comment(s) on this page. Add your own comment below.

Ilan
Mar 8, 2012 2:59pm [ 1 ]

Guess I'm not building an app for the ipad!

Mar 9, 2012 12:16pm [ 2 ]

I believe we'll see designers and developers start moving towards using SVG images, CSS3 effects, and icon web fonts to help handle changes in device resolution. Raster images will no longer suffice to fill our needs.

abracadabra
Mar 11, 2012 2:54am [ 3 ]

Roll up the sleeves and use pngmini or pngquant. They reduce PNG sizes by factor of four, so you'll be back at normal size :)

Mar 12, 2012 9:04am [ 4 ]

Pngmini and other image compression tools have zero affect though on images for native apps. The good folks over at Bjango did some tests on image compression in native iOS apps. You can check out the scientific stuff here http://bjango.com/articles/pngcompression/. But what boils down to is we can't make these images any smaller for native, so it's still gonna be rough on designers, developers, and of course disk space. That being said, I'm looking forward to it.

Jonny Kaldor
Mar 12, 2012 9:16am [ 5 ]

Yep - completely agree - the new display further supports the argument for delivering content as it should be delivered - through HTML, and doing it all in a native container to get the best of both worlds. The sooner publishers go hybrid the better! Check out pugpig.com to see how it's done...

abracadabra
Mar 14, 2012 5:31am [ 6 ]

@Jason Grandelli: That's only half right. If you fix Xcode's settings, you can optimize PNGs for iOS.

protomech
Mar 26, 2012 9:14am [ 8 ]

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

Really, 6-12x as large? Apple's 2x image assets are 3x as large.

PNG 3829 KB, 2048x1536 JPG 848 KB, 1024x768 JPG 301 KB (2.8x) http://upload.wikimedia.org/wikipedia/en/1/17/MaineEastHSfacade.png

PNG 1068 KB, 2048x1536 JPG 773 KB, 1024x768 JPG 298 KB (2.6x) http://zapp5.staticworld.net/images/article/2012/03/ipad3_link-11336170.png

Just a random search online for 2048x1536 PNGs. Not saying these are representative, just that I don't see where the 6-12x figure is coming from..

Another random thought. For a fixed image filesize budget, what looks better, a heavily compressed full-res image or a more lightly compressed half-res image? Does this change as the fixed image size increases? Is there a sweet spot web developers and magazine developers should target?

Add a Comment

Don't be shy.

(Use Markdown for formatting.)

This question helps prevent spam:

Download Big Medium
Try it free for 30 days, or buy to unlock.

A Better Place

“The App Store would be a better place if every app designer read Tapworthy.
—Juri Pakaste, developer

Tapworthy is far and away the best book on the subject.”
—Mike Rundle, iOS designer, Flyosity

Tapworthy is a great read for every iPhone app maker!”
—Sophia Teutschler, iPhone developer