Wizards, Rockets and Exploding Heads: why designers should code

June 30, 2011 by Pete

There’s continual debate within the web design community as to whether designers should (or indeed can) write code.

The answer is that yes, designers can code, and yes, designers should.

Why you should code

Efficiency – You’ll work better with developers

If you know how websites are built, developers won’t send work back to you with an apologetic “sorry, we can’t build it quite like this”, because all those carefully considered decisions around typography and layout that you made will have been better informed.

You’ll have more control over the design

A Photoshop comp isn’t a design, its an artist’s impression. That italicised Georgia pull-quote may look beautiful in Photoshop, but it may be almost illegible rendered in Windows. Designs almost always need to be revised once they’re in the browser.

Additonally there are always dozens of pages, elements, fringe-case situations etc that aren’t covered by those Photoshop comps, and someone needs to design them. You might be lucky to be working with a developer with a good eye, but you might not, and micro-managing a less design-savvy developer is inefficient to say the least.

If you can build sites as well as visualise them in Photoshop you will be able to adopt far more flexible design processes. I routinely switch back and forth between designing in Fireworks and designing directly in the browser with CSS. Its a fluid process that works well for me, and I bet it would work well for you too.

Being able to build your own designs, and have full control over every nuance, is a great thing.

Be prepared for the future!

There’s a real momentum gathering around the idea of responsive web design – in a nutshell, websites that adapt themselves to a wide range of screen and device widths, with no fixed layout. For obvious reasons it is very hard to design such sites without taking the design into the browser, and playing directly with CSS.

You’ll be more employable

Being able to design and code means that you will be able to dive in to help out in a wider variety of situations. That makes you a greater asset to any team, and especially attractive to startups, who often don’t have the resources to employer both a designer and a developer. And if you’re freelance, you’ll have a wider choice of gigs.

Why you can code

Some designers feel they can’t code, or that they could but that it would somehow dilute their design skills. Many designers are discouraged from doing so.

All these barriers are based on two myths.

MYTH 1: You can’t do both – they’re a different mindset

There’s a widely believed myth that designers and developers have different mindsets, and that it simply isn’t possible to do both jobs well.

That simply isn’t true.

Contrary to popular belief, using both the left and right hand side of your brains doesn’t make your head explode. It can be done. Many great contributors to culture and science, like Leonardo da Vinci, have done it.

I think its true that some developers can’t design. Design requires an innate ability – without it, all the design principles in the world won’t make a developer a great designer.

And I think its true that there are few designers that can become equally great back-end developers (by which I mean all the really hardcore programming and database stuff).

But I’ll let you in on a secret…

CSS isn’t rocket science

This is rocket science:

rocket science

Pretty damn complicated, isn’t it? You’d have to be a rocket scientist to understand it.

This is CSS

rocket science

‘p’ stands for paragraph. You can guess what the rest of it does, I’m sure.

CSS is written in something approaching English. HTML is pretty straightforward once you’ve learnt it. There’s no logic involved, no calculations, nothing to make your brain explode. You just need to take the time to learn it. Trust me, it feels more like a craft than a science.

MYTH 2: Designing and Coding means you can’t become a specialist in either

When I was a kid I used to play Dungeons and Dragons. In that game, players would choose a profession – a fighter, a wizard, a priest etc. On their adventures players would gain experience points for using their profession’s skills. As they gained more experience, they would become more powerful. A Level 10 Wizard was far more formidable than a Level 1 Wizard, for example.

But you didn’t have to choose just one profession. You could become a fighter-wizard, for example. A fighter-wizard would take longer to progress through the levels, as experience points would be divided between the two professions. It would take a fighter-wizard twice as long to reach Level 10 than a fighter or wizard would. But crucially, they would have the exact same skills and proficiency as their single-profession counterparts when they got there.

If wizards can do it…

The analogy is obvious, and accurate.

Some would argue that if a designer concentrates purely on design for 10 years, rather than dividing their time between design and development, then they’re going to be a better designer.

But I would take issue with that. First, how much better would they be? The more experienced we become in something, the slower our skills grow – there’s a much greater difference in ability between someone with 1 years experience and someone with 10 years experience than there is between someone with 10 years experience and someone with 20 years experience.

I’d also argue that when it comes to web design, that an understanding of front-end development is itself crucial in making you a better designer.

A designer who codes is a specialist

Besides, what constitutes a specialist? I don’t do all aspects of design – I don’t do print design, and I don’t do campaign work – I design interfaces. Similarly, my development skills are concentrated on developing interfaces, not any of the ‘behind-the-scenes’ stuff. I am, in essence, a specialist in interfaces.

I’m at least as specialised as a designer who specialises in ‘design’, working in both print and digital, or a developer who writes both front and back-end code. The only difference is that my skillset overlaps two more generalised areas.

Summary

Being a designer who codes isn’t as hard as some people make it sound. Nor does it make you a worse designer. It makes you a better designer.

So why not give it a go? You may even enjoy it.

A pragmatic approach to responsive web design

June 23, 2011 by Pete

There’s a lot of talk these days about ‘responsive web design’, and I believe that the techniques and approaches that it encompasses are going to prove invaluable as we design new sites for an ever widening range of different devices.

Retro-fitting responsiveness

But those techniques don’t need to be limited to new designs or major re-designs. They can be applied to existing fixed width sites to improve the experience for users on handheld devices. And though adapting an existing fixed width site so that it behaves more responsively can seem like a daunting task, it can actually be relatively painless.

I’m going to share my experience of doing so on a site I built for an artist’s portfolio, and highlight some of the techniques and decisions that were made.

The site

The site was initially prototyped in HTML. Layout, typography, colour palette etc were then explored within Fireworks mockups and then developed and refined within the prototype itself. A few markup tweaks later and the site was essentially done.

The problem

The site was fixed at 960px wide. It worked fine at desktop resolutions but was fiddly to use on mobile devices, requiring an awful lot of scrolling and zooming to look through the artwork.

A pragmatic approach

In retrospect I should have taken a responsive approach from the outset, eg. allowing images to stretch/shrink to best serve the many resolutions they might be viewed on. But rather than try and retro-fit an ideal approach, I wanted to see how quickly and easily I could fix the biggest issue – the need for better presentation on mobile devices.

Setting up

First I added two media queries to my global stylesheet – one to target mobile devices (ie. device widths 480px and below), and one to target anything larger than mobile. Anything outside of these queries would be applied to all devices. It then became a simple process of moving existing styles into the second query if I didn’t want them to be applied to mobile devices, and adding new mobile-specfic styles to the first query.

The changes for mobile

Page widths

The site is currently fixed at 960px. I wanted it to be full width of devices up to 480px wide, so changed the page width to 90% for device widths 480px and below.

Navigation

The tabbed navigation simply doesn’t work. If shrunk down the fit a small screen it becomes impossibly fiddly to use. I’ve re-styled them completely, ensuring they have large hit areas, and allowing them to stretch, in a manner similar to that demonstrated by Ethan Marcotte’s ‘Responsive Web Design’.

Desktop

Mobile

Mobile (landscape mode)

screenshot of navigation on mobile landscape mode

Title

The graphical title didn’t work well with the revised navigation, so I moved the image-replacement technique to the larger-than-mobile media query and re-styled for mobile devices using the Typekit styles used elsewhere on the site.

Desktop

screenshot of page title on desktop

Mobile

screenshot of page title on mobile

Line-height

There’s a generous 1.8em line-height on some passages of text on the desktop version that feels uncomfortable on the mobile version when those passages are reduced to less than 300px wide, so I reduced it accordingly.

Background imagery

The CV page has a large typographic background image that makes no sense when cropped on the mobile version, and looks fussy when scaled down to fit. It is simply removed from the mobile version (by moving the image out of the global styles and into the larger-than-mobile query).

Whitespace

The desktop version uses a generous amount of vertical whitespace in its compositions to group elements together, and to give the design an airiness. In the linear mobile version the whitespace breaks the flow of the page, and so I reduced it.

Desktop

screenshot of whitespace on desktop

Mobile

screenshot of whitespace on mobile

Hover states

Obviously hover states on links have no value on a touch-screen mobile device, so all hover states are moved into the larger-than-mobile query (though I could have left them for the benefit of some future hover-sensitive touch screen device). I then double-checked that there were enough visual cues for links after those hover-states had been removed.

Homepage Carousel

I’ve removed the carousel on the homepage entirely for mobile devices using a simple (albeit crude) “display: none”. The decision to do this is more of a hunch than anything – a feeling that users on a mobile are likely to be browsing quicker than desktop users, and won’t be lingering long enough on the homepage to enage with the carousel. I’m not sure its advisable to second-guess the context in which users are using their mobile device, but I’m comfortable with the decision.

Tweaks and fixes

There was a fair amount of kinks to iron out (eg. margins between floated columns caused alignment issues when linearised in the mobile version, and some larger images needed to be changed from fixed width to percentage-based to stop the layout breaking).

Conclusion

And that’s about it. I’m not suggesting that this retro-fitting approach is preferable to rebuilding a fully responsive layout from scratch – it isn’t. But this exercise hopefully shows that with just a couple of hours work you can get a previously fixed width site looking pretty respectable on a mobile, and far easier to use.

To learn more about responsive design techniques I can thoroughly recommend ‘Responsive Web Design’, and to see some properly responsive designs (as opposed to the hatchet job I’ve described above), check out the Media Queries website.

The Page Fold is Dead… Long Live the Page Fold!

December 6, 2010 by Pete

The page fold exists. It influences users’ behaviour. And it needs to be considered.

What is the Page Fold?

The page fold is a classic case of a widely agreed upon print design phenomenon that was adopted early on by web designers, as it was assumed to hold true in their discipline. The principle is simple – newspapers folded on a newspaper stand have only the top half of their page visible to the passer by, so if you want a headline to grab attention it must be ‘above the fold’.

Clearly, a rule in one design discipline does not necessarily apply in another. After all, it takes far less motivation on the part of the user to scroll a web page than it does to pick up a newspaper from a news stand and unfold it. But we have to remember that in the early days of the web, designers and users alike were unfamiliar with the medium, and it made sense to adopt tried and trusted principles from other areas of design.

And so the idea persisted, with designers often cramming as much content as possible ‘above the fold’, afraid that anything below it would be likely to be missed by the user.

Page Fold – Myth or Reality?

But although this idea of page fold as significant barrier has been rightly debunked in articles such as ‘Myth of the Page Fold’, too many people are now rallying behind a cry of “There is no page fold!” as blindly and unthinkingly as those that promoted the idea of the fold in the first place.

To begin with, dismissing the fold is to dismiss not a myth, but a simple observable fact – that some content is visible in the user’s browser when a page loads, while some content isn’t.

And this fact has consequences.

For example, content above the fold is essential in forming a user’s initial, split-second impression of a page, which can be formed in as little as 50 milliseconds (‘Web users judge sites in the blink of an eye’). If a user isn’t instantly convinced by a page, then they may not wait for the page to finish loading, let alone scroll down the page to explore further.

That doesn’t mean cramming content above the fold (if anything it means keeping things as simple and focussed as possible), but it does mean that the area above the fold has to work hard to be visually engaging.

The question of course is ‘where is the page fold?’ – the answer to which is that could be pretty much anywhere. With the enormous range of platforms and devices on which we view web content these days, it is impossible to know how much of a page’s content is visible above the fold.

But just because something is elusive, that doesn’t mean we should stop considering it. In fact, I’d argue that we should now be thinking about the page fold more, as it is manifesting itself in ever more nuanced and interesting ways.

The New Page Fold

Starting up Safari the other day I was struck by how much the Top Sites layout resembles a newspaper stand. The more I looked at it, the more I saw similarities, most significantly the fact that, for each website, Safari was showing me only the content above a ‘page fold’.

screenshot of Top Sites

The reason this is significant is because the thumbnails are not static images, but continually updating representations of actual content. When I launch Safari I get an overview of the actual content of my bookmarked sites. If something catches my eye, I click on the thumbnail to open up the site. But in order for something to catch my eye, it has to be ‘above the fold’.

Take the example of ‘Typography Served’, the site shown in the upper left thumbnail. There are six rows of images on the website, but the thumbnail in Top Sites shows only the first of those rows. If an item of content isn’t in that top row, then it isn’t going to catch my eye, and isn’t going to be explored.

Yes, I can open the site to see what is ‘below the fold’, but that requires an additional level of engagement, much the same as lifting a newspaper off a news stand does. I don’t do it.

An example of how the phenomenon of the fold still influences how we engage with content, and as the ways in which we experience web content diversifies and evolves, it is starting to manifest itself in all kinds of ways that we have not foreseen.