Archive for the ‘Visual Design’ Category

How Do You Use Responsive Images?

That's a lot of screens, are your images ready? (testing using Adobe Shadow). Photo: Adobe.

No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants their images to look good on the multitude of screens connecting to today’s web. Finding the balance between the myriad factors — screen resolution, screen size, bandwidth, layout and design — is a tricky process.

We’ve looked at a number of techniques for handling images in responsive designs, but one thing that we haven’t covered is where to put the actual breakpoints.

You’re probably familiar with breakpoints in responsive design, they’re the screen widths in your media queries. For responsive images the idea is the same; a “breakpoint” is the screen size at which you swap in and out different size images.

At first glance it might seem logical to use the same breakpoints for your images that you’re using in your CSS media queries, but as Cloud Four’s Jason Grigsby writes, that’s not always the ideal solution. Grigsby tackles the potentially tangled question of breakpoints in a new post, So How do You Pick Responsive Images Breakpoints?

To simplify what can be a very complex question, Grigsby ignores some scenarios, including the so-called “art direction” use case where images are optimized (cropped differently, for example) for different screens. Instead Grigsby focuses on the question of how to best select “different image files with different resolutions of the same image based on the screen size.”

The simplest solution is to just make your image and responsive design breakpoints the same, but that’s rarely going to be ideal for your site’s visitors. Here’s what Grigsby has to say about using the same breakpoints for both image and media queries:

If we were talking about the art direction use case, then it is likely that the breakpoints would be the same because changes in the layout might also indicate an edit to the image.

But in the case where we’re simply changing files to provide different resolutions and a faster download, the image breakpoints should be determined based on when the browser is downloading an unnecessarily large file.

The main problem is, what constitutes an “unnecessarily large file”? But even if you answer that, as Grigsby writes, you still haven’t answered every question:

How do you determine what is an unnecessarily large file? Is that 1 byte? 10k? 20k?

And if you can answer that question, how do you determine the resolutions at which those file size jumps are going to occur? Depending on the content of an image and the compression algorithm used, images are likely to have different resolutions at which they experience significant changes in file size.

In the end Grigsby doesn’t yet have an answer to the question of how to handle responsive image breakpoints. And neither do I. There just isn’t an easy answer that will work for every project. My thinking, and what I’ve done on my own site, runs pretty much along the same lines of Eric Portis’s comment on Grigsby’s post. If you’ve got ideas, head over to Cloud Four and let them know how you’re doing it.

File Under: Visual Design

Source Sans Pro: Adobe’s First Open Source Type Family

Image: Adobe

Adobe has released a new open source font family by the name of Source Sans Pro.

You can check out and download the various font weights and styles in both OTF and TTF formats from Adobe. There’s a PDF glyph sample available as well. Both Adobe Typekit and Google Web Fonts are serving up hosted copies, if you’d like an easy way to use Source Sans Pro on your website.

Source Sans Pro makes a nice headline font on the web, with a nod to classic News Gothic headline fonts of the early 20th century.

Adobe typeface designer Paul D. Hunt created Source Sans Pro. “I was drawn to the forms of the American Type Founders’ gothics designed by Morris Fuller Benton…. I have always been impressed by the forms of his News Gothic and Franklin Gothic,” writes Hunt on the Adobe Type Blog. The goal behind Source Sans Pro was to create a font that’s “both legible in short UI labels, as well as being comfortable to read in longer passages of text on screen and in print.”

Adobe’s plan is to use the new font in its open source applications, and indeed Source Sans Pro is already part of the WebKit-based code editor, Brackets. An earlier incarnation was used in the Strobe Media Playback framework. (in Strobe, Source Sans Pro is known as Playback Sans).

In addition to the font itself, Adobe is releasing the underlying source materials so that anyone who’d like to can modify Source Sans Pro to suit their whims. Source Sans Pro is available under the OSI-approved SIL Open Font License.

File Under: JavaScript, Visual Design

Prism: Beautiful Code-Highlighting for the Web

Deliciously meta: the Prism source code, highlighted with Prism. Image: Screenshot/Webmonkey

Prism is a slick new JavaScript library that adds a very attractive syntax highlighter to any website with a mere 1.5KB (minified & gzipped) of extra bandwidth.

PrismJS started life as the highlighter for Dabblet (which we looked at previously), but popular demand convinced developer Lea Verou to extract the library and release it as a standalone project.

Even if you’re happy with Pygments or another popular syntax highlighter, Prism is worth a look if only because its default syntax highlighting color schemes are beautiful.

Other things we like include the ability to add new color schemes and languages, as well as a plugin system for extending Prism. For the launch Verou has made three plugins available — line highlighting, a “Show Invisibles” tool and an autolinker to make URLs and emails in source code clickable. We also like the fact that Prism doesn’t force you to use any Prism-specific markup; just use <code> tags, along with the recommended way to define a code language in HTML 5 — by adding a language-xxxx class — and Prism does the rest.

As with anything cool on the web there is one catch to be aware of — namely Internet Explorer 8 and below, which Prism doesn’t support. It shouldn’t cause any problems for older versions of IE, but those users won’t see the pretty code highlighting.

For a full list of features — and a few limitations to be aware of — head over to the new Prism page.

Make Sure Your Site Looks Good on the New Retina MacBook Pro

Apple's MacBook Pro with Retina display in a glass case at the Worldwide Developers Conference. Photo: Jon Philips/Wired


The high-resolution web isn’t just for iPads anymore.

Apple is bringing high-resolution screens to the laptop world with the debut of the new MacBook Pro. With over 5 million pixels on the screen, Apple’s rebirthed workhorse, announced Monday at WWDC, offers double the screen resolution of most laptops.

That’s awesome news for anyone upgrading to a new laptop, but like the high-resolution iPads before it, the arrival of the Retina-equipped MacBook Pro is sure to cause some new dilemmas for web developers who’d like to offer a better experience for high-resolution screens.

These screens aren’t going to break the web; pixels are doubled, so Retina’d visitors will see the same layout in the same physical dimensions as non-high-res visitors. But the increased pixel density means you can serve up sharper, better-looking graphics. And there is a small downside — ordinary graphics, particularly icons and logos, can look fuzzy on high-resolution screens.

There are a couple of solutions to this problem. You can use icon-fonts instead of image sprites. Most fonts will scale and render crisply on both high-res and traditional screens. Another tactic is to switch your icons and logos to SVG files. After all, SVG stands for Scalable Vector Graphics, which is pretty much exactly what the doctor ordered for high-res screens. The main problem with the SVG format is that not every web browser supports it. Most modern browsers do — the pain points are Internet Explorer 8 and below, and Android 2.3 and below. How much that affects your site will depend on your audience. Check your visitor stats and choose accordingly.

Icon fonts and SVG offer future-friendly solutions, but if you just want a quick fix to make your site’s logo look sharp on high-res screens there’s a third way: using media queries to swap in bigger images. To make this work, just create a version of your logo that’s twice as big and use a media query to target high-res screens.

Suppose you have your logo in a tag with the class “logo” and the actual size you want the image to appear at is 100px by 100px. Start by creating a copy of your logo that’s 200px by 200px.

Next, here’s what you’d add to your stylesheet to target high-res displays:

@media only screen and (min--moz-device-pixel-ratio: 2),
only screen and (-o-min-device-pixel-ratio: 2/1),
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min-device-pixel-ratio: 2) {
    .logo {
        background: url(/path/to/my/highreslogo.png) no-repeat;
        background-size: 100px 100px;
        /* rest of your styles... */
    }
}

The key to this code is the background-size rule, which tells the browser to scale the image down. The other thing to note is that all browsers currently require a prefix in the media query, and Opera requires the ratio be expressed as a fraction. The one caveat to this approach is that the high-res MacBook will apparently offer some options for how its plethora of pixels are used. You may want to experiment with different min-device-pixel-ratio options to see which works best in the various display settings.

So, there are three ways to handle graphics served out of your stylesheet, but what about good old inline images served up with an <img> tag? Well, that’s more complicated, and in fact there is no ideal solution yet. The WHATWG and the W3C are working on standardizing a solution, but all we have right now are some (often clever and useful) hacks, each with its own pluses and minuses.

For a primer on serving up different images based on screen size, see our earlier write-up on responsive images. It’s also worth reading up on Adaptive Images.

If you’re worried about legacy sites suddenly looking very bad, fear not. They won’t look any worse than they do on the most recent iPad. The sky isn’t falling, it’s just getting bigger. Sure, your images might be a little less than crystal-clear on Retina displays — particularly logos and icons, while photos will generally look fine — but layouts and structure will continue to render as they always have.

Cure the High-Res Blurs With SVG and Icon Fonts

The high-res future is coming fast. Photo: Ariel Zambelich/Wired.com

The rise of high-resolution displays means that web developers need resolution-independent graphics. The good-old PNG icons we’ve been relying on just aren’t going to cut it for much longer.

It’s true that a slightly blurry icon or logo on the iPad probably isn’t going to ruin a site by driving visitors away in droves, but it is a problem, and one that will only become more obvious as higher-resolution screens proliferate.

At the moment there are essentially two ways to swap out your PNG icons for something a bit crisper: icon-fonts or SVG graphics. Naturally, neither is perfect — the last time something worked perfectly on the web Tim Berners-Lee and friends were the web’s only users — so it’s worth looking into the advantages and drawbacks of each.

That’s exactly what UIX designer Simon Uray recently did, breaking down the good and the bad of both icon fonts and SVG images. Give Uray’s post a read for the finer details on both, but here’s the short story: icon fonts are probably your best bet at the moment, though you’ll have to live with the fact that some icons are a tiny bit blurry on traditional displays.

Since at the moment the vast majority of screens on the web are not high resolution, adopting icon fonts over the PNGs you’re using now might be a case of premature optimization.

As Uray writes, “sorry, if you’re looking for a silver bullet, I’m afraid it doesn’t exist.” To that we might add “yet.” But SVG support in browsers (one of the chief problems with SVG is that it isn’t as widely supported as icon fonts) continues to improve. There’s also always the option to use them all. “Maybe best,” writes Uray, “is to use PNG served in many different sizes for your high fidelity, multi-color logo and other graphics… SVG icons for your navigation that stays the same size, but also look sharp on Retina displays [and] Responsive inline SVG for bars and charts and an icon font for all your different button sizes.” The best of all worlds.

For more on icon fonts, be sure to check out Chris Coyers interactive write up on how to use icon fonts.