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.

Read More

Netscape Navigator 2.01 Celebrates 16th Anniversary

As of March 18, 2011 Netscape Navigator version 2.01 has turned 16 years old. Back when it was released in 1996 it was the bees knees. It introduced JavaScript (originally LiveScript), Java support, plug-ins, an email client, auto-dithering, and Live3D. It also provided support for font color, div, wrap, sup, sub and textarea elements/attributes. It even gave us support for the (now cool again) animated GIF.

While I wanted to write this up last year, by the time I remembered to I couldn't get data for 2011 (Navigator 2's 15^th anniversary). Now that I let it lapse, however, I have data from 2011 to use for my screen shots.

Top 10 Sites of 1996 in Navigator 2.02

What I have done is gone back and looked at the most visited domains in 1996 — the year that Netscape 2 was making it big (2.0 came out in September of 1995, but factor time for adoption and sites to adapt, and 1996 represents more of the Netscape 2 world). I fired up my copy of Netscape 2.02 (which you can get from the evolt.org browser archive), set it to 640 x 480, and went about visiting the modern versions of the top 10 sites of 1996. You may note that some have gone away. Clicking the image will bring you to a larger size.

Top 10 Sites of 2011 in Navigator 2.02

If somehow you were resigned to using Navigator 2 for your surfing needs today, how much could you get done? Many sites try to serve XHTML and won't even render, other sites rely on JavaScript and won't render. Most sites use CSS so you won't see much layout. And if a site uses PNG images then you won't see many inline pictures, either. I did, however, assume a new monitor for our 1996-era user and scaled the window up to 1,024 x 768. Mostly so you could see a little more of the page. I surfed to the top 10 sites from July 2011 as determined by ads served (so my blog won't be in there).

Bonus for 16 Years of Animated GIFs

As you watch this video from PBS, remember that Netscape Navigator 2 really made animated GIFs possible by adding support for and popularizing it, now re-popularized in some odd hipster fascination with low-tech fun (on JS-only sites, of course).

Please don't say Jiff, it's Ghiff. Otherwise you should call it the Jraphic Interchange Format, and that's just silly. Unless you're a hipster too cool to use the accepted name and too young to remember its introduction.

Conclusion

Browsers from 1996 are fun.

Related

• Everything Will Be the New IE6

Read More

HTML5 and Enterprise on Mobile

An Argument

Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That's as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you've read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author's inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as "enterprise" to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn't addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what "enterprise" means.

Security

So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven't been inculcated in an enterprise environment and maybe don't think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the "new shiny" and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn't mean they aren't in the code borrowed from somewhere else, especially if the developer is new to the game.

Synchronicity

I'd like to think every developer has already built a system to lock records — ideally one that doesn't halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don't "log out," and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it's a bit trickier with more likelihood of flaky connections and long wait times. It doesn't need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don't have clean methods of handling dropped connections and can end up leaving users stranded.

While that's not the technology's fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you've been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla's IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren't in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.

• There is no simple solution for local storage by Chris Heilmann;


• PSA: DOM Local Storage considered harmful by Taras Glek;


• In defense of localStorage by Nicholas C. Zakas;


• localStorage, perhaps not so harmful by John Allsopp.

Conclusion

Look to the business case. Don't fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don't fall for the arguments in favor just because of a knee-jerk reaction against "stodgy" enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Read More

The Return of “Best Viewed in…”

The graphic above (and its lengthy alt) is a parody based on a rather neat utility called the HTML5 Please API. You can drop the code onto your cutting edge demo site and it will indicate to a user what browsers support the features within. The code stays current by leaning on data from CanIUse.com

You can see this code in action by grabbing any browser that isn't Chrome or the latest version of Firefox and visiting mothereffinganimatedgif.com, a browser-based utility built in 24 hours to produce animated GIFs.

The feature is great for demo and practice sites, but there is a risk that developers may drop this onto end-user facing sites without building appropriate alternates or back-ups to the features. The language for this project doesn't help:

If you've created a demo or site that requires Canvas or WebSQL DB, you've been in the awkward situation of telling some of your visitors that their browser isn't good enough.

That last part gets me. The first part does, too (demo or site), but the last part is the modern version of "best viewed in Internet Explorer." Those of us who've been doing the web thing since its start know the disdain and disrespect for our users that message entails and have moved beyond such statements. Younger developers who are fascinated with all the "new shiny," on the other hand, may take the explanation as validation that they can just ignore users who aren't on the browser the developer has decided to support.

We have plenty of evidence to suggest that a browser monoculture is coming back, a repeat of the monoculture that we as developers created when we built for IE6 only, and now we rail against as if it's the user's fault.

The ongoing battle over vendor prefixes in CSS is a current example of the Webkit, or perhaps more accurately, iPhone mnonoculture that is developing:

• Browser Makers Caving to Vendor Prefix Misuse on this blog, Feb. 9, 2012;


• Reading List – Vendor prefixes, mobile, monoculture by Bruce Lawson, Feb. 13, 2012.


• The iPhone monoculture by Peter-Paul Koch, Feb. 20, 2012;


• Developers focus on the iPhone too much at .net Magazine, Feb. 21, 2012.

An sample that came across my Twitter feed is a rather nice mini-site called "The New Web Design Guidelines." It uses an attractive design with clean cutting-edge transitions and animations, while promoting support for touch, displays of any size, and exploration. The new guidelines also suggest blocking any browser that isn't Webkit:

For this screenshot I had to scale the page down. It seems designing for displays of any size work as long as the aspect ratio isn't a netbook. Even when I could see the animations (using Chrome) I had the same height problem.

What's so frustrating is that I have seen similar effects on other sites that work fine in Mozilla and Opera, but this developer has chosen to forbid those browsers from seeing the page. If these are truly the new design guidelines, then we may already be too far into a browser monoculture to climb back out any sooner than 10 years from now.

Read More

Ongoing Misunderstanding of Flash and HTML5

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, "What the Demise of Flash Means for the User Experience." To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe's decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe's decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn't anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it's fair to challenge the claim that HTML5 creates "ubiquitous user experiences regardless of device" when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It's also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let's not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of "graceful degradation" and "progressive enhancement."

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author's math doesn't bear out the assertion — by the author's numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author's word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5's doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn't tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn't need to change. The user shouldn't need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don't know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn't do anything to advance HTML5 and its related specifications.

I'd love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Update: May 8, 2012

The BBC makes this same set of mistakes in its piece Coding the future: HTML5 takes the internet by storm.

Read More