Many years ago, the web was a simpler place, in terms of design. After all, it's quite hard to bring anything of visual beauty to your users, when your canvas is monospaced syntax-highlighted text, and nothing else.
The Controlled Grid
The first thing that needs tackling is our relationship with grids and grid layouts. Firstly, I want to make something very clear: I'm absolutely not saying that grid layouts are bad or shouldn't be used. The fundamental principles behind them are well known and tested, and work nicely.
The problem that we've come to confused the cause with the symptom, or rather, our method of implementation with our intended results. Firstly, let's consider the following piece of code:
<div class="row"> <div class="col col6">Column 1</div> <div class="col col6">Column 2</div> </div>
Here we have some basic HTML that we can control with CSS to produce a containing row and two interior columns. Now this was fine in a simpler time when you could be fairly certain that your single 960px-ish wide desktop view would work quite nicely for everyone. Unfortunately, with the explosion of larger screen sizes, mobile devices and tablets, there's two fairly obvious issues that arise:
- If we don't have a responsive design, users on tablets, mobiles and ultra-high resolution devices are going to have a sub-optimal experience
- If we do, on tablets and bigger we've got two columns of equal size, and on mobile they'll (probably) collapse down into a single stacked column. This means we're compromising a large number of our users
Ethan Marcotte's early thoughts on responsive design on A List Apart was a step in the right direction. However, whilst the idea was wonderful, the ways of building it weren't.
The Fault, Dear Brutus, Is Not In Our Stars, But In Ourselves
Our methods for creating grid based layouts tended to revolve around assigning class names to html elements, to create rows and columns, as in our example earlier. Fine in theory, but problematic in practice. The issue is that it creates sub-optimal designs on every view except the one it was initially designed for. It's not that those views would be bad, per se, but that they'll be less elegant than they could be.
So how can we change this?
Well, we need to go back to the drawing board. I used to recommend a Frameless Grid approach, as first imagined by Joni Korpi. However, nowadays I'd suggest using an Adaptive Grid: CSS classes on column elements, starting at mobile and adapting up when required. This way you can have different width elements at different resolutions. For an example of this, take a look at the audio component near the end of Man on the Moon, part of the larger Fly Me to the Moon piece.
As the resolution changes, the main container width changes, and internal elements can be changed (or not) as desired, to ensure consistent usability.
The Rules Of The Adaptive Grid
Firstly, only change layout when it makes sense to do so. Different layouts of different elements make sense at different sizes. As such, we must therefore introduce our next rule...
Second, create a different design for each required layout. The upside of designing in this way is that we can make any sized viewport have a perfect design. The downside is that we do actually have to think about those designs, rather than simply letting the responsive code take care of it itself.
Thirdly, our design must elegantly enhance. Our initial design will be entirely held outside of media queries, and thus be our mobile design. This will be the most basic design for the site; an interface that is designed to be in its simplest form, whilst still retaining all the needed functionality for the site to work.
This means that all other designs (for tablets, desktops, and really huge screens) will be held inside media queries, and served only to browsers capable of handling them. Every device should therefore get the most beautiful layout available to it, in it's most complete form. No browser or device should be treated as a second-class citizen.
The second area on which we shouldn't compromise is text. Type should be beautiful whatever device the user is using, and no matter who they are. So let's set out some basic theory.
Firstly, type should be designed around the user. If they're teenagers with 20/20 eyesight, then it makes sense to use 8 or 9 points for your font size. However, you probably deal with people in their 30's and 40's most, which means you probably want something closer to 11 as a minimum, with 12 being my recommended. People generally find it easiest to read type set around 10 to 12 points, so start with that in mind when you start on your design.
However, it's not quite as simple as that, because if you're not using points, but pixels, then different fonts become different sizes. As a general rule you probably want your type to be at least 3.5mm or higher (I tender to prefer 4+), or around that 10-12 point area, then you probably want a height in pixels of around 14-16px.
It gets even worse though, because you need to control the width of lines too. The longer a line of text is, the harder it is to read. So as a result, you'll want to impose a maximum width on yourself. For the best user experience, stick with something like 10-15 words per line, or around 60-90 characters, dependent on the width of your font.
But not only that, we have to control our line heights too. Generally, if you assume that you want a line height that's between 1.4 and 1.6 times your font size, you won't go far wrong. Again though, test against your font stack to ensure it all looks right.
If you need something a little more visual as a reference point, here's a bunch of font stacks all set to the same size, so you can see how different the actual heights are, despite being set the same:
- font-family: "Hoefler Text", Garamond, Baskerville, "Baskerville Old Face", "Times New Roman", serif;
- font-family: "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Verdana, Tahoma, sans-serif;
- font-family: "Andale Mono", "Courier New", Courier, monospace;
- font-family: Baskerville, Garamond, Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", serif;
- font-family: "Lucida Grande", geneva, helvetica, sans-serif;
- font-family: Baskerville, "Baskerville old face", "Hoefler Text", Garamond, "Times New Roman", serif;
- font-family: "Big Caslon", "Book Antiqua", "Palatino Linotype", Georgia, serif;
- font-family: "Bodoni MT", Didot, "Didot LT STD", "Hoefler Text", Garamond, "Times New Roman", serif;
- font-family: "Book Antiqua", Palatino, "Palatino Linotype", "Palatino LT STD", Georgia, serif;
- font-family: Cambria, Georgia, serif;
- font-family: Constantia, Palatino, "Palatino Linotype", "Palatino LT STD", Georgia, serif;
- font-family: Didot, "Didot LT STD", "Hoefler Text", Garamond, "Times New Roman", serif;
- font-family: Garamond, Baskerville, "Baskerville Old Face", "Hoefler Text", "Times New Roman", serif;
- font-family: "Goudy Old Style", Garamond, "Big Caslon", "Times New Roman", serif;
- font-family: "Hoefler Text", "Baskerville old face", Garamond, "Times New Roman", serif;
- font-family: "Lucida Bright", Georgia, serif;
- font-family: Palatino, "Palatino Linotype", "Palatino LT STD", "Book Antiqua", Georgia, serif;
- font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
- font-family: "Franklin Gothic Medium", Arial, sans-serif;
- font-family: Futura, "Trebuchet MS", Arial, sans-serif;
- font-family: Geneva, Tahoma, Verdana, sans-serif;
- font-family: "Gill Sans", "Gill Sans MT", Calibri, sans-serif;
- font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
- font-family: "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Geneva, Verdana, sans-serif;
- font-family: Optima, Segoe, "Segoe UI", Candara, Calibri, Arial, sans-serif;
- font-family: Segoe, "Segoe UI", "Helvetica Neue", Arial, sans-serif;
- font-family: Tahoma, Geneva, Verdana, sans-serif;
- font-family: "Trebuchet MS", "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Tahoma, sans-serif;
- font-family: Verdana, Geneva, sans-serif;
- font-family: "Avant Garde", Avantgarde, "Century Gothic", CenturyGothic, "AppleGothic", sans-serif;
- font-family: "Brush Script MT", cursive;
- font-family: Copperplate, "Copperplate Gothic Light", fantasy;
- font-family: Impact, Haettenschweiler, "Franklin Gothic Bold", Charcoal, "Helvetica Inserat", "Bitstream Vera Sans Bold", "Arial Black", sans serif;
- font-family: Papyrus, fantasy;
- font-family: Rockwell, "Courier Bold", Courier, Georgia, Times, "Times New Roman", serif;
Everything here has been set at the same font size, so you should be able to see how different fonts are more or less readable. Hence why stacks like the Rockwell/Courier/Georgia/Times one are great for headings, but lousy for body copy, and visa versa for the Optima/Segoe/Candara/Calibri/Arial stack.
Content !~ Design
Secondly, let's talk about contrast. Whilst it's important that a site have a beautiful design, it's not right that we sacrifice usability and readability to achieve this. Aesthetic considerations don't trump real life user experience, for the simple reason that content isn't there as a design element.
So how do we deal with the problem of design, when we decree that we can't compromise content? Simple – make it the linchpin.
Oliver Reichenstein wrote a wonderful piece back in 2006 called Web Design is 95% Typography and followed it up with Reactions to 95% Typography. Bookmark them to read. I'm going to throw out a few quotes here for reference:
Control over typography is not just a basic design necessity, knowing how to treat text as a user interface is the key factor for successful Web design. Successful websites manage to create a simple interface AND a strong identity at the same time.
Yet typography is an old school discipline that requires a lot of studying, repetitive concentrated effort and looking at printed materials. Typography in practice is not choosing fonts or making fonts, it's about shaping text for optimal reading experience.
In a medium that usually makes it very hard to read you have to know the original rules of typography by heart. The rest (colours, line or not, boxes, what picture and how big etc) falls into place by itself.
Hopefully you'll by now understand why responsive designs don't work – they assume that the same structure of layout used on a small screen will work fine on a big screen, if you just make everything wider. But this simply isn't the case. Readability suffers greatly as line width increases. The way users interact with content changes as the size and shape of it changes. It's not enough simply to scale up and hope for the best; we have to fundamentally sculpt our presentation methodology around the viewports that users choose to view our content on, and make sure that whatever the device, the experience they receive is exceptional.
Having just said all that, let's start with something simple. Baseline alignment of text. This is one of those little minor details that helps ensure that a website looks great, rather than simply good. But whilst it's not hard for publishers, that's not the case for web designers. We've got to deal with inconsistent font sizes, alignment controlled through that most mercurial of mediums – CSS, and a lack of consistent rendering across browsers.
Yeah, it's hard.
But it's not impossible. And thanks to the likes of LESS and SASS it's now at least manageable. There's no real magic to it, it's just simply a case of sweating the details. From my own experience with OpenDAWS, I can tell you that forms will be the biggest point of pain. It's not that they're impossible, but that they require far more thinking about than most elements.
My advice would be to start with a framework that already has most of this taken care of already. Unfortunately, there's not many of those around, so you're going to be stuck with either Baseline, OpenDAWS or Blueprint. Alternatively, if you're a masochist, you can do it from scratch yourself.
The Living Design
Over the past couple of years, I've come to advocate a two stage approach to design. In the first step, concept wireframes are produced using your UX wireframing tool of choice. This allows for very rapid design and iteration on ideas. Then, once the initial concept has been agreed, this can be fleshed out into an ultra simple, working functional wireframe built to be used. This then allows for user testing, as your test subjects can actually interact with a real example of the final product.
The upside of this is simple – by restricting the elements we can use to design initially, and then moving to a live, workable version, we avoid unnecessary chrome creeping in to the design. It tends to therefore produce a more elegant, cleaner end product.
Designing In The Browser
As we've gotten more advanced in our tools, a new trend has emerged in web design – moving away from Photoshop and other tools for producing design work for the web, and into rapid prototyping with Visio, Omnigaffle and the like, and then simply building the site layout itself. Thanks to the power of tools like WebInspector, we can design pretty much anything we want on the fly. Then, after the initial groundwork has been done, extra chrome can be added after (if it needs adding at all).
This then creates a new way of thinking about design work for the web – when you're starting off with the content you're going to be using and no set grid, you can choose exactly how wide you want any individual element to be. This means that instead of making a design that's beautiful because of its chrome and artwork, you can make something that's beautiful because it, in and of itself is beautiful.
The downside with this is that it's not as simple. It requires that at the outset, you have all the content that you'll be using (or at least a decent approximation of it). Designing without the content in mind can result in the creation of something that has great visual impact, but doesn't actually work for the user once the copy and other required content components have been put in place. Suddenly elements don't align or you realise that you need extra navigation that you'd previously not accounted for.
The Iterative Website
This brings me on to the final point of modern digital design – it's never done. Unfortunately, too many people believe that you can simply pay an agency to produce a site or an app, put it live and then the job is done. This should never be the case. The instant it's done, you should start conducting tests, as the only thing you'll be able to guarantee is that it's not performing as well as it could. That means that you're leaving money on the table.
And how you go about that will be the subject of the next post. Tune in next week
If You Want It Done Right...
Sweat the detail. Pay attention to every tiny part of your site. And do it yourself, because no-one's going to do it for you.
If you've enjoyed this post, you might want to follow our founder, Pete Watson-Wailes on Twitter