iPad Retina Display Concerns and Tips

TL;DR

The iPad 3 retina display means a lot of apps and web sites are going to feel pressure for sharper (bigger) images. Knowing if you need to scale your images, the impact on end users and some ways to mitigate that impact is the right way to approach this.

What's All the Fuss?

With the announcement of the new iPad's "retina display," there has been quite a lot of buzz among web developers about what that means for graphics. Some are welcoming the change by diving right into their projects and kicking up the size of their images, and some are lamenting the ongoing unabated bloat of web pages and apps since images can quadruple in size.

If you don't believe Apple sees the potential for apps to grow in size, earlier this month it raised the cellular network download limit in the App Store from 20MB to 50MB. While there are many arguments on why Apple might have done this, knowing that the image assets for any app may bloat in size by four times when targeting the new display provides a rather compelling reason on its own.

David Sleight points this out in his post A Retina Display Reckoning for Magazine Publishers, using magazine page sizes as an example of the problem scaled-up images could produce:

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.

Apple also understands that images on the web will grow in size to target the iPad 3. The method Apple employs to deliver these images is not only inefficient, if web developers user Apple's code as a baseline then all the sites they build will affect their users. From a post last week, How Apple.com will serve retina images to new iPads, Jason Grigsby outlines just what happens to the end user:

As far as I can tell, there is no attempt to prevent duplicate downloads of images. New iPad users are going to download both a full desktop size image and a retina version as well. […] The total size of the page goes from 502.90K to 2.13MB when the retina versions of images are downloaded.

This doesn't even account for the HTTP requests for the original images, the HTTP requests for the high resolution images, and the HTTP request to test if there is even a high resolution image to retrieve. All of this is wrapped in a browser detection script, something at which a seasoned coder may wince.

Josh Clark points out in his post 3.1 Million Pixels Are Heavy that responsive design is still a method-in-progress and that using techniques like Apple does to serve high resolution images can push down far more than a user needs:

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.

Peter-Paul Koch takes this a step further in his article The iPad 3 and Moore’s Law, where he talks about the impact that larger images will have on network speeds and ultimately user experience. Citing an example of an app that will bloat from 18.3MB to ~35MB, he brings the file size discussion to its logical conclusion:

Thus the Retina display puts incredible extra strain on the already-strained mobile web. Retina may be great for the end user, but the data networks simply cannot handle it (yet).

A common response to the scaling of images involves reliance on SVG images. Because SVG images are vector files, meaning the elements of the image are defined as scalable shapes instead of columns and rows of pixels, they can be sized up or down and still maintain the same file size and not lose any information. For images that are not photographic this sounds like a good workaround when targeting iPads only, regardless of SVG support in other browsers.

As anyone who has worked with vector imagery may know, however, vector images typically don't scale in ways that maintain the goal of the image. If you look at the icons on your computer and explore all the sizes, you may notice some elements change shape, relative size, or are even discarded altogether. The article About those vector icons by Kirill Grouchnikov demonstrates this in detail with some great examples. He also has a well-supported conclusion:

So no, SVG is definitely not the answer. At least not today.

The SVG solution is the common comment response to Brad Frosts' post iPad3′s Retina Display Will Wreak Havoc on the Web. As you read through the comments it's easy to see why I stress about the return of the browser monoculture, this time iPhone and iPad rather than IE6, as I wrote about a couple weeks ago (The Return of “Best Viewed in…”). Sadly, from that entire assault of comments pushing SVG or suggesting users just accept the bloat, only three comments even thought to mention responsive images, something the W3C is working to address now in a dedicated responsive images community group.

How to Adapt

I haven't reviewed all this to disparage the new retina display on the iPad 3. Instead an informed developer takes into account the pros and cons of every scenario and makes informed decisions that balance the needs of the user with the practicality of development efforts.

If you build stand-alone apps for the iPad, then you'll need to make many decisions about the images you use and whether or not they all need to be updated. You may find that getting the right icon size can be a bit tricky though, and Louie Mantia was kind enough to put together this iOS app icon template.

As for web development, a few posts have started to pop up that echo the same ideas good developers have used for years — evaluate the need, weigh the solutions, don't get too caught up in the bleeding edge. Here is a distilled list from the post iPad 3 and Retina Screen: What it means for your mobile commerce site:

1. Prioritize important images;
2. Make text into text;
3. Boost button sizes;
4. Make the logo bigger.

Brad Frost offers some tips in his post Optimizing Web Experiences for High Resolution Screens:

1. Media queries (that sadly still lean on vendor prefixes);
2. SVG, with a link to browser compatibility tables;
3. @font-face to put icon typefaces to use;
4. Detect network speed (its own special kind of train wreck);
5. Get involved with the W3C Responsive Image Community Group;
6. Don't forget some basic best practices:
   • Start with low resolution images first;
   • Make sure you optimize your images;
   • Use CSS3 for corners, gradients, etc.;
   • Use resolution-independent options;
   • Detect the network (when you can);
   • Know your browser compatibility.

My simplest tip on all this is to look at the logs for the web site in question and see if enough users come in on iPads to warrant the stress at this point.

Related

• Case study: Tweetbot for iPad from ImageOptim showing some impressive manual optimization tricks.
• Is the New iPad Screen Too Good for the Web? from The New York Times, because your clients may be reading it.

Don't Let HTML5 Become the New DHTML

This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It's a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted "HTML5" as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn't care. It didn't matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

• W3C Clarifies HTML5 Logo Is for HTML Only
• HTML5 Finally Gets... a Logo?
• Google, Arcade Fire Confused on HTML5
• Google Doodle: Bouncy Balls Aren't HTML5
• HTML5 and CSS3 Confusion

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don't know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

• On the HTML5 logo, by Bruce Lawson on January 18, 2011.
• HTML5 logo: be proud, but don’t muddy the waters!, by Chris Mills on January 18, 2011.

Google Doodle: Bouncy Balls Aren't HTML5

When Google changes its logo in honor of a holiday, someone's birthday, or just for the heck of it, it sometimes gets some chatter. When Google created the Pac-Man logo, articles appeared of people trying to figure out how it worked, or commenting on tech support calls within organizations from users who blamed their own IT team, or even notes about lost productivity.

Today's Google Doodle has gotten a lot of traction in the web standards community and even sites that sometimes talk about web standards, like Mashable (Google Logo Turns into Animated Particles) and New Scientist (What's Google's mysterious doodle?). Those aren't the interesting bits of coverage, however.

Not HTML5?

Christian Heilmann took the time to reverse engineer the code and discovered that the balls were nothing more than divs with a border radius using script to move around the page (Google goes bubbly – interactive logo today on the UK homepage (plus source)). As he notes, the effect isn't exactly HTML5. The script moves and resizes the divs, but that isn't unique to HTML5 and could be done in HTML4 and support IE6. While CSS3 is used to create the balls, that could have been done with other techniques, and CSS3 is still not HTML5. Interestingly, Google blocked Opera in its browser sniffer, which Bruce Lawson explained could be bypassed by telling Opera to report itself as Firefox.

HTML5 canvas

Rob Hawkes wasn't impressed, primarly because Google did not use HTML5. He set about rebuilding the Google Doodle in the HTML5 canvas element, and did so in just a couple hours (Recreating Google’s bouncing balls logo in HTML5 canvas). If you have a canvas-capable browser, check Rob Hawkes' version.

SVG

Robin Berjon borrowed (stole?) Rob Hawkes' code to use a base for re-creating the effect using SVG (Google's Bouncy Balls, in SVG). See the SVG version in all its (somewhat chunky) glory.

Who Called it HTML5?

When New Scientist tweeted its article about the Google Doodle, the tweet read: "Could the Google doodle herald HTML5?" They could be forgiven simply for not being a web-focused magazine. Pocket-lint reported it was written in HTML5, but they are also not dedicated to web development. It seems the rumor started in multiple places via multiple tweets via multiple users, and probably owing to the HTML5 doctype on the page, which implies HTML5 but doesn't actually make it HTML5.

If you didn't get to see today's Google Doodle, or you prefer to surf in Netscape Navigator 3.04, then check out this screencast lovingly stolen from Christian Heilmann:

If you haven't tried it yet, try moving the browser window around and watching the balls react.

Update (Sept 9): AreGooglesBouncingBallsHTML5.com — Need I say more?

SVG Progress Bar Contest

Thanks to the W3C Twitter feed, I discovered a W3C blog post about an SVG contest, "No Bit, Sherlock." While the W3C may be pushing the contest, they aren't the sponsors. The contest is produced by Web Directions, an organization founded by John Allsop and Maxine Sherrin to create web developer conferences around the world. They pushed Microsoft UK to pony up some prizes for a contest, owing to Internet Explorer 9's plans to support SVG, something sorely lacking in all prior versions of IE (you can grab an Internet Explorer 9 preview release if you really want SVG now).

The gist of the contest is simple: Create a progress bar in SVG. Contestants are allowed leeway in how it looks and functions, but it must adhere to two key elements:

1. It must indicate to a user when waiting in an indeterminate state, and
2. it must indicate to a user how much a process has progressed.

Here's the catch: It must be submitted by June 11 at 2pm, British Summer Time (yeah, I'd have to call someone in Britain, too). The date was probably chosen to coincide with the Web Directions @media conference in London, June 9-11. You can read John Allsop's blog post about the contest and why they thought it up.

The criteria, from the "No Bit, Sherlock" site:

1. Your control has to work acceptably in the latest versions of Opera, Safari, Chrome, Firefox, and Intenet Explorer 9, so it would probably make sense to at least give it a look see in all these browsers.
2. Your SVG has to validate.
3. The judges will also pay attention to accessibility factors - hint - investigate the ARIA role attribute.
4. And, they'll take a quick peak under the covers at your code, so the cleaner and more legible that is, the better
5. They'll also consider how well the control communicates the two states described above, how attractive it is, and if it has that x-factor, then all the better.

Further details, including the list of judges, prizes, and even some SVG resources are all at the contest site. If you are new to SVG, I suggest you take a look at the SVG information at the W3C site.