How to design for hi-res displays

Web design specialist Christopher Schmitt has a positive response to the question of whether we should be factoring hi-res displays in to our design methodologies: “We used to have browser wars. Now we have tablet wars. The marketplace will only become more saturated with hi-res displays. This must be addressed, because the issue won’t go away.” And he’s not alone. “The fact is, practically every smartphone and tablet now has a hi-res screen, and desktops aren’t far behind,” agrees JavaScript guru Thomas Fuchs. “But wait too long to respond and you’ll be left behind.”

Not everyone is as gung-ho. “I don’t like the idea of designing a second set of hi-res images for Retina and using JavaScript to serve them based on the receiving device,” complains Happy Cog founder Jeffrey Zeldman. “That feels like a giant step back to the days of ‘best viewed with …’ That’s not what standards-based design was supposed to be about.” Interaction designer Wells Riley notes that tech heads can be “caught in a bubble, especially with new Retina MacBooks on their desks”, but admits that it could be time to “invest brainpower in adopting a new technique”.

For designer and author Andy Clarke the argument is simpler: “If you’re a web professional, you owe it to clients and users to make your site look its best on every device you can. That means designing and developing for high-resolution displays.” He adds that the one-way trend is toward higher resolution and, like Fuchs, Clarke reckons designers should by default add hi-res support to new projects and upgrade old ones when possible. “It’s something you can’t leave to chance,” says Treesaver co-founder Roger Black. “Some sites got lucky, but then you see hapless bastards sending magazine apps as a book of PNG files, [and] text dithered so badly that you can’t read it …”

Steps to hi-res

By starting immediately, frontend web developer Todd Motto says you won’t need to ‘upgrade’ older sites at a later date. But with devices, connectivity and web standards far from stable, it pays to plan ahead. “If I have a hi-res iPad but a slow connection, do I want to wait for a hi-res image?” asks Zeldman. “There’s no way to know for sure. In a world where mobile is more and more important, and bandwidth is less and less consistent, serving Retina-optimised images doesn’t seem like a great idea.”

Designer and developer Mat Marquis also urges caution. “Two billion people access the web. Most are in Asia, with a huge number using feature phones and paying for every kilobyte they consume.” His point is that they consciously avoid bandwidth-heavy sites, and designers must be mindful of catering for this market. “It’s irresponsible to saddle users with additional economic costs for enhancements they won’t benefit from. To build ‘Retina by default’ thinks only in terms of our own privileged context – sharp images for the sake of our $3,000 laptops, delivered via nigh-unlimited bandwidth.”

Initially, then, the key is to prioritise. Freelance designer Paddy Donnelly suggests serving a hi-res logo, which “makes a big difference in how people experience your brand on a Retina display”. Tackle icons next, he says, because “they can become unrecognisable when scaled up”. For other aspects of a site, Kitcatt Nohr Digitas technical director Mo Morgan suggests focusing on the relationship between content and users: “There are contexts where users will benefit from higher resolution, such as images of goods in an online shop. It’s hard to conceive why a user wouldn’t want to see more clearly something they might buy.”

A change of process

The thoughts outlined so far showcase how hi-res has disrupted web design certainties. “We’ve spent 20 years saying we build sites to be browser-agnostic, but it was a white lie,” says Schmitt, reasoning that assumptions were often made about 960-pixel widths and 72 points per inch. “Now the truth has been exposed, we must think about designs as a series of conditions that create different flavours of a design.”

Morgan believes this ‘mixed state’ should prompt reassessments regarding production. “If you’re building a site and it can’t justify specific considerations for hi-res today, that doesn’t mean it won’t in future. And there’s nothing to say we won’t see even higher-res displays.” To make transitions painless, he recommends no longer considering site repositories as snapshots of an ‘end product’, with heavily optimised assets. “Hi-res devices remind us that it’s important to version the sources of such assets, including print-quality images and vector illustrations. We don’t know when we’ll need them again, but it’s likely we will.”

Mobile strategist Jason Grigsby agrees, and advocates storing and uploading all assets at the highest available resolution. “The photograph that seems too large to ever make sense online may later come in handy when everyone’s using Ultra HDTVs in their homes. But trying to track down source files later is expensive when everyone has left a project.” Beyond photography, Fuchs thinks “it pays to have artwork as vectors whenever possible”.

An uncertain future

Grigsby, Fuchs and others are thinking ahead. While you shouldn’t waste time optimising for pixel densities that don’t yet exist, there’s no harm in planning for what might be. “It would be foolish to restrict our thinking to x1 and x2 images,” believes designer and developer Dan Eden. “Pixel densities are likely to keep on getting more intense, but can you imagine serving images at x1, x2, x3, and x4 sizes?” He too favours vectors, and also CSS3 for scalable elements such as buttons, along with content management systems such as WordPress, which automatically generate multiple resolutions for uploaded images.

Clearleft frontend developer Josh Emerson concurs, arguing you should only aim for ‘x?’, because just as you can no longer predict the viewport size of a user’s display, soon it won’t be possible to predict resolution density. “Embrace the uncertainty of the future by recognising everything you don’t know and designing for it,” he suggests.

There are further uncertainties to come, based on the way higher resolutions will affect content. Photographer Will Fallon says that although existing kit produces imagery suitable for high resolutions, “the margin for error is significantly reduced, and so creative briefs and planning become significantly more important”. He believes that photographers will soon be clamouring to upgrade cameras accordingly, and the creative freedoms they enjoy within the web environment could be curbed. Typography is another heavily affected area, because screens are evolving from obvious pixellation towards a state similar to print. “But everything is relative,” warns Black. “A Retina display is not as sharp as a laser printer. For reading, I still recommend fonts designed for small text, like Verdana and Georgia, or Reading Edge fonts from Webtype.”

Although industry figures also enthuse about the freedom of the modern web regarding fonts and high resolutions, freelance designer Oli Studholme agrees with Black that ‘default’ fonts aren’t necessarily a bad idea: “If you’re using high DPI images, perhaps a default font for body text is a worthwhile concession for performance.” He adds that while hi-res displays do show off a font’s details, that’s not always necessarily a good or a bad thing: “Fonts originally designed for print tend to work well, but these screens are still new and foundries are still adapting to them.” Furthermore, Emerson notes that such displays might be more accurate, but they “don’t magically improve someone’s eyesight, nor make them more compelled to read long paragraphs written in some fancy script font,” and so maintaining legibility is key.

A plan of attack

Abstracts are fine, but at some point you must embrace current reality and start working with assets, markup and CSS in a manner that works with varied displays. Numerous techniques exist for production and application, depending on the content you’re working with. With raster images, Studholme recommends taking care to create content that divides easily and downsizes well, avoiding odd-pixel widths in x2 images. “Get familiar with scripting your image program to spit out the sizes you need, possibly in multiple formats to compare which is best for each size,” he says, adding that logos and favicons are a great place to start. With larger images, experiment with compression. “I’ve found an image compressing better in PNG at normal resolution and JPG at high resolutions,” notes Studholme; and as pixels are almost impossible to resolve on hi-res, you can often get away with heavier JPEG compression than when exporting for standard displays.

It’s also important to realise when to avoid using images entirely. Studholme says: “Text is always hi-res, so avoid text as images. Use CSS3 for bling like drop shadows. If you have monochrome vector-based images like icons, consider icon fonts or SVG. Best practices – such as designing from the content out, progressive enhancement and responsive web design – also give you a solid base.” Bjango director Marc Edwards warns to carefully test image output, though, rather than making assumptions: “Interface elements created entirely in CSS scale infinitely, but can be a performance bottleneck if overly complex. SVG is good for glyphs and icons, but being vector and drawn at runtime it can cause performance issues if the image is too elaborate. Image fonts have great browser support, but they’re difficult to create and maintain, and don’t offer pixel-level precision.”

Coding techniques

For markup and CSS, Clarke first optimises site furniture using CSS background images and CSS3 media queries. This technique allows the browser to react to a device’s pixel density by serving the appropriate image. For inline images, Motto reckons you need more control, advocating using an <img> tag with a 50 per cent reduced width. This, he says, works especially well for logos. Essentially, you use a logo at double the size you want it to appear on the hi-res display, and define width and height values at half of its dimensions in CSS (using rules such as #container img).

JavaScript should be avoided, according to Fuchs, except for backwards compatibility with SVG. “It’s unnecessary and increases load times,” he says. “Instead, you can usually use a hi-res image, design for Retina and let browsers on non-Retina screens scale images down. This will also help with mobile devices where people zoom in to read – images will appear crisper because the resolution is higher.” Exceptions, he notes, are icons and small type in graphics: “You’ll want separate versions – normal and hi-res – there to tweak icons pixel-by-pixel if necessary.” It’s also important to remember to compress when serving larger images.

Marquis has an opposing viewpoint regarding scripts, and advises exploring a few to see if they suit your purpose. For hi-res content images, he swears by Scott Jehl’s Picturefill, which “mimics the behaviour of the proposed <picture> element using standards-compliant markup and attributes”. Unlike many ‘standard versus hi-res’ solutions, Picturefill avoids a redundant request: “Rather than requesting the standard image and then optionally requesting the hi-res image, it only requests the image appropriate to the user’s context.” There’s also a branch that enables the user to define a site-wide preference, potentially satisfying the issue Zeldman mentioned earlier.

Additionally, Marquis reckons that the pain of preparing fallbacks for non-SVG browsers can be eradicated with Grunticon, a plug-in written for Ben Alman’s Grunt.js by Filament Group. Grunticon takes a directory of SVG icons and creates a stylesheet of in-lined SVG icons, a stylesheet of in-lined PNGs (for browsers that don’t support SVG but do support data URIs), and a stylesheet linking to a set of PNGs the old-fashioned way (for older versions of IE). “Having only used it in production a handful of times, I already can’t imagine going back to juggling sprite sheets,” enthuses Marquis.

Spec to the future

In part, disagreements over technique and methods stem from the fact that standards are scrabbling to keep up with increasing resolutions. Few designers blame standards bodies and browser makers, but they still have wishlists. “We need an image format storage solution that would store many resolutions of an image, and the browser could pull the one it needs,” posits Schmitt. Emerson agrees, adding this could reduce sprite use, which he sees (alongside icon fonts) as a hack: “We abused background-position and display: none to reduce requests and provide one image rather than 100. I’d like to see a format that allows many images to be bundled into a single file, and gives each image a namespace so we can specify which image to use with something more friendly than background-position: 0, -100px. This could be a zip file containing a bunch of assets, and the namespace would be their filenames.”

There are also calls for browser intelligence related to network speed. “Eventually, we’ll head towards content negotiation where a browser decides what resolution of content it would prefer based on network and user preference – similar to video now – but we’ll have to muddle on for the time being,” reckons Studholme. And Black hopes the W3C will define an “absolute size for CSS, like the metre-long platinum bar in the French National Archives”. He recalls that “size weirdness on the web” began with Microsoft in the 1990s, and we gave up points for pixels. Now we’re moving to a point where we can’t predict the size of pixels.

We have the tools we have, however, and Riley’s advice is to use them and not worry too much about what may come several years down the line: “Most web projects have a short shelf life – a five-year-old site is practically ancient. But what if 3D is the next revolution? Or holograms? No one can anticipate what’s going to happen in one, three or five years.” Hi-res or otherwise, he thinks if a site suddenly doesn’t work under new constraints you’ll probably redesign it anyway, so just take advantage of what’s currently available."

This article first appeared in issue 235 of .net magazine – the world's best-selling magazine for web designers and developers.

Liked this? Read these!

• Eye-popping examples of parallax scrolling websites
• Delight in these top examples of JavaScript
• The best infographics on the web
• Make your apps work for you! Splendid IFTTT recipes