Should designers be able code

2010-02-19 16:22:33 +0000

This has cropped up lately following Elliot Jay Stocks post (and tweet). So here’s my tuppence.

Should designers be able to code their designs?

No.

But then again it isn’t that cut and dry. I think that there are a very small number of designers that might just be able to get away with it, but they are a minority in the geek world. There’s a reason people like Andy Clarke and Elliot himself are respected so well, because they are skilled and motivated enough to keep on top of design and code. For the majority of us we should specialise in design, front end development (HTML and CSS) or back end development. I also still think there’s a place for pure JavaScript developers (reducing the reliance on jQuery and other frameworks to optimise code).

So should designers know how to code?

Yes.

Learn how designs are laid out, learn how positioning works, learn about floats, browser bugs and the deficiencies of Internet Explorer (and Safari, Chrome, Opera and Firefox for that matter). There should be no excuse for providing designs that are an absolute nightmare to build, but it doesn’t mean you have to be able to build them yourself. If you know the limitations of the technology you can both design to their limitations and think about ways to get round that and make your awesome designs work.

Which brings about an interesting point, the best way to learn HTML and CSS is just to do it, so if you ask the question again, the answer might be different.

Should designers be able to code their designs?

Yes. But don’t let them build the production site.

Why not then, if they can? The intricacies and time spent on testing and debugging is a start, but I also spend a lot of time keeping up to speed on how Google looks at my code, mobile development, I’m still getting to grips with HTML5 and CSS3, I’m work hard on optimising code, and if I had to do all of that and design sites I build I would let myself down in one area. Not to mention I am not a designer, I do code, that is my passion and so I’m sticking to it and not learning design or keeping on top of design to be able to do both.

You could well apply the same principle to the difference between a front end developer and a back end developer, but I’ve got work to do!

BoagWorld

2010-02-10 14:18:54 +0000

Hoorah! I took a bit of time over Christmas to read and review the book Website Owners Manual by Paul Boag, of BoagWorld podcast and Headscape design agency fame.

My review which I recorded in January made it onto the podcast number 198, and as it was the author presenting the review, it became a lot funnier than I had ever planned!

Transcript:

The website owners manual by Paul Boag, published by Manning Publications

The website owners manual by Paul Boag is targeted to help those who own, run or manage web sites make them more successful. A quiet and humble man Paul has attempted to deliver all the lessons learned through more than 10 years of experience, at all stages of a site lifecycle, into a single resource. The result is a book that will help those responsible for websites be as successful as they can.

Covering topics ranging from selecting the right web agency all the way through to planning for the future, not all content might be appropriate for all website owners, but if the desired audience pick up this book, I don’t think there a single reader that will not learn something and become more successful in their role because of this book.

The book contains succinct well considered advice, which will not overwhelm any reader. I thought there might not be quite enough in depth information, or further resources, provided some sections to really make a difference, like reviewing site analytics. The book could have also better proofed, but this is a matter for the publishers. Not to mention one of the images depicting a developer in a tie.

The website owners manual is divided into standalone chapters that each covers a different stage or process involved in running a website. The 12 chapters cover:

  1. The secret to a successful website
  2. Stress free planning
  3. The perfect team
  4. Differences over design
  5. Creating killer content
  6. User centric design
  7. Ensuring access for all
  8. Taking control
  9. Decoding technobable
  10. Engaging visitors
  11. And finally, Planning for the future

Although not all chapters will be relevant to all website owners, and any experienced website owner will probably have a lot of the advice and recommendations in place, there is still an awful lot to either learn, or be reminded of while running your website.

The topics covered in the book do a good job of providing a feel for the requirements of each stage in the web site process. Some really useful content includes stress free planning, the perfect team, decoding technobabble and becoming number 1 on google.

firstly, Stress free planning, where in the “picture your users” section, Paul explains how you can research properly, prioritize your users and use fictional personas to better understand and relate to your target audience.

The Perfect team does an excellent job of explaining why a brief is so vital, even for small changes. Including an annotated example brief for fictional client “The Joke Factory” to explain why each part of a brief is so important.

Selecting the right people to work on your website might be the most important (and expensive) decision you make in the whole life of your website so it was good to see the steps Assessing proposals, interviewing the short list and evaluating agencies (especially with advice on talking to references).

Decoding technobabble is a problem for all us developers, so despite Paul claiming web developers are going to hate this chapter, I know my clients won’t hate me reading it. Not using simple terms to explain how a website works and introducing concepts like hosting is something I know I frustrate people with, but not for much longer.

Whilst reading the becoming number 1 on google section in the chapter driving traffic I was very pleased to read Paul explains about Black hat search marketing methods and why site owners should steer well clear of these underhand techniques.

In Planning for the future, I can take a lot from concepts such as Microformats, APIs and alternative devices concisely explained direct to my clients.

I really think this book is a must for any person responsible for a website, due to the wide range of topics covered. Although as I said, not all chapters will be relevant to all website owners, there will be more than enough for the book to be a real valuable resource. I like to think of it as a fully fledged consultant sitting on my bookshelf.

There were real moments of enlightenment about how I can help clients really grasp the requirements behind an effective site. I hope this will dramatically improve my client communication using Paul’s thorough but clear explanations of the concepts required for a successful website.

So that’s what I thought about the website owners manual, but its only the tip of the iceberg, and each person that reads the book will take learn something different, so I urge you to buy it and see what it can do for you.

Wireframes

2009-09-23 09:42:35 +0000

Here at GyroHSR (I had nothing to do with that site, thankfully) we are all a little bit confused over wireframes. Essentially, I think that the main issue lies in what exactly is a wireframe supposed to deliver.

In my opinion I believe a wireframe should simple layout exactly what information should be displayed on a page and define the importance of that information, in relation to the rest of the content.

With this idea in mind, a wireframe does not necessarily have to provide any sort of guide to the actual layout of a page. There isn’t really anything wrong with this for a simple contact page wireframe:

Header elements</p>

Logo – prominent positioning.
Search box – enable users to search whole site.
Navigation – full site navigation.

Main content

Contact form – main content on page, encourage users to use this method of contact.

Secondary content

Postal address – specify preferred correspondence address.
Email address – link to create email for users that prefer this method of contact.
vCard – Download contact details to an address book for future use.

Other content

Company details – registerd company address and registration number.

That will provide the main information required by a wireframe, and producing this format for every page to be developed should meet the designers needs.

However one point above is always missed, producing a wireframe for every page. Without doing this you are not creating an information architecture for a designer to follow, resulting in questioning why wirframes for any pages were created at all.

The same problem applies to wireframes that incorporate some form of layout:

Example wireframe - courtesy of http://totheweb.com<figcaption class="wp-caption-text">Example wireframe - courtesy of http://totheweb.com</figcaption></figure>

Creating a wireframe for every page becomes even more important with this wireframe style, in my opinion. Creating this type of wireframe for only a small number of pages during the information architecture stage of a web site process results in designers feeling restricted to make all pages following the same layout. Often the content will lend itself to a completely different layout, which means it needs its own wireframe and if not it should be easy to create another wireframe based on what has already been created.

One other thing I often find missing from wireframes are annotations. Visual representation is fine, but if you really want to let a client or designer know what you plan for the page, it needs to be annotated well. The annotations let the wireframe make sense and are vital to communicating the user experience. A poorly annoted wireframe wil result in poorly communicated ideas and will very probably hinder the final user experience.

So that’s what I think about wireframes, feel free to correct me if you think I’m wrong, or to add to this because wireframes are such an important part of the web development process that I think anyone involved in the industry should input into how wireframes can help ease the pressure on project management, information architecture, design and development.

I’m a Vitruvian!

2009-09-06 16:41:07 +0000

Which mean I have successfully completed the Vitruvian Triathlon, a half IronMan distance triathlon (almost – the bike is 5km short!). That’s 1.9km swim, 85km bike and 21km run.

I was pretty pleased with the time, 5 hours 08 minutes and 35 seconds, with the following splits:

Swim 00:36:21
T1 00:03:05
Cycle 02:42:46
T2 00:01:33
Run 01:44:47
Total 05:08:35

The swim started bright and early at 6:20am, so I was up and out of the B&B, with Rich from GyroHSR who was also racing, at 5am. We arrived and got transition sorted, I rushed a bit by faffing far too much, but all went relatively smoothly.

Rutland Water, home of the Vitruvian Triathlon<figcaption class="wp-caption-text">Rutland Water, home of the Vitruvian Triathlon</figcaption></figure>

The water was full of plant life which was a bit annoying to say the least, tangling around my arms a few times but after 2 laps of the 950m course, I emerged feeling quite good. So much so I probably could have taken another minute off the swim time, but it was also a rough swim, with other competitors around me all the way.  I took my time a bit in transition, getting the wetsuit off and making sure I had all the gels and bars I needed and set off on the 2 lap 42.5km course.

It was cold, very cold and a bit too windy on the bike, but the hills got my heart going when they came around. I aimed at keeping my heart rate at 140BPM on the bike, gauging that would be the level I thought I would need to post a sub 3 hours time, turns out it was a great time, as I got through the hills and the wind still feeling strong for the part I had trained most for recently, the half marathon.

Feeling pretty  strong I set the target heart rate of 157 all the way, which should post a 1:35 half marathon, not bad at all. However I expected to flag and while I felt strong most of the way round, the faster runners were a little demoralising.  I kept above 155BPM most of the way round, in the last 7km easing off a little and cruising home at 145BPM, with an average HR of 154BPM for the 21km. I even had a little in the tank for a 50m  sprint at the end!

Only down side to the day was finding Rich at the end, and hearing his race wasn’t ideal – I wish he’d felt as strong so we had a fair comparison of times. Still, I had quite a bit of time on him and better training in the build up may just have given me a sub 5 hour time, but that’s life!

And the day after,  following that monster challenge, I had my Choi Kwang Do yellow belt grading, so now I’m a Vitruvian and a a proper colour belt in martial arts. All in all a good weekend!

Email marketing – a bit of a rant

2009-08-17 16:55:58 +0000

As developers we hate it. But I have to admit it is an unnecessary evil in my (current) world as an agency web developer. Lets face it – it works.

So here it is, the blog on the dreaded subject of email marketing from a my point of view, why we hate it, how we can make it work, what people can do to make our lives easier and campaigns more efficient and effective.

Why don’t I like building emails?

This is simple. We love accessible, semantic, standards based code. We do not like going back to techniques used over 10 years ago. We have to use out of date layout techniques and the code is long winded, complicated and boring to produce. It wouldn’t be so bad if we could use the same HTML and CSS standards we use for web sites, but unfortunately it isn’t an option. Not if you want your campaigns to include the creative idea that you are so sure will work, at least. And this doesn’t look like changing anytime soon.

If you haven’t seen the problems with Microsoft Outlook 2007 using Microsft Word to render emails, then the internet is full of disgruntled people. Actually, I’ll help you with that. Don’t get me started on Lotus Notes.

It isn’t our fault animated gifs don’t always work. Flash can’t be used. Hell, even background images don’t work. These points ARE NOT OUR FAULT. But it still provides a hot topic of discussion between designers/concept teams and us developers. Trust my judgement, look at how long I’ve been doing this, we do actually know what we are doing, although maybe you and your great idea are more important than everyone seeing it as intended. Or doesn’t that defy the point altogether.

There are hundreds of different software, webmail and operating system combinations for us to work to. If you want your campaign to work in even 80% of them. Please listen to my advice, not just try to replicate your print campaign in an email. They are completely different mediums.

What works?

Again, simple things.

Keep your text to standard web fonts. Don’t rely on background images. Don’t ask for Flash or an animation. Keep the layout simple. The fewer images the better. Yes we can code so things will degrade gracefully, but if the client views the email in their inbox (compared to the signed off HTML file they viewed in a browser) with missing design elements they liked, it won’t be your fault, it will be mine. So please just make the designs possible in all clients.

Unless of course you have stats showing 100% of your recipients use an email client that supports animated gifs or background images – but first of all that is unlikely to be available, let alone likely to ever happen!

Even so what people don’t seem to understand is that everything doesn’t have to happen in an email. We have awesome tools in jQuery, Flash, and even simple HTML/CSS that can impress and prompt customer action better than an email. So a well thought out simple email to get people to somewhere showcasing the creative concept and getting customers interacting will work better than trying to contain everything in someone’s inbox. I find that a simple concept to understand. Why can’t others!

In the words of Columbo…

Just one more thing, if I can get on with building sites because I don’t have complicated email discussions going back and forwards, I will be happier. Of course sites are what I love, so if emails could disappear completely I’d appreciate it.

Resources

Finally, here are some good email resources, not that you’ll probably read them anyway. All are from Campaign Monitor, because they are good.

What am I?

2009-08-14 12:46:58 +0000

The reason I ask is because the variety of job titles for my role astounds me. As Stanton, Ryan and Sarah mentioned on the Boagworld podcast episode 176 the number of job titles is never ending. Consider this, I have seen all the below job titles for my role or roles within my day to day responsibilities:

  • Front End Developer
  • Web Author
  • Client Side Developer
  • Web Designer
  • Web Producer
  • Web Programmer
  • User Interface Developer
  • Digital Strategist
  • Web Manager
  • Digital Developer

What do any of these mean? For my part, I believe that Front End Developer covers all the bases. Web developer will cover front and back end work and server side (or back end) developer will work for,  you guessed it, server side developer.

I don’t know if it is because of the young age of the industry, or if people are trying to create the most impressive sounding titles for themselves or their staff, or if it is HR not understanding what somebody does.

Why would this worry me? I worry because I currently have the title Senior Web Author. What I don’t want is people to read that who has a different definition of the role and immediately discount me from anything that I may suit. If I were offered the role today I wouldn’t expect to be heavily involved in HTML/CSS and Javascript development, but I would think that an author would be more involved in content authoring.

The same works the other way, I may be looking for a role and find that I completely miss my perfect job because it was advertised as a “web designer” role. Would I expect designers to build code? Not nowadays.

This specificity us geeks now show may be a direct contributor to the current job title confusion. Back in the early days a web designer will probably have had to build the site they design, but with technologies needing such attention, people really need to specialise as early as possible. The old saying “jack of all trades and master of none” applies a great deal in our industry.

Of course a lot of companies (including my employers GyroHSR*) are still trying to determine the best structure for their digital department, the job title situation may get worse rather than better, but I hope that anywhere I have influence we can set the following roles, all that should be needed in a web site development process, especially the small to medium builds I am involved with:

  • Project Manager
  • User Experience/Information Architect
  • Web Designer
  • Front End Developer
  • Server Side Developer

And User Experience/Information Architect and Front End developer roles are the ones I look out for. How better to start trying to select something new when you know the organisation has similar structure ideas to mine.

Please comment if you have any job titles I missed, or any suggestions for jobs I might look out for I would normally skip in the listings!

  • I had NOTHING to do with our terrible web site, by the way

Milton Keynes race report

2009-07-26 21:39:47 +0000

Milton Keynes race results:

Swim 1.5km 00:25:30
T1 00:01:52
Bike 40km 01:11:42
T2 00:01:08
Run 10km 00:42:25
Total 2:22:37

I have to admit, I’m pretty happy with that – despite getting a bit lost and disoriented on the swim, I made it round in closer to my original goal of 2hr 15 than my revised goal of 2hr 30. Full results are available on the Big Cow website. The winner, Adam Bowden, managed a pretty amazing 1hr 48min time.

To say I’ve also run my fastest ever 10km after an undulating bike ride also says quite a bit for the training from Jen at Optimum Velocity which has really pulled me back from running oblivion!

Then of course this morning I thought what better way to recover than a 5km run and a coached swim session. That was painful!

F3 Events triathlon and look ahead to MK 2009

2009-07-24 10:16:30 +0000

I appear to have finally exorcised the running demons for this season, only more than half way through the season, but at least I have managed to get ready for my main Olympic distance race in Milton Keynes on Sunday 26th July and the dreaded Vitruvian race in September.

Completing a warm up sprint distance triathlon on Wednesday gone in the F3 Traithletes World series, at Dorney Lake, was a bit of a milestone in the end. Posting not only my fastest swim yet, I also managed a pretty good 21:32 5km run off the bike.  A total time of 1:14.58 met my final goal of last year and hitting under 1:15 for a sprint triathlon really felt like an achievement. Now lets see if 1:10 is possible next year!

Milton Keynes have slightly annoyed me by changing the bike route to a 2 lap 20km route rather than one 40km loop, however I hope to use this to my advantage and blitz the second lap by know where I can punch it and when I need to save some leg strength for the undulations. Travelling up there by car Saturday means I’ll also have chance to recce the course, better preparing myself even more.

I’ve also just started my own running club! Work have introduced a scheme to try and get people more active and I’ll be taking on the running side of it with regular runs for all abilities at various times throughout the week. Will have to plan the best way for beginner and mixed ability running sessions, but I also look forward to the faster lot providing a bit of a challenge and motivation during some really tough interval and fartlek sessions.

The GyroHSR Chicago office have also laid down challenge in regards to a Nike+ inter-office challange, so I’ll have to get myself an iPod and Nike+ sports kit to participate in that – but to be honest its a good excuse for more training tracking toys.

Back on the running trail

2009-07-02 14:49:57 +0000

After having iliotibial band syndrome (ITBS) forcing me out of running for a while I have attempted to start running again this week, in preparation for the Milton Keynes triathlon on 26 July. If I am to reach my (revised) goal of 2hr 30 I have to really get in a 46 minute 10km run time. I had hoped to complete a 2hr 15 Olympic distance triathlon but with injury interrupting training since I set that goal in January, I have decided 2hr 30 is a respectable target time.

Thankfully this week I have completed a 6km and 7.5km run with absolutely no ill effects whatsoever, in fact my legs felt stronger than they ever have following any distance running. Tomorrow I am tempted to even try the 11.4km run into work (SW20 to SW10), however it might be a bit soon for an undulating run like that.

I’m attributing this feeling to 2 things, the excellent physiotherapy (and subsequent stretching exercises) that David Bolton provided and Choi Kwang Do study and stretching. Now I included a Choi Kwang Do warm up before my running and with class twice a week I hope that the injuries will stay away – goodness knows I’ve had a shocking time with injuries so far this year.

Outlook 2010 – still not helping anyone

2009-06-24 10:52:44 +0000

So here’s the great news that Outlook 2010 is in beta development. Here’s the not so great news. They are still planning on using the Word rendering engine to display HTML emails, just as in Outlook 2007.

Goodbye styles and background images, hello tables (my old friend) and broken emails.

There may be all sorts of reasons behind the move, be it a reaction to Microsoft not being allowed to bundle Internet Explorer with Windows 7 or the official Microsoft view that using Word offers the most powerful email composition tools for Outlook users. This is flawed by tha fact that recipients will require Outlook to view the emails properly, and with only 7% of the market this punishes Outlook users in my opinion. I see no reason why a corporation such as Microsoft can’t allocate the resources to create an email client that provides powerful authoring and rendering of emails, using email standards.

The Email Standards Project, Campaign Monitor (I love you guys!) and New_ism_ have initiated a campaign, http://fixoutlook.org/, to try and highlight the problems to Microsoft, so lets all hope they listen.

Outlook is broken - let's fix it!

Alternatively the sooner I get away from having to worry about building HTML emails, the better.

Addition: the Microsoft response

Microsoft have provided a response to the campaign on their MSDN blog which expands on a number of points I raised. In the comments I pointed out that HTML is not an email standard, and Microsoft correctly state “There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability“. This is my view too but of course it doesn’t make my day job any easier.

I agree that many using Word to compose rich emails will find that the easiest and most powerful method – but it still relies on the recipient using a client expecting Word formatted HTML.

Finally, if Microsoft would please prove to me that “Word has always done a great job of displaying the HTML which is commonly found in e-mails around the world” I’d appreciate it, because I think that is absolute bollocks and my professional experience backs that up.