Straight to Code

IMG_1468

Straight to Code

Well, it's been an interesting couple of weeks for me, having thoroughly submerged myself in learning html5 and CSS3. I've been reading a slew of books on the subject, my favourites being (in no particular order) 'Responsive Web Design' by Ethan Marcotte, 'HTML5 for Web Designers' by Jeremy Keith, 'CSS3 for Web Designers' by Dan Cederholm and 'Hardboiled Web Design' by Andy Clarke.

It was a talk given by Jeremy Keith on vimeo that originally stoked my interest in wanting to learn more about how we approach web design, and how for the larger part, most of us have been going about it in the wrong i.e. taking print sensibilities and trying to apply them to digital.

Jeremy's talk and the books above explain it a lot better than I can, so I won't attempt to try here.

But what I would like to talk about is something that I first read earlier this year in an article by Meagan Fisher, and in a presentation by the aforementioned Mr Clarke. Firstly, I would like to point out that both Meagan and Andy's posts are from way back in 2009!!!! A staggering 3 years ago, and I still don't hear of many designers using this approach.

What they are both advocating is a 'mockup in markup' approach, to do away with static visuals and show clients what they're actually getting, not some impostor. And as Andy says "We aren’t designing copies of web pages, we’re designing web pages."

This isn't to say that you should never touch photoshop, illustrator, fireworks (or whatever graphics program you like to use to design sites in) again, of course not. But what we should stop doing is letting a client see a static, fixed sized visuals straight from these applications.

So last week I thought I'd give this approach a go with the web project I'm currently working on. I decided I'd create the wire frames for the site in html rather than illustrator (my preferred design tool) as I felt it would be beneficial for both me and the client. The benefits to me were if these had been illustrator files any minor changes like changing the name of a section or moving something to another area would have taken a considerable amount of time (there would be over 25 different visuals - it's a big site), then there's a saving a jpeg of each visual as well, attaching them to an email, blah, blah… all that time spent on something I can't use for anything afterwards. Building in code first means everything is reusable, it's the foundation of the actual website – and that's what really is a benefit to me.

For the client, the benefit is seeing an actual working prototype that looks and behaves like a website – because it is! Yes, these are just wireframes at the moment, but allowing them to have a proper sense of how the site works in different browsers, devices etc. is invaluable in a project of this size, to them and me.

I would like to point out that creating the wireframes did take me longer than it normally would have if I'd have made them in illustrator, but I truly believe I've saved myself a heck of a lot of time here in the overall timeframe of the project. Also, using this approach more often means I'll get better and faster at it, and I do believe in time I'll be just as fast in making mock ups in code than I can currently do in illustrator.

This also hopefully means I'll become a more proficient coder and my clients will hopefully save money because I'll have less time to bill for …hmmm… maybe this wasn't such a good approach after all… but you get the idea ;)

I really do feel this is the way forward for web designers and I hope I see and hear more of it being used :]