As a follow-on from my recent post on responsive web design (RWD), I thought it might be useful to take a look at another one of the challenges arising from the new generation of computing devices, and at one particular solution we’ve arrived at for our own projects.

The challenge of hi-DPI

Hi-DPI is a generic term used to describe the increased-resolution displays featured in many modern mobile devices and a in small number of very recent computers. Some manufacturers have there own terms for such screens: most prominently Apple Inc. use the trademarked name Retina to describe their own hi-DPI displays.
The term hi-DPI is a contraction of ‘high dots per inch’ and refers to the density of pixels found in a one inch line on the given display. To be considered ‘hi’, the display would typically have a density greater than 160dpi – often much greater.

The popularity of these displays presents a significant challenge to web designers as, ever since the web first gained support for images, we’ve optimised all of our graphics down to the standard resolution for traditional desktop PCs – a lowly 72dpi. Meaning that, although they look ok on old-school displays, these graphics look pretty nasty when viewed on modern devices.

Why should I care?

At Iriss, we’re of the belief that the products we build should represent the best possible quality that we’re capable of producing. While it might be tempting to put off catering for hi-DPI displays until they’ve become the norm rather than the exception, we prefer to ensure that our sites have the highest possible quality of fit and finish for all our users. We also believe that clearer text and graphics aid usability, and further, that catering for hi-DPI displays now is the most future-friendly approach (after all, the number of these displays in circulation is only going in one direction, and it isn’t down).

Designing for hi-DPI

There are many different kinds of graphics on the web (photographs, background images, user-interface elements like buttons and icons, etc), and many different formats that these can be rendered in. Addressing the issues and possible solutions around every one of these is well beyond the scope of this article, so today we’re going to look at just one type of graphic that features in nearly every modern web site, and at one particular solution we’ve arrived at that provides pin-sharp images irrespective of resolution.

Icons

Most modern websites utilise icons for a number of purposes, most commonly to help aid at-a-glance identification of buttons and interface elements. When redesigning the Iriss website in early 2011 we made the decision to use icons to represent, amongst other things, the RSS and social media links in the footer area of the website. Initially, these were realised as traditional images, and coded into the page using text links in the HTML, with CSS trickery seeing those links replaced in visual browsers with our carefully wrought graphics.

However, June 2010 had seen the release by Apple of the iPhone 4 – the first device with a Retina display. Testing the new Iriss site on the iPhone 4 was a sobering experience. The graphics, and the icons in particular, didn’t respond at all well to being displayed at such revealing resolutions. There had to be a better way…

Raster vs vector

Computer graphics essentially come in two flavours – rasters (sometimes referred to as bitmaps) and vectors.

Raster images are dot matrix structures that are mapped out in a pixel-by-pixel rectangular grid. They have a fixed resolution, and can’t be enlarged beyond that without a serious drop in perceived quality (that “enlarge and enhance” stuff only works in the movies). On the web, raster images are usually found in jpeg, gif or png formats.

Vectors on the other hand are stored as mathematical expressions, and are drawn geometrically every time they are rendered. For this reason, vector images are said to be ‘resolution independent’ – since they are drawn anew each time, they can be set to any size at all without loss of quality. The primary vector format for the web is SVG (Scalable Vector Graphics).

Twitter icon zoomed — Raster (left) and vector versions of the same icon at 10x zoom

So SVGs are the perfect solution, right?

Sadly not. Although they’ve been around since the end of the last century, uptake of the SVG format has been slow. Support remains patchy at best, with Internet Explorer versions 8 and under, and older versions of Google’s Android operating system, having no support for SVG whatsoever.

Ah, ok, so that rules out vectors then…

That’s what we thought too. Until, one day while marvelling how crisp text looked on a then newly-released Retina iPad, the penny finally dropped – fonts are vectors too! Typefaces are stored within font files as mathematical expressions, and are drawn at whatever size you need them, just like all other vector graphics. So why not turn our icons into a font?

Icon fonts

The CSS2 specification, published as long ago as 1998, includes something called @font-face. This (somewhat controversial) technology allows web pages to display their text content using a font which, rather than being installed on the user’s own machine as is the norm, instead lives on a web server. This means that we can safely design our own font, put it on our server, and tell the user’s browser to use that font to render certain text and symbols on our pages.

Better yet, browser support for @font-face is generally superb – it even works in Internet Explorer 6 (and nothing works in IE6!)

With our icons having been drawn in Adobe Illustrator (meaning the original source files were already vectors), all we had to do was package them up into the various web font formats that the different web browsers use for @font-face substitutions, then map the various icons to characters that our web site could reproduce. There are a bunch of tools available that will do this work for you, including:

IcoMoon App (hint: this is our favourite)
Fontello
Inkscape (see this article for info on using Inkscape to make icon fonts)

A few minor changes to the HTML and CSS later, and we had our vector icons up and running beautifully on the IRISS website.

Social icons full at normal size on Retina iPad — Icons viewed at normal size on Retina iPad – icon font at top, graphic version at bottom

We’ve since used this method extensively while developing Iriss.fm and Mindreel, and retro-fitted it to another of our online resources.

Typical Mindreel page with icons highlighted in red

Don’t like drawing? No problem

So, unsurprisingly, it turns out that we weren’t the first people to arrive at this solution. If you don’t want to draw your own icons, there are now plenty of ready-made icons fonts available to download and use. However, there are a few potential negatives to be aware of if going down that particular path: some of these cost money to use; most will include many more icons than you’ll ever truly need; many won’t feature all of the icons that you do actually want – and all those unused glyphs contribute to larger files for the user to download.

A better plan in that case would be to leverage either IcoMoon App or Fontello to pick and mix the icons you need from the different pre-made icon fonts they offer. You can then download these as a custom font containing only the icons you want and no more.

Conclusion

While no solution is ever entirely perfect, we’re really happy with the way our custom-designed icon fonts render across both traditional lo-DPI displays and the new hi-DPI equivalents. We’re still evolving how we work with these techniques, and have a few ideas that might further enhance our future projects.

Icon fonts: the pros

Future-proof: provides infinitely scalable design elements
Cross-browser compatible (they even play nice with legacy browsers)
Small file-sizes against comparable raster-based solutions

Icon fonts: the cons

Single-colour only
Sub-pixel anti-aliasing can make them look blurry when rendered at small sizes on some low-resolution displays
There’s a maintenance overhead: changing a single icon requires regenerating the whole font

Hi, I’m Ian and I’m an Interactive Designer here at Iriss. Today I’m going to take a look at Responsive Web Design (RWD), and how we’ve implemented it in a couple of recent IRISS projects.

Background

The last few years have seen a fundamental shift in the way people access and use the web. In 2012 the Internet is no longer limited to your computer screen. It’s just as likely that you’re reading this article on your phone, your tablet, your laptop/netbook/ultrabook (and if you’re reading this a few years down the line, I can only imagine what you’re reading it on!) As a web designer, this new multi-platform, post-PC world presents some interesting challenges.

As a community, web designers are well-practised in the art of self-deception. For years we’ve pretended that we knew, or at least had a rough idea of, the dimensions of the screen that the people who use the things we build will view them on. We embraced something called the 960 grid in the belief that a one-size-fits-all system would streamline our design process while providing a layout that would work for (nearly) all of our end users. We fooled ourselves into believing that something we couldn’t possibly know (the size of our end users’ screens) could be standardised as something we did know. In short, and to channel Donald Rumsfeld for a moment, we had chosen to treat a known-unknown as if it where a known-known. With the rise of the mobile web, however, we’ve been forced into recognising the unsustainability of that delusion: the simple truth is that we have no way of knowing the size, ratio and resolution of the screens on which our designs will ultimately appear. The solution…?

Responsive Web Design (RWD)

RWD can most simply be defined as a method that allows web pages to respond to fit their environment. So when you visit a responsive web page, its design should take our multi-platform world into account, and morph to ideally match the size and shape of the screen you’re viewing it on.

By way of an example, the image below shows the same web page (the homepage of Mindreel) as it would be laid out for a modern smartphone, tablet (in portrait) and desktop computer.

So what is this RWD thing exactly?

While it’s beyond the scope of this post to detail the nuts and bolts of how RWD is implemented, it’s important to understand that RWD is a methodology, not a technology. Responsive sites are built using the same core technologies as every other web page (HTML, CSS and JavaScript) – the differences lie primarily in the ways in which these technologies are used and how they interact. It should be noted though that most implementations of responsive designs rely, in part at least, on the users’ web browser being compatible with the latest versions of these technologies. With modern browsers and devices this isn’t an issue, but it does require a little extra consideration to ensure that our responsive designs work in a satisfactory manner with legacy browsers, such as Microsoft’s Internet Explorer versions 8 and older.

And what it isn’t…

Responsive design doesn’t involve sniffing out different devices or browsers (that way madness lies), and it certainly doesn’t involve the production of separate ‘mobile’ and ‘desktop’ versions of websites. RWD is very much a ‘publish once, display as appropriate’ solution.

Responsive projects at Iriss

So now that we’ve covered the basics of what RWD is (and isn’t), let’s take a look at how we implemented it across a couple of recent projects at Iriss, and some of the key decisions we had to make.

Adaptive or fluid layouts

The first choice that needs to be made when designing a responsive site is whether to use adaptive or fluid layouts. Adaptive layouts use multiple fixed-width designs (ie mobile/narrow/normal/wide) and switch between them as appropriate. Fluid layouts flow the content out to fill the width of the screen whatever it might be, like the same quantity of water poured into either a tall glass or a wide bowl.

Neither approach is ever entirely right nor entirely wrong, but both bring issues and compromises. Adaptive layouts can result in wasted space where the screen size used falls between the sizes you offer, and you need to make a call on just how many different sizes you’re willing to cater for (which becomes crucial once we get down to the difference in screen width between the millions of smartphones in circulation). Similarly, while fluid designs mean not having to make difficult decisions about where you draw the lines of your supported screen widths (remember, they’ll flow to fill the available space, no matter how narrow or wide it may be), they often do so at the cost of undesirable intermediary stages. For example, if we look at the excellent North Lanarkshire’s Working website, although its fluid design works very well at the extremes (smartphone and PC), it works less well for devices that fall in between (such as some tablets).

That’s not to suggest that the North Lanarkshire’s Working website is flawed or badly designed in any way – it’s an excellent piece of work – but it does illustrate the compromises that, as designers, we sometimes need to make.

What about a hybrid approach?

At Iriss, we’ve settled on a hybrid, or mixed, approach for screen layouts. For both Iriss.fm and Mindreel, we opted for a system which uses adaptive fixed-width layouts for narrow, normal and wide layouts (covering everything from the most popular brand of tablet to desktop computers) but switches to a fluid layout for anything smaller. This means that all smartphones, most e-book readers and smaller Android-based tablets will get a version of the narrowest layout, but flowed to fill their screens, while larger devices will get a carefully considered fixed-width layout that’s better suited to their larger screen real estate.

Counting columns

For Iriss.fm we arrived early in the development stage at a design which presented content (episodes, contributors, etc) as a number of panels arranged in columns on the page. This meant that we were faced with a decision as to what we prioritise across the different screen sizes – do we keep the same number of columns and make the panels progressively narrower across smaller screens, or do we preserve the width of the panels at the cost of reducing the number of columns? In the end we did a little of both.

We settled on a solution that uses a three-column grid for both normal and wide layouts (changing the panel width as appropriate), then we drop to a two-column grid for the narrow layout, before finally going down to a single-column layout for the fluid ‘smartphone’ version. The wireframe below shows the difference between the normal, narrow and mobile layouts, as they’d appear on an iPad held in landscape (normal) and portrait (narrow) orientations, and also on an iPhone (mobile).

In addition to varying the number of columns across layouts, we also elected to modify the amount of information that we’d show the user in different layouts of the homepage. The graphic below shows wide, narrow and ‘smartphone’ layouts: note that we reduce the number of panels in the ‘episodes’, ‘contributors’ and ‘tweets’ fields as we switch from three-column to two-column configurations (from six/three/three to four/two/two). We chose to do this partly to present a more appropriate amount of content given the screen area available, but also to ensure there was no excess white-space resulting from having an odd number of panels appearing across an even number of columns.

Prioritising content

As the above illustrates, designing for smaller screens isn’t just a matter of adjusting layout. Sometimes you need to adjust the amount of content too. With both Iriss.fm and Mindreel we spent some times prioritising the content and, where appropriate, took the decision to hide some tertiary content from very small screens. The image below shows the contrast between the footers of the normal and mobile layouts of a page on Mindreel.

In this case we chose to hide the footer navigation (which is merely a repeat of the primary navigation for convenience), the email link and also to simplify the Twitter link and IRISS credit. Note, however, that we added a ‘back to top’ link, as some of the pages on Mindreel can get quite long when rendered in a single column format.

Getting around

One of the greatest challenges faced when implementing a responsive design is deciding what to do about navigation. In the past, navigation on web sites has generally tended to be either horizontal along the top of the page, or listed down the left-hand side.

For both IRISS.FM and Mindreel, we settled on the traditional horizontally arranged list as the best solution for wider screens, but quickly realised that wasn’t going to work for smaller mobile devices. After looking at several possible ideas, we eventually settled on an off-canvas solution. In both cases we chose to move both the primary navigation and site search field off the top of the screen. We then introduced a three-bar icon (the new de-facto standard for fly-in menus) which toggles the navigation area at the top of the screen.

Making it all work in legacy browsers

Unfortunately, as mentioned above, none of this responsive design work will be available for people stuck using legacy systems. RWD, at least as we implement it at IRISS, relies on something called media queries to determine the width of the screen that the site is being rendered on. Media queries are part of the CSS3 specification and, as such, aren’t supported by older browsers such as Internet Explorer 7 & 8.

Our fall-back solution for people forced to persevere with these older browsers is to ensure that they receive the ‘normal’ fixed-width layout, which is based around the familiar 960 grid. As, by definition, these users aren’t on modern mobile devices, we can safely assume that their screens will mostly be able to display that width of content without too much difficulty.

Without wanting to get too much into implementation details, we serve up this layout, not by trying to sniff for old versions of Internet Explorer (which would be a REALLY unreliable way to do things), but by testing for support of modern CSS. In simple terms, our sites ask:

“Do you understand what media queries are? If so: great! do this; if not, that’s ok, just do this instead.”

Conclusion: The only constant on the internet is change

These are just a few examples of the ways that we’re using responsive design at IRISS. It’s our hope that working this way helps us create the best custom solutions for the widest range of users on an ever-expanding range of devices. We use RWD to improve the products we make and, to some extent at least, to future-proof them too. It’s not an absolute final answer and, as a recent development, best practices are still being established. However, we believe that working this way allows us to tailor our content to best suit all of our users, irrespective of the technology or device they’ve chosen to access our content from. And that was kind of the point of the web all along.

Author: ianphillip

Resolution-independent icons with custom icon fonts