10 problems your content management system will not solve and how to overcome them

Posted in Development on October 30, 2009 by Paul Boag

Content management systems are often perceived as a silver bullet that will solve all your content problems. In reality having a CMS is not enough. You must also address broader issues associated with the content of your website.

So many website owners hate their content management system. This is often because it has failed to live up to their unrealistic expectations.

Many organisations purchased their CMS hoping to solve a wide range of issues surrounding content production and delivery. In reality, a CMS is only capable of overcoming relatively few. In fact often a content management system will solve one set of problems only to create more. It is these new problems that I wish to address here.

What follows is a list of 10 issues that are either directly created by content management systems or that a CMS will fail to solve.

1. A lack of editorial control

One of the primary reasons organisations purchase a content management system is to de-centralise control of content and therefore remove the bottlenecks that surround posting content to the web.

The consequence of this approach is a lack of central control to ensure the quality and accuracy of copy produced. This can lead to contradictions and varying styles of writing across the site.

Although many content management systems provide the tools for central editorial control, they are not always used and require somebody with the editorial experience.

The Solution: Get an editor

Unfortunately this is one problem that technology cannot solve. What is required is a content editor. Somebody who checks what is being produced and ensures it communicates a consistent message in a consistent tone.

Ideally this should be somebody who has experience in writing and editing online copy. However, the most important thing is that this person feels confident in editing copy, and has the authority to remove inappropriate material.

This person will also require a vision for the site and in particular what personality it should be projecting.

2. A lack of personality

Many websites lack real personality. They either ooze marketing BS or come across as singularly bland. This is largely due to the fact that they have been written by people more interested in communicating facts or selling stuff, than wishing to engage with users.

Websites with great copy that is full of personality, stand out from the crowd. They do more than convey information. They actively seek to make a connection with users in much the same way people do face to face.

Unfortunately the distributed nature of content production through the use of a CMS undermines that.

The solution: Decide on your sites personality

The first step towards overcoming this problem is to define who you are. If your website was a person what type of person would it be? What words best describe your sites character? Is it playful, serious, enthusiastic, or friendly?

Next put together a content style guide. This will include examples of writing styles that should be used on your website. It will also include guidelines in terms of tone and wording. This document should then be distributed to your content providers.

Producing an effective content style guide is not an easy task. You might wish to consider employing a freelance web copy writer if you do not have somebody in house. However once it has been produced, it should provide everything your content providers need to add some
personality into your copy.

Of course that does still require your content providers to be committed to the cause.

3. Uncommitted contributors

One of the great selling points of having a content management system is that they allow anybody to post to your website. Unfortunately, just because your staff can edit the site, does not mean they will.

It is not unusual to find that content management systems go unused except for by a few individuals. The belief that content management can be easily decentralised is false. There are two primary reasons for this.

Firstly, some people do not see it as their responsibility to provide web content. They see the website as a marketing or sales tool and so should be managed by marketeers.

The second reason is that most people do not have the time. Writing web content is often seen as a low priority and constantly gets pushed out by “real work.”

The solution: Recognise the importance of the web

The solution to this problem has to come from senior management.

The website needs to be seen as a critical business tool and job descriptions must reflect this by making site maintenance a key component of people’s job. This should include website duties being apart of employee assessment.

There is however another reason people do not using the CMS – they don’t know how to use it.

4. Poorly trained authors

When an organisation rolls out a new content management system they almost always offer some form of training. However, in many cases it is not enough.

Normally training consists of an intimidating manual and one off training session. For the few people who are updating the website regularly this is probably enough. However for more infrequent content providers, this is inadequate.

The trouble with one off initial training sessions is that by the time the content provider comes to update the website, they have forgotten what they learnt. Admittedly the information they need may well be contained in the manual, but who reads those?

This can easily lead to only a few people capable of making updates to the site, thereby undermining the very reason for having a CMS in the first place.

The solution: Provide video training material

The combination of occasional users and new employees, means that most organisations need a long term strategy for training people in the use of their content management systems.

We have found that a series of short video tutorials covering key functionality works much better than training sessions or intimidating manuals.

We still run training sessions for frequent users. However, the video tutorials allow users to work through the material at their own pace. Also, unlike a training course they can learn only the parts of the system they actually need.

However, training in the technology is only half the battle. Content contributors also need to know how to write compelling copy.

5. Bad copywriting

The harsh truth is that not everybody can write good web copy. Even somebody who writes brilliantly in print, does not necessarily write well for the web.

There is an art and science to writing good web copy that many people are unaware of. Copy written by content providers is often verbose, un-engaging and hard to scan.

The solution: Provide a structure for content production

The solution is three fold:

First, the introduction of an editor means that content providers do not have to worry about writing perfect copy. It should be the job of the editor to take the raw copy they provide and re-write it for the web.
Second, the training provided with a content management system should extend beyond the functionality and also include advice on writing good web copy.
Finally, by producing a basic template for content providers you can help them focus their writing. A content template should ask questions such as who is the audience, what is the key message for this page and what is the call to action?

However, the problem is not just limited to the quality of content but also the quantity.

6. Bloated websites

Much like this post, most websites end up far too bloated. This is a problem that content management systems only serve to exaggerate.

By removing the barriers to putting content online, you encourage people to add more. However, more is not always better.

Content providers often approach the website with entirely the wrong mentality. They look at the content they have or can easily produce, and decide to put it online because “somebody will find it useful.” They are driven by what content is available, rather than user’s need.

The problem is that the more they put online, the harder it is for users to find the content they want. It is like trying to find a needle in a haystack.

The solution: Focus on users and remove

The best solution is to prevent this from occurring in the first place. This is done by fixating on user needs. Before putting anything online ask two questions:

Is the content aimed at your primary audience?
Is the content essential for helping those users complete their objectives?

If you cannot answer yes to both questions, then seriously consider whether putting the content on your website will cause more harm than good.

Of course, you may already have a bloated website. If this is the case then you need to review each page of your site and apply the principles above. If a page fails to cater for a specific use case of your primary audience, then it maybe time for it to be removed.

The problem is that most organisations have people responsible for adding content to their websites. However, few have somebody charged with removing it. This is an important role and one your web editor should have the power and time to do.

However, user needs is not the only criteria for judging the worth of content. There are also calls to action.

7. No clear calls to action

As I have already said, most content providers are focusing on conveying information rather than meeting users needs. However, they are also neglecting the business needs too.

With the exception of marketeers and sales people, few content providers are thinking about calls to action. What is it that you want users to do next? How do you wish them to respond?

Even when content providers are thinking about calls to action, they are focusing on the big actions such as “contact us.” Until the user is ready to take those major steps they are left to wander around the website.

The solution: Always guide the user to the next action

It is important to consider the main calls to action for the entire site. Typically they consist of one or two major actions such as buying a product or completing a contact form.

However, there is also a need to think about the calls to action of each page. Avoid leaving your user with no obvious next step.

Take for example this page. Directly below this article you can take three actions:

Leave a comment
Provide feedback – That leads to videos offering a number of next steps
Read a related post

At no stage is the user left without a next action.

A big source of next actions is your information architecture. Unfortunately most navigation is not focused on users needs, let alone business objectives.

8. An organisational focused IA

An unfortunate side effect of running a content management system is that it encourages information architecture built around organisational structure rather than users needs.

If you look at most organisations CMS driven websites, their information architecture closely mirrors their internal structures. This is because it is easier to divide up responsibility for updating various parts of the site if it is structured along departmental lines.

The problem with this approach is that users do not think in terms of organisational structure. They are task focused and so often an organisational IA is entirely inappropriate. It leads to confusion and frustration among users.

The solution: Focus on user tasks

The only solution to this problem is to stop structuring sites around organisations and start focusing them on users.

Although it is easier in most content management systems to allocate permissions based on a per section basis, there is not normally a specific need to do so. It is just as feasible to give access on a per page basis making it unnecessary to organise around internal structure.

Ultimately your site should be about your users and that includes your IA. However, it does not stop there. The community you build around your site is important too.

9. No sense of community

Increasingly content management systems come with some great community tools. They have forums, comments and integrate with everything from Facebook to Twitter. However, great technology does not build great communities.

Many organisations implement these community features on their site and are disappointed when they are not used.

Worst still some organisations launch these features but moderate so heavily that users respond negatively. Eventually the functionality is removed entirely.

The solution: Build relationship not functionality

It is important to realise that online communities are about relationships and not technology. If you want to build a successful community around your website, you need to actively and regularly engage with users.

This involves having people within your organisation who are constantly talk to users, asking and answering questions, and getting to know people through open and honest relationship.

Of course, the problem here is the same as content production. This is not seen as an official role. Instead it often falls to enthusiastic individuals. If you want your community to succeed you are going to require passionate people who have the time and resources to sink into that community.

And it is a lack of resources that leads us to our final problem that content management systems cannot solve – single language content.

10. Single language content

The majority of invitations to tender Headscape receive for content management builds, request multi-lingual support.

In the end few of the sites we build actually make use of that functionality. In effect they are paying money for something they will never actually implement.

There are two many reasons for this.

The first is aspirational. Many organisations request multi-lingual support because they have dreams of expanding in the future and unfortunately those dreams do not come true. I can at least respect this viewpoint. There is nothing wrong with planning for functionality you might need at some point in the future.

However, the second reason is not so admirable. A lot of sites fail to implement their multi-lingual support because they have not fully thought through what that involves.

Implementing a CMS with multi-lingual support is easy. Creating a multi-lingual website is hard. You have to decide what content is going to be translated. You need to find a translator and then you also need to maintain that content over the long term.

The solution: Think twice before requesting multi-lingual support

There has to be a good business case for implementing a multi-lingual website. Unless you are sure that you are going to make money from a foreign market, it is probably not worth investing in language support.

If you aren’t serious about supporting other languages do not add it to your ITT, at least not as a primary requirement. There is no reason to rule out a CMS for not supporting multiple languages unless you are sure you are going to use that functionality.

Conclusions

You could interpret this post as a criticism of content management systems. That is not the case. I believe content management systems are a valuable addition to most websites. However, as I said at the beginning they are not the silver bullet may perceive them to be.

The success of your CMS is largely reliant on you being aware of its limitations and being prepared to deal with these restrictions. If you do then a CMS could be the best investment you ever make.

159. Special Guest

Posted in Classic shows on April 1, 2009 by Paul Boag

On this week’s show: The northerners are back with special guest host Sarah Parmenter.

Podcast: Download (29.1MB)

On this week’s show: The north erners are back with special guest host Sarah Parmenter. We answer your questions on how to quote for projects and whether using off-the-shelf software is wrong and we have a chat with Sarah on her experiences in the industry and the difference between developing for clients and developing for yourself.

Download this show.

Launch our podcast player

News

Alkaline

Our first story for is a new product by the guys over at Litmus, you may have come across their Browser and Email testing apps before and they’ve just released a new Mac app called Alkaline, this is a Mac front-end to their online browser testing suite and lets you test your website designs across not only 17 different Windows browsers which they mention on the site, but also all of the Mac and Linux browsers that the online Litmus services test against.

Alkaline grabs screenshots of your site rendered in all major browsers, the number of which depends on your chosen pricing plan, It’s free to test against IE7 and FF2 and if you need to test across all browsers, it’s available under the standard Litmus pricing plan which offers both individual and team monthly subscriptions, and a handy day-pass if you only do this kind of testing every now & then. Litmus also stores a history of your screenshots so you can see the evolution of your design and also reports your HTML and CSS errors.

There’s plugins available for Textmate and Coda, and you can preview the sites right inside Coda 1.6’s preview window, however because Alkaline grabs screenshots of your pages it’s not possible to do any live updating of CSS and see the results in all browsers.

Paul at Litmus also informed me that throughout April, they’re offering full access to the Litmus service for free on Weekends, so on Saturday and Sunday you can test across all the browsers (using Alkaline or the Litmus site) and all the email clients, even if you only have a free account.

16 design tools for prototyping and wireframing

It’s no secret that prototyping or wireframing can really help in the overall design process, and there’s now a wide range of tools on the market that aim to help you in this process. A recent Sitepoint article lists 16 of these tools and rates their usefulness.

The list of tools is good, convering favourites such as Omnigraffle, Axure and Balsamiq to other applications which can be used to wireframe such as Powerpoint or Keynote. If you’ve not looked into these kind of apps before then do check it out, they also lists the price of the apps so you’re sure to find something within your budget.

10 Lessons every freelancer should learn

If I remember rightly, I came across this link from one of the people I follow on Twitter and it covers some killer tips on how to be a better freelancer, covering everything from self promotion, organising your workflow, finding time for your own projects, keeping motivated and how to charge appropriately, this is a must-read for anyone considering freelancing, or indeed those already in the freelance world.

Some great tips come in the way of keeping customers happy and generating repeat business and I’d like to squeeze in a forth link here to another Sitepoint article (sorry) which covers how to upsell additional services to clients as a freelancer you should be looking at maximising the amount of money you can make from each project through added services, whether it’s packaged services such as hosting, logo design or business cards.

I don’t really freelance but I do manage a couple of small sites I built on a freelance basis, and I get recurring revenue by hosting them on a small reseller account. I’ve also been able to tempt the customers into paying for a years hosting rather than a monthly cost by rounding the amount down to an even figure, which while it’s only a couple of pounds cheaper, always got chosen.

Interview: Sarah Parmenter on the difference between developing for clients and developing for yourself

Ryan: OK, so onto our interview section and what we are going to do today is an off-the-cuff interview with you, Sarah, er, so for people who don’t know who you are, er, do you want to introduce yourself.

Sarah: Sure, my name’s Sarah, I’m based in Leigh On Sea in sunny old Essex and I own a company called ‘You Know Who Design‘ that’s been going for about nearly seven years now, um, and I just do web development and sometimes I dabble in a bit of graphic design. Um, when I started off when I was younger, it was more graphic design than web but now it’s purely web and, er, yeah, it’s what I love doing.

Ryan: Right, OK, and we think a good topic to have a chat with you about would be the difference between developing for clients and developing for yourself.

Sarah: Yup

Ryan: So, er, let’s start off. Do you give yourself time to work on personal projects?

Sarah: I do, but not as much as other people do; whenever I see on Twitter, there’s a lot of people who have a lot of personal projects on the go and it generally tens to be on a Friday as well (all laugh), you see Twitter on a Friday, generally full of people, um, doing their own stuff but I tend to, if I’m doing something I tend to, maybe, give myself a couple of hours if I’ve got a spare, if I’m waiting for a client to get back to me on something and I can’t proceed with anything. I put client work first, and I don’t know if that’s a good thing or a bad thing, but that’s the thing that pays the bills, so, um, they always come first and if I’ve got a bit of downtime, I’ve always got projects that I want to work on, but possibly haven’t got the amount of time to dedicate to them as I’d like. I think it’s probably the case with everyone.

Sarah: Yeah, absolutely. You get some time, don’t you, through work?

Paul: Er, well we did sweet talk our boss into giving us 5% time, which was supposed to be like Google’s 20% time, where they get a whole day to work on personal projects, if it benefits the company.

Sarah: Really?

Paul: Yeah, well we got, like an afternoon on a Friday, which is kind of sidelined at the moment.

Ryan: To spend in the pub (laughs)

Paul: That’s personal projects, I’m sure. No, it’s kind of sidelined at the moment, we’ve got some major projects on which are taking up all our time with some heavy deadlines, so we’ve had to shuffle that. Hopefully we’ll start to get that back over the summer and work on some cool stuff instead of the business stuff.

Sarah: I think it’s rea
lly difficult, because obviously your client stuff does have to come first, and even if you’ve dedicated an afternoon or a couple of hours, if something comes up that morning, or if you’ve got a problem that needs sorting, unfortunately, it’s just the way it is, your client work has got to come first.

Paul: Yeah, pays the bills.

Sarah: I mean, a lot of personal projects, a lot of people’s personal projects, do end up very lucrative for them, and you could argue that it’s just as lucrative to just go along with your own personal projects, but I think in general, most people would find that their client work would, er, would have to come first.

Paul: We’re trying to convince our boss to let us build, er, an iPhone app

Sarah: Really?

Paul: and sell it on the app store. He’s not having none of it, because we’ve told him we all need iPhones to test it on, he just won’t buy them for us.

Ryan: and a mac to develop on

Paul: a Mac to develop on, yeah. For some reason, he’s not warming to the idea.

Ryan: he can’t understand the thirty grand, you know, outlay to…

Paul: We’ll easily make that in a day on the app store (all laugh), I keep telling him this.

Sarah: the app store!

Paul: Yeah, the app’s 50p, you know…

Ryan: Er, completely sidetracked there, erm. What differences do you find, er, between developing for clients and developing for yourself? What major differences do you find?

Sarah: I find, when I’m doing stuff for myself, I’m actually a lot less decisive on stuff. I sort of, because I’m immersed in, maybe my own branding, or sometimes it’s really good to look at it from an outsider’s point of view. If you’re doing stuff for clients, I think sometimes it’s easier to look at stuff and go ‘well, that needs to go there and that needs to be there to catch someone’s attention’ or you need to move that or make that a different colour, and when it’s your own stuff I think you tend to be either really creative and you don’t really care if you get stuff wrong, or if, do you know what I mean? It’s more, sort of… the boundaries aren’t there, you’re not time-constrained, there’s no brief, you just go off on one, doing whatever you want, whereas with client stuff, there tends to be a bit more, erm, what’s the word, consistency across everything, and I find, personally, when I’m doing my personal stuff, I could sit in front of Photoshop pushing something from the left-hand side of the screen to the right-hand side of the screen for two hours, wondering whether it looks right or not, whereas if it’s a client site, I think ‘right, I have to make a decision on this – where would this go, or where would it be best placed, and you make a decision and you move on, because otherwise the more time you, you take going backwards and forwards is, er, less money that you’re earning, so I think I tend to be more decisive with client work and with my own I tend to be a bit more, erm, easy-going and, er, possibly a bit more creative, in the sense of trying things that I haven’t tried before. Erm, yeah, I think it’s just good to be (pause – all laugh).

Paul: I think personal projects give you time to play with the stuff that you wouldn’t normally risk putting into a client’s site, things that might take you a week to figure out.

Sarah: That’s what I, sorry a man just walked past my window in a pair of shorts, as I was answering that question, which completely put me off,

Ryan: Was it an ugly man, or a good-looking man?

Sarah: No, he was an old man.

Ryan: Oh, right. OK

Sarah: I wondered if he had dementia or something, and he thought it was summer.

Paul: Was he in just a pair of shorts?

Sarah: Yeah

Ryan: A pair of shorts and a smile?

Sarah: No, and a newspaper.

Paul: Strategically placed.

Sarah: It just completely sidetracked my thinking pattern, then.

Paul: That’s OK.

Sarah: Oh, sorry.

Ryan: Where were we? So, which do you prefer, developing for clients, because obviously you’re doing that every day, or do you prefer developing for yourself?

Sarah: I actually prefer developing for clients, erm. I prefer getting a brief and thinking ‘right, how can I best interpret this brief, and get the objectives that they want, er, they want to get out of this website, how can I do that in the best possible way?’ Whereas, I think that when you do stuff for yourself, you don’t necessarily write down a brief as strict as you’d get when a client is sending through something. So, I, I actually prefer developing for clients, I really like, I don’t, I really like doing all the end, getting to the end product with a client. I think I get more satisfaction out of that than I do when I’ve done it for myself, because I still look at it in a very critical point of view, I still think, ‘oh well, maybe I could make those buttons a slightly different hint of green and it will look better’; whereas, with client stuff I think it’s just all about decision making, I think you tend to make more decisive decisions with client work than you do with your own. You think of your own as an ever-ongoing project that you can forever tweak and make changes to, whereas with client stuff you, once it’s live, it’s pretty much. You might get to update…

Ryan: Yeah, it’s difficult to come back, isn’t it?

Sarah: Yeah. Exactly. So I much prefer developing for clients, when they’re nice clients!

Ryan: Yes, we only like the nice clients.

Sarah: Yes, we all like nice clients.

Ryan: But do you think personal development time is important, do you think it’s important to develop your own projects?

Sarah: Yeah, I do I think it’s important from the sense of being, when I personally do lots of my own stuff, I find that I tend to be a bit more, erm, creative, in the sense of I’ll try stuff that I might think ‘oh, that’ll look awful, I won’t bother doing that for a client site’, but I might try it and actually surprise myself and think ‘oh no, actually, that’s a really good technique to use’ or do something a bit different because you’re not constrained by time when you’re doing stuff for yourself, necessarily. But I think, I do think it’s really important to do your own, your own thing, because I think it’s also a learning curve, you might try out different systems to use, you might decide to learn something, you might decide to use something like, if you’ve never used WordPress, you might decide to go and bolt WordPress onto your site just to see how you get on with it, you might try different apps. I think it’s important, because it frees the mind to use other things that you might not necessarily get to use when you’re in an office environment or, or perhaps even day to day because you don’t have the time to learn it, so I do think it’s important, but I don’t think it’s the, er, the be all and end all of everything.

Ryan: I think, er, a good tie-in question, not specifically about developing for clients and, er, yourself. Erm, keeping it with blogs and stuff, do you allot yourself a, like, time to read your feeds and, er, things like that, and to keep up with them, because I’ve been so busy in the last two weeks, my feeds have just gone like – you know when Google Reader says ’1000+’ and that’s it, it’s just stopped counting, it’s gone ‘look man, give up on these feeds, you’ve passed a thousand.’

Paul: You need to declare feed bankruptcy, I think.

Sarah: I tend to do this really annoying thing, where if someone posts a good link on Twitter, I’ll open it up in a browser window in a tab, and then if someone else posts, I’ll open that in another browser tab, so I’ve got about 100 tabs open in Firefox that I never get round to, to looking at, which slows the whole thing down and end up having to then bookmark them in a little folder called ‘Interesting Links’, that I never get around to reading.

Ryan: When you look back, they’re four years old and completely out of date.

Sarah: Yeah.

Paul: The shocking thing, because I do the research for the, the Boagworld news and push it all through the links, I probably churn through 150-200 feeds a day (Sarah: gasp), which is so many feeds that I haven’t got time to read them, which is shocking; I get so much information, so many good things that I’m pushing out to other people, that I just don’t have time to read them, there’s too much information.

Sarah: Do you skim-read them?

Paul: I do, I skim-read, I usually read the first few paragraphs, just to see what the article was about, clip out the interesting bits of text for the previews and then send it on it’s merry way out of Twitter and then I’ve written a function that, every time someone clicks a link on Twitter, it kind of lets me know, tracks back and so I can see, right, which… and I watch it, I’ve got live stats and streaming on one of the spare monitors, so as this link goes out onto Twitter, I can see it being read, so I can actually what’s actually what the people are reading, what’s been interesting that way, instead of me thinking ‘that’s genius, we’ll use that on the show’. It’s actually kind of crowd-sourcing information like this.

Sarah: Yeah, that’s a better way of doing it, isn’t it? It’s more productive.

Paul: Yeah, but I do the same, it’s like something I really want to read, I’ll open it in a tab and I’ve got the permatabs thing on Firefox, so I’ll set it so that I can’t delete it until I’ve read through it, but usually it just ends up there for weeks.

Ryan: I tag them in Delicious, so I’ve got like tutorials and stuff that I think ‘oh, that looks fantastic’ and I’ve got a ‘to try’ thing, which is slowly increasing in number and I never sit down and have a go through the tutorials or anything like that.

Paul: Yeah, I think the key is to follow a few key, key things and not try and follow too much information, and then just look at what everyone else around you, the people that you respect, in what they’re sending out and try not to get overwhelmed because there’s a lot of information out there.

Sarah: Dead right, there’s so many, it seems to be a new thing on Twitter to actually post those sort of links, day in, day out, which is really handy because there’s a lot of people who have a lot of good stuff on Twitter.

Paul: Oh twitter.com/boaglinks is the premier source of all this information, of course.

Sarah: Of course! (all laugh)

Ryan: Er, OK, so I think the final question to you, then Sarah, is, erm, what inspires you to pursue your personal projects?

Sarah: Erm, oh, that’s a difficult one. I kind of get inspired in strange places, when I came back from the Future of Web Design and Future of Web Apps, I kind of get inspired by other people, not necessarily the apps that they’re producing, or work that other people are producing, but I sort of feed off other people’s energy, strangely. If other people come away from something really, erm, excited about something, I tend to think ‘oh, yeah, that sounds like a good, like when Adobe Air came out, that was a kind of a buzz around that for a while and it got me thinking ‘um, what can you develop with that that would, you know, might be interesting to other people or that other, that other web designers might want to use?’ but that’s kind of what happened with my own app, Olive, it’s kind of on the backburner at the moment, but there was a problem that came up at work and it was coming up time and time again and I thought ‘there must be something out there that actually addresses this issue of, of erm, client management, so went around, couldn’t find anything and then ended up building it, and it was actually built more for me, rather than other people and when I sent it out to a few people, they really liked, and got into using it and, erm, it’s just kind of handy if you build something that’s, that’s great for you, but equally other people find interesting as well. It’s, erm, it’s a win-win, really. I mean, I use it all the time, and there’s other people who do as well, bu
t at the moment it’s, er, needs a lot of updating, because I’ve been so busy with client stuff, but maybe I should have put that first, but clients pay the bills unfortunately.

Ryan: Absolutely, absolutely. I think I, erm, I think I overthink things, so I think to myself ‘oh, I’d love, love for this to exist’ and then I think to myself ‘I could spend the next three years developing that’ and, and someone would do it better than me, you know and just finding time as well.

Paul: Yeah, I think it’s right what Sarah says, you’ve got to scratch your own itch, you’ve got to find something that you would want to use so much that you would spend that amount of time to build it, and then if it’s for you, it doesn’t really matter that much if no one else wants to use it because it does something that you want it to do.

Sarah: Exactly.

Paul: And it’s a learning process, you can choose any language. If you want to learn a new language, if you want to learn Django or Python or something, you could build it in that, just to learn that language, erm, and then send it out in the world, see if people use it.

Sarah: Exactly, that’s kind of what happened. I was learning quite a bit about Ruby at the time, because Olive, Olive’s built on the Ruby on Rails platform and it was so interesting just to get an insight into how different developing with Ruby is compared to PHP. That was just worth it in it’s own right, really because I find that I learn much better with real world examples rather than looking at a load of code. I find that if, if I ever get something like that, I have to take it apart, almost, and then try and work out how to put it all back together so that it works. I think I learn better by doing that and a lot of people do. If you going on to any of the tutorial sites now, there tends to be a lean towards developing an app or something small; I think on the Nettuts at the moment, website – do you guys know that one?

Ryan: Er, yes.

Paul: Yes, ah the Nettuts, oh yeah.

Sarah: Yeah, there’s a, there’s a sway towards actually building like login systems from scratch and things like that on there, where it’s actually showing you the code and then showing you how it works in real world situations which I think is really good, for me, I don’t know about you two, but I personally prefer picking stuff apart (laughs).

Paul: Yeah, absolutely. I usually start at the very lowest common denominator, like a user access system, and I’m learning CakePHP now which is, kind of a Ruby clone for PHP and instead of using their in-build methods which will do it all for you with build this, just write these classes and it’s like ‘No, it’s like the most basic thing I can do in this language, let me learn how to do it’, and I’ll learn that way.

Sarah: Yeah, yeah, that’s, I think when, erm, when I looked at using Ruby for, er, for Olive, I didn’t build it, it was built by a guy, a brilliant guy, Adam Cooke, but I was still really interested to know how it would work and how Ruby is different and the first thing I did was built a, erm, a basic recipe, sort of database thing with, it was off of a tutorial site and I think it’s great if it gives you just a little bit of insight into something that you might not have already realised or known about building your own stuff, then I think you have that sort of passion to go forward with it, you have that confidence to then think ‘oh, well I’ve done that tiny thing, maybe I can do something else with it. Whereas, if you’re doing it for clients, you don’t, you wouldn’t really venture into using another programming language that you weren’t comfortable with on a client site, unless you were a bit silly.

Ryan: Absolutely, absolutely. Paul told me a really funny thing, in between, er, when he told me he was learning CakePHP. He said, I’m trying to remember what it was that you told me, it was ‘if Ruby’s French, CakePHP is French with an English accent’

Paul: Yeah, its kind of the same, just not quite as elegant.

Ryan: Yeah, I thought that was fantastic, that was so fantastic, I made it into, I have some rotating quotes on my web-site, and that made it into my quotes, that was fantastic.

Much thanks goes to Simon Douglas for transcribing this interview so quickly!

Listeners Questions:

Is Using Off-The-Shelf Software Wrong?

Jon Writes:

I guess my question is about the use of off-the-shelf software. I must admit I feel slightly uncomfortable using it at all. As a decent sized agency of 9 people, with our own very capable developers, I can’t escape the nagging feeling that we are “cheating” slightly by using an off-the-shelf platform at all. Although we adhere strictly to licensing requirements, most of our customers do not know that their stores are powered by what is essentially a ready made system, which we then skin, configure and populate.

What are your views about off-the-shelf stuff and the pros and cons of using it on client work?

Thanks and keep up the good work!

I think the main source of your discomfort is the fact that your clients don’t know you are using off-the-shelf software for their projects, which raises the question why not?

Your clients have approached you to provide them with a service they cannot perform themselves. Whether that is building a system from scratch or integrating and customizing an third-party system to meet their needs, you are still the expert.

There are very powerful off-the-shelf e-commerce systems, blog engines and CMS’s that should be thought of as weapons in your arsenal rather than “cheating”. Explaining to your clients why you are going to use a particular system for their project can be hugely beneficial. It shows that you don’t want to waist their time and money re-inventing the wheel.

Therefore, the pro’s are:

It meets there project aims
You are experienced with the system
It’s supported by a third-party team of developers who are dedicated to that one product and includes a vast community of other users who support each other
It can be implemented in a shorter period of time than building from scratch (i.e. cheaper for the client all round)
It’s a tried and tested system (You could even give your client a list of other successful companies that are using it)
It is also more than likely that a third-party product that has been around for several years is a more reliable and robust system than the one you develop in a couple of months.

That said there are always inherent risks in using anything third-party, whether it be API’s, frameworks, libraries or software and I have a general rule of thumb that I try to always adhere
to:

Don’t implement something you don’t understand!

If it breaks, it costs you time and money to fix the problem, and that’s once you’ve diagnosed what that problem is. The longer it takes you to fix the higher the risk that your client is going to lose confidence in your ability to deliver.

So take the time to do some dissecting and learn how to use your tools as fully as you can prior to implementation.

How do you price and quote different projects?

Jamie who’s just started up his own web development company is having trouble working out how to price and quote different projects and wonders if we have any tips that we’ve found helpful when quoting for clients?

One of the hardest things when starting out, and even for established businesses is finding your feet with pricing. I think the biggest lesson I learnt is not to under-quote just to gain the business, even though you are in need of clients. It makes no business sense to work for peanuts, you’re better holding off for a client who respects the work you do and pays honestly for that work rather than being a design machine churning out work just to make ends meet.

The other important thing I learnt in my first year of business is, clients who barter with your prices are generally bad news. We’ve all heard it, “if you can do this one at x-amount we have plenty of other work in the pipeline we want to use you for” – while this sounds tempting, 9 times out of 10 the promise of the further work never comes off, even if it does they would normally expect further work at the “cheap” price they paid you before, as you accepted it so you must be happy to work for that right? Wrong.

I always find it helpful to ask the client for a ballpark figure prior to laying out the full proposal, this negates you wasting time putting together the proposal of cost plus terms and conditions only to find the client wants to build ebay on a budget of £300.

I also find ballpark figures helpful because I find it easier to provide the client with options, even if they have a relatively small budget there is normally still something you can do, even if it is very basic – but it gives you a starting block to explain if their budget was a bigger they could bolt on a CMS system or have a better shopping cart, then explain the benefits of those. You’d be suprised how much the budgets are then increased by.

It’s all about providing the client with the best solution for their project at the end of the day, and if you think the best solution would be bolting on Expression Engine or the like, you need to give the client the choice to do this and expand their budget if necessary rather than cut them out of the equation because of it, it’s all about educating the client.

10 criteria for selecting a CMS

Posted in Development on March 5, 2009 by Paul Boag

Choosing a content management system can be tricky. Without a clearly deﬁned set of requirements you will be seduced by fancy functionality that you will never use. What then should you look for in a CMS?

I have written about content management systems before. I have highlighted the hidden costs of a CMS, explained the differentiators behind the feature list and even provided advice for CMS users. However, I have never asked what features you should be looking for in a content management systems. That is what I want to address here.

When I left home for University my mother taught me a valuable lesson. If you want to save money, never go grocery shopping when you are hungry and always write a list. If you don’t you will be tempted to buy things you do not need.

The same principle is true when it comes to selecting a content management system. Without a clearly defined set of requirements you will be seduced by fancy functionality that you will never use. Before you know it you will be buying an enterprise level system for tens of thousands of dollars when a free blogging tool would have done.

How then do you establish your list of requirements? Although your circumstances will vary there are ten areas that are particularly important.

1. Core functionality

When most people think of content management, they are thinking of the creation, deletion, editing and organizing of pages. They assume all content management systems do this and so take the functionality for granted. However that is not necessarily the case. There is also no guarantee that it is done in an intuitive fashion.

Not all blogging platforms for example allow the owner to manage and organize pages into a tree hierarchy. Instead the individual ‘posts’ are automatically organized by criteria such as date or category. In some situations this is perfectly adequate. In fact this limitation in functionality keeps the interface simple and easy to understand. However, in other circumstances the absence of this functionality can be frustrating.

Consider carefully the basic functionality you need. Even if you do not require the ability to structure and organize pages now, you may in the future. Be wary of any system that does not allow you to complete these core activities.

Also ask yourself how easy it is to complete these tasks. There are literally thousands of content management systems on the market, the majority of which offer the core functionality. However they vary hugely in usability. Alway look to test a system for usability before making a purchase.

The editor is one core feature worth particular attention.

2. The editor

The majority of content management systems have a WYSIWYG editor. Strangely this editor is often ill considered, despite the fact that it is the most used feature within the system.

The editor is the interface through which content is added and amended. Traditionally, it has also allowed the content provider to apply basic formatting such as the selection of fonts and colour. However more recently there has been a move away from this type of editor to something that reflects the principles of best practice.

The danger of traditional WYSIWYG editors is two fold. First, they give the content provider too much design control. They are able to customize the appearance of a page to such an extent that it could undermine the consistence of design and branding. Second, in order to achieve this level of design control the cms mixes design and content.

The new generation of editors take a different approach. The content provider uses the editor to markup headings, lists, links and other elements without dictating how they should appear.

Ensure your list of requirements include an editor that uses this approach and does not give content providers control over appearance. At the very least look for content management systems that allow the editor to be replaced with a more appropriate solution.

The editor should also be able to handle external assets including images and downloads. That brings us on to the management of these assets.

3. Managing assets

Managing images and files are badly handled by some cms packages. Issues of accessibility and ease of use can cause frustration with badly designed systems. Images in particular can cause problems. Ensure that the content management system you select forces content provider to add alt attributes to imagery. You may also want a cms that provides basic image editing tools such as crop, resize and rotate. However, finding such a cms can be a challenge.

Also consider how the content management system deals with uploading and attaching PDFs, Word documents and other similar files. How are they then displayed to users? What descriptions can be attached to the files and is the search capable of indexing them.

4. Search

Search is an important aspect of any site. Approximately half of users will start with search when looking for content. However, often the search functionality available in content management systems is inadequate.

Here are a few things to look for when assessing search functionality:

Freshness – How often does the search engine index your site? This is especially important if your site changes regularly.
Completeness – Does it index the entire content of each page? What about attached files such as PDFs, Word documents, Excel and Powerpoint?
Speed – Some search engines can take an age to return results. This is especially common on large sites.
Scope – Can you limit the scope of search to a particular section of the site or refine search results once returned?
Ranking – How does the search engine determine the ranking of results? Can this be customized either by the website owner or by the user?
Customization – Can you control how results are returned and customize the design?

The issue of customization is one that goes far beyond search.

5. Customization

I have been unfortunate enough to work with content management systems that are completely inflexible in their presentation.

The presentation of your content should not be dictated by technology. It is simply not necessary now that we have techniques for separating design and content. Unfortunately like web designers, many content management providers have failed to adopt best practice and their systems produce horrendous code. This places unreasonable constraints on design and seriously impacts accessibility.

You need a content management system that allows flexibility in the way content is returned and presented. For example can you return news stories in reverse chronological order? Can you display events on a calendar? Is it possible to extract the latest user comments and display them on the homepage? It is flexibility that makes a cms stand out.

Talking of user comments, it is worth mentioning all forms of user interactions.

6. User interaction

If you intend to gather user feedback, your cms must provide that functionality or allow third party plugins to do so. Equally, if you want a community on your site then you will require functionality such as chat, forums, comments and ratings.

As a minimum you will require the ability to post forms and collect the responses. How easy does the cms make this process? Can you customize the fields or does that require technical expertise? What about the results? Can you specify who they are emailed to? Can they be written to a database or outputted as an excel document? Consider the type of functionality that you will require and look for a cms that supports that.

Also ask what tools exist for communicating with your customers. Can you send email newsletters? Can recipients be organized into groups who are mailed individually? What about news feeds and RSS?

Finally consider how you want users to be managed. Do you need to reset passwords or set permissions? Do you need to be able to export user information into other systems?

But it is not just user permissions that may need managing. You also have to consider permissions for those editing the site.

7. Roles and permissions

As the number of content providers increase, you will want more control over who can edit what. For example, personnel should be able to post job advertisements but not add content to the homepage. This requires a content management system that supports permissions. Although implementation can vary, permissions normally allow you to specify whether users to edit specific pages or even entire sections of the site.

As the number of contributors grows still further you may require one individual to review the content being posted to ensure accuracy and consistent tone. Alternatively content might be inputed by a junior member of staff who requires the approval of somebody more senior before making that content live.

In both cases this requires a cms that supports multiple roles. This can be as simple as editors and approver, or complex allowing customized roles with different permissions.

Finally, enterprise level content management systems support entire workflows where a page update has to go through a series of checkpoints before being allowed to go live. These complex scenarios require the ability to roll back pages to a pervious version.

8. Versioning

Being able to revert to a previous version of a page allows you to quickly recover if something is posted by accident.

Some content management systems have complex versioning that allow you to rollback to a specific date. However, in most cases this is overkill. The most common use of versioning is simply to return to the last saved state.

Although this sounds like an indispensable feature, in my experience it is rarely used expect in complex workflow situations. That said, although versioning was once a enterprise level tool it is increasingly becoming available in most content management systems. This is also true of multi-site support.

9. Multiple site support

With more content management systems allowing you to run multiple websites from the same installation, I would recommend that this is a must-have feature.

Although you may not currently need to manage more than a single site, that could change. You may decide to launch a new site targeting a different audience.

Alternatively with the growth of the mobile web, you may create a separate site designed for mobile devices. Whatever the reason, having the flexibility to run multiple websites is important.

Another feature that you may not require immediately but could need in the future, is multilingual support.

10. Multilingual support

It is easy to dismiss the need to support multiple languages. Your site may be targeted specifically at the domestic market or you may sell a language specific product. However think twice before dismissing this requirement.

Even if your product is language specific, that could change. It is important that your cms can grow with your business and changing requirements.

Also just because you are targeting the domestic market does not mean you can ignore language. We live in a multicultural society where numerous languages are spoken. Being able to accommodate these differences provides a significant edge on your competition.

That said, do think through the ramifications of this requirement. Just because you have the ability to add multiple languages doesn’t mean you have the content. Too many of my clients have insisted on multilingual support and yet have never used it. They have failed to consider where they are going to get the content translated and how they intend to pay for it.

Conclusions

Features are an important part of the CMS selection process, but they are not everything. It is also important to consider issues like licensing, support, accessibility, security, training and much more.

I leave you with a word of warning – Don’t let your list of requirements become a wish list. Keep your requirements to a minimum, but at the same time keep an eye on the future. Its a fine line to walk. On one hand you don’t want to pay for functionality you never use. On the other, you do not want to be stuck with a content management system that no longer meets your needs.

This has been an extract from the Website Owners Manual - now available as an ebook and for preorder in print.

7 Harsh Truths about running online communities

Posted in Site content on February 23, 2009 by Paul Boag

In ‘10 harsh truths about corporate websites‘ I highlighted some of the problems I perceive in how companies run their websites. However, many organisations are not content to simply run a website, they want to run an online community too.

Don’t get me wrong, I am excited to see organisations embracing the idea of community. I have been involved in running virtuals communities since 1996 and in 2004 I wrote about the business benefits of community. To this day I encourage Headscape’s clients to build relationships with their users.

A well run community can…

Drive traffic to your site
Generate a passionate, evangelistic users
Encourage repeat traffic
Help develop your products and services
Save you money

This is not a ‘rant’ against community, or even corporations running communities. It is an argument against the way they sometimes choose to do so. I continually see the same mistakes being made by organisations. It is time that they faced the harsh realities of running an online community.

1. Technology does not create community

When clients ask for help to build a community, they almost always talk in terms of technology. “We want to add a forum to our site” or “can you create a profile system”.

In ‘10 harsh truths about corporate websites‘ I write about how a CMS will not solve your content problems. In the same way a forum will not create a community.

Vanilla Website

Community is about people and relationships, not technology. The technology is the easy part. You can have a forum like Vanilla up and running in minutes, but it will take months of hard work to build a vibrant community.

If you implement the technology and just sit back then your community will fail. The technology merely allows you to engage with your community in the same way as a telephone lets you talk to your friends. It is a tool and nothing more.

2. Show some commitment

I have already said that building a community takes time, but it also takes commitment.

Too many website owners start communities only to give up when they do not see fast results. A community can take months to get off the ground and years before it shows real returns.

It also takes ongoing input. To make your community successful it must be nurtured on a daily basis. When a user posts, you need to replying promptly. Until your community is well established it will need monitoring multiple times a day.

You also need to demonstrate commitment to the individuals that make up your community. You need to take on board their input, address their concerns and encourage their contributions. You need to show you care.

3. Learn how to lead

As well as caring for your users, you also need to know how to lead them.

This is not leadership in the ‘managerial’ sense. These people are not obligated to listen to you or do what you say. You need to inspire, excite and encourage them.

Running a community requires you to be more like a politician or preacher than a manager. You need to mobilise people around a common cause and stamp your personality on the community.

Unfortunately there are few course that teach these kinds of skills. However, I would encourage you to look at great leaders like Gandhi, Martin Luther King and even Barak Obama for inspiration. These men can teach you a lot about engaging with people and encourage others to follow your direction.

Photograph of Barak Obama

4. An antisocial community is your fault

As the leader of your community, your personality sets the tone. As a result if the community behaves in ways you do not want, then you only have yourself to blame.

I have seen many bloggers write about the negative comments they get on their posts. In most cases this is due to the tone they themselves strike in their writing. Although there are exceptions I believe that users will respond in the same voice you yourself set. If you are irreverent, then so will your users be. If you are rude, expect rude responses.

A good example of this is the social news website digg.com. Digg has developed a reputation for its ‘harsh and juvenile’ comments. I believe this comes from the leadership of founder Kevin Rose in his associated podcast Diggnation. This irreverent, comically and highly entertaining podcast has set a tone that has been carried across by users into the comments.

Diggnation Homepage

This is not a criticism of diggnation. Digg.com has become very successful because of their passionate community. It is merely an observation that you reap what you sow.

5. You need to swallow your pride

Another aspect to leading a community is the need to learn humility. No matter how well you run your community, you will mess up. When you do, how you respond is of crucial importance.

Because of the ‘distance’ that the web affords, people are often more critical than they would be face to face. Feelings are overstated and there is an inability to read the non-verbal signals we normally rely upon. This can often lead to confrontation and disagreement.

I have seen communities fail because the organisation alienated its community by responding badly to criticism.

If you want to run a successful community you must swallow your pride and never respond defensively to criticism. Instead acknowledge the comments and thank people for their honesty. Ask others what they think and hopefully they will come to your defence. If not, then you must seriously consider whether the criticism is valid. If it is then you need to admit your mistake and correct it.

By admitting you are wrong, it is possible to heal a relationship with your community and actually leave them even more enthusiastic about your brand than before.

flickr blog post - Sometimes we suck

6. Stop trying to control the message

If you work in marketing some of these points may make you feel uncomfortable. It feels messy and you do not have control over your message. Unfortunately that is the reality of community.

Community is not marketing in the traditional sense. It is not a broadcast medium, it is a dialogue with your users. Failing to grasp that will rip the heart from your community and force it underground.

I have seen unsuspecting companies experience a terrible backlash from a community simply fed up with being sold at rather than listened to. Users do not want a sales pitch or a feature list. They want the opportunity to feedback and a chance to help shape the future of the product or service they use.

Another tactic for controlling the message is to moderate. In extreme cases I have seen organisations moderate every single user contribution that appears on their site. However, I have also seen companies quietly remove negative comments made about their products and services. This is enormously counter productive because people feel censored and will go elsewhere to express their feelings.

That is the trouble with community, you simply cannot control it. If you do not allow it to flourish on your site and engage with it there, then it will pop up elsewhere where you have no control over what is written.

Adobe complaints on Get Satisfaction

7. Nobody likes to be alone

The final harsh truth I want to raise is that “users don’t want to be alone”. Too many organisations launch a forum with a plethora of topics and discussion areas only to have it lay dormant and unused. The reason – it appears empty, so what is the point of posting.

Before you can even consider adding community features to your site you need a critical mass of users that want to get involved. A lot of companies add community features not because users are asking for them but because management wants it. Communities like that rarely succeed.

Also there is a tendency to go straight for a forum. However, a forum requires a substantial number of users to work. Contributions can often become buried in some thread or topic and remain unanswered because it is never seen. If your community is small you may be better starting with comments, reviews or a mailing list. User contributions are much more likely to be noticed using these tools.

Finally, make sure you are seeding the discussion through new topics of your own. Asking lots of questions is a great way to stimulate discussion and prevent people from feeling like the only kid at the party.

Conclusions

After reading this you might feel that running a community is too much like hard work. You may decide not bother at all. However, that would be a mistake.

The ultimate harsh truth is that your users will be talking about your website, services and products, whether you want them to or not. The only question is whether you want to engage in that discussion.

10 harsh truths about corporate websites

Posted in Web strategy on February 11, 2009 by Paul Boag

We all make mistakes running our websites. However the nature of those mistakes varies. As your site and organisation grow, the mistakes begin to change. This post addresses common mistakes in larger organisations.

Most of the clients I work with at Headscape are larger organisations – Universities, large charities, public sector institutions and large companies.

Over the last 7 years I have noticed certain reassuring misconceptions within these organisations. The idea of this post is to dispel these illusions and encourage people to face the harsh reality.

The problem is that if you are reading this post you are probably already aware of these things. However, hopefully this article will be a useful tool for convincing others within your organisation.

Anyway, here are my 10 harsh truths about larger websites.

1. You need a separate web division

In most organisations I work with the website is managed by either the marketing or IT department. However, this inevitably leads to a turf war and the site becoming the victim of internal politics.

In reality running a web strategy is not particularly suited to either group. IT maybe excellent at rolling out complex systems but they are not suited to developing a friendly users experience or establishing an online brand.

Marketing on the other hand is little better. As Jeffrey Zeldman puts it in his article ‘Let there be web divisions‘:

The web is a conversation. Marketing, by contrast, is a monologue… And then there’s all that messy business with semantic markup, CSS, unobtrusive scripting, card-sorting exercises, HTML run-throughs, involving users in accessibility, and the rest of the skills and experience that don’t fall under Marketing’s purview.

Instead the website should be managed by a single unified team. Again Zeldman sums it up when he writes:

Put them in a division that recognizes that your site is not a bastard of your brochures, nor a natural outgrowth of your group calendar. Let there be web divisions.

2. Managing your website is a full time job

Not only is the website often split between marketing and IT, it is also normally under resourced. Instead of having a dedicated web team, those responsible for the website are often expected to run it alongside their ‘day job’.

Where a web team is in place they are often over stretched. The vast majority of their time is spent on day to day maintenance rather than longer term strategic thinking.

This situation is further exaggerated because the people hired to ‘maintain’ the website are junior members of staff. They do not have the experience or authority to push the website forward.

It is time for organisations to seriously investing in their websites by hiring full time senior web managers to move their web strategies forward.

3. Periodic redesign is not enough

Because corporate websites are under resourced they are often neglected for long periods of time. They slowly become out of date both in terms of content, design and technology.

Eventually the site becomes such an embarrassment that management step in and demand it is sorted. This inevitably leads to a complete redesign at considerable expense.

As I point out in the website owners manual this a flawed approach. It is a waste of money because when the old site is replaced the investment put into it is lost. It is also tough on cash flow with a large expenditure happening every few years.

A better way is continual investment in your site, so allowing it to evolve over time. Not only is this less wasteful it is also better for the users as is pointed out in Cameron Moll’s post ‘Good Designers Redesign, Great Designers Realign‘.

4. Your site cannot appeal to everyone

One of the first questions I ask our clients is ‘who is your target audience?’ I am regularly shocked at the length of the reply. Too often it includes a long and detailed list of diverse people.

Inevitably my next question is which of those many demographic groups are most important. Depressingly the answer is that they are all equally important.

The harsh truth is that if you build a site for everybody it will appeal to nobody. It is important to be extremely focused in your audience and cater your design and content around them.

Does this mean you have to ignore your other users? Not at all. Your site should be accessible by all and should not offend or exclude anybody. However, it does need to have a clearly defined audience that the site is primarily aimed at.

5. Your site is not all about you

Where some website managers want their websites to appeal to everybody, others want it to appeal to themselves and their colleagues.

A surprising number of organisations choose to ignore their users entirely and build their websites entirely around an organisational perspective. This typically manifests itself in inappropriate design that caters to the managing directors personal preferences and content full of internal terminology and jargon.

A website should not be about pandering to the preferences of staff but about meeting the needs of users. Too many designs are rejected because the boss doesn’t like green. Equally too much website copy uses acronyms and terms that are only used internally within an organisation.

6. Design by committee brings death

The ultimate expression of a larger organisations approach to website management is the committee. A committee is formed to tackle the website because internal politics demand everybody has their say and all considerations are taken into account.

To say that all committees are a bad idea is naive and to suggest that a large corporate website could be developed without consultation is fanciful. However when it comes to design, committees are often the kiss of death.

Design is subjective. The way we respond to a design can be influenced by culture, gender, age, childhood experience or even physical conditions (such as colour blindness). What one person considers great design another could hate. This is why it is so important that design decisions are informed by user testing rather than personal experience. Unfortunately this approach is rarely followed when a committee is involved in design decisions.

Instead, design by committee becomes about compromise. Because different committee members have different opinions about the design, they looks for ways to find common ground. One person hates the blue colour palette while another loves it. This leads to design on the fly when the committee instructs the designer to ‘try a different blue’ in the hopes of finding a middle ground. Unfortunately this can only leads to bland design which neither appeals to, or excites, anybody.

7. You’re not getting value from your web team

Whether they have an in-house web team or use an external agency many organisations fail to get the most from their web designers.

Web designers are much more than pixel pushers. They have a wealth of knowledge about the web and how users interact with it. They also understand design techniques including grid systems, white space, colour theory and much more.

It is therefore wasteful to micro manage them by asking for ‘the logo to be made bigger’ or to ‘move that 3 pixels to the left’. By doing so you are reducing their role to that of software operator and wasting the wealth of experience they have.

If you want to get the maximum return from your web team present them with problems not solutions. For example, if you have a site aimed at teenage girls and the designer goes for corporate blue, suggest that the audience might not respond well to the colour. Do not tell them to change it to pink. That way the designer has the freedom to find a solution which might be even better than your choice of pink. You allow them to solve the problem you have presented.

8. A CMS is not a silver bullet

Many of the clients I work with have amazingly unrealistic expectations about content management systems. Those without one think it will solve all of their content woes, while those who do have one moan about it because it hasn’t!

It is certainly true that a content management system can bring a lot of benefits. They…

reduce the technical barriers of adding content,
all more people to edit and add content,
facilitate faster updates,
allow greater control.

However, many content management systems are less flexible than their owners wish. They fail to meet the changing demands of the websites they manage.

Website managers also complain that their CMS is hard to use. However, in many cases this is because those using them have not been given adequate training or are not using it regularly enough.

Finally, a content management system may allow for the easy updating of content, but that does not ensure it will be updated or even that the quality of copy will be maintained. Many content managed websites still have out of date content or are filled with poor quality copy. This is because the internal processes have not been put in place to support the content contributors.

If you are looking to a content management system to solve your site maintenance issues you will be disappointed.

9. You have too much content

Part of the problem with content maintenance on larger corporate websites is that there is too much content in the first place. Most of these sites have ‘evolved’ over years with more and more content being added. At no stage has anybody ever reviewed that content and asked what can be taken away.

Many website managers fill their sites with copy nobody will read. This happens because of:

A fear of missing something – By putting everything online they believe users will be able to find whatever they want. Unfortunately, with so much information being made available, it is hard to find anything.
A fear users will not understand – Whether it is a lack of confidence in their site or in their audience, many website managers feel the need to provide endless instructions to users. Unfortunately, users never read this copy.
A desperate desire to convince - Many website managers are desperate to sell their product or communicate their message. Text becomes bloated with sales copy which actually conveys little valuable information.

Steve Krug in his book ‘Don’t make me think’ encourages website managers to ‘Get rid of half the words on each page, then get rid of half of what’s left’. This will reduce the noise level of each page and make useful content more prominent.

10. You are wasting money on social networking

I have been encouraged that increasingly website managers are recognising that a web strategy is about more than running a website. They are using tools like Twitter, Facebook and YouTube to increase their reach and engage with new audiences.

However, although they are using these tools, too often they are doing so ineffectively. Corporate twitter accounts and posting sales demonstrations to YouTube miss the essence of social networking.

Social networking is about people engaging with people. Individuals do not want to build relationships with brands or corporations. They want to talk with other people. Too many organisations are throwing millions into facebook apps and viral videos when could be spending that money on engaging with people in a transparent and open away.

Instead of having a corporate twitter account or indeed even a corporate blog, encourage your employees to start tweeting and blogging themselves. Provide guildelines on acceptable behaviour and the tools they need to start engaging directly with the community that surrounds your products and services. This not only demonstrates a commitment to your community but also a human side to your business.

Conclusions

Large organisations do a lot right in the running of their websites. However, they also face some unique challenges that can lead to painful mistakes. Resolving these problems will involve accepting mistakes have been made, overcoming internal politics, and changing the way you control your brand. However, doing so will give you a significant competitive advantage and allow your web strategy to become more effective over the long term.

For more information on how you can make your site more effective read the Website Owners Manual or discuss your site with Paul personally.

There is a followup to this post entitled ‘10 ways to battle site bureaucracy.’ Check it out!

5 options when website budgets get slashed

Posted in Web strategy on January 30, 2009 by Paul Boag

Your site is in desperate need of a redesign, content is out of date and the technology is archaic. Unfortunately times are tight and your budget has been cut. What do you do?

The economic downturn is affecting everybody and even at Headscape we have noticed the budgets of clients shrinking. With less money to spend how can you maximise the return on your investment?

To be honest I think it is a good thing that people have less to spend on their websites. We have had too many clients approach us asking for complete overhauls of their sites when that is not what is really required. Often more subtle changes can have a greater impact over the longer term. They certainly generate a better return on investment.

We have been working closely with our clients to suggest ways they can improve their sites without breaking the bank. Here are just 5 of our suggestions.

1. Realign rather than redesign

Why do you need a redesign anyway? Redesigning your entire website is time consuming and costly. However, more importantly it is often unnecessary. I seem to be quoting Cameron Moll’s excellent article “Good Designers Redesign, Great Designers Realign” a lot recently, but that is because he talks a lot of sense. He writes:

Like a kid in a candy store, we creatives redesign like it’s the new black. Why do we possess such an insatiable desire to refresh and remake? Why do we thrive on renewal? What tempts us to be seduced by the sway of renaissance?

I believe it is because we see a redesign as the solution to a failing, tired site. However that is rarely the case as Cameron goes on to explain:

Too often, look and feel, color scheme, layout, and identity are presented as solutions to problems… long before regard is given to other less-aesthetic issues that may very well be the root of the problem. The old warning against treating symptom rather than cause comes to mind.

What is more redesigns can often cause more harm than good by confusing the loyal users who are familiar with your old site.

When budgets are tight let go of the notion you need to do a complete redesign. You can improve your site many times over with the smallest change. Just take the case of the $300 million button I mentioned in show 150 of my podcast.

2. Simplify

As website owners we are always looking to expand our websites by adding more features and content. However, that costs money we may not have.

Here is a radical alternative – Instead of adding more to your site, why not take things away.

Typically websites are stuffed with content and features that users simply do not use. A quick look at your analytics package will demonstrate the problem. The vast majority of traffic is to a handful of pages.

The problem is we tend to leave content in because ‘somebody might find it useful’. Although this maybe true, it does not necessarily mean keeping content is a good idea.

The more content and features we make available the harder it is for users to find what they need. It is the proverbial ‘needle in a haystack’.

Fortunately, simplifying your website does not have to be entirely about removing content. According to John Maeda’s book ‘The Laws of Simplicity‘ we can also streamline our sites by shrinking and hiding content too. Consider ways to reduce the prominence of less important content, to place a greater emphasis on what matters.

When budgets are tight take a long hard look at your site and ask whether more can be achieved by simplifying what you have rather than adding complexity.

3. Prioritise and phase development

Another technique which can be used when budgets are tight is to phase development. There seems to be a tendency among website owners to store up changes and roll them out in a single large deployment. Unfortunately this means a large single expenditure too and that can be problematic from a cash flow perspective.

A better approach is to roll out incremental changes on an ongoing basis. Not only is this better from a financial perspective, it brings other benefits as I explain in the Website Owners Manual. Phase development also provides:

Faster delivery because new features are launched independently. Some features can be launched while others are in development. This prevents a single feature stalling the entire rollout.
More accurate estimates. Bigger project are harder to estimate. Breaking them down makes it easier for suppliers to quote accurately.
Better PR opportunities. Whenever a new feature is launched there is an opportunity to publicize the site. New features can motivate users into taking another look. A single large project only provides a single opportunity to grab peoples attention.
Limited risk of working with a new supplier. Choosing an agency is always a risk. Until you work with somebody, it is hard to gauge how good they are. Reduce this risk by limiting the size of project they are commissioned to build. If the agency fails to perform, you can look elsewhere when commissioning subsequent work.

This is an approach commonly adopted by larger websites with their own in-house teams but much rarer among smaller sites who use external agencies. Nevertheless, it is an approach which works well in tough times.

4. Reuse and recycle

Too often we reinvent the wheel. When budgets are plentiful this can make sense. Although there is similar functionality out there, we might choose to develop it ourselves so we have more control or can customise it to our exact requirements. However as budgets begin to get squeezed these are luxuries we cannot afford.

In a world of widgets, APIs and open source it is becoming increasingly hard to argue the case for custom builds. Why build your own mapping application when there is Google Maps? Why build a forum when you could use an open source alternative like Vanilla?

My only word of warning is in regards to integration. It can be hard to get these ‘prebuilt’ tools to work together. Be careful that the savings made are not lost to integration problems. Where possible use tools like WordPress that provides an architecture with a wide range of plugins for quick integration.

5. Move beyond the website

Finally, I think it is important to remember that your web strategy is not all about your website. We spend the majority of our ever decreasing budgets on adding bells and whistles to existing websites when there are large number of potential customers who never reach our sites.

Instead of sinking your budget and efforts solely into your website consider looking further afield. Could your web strategy be better served by putting resources into a Facebook group or a twitter account for example? Would your target audience listen to a podcast? Do they read RSS? What about a mailing list? The possibilities are endless.

Ask yourself where your target audience congregates. Instead of constantly trying to draw users to your site begin to spend time where they already meet. What social sites do they use? What editorial sites do they read? Contribute to these communities and offer to write for the editorial sites they read.

Many of these things can be done at almost no cost and with little technical knowledge. All it takes is some time and enthusiasm.

Conclusions

Whether a site is successful is not dictated by its budget. However many larger organisations have relied on money as a method of driving their web strategy forward. As these budgets are slashed there is an opportunity to gain a competitive advantage by being smarter.

Hopefully this post has demonstrated a few of the possible avenues available and inspired you to discover some more of your own. However if you would like some more personal advice specific to your own website then feel free to drop me an email.

148. Recession Cheer

Posted in Classic shows on January 13, 2009 by Paul Boag

On this weeks show: Surviving the recession with Andy Budd, providing effective browser support and free boagworld consultancy.

Download this show.

Launch our podcast player

Housekeeping

Unfortunately we have a bit of housekeeping to get out of the way before we begin:

Boagworld Christmas Appeal – I really want to thank everybody who gave so generously to this year’s Christmas Appeal. You guys have raised over £2000 for Sarah and Simon’s work in India and they are both over the moon. This money will allow them to provide better facilities for the growing number of children they work with, and doubles the amount raised last year.
Transcribers – After such an amazing effort for the Christmas appeal I feel bad asking you for more. However, we really need people to help transcribe the podcast interviews. We believe it is important to make our show as accessible as possible and we need your help to do that. If you feel you could help or have questions about what is involved email Ryan Taylor at [email protected].
.net Magazine offer – Fortunately my next piece of housekeeping allows me to give something back to you guys. I know you love the offers and competitions we run from time to time and this is a particularly good one. .net magazine have been kind enough to offer boagworld listeners some massive discounts on their annual subscription. In case you haven’t heard of .net magazine it is the UKs premier web design magazine and has some truly phenomenal content each month. If you are based in the UK, you can now get the magazine for 50% off. That is only £9.75 every 3 months. In the USA the discount is even bigger at 54%. That means an entire years subscription is only £64.99. In the EU you pay £55 for a year and the rest of the world pays £67. Those are excellent prices for a really good magazine. To take advantage of these offers visit the special boagworld offer page.
Free consultancy – My final piece of housekeeping is a little competition we would like to run. We are always giving away other people’s stuff but never give away anything ourselves. To rectify this problem we are giving away a day of our time to a lucky winner. Myself and Marcus will provide a free days consultancy where we will dispense advice on ways you can take your website forward. If you are interested in entering, email myself by the end of January. Include your name, company (if you have one), URL and why you want our help. We will pick the most deserving case and contact them at the end of the month.

News and events

Obviously a lot has happened in the world of web design while we have been on our Christmas break. To make matters worse, I must confess to not following the news while we were away. I have therefore gone for the first four stories that caught my eye. Apologies for the lack of professionalism!

A roundup of 24 ways

Way back in show 146 I mentioned the return of the 24 Ways website. As I explained on that show 24 ways is an advent calendar for web geeks. Each day throughout December they publish a daily dose of web design and development goodness to bring a little Christmas cheer.

As I said before 24 Ways is without a doubt one of my favourite web design sites. However, it does have one fatal flaw – it releases one article every day throughout December and I just can’t keep up. December is always mad with clients wanting stuff wrapped up before Christmas and people taking holiday felt right and center. I simply do not have time to read everything they publish.

Fortunately their archive of articles are still all waiting for me on my return and make perfect reading as I struggle to return to work.

This year has a truly bumper crop that I cannot wait to get into. The top titles that have grabbed my attention are:

Sitewide Search On A Shoe String by Christian Heilmann
The IE6 Equation by Jeremy Keith (Deciding when to support IE using Algebra!)
The First Tool You Reach For by Kevin Yank (A look at CSS tables)
Making Modular Layout Systems by Jason Santa Maria (Gaining greater flexibility in laying out content)
Shiny Happy Buttons by John Allsopp (Styling HTML buttons without resorting to images)
Recession Tips For Web Designers by Jeffrey Zeldman
Contract Killer by Andy Clarke (Writing the perfect contract)

Most of these I have yet to read but they promise to keep me entertained and informed until next year.

WCAG 2.0. is official

Probably the most significant story while we have been away is the release of WCAG 2.0. WCAG 2 has taken an age to be released but has also come a long way from its controversial beginnings. When I read some of the initial drafts it was horribly complex and anything but accessible. However the final release is extremely well thought through and communicates complex concepts and ideas in an easy to understand manor.

I think what impresses me most about WCAG 2 is the way the guidelines are conveyed. It has four layers of guidance which include:

Principles – These are broad principles of accessibility which need to be understood by everybody. If you had to explain web accessibility to senior management you would probably talk in terms of these top level principles. They include the need for a website to be perceivable, operable, understandable, and robust.
Guidelines – There are a total of 12 guidelines organised into the 4 overarching principles. These are ideal for website owners or project managers that need to understand more detail on how to achieve the broader principles but do not need to understand the technical detail.
Success Criteria – For each guideline, testable success criteria are provided that allow designers and developers to know specifically how to conform to a guideline. These are the equivalent of the WCAG 1 guidelines and are still organised into Priority 1, 2 and 3.
Techniques – Finally, designers and developers can also access techniques that may help them to fulfil the success criteria but are not in themselves mandatory.

It is a very logical approach and makes it easy for anybody to understand how to make their site accessible. With these guidelines now official it is important that you begin to learn about these guidelines now, even if you just start with the 4 broad principles.

Issuu Smart Look

From WCAG 2 to something that encourages website owners to ignore accessibility! I often find myself torn over whether to share something on this show or not. Part of me wants to teach and encourage best practice, but another part is more pragmatic and accepts that sometimes we have to compromise. The next item is an example of the latter.

Website owners love to post PDF, Word files, and Powerpoint presentations on their site. It is quick, easy and gets their content online with minimal fuss. However, it creates accessibility problems requiring users to have appropriate software or plug-ins. It also makes it hard for search engines to index their content and increases demands on bandwidth.

If you are a website owner and you do this – stop it!

That said, if you have no choice or you are a web designer being forced at gunpoint by your client, then there maybe some hope.

Document publishing site Issuu has released a promising Javascript tool called Smart Look that allows users to view PDFs, Word files and Powerpoint presentations in much the same way you would view an image using one of those Javascript overly script.

The best thing about the service is that it involves very few changes to your site. All you have to do is copy and paste some Javascript into each page. Your downloads will then be miraculously presented in the new format.

A List Apart discusses content

Finally, I wanted to mention two articles posted on A List Apart over the Christmas break. Both article tackle the subject of Content Strategy. Without a doubt content is the most ignored aspect of our websites and yet is also the most important. It is great to see the profile of content increasing and seeing sites like A List Apart promoting it.

However, I do have doubts about the way content specialists are promoting their work. This particularly shines through in the two recent List Apart articles. First, there is an obvious sense of frustration that people do not value their profession. This is entirely understandable. However, sometimes it comes across as them ‘justifying their own existence’ rather than emphasising the value of content. Second, and probably more significantly, they seem to be fracturing their profession into more and more specialist areas. Where once there was a content editor there are now content strategists, copywriters, editorial specialists, content analysts and more.

Although this specialisation is not out of line with the way the entire web design sector is moving (after all once upon a time a ‘web designer’ built your entire site) I don’t believe the majority of clients are ready for this complexity.

Everything I read in these two posts was excellent, but both struck me as expensive and complex. I still struggle to convince clients of the value of investing in content and I don’t feel these articles do anything to aid that cause. Of course, that wasn’t really their aim. However, what I need is a simple and coherent argument for investing in people to write good copy before we start breaking the skillset down even further.

That said, these are great articles and certainly worth reading, if for no other reason than to understand the importance and complexity of our content.

Feature: Effective Browser Support

Browser support should focus on usability and accessibility rather than pixel perfect design. Sites should render in all browsers, but provide advanced features and aesthetics to those which can support it. Read More

Interview: Andy Budd on how to recession proof your business

Paul: So here we are a new year and our first interview of the year and who else would we get on the show except Andy Budd? Hello Andy.

Andy: Hi Paul. How are you doing?

Paul: I’m doing very well. It’s been so long since we’ve had you on the show. Probably for good reason.

Andy: Are you running out of guests or something?

Paul: Yeah, we’re just having to repeat now, endlessly. There’s only three people that can string a sentence together, that’s the problem, of which I am not one of them.

Andy: Aww, you do yourself a disservice.

Paul: So we thought we’d pick a nice cheery subject. Me and Andy had a little chat earlier about what subject we would talk about today and we thought, "New year, new opportunities, exciting times, let’s talk about the recession and the economic downturn." So here we are. Everybody’s been going on so much at the moment that it’s all doom and gloom and I have to say, I don’t know about you, but you know I’m seeing with regularity on twitter people saying, "I’ve just been made redundant," and it’s a bit of a scary time, isn’t it really?

Andy: Um yeah I think it is. I think a lot of people at really good companies, really good people at Yahoo! and whatever have been made redundant in the last few weeks. Last.fm have been having redundancies as well and it’s like, "Oh wow, really smart people are being made redundant," so it is a bit of a worry for everybody I think.

Paul: The trouble is, everybody’s a bit cagey, aren’t they about their own situation and what’s going on so I thought, "Let’s talk a little bit, try and clear up some of the mystery around it," and I thought, "Let’s start by talking a little bit about our own experiences," you run a small agency, I run a small agency. I mean from our personal point of view at Headscape we have seen a little bit of a downturn. Not dramatic. You know I keep kind of waiting for the other shoe to drop and everything to dry up but certainly we’ve seen maybe a slight reduction in the value, the budget that people have and they seem to be taking longer to make a decision and thinking more carefully about what they’re doing. Is that similar to what you’re experiencing with Clearleft or is everything lovely with you guys?

Andy: No, I think that’s probably very similar here. I mean I know sort of before Christmas we really hadn’t experienced much of an effect at all, in fact kind of October, November, December, particularly October – November, was the busiest time we’ve ever had as a company. We were kind of really really rushed off our feet, but things have slowed down now. I guess the difficult question though is, "What have they slowed down?" I think in part it’s because of the recession, but partly it’s because people have been on holiday over Christmas and stuff so I think the real what we just need to see is what’s gonna happen over the next few months. Christmas is one big milestone because obviously a lot of companies their financial years end on the calendar year and they will start to get new budgets at the start of the new year. So what normally happens is January is usually quite quiet anyway and it starts to pick up toward the end of January when people have now got their budgets and they’re setting their schedules and their priorities for the coming year. Another kind of key point is March. You know March – April when a lot of other companies’ financial years kick in. So I think we need to kind of give it a couple of months, give it until March and then we’ll have a much better idea about the effect it’s had on clients’ budgets. But yeah, I would agree. I think people are just more cautious. I think all of this discussion about doom and gloom, frankly a lot of the reason why we are in the situation we are at the moment is because of media. The more people worry about this stuff, the more cautious people are going to be and it becomes a bit of a cyclic effect. But yeah, I’d say the same. I’d say clients are being a bit more cautious. We haven’t had too many issues with companies. We had one Icelandic bank that pulled out of a project in November which was quite amusing. They contacted us like a week before Iceland, kind of, you know, blew up. And we were like, "Yeah, we could have seen that coming," but apart from that it’s OK. Slackened off but it’s seeming to be OK at the moment.

Paul: So what about you? You’re talk about clients being cautious. What about you at Clearleft? Are you guys being a bit more cautious in what you’re doing? You know, your outgoings and that kind of thing?

Andy: I think we’ve always been reasonably cautious and I think that hopefully will set us in good stead for the next six to nine months. One of the things that we were really really conscious is running a good stable business and we’ve seen a lot of scare stories from the last .com boom with companies growing really really rapidly. They’d basically expand as much and as fast as they possibly could to fulfill the demand. That’s really great in the good times when people are throwing money and projects at you, but as soon as the projects dry up you’ve suddenly got a lot of mouths to feed, and I don’t think that’s necessarily true of Yahoo! but I think it’s probably true of some of the startups like Last.fm. You know, Last.fm have grown hugely over the course of the ten or twelve or eighteen months, and then all of a sudden when people start reigning in their budgets there’s not the work out there and they have to make people redundant. I think we’ve always tried to grow at a steady rate, you know we’ve been through boom times where we’ve been literally turning work down and we could have hired another couple of developers, couple of designers easily, but we chose not to because we didn’t want to get into that situation of the work drying up and not having any business. So yeah, we’ve been fairly careful how we’ve grown.

Paul: Do you think there’s, I mean, the kind of other side of the coin is to take the approach that perhaps Carsonified have done where they’ve actually been proactive in cutting their overheads by admittedly laying off staff in preparation for what is to come. I mean, you know I don’t kind of want to get personal about the guys at Carsonified but that’s certainly an approach that someone like Jason Calacanis would recommend. That actually before things get too bad you should shrink your business so that you’ve got you know, "a long runway," as he puts it, of money behind you over the long period. Is that and approach that you would consider? Well obviously you’re not going turn around and say, "We’re going to lay off all our staff now," but do you know what I mean?

Andy: Yeah, absolutely understand the question. The answer to that is, "Absolutely not," but it’s actually a two-part question. Um, you should, if you’re running your business well, you should ideally have a certain amount of money in the bank to cover operating costs. Now again, one of the things we were very clear of when we set up Clearleft is we would always have, would always aim to have six months of operating money in the bank. Now it’s not always like that. Sometimes it’s four months, sometimes it’s five or six. But that’s kind of what we try and aim to do. So before taking any money out of the company, before buying a nice car or giving ourselves a bonus we try and make sure that there’s enough money in the company that should we lose a couple of clients or should anything bad happen we can carry on paying people’s wages. I think in this industry, in the web design industry it’s all about people. We can’t build good products, you can’t build good services without having good people. So it’s the people that make the companies, it’s the people that make the industries, and I think as the boss, I think as an employee you have to put the good of your company and the good of your staff ahead of your own personal gain. So I think there are two ways of running a company. I think some people run a company almost like a general that commands their troops from the back of the battle front where they send all these people out ahead of them and they get picked off one by one until eventually you’re the only person left. I actually think as somebody running a company you have to take charge yourself and I would much prefer to lose, I would definitely cut my lifestyle and cut my wages before I would let anybody go in the company because you start slashing staff now and then when times are good you have a hiring problem or you get known as a company that will just sacrifice their staff. And I’m not speaking about any particular companies specifically but I think it’s important to realize that the wealth of your company is in the people that work for you. So yeah, I would always consider that as a last option, not a first option. Might not be good accounting sense. I’m sure if you’re just looking at sort of the figures, it might not be good from an accounting sense but people come and work with you and they stick with you through the good times and the bad and I think you’ve got to afford them every opportunity so that’s kind of my philosophy.

Paul: I think to some degree it could be good from an accounting sense as well. I mean it’s very easy to underestimate the cost of rehiring staff. By the time you take into account finding the people in the first place, that often involves going to the dreaded recruitment agency and the horrible costs and pain of that, you know if you don’t have a big network of people you can draw on. But also the cost in time of interviewing and all of that kind of stuff can really mount up so I guess to some degree it depends on how long this goes on, if it goes on at all. I mean we’re still waiting for something to happen. I can understand the whole philosophy about having a runway if you’re a startup company without regular revenue that’s dependant on venture capital or whatever but if your business is like an agency or if you’re a freelancer or something like that then hopefully you’re going to continue to have revenue coming in from work.

Andy: Well I think if you’re running your business responsibly you need to make sure that there’s always a runway. There’s some proverb or fable about making hay while the sun shines or whatever. You need to try to put a bit of a war chest, for want of a better word, in the bank or you’re getting good money because you know times, you know winter is coming and you need to kind of buckle down, but some people just go and as soon as they’ve got money they go and spend it on nice cars, nice apartment, holidays or whatever and as soon as things start to get tough then you’re in difficulty. But yet like I said I think you should always have a bit of money in the bank. You shouldn’t expand too quickly and I think if you end up hiring a large number of staff and then letting them go sort of shortly afterward it’s probably an indication of you probably shouldn’t have hired that many people so quickly in the first instance so it’s difficult. I don’t think there’s any right or wrong way of doing this. Everyone’s got their own approach.

Paul: I mean of course a lot of the people listening to this show aren’t going to be running their own businesses anyway so that kind of comes on to another question about if you’re working somewhere at the moment what should you do? Are you better off just tucking your head down and hoping that things go well in the company you’re working for or should you look at maybe now is the time to start your own business. I mean there was an interesting article by Drew, isn’t there, about you know the myth of stability and that actually you’re almost more stable being in control of your own destiny as a freelancer cause at least you know what’s happening with your business in preference to being employed. So, what advice would you give for people perhaps worried about their job at the moment?

Andy: That’s a difficult thing. There’s always been this myth that if you go and work for a big company there’s stability but I think recent events have shown that’s not true. If you’re running your own company you obviously have a much better understanding of what’s going on and you’re much more able to control the near future. Obviously you can’t plan too far ahead because most web design companies only book up projects three to six months in advance. So you can only really plan financially up to a certain stage but I think it’s good running your own company to a certain extent because you have a bit of a master in your own domain. You know what’s going on. On the other hand there is a certain level of security of working with a company, at least in the UK, a large company particularly because if you do get made redundant you get a redundancy package. If you’re a good productive member of the community or productive member of the company there’s a good chance they’ll try to rehire you in a different role. So I don’t think there’s any certainties there.

Paul: Do you think it would be a ridiculously stupid time to go freelance?

Andy: I think it’s a difficult time to go freelance. I think the problem at the moment is that there’s a lot of people freelancing in the industry and there’s a lot of people who are just not very good. I hate to say that but I think there’s a lot of people who are getting by at the moment on a subsistent wage who are a bit too much of a jack of all trades and a master of none and are kind of operating in a slightly more bottom end of the market. So I think that one of the first things that’s going to happen with the economic shift is the bottom end of the market is going to get even tighter and you’re going to be finding it really difficult if you do a little bit of PHP and a little bit of HTML, a little bit of design, a little bit of this, and a little bit of CMS stuff. It’s going to be a lot more competitive. However, if you’re really good at one thing, if you’re a really awesome designer, if you’re a really awesome coder, if you’re a really great Rails developer, if you’re a great User Experience person, if you’ve got a real skill that you’re well known for there is always going to be a market for good people. There’ll be more people on the market. There’s people being made redundant from Yahoo! and other companies who are really really good at what they do so it’s gonna get more competitive so I wouldn’t necessarily say that it’s a good opportunity for people to necessarily go freelance unless they’re really really talented and have a good existing stream of revenue and they know a lot of people but I think there’s opportunities in other areas in terms of setting up your own projects and doing startup and doing work outside the office. I think there’s interesting opportunities there.

Paul: So if there are people listening to this show that are going, "Crap! He’s just described me. I’m a freelancer that works on that kind of bottom end of the market." What should these guys be doing? How can they go about improving their position?

Andy: I think again while the industry was going at a rate of not to new, last year there was so much demand for people, companies, clients would hire anybody no matter what your skills were. I think now we’re in a situation where to really stand out you’ve got to be good at what you do. You’ve got to be highly skilled, and I think people need to see training as an investment. I think we’re really bad as an industry of investing in ourselves of investing in our own personal development. We’re all very happy to go spend £500 on an iPhone or £1000 on a new Mac but spending 500 quid on a training course, people go, "Well that’s just a waste of money," but I don’t think it is. I think you need to invest in your personal development and your professional development so I would say figure out what it is you’re really good at, figure out what it is you enjoy and then see if there are training courses go on or conferences you can attend that can help teach you those skills.

Paul: You missed a perfect opportunity there to pimp UX London, didn’t you there?

Andy: I guess so, yeah.

Paul: You’re just too nice. Tell us a bit about UX London, Andy.

Andy: A lot of what we do again, you know me and you know what the company’s like. A lot of what we do isn’t necessarily about our gain as individuals just purely from a financial point of view. We run conferences like dConstruct because we want everybody in industry to benefit. We want people to get better at what they do, to produce better websites and I think by doing that everyone benefits. And again UX London the whole purpose of UX London, it’s a conference we’re organizing in London in June it’s a very targeted conference. It’s much smaller numbers than dConstruct. It’s 160 people and it’s a real education-based event, to teach people how to be really good User Experience designers, User Experience developers, information architects and usability people. So we’ve got some of the best speakers in the industry coming over. We’ve got Don Norman who’s like the Godfather of User Experience, we’ve got Dan Saffer, we’ve got Peter Merholz, Jared Spool, Jeff Veen, we’ve really had an opportunity here to play fantasy league conference and put together the kind of event that we wish that we could have gone to five years ago. Particularly User Experience is a growing field and I think within the recession or within the looming economic crisis, companies are going to be spending less and less or are going to be able to spend less and less on acquiring new customers and where they’re going to need to spend their money is satisfying existing customers and making sure that the customers that they’ve got don’t go to other brands, other companies and are much better at converting and User Experience is one of the ways we can do this. So I definitely think if you’re interested in getting into the User Experience realm going to something like UX London would be a great opportunity. It’s essentially three days of workshops and practical hands-on stuff. I mean it’s not just a standard talking head kind of conference it really is getting in there and learning new skills. Not just UX London, there’s all kinds of conferences and events out there, there’s all kinds of training courses. There’s development training courses, there’s usability training courses, there’s designing courses, but pick something you’re really passionate about and get really really good at it and if you get really good at it people will find you. There is still a massive demand for Rails developers, there is still a massive demand for good visual designers and there’s still a massive demand for really good UX people and I think those three practices are going to get more and more important so yeah that’s what I’d say.

Paul: You said something there about if you get really good at something people will find you. Do you think that that’s actually going to remain true or are we going to have become more active at going out there and finding work? I mean to some extent people like you and me are we not a little bit spoiled because we’ve already built up this reputation, people are aware of us, because in my case because of the podcast, because of your book and the various things that you do. Is that all that you do to win business? Write a book or put on a podcast? There’s got to be more to it than that.

Andy: It doesn’t hurt, I can kind of say that but that’s the situation we’re in now obviously but the reason that we were able to do this, the reason that I was able to write a book and you were able to do the podcast was because five, six, seven years ago we just sat around writing blog posts about what we were passionate about, what we were interested in and the Internet has an amazing capacity for putting like-minded people in touch, whether it’s through your blog, whether it’s through your twitter stream, whether it’s through meeting people at conferences. I mean again, going to a conference is a great opportunity to network and meet people and I think there’s a community in the Web and you need to be a part of it. If you’re not part of it, if you’re just sitting on the fringes then you’re going find it a lot more difficult to pick up work, but if you throw yourself into this community and actively participate it’s not that difficult, if you’ve got a skill, if you’ve got a talent it’s not that difficult to make people aware of it. You do have to do a bit of promotion though, you do have to write some articles or contact a magazine and say, "Hey do you mind if I write something for your magazine?" Or go around to some of your favorite bloggers and leave messages on their blogs and write to them and say, "Hey look, I’m doing this, that and the other." I’m probably going to get inundated with responses now but we’re always on the lookout for really good people. Despite the number of people working in the industry we find it really difficult finding good visual designers we find it really difficult finding good Information Architects and we find it really difficult getting good front end coders. We see a lot of average people. There’s a scary number of really bad people out there, but finding good people is difficult and we’re not just falling over people in the street. I’m spending a lot of my time actively asking around and asking friends and contacts and doing searches on Google for people so if you make yourself available and you go out of your way to put yourself in that situation it can only be of benefit. I was talking to you before we started the podcast about something we’re doing at Clearleft is that we run an internship program and part of the purpose of this internship program is to get people that haven’t had that commercial experience, that maybe have just left University after doing a graduate degree or maybe are in the middle of a Master’s Degree or maybe are just transitioning to a different career area and maybe they were starting off doing more design and they want to get more codey or they were a coder and they want to do more information architecture and actually having the opportunity to go and work for a company for ten weeks is an amazing training opportunity, sorry if I sound like I’m promoting myself a bit too much but we had a really great guy come in over the Summer a guy called Amild who was from Sweden and he was part way through a University course and in the Summer he came over and he worked for us for ten weeks and he got to work on real-life projects he got to sit down and program with Natalie and argue semantics with Jeremy and be involved in every single part of the process and doing that, you get so much knowledge and training out of going and working hands on like ourselves or yourselves, much more so than you’d probably get doing little side projects over the course of a couple of years I mean I know we’ve had a couple of interns now and the amount of stuff that they know when they leave working with us is two or three times the amount they knew when they came in and actually ironically people come to Clearleft quite often a little bit cocky because they’ve heard about us and they know we’re good at CSS and Web Standards and they come in thinking, "Yeah, I do this," but when they sit down with someone like Natalie and she explains all this stuff their eyes and their universe ends up opening and it’s like, "Oh my God I didn’t know this stuff existed. I didn’t know people would go to so much effort to craft a nice, well designed, well put together website." So yeah we’re running an internship for Spring so if anyone listening out there wants to come work down in Brighton in the Clearleft offices for ten weeks and is really interested in good front end code and HTML and CSS then please go to clearleft.com/jobs and there’s some details of the internship there. We’ll be running it again during the Summer maybe May, June July time. At the moment we’re looking for a front end developer to be an intern. The last intern, the last before one intern we had was more of a User Experience person, we might be looking for design intern next we might be looking for a bit more of a generalist so I can’t really tell you what we’ll be looking for in the Summer, but at the moment yeah we’re looking for a front end developer to come and help us out.

Paul: I think as well, if I was in that position to have the guts to just approach random companies and I get people contact me regularly asking whether we do internships which we occasionally do and a lot of time I’m having to say no to people, I don’t mind them writing. Having the guts to approach a company to say, "I really like what you do, I’d love to work with you." I think that’s great. You’ve just got to go for it and put yourself out there whenever possible.

Andy: Absolutely. If you’re trying to get work, send your CVs around, drop people emails saying "Hey, I’m a freelancer. I’m doing this. I’m doing that, " and stay in touch. It’s really difficult for you as a business owner to keep in your head of who’s available, you don’t have a clue who’s available when and the people we end up working with, the freelancers we end up working with, you work with them once and you probably never let them go again because they’re usually really good. They’re usually awesome and once they start working with us, we stick by people. So it’s worth once you send your CV to someone, drop them a line every couple of months, every time you’ve updated a website or you’ve done something you think is particularly interesting and just keep on the radar and the more you keep doing that, the more you promote yourself the better it will be.

Paul: Of course that works very well if you’re a freelancer, this whole thing of getting involved in the community and building relationships and all of that. It’s great if you’re a freelancer where you’re working for someone like Clearleft or Headscape in that kind of relationship but what about people that are working directly for clients who aren’t part of the Web Design Community? They stand outside of that, have you got any advice for engaging with them, how to find out about what jobs are out there, how to get on those tendering lists and that kind of stuff?

Andy: Well you don’t need to be getting on tendering list I’d say because most organizations that have tendering lists have got a lot of hoops that you need to jump though, it’s very time consuming, there’s usually financial constraints about how big you are as a company, how many staff you’ve got, all that kind of malarkey which I’m sure you’re very familiar with. I think it’s really difficult as a freelancer. I think there’s a glass ceiling in the kind of scale and size of work you do. I think it’s tough. I think you end up doing smaller projects but lots of them, usually for not a huge amount of value and so it’s really difficult when somebody big comes along and says, "Show me the last big project you did," and it’s, "We haven’t really done any because I’m a freelancer and I’m working directly with clients," so the way you can get experience and exposure of working with larger clients is to go and be a freelancer with agencies and actually if you’re a freelancer it makes much more sense to try and approach two or three decent agencies that continuously pass you work than it is to constantly try and get small £1000, £2000 projects. Then also if you’re doing that you’ve got a lot of marketing to do, all of the accounting, the bill chasing, it’s a lot harder and like you say I think it’s gonna get a lot tougher at that end of the market so yeah I think being a freelancer you’re probably best off targeting agencies if you want a more stable income.

Paul: Here’s a tough question and I certainly don’t know the answer to this so I forgive you if you don’t either I mean we’re seeing people being made redundant at the moment, we’re also seeing people that have gone through years of University training going, "I’m gonna become a Web Designer," and they’re stepping out into probably the worst economic situation since the .com bust for web design. What are these guys supposed to do? How are they going to go about finding a job? Does this just come back to the networking issue again?

Andy: I think we’re in a really interesting position. We’re in a really tricky position for a lot of recent graduates. When me and you started doing websites, or when I started doing websites the designs I was producing were rubbish. It really was terrible. The markup was terrible, the design was terrible, but luckily every other website out there was also equally bad so we weren’t worse or better than anyone else we were just meh. As we’ve matured and as the web’s matured we’ve got better at what we do, we got better at the stuff we produce. I went to a local agency in Brighton that kind of supports the local digital markets had a portfolio clinic last year where they had people fresh out of University and the quality of the designs they were producing was about the same level of the quality of design I was producing when I came into the market, but the problem is the bar has now been set so much higher so it’s really really tough. If you go into a three year degree where you spend one semester learning Dreamweaver, one semester learning Flash, coming out built a really lovely Flash animation of a monkey riding a bike and thinking, "OK, I’m gonna get loads of work with my great Flash animation skills," you’re gonna be coming into quite a harsh marketplace. What you need to do is you need to train yourself. You need to up skill. You need to do as much work as possible. You need to get your skills up. You need to get your design up. You need to specialize and to be really good at one thing. Be really good at design. Be really good at HTML and then you’ve got a chance of getting a foot in the door. Internships are good, training are good, but you need to have innate skill and actually in a kind of a weird perverse way I think the shake out is possibly good for the industry because like the last industry shake out is a lot of people who probably shouldn’t have been working in this industry, who didn’t have the passion ended up losing their jobs and going on and working in another industry, but people that stuck with it are the people who are good at it and passionate about it, stayed with it and survived through it and so I don’t think it’s necessarily a bad thing. I think there’s a problem with education that is trying to convince kids that they can go through a three year Bachelor’s Degree and come out and get a job. I think the industries that are going to be hardest hit in this recession are obviously financial industries are kind of stuck, or kind of enterprise level applications that any people working at enterprise apps are going to find it tough. I think people that are working in particular vertical markets, if you’re just a company that just solely focuses on doing startup business, the startup funding is drying up. It’s not gone completely and there’s a big argument to say that actually in times of economic recession that’s the time you want to invest in innovation, you want to invest in startups because once you come out of that recession you’ve got a product that’s ready to go that has been developed for a lot less money because resources are much more prevalent. You can hire developers much cheaper now and if you can start building your ideas up now very very cheaply, come two years time you’ll be two years ahead of the competition and if you’ve got a really really good idea you’ll come out of the market ahead. But I think at the moment if you’re only focusing on developing sites as startups you’re going to have a problem, you need to have a diversified portfolio of clients. I think the other thing is if you’re focusing on getting the majority of your income from just one or two big companies and that is quite common particularly in the entertainment industry. I mean are these Flash games developers or Flash entertainment sites developers that will just work with one or two large media brands. If suddenly they start pulling back on their funding you lose one client that is worth thirty percent or forty percent of your revenue you’re gonna be stuck so I think as a freelancer coming out of the industry it would make sense to focus on where there is growth in the market where the market’s stable. I don’t think it’s in producing Flash games necessarily and I don’t think it is producing multi million dollar blue chip corporate websites I think it is in creating websites that show real return on investment and that is in usability and accessibility, that’s web standards that’s understanding the psychology of human behavior. It’s all those kind of things we’ve been talking about for the last couple of years are becoming even more important.

Paul: You said an interesting thing point though. You talked about innovation and I think that’s quite a good place to end though all of this situation is going to effect innovation and kind of the evolution of the Web, do you think these kinds of slow downs will affect the growth of the Web?

Andy: It’s obviously going to affect the growth of the web because by the very name of recession it means growth of the economy isn’t growing it’s receding so I don’t think it’s going to be a time of growing much I think companies, large companies particularly are going to be taking stock and focusing on what they do well, their core assets. However I think what happens is it provides space for smaller companies to grow so you’ve now got these big companies competing for the same market as you so you can come up with new innovative ideas. You can come into the market much quicker. You can do it much cheaper. You are much more able to spot gaps in the market or gaps in the experience curve you know you’ve got a lot of companies doing this. You’ve got people like TripIt who have seen that there’s a gap between buying tickets and managing your calendar so identifying a gap in the market, "Because the airlines aren’t helping manage your trip, we’ll help you manage it for you," I mean dot was doing exactly the same thing so I think if you’re smart, if you’re clever and good at what you can do and you can see opportunities, there will always be opportunities, big companies going out of business, people cutting back on their R&D, people cutting back on their spending gives you an opportunity because it means less competition in the marketplace, there’s more available talent, there’s more available attention which is a big thing. You can grab people’s attention doing something different. There’s opportunities for making people money, in times of recession people are going to want to save money so if you can come up with an app that helps people save money, helps them, obvious examples are big slew of apps at the moment revolving around either managing your finances or getting better deals on car insurance all this kind of stuff, anything that can actually make people better off or more efficient. Productivity apps I think are gonna thrive.

Paul: Thank you Andy! That was both good and depressing at the same time!

Andy: Oh thank you. I’m glad talking to me you find depressing. Cheers!

Paul: Actually it isn’t depressing. I’m very upbeat about the coming year. I feel that, "OK, we are in an economic slowdown but it does provide lots of opportunities." Even being made redundant has its upside. As somebody that was made redundant and then went in to set up Headscape I really know and understand that these things can be turned to good so I think yeah, I’m positive about the coming year although hopefully I won’t be made redundant from my own company because that would be embarrassing. So there we go. Thank you very much Andy! We’ll get you back on the show soon and Happy New Year!

Andy: Happy New Year to you too and to all the Boagworld listeners out there!

Thanks goes to Todd Dietrich for transcribing this interview.

133. Agile

Posted in Classic shows on September 3, 2008 by Paul Boag

In this weeks show we talk to Jackson Wilkinson about Agile and answer your questions on web design courses and showing off development work.

Podcast: Download (26.8MB)

Download this show.

Launch our podcast player

News and events

The Target accessibility settlement

Previous we reported that the retail chain Target was being taken to court over the inaccessibility of its site. Many hoped this would be a landmark case that would clarify whether the Americans with Disabilities Act applied to the web. As with the Disability Discrimination Act in the UK the wording is open to interpretation.

Well after 2 years of legal battle Target has agreed to pay $6 million in compensation and correct the accessibility problems on the site by February 2009.

Some are complaining that the case has failed to achieve all it could. They argue that although $6 million sounds like a lot of money it is small change for Target. What is more, they argue, Target has admitted no ‘wrongdoing’ and the case has done nothing to clarify the law.

These are legitimate points but I prefer to take a more positive view. This has been a significant embarrassment for Target and although $6 million is a small figure it is substantially more than they would have paid to address the problem from the start.

Finally, as Matt May points out on the WaSP website, this case may not clarify the law, but that does not matter. As web designers, our role should be to educate clients about the importance of accessibility rather than campaign for tighter legislation. In my opinion the benefits of accessibility are considerable and if presented correctly do not need laws to enforce them.

Long live IE8. Goodbye IE6?

This week saw the release of IE8 Beta 2 and I have to say that things are looking good. Quirksmode says it is shaping up nicely and Sitepoint has even asked whether web designers will switch from Firefox back to IE (the overwhelming answer was no!).

If you build websites and have yet to take a good look at IE8 then now is the time. I suggest you start with Microsoft’s own ‘readiness’ documentation for developers. This talks about all of the new functionality. You may also want to look at their separate documentation which lists the new CSS properties supported.

As IE8 teeters on the brink of release there is a growing movement to stop support IE6. With 37Signals, MobileMe and now even Facebook effectively dropping support for IE6 it would seem the tide is turning. There is even now a site dedicated to the demise of IE6. On it the author writes…

Internet Explorer 6 will be SEVEN years old on August 27th. It came out a few weeks before the Twin Towers fell. It came out before the Nintendo GameCube. It came out before the first iPod.

Makes you think doesn’t it.

OS form elements

Paul Stanton sent me a link this week to a great tool for you designers out there.

When I am working on a design for a site in Photoshop, one pain in the ass is creating form elements. You have to open a browser, find the form element you want, screen grab it and then edit it to remove all of the background elements. Its not a big job but it is annoying.

If I had any sense I would keep a library of all these form elements. However, somehow I have never gotten around to it. Fortunately I don’t have to now as there is a great site which provides them all for me.

The site is called the Designers Toolbox and includes web form elements for IE, Firefox and Safari under both Windows and Mac. They can be downloaded in PSD format and even include browser windows at various resolutions.

Blogging software reviewed

Finally, it wouldn’t be boagworld if we didn’t plug at least one Smashing Magazine story each week. Damn them and their compelling content!

This week they have published a review of 10 blogging applications including…

WordPress
Movable Type
ExpressionEngine
Drupel
TextPattern
Joomla
b2evolution
Nucleus CMS
Serendipity
Mephisto

The subject of blogging software, or content management systems in general, is a controversial one. This post alone has generated 137 comments, mainly consisting of people promoting their own personal preference. People are passionate about the system they use and often it can be hard to get a balanced evaluation. This makes selecting a system that is right for you difficult.

This post does a fair job at providing some subjectivity to the discussion. It addresses the pros and cons of each system and indicates the kind of site the system would be best suited for.

It is not a comprehensive guide, but is useful if you want to see what is out there.

Interview: Jackson Wilkinson on Agile

Paul Boag: So I’m pleased to have joining me today Jackson Wilkinson. Good to have you on the show.

Jackson Wilkinson: How’s it going Paul.

Paul Boag: Very well indeed. Just for those people that don’t know of you can you kind of give people a little bit of background so that they kind of know the angle you’re coming at things.

Jackson Wilkinson: Sure. I’m a user experience strategist at Viget Labs which is outside of Washington DC in the US. We’re essentially a full service web consulting shop. As a company we do design and development mainly in Ruby on Rails. We also do sort of the pre-product, pre-development strategy, that’s a lot of what I am involved in. We also do marketing. So specifically I attack working on the web from that angle of improving and setting the user experience at a product level before hand and then usering it in to usually the design phase after that. I tend to dabble in a lot of things. I was formerly a developer and have also been a designer here and there and try to keep my hands dirty in a lot of different areas.

Paul Boag: Cool. So I mean the reason we’ve got you in to talk today is to talk a little bit about the idea of agile developement. Particularly how it kind of applies not to the developer side of things that a lot of other people have talked about but you know to the design side of things, to the design community. But before we get into that let’s take a step back and start off by explaining to those that don’t know what agile development is. Could you kind of give us a potted summary of agile development.

Jackson Wilkinson: Sure. I think the short form answer to that is that, agile is basically a process for software development, typically software development, that is the opposite of your typical waterfall process where you have this big planning stage up front. You decide what every screen’s gonna look like. You decide how every feature is going to act and so on an so forth. Instead the agile proccess focusses on short rapid bursts of development which are usually called iterations, and essentially you’ll work on your product for somewhere between two and four weeks at a time implementing little bits of functionality so that you have a completed product every two weeks or so. The idea is that you’re able to adapt to change. You know if you decide that requirements need to change two months into the project that’s not a big deal because it only affects this two to four week period of development. You don’t have to go back and redo everything that you’ve already done. I think that’s pretty much the short form version there.

Paul Boag: Okay. That’s good. So in what kind of projects is this normally used on? You mentioned software development but what other kind of things?

Jackson Wilkinson: Well the proving ground so far, agile’s pretty new in so far as development processes can be new. It’s proving ground has largely been on the web. So web apps and web products have really been the biggest place where agile has been used but that’s not to say that that’s the only place where it has been or where it could be. Many larger products, many end user pieces of software. Largley ones that affect developers or that affect designers have been used and have been developed in an agile way. Definitly if you’re thinking sort of the 80/20 rule the vast majority of agile development has sort of been on the web for web apps. That tends to push those boundaries anyway, that web industry.

Paul Boag: So this has been, this can be used on larger projects? It’s not limited to smaller more self contained things then?

Jackson Wilkinson: Sure it certainly can be used on larger projects. It really depends on the structure and the climate at the development shop where this is happening. If you’re a really large shop that has lots of beauracracy and lots of stake holders and your client needs to get approval from 5 different places then this notion of quickly changing rapid development, quickly developing specs and the rapid pace of development is probably not as conducive. But when you’re in an evironment that has senior level developers who have a lot of autonomy and everybody tends to trust each other to roll with the punches, or you just have a lot of trust in your entire team then an agile process can work on any kind of software. Whether it’s a two month project or a two year project.

Paul Boag: Interesting. I mean from what I’ve heard of agile development before it’s a technique that’s growing in popularity amongst developers. You seem to think that some of the elements of agile development can be applied to designer’s as well. Tell us a little bit about that.

Jackson Wilkinson: The main reason why I’ve been thinking about this lately and why a lot of others have been thinking about this lately is that certainly as developers work on web apps they interface with designers a lot. If you’ve got this notion of a two week iteration then, maybe an example of an iteration might be that you’re working on a sign up process or you’re working on a registration process for one iteration. Then you go on to, you know if you’re making a social network for quilters, then you’ll add in social networking features after that or something along those lines. If you’re only constraining your work to those two week batches then often times the designers will be basically in this position that they will be forced to hustle to meet the development schedule. That’s not necessarily conducive to the design process as we normally think about the design process. That’s kind of how I came to thinking on this topic and how a few others have as well. The challenge really is to take some of those elemental notions of the agile process and to try to shape the design process around them so you can best use them to your advantage. A lot of times that means if you’re a user experience type of person or an information architect you’re planning process probably won’t be 4 to 6 weeks long or even longer with lots of user interviews. Instead you’re focussing on the law of diminishing returns where you’re talking to a couple users and getting there feedback and doing a little work on some interfaces and testing them out and moving on from there or as a designer you’re working on 5 or 6 screens at a time. Sort of in the silo of what’s going to be happening on the next iteration and then those get implemented. As you see what’s worked you constantly are improving your interface and improving your design as you see these things implemented. You’re in fact taking feedback from what’s already happened and using that feedback either from internal users or external user tests or even just what the developer’s and your friends and other designers are saying about it as it gets implemented. You’re pushing that back into your own process to in fact build a better product for the next iteration and do a better job there.

Paul Boag: How does that work from a kind of, you know the broad overview point of view? You know, as somebody that’s designed interfaces for fairly large and complex sites that would go beyond the two or three week or whatever cycle. You do so many different things with the different templates that you produce. What you do on one set of screens may affect what you do on another set of screens further down the line. If you’re working on all the individual iterations or silo’s of work is there not a danger that problems get ignored because they’re outside of the current cycle of development? Is that making sense?

Jackson Wilkinson: Well that certainly makes sense. That’s a challenge that a lot of folks new to the actual process experience where your essentially thinking we’re done with this piece of the product we’re totally going to ignore it from now on. That’s really one misconception and mistake a lot of folks make. Instead you should be thinking that part of each iteration is going to be addressing observations and addressing things you’ve discovered about the work you’ve already done. You’re third iteration is probably largely based on developing new features or developing new parts of your application. At the same time you’re going back and making tweaks and making changes to the work that you did in your first and second iteration based on testing or things that you’ve discovered about it or changes you have to make based on things that you know now that you didn’t know then. That way it definitly keeps everything moving. It keeps the whole product getting better at the same time.

Paul Boag: But isn’t that end up requiring a lot of re-work? You know you kind of are constantly doing things over and over again?

Jackson Wilkinson: Ideally it doesn’t require that much re-work no more than you would spend that time in a waterfall process determining what exactly you want in the first place. Certainly the agile process kind of comes with this belief that mistakes aren’t necissarily a bad thing and that you kind of embrace the notion that you may be wrong but you embrace that notion thinking that you’re going to be quickly making decisions and quickly making your best judgements about something based on what you already know. The time that you’ve saved by quickly making those judgements will completely of set and hopeful you’ll still be in the black when you have make a couple of changes down the line.

Paul Boag: So it’s basically doing away with the laborous documentation and the specing up of a project at the beginning and okay you loose some of that when you have to then re-work stuff but overall you end up, as you say, in the black.

Jackson Wilkinson: That’s the idea. That’s the hope. It seems to work out pretty well for us. It doesn’t always work with every type of client or every type of project. If it’s a client who isn’t a really adaptable to change on a regular basis or something like that. The notion that you’re not going to have this big spec doc up front may be a little unsettling for them but hopefully on an agile team you have a client, whether it’s internal or external client, that is buying into your expertise and really trusts your process and knows that your going to end up with really what works best in the end.

Paul Boag: There are differences between how this process applies to a designer rather than a developer. Are there changes and tweaks that need to be made?

Jackson Wilkinson: Yeah. In the end changes and tweaks tend to happen pretty equally to both the development of the site and the design of the site. Essentially if you’re a designer who is taking responsibility for the entirety of the interface and you’re designing that inteface completely, then you’re going to basically be making changes that could affect the developers as well. That’s something that designers need to keep in mind. They need to work very closely with developers to understand what the changes that they’re suggesting imply and really you make changes based on the time available in this iteration and what really is going to be most effective to change in the time you have available to you.

Paul Boag: So you have to be quite strict about these time scales from the sound of it? You were saying there that you only make the changes that you can within the current iteration before you deadline runs out. Am I understanding that correctly?

Jackson Wilkinson: Yeah, one of the biggest challenges there is knowing what size changes you want to bite off of this project. So you’ll have this mountain of changes that you eventually want to make and a lot of the project management involved is figuring out what you’re going to place in the next iteration. Doing as much work as you can on those bits and then reassessing at the end and hopefully having a new product or a new potential release, even if it’s not quite ready for release, a potential release finished at the end of that end of that two week block to evaluate everything you know at that point.

Paul Boag: I mean I can imagine there’s a lot of people listening to this that may be a little bit nervous about the idea. They’ve come from a very kind of waterfall driven mentality, where you know you pass things from one person to another. On the other hand they concede the potential in it and are maybe interested in finding out a little bit more. Where do suggest people start if they want to experiment with agile development? How do you do begin?

Jackson Wilkinson: Well I think that capital A agile proponents would probably say that you really need to dive in. I’m not sure that I buy that. I’m more perhaps a post-agilist, in thinking that you really need to just do what works. What works for you might be different than what works for somebody else. If you’re really ingrained in a process that has a lot of aspects of waterfall, has a lot of upfront planning, then you know you still can do a lot of the agile things to dip your toe in. The first thing that I might suggest doing is that even if you have a long planning process upfront where you determine the full scope of work. You determine even many of the streams and many of the design elements that are going to be implemented. Still break those goals up into two to four week iterations. At that point you still have the comfort of the planning that you’ve done ahead. If you concentrate on creating a self-supporting product within two or three weeks then you’re half way along that train. You can see how that goes. You’ll probably find that after you’ve gone through a couple iterations you’re thinking about things you’d want to change back in the planning section. That then maybe that’s okay at that point. You’re realizing how this self driven process works. As you become more and more comfortable then take away some parts of the planning. Maybe put the visual design to be a piece of the iterative structure while you’re still maintaining the feature scoping and the wire framing up at the front end of the project. Dip your toe in it first and then your whole foot and then maybe eventually you’ll be in up to your waist.

Paul Boag: So mean there must be resources out there? Lets send people away from this interview with something constructive to do. Where should they be going to learn more about this? What’s the next step they can take?

Jackson Wilkinson: Sure. If you’re a designer there isn’t necissarily a lot that addresses agile in the design case right now. Most of the agile books and the agile resources that you’ll find tend to deal mostly with a strict development structure. Certainly if you’re simply interested in looking at things and what the agile process is in general then you can look for books that deal with extreme programming or agile. You’ll find countless numbers of them. I’ll certainly give a list to you Paul so you can put them on the website afterward. Beyond that there are a few websites that deal with the agile design process. Emily Chang wrote a post call the agile web design manifesto. It’s a couple years old now but most of the concepts still remain. Where you’re kind of marrying this notion of design with agile development. She offers some good suggestions and especially the comments that follow her post are super useful to look through. If you’re involvedin IXDA which is an interaction design group. There are numerous discussion’s on there mailing list about how agile processes fit in to. The whole notion of the message boards is probably a good source in this case. I’ll certainly be happy to forward along a list for everybody to check out.

Paul Boag: Excellent. Thank you very much for your time. That’s really interesting. We’ve kind of touched on agile development very lightly on a number of occasions but we haven’t really looked at it in any kind of depth I guess, or kind of broken down what it is and how it works. It’s great to have you on show. Thank you so much for your time and I look forward to looking through that list.

Jackson Wilkinson: Yeah. Absolutely thanks for having me. I really enjoyed it.

Thanks goes to Curtis McHale for transcribing this interview.

Listeners feedback:

Courses on web design

Jonathan asks: I am looking to get into web design and was wondering if there are any colleges or courses you could suggest. However, I do not have any A Levels.

I get questions like this fairly often, but tend to avoid them for two reasons. First, I went to college 15 years ago and so am out of touch with what is available (web design courses didn’t even exist!). Second, this is a country specific question, as nations have different educational systems.

However, because it is a popular question I will address it. There is certainly some generic advice I can give:

Look for practical courses – I did two courses between school and work. The first was a BTEC and the second a degree. Although the degree was supposed to be a more advanced course, the btec was far more useful. That was because it taught me hands on skills that I still use. My degree on the other hand was very academic and abstract. Where possible choose a vocational course.
Focus on web design – I receive a lot of CVs from people with computer science or art degrees. This tells me two things. First, when they selected their course they didn’t know specifically what career they wanted. Second, that if I hire them I have to train them. I would prefer somebody who specifically wants to be a web designer and already has a good grounding in the basics.
Consider an apprentice scheme – If you have not performed well in the education system, consider an apprentice scheme instead. You will learn considerably more working for a web design company than doing an academic course. You will also get paid at the same time! Even if you cannot find an apprentice course in your country there is nothing to stop you arranging this yourself. Find a friendly web design agency willing to take on a trainee and also attend a part time or evening course.
Learn business skills – Web design is not just about design and development. You need to understand business principles as well. You will be required to manage your time and potentially other people. Also, if you decide to become a freelancer you will need to understand sales, marketing, tax, invoicing and many other aspects of business management.

Showing off development work

Teifion asks: As a designer you can show off your work in a portfolio. As a programmer I cannot. What is the best way for developers to show off their work?

There is no doubt that it is harder for a developer to demonstrate his skills than a designer. However, it is not impossible. Let me suggest 4 approaches you could use:

Sandbox – Have an area of your site where you build prototypes of functionality. It is a chance for you to experiment and show off your skills. Even large organisations take this approach. For example Google Labs showcases development projects which are far from finished.
Blog – A blog gives you a chance to expose some of the code that lies behind your work. It also demonstrate your knowledge and techniques. Many developers shy away from documenting their work in this way. However, it is an effective promotional tool when seeking employment.
Case studies – If a blog feels too much like an ongoing commitment consider writing occasional case studies. This works especially well if you have commercial work to showcase. A case study should not only demonstrate your coding skills, but also your ability to interpret a brief and formulate a solution.
Screencasts – If writing fills you with dread, why not produce a series of screencasts. Screencasts allow you to show your code in action. You can demonstrate work and also show the process used to develop that approach.

You should not limit yourself to just one of the options above. Ideally look to combine approaches to effectively communicate your coding ability.

130. Air

Posted in Classic shows on August 13, 2008 by Paul Boag

On this week’s show; Paul talks about better understanding disabled users. We have a tip from Jeremy about problem solving and Jonathan Snook introduces us to Adobe Air.

Download this show.

Launch our podcast player

Housekeeping

A few pieces of housekeeping I wanted to quickly mention at the start of this week’s show.

FOWA – The guys over at Carsonified have been kind enough to offer boagworld listeners a 15% discount off of the upcoming Future of Web Apps conference in London. The conference takes place between the 8-10 October and is an absolutely superb event. To claim your discount use the code FOWA-bw at checkout. There are only 50 discounted places, so be quick.
SXSW – Talking of conferences can I ask a favour of you all. Marcus is desperate to go to next years SXSW conference in Texas. However he is only allowed to go if he is speaking. As you may know speakers for SXSW are chosen using a voting system. So, in order for Marcus to attend SXSW he needs your votes. Give an old popstar a second chance. Go vote for him now!
Think Vitamin - Finally I just thought I would quickly mention an article I have recently written for the Think Vitamin website. It is entitled "the 5 hidden costs of running a CMS" and I thought you might be interested in check it out. It is an extract from chapter 8 of my book the Website Owners Manual, which as I have said many times before, you can download right now ;)

News and events

Designing for emotion and flow

Not long ago I wrote an article for boagworld on the importance of context. In that article I highlighted elements such as time, mood and environment as key factors that contribute to a users context when accessing your site. This context directly impacts how the user interacts with your site. What I didn’t tackle in my article is exactly how context should affect the way you design.

An article called "Design for Emotion and Flow" on the boxes and arrows website, takes my post a step further by going into a lot more detail about what affects users behaviour and how we should design in a way that accommodates their state of mind.

Its quite an in-depth article but worth the read. It touches on user physiology as well as issues of environment and although it can be slightly theoretical at times, it focuses in on what you can practically do towards the end.

Articles like this always leave me with mixed feelings. They can easily feel overly analytical to the point where you wonder if they are applicable in the real world. However, in my experience if you take the time to read and digest them, they start to influence the way you design on an almost subconscious level.

7 essential guidelines to functional design

By contrast our next article is much more down to earth. The "7 Essential guidelines to functional design" is another post by smashing magazine and focuses on some fundamentals of good design.

However, don’t get the impression that this is just an article for designers. The principles it talks about also apply to developers and website owners. Basics such as the goal and audience for your site are things everybody should be considering.

According to Smashing Magazine the 7 essential guidelines to functional design are:

Consider our product’s goal
Consider who will be using it
Consider what your audience intends to do with it
Is it clear how to use it?
How does your user know it’s working?
Is it engaging to your users?
How does it handle mistakes?

Whether this is the definitive list, I am not so sure. However, it is a worthwhile read especially if you are just starting out.

15 companies that really get corporate blogging

While we are on the subject of lists our next post is "15 companies that really get corporate blogging". What can I say, I am a sucker for a list!

This one is really for those of you who run a website and in particular run a corporate blog. As the name suggests it lists companies that do a good job at blogging. However, it is not the list that attracted me to this article, it is the reason why the companies got on the list.

There is a lot of good advice to be gleaned from this post. Just a few snippets I picked up include:

Don’t just pimp your products, talk about other stuff too
Post regularly
Encourage conversation
Be candid and open
Offer advice and lessons you have learnt

The list could go on. Corporate blogging is by and large a disaster with many companies just failing to ‘get it’. According to a recent report, 56% of corporate blogs just republish press releases and two thirds hardly ever receive comments. However, as is highlighted in this post there are a growing number of organisations that are doing things right and we should follow their example.

Learning from signage

If you have listened to this show for any length of time you will know I am a great fan of looking beyond the web for inspiration. I also believe there a lot to be learnt from other forms of design including signage.

It would appear that Mark Boulton would agree with this sentiment judging by his recent post on airport signage. Mark, compares the signage in two airports and looks at how the lessons learnt apply to web design.

Some of the gems he discovered include:

Signage should work without colour coding
Only designers care about fonts
Don’t rely too heavily on pictograms
Always put your ideas to the test

This is a great article which should (if nothing else) encourage you to look at the world around you for inspiration.

Interview: Johnathan Snook on Adobe Air

Paul: Joining me today is Johnathan Snook who I recently saw at the @Media conference. It was great to see you there again Johnathon.

Johnathan: A pleasure to see you there as well.

Paul: You really got me with your presentation. It was an excellent presentation. Very, very enjoyable, and you touched on the subject of Adobe Air. It wasn’t the main thrust of the presentation, but it was the bit that really grabbed my attention so I thought "let’s get you on the show and have a bit of a chat about it" if that’s O.K. with you.

Johnathan: Absolutely.

Paul: Good. So, let’s start from the absolute basics so that we’re all on the same page. Could you just explain very briefly what Adobe Air is so that people that haven’t come across it before kind of know what it does.

Johnathan: Certainly. Adobe Air is a development platform for making desktop applications to make desktop applications cross-platform. So, something that you build once and that would work on Windows, Mac OSX as well as Linux.

Paul: O.K. And this is built using web technologies…

Johnathan: Yeah, It’s really great that they’ve managed to leverage what they know things like Flash, Flex, and really the kicker is being able to develop desktop applications using HTML, CSS and JavaScript that, obviously, a lot of us web developers are going to be familiar with.

Paul: Sure. So, I mean that’s I guess why we’ve included it on the show even though it’s a web design podcast, that kind of line between the web and desktop applications seems to be blurring and Air is a big part of that. What drove you to kind of investigate it and kind of look into Air as a product?

Johnathan: For me, it was just a curiosity. The platform, what it could do, knowing that I could create a cross-platform desktop application was kind of enticing. When we build for the web we’re trying to do things as cross-platform as possible make sure that we target as many browsers as we can, and really be able to reach out to the people and do really cool things. So, for me it was like, O.K., well what can I do with this what are the possibilities. One of the first things that went off in my brain was building a Twitter application. At the time, when Twitter was up for more than 24 hours straight, it was kind of cool to be able to build a desktop application to kind of separate out from the web, because the web site was frustrating me to know end, and to be able to put in stuff that made the site more usable for me and in the end was a tool that I got to use every day and that I enjoyed to use.

Paul: Cool. I’ve kind of got a basic understanding of it. I understand what it does and I understand the kind of technologies that exist under it, but can you kind of give me an idea of, you know, how it works as such. I know how to create an HTML page, CSS and Javascript and stuff like that. How do I get from there into turning it into a Air application?

Johnathan: It’s surprisingly quite easy. What happens is, if you look at the Air runtime, is it essentially runs your Air application, so you don’t create a .exe file or a .dwg file you don’t create an executable in the traditional sense. What you end up doing is creating a .air file that you use to distribute. The Air runtime actually handles that. Building that .air file, there is an SDK available from Adobe that allows you to compile this Air file. So, those Air files are pretty straight forward, they’re really just like a ZIP file with some extra information in it. So, to create an actual Air application, you can do it just using a normal text editor, you can do with specific IDEs like Eclipse. If you’re into Flex development, they have Flex builder. If you’re into just doing HTML and CSS kind of thing, you might want to look into Aptana they have Air support built right in. If you’re a fan of Dreamweaver, there’s a Dreamweaver extension for automatically compiling your application, and being able to set properties on your application. So, things like how big should the window be when it opens up, can I resize it, what kind of stuff can I do with it. That obviously, in this GUI sense, to a certain degree can make things a lot easier. So, I think there are a lot of benefits to using an IDE with built in support, but you don’t have to. There is the capability of just using a normal text editor and then running the SDK command line sequences to actually generate the Air file. It is really straight forward.

Paul: So, the one selling feature or one thing about Air that’s been promoted quite heavily is the fact that you can take online applications offline in a sense. The application is still usable even if you’re not connected to the Internet at a particular point in time. I think they showed off, right from the beginning, an eBay example of that where you could do all kinds of things offline, and then when you connected it was all uploaded. How does that kind of process work? There must be some kind of local database that’s running, one presumes.

Johnathan: That’s correct. I think some people may be familiar with Google Gears in having the local storage using the SQLite database. Adobe Air actually does something very similar. They do have a local SQLite database that you’ve seen create local databases and store any information there. There’s actually different ways. You have access to the local file system, so you can certainly write new files. Say, if you wanted to create new text files, xml files, new binary formats. So, if you wanted to create an image editing software that stores files in a binary format, you could do that. So, there’s a lot of flexibility there because you do have some access to the local system. You have network connectivity, so you can do either regular AJAX calls or you can do socket connections. You can connect to web servers. You can connect to remote database servers. You’ve got a lot of flexibility and a lot of control because of that.

Paul: You seem quite enthusiastic about the development environment. What has been your impression of it. Was it something that was a steep learning curve, but when you get there it’s really cool, or is it easy straight out of the box? What were your impressions?

Johnathan: I think it’s going to depend on what it is you’re trying to do. I think that there are going to be some frustrations. There are going to be some things that you have to understand about the environment. To give you an example; the HTML/CSS stuff is pretty cool it basically runs on a WebKit engine, which is the same engine that powers Safari. That gives you a lot of control and stuff, but ultimately that WebKit engine is still running within a Flash runtime. So, there are some limitations to that because of the fact that Adobe just simply hasn’t built in certain support. Things like support for double byte character encoding, so Chinese and Japanese character sets can be more difficult. However, they are working on that. Version 1.1 is supposed to be coming out soon it will have support for that, but right now you’re limited because of that.

Paul: What kind of people should be delving into this. Is this the kind of thing that only a hardcore developer like yourself should be touching or is it something that somebody like myself that would be a front-end interface designer should I even bother picking it up or am I better keeping away?

Johnathan: It’s really easy to develop in. I think you can make really quick solutions really straight forward. To give you a comparison; there is a Mac software called Fluid for creating site applications, but that is separated from the browser. You can kind of plot the same kind of things with Adobe Air because you do have that WebKit engine. You can basically use it as a browser. So, to give you a quick example; Muxtape, which is an online mix-taping thing you upload MP3s, and then people can go to your page and listen to your mix tape… The problem is that if you accidentally close the browser, you lose that information. I think there are a lot of websites that have this stickiness factor where you want to decouple the application from the browser. So, I put together a really basic example in which you type in a URL and it loads up a mix tape. That’s a very straight forward interface, but to be able to do that in a desktop application that I can minimize to the dock or the system tray is something that is, I think, a lot more appealing than running this kind of stuff through the web browser. And, it was really easy to put together. I spent about an hour one evening to put that kind of thing … I mean it is a very basic prototype, but the fact is that it is very straight forward to put that together. So, I think if web developers have ideas, they can really take advantage of that and build pretty cool stuff.

Paul: So, it’s not something we need to be intimidated of, then.

Johnathan: No, absolutely not.

Paul: The other thing that maybe is a bit of a concern to us very standards-based designers in comparison to the Flash community is that Adobe says we support CSS and HTML, as well as Flash, but obviously Flash is their product. You kind of get this feeling that they’re going to always support Flash more and that CSS and HTMl are a bit of an afterthought. Is that the case, or is that unfounded?

Johnathan: To a certain degree, it is the case. It’s, I think, unfortunate. I think they are more familiar with Flash. They’re more familiar with that environment. So, as you try to build the equivalent of a browser within this Flash runtime it’s going to be extremely difficult and I think things are going to get missed. And, I saw that sort of along the Beta process. Things like no support for "undo." I mean, that’s a pretty basic thing, but the fact that that’s not built in there does hamper people trying to build HTML-based applications. It works great in Flash-based applications and then what you end up running into is, to give you another example with Snitter, my little desktop Twitter application because it’s built using HTML and CSS, it had certain limitations, but there’s other Twitter clients built with Adobe Air that were built using Flash that actually have different limitations. So, people would say, "Well this application can do it just fine. Why can’t yours?" You have to kind of explain to them that it’s because of the limitations of how the environment was developed. Despite the fact that they are both still Adobe Air applications, technically they’re done differently and there are maybe more limitations as a result of that.

Paul: Is there an opportunity to mix Flash and XHTML and CSS and whatever else together, or do you have to make this decision up front?

Johnathan: No, absolutely not. Certainly, within the Adobe Air environment, you have that flexibility to create these little hybrid applications. I think Snitter, for example, is a good example of it. There’s a lot of Flash components out there that can do certain things. For example, a bunch of folks made an iMap component, so you can actually connect to an iMap server. However, that component is Flash-based. Another component out there that I saw was a Jabber client. So, let’s say you wanted to do a GMail chat client or some other Jabber-connected application, you can import those Flash runtimes into your application and use them from Javascript. So, you do have that flexibility to use both technologies and take advantage of that. I’ve certainly done that with Snitter, and I’ve done that with other applications as well because we have that flexibility of the environment. I think there is that sort of understanding that you can do that, and actually look out for the solutions that not only are HTML and Javascript, but that are Flash-based as well and come up with new ways of thinking because I think, traditionally, as web developers, we tend to separate those two as much as we can.

Paul: That’s quite interesting. You talked about this kind of hybrid approach of combining Flash and HTML at @Media combining them together and about how we had some fears as standards-based designers of even touching Flash in any kind of context. Is that a kind of approach that you would apply beyond Air to the web generally?

Johnathan: Absolutely. I think MuxTape is a great example of that. To be able to play MP3s isn’t something that’s easily done using Javascript. However, you can take advantage of Flash and use its capabilities to play MP3s to create new interfaces that aren’t specifically 100% Flash-based; that we have something that’s still HTML and Javascript that interacts in ways that I think a lot of us are comfortable with, but still have access to a lot of features that Flash offers to us you know, the fact that we can create the bridge between the two; we can do that on the web just as well as we can do that within Adobe Air.

Paul: O.K. That all sounds very interesting and it certainly has made me want to kind of pick up Air and have a play with it and kind of get my hands dirty. I guess, perhaps as the last question then, is what tips would you give to people like me that haven’t yet touched Air and are considering having a play. What are the big traps to avoid? What are the good things to start with. Where should I begin the journey, so to speak?

Johnathan: I think probably one of the first things you should do is head over to the Adobe web site. They have a number of really good resources to start off with. Obviously, you’re going to need the SDK so you can actually build your applications, but they also have the dev center where they have a number of introductory articles to learn how to build applications and it doesn’t mean those applications have to be built using Adobe applications like Dreamweaver, you can certainly do them without. So, there’s a lot of really good tutorials on there. From there, they lead off to a number of resources outside of Adobe that would certainly help you get started.

Paul: What about mistakes? What were the big mistakes you made up front that, with hindsight, you would avoid? Or, did you get it right the first time?

Johnathan: I don’t make mistakes! Well, I think one of the cool things about the environment is certainly the flexibility to take advantage of a lot of advanced CSS. Because you are using the WebKit engine which, when it comes to CSS 3 support, is one of the most advanced, you know that you have support for things like rounded corners, border radius, that you have support for multiple backgrounds, image-based borders you can do some really cool stuff with that that is really fun to play around with. You can create transparent applications, so if you wanted something that was completely and uniquely shaped, you can do these really cool things. The downfall for that is that you can quickly start running into performance issues. If you start creating all of these alpha PNGs that are layered over the top of each other, they give you a lot of flexibility, but unfortunately are a performance drain on how much your system can actually handle. I think that was one of my initial mistakes going in and saying "Wow, I’ve got all of this stuff that I can use let me throw everything at it" and then realizing that, you know, maybe that wasn’t the best solution. I think we still have to be wise in considering how we structure our CSS, how do we structure the design in such a way that, while it’s still flexible, it still does things from a performance-minded aspect so we’re not doing things that are going to unnecessarily slow down or application. Those are things that we’ve got to think about.

Paul: That’s some really good advice Johnathan. Thank you so much for coming on the show. That was a great introduction to Air. Hopefully it’s encouraged a lot of people listening to the show to go out there and give it a go. Thanks for coming on and talk to you again soon.

Johnathan: Awesome. Thank you very much.

Thanks to Aaron Cooper for transcribing this interview.

Listeners feedback:

Getting a feel for accessibility

Our first contribution is from Kenneth and is about accessibility:

I listen to your podcast all the time and am working hard to become a very good web designer. My question for you is about accessibility, I hear a lot of people talking about it but not a lot of web designers are working hard on it to create sites that disabled people can use. I want to be a person who builds accessible sites that really work. How would someone know if their site is really accessible? How can you feel what disabled people are feeling when they visit your site? Could you talk about the different tools that disabled people use to go online so that we can use those tools and try to understand how they feel.

Okay. Let’s start by clearing up a minor point. Validation is not directly related to accessibility. Having a site that validates does not make it accessible. Equally, a site that does not validate is not necessarily inaccessible. Admittedly a site that validates is more likely to be accessible, but that is all. It is great you validate your code and you should continue to do so. However, it is okay if your site does not always validate. There are good reasons why Boagworld does not and I am sure the same is true for Clear:Left.

Let’s turn our attention to the heart of the question; how can you better understand the experiences of disabled users? It is an admirable aim but one that ultimately is impossible to achieve. There are so many different types of disability that you cannot associate with them all. That said, I can make a few suggestions which might help.

A good place to start is by trying out a screen reader. Increasingly screen readers are bundled with operating systems. Recent versions of Microsoft Windows come with a basic Narrator, while the Mac OS includes a more feature-rich screen reader called VoiceOver. However, the most widely used screen readers are the separate commercial products like JAWS for windows. This is probably a good place to start as JAWS offers a free trial version for you to experiment with.

However, be warned. When you first use a screen reader it is an intimidating experience. They take a lot of getting used to and can leave you with the impression that a blind person will never be able to use the internet. An alternative would be to watch a demonstration of a screen reader in action. Ian Lloyd did an excellent demonstration for Boagworld a while ago.

Of course not all visually impaired users are blind. Some use screen magnifiers which enlarge screen content. Again, most operating systems have this functionality built in so you can easily try this for yourself. However, there are also a number of commercial products you can try out too.

The other form of visual impairment worth investigating is colour blindness. Although not as serious, it is far more common and affects a large number of users. There are a couple of tools which will give you an idea of what a colour blind person is seeing. The first is Colorblind Web Page Filter which allows you to enter a url and see what that page would look like to a colour blind user. The second is Sim Daltonism, a colour blindness simulator for the Mac OS. Both will help you better understand what the web is like for colour blind users.

The final little tip I want to share with you is kind of stupid but does sort of work. I do a lot of design for the elderly and they often suffer from a mixture of visual problems and motor issues (like arthritis). In order to better understand their experience I have bought a pair to ski gloves and some reading glasses (I don’t need reading glasses). Every now and again, I surf the site I am designing wearing both the glasses and gloves. The glasses make the screen hard to read while the gloves hamper my use of the mouse and the keyboard. There is nothing more frustrating than trying to select something from a drop down menu wearing ski gloves!

Turning problems upside down

Our second listener contribution for today is not a question but a tip. It comes from Jeremy and he writes:

I can’t remember the name of the book off the top of my head (Getting Things Done?) that you’ve been recommending, but you mentioning it reminded me of a problem solving method that I learned a few years back that I thought you might enjoy. It’s called turning the problem upside down. It sounds stupid, but honestly it works pretty well.

The principle behind it is if you can’t figure out a solution to a problem or are having trouble coming up with different ideas, you turn the problem upside down, or invert it, and then come up with solutions for the backwards problem. For some reason it’s much easier to think of the backwards solutions. Then you flip them back to normal and there are your solutions. Sounds confusing, so here’s an example:

Problem: You want to increase traffic to your website

Turn the problem upside down: You want to decrease traffic to your website

Some ‘off the top of my head’ Solutions:

Make the site unfriendly

Randomly shut it off

Never update anything

Be rude

Keep key content hidden or difficult to find

Now let’s flip the solutions back again and see if they solve the original problem:

Make the site more warm/friendly

Make sure it stays up reliably

Be good about frequently updating content

Be aware how of my copy and if I’m talking down to my visitors

Make sure the good content is easy to find and prominent

What a great little tip! Excellent when you are suffering from creative block. I love it when you guys send in suggestions rather than questions. I know from the forum that the boagworld audience is hugely experienced and its great when you share that experience. Keep them coming!

Too many content management systems

Posted in Development on August 8, 2008 by Paul Boag

I know we live in a capitalist society. I know we are supposed to believe in choice. However, there are just too many damn content management systems. Another extract from the Website Owners Manual

Let’s face it, most content management systems look the same there days. They all offer very similar functionality. After all, most people want similar things. Once you have narrowed the field by price it can be hard to make the final decision.

However, functionality and price should not be the only criteria by which you make your judgement. There are a number of additional issues which need considering. In many ways these are just as important.

These include:

Licensing
The development team
Security
Accessibility and code quality
Documentation and training
Support
Community

We should begin by looking at the subject of licensing.

Licensing

Examine in detail the license attached to your choice of cms. It is not uncommon to find licenses that state you can make no change to the source code or use a alternative developer.

You may also find that licensing is per site or worse still per user. This can become very expensive if you want to setup multiple sites or have a large number of content contributors.

Ideally you want an agreement that allows unlimited use of the cms with the exception of reselling.

The development team

Look carefully at the development team behind any cms you are considering. For example is it an open source project with a community of developers or the product of a single company?

Neither approach is wrong. However you need to be confident in the long term health of the product.

Open source projects can be highly productive despite often being created by volunteers. That said, they can die off quickly if a more attractive project comes along. If you are considering an open source solution look at the age of the product. Mature products are more likely to remain supported in the long term.

With a commercial product you need to be confident in the long term viability of that company. Consider requesting a copy of their accounts to confirm their financial stability.

In both cases look for a team that are regularly releasing updates to their system. This is particularly important from a security perspective.

Security

Security is an important issue for any content management system. If your site is hacked you could loose content and find yourself in litigation if hackers get hold of your users personal data.

Judging the security of a content management system is not easy unless you have technical expertise. If unsure, get an experts opinion. However at the very least you can do a google search on the name of the cms and ‘security issues’. If you see lots of results then you will definitely want an expert opinion.

Accessibility and code quality is another important, and yet hard to judge, issue.

Accessibility and code quality

As we established in chapter 7 it is important to build using the latest best practice. This ensures your site is accessible and provides the flexibility to adapt over time.

Judging whether a content management system uses best practice is difficult if you are not a web designer. However, talk to the cms developers about their approach to accessibility. Equipped with the knowledge from chapter 7, you should be able to get an indication of their competency.

One aspect of best practice we have yet to discuss are webpage addresses. For a long time content management systems produced addresses that were hard to read. For example:

http://www.boagworld.com/index.php?sourceid=navclient&q=4

However, more recently content management developers have realized this is hard to read and damaging to search engines placement. Therefore modern content management systems produce addresses that look more like this:

http://boagworld.com/technology/friendly_urls/

This is a huge step forward and also allows the web address to be used as a navigational tool. Users can identify where they are in the site and even edit the url to find different pages. For example if the above address is shortened to:

http://boagworld.com/technology/

it will return all pages within the technology section.

Whenever possible look for systems that support friendly urls. They are a good feature to have and provide an indication of how up-to-date the practices of the developers are. If a cms supports friendly urls they probably support accessibility and standards too.

Additional information on best practice should also be made available through the documentation that supports the cms. This too is an important differentiating factor.

Documentation and training

Good documentation is a crucial component of any cms. As I have already said, content providers may not be using the system on a daily basis. They can easily forget how it works. Documentation should therefore be comprehensive and easy to use. Some content management systems also provide walkthroughs and video tutorials. These also help users understand how the system operates.

There should also be documentation for developers too. This will enable your web team to adapt the cms to better suit your needs. Without this it can be nearly impossible to work out how the cms works.

Alongside documentation, training is another useful resource. This is important for content providers who need more than a manual before they start using the system. Training provides them with hands on experience and the opportunity to ask questions.

No matter how good the cms and supporting documentation, there are occasions when you will require additional support.

Support

You need to ask some hard questions about support. What happens if you identify a bug in the content management system? Will you be required to pay for the fix? How fast can you expect a response? Do you require 24/7 support?

You need to know your requirements and have a good understanding of what the cms provider can offer.

Beyond fixes, there are broader questions about help. If you have a problem with the system is there somebody you can turn to for advice. Do you have to pay for this support and when is this support available?

Of course not all content management systems come with support. It is unusual for anything but enterprise level systems to offer this option. If it is not available you need to look at whether the system has a vibrant community.

Community

The community is made up of other individuals who use the cms. They share advice and experiences via forums, mailing lists and support sites. Such communities are particularly important for open source content management systems because these products rarely offer formal support and training. However, many commercial products also have excellent online communities.

A good community will be able to answer questions, offer support and even make available a range of plugins that can be used with your cms. Before investing in a cms ensure it has a vibrant community. Visit the support site and look at how many users are registered and how often they post. Examine the kind of topics people are discussing and particularly how supportive they are to new users. It is not unusual to find apparently vibrant communities that are hostile to new users asking ‘dumb questions.’

For more from the Website Owners Manual and early access to chapters as they are written go to the books website.

124. HTML 5

Posted in Classic shows on July 2, 2008 by Paul Boag

In this weeks show we explore how to create better online surveys and Lachlan Hunt joins us to discuss HTML5

Download this show.

Launch our podcast player

Watch the behind the scenes video (Part 1)

Watch the behind the scenes video (Part 2)

News and events

Removing Microformats

The story that has generated the most email this week is the BBC announcement that they will be dropping the hCalendar Microformat. This decisions comes because of long standing accessibility concerns over the machine readable content within that particular Microformat. The problem is that code meant to be used programatically is potentially read out to screen reader users and displayed as meaningless tooltips to sighted users.

The decision of the BBC to adopt Microformats was a huge boost to the movement. Equally the rejection the hCalendar is a blow. However, it is important not to get this out of proportion. Remember, they are only rejecting a single Microformat not the whole approach.

The other thing to consider is that the BBC is a public service organisation with an incredibly high obligation to ensure maximum accessibility. In many ways they are in a unique position. Although it maybe appropriate for your organisation to pull hCalendars too, it should not be based on the decision of the BBC.

My advice is as follows. If you already have hCalendar information on your site I would probably leave it (dependant on your exact circumstances). The Microformat community is working on a solution and I would implement that rather than removing hCalendar entirely. If however, you are not yet using hCalendar then I suggest you hold off until an updated specification is released.

Becoming employable

In the past we have spoken about becoming a professional web designer. I know that many people who listen to this show or read the blog are students. You are concerned that the skills you are being taught are out of date and will not improve your employment prospects. How then do you become a more employable web designer? What skills do you actually require?

Andy Rutledge tackles this subject in his post "the employable web designer". Without a doubt it is the best post I have read on the subject of web design career development. I highly recommend you read it.

The thing that impresses me is that it looks beyond the obvious design and technical skills required to be a web designer. It also tackles the business and communication skills too. He really drives home quite how wide an understand a good web designer has to have.

My only criticism is that it could feel demoralising. You may read the list and think it is an unachievable aim. However, I don’t think that is the case. What Andy outlines is the optimal requirement of a web designer, rather than what is needed to get your first step on the ladder. I certainly did not have all of the attributes listed when I started.

All we need now is a second post telling us how to gain the skills he lists.

Better CSS font stacks

David (a boagworld listener) sent in the next story. It covers a subject that I am currently still grappling with. It is a post about CSS font stacks.

If you code in CSS you already know about font stacks. It is where you specify the fonts you wish to use. You can say for instance; use Helvetica and if that isn’t available use Arial. If that fails use a generic san-serif font.

For many of us that is as far as our thinking goes. The majority of us use very basic font stacks that are uninspiring to the point of being insipid.

I love this post because it lays out a very clear methodology for improving your font stacks. It also goes on to provide an impressive selection of font stacks organised into heading and body fonts, allowing you to instantly improve your site

If your site is looking tired and boring, but you don’t have the time to redesign, consider adding a new font stack. Such a simple change could make a real difference.

Do flexible layouts still matter?

Our last story of the day is a post from Smashing Magazine entitled Flexible Layouts: Challenge For The Future. To be honest I was ensure whether to include this post or not. On one hand it covers an issue many people have been asking me about. On the other, its arguments seem stretched and the whole thing ends with an advert for a CSS framework.

The article tackles zooming and fluid design. The new generation of web browsers – Firefox 3, Opera 9.5 and Internet Explorer 7 – provide full screen zooming. This gives users has the ability to enlarge the whole interface, not just text. Some are arguing that this is the end of fluid layout because zooming tackles many of the accessibility concerns associated with fixed width sites. However, this article strongly disagrees.

The author argues that flexible designs are better for mobile devices, that pixels are becoming less important and that the user shouldn’t be required to customise a site to their needs (it should be done automatically). Although his arguments are weak at times and he uses some fairly dodgy comparisons I do generally agree with him. I see no reason to think fluid design will go away anytime soon.

That said, I am in no doubt that page zoom does reduce the number of occasions fluid sites are necessary. Ultimately there is no right or wrong answer. It is entirely based on the situation. For example Boagworld, Headscape and The Website Owners Manual all use fixed designs. However, many of my client websites do not. That decision is based on numerous factors such as device, user base and business priorities.

Feature: Creating a Better Survey

The web allows us to interact with our customers more than any other medium. One of the tools in our arsenal is the online survey. However, these are often badly implemented. In this weeks feature we find out how we make your surveys more effective?

Interview: Lachlan Hunt on HTML 5

Paul: Joining me today is Lachlan Hunt; It’s good to have you on the show

Lachlan: Thank You Very much

Paul: It’s great to have you here I really appreciate you taking the time to join us, now the reason that we asked Lachlan on the show is because he posted a brilliant article on the A List Apart site about the subject of HTML 5 and I have been keen to look at this subject for a while partly because of my own ignorance to be honest, um, so lets kinda kick off by if you could perhaps tell us a little bit about where HTML 5 is at the moment I know that kinda getting a language to a release like this finalized is a massive process so can you tell us where we are at in that process.

Lachlan: OK, it’s, um, a really an ongoing process with browsers implementing different parts of it progressively so it’s not, you know, going to be all implemented at once and ready to go in one, er the next few browser implementations. We have some features implemented already and shipping in browsers other features which are being worked on at the moment and other are planned for, but still a few years of yet. But it is gradually getting there. We are trying to focus on what authors really need, instead of trying to do it all at once

Paul:Ahh, okay so that a slightly different approach that we have seen in the past, the idea of an incremental roll out. So how does that work from the W3C’s point of view are they doing modular releases is that how it works

Lachlan: Um, at the moment no, but the way the spec is structured each part of the spec, what I am trying to indicate is the stability of each section of the spec as we go along. SO thing like the Canvas API which has been in browsers for a few years now, it should be getting to IE very soon. That section is pretty stable, Other things for example "data grid" or a lot of the web forms are not widely implemented.

Paul: OK so that quite an interesting approach to the problem I guess from what you were saying earlier to me there is a community base element people can get involved and contribute. How is that all working then?

Lachlan: Well we’ve got a REALLY REALLY open mailing list on whatwg.org anyone can subscribe at the moment there wa about 800 subscribers on that list anyone is free to subscribe and post feedback about the spec if they want to, but that’s not for everyone obviously because it’s quite a high volume mailing list and not everyone can keep up with that. We have also got an open blog on http://blog.whatwg.org/ where absolute anyone who wants to can write an article submit it and have it published. Anything to do with what the WHATWG are about, HTML5 and anything related to it at all. It’s also a good way to let the community know what’s going on by publishing articles also to find out what people think because they keep posting comments on there as well. We have also got an open forum which is at http://forums.whatwg.org/ again anyone can subscribe to that, am sue you know how a forum works

Paul: So there are lots of different ways to be involved, I have to confess things like that can feel quite intimidating to get involved in. You’re kinda worried about putting your foot in it, and saying something really dumb, is there kind of Opportunities to lurk and are people fairly friendly over there? I guess you are going to say yes aren’t you

Lachlan: Yeah everyone is friendly over there,they are nice sort of area to go to aim at web developers and people who aren’t quite as technical with the spec areas and stuff. You can ask any question you want and just learn whatever you want as well. Their is also the w3c side of it as well. Which is strictly related but is more focused on the actual technical side and issues so yeah. The What WG and the W3C are both publishing exactly the same spec and they both work on it together and feedback can be sent to either place, it will all be taken into account

Paul: Oooh, that’s useful. So looking at kinda the state of affairs at the moment with HTML 5, reading through your article there was some things in there that really sounded quite exciting, there was this thing about structure and some kind of additional elements that could be used, which provide a little bit more structure, headers and footers and things like that can you tell us a little about that, and maybe explain a bit of what those do.

Lachlan: Well at the beginning of the work back in 2004 / 2005 we basically took a look at what a lot of site where doing and we noticed that they were all using a similar structure. All the blog’s were using headers and footer and generally things like column layouts to show articles and stuff like that. So we wanted some semantic elements to come and cover each of those features that people actually used, solving the real problems that they were actually focusing on. instead of having to do "Div" elements for everything, which is what people do we give them an actual element and that also has a side effect of increasing accessibility because an element with specific semantics can be hooked into the accessibility API’s and help someone with assistive technology navigate the document a bit easier.

Paul: Okay, because I mean reaction just glancing at it quickly and not thinking about it was what’s wrong with the div with an ID Equals footer, or an ID equal header or whatever but like you say, as you think about it more it become obvious that if those are considered distant elements, one person might call it a footer another might call it "the bottom" or whatever else if they have consistent semantic names then you know you can have screen readers and stuff jumping to the footer or avoiding / not reading the footer depending on what is set in their preferences, is that what you are thinking?

Lachlan: Yeah that sort of it, it’s also helping the authoring side too, as there are lots of Div elements in source code which makes it easier to read if you have got elements with different names

Paul: yeah very much so, I spend half my life trying to which closing Div relates to which elements, that very exciting. Obviously the other big area you talk about in your A List Apart article is the audio visual elements and there is a lot that’s happening in there. It’s always had the vague feeling that HTML has never had any kind of, erm, erm, the audio visual elements have always been and after thought, what happing in HTML 5 in regards to that?

Lachlan: Well we have added the video and audio elements to the spec to try and allow video to be added directly to HTML, at the moment we have sites like youtube revel and all the other video site out there using flash to embed video and using the flash to give customized controls and stuff to the user, it’s really awkward, depending on proprietor technology, so we want to open that up a bit give a very very easy to use Javascript API to hook into and promote custom controls and all sorts of cool stuff with videos and of course audio as well. We have got experimental implementations of that in opera and in webkit. I have heard mozilla is considering implementing it as as it is now I am not sure of the status of their implementation. However the one big problem with video and audio at the moment is with Codecs, there are a whole load of software patent issues going around and we are not quite sure what codec we are going to standardize upon or if we are going o be able to get common codec support among the browsers, That’s an open issue but I am no lawyer to I cannot really go into that, so the ultimate aim is that you will be able to embed your movie file, your avid file or whatever directly into the HTML without the need to kinda pump it through something like flash

Paul: cool

Lachlan: that make it a whole lot easier to the authors hopefully

Paul: Yeah, you kind of, to some extent got to ask the question why do we need that when we have got a solution like flash

Lachlan: Well because Flash is a proprietary technology it’s managed only buy Adobe , they control it, they control the changes and what does and what does not go into future versions of it, however the thing with HTML is that it is an open standard platform which can be implemented by anyone and maintain interoperability between those venders.

Paul: It’s intrusting isn’t it that adobe has just announced they are opening up the flash format, do you wonder if that’s a reaction to some of the stuff you have been doing to kind of force their hand if they want to stay ahead o the game and dominant they need to be open

Lachlan: Yeah I don’t know how that going to work though, it depends, if they open the format up and actually make it an open development process where anyone can contribute to the future version and features which go into it or whether they just write the specs and tell other people to implement based on what they write, so I don’t know much about that. It will be interesting to see how it goes.

Paul: Very interesting, Now the next thing you cover in the A List Apart article is something which you titled "Document Representation" now I have to confess this confused me, so do you want to explain a little about what you meant by document representation. What you were getting at there.

Lachlan: Yeah, well in the past we have had HTM, and XHTML with two separate specs, HTML 4.1 which a lot of people use and XHTML 1.0 which a whole lot of other people use one of them is based on XML and is really really strict syntax that requires well formedness and is supposed to when you serve it correctly, if you make a well formedness error the browser is suppose to stop processing and throw and error message saying "Sorry I cannot handle this" where as HTML is more sorta loose and convenient in its error handling, it’s the traditional inspired by SGML, although really only syntactically similar these day but the error handling is a bit more lenient and you can get away with making a lot more errors. So instead of having two distinct language which you can use we have combined them into a single language which share the same elements and attributes and everything and as much a possible and when the browser reads those file it produces and internal representation called the DOM, a lot of javascript user will be familiar with the DOM as they work with that with their scripts to modify the document through the DOM. That’s an internal representation which is mapped, the DOM which is sort of mapped to by the syntax’s, the HTML and the XHTML syntax’s so it give the authors a choice of which syntax they want to use

Paul: So why do we need that choice what is the key difference, I mean you talk about HTML being more lenient are there other reason for choosing one over the other.

Lachlan: erm, well I don’t really know. However a lot of authors do prefer the strict syntax of XHTML like to make sure they quote the attributes and encode all their ampersands properly. They like to know they have done everything perfectly as with HTML a lot of people do make mistakes inadvertently and don’t want end users to see big error messages, so it’s a bit more user friendly if some little small error slips though their CMS and causes problems.

Paul: So it’s basically come down to personal preference then

Lachlan: yeah

Paul: Okay, that’s fair enough, so both, we are going to see equal support for both of them in browser manufacturers are we

Lachlan: Well that’s the hope we have said that we have got good support in most browsers, it’s just IE which is lagging behind

Paul: (Sarcasm) Oh that’s a suprise (Laughs) Okay are there ant other things in HTML 5 that might be of interest to those listening to the show which we should be paying attention to?

Lachlan: erm, well, as I said before we got canvas implemented in most browsers

Paul: So tell us, what’s canvas

Lachlan: It’s a 2D drawing API that you can use javascript to draw dynamic image with. People have used it to implement things like graphs that are built using tables of data which are on the page. People have also gone and done 3D games with it which is really cool

Paul: Wow, that incredible. I mean that sounds very similar to SVG is it a different thing.

Lachlan: It is different SVG is entirely done with XML, you modify that with script via the DOM by changing elements and attributes and stuff or with CSS. Canvas is an immediate mode graphics API where it is more like a bitmap sort of thing where as SVG is vector graphics, and canvas is bit map. They can both do images, the same sort of images, if you like but we have both vector images and bitmap images, so they both can serve different purposes.

Paul: Right, I see. Okay that’s good, so okay the big question, kind of the final question everyone is going to have is when can they start doing some of the cool stuff. Now you said right at the beginning this is going to be modular support based thing so we are going to be able to see some of these elements before others. You know some parts before other, so what can we do now, what are we going to be able to do soon give us an idea of where things are at.

Lachlan: erm, okay let’s see I think what’s being implemented at the moment. Cross document messaging is being implemented at the moment, that’s an API that lets you send message between documents with javascript without worrying about cross domain security issues,

Paul: Oooo…. that’s good.

Lachlan: Yeah it’s a really, really handy API that been implemented in opera for a while and I heard mozilla is implementing it soonish and should be in firefox 3 thought I am not entirely sure about that. That should be very very soon, erm, what else have we got, we got…. hmmm, this is tough

Paul: Sorry put you on the spot there (laughs) is that last one supported in webkit?

Lachlan: erm, I am not sure I would have to double cheek that

Paul: Okay that’s fair enough

Lachlan: yeah,

Paul: Okay so any other elements? Things like the structural changes are any of those being supported yet?

Lachlan: Not quite yet, erm as far as I know support for those requires changed to the phaser, and to implment the new pharsing algorithm in HTML 5, as far as I know browsers are not yet focusing on doing that because..

Paul: Okay that’s a shame, because that one I liked the sound of, what about the audio and the visual stuff?

Lachlan: We have experimental implementations in opera which supports OGG video, though it’s not really in a public build version yet, there is a experimental version which was released last year sometime. And webkit also has support in their nightly builds, which supports mpeg 4 unfortunate they don’t support the same codec but you can experiment with them.

Paul: (laughs) That would be far to easy

Lachlan: yes I know

Paul: So it’s all progressing slowly but, erm you know obviously the one name which has been very absent in the list you keep mentioning is Internet Explorer, so I expect we can probably see some slower movement there. We are talking you know in the years before this all becomes mainstream and we can actually start using it. Is that a fair comment to make?

Lachlan: Yes it will be several years before the entire spec is finished, we are hoping that it can get finished sooner rather than later but realistically it’s going to be quite a while yet, But it is important to know people will be able to use theses features before the spec is finished; so it depends on when browsers start supporting features authors can go ahead and use it.

Paul: That’s great and real exciting that you can start to do that sort of stuff. you know that we don’t need to wait for it all to be set in stone before moving forward. And it’s always exciting as well to see the future, know what coming up and be aware of everything. so is there somewhere people can go a websites address and keep an eye on what is currently supported by browsers.

Lachlan: Not at the moment but that’s something worth looking into, I think there is a wiki on the Working Group site, it does have some implementations listed but I am not sure how up to date. But it’s something I think we should look into

Paul: Yeah it would be great to have some kind of single page which says what features are supported by each browser that you could check back every few months see what’s going, there you go there is my contribution to the working group (laughs). Alright it was really good to speak to you and thank you so much for your time, What we will do is to get you back in further down the line and have a check to see where we have currently got to in the development of HTML 5, Thank you so much for your time.

Thanks to Jamie Knight for transcribing this interview.

Listeners feedback:

Staying healthy on the web

Evan writes: My question to you is not entirely related to design, development or management but rather about health in the web industry. This is very important but we often seem to forget about it. We spend hours upon hours at our desks but are unaware of the damage this could be having on our health. Eyeballs almost touching the screen, typing without a break, sitting incorrectly – just a few examples. So, what do you do to maintain good health while working?

I am possibly the worst person in the world to answer this question. I consistently abuse my body while at work. In fact a physiotherapist friend said I had the worse posture in front of a computer she had ever encountered.

However, there is possibly something to learn from my terrible example. Let’s look at what I do and compare that to best practice.

I sit with my leg tucked up under me – Posture while working is important. Both feet should be flat on the floor, rest your wrists on the desktop in front of your keyboard and make sure your monitor is at eye level (in other words avoid laptop screens).
I stoically refuse to use anything other than my preferred mouse and keyboard – Using the same keyboard and mouse in the same position day after day can cause damage. Try using a variety of different hardware and positions. Push your mouse and keyboard nearer or further from you to change the position of your arms.
I believe that an individual pixel should fill my field of view - Leaning too close to your monitor is a particular weakness of designers who want to position that pixel ‘just so’. This not only damages your eyes but also your back. When you learn forward your neck and back support the weight of your head. When sat upright, the head is supported by a straight spine and therefore your chair bears the weight.

On the upside I do take regular breaks. I would like to claim this is because of my health. However, I think it has more to do with my short attention span. I get easily distracted and wander off to do something more interesting.

From Photoshop to HTML

I see a lot of PSD 2 HTML services on the internet but never tried any out. It seems to be an great option for an designer for making an quick website, to edit later myself.

What is the opinion of you guys? Love to hear you discuss this topic in one the next podcasts.

An long time listener from Holland.

I have to confess to being a snob over these services. Until recently I have always doubted the quality of the code but after seeing some recent examples I have begun to change my mind.

We are even considering giving them a try at Headscape, just to see what happens. Certainly from an economic point of view they make sense especially if you have more work than you can handle. That said, I do have three concerns.

First, results may vary. Without a personal recommendation it could be hard to find a provider who can produce the quality you require. Anybody can convert a photoshop document into HTML. However, it is much harder to do so using techniques like microformats, semantic markup and accessibility. Also, just because the quality was good once, does not mean it will be so again. As the good providers get busy it can lead to a decline in quality.

Second, people code in different ways. Unless careful attention is given to commenting, it is hard to pick up somebody elses markup. This is fine for relatively static sites where only small changes are required. However for projects where change happens regularly as the site evolves, it is more important that the markup is tailored to your style of coding.

My final concern is that this could lead to designers not learning HTML. As I have said before on the show, I believe all designers should be able to code themselves. You need to understand how the web works and markup is apart of that. Also, if you cannot code how can you judge the quality of the markup you receive?

121. Coda

Posted in Classic shows on June 11, 2008 by Paul Boag

In this weeks show we discuss 5 quick fixes to accessibility, and we review the mac code editor Coda.

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Skipping Photoshop

The biggest news this week is a post from 37Signals entitled ‘Why we skip Photoshop‘. The article outlines some excellent reasons why they choose to bypass designing in Photoshop, instead going straight from sketches to HTML/CSS. Reasons include…

Mock-ups are not interactive
Photoshop draws you into the details too early
Text on Photoshop is not like text on the web
Photoshop is not productive
Photoshop does not aid collaboration
Photoshop is too complex

They are all valid points. However, although I accept this is right for 37Signals, it is not right for Headscape. Our view is echoed completely by the response of Jeff Croft at Blue Favor. He argued…

37Signals are working with an established visual aesthetic
That 37Signals aesthetic is simple and so is better suited to pure HTML/CSS
That 37Signals do not work with clients
That working in HTML/CSS can lead to constrained design.

That said, the post has made me consider experimenting occasionally with the approach. For me that made it worth reading.

It is a great discussion and I am really glad Jason at 37Signals brought it up. It has certainly created a lively debate including posts from Jon Hicks and Mark Boulton.

Web Designers should do their own HTML/CSS

But we haven’t finished with 37Signals yet. They have posted a second blog entry this week entitled ‘Web designers should do their own HTML/CSS‘. The title is fairly self explanatory and they put forward a good argument as to why designers should never produce a design and then simply hand it off to ‘code monkeys’ who make it work.

At the end of the article they write…

We simply don’t consider designers who don’t get their hands dirty with the materials relevant to the kind of work we do.

If you’re a designer working with the web who still doesn’t do your own implementation, I strongly recommend that you pick up the skills to do so.

Whether you agree with 37Signals or not, the message is clear: You will struggle to get a job if you do not know how to code pages as well as design them.

We would certainly never hire somebody unless they know HTML/CSS just as well as they know Photoshop. The nature of the web means that an understanding of the medium is crucial to creating a great user experience.

Beyond CAPTCHA

I hate SPAM. I hate it with a passion. I particularly hate comment/forum SPAM because it not only inconveniences me but also affects my users.

One common approach to the problem is CAPTCHA. CAPTCHA presents the users with a distorted word(s) that they have to type in before they can comment.

Although in principle CAPTCHA sounds great it does have a number of weaknesses…

It creates accessibility problems
It are hard for normal users to complete
It can be beaten by spammers
It make SPAM the users problem

In short, CAPTCHA doesn’t work. So what is the alternative? Well, that is what James Edward (AKA Brothercake) explores in a post on Sitepoint entitled ‘Beyond CAPTCHA‘.

He looks at server side solutions, services like Akismet and honeytrap approaches. He also looks at OpenID and other forms of authentication.

The conclusion is that there is no perfect solution. However, he argues we need to stop making this the problem of users and take on the responsibility ourselves.

I can certainly see his position and generally speaking I agree. However, when you are faced with limited time and budget it can be necessary to cut corners. Personally, I cannot stand CAPTCHA and I regularly fail to complete them first time. However, I have no problem completing a basic question such as found on the boagworld website.

Read the article and make up your own mind. At the very least it will offer you some alternatives to CAPTCHA that can be implemented quickly and easily.

Website Owner’s Manual

Our last news story is a little bit of news about the book I have been working on. For a start it has a title; ‘The website owners manual‘. However, the big news is that you can start reading it and contributing to the final version.

Feature: Quick Fix Accessibility

Complying with accessibility guidelines can seem like a massive undertaking. However, addressing 5 simple problems can make a huge difference to your sites accessibility. We discuss these in this weeks feature

Review: Coda

Find out why I am seriously considering abandoning the code editor I have been using for over a decade in favour of Coda for the mac in this weeks review.

Listeners feedback:

Team working environment

Gareth writes: I have been “promoted” from a support desk position for an Oracle based financial system to the company’s single web designer. We are not by trade a dedicated web design firm and as such i am having to develop procedures and polices by myself. I have been reasonably successful in this thanks in large part to your podcast, which has in turn led me to blogs and websites such as A List Apart, Sitepoint, Headscape (obvious one that) and many more that have also helped me.

Due to the sheer volume of work that is coming in this year we have found ourselves needing to recruit an additional web designer. At the moment i have all of my work saved on my laptop and all my tasks and appointnments stored in my Outlook.

What tips can you give me in relation to creating a centralised working environment that can be used by both myself and this new person as well managing our work loads. What do Headscape do? I should probably point out that we will be office based in the sane room rather than working from home.

Why is it that Ryan our producer, keeps picking questions he knows I am not an expert on. I am a front end interface guy. What do I know about this kind of thing! Also we primarily work remotely so have a different setup anyway.

That said, I am willing to give anything a go and ignorance has never stopped me before.

Okay, if you are sitting in the same office communication is not going to be the primary problem.
However, you still may want to take a look at Basecamp. Its a great way of organising team working.

The main problems will come in the form of file sharing, backup and overwriting each others work. One thing you might want to consider is a version control system like Subversion. At Headscape we use something called Source Anywhere however this is just personal preference. These systems allow you to…

check out files, preventing others from overwriting them,
rollback to previous versions of a file,
branch files, allowing multiple versions of the same file.

However, for some this might be an over the top solution. The biggest danger is overwriting files. There are a number of code editors which prevent this including Dreamweaver and Coda. This just leaves the problem of shared storage and backup. You could solve these problems separately. However, personally I like the look of Drobo. Its not that cheap ($499 plus the drives) but it provides an incredibly expandable solution that minimises the problem of data loss.

No doubt my ignorance is showing in this question so if you have better advice please post it on the show notes.

Internal Search

Stephanie writes: I have a question regarding internal site search. I am wondering what types of solutions there might be for enabling a site search when one does not have a development team to turn to. All I can come up with is Google custom search and it has some drawbacks (ad serving in the free edition and blog posts do not get indexed right away).

Love the new site!

So you want to add search to your site eh? If you’re using a popular engine such as MovableType, then there will be a built in search, so let’s assume you’re not. If you’ve just built your site using HTML, or aren’t happy with the results of your CMS’s out-of-the-box search, you still have options.

If PHP is your game, you can install a spider on your server, such as Sphider. This will index your site and provide a very customisable solution, that doesn’t send queries off to a third party server. If you’re looking after a large site, with huge numbers of pages and documents to index, you might consider a program called SearchBlox. SearchBlox is expensive, but powerful. It runs as a java based web app on your server, with many fine tuning features that will keep even the most fastidious of clients happy.

If it’s a free, third party service you’re after then you might consider Atomz or Google. Atomz is easy to setup, free and customisable but does include text based ads, similar to Google. The indexing schedule is regular, but only weekly. Google is an established name in search, but also has the downside of irregular indexing and ad supported results. It is of course possible to spend a little extra money to remove these, with Google Site Search

There is however an interesting alternative service called JRank. JRank don’t stuff adverts into the results, they only require that you provide a link to their website on the page that you set as the index for crawling. They also have a REST API, so without much work you can integrate the results in your website, as the PHP code below demonstrates:

<?php $jrank = file_get_contents('http://www.jrank.org/api/search/v2.xml?key=[API key]&q=[query]'); $xml = new SimpleXMLElement($jrank); $result = $xml->xpath('//entries/entry'); while(list( , $node) = each($result)) { echo '<h3>' . $node->title . '</h3>'; echo '<p>' . $node->content . '</p>'; echo '<a href=”' . $node->url . '”>' . $node->url . '</a>'; } ?>

An interesting point in the question was that Google doesn’t index blog posts right away. In my experience, search is used to find old articles or those that can’t easily be found by tags or menus. Newer articles should be easy to find from the home-page of the site, particularly if it is a blog site. If powerful search is required, then you’re going have to put up with the ads, or fork out for a bespoke solution.

120. WCAG 2

Posted in Classic shows on June 4, 2008 by Paul Boag

In this weeks show we talk with Patrick Lauke about WCAG 2 and we discuss the perils of blindly following conventions.

Download this show.

Launch our podcast player

News and events

IE testing made easy

Testing in Internet Explorer is horrible for many reasons. Not least the fact that you cannot run multiple versions of IE on a single operating system.

In the past there have been a number of solutions to this problem. There were standalone versions of IE. However, it quickly became apparent that they did not behave as IE does natively. There are online services which provided screenshots of your site in different versions of IE. However that does not give a sense of whether interactive elements were working correctly.

The only really feasible solution was to run multiple operating systems as virtual PCs but this was slow and inconvenient.

However, it looks like things might be about to change. DebugBar have just released IETester. A free web browser that allows you to have the rendering and javascript engines of IE8 beta 1, IE7, IE 6 and IE5.5 on Vista and XP all at once.

They are currently describing it as Alpha software (whatever that means), so it sounds like it is still a work in progress. As with any such software it is hard to know if it is accurate. If you do choose to use IETester, I would still recommend giving your site a final once over in native copies of IE before making it live.

That said, this does look very promising and I will be trying it out myself very soon.

Hosting your Javascript libraries

Our next story is an announcement from Google. They have started to host the main Javascript libraries including…

jQuery
prototype
script.aculo.us
MooTools
dojo

This means that if you are using a Javascript library it does not need to run from your own server, but can pull it directly from Google.

“Why would I want to do that?” I hear you cry. Mainly to improve performance. First, according to people much cleverer than myself the Google servers are faster and can deliver libraries much quicker. I know little about server performance so I will have to take their word on this.

However the main reason is that if enough web developers use this approach we will see a significant caching benefit. Lets say a user visits headscape.co.uk and this site pulls its jquery library from Google. Boagworld.com does the same thing so when the user visits that site it uses the cached version (from the visit to Headscape) rather than re-downloading it again. As more and more sites pull their Javascript libraries from Google the likelihood that a user already has a cached copy of that particular library increases.

Of course allowing Google to host your Javascript does require a level of trust. What if Google goes down? What if Google turns evil and starts using Javascript to manipulate your site? What about the data this approach gives Google about your site?

However, if these concerns do not worry you, then there are definitely tangible benefits.

Prototyping website interaction in flash

Next up we have a tutorial demonstrating a quick and easy way to prototype complex website interactions.

In some ways the static Photoshop comp is becoming less useful. Modern websites have numerous interactive elements that are hard to convey through static images. There is a need for something that can demonstrate this functionality.

We have spoken before about wireframing interactive websites, but not how to demonstrate changes in visual look and feel. This article on boxes and arrows suggests that Flash maybe the answer.

The advantage that flash has over something like a clickable PDF is that it allows for easier updating when the client wants to make changes. However, it does require basic Actionscript skills. Fortunately, the tutorial talks you through these step by step and none of it is too challenging.

If you are looking for a way to better demonstrate interaction in your design comps then this might be the answer.

The rule of thirds

The final news story today is another post from those lovely people at Smashing Magazine (we love them since they said nice things about our podcast!) The article entitled “Applying Diving Proportion To Your Web Design“, introduces the reader to the fascinating subject of the golden ratio (also known as the divine proportion or rule of thirds.)

If you haven’t come across this principle before then I highly recommend reading more. The rule of thirds emerged in the Renaissance but has always excited in nature. There seems to be something inherently pleasing about these proportions and they occur again and again. There is something about human perception that is naturally drawn to this composition. We can use this to our advantage when designing websites.

The article goes on to demonstrate how the golden ratio can be used in all aspects of design from photography to web design. In particular it focuses on the benefits this can provide to the grid structure of your sites.

Admittedly if you have not come across the rule of thirds before this can all sound like hocus pocus. However it really does work. Following principles like this can dramatically improve your designs. What is more they can be followed by anyone even if you would not consider yourself a designer.

Feature: Defying Conventions

As the web matures an increasing number of conventions are emerging. But should we always follow the crowd? In this weeks feature we discuss just that.

Interview: Patrick Lauke on WCAG2

Paul: So joining me today is Patrick Lauke from splintered.co.uk, is that best way to refer to you?

Patrick: Yeah, it’s one of my many monikers, yes.

Paul: Just so many presence on the web, you’re just so well known. Good to have you on the show, Patrick, it’s been a while.

Patrick: Thanks for having me.

Paul: I don’t think you’ve actually been on Boagworld before have you done Dot Net with me, but I don’t think you’ve done Boagworld.

Patrick: Exactly, yeah, I’ve only had the pleasure of sitting on the Dot Net one.

Paul: Well this is the proper grown up, you know, professional version compared to Dot Net.

Patrick: Super!

Paul: So the reason I wanted you on the show, Patrick, I have to be honest is as much for me as it is for my listeners this time round, because you are our resident accessibility expert, and we had a conversation a long time ago on the show about WCAG2 and we talked a little bit, not with yourself but we’ve talked on the show before about WCAG2 and it was coming along and all the rest of it, but it suddenly occurred to me we haven’t done anything on it for ages, and I’m wholly ignorant on the subject and the current state of affairs, so I thought, I know, I’ll get Patrick on the show, I’m sure he’s bothered to read it and knows what’s going on. Hence you’re here.

Patrick: Excellent.

Paul: So you’re not going to let me down, you have actually read WCAG2 have you?

Patrick: I have, I’ve been fairly involved with it, yeah.

Paul: Good! That’s encouraging. OK so perhaps the best place to start is, where’s it currently at, what’s the stage of development at the moment?

Patrick: Right, well literally a few weeks ago it entered what’s called the Candidate Recommendation Stage, all part of that W3C terminology they use. It wasn’t…it has been in last call for about 2 years now, but yes, Candidate Recommendation really means that now the WCAG working group and the general public has been kind of sending in comments etc on the status of the document. They’ve all reached kind of a broad consensus about, yeah, it’s fairly…it’s pretty much there, you know, it’s fairly accurate, technically there’s no big howlers in the actual wording of the things. I mean there might still be a few minor, minor details that change from now until the end, but pretty much the actually core of it is as good as it’s going to get.

Paul: OK.

Patrick: And really the…kind of the purpose of this Candidate Recommendation Stage, you know, why aren’t they going straight out and releasing this now as a standard, is really to give people an opportunity to start test driving, you know, what WCAG2 says in its current state, so working group thinks it’s pretty much there, let’s test it out actually in the real world, so give people the opportunity to run it…run their websites through their paces according to WCAG2, see if, you know, things are feasible, if it’s realistic to kind of say, yeah, this will be the standard from now on, and they’ve actually…they want to make it quite official, so if you have an intention of kind of doing that, you have a website and you want to actually officially say, OK, I’m going to use that website to test WCAG2, they’re now asking for people to basically register their interest and to actually, you need to then implement that, you need to say, right, I’m going to run WCAG2 on my site and by the 30th of June you want to be able to basically say right, I’ve finished it, and then give feedback and basically say yeah, no problem, or you know, we tried and tried, but this is actually not realistic, it might need to be modified, but unless there are major, major issues that come out in the wash as people are now trying to implement it and test drive it, it should be fine really. One of the main things with WCAG2 is, as with any kind of Candidate Recommendation documents, is really that there are a few items where even though we’ve got consensus, the working group isn’t 100% sure that they’re going to make it in their current stage, so they’ve kind of gone very ambitious with some of them, but they realise that yeah, it might not actually make it through, and they’re called….quite fittingly, items at risk, which in the latest CR document, Candidate Recommendation document, they’re clearly marked, and they’re basically…the testing phase is really about, let’s have a look, specifically these kind of items at risk, can they actually be implemented in the kind of more stringent way that we’ve worded them? If not, we might have to scale them back. I mean there’s one for instance where it says, it talks about, you know, colour contrast, and they’ve worded it currently that the contrast needs to be on a ratio of 5:1, so if you’ve say got, you know, text and background colours, you need to have…want to do your calculations for the various algorithms, there needs to be a contrast of 5:1. Now they’ve put that at risk, because some people still felt that it might be a little bit….setting the mark a little bit too high, and they were already saying, OK, well if it turns out that it is too ambitious to say, right, you need to have that ratio, that they’re happy to kind of jump back to 4.5:1 or even 4:1, so it’s kind of things like that, we’re really now at the nitty-gritty stage with these kinds of things, of saying, you know, can it actually be implemented.

Paul: So this is getting very close to the point where, you know, your average website owner and your average web designer needs to be…we need to be looking at this now, don’t we really? I mean we’re getting that close?

Patrick: Yeah

Paul: OK, I mean it sounds like things have gone a long way since the kind of early stages where WCAG2 was quite heavily criticised. I mean what kind of shape do you personally think it’s in at the moment?

Patrick: Yes, I mean looking back, I think it was May 2006 where Joe Clarke wrote his kind of vitriolic post, to Hell with WCAG2 on A List Apart, we have definitely come a long way since then. I think it was a good wake-up call back then for somebody like Joe, somebody of Joe’s stature, to really come along and, where web designers maybe at that stage weren’t really that interested in WCAG2 to actually say, look guys, you need to start looking at this because in the current shape it’s in, it’s really not feasible, and what Joe said at the time, there are many things that he criticised, but you know, overall he was spot-on with a lot of the things. The main thing was that the whole document at that time was extremely bulky, it was one big monolithic document which tried to do everything. There was loads of Orwellian-style language, everything was made up of Newtons, and they pretty much invented…because the problem with WCAG2 it’s a kind of full shadow of it, is that because it tries to be technology agnostic, it tries to avoid in the main document and talk about anything relating to actual technology, so it doesn’t mention specific HTML elements or things like that, so to make it very tech-agnostic, that document at the time really re-defined almost anything, so it didn’t talk about web pages, but it started ta
lking about web units, and basically the glossary was almost bigger than the actual document, so you know, that was very problematic because even people who’d been doing web development for years, if you just gave them the document as it was, they would have had to completely re-learn whatever all the terms were, it was of no practical use.

Paul: So has all that gone now?

Patrick: Yes. The language has been simplified. I mean it’s gone now from 2006 onwards it’s gone through, I think it was 2 or 3 last call stages. Well it went back from…in 2006 it was at last call stage, literally the stage before we’re saying, OK, we’re up to Candidate Recommendation. They actually scaled that back. W3C don’t admit that was because of Joe Clarke, and OK, it was probably not exclusively because of his article, but I think the general kind of feelings that it stirred up, or that it tapped into, kind of made the W3C reconsider. They’ve scaled it back to a public working draft, which is kind of one step previous to that. Everybody had a pretty good look at it. There’s been rounds and rounds of comments, I mean I’ve submitted in the 2 year period that it’s now been since that article, I’ve submitted loads of comments. I mean ranging from really small things like, oh you missed a comma there, or that’s not very clear, to kind of very substantial things about the actual core concepts that are being discussed, and in that process, a lot of really hard copywriting and editing has happened since then. They’ve also split out the document into far more manageable sub-documents themselves. One of the main things, for instance, is that the whole structure of, you know, WCAG2, it’s actually a suite of documents. The main guidelines document itself is only a handful of pages, I think it’s…yes, 19 pages I’ve printed out today. That is purely the core guidelines document, and that’s the only part if you will, that is actually normative, that’s the only one that is the actual guidelines. Then there was a lot of extra documents that really are just what’s called informative, so you can read through them, but you can’t actually refer to them in terms of, you know, just if somebody sort of says, your site isn’t accessible, you can’t point to an informative document and say, yeah, but I’m following that particular thing.

Paul: OK

Patrick: One of the documents will be the techniques document. You can’t actually point to that and say, well I’m following these, because the only thing that’s important are the actual guidelines, so they’ve really slimmed it down, broken it up into separate documents, you know, 19 pages printed out, it’s nothing, you can pick that up, you can read it through. It’s roughly the same size now of WCAG1 if you will. So they’ve simplified the language. There were loads more contentious kind of fundamental problems with WCAG2 as it was back in May 2006. I mean one of the main ones that really caught, you know, the eye of a lot of developers, was the concept of base lines where basically at the time they were saying, even though the concept itself is good, but it’s pretty much read like, as a website owner I can basically say, right, to work with my site, you need to have Flash and you need to have this and you need to have that, which was completely opposite to, you know the very austere WCAG1 which basically said, you can’t have anything. This seemed to open it up completely and allow for website owners to basically say, right, you know, we are going to do a whole Flash website if you will, and our baseline will be, you need to have Flash to use this site. But the concept was good at the time, but the wording pretty much came out like that, so these kinds of things, base lines, at its core, is actually still in the current document. They’ve basically re-worded it and turned it on its head, where before it was talking about website owners can say what technology they’re using, now it’s far more, if as a website owner or designer, I’m using a technology, I need to make sure that I know for a fact that it’s supported by accessibility…assistive technologies, for instance screen readers, so they kind of turned it on their head. The onus isn’t any more on the user to say…to have the latest technology, but on the developer to make sure that the technology they use needs to be accessibility supported. So loads of kind of fundamental changes like that have happened really, and no, definitely to go back to the original question, it has improved quite dramatically since May 2006. I mean I’ve now familiarised myself extensively with it. It’s good bedtime reading material!

Paul: You’re not convincing me of that one. Not unless I want to go to sleep I guess!

Patrick: I know. OK, I’ll be blunt, it’s better toilet reading. You kind of print it out and you put it there, instead of a novel you’ve got that there. But it is very good. I mean it’s now down to the level of…it almost reads like common sense. You kind of…you go through it and you just find yourself nodding and thinking, like, that’s not contentious. OK, there are still a few here and there where I might slightly disagree in a heated argument, but overall there’s nothing really there that makes me think, ooh no, that’s never going to be realised, so absolutely, it’s in very, very good shape I would say, and this Candidate Recommendation Stage looks like it’s going to be very successful really, and fingers crossed, I think; I’m not 100% sure now of the timeline that W3C are working by, but I wouldn’t be surprised if, say by the end of calendar year, we might see actually WCAG2 being released and getting out and becoming a proper recommendation.

Paul: Cool. So then what’s the big differences from WCAG1. I mean with WCAG1, you know, every kind of standards-based designer became very familiar with that. I was a great fan of that, you know, single sheet which listed everything by priorities and I would go through and I’d check myself off, and I kind of knew where I stood with WCAG1. With WCAG2, it’s much more of an unknown entity at the moment, so kind of give me the potted version. Where are the big changes?

Patrick: Right. No you’re quite right, it’s actually a lot more vague WCAG2, but it’s that way for a reason. Right, so WCAG1 really was very much, I mean it’s a product of its time, I mean it was 1999, the web was still quite in its infancy, and it is very much HTML focused, WCAG1, there’s no denying that. There’s a few mentions of things like CSS, but pretty much it’s all about how to use HTML to create content that at the time would be deemed accessible. I mean JavaScript was pretty much bad; I mean you could use it but you need to make sure there’s a fall-back. Non-W3C technologies were completely out basically, unless you provided a W3C alternative, so things like Flash and PDF etc, when they first started becoming more and more used, that directly clashed with WCAG1 at the time. Now WCAG2, as I mentioned before, it’s far more tech-agnostic. It tries to basically not t
alk about specific technologies. It doesn’t directly reference HTML or CSS or Flash or Flex or various other things in the actual core guidelines. Now the reason for that is WCAG1 as soon as it was released, the thought behind it was that it would be updated on a very regular basis, but from 1999 onwards, nothing has really happened, and because it was so heavily influenced by the technology of its day, it aged very, very badly. I mean nowadays, if I hear people saying, we’re building against WCAG1, I almost have to chuckle a bit, because it is pretty much just going back to, you know, we’re doing the web like it’s 1999, you’re not really allowed to do anything, and it’s completely opposite to what’s actually happening with the web. I’m not going…well I am going to say Web 2.0 to sound all trendy, but you know, all those things, Ajax, Flash, PDF etc, particularly say PDF, there is now…there are now easy ways, or relatively easy ways, to create reasonably accessible PDFs, I mean the technology itself has moved on, the format has moved on, screen readers are quite capable of dealing with well-structured PDFs that are created in a certain way. We’re not really talking about, you know, you need to test your pages with links because, you know, people might just use a text only browser. Things have moved on, but WCAG1 is pretty much kind of frozen in time of 1999. There have been a few kind of…people who’ve been working towards WCAG1 have started kind of re-interpreting it a bit for the modern days. I mean in my own practice in my…one of my other identities, in my day job as web editor for the University of Salford, I’ve never actually said, we’re going to make our pages WCAG1 compliant, but always said, you know, we’re going to take inspiration from WCAG1, filter it through our own knowledge of what the technology landscape actually is today, and try to do the best we can to actually serve the users and you know, how they currently use the web.

Paul: So….so are you, you know, you said that you’d never claimed in your day job, you know, to be WCAG1. Are you intending, you know, are you more confident in WCAG2 to be able to say that, that we’re going to be WCAG2 compliant, or is it not that kind of thing?

Patrick: I think …I think yes, WCAG2, it would be a lot easier to say we’re working towards WCAG2, because to kind of go back a bit and explain WCAG2’s kind of…the thinking behind WCAG2 and how it’s structured. WCAG2 as I said, doesn’t talk about HTML, CSS, it really just sets out very general principles, when then break down into guidelines, which then in turn break down into success criteria. Now again it probably sounds like there’s a whole new language to learn, but it is fairly straightforward, so if you think, web pages themselves need to be the four principles. They need to be perceivable, operable, understandable and robust. So those are the four kind of guiding principles, which you know, make sense. It was already implicit in WCAG1, but this kind of just spells it out. These are the kind of four things that we want to make sure. Now under each of those principles, say perceivable or whatever, there are guidelines which still provide…they don’t go into detail, but they provide some very, very basic overall goals, so what we want to achieve is X. They’re not testable, because they’re still very, very generic, they’re saying, we just want to make sure that people can, say, use a keyboard to do things. They don’t go into detail about what that means particularly. And then under that you’ve got the testable, what are called success criteria. Now these are very small kind of little atomic sentences if you will, that say, right, very specifically, if you’re providing this, then make sure that that happens. Now I’ll pull out an example, I’ve made some notes here, let me just go through…yeah, I’ll give you an example here. So in the big WCAG2 document, you’ve got principle number 2, operable. User interface components must be operable. So, you know, you can’t argue with that, fair enough. Underneath that, there’s loads of guidelines, I’ve pulled out one here, guideline 2.4, navigable, which states that you should provide ways to help users navigate, find content and determine where they are. Again, that’s a very, very broad goal that doesn’t say anything about you need to use a link, you need to put title in here, or you need to make sure you use access keys. None of that. It basically just very generically tells you that. Now under Guideline 2.4, there’s loads of smaller success criteria. Now I’m just going to pull out one of them. The first one, 2.4.1, which basically is called bypass blocks, and I’m just going to read it straight from the thing, ‘a mechanism is available to bypass blocks of content that are repeated on multiple web pages’

Paul: Yes

Patrick: Now again, this doesn’t say anything about HTML or whatever, but it is quite testable. You can actually pull up your web pages and say, right, are we following this? Is there a mechanism available to bypass blocks of text, blocks of content, sorry, that are repeated? So I don’t know if that gives a flavour of…

Paul: Yeah it does.

Patrick: …against WCAG1. Now you couldn’t write a validator to actually just run through this and check for that, that is one of the core differences I think with WCAG2 compared to WCAG2. I mean even WCAG1 we all agreed that you can’t just run it through Bobby and then, you know, if Bobby gives you the thumbs up, that’s good. You still have to do some manual checking. But there were a lot of things that because it was so HTML-centric, you could pretty much run it through something and it gave you a fairly good indication of whether you were achieving that particular check-point in WCAG1 or not. Now the way the success criteria are worded, yes you could say, OK, if we accept that, we want a skip link, and the skip link will fulfil that particular success criterion, we could write an automated tester that just looks for skip-links, the presence of skip-links, however you want to code that, but it’s not to say that that is the only way in which you can pass that success criterion. The actual guidelines don’t say exactly what you’re supposed to do. They pretty much focus on the end result and particularly what I’m interested in, they focus on the end result for the user for the most part, so it really puts the onus on the developer to understand, these are the user needs, and this is the kind of very generic thing that needs to happen. You can then, from that success criteria, jump over to the techniques document for instance, which actually goes into detail, if you’re using HTML, here’s some of the ways in which you could achieve this success criterion, and then you can test against those, but the techniques document is only informative, it’s not the be-all and end-all. You could follow whatever’s said in there, or you could actually come up with something that’s completely separate, is not mentioned anywhere in the techniques, but if the end result of an actual real user is still, OK, they can still bypass blocks of text that way, then that’s fine.

Paul: Which is great, because it kind of gives people the freedom to innovate and come up with original ways of solving accessibility problems.

Patrick: Absolutely, and it puts…it puts the focus straight back on doing something that is good for the user, rather than right, we’re just going to go and make sure that we tick that particular box because the guideline says we need to do X in HTML and, well, we’ve done it, so we’re cool. This kind of forces you to actually think about solutions. I mean you can… you can go into the techniques document, and what’s mentioned in the techniques document, is pretty much they’re tried and tested ways in which that situation has been solved, so you know, you can be I’ll say lazy, but you know, you can get guidance from that techniques document, but that’s the important thing to know, is it doesn’t mean that you have to necessarily use one of those techniques, and absolutely you’re right, this will stimulate a lot more creative kind of ways in which these success criteria can actually be met. And as I said, it then applies to any technology. You could say, right I’m going to provide that functionality in Flash if I’m doing Flash, or maybe I need to do that in PDF, or whatever, so it is a lot more open. Which obviously is a problem if you’re very set in the ways of I’m going to run it through a validator, and I’m going to get a clear yes or no answer, because you pretty much need either a lot of user testing to say, OK are the users actually able to do this particular thing that the success criterion says, or you get experts that kind of help you with that, and there it’s a lot more likely that you’re going to get 2 or 3 experts and they might not necessarily agree on what’s the best way to implement something, so that is kind of…not the problem I would say, but the slight shift in mentality that website designers and website owners will have to make, that it’s less easy to make a very kind of cut and dried, yes it’s accessible, not it’s not accessible. I mean it was problematic before, now it could be even more woolly, which you know, is a bad thing in a way, but also a good thing because it does force you really to focus on the actual core of the problem rather than trying an easy way out and just implementing some mark-up that a guideline suggests.

Paul: Yeah, I mean yeah, I can see how it potentially might create some legal problems further down the line, but it certainly gets people beyond that kind of arse-covering check-box mentality, which has good to be good. So it sounds like a lot of the time we’re kind of going to be working as web designers on the success criteria level where we’re going through and making sure we conform with these various success criteria. What about priorities? WCAG1 had Priority A, AA, AAA or whatever you want to call it; Priority 1, Priority 2, Priority 3. I mean, did, you know, is there anything like that any more or has that gone away completely?

Patrick: No, that’s actually still there. At one point there was a bit of a change in terms of how it’s going to be worded, whether you could achieve full compliance or not by following…having to do all the success criteria for a particular level or not, but no, they’re pretty much there in their old form if you will, so it’s still called Level A, AA and AAA. One of the things that WCAG2 has tried to do in its wording of these Levels is to say that it wants to remove the kind of idea of hierarchy that AA aren’t less important than A, and AAA aren’t less important than AA. They’ve written a lot of nice words around it to explain why it’s actually still worth doing AAAs when you’re not fulfilling all of AA etc, but I think they’ve actually muddied up the waters a bit because in effect, you can’t claim, say, AAA, if you haven’t claimed AA, so the hierarchy is actually still there, so probably this explanation was quite confused, but it actually reflects exactly how confused the WCAG2 document is about that. They’ve tried to kind of have their cake and eat it at the same time, I think, because they have to…necessarily have some hierarchy, but they’re really trying to stress that they’re all equally important, you know, but some are just more important than others. So…interesting.

Paul: Yes. So I mean what, you know, we’ve got potentially, you know, if you’re right, until about Christmas to sort out our act and to kind of really get thinking about WCAG2. What kind of steps would you recommend for people that are owning and running websites in order to kind of prepare for this?

Patrick: I would say that because WCAG2, as I say, is a whole suite of documents, you’ve got the actual guidelines which I mean now I can read them and they’re quite understandable to me, but I’m obviously very close to the subject at hand. I can kind of understand where they’re coming from. But as part of the suite of documents, there are kind of better documents possibly to start with, depending on what your current level is. There are ….there are simple things like Understanding WCAG2, which kind of takes a helicopter view of WCAG2 and gives a lot more context that explains why, you know, certain guidelines are important, how, you know, people will use them, how they will benefit from them etc. It goes more of a context. It’s obviously a lot weightier than the actual core guidelines, but that is…if you’re a bit rusty with, you know, I haven’t looked at WCAG2 at all, you’re a bit rusty with what WCAG1 even was about, beyond just being a document that you checked some boxes against, that’s certainly worth reading, just to really get a feel of understanding why….why are we changing things, why wasn’t WCAG1 good enough, so that really gives you a good kind of introduction to the subject. And I think that’s an important step towards actually implementing WCAG2 would be for people to buy in, as with anything, if you’re trying to push it through at an organisational level. People need to understand the rationale behind it. You can’t just dump this document on say your developer’s desk and say, right, these are the new rules, you know, white is black, black is white, this is what you need to do now. They need to buy in from actually understanding what the rationale behind it is, so the understanding document will really give them all the information they need. Some, you know, technically minded people might be tempted to jump straight to the techniques document, which is fine, but again with the caveat that I mentioned before that the techniques document is actually only informative, so whatever’s written in there is not the law. Some techniques that are currently in there might even be proven later on to be maybe not optimal in certain situations etc, so it’s not the law; it can help you initially get, if you’re really technically minded, you might read the success criteria and say, yeah, OK, that’s all nice language, but what does it actually mean, you know, if I’m doing HTML, what….what are you expecting me to do? The techniques document can help, it will give you actual examples. If you’re using HTML do this, if you’re using Flash do that, etc, so it brings it back down to something that as a techie, you might be more comfortable with, but again, understand
ing that that is not the law; those are not the guidelines, and that there might be even better or more creative ways around the problems, but it’ll get you into the right frame of mind I would say.

Paul: Cool

Patrick: There’s also documentation that just pretty much compares WCAG2 to WCAG1,

Paul: Ah, that’s good

Patrick: Yeah, if you’ve got a lot of experience with WCAG1, that will kind of help you roughly map, you know, what used to be WCAG1’s check-point about this, is now this far broader guideline that covers a lot more aspects, so it’ll help you kind of move towards the thinking behind WCAG2. And I think that is the main thing as a website owner or as a designer; it’s more of a shift in perception if you will, more of a shift of understanding of what accessibility is, more than, you know, the change of how is my mark-up now going to be affected by it. It’s really moving beyond that kind of very HTML specific, you must do exactly this, to a more, you need to understand how users actually use your website and how to creatively kindly of help them in that pursuit really.

Paul: Cool. I mean that sounds good; there’s lots of different ways you can kind of start the process of learning it

Patrick: Absolutely

Paul: …which is good. I mean I guess my last question, you’ve almost kind of answered, which is, you know, if you’re somebody from a WCAG1 background that is comfortable with WCAG1, the one thing that you’re thinking is, hang on a minute, I kind of knew this, I had my head around this, you know, I’ve suddenly got to change to this new system, you know, is it going to involve more work, is it going to be painful? The fact that you’ve talked about this document that does transition, you know, between WCAG1 and WCAG2 sounds helpful. Overall, do you think it’s going to put more pressure on designers or is…more going to be expected of them as they develop stuff?

Patrick: I think it’s going to be interesting for a variety of reasons. I wouldn’t say necessarily there’s going to be more work involved. If you’ve been working similar to the way I’ve been working, that you take WCAG1, you take what you want from it, and you filter it through your knowledge of, yeah, that screen-readers can actually work well with PDFs, so I’m ignoring the non-W3C technologies I’ve banned that used to be in WCAG1, so if you’ve actually been doing accessibility based on WCAG1 in the real world rather than simply just following it as a set of check-points that you just tick the boxes, I wouldn’t say it’s going to be more work. Certainly if on the other hand, if you have been somebody who hasn’t been too understanding or involved with WCAG, you pretty much had it as a function in your, say, Dream…copy of Dreamweaver or whatever, I’ll just quickly run it through this validator, I’ll run it through Bobby, although Bobby’s now gone, thank God, various things like that, you know, if you really just saw it as a check-box exercise, yes there will be…it will be more of….I don’t want to say paradigm shift…well there you go, I just said it….absolutely, no cliché will be left unturned in this particular episode…you really need to start understanding it more. But if you’ve actually been doing what I would term in a quite elitist way, real web accessibility over the last few years, there’s no major, major big surprises there, and there’s…I wouldn’t say there’s a lot more work involved. Now it would be interesting, I think, one of the aspects will be if you’ve been working in an organisation and you’ve been trying to appease management say, and one of the things that management might have erroneously picked up is, we need to make sure our pages are Bobby-compliant, for instance, is that will be a difficult, I would say, or challenging, should we say, situation because you will have, already at the time you might have been crying, saying, well, the validator can’t check everything, you still need to do manual checks, but at the end of the day, some managers, all they wanted was to see the thumbs up and the smiling policeman with the helmet on their website. This time around it will be a lot more difficult, and yes, as I mentioned before, there will be automated tools that will help you in determining whether you’re doing certain things right according to WCAG2, but because, as I said, the techniques…there is no definitive list of techniques that are OK, and there are no definitive lists of techniques that aren’t OK, it’s practically impossible to write an automated checker that will be able to check against everything, so tools…automated tools will really just be relegated to certain interpretations of WCAG2. I know that there’s a few organisations in the States that are currently working on, you know, validators. I think the….name escapes me now, but the Fraunhofer Institute in Germany, they’re currently working on their own version of a WCAG2 accessibility tester for instance, and I had an interesting discussion with representatives from Fraunhofer the other week when I was in Germany at a conference, and they’d pretty much agreed that their tool will only check against, basically, their favourite techniques if you will, from the techniques document. Now who’s to say, as we said before, that those are the best techniques? They’re ours. You might come up with a really creative way that no tool has been primed to kind of sniff out in your mark-up or in your Flash or PDF or whatever, so you’ll always get a very, very subjective, based on what the developer’s written into their tool, very subjective assessment of your website, so bring it back to the point, it will be extremely difficult I think for a manager to be able to say, right, I just want to make sure that we pass that particular test, unless you then go and dig out exactly what that tool is looking for, and you end up back in the situation that we used to be in, where you’re trying to write it to get a good grade from a tool, rather than actually thinking about what is best for, you know, users with disabilities or users in general, so that, I think that will be the more challenging part, as I said, the paradigm shift, getting managers who might not have understood it up to now, to really kind of confront the fact that automated tools aren’t the be-all and end-all, and that yes, everything is a lot more subjective now, so really I would say the only solution to that is really start thinking more exclusively about proper user testing, getting actual end-users in there. You could give them the success criteria from WCAG2 and basically say, can you confirm that this is something that you can do on our website, so it becomes a lot less about automation and a lot more about actual end users.

Paul: Cool. I mean it all sounds really exciting, you know, a bit apprehensive, you know, a whole new thing to learn and all the rest of it, but I think the whole freedom of approach side of things, that you can approach problems in different ways and sold things in different
ways, is very refreshing and it all sounds really exciting. Patrick, thank you so much for coming on the show, that’s been really enlightening, and I look forward…

Patrick: a delight

Paul: Yes, and I look forward to getting you on again, maybe to get into some specifics once WCAG2 is up and running. Good to talk to you.

Patrick: Yes, super duper. Okey-doke.

Thanks to Alison “Anna’s Mum” Debenham for transcribing this interview.

Listeners feedback:

What are the key features of a CMS

Hi Paul. Hi Marcus. What in your opinion are the important and fundamental features of a CMS, not such as the ability to create pages, but the add-on features that make a CMS better than other CMS’s around it. Thank you very much for answering my question.

Interestingly Drew Mclellan was talking about content management systems at this years @Media. He had an excellent list of things to look for in a CMS. Some of his recommendations were…

Friendly URLs
Data Feeds(RSS)
Customisable and accessible administration interface
Well implemented search
Multi-site support
Multi-language support
Caching
Support for user generated content

Interestingly some of the features he looks for (such as friendly urls) are not always required. He wants to see them there because it indicates best practice from the developers who built the system, not because he actually needs them.

He also spoke in his presentation about the importance of not buying a CMS based on a wish list of functionality you might need one day. This will lead to unnecessary expense. It is also the problem with ‘off the shelf content management systems’. You end up buying functionality you don’t require and introducing additional complexity into the user interface. Perhaps that is the reason why both edgeofmyseat.com (Drew’s company) and Headscape have chosen to build their own CMS codebase, which can be customised to clients needs.

If you are looking for more information on the selection of a content management system be sure to check out episode 24 where we dedicate the entire show to the topic.

Is certification worth it?

Chris asks: I’ve been working in web design for the last 5 years and am really looking to get into the more user experience side of things. I was wondering if you or our listeners knew of any qualifications or certifications that might be a good idea. Are they even worth the good idea in the first place or are they not worth the paper they were written on?

As somebody who regularly recruits user experience designers I have to say that qualifications and certifications mean little. Sure, I like an employee to have a degree simply because it demonstrates a certain level of academic achievement. However, I don’t think that web specific qualifications count for a huge amount.

What I consider important is example work, that shows your skills in user interface design. I want to see sites you have produced and for you to explain to me the underlying thought process that went into them.

Given a choice between work experience with a high profile web agency or becoming a student again, I would recommend the former every time.

113. Hiring

Posted in Classic shows on February 27, 2008 by Paul Boag

On show 113: Christian Heilmann on common Javascript mistakes. Marcus talks about hiring new staff and Paul shares his journey into screencasting.

Podcast: Download (29.9MB)

Download this show.

Launch our podcast player

News and events | Hiring new staff | Christian Heilmann on common Javascript mistakes | Listener emails

A quick request. We are really in need of some more transcribers to help with the interviews we do every week. The team we have are doing an amazing job but it would be great to spread the load.

If you feel you could help once in a while please drop me an email and I will add you to the list.

News and events

Highly extensible CSS

A while back Cameron Moll released a tantalising screencast of a seminar he was running on Highly extensible CSS. Website today need to be ultra-flexible, dealing with changing content, multiple devices, and user customisation. Cameron’s presentation aimed to teach designers and developers how to build interfaces capable of adapting to the unforeseen.

Unfortunately, I didn’t get the opportunity to attend. I was therefore excited to discover that Cameron is about to cover the same subject in a series of four posts on his website, all for free!

So far he has only posted the introduction. However I am really looking forward to the whole series. For now just check out the screencast and see if it excites you as much as it did me…

Video tools

Talking of screen casts I have actually been working on several myself at the moment. We are in the process of redeveloping the Headscape website and have decided to include a couple of demonstrations and presentations.

This means I have been in research mode and I thought I would share what I have found. Firstly, I have discovered a great screencasting tool called Screen Flow. This Leopard only software stands head and shoulders above anything else I have tried on either Windows or the Mac. It is amazingly easy to record and edit your screencast and has some great built in effects. My favourite feature is that it will capture from both a web cam and the screen at the same time. This allows you to cut between video and the screen or even overlay a video feed on top of the cast.

Once I had recorded my video I started to look for somewhere to host it. Although I would be foolish not to put it on Youtube where it will get the most exposure, I didn’t want to use Youtube when embedding on my site. The quality on YouTube is poor and you are limited over length and size. With this in mind I looked at a number of competitors. The winner for me turned out to be Vimeo. The quality is superb, they are much more flexible over length and time, but most of all they provide links to the original file and allow you to customise the interface.

So, if you are looking to create a screencast I highly recommend Screen Flow and Vimeo. Also, if you are looking for tips on how to make an engaging video then check out Ryan Caron’s tips over at Carsonified.

Microformat boost

The last thing I want to mention in this week’s news segment is the growing interest we are seeing in Microformats recently.

For a start Firefox 3 is going to have built in support for Microformats, which will be hugely significant in itself. However the guys over at Yahoo! are doing some interesting stuff in the area too. Yahoo! Micro Search is a new way of viewing search results that include all kinds of metadata including microformats. According to David Peterson at Sitepoint this could allow Yahoo to really challenge Google.

I am not sure whether that is true or not, but I do know it is a great time to start using Microformats. If you want to get started then check out Microformats.org or for you more advanced users have a look at this interesting demo of compound Microformats.

Feature: Hiring new staff

Marcus shares his thoughts about taking on web design staff for the first time.

Expert interview: Christian Heilmann on common Javascript mistakes

Paul: As I said at the beginning of the show, joining me today is Christian Heilmann. Hello Christian, how are you?

Christian: Hello Paul. Why it’s quite fun cause it’s Valentines day & I’m stuck with you as a date.

Paul: Well I’m sorry that you had to ah to endure me on Valentines Day but I’m sure you’ll survive. And um yeah… so basically, the reason that we’ve got you on the show today is we want to talk a little bit, a little bit about javascript. Now we’ve talked a lot of times about javascript before and it’s not a new subject, but I kind-of um… felt it would be worth touching on the kind-of common mistakes that we’re seeing a lot in the world of javascript at the moment. I think um… you know obviously javascript is very in and there’s load of cool stuff being done with it but not always in the wisest ways. Um… and then on top of that, so there’s this kind-of group of people that are doing quite advanced stuff with javascript with maybe not considering all the ramifications of what they’re doing. And there’s another kind-of group of people which are people like myself that go ‘Ewww… look at that, that’s cool I want to start doing things like that.’ And so you know a little, a little knowledge is dangerous as they say, and you know we’ve picked up books like Jeremy Keith’s scripting book and read that and now we think that we can, we can build javascript applications and are kind-of hacking things together. So I thought lets spend a few minutes looking at those, those kinds of issues. So um um… maybe probably a good place to start off if you don’t mind Christian is what advice you’d give to somebody starting to learn javascript so that, so that they kind of avoid some of these mistakes you know from the get go. What good principals, good foundations should they be working on?

Christian: Um… the main foundation is that javascript is a language in its own rights. It’s uh uh… you can not take any other knowledge and try to apply it on to javascript and this is where the two angles actually come where people that come from a higher programming language background trying to find the same principals that apply there inside javascript

Paul: Um hum…

Christian: Or people that come from CSS design background, basically think that it’s as easy as applying a CSS selector to an element that everything will be matched magically…

Paul: Yeah…

Christian: … and not realizing that there is an impact on speed and an impact on how the browser actually finds these things and what kind of mistakes the browser does. The main thing to remember about javascript is ah… there are many different ways of javascript, there are many different environments where it’s applied. So there is lots of really clever things being done right now with javascript, even on the service side and inside frameworks and inside API’s. But there’s also, in the end you would run it in a browser sooner or later. And if that’s where you are going to work the best advice is actually to not trust javascript ever and to actually um… enhance with it but not really rely on it.

Paul: Um hum…

Christian: So if there is a window print link, then this link should be generated with javascript and not just be an ‘href’ javascript window print because if somebody doesn’t have javascript or for some reason javascript’s broke, or the engine doesn’t work in your environment then you click the button and nothing happens. And there’s nothing worse than uh promising an end user something that you don’t deliver in the end.

Paul: Yeah.

Christian: The other thing is that uh… when you start from javascript, one of the first things to remember is that you should always learn the if statements and learn that they’re your best friend. Like never do: ‘apply something’ BUT IF ‘something’ THEN ‘apply something’. So if you…

Paul: Umm…

Christian: Try to access a heading with an ID for example, and then you don’t just do: HEADING ID ‘something’ = ‘something’… cause it might not be there.

Paul: Yeah.

Christian: So basically test for it, before you apply it. When you follow this principle through with all of your programming, this kind of defensive programming, then you will (we will) definitely write good javascript in any programming language really. Over the years when you get more and more experience you just learn more and more ways how the technology that you use fails…

Paul: Mmm…

Christian: …rather than actually succeeds. So you learn how to avoid the biggest pitfalls.

Paul: I mean, you always hear this thing don’t you about um… that not all browsers support javascript or that not all users have javascript turned on. I mean how real a problem is that? Is that being overly cautious to worry too much about that kind of thing or is it a real problem? Are there actually a lot of users out there that… that don’t have javascript for one reason or another?

Christian: It’s impossible to say. Its statistics and it’s a bit like flash. When you when you look at flash statistics and you hear like a 99% have it enabled on the Adobe side, then you’re like ‘Oh yeah really.’ because these are the only stats that you find…

Paul: Um hum…

Christian: …the company that delivers that is a bit like… yeah, I think that the Microsoft help pages with have a lot of hits from people with Windows.

Paul: Yeah.

Christian: So um… it’s not really a problem I don’t see the problem at all. I see the problem of people… uh, architecting and designing applications around the premise that javascript will be there, and everything will be happy and work.

Paul: Mmm hmm…

Christian: If you write your applications like javascript does not need to be there, but is nice when it’s there and actually makes it a lot smoother, then you don’t have a problem…

Paul: Mmm…

Christian: I don’t buy this whole argument of like… oh AJAX is so cool because we don’t’ have much traffic on our servers any longer. It’s like yeah, but you never know the environment that javascript is run in. It could…

Paul: Mmm…

Christian: …my mobile phone, it could be it could be an iPhone, it could be it could be an old browser. I just bought myself this eeePC that doesn’t have much memory. It’s uh… you can never expect the end user to actually cater their hardware to your needs…

Paul: Mmm…

Christian: So it’s pretty… it’s pretty unsafe to actually rely on it. So even if the statistics are ridiculously low, it doesn’t really matter because you don’t want to deliver a bad practice and deliver a bad experience to users.

Paul: Mmm…

Christian: And then there’s, of course, the SEO problems as well. If you have a navigation that’s dependent on javascript and doesn’t show anything – or you make elements clickable that shouldn’t be clickable, then you won’t have search engine spiders following these links and your sites won’t be indexed.

Paul: Mmm…

Christian: Same with accessibility. When you make something clickable that is not clickable by default, like a ‘span’ or a ‘div’ or whatever, then you can not expect a user agent actually to allow people with assistive technology or people that use a keyboard to use the same application because browsers are just not clever enough for that.

Paul: Mmm. So what about people, um… starting out as absolute beginners – what are the most common mistakes you’re seeing them make when they start out doing javascript?

Christian: A lot is copy and pasting and hoping that nothing breaks…

Paul: (Laughs)

Christian: …and ah… also um… a lot of it is skimming tutorials. A good tutorial writer will tell you a lot in the paragraphs between the code examples.

Paul: Mmm.

Christian: And um… just going through the code examples and trying to figure out what’s going there yourself and copy and pasting it does not really make you a good developer. This information was put there for a reason and actually explains you the smaller bits that you need to know about the language. ‘Cause most of the javascript errors that actually happen in the real world is not because you did a coding mistake, but because you made an application mistake that you expected a browser to do something. Or you expected an application to give you the right information back, where as you didn’t test for it. So um… I think trusting tutorials and uh… just copy and pasting code without actually knowing what it does is a very dangerous thing.

Paul: Mmm… Would you apply that same principal to frameworks? You know and not under… if you don’t understand what a framework is doing then it is probably best to avoid it.

Christian: Well it’s a matter of what it does. I mean uh… the last few years in web development have become a lot more transparent than before and that’s… Firebug is actually to blame for that.

Paul: Mmm…

Christian: It’s great because you can look at code that is generated by javascript or a backend application and you always know, you can always analyze the whole document ñ what’s doing on there if you know your Firebug. That’s another thing that I would actually tell any developer that would start with javascript to get his head around it’s like java… uh… Firebug is a great great way to learn from other people’s mistakes and also to monitor what’s going on in your scripts all the time. When it comes to library’s, that’s a bit of a different story because um… I had a bit of foot in mouth moment there when I proclaimed in the past that most library’s are bloated and unnecessary and um… now I am part of a library…

Paul: (Laughs)

Christian: …and uh I’m also I also talked to media AJAX to a lot of library developers and I realized that all the libraries do the same thing. All of them actually make the pain and the uncertainty that is browsers out there bearable for you.

Paul: Mmm.

Christian: So um… if you don’t understand what the source code of jQuery is, or the source code of the YUI is that does not mean that you shouldn’t use it.

Paul: Okay.

Christian: Other people have had that problem before you and loads and loads of people find bugs and submit bugs and help these libraries get better. So now a days if you are a new javascript developer I would basically say that you have learn the syntax, you have to learn the standards like what does DOM scripting mean, how does event handling work – but by all means if you go into a production please please use a library.

Paul: Oh okay.

Christian: Because that one take the cruft of all the fixing and uh… hacking that you have to do to make something work away from you.

Paul: Mmm.

Christian: It’s a matter of what you do. I mean if you’re doing a high traffic Twitter clone, or whatever, that runs an error application then you might have to these fixes – but you’re not necessarily going to do that as a new beginner.

Paul: Okay yeah… that that’s a very different opinion than I’ve heard in the past and it’s quite interesting to hear the other side of the argument. It’s good. So what about… what about dangerous people like me? So you know… where I knew nothing about javascript but I decided: ‘Yeah, I really need to learn this’. So I got a couple of books, I’ve read a couple of books and I’m kind of up and running but I’m not… you know I’m not a developer. I’m not somebody that’s an expert. You know… what other kind of common screwups you’ve seen people like me make?

Christian: Um… It’s tricky to say. It’s like most of the time, what these kind of people do is also try to solve problems that other technologies have with javascript.

Paul: Mmm…

Christian: Which is sometimes cool, but sometimes it’s also thinking about there’s a reason why that doesn’t work. So um… I mean the classic is… the classic is like rounded corners and things like that. There are loads of javascript rounded corner solutions which on the outskirt look like they are really clean solutions. This is also might be to put a class on a ‘div’ and to put a bit of javascript in and then everything has rounded corners and there’s no harm done.

Paul: Mmm.

Christian: That the javascript needs to inject a lot of HTML and probably is slow doing so. It’s the other side of the story it’s uh… I think people like you, that are just enthusiastic about it and basically want do it are not necessarily savvy of the implications that it has.

Paul: Yeah.

Christian: So the uh… the information that we need there is that we need a lot more tutorials on um… how javascript impacts performance. And we are starting with that already in the development network and other people are doing that as well, but there are lots of mistakes being done as well there. The other problem that I see with people that have just started with javascript, is they apply… they find one solution, they find one library then they become the biggest fan of that library then everything else is rubbish.

Paul: (Laughs)

Christian: And uh… that is a very dangerous attitude as well because you will not be, you will in your career work for different clients that will use different libraries as well. So you shouldn’t make yourself dependent on only one but understand what the benefits of each of them are and where you should apply them.

Paul: Um huh.

Christian: And how they actually make your life easier, or how they make your life less easy, than another competing product. So the implications there is that a lot of people use these newer libraries, or newer ways of using javascript, to actually make javascript behave like their favorite language or their favorite technology. That’s why people went nuts with every javascript library came up with the CSS selectors.

Paul: Yeah.

Christian: And that’s great because now I can go fifty levels deep in my CSS selector and the javascript finds what’s in there. While this is already an indicator that your HTML is not necessarily good structure

Paul: (Laughs)

Christian: …and it also means that if you change your HTML in the future you also have to change that path, or if you don’t change that path then your javascript will break.

Paul: Yeah.

Christian: And a lot of libraries break silently as well. So instead of just getting the error in your face that you’ve basically screwed up, you will not know what’s going on and will wonder what’s going on.

Paul: Mmm.

Christian: And when that happens that’s normally when people, like you, fire up emails to the library developers and tell them that their product is rubbish.

Paul: (Laughs) Yeah… I can’t disagree with that. That’s the kind of thing that I’d do probably. Um… what about, I’ll tell you the one thing that I’ve come across is that… I’m kind of competent enough to write functions to do a lot of the things that I need to do. Nothing really complicated, I couldn’t build anything too sophisticated, but you know enough to get me by. But then as I’m kind of looking at other people and what they’re doing um… a lot of them are using object orientated type techniques in the code that they are writing. There’s me hacking away with little functions and there seems to be some transition across object orientated approach when you kinda hit a certain level… you know why, what’s the benefits of that? Why do people take that kind of approach?

Christian: (Laughs) Um… It’s been very beneficial in other languages, and other environments, especially when the environment is rather sophisticated.

Paul: Mmm.

Christian: Then ah… you seen for example action script. Action script has been as much as a hacky javascript. Yeah, look what I can do if I do it this way language and now with the Flex frameworks, and Adobe opening up more and more to the java world, um… it’s getting more and more into structured ways. And the structured ways are hard to understand for somebody who is not from that background.

Paul: Mmm.

Christian: And I can safely say that, I’m not myself. So I um… I have a lot of problems with like properly, or massive structures, and frameworks. But when you see people do proper action script, for example, or do Rhino applications for the server in javascript, or some of the things that are happening with javascript 2… that there is a reason for that and the reason for that is the scalability is just so much bigger.

Paul: Right.

Christian: It’s uh… basically you can extend an object and I can reuse a class and I don’t have to worry about that. It’s like I start building these little small components, all of them in themselves tested and unit tested, and I know they work. And then I can build a bigger application from them.

Paul: Mmm.

Christian: Basically without really needing to know to test these things ever again.

Paul: Yeah.

Christian: That’s how things like PEAR and PHP and Perl libraries work as well. It’s people extending these kind of already existing bits, and bobs, rather than starting from scratch every time.

Paul: Mmm hum.

Christian: Most of the time for the little web development things that we do like the AJAX form or the Constentina navigation that’s not necessarily needed, but when you write a library for example, and it grows, like YUI is growing or like jQuery is growing as well… then you need to adhere to these standards ’cause otherwise everyone will just submit their own code in forms that are just terrible.

Paul: Yeah.

Christian: And there’s not much magic to it. I mean I get annoyed when I see javascript guys going on stage and saying like: ‘Well guys, this is a function and when it’s an object it’s a method and…’ and why should I know this? Well you should know this because you need to communicate with other developers as well sooner or later.

Paul: Umm hmm.

Christian: And these people speak that lingo and rather than you having to explain yourself for 15 minutes you could communicate in 3 minutes.

Paul: Mmm.

Christian: And that gives you more time for lunch break.

Paul: (Laughs) …or drinking…

Christian: So the worlds of hard core programming and javascript are actually getting closer and closer and seeing some of the things that browser vendors come out with and some of the other software that builds on web technologies that is being built at the moment, I don’t think that we can actually rely on our being the cool cookie web developer anymore.

Paul: Mmm.

Christian: It’s a bit like we have to have broaden our horizons the same way that backend people have to broaden their horizons when it comes to using javascript, but you can only make someone understand your problems when you understand how they tick.

Paul: Mmm.

Christian: Otherwise you start preaching to the choir.

Paul: Yeah. Okay here’s the last question to wrap up with. I’m going to open it up and let you rant uncontrollably. What are the worst mistakes that you’re seeing at the moment made with javascript, just generally.

Christian: Uh. The worst mistakes that I see are that people write little scripts for tasks over and over again.

Paul: Okay.

Christian: The same task and I see them actually tying the interface a lot to the javascript. So…

Paul: What do you mean by that?

Christian: Instead of making a javascript that actually creates the things it needs, there will be HTML that is just not necessary where the is not javascript available.

Paul: Okay yeah.

Christian: So instead of starting with the proper HTML and CSS structure, you basically have this whole gumph of HTML because there’s the javascript to clean it up anyways.

Paul: Yeah.

Christian: So um… basically the main tip is you will never ever be able to replace a proper HTML structure. It doesn’t matter where technology is going because technology will go away from that sooner or later, but at least a human could actually go there and see that there is a structure.

Paul: Mmm hum.

Christian: And that there’s a way to convert this to something better in a second step. If you’ve created a lot of spaghetti code with like HTML and javascript mixed in and lots of little scripts in there, then you will never be able to convert that to something better in the future and this is what we’ve been running in circles for years and years. We’ve never been improving things, we’ve just been fixing things and adding little bits, and bobs, to it.

Paul: (Laughs)

Christian: The other thing that I keeps seeing is well the fan boy thing, about javascript libraries and of the academic way of some people measuring javascript. You have all these like, I mean there’s people that spend like weeks finding different javascript includes and script libraries and measuring how fast they are on their computer…

Paul: (Laughs)

Christian: …generating twelve thousand objects and trying to put them on dominoes. Show me the application that needs that done, then your comparison actually makes sense.

Paul: Yeah.

Christian: It’s the same as CSS. You have like ’10 Most CSS Tricks That You Never Knew’ or ’10 Most Beautiful Naviagations’. It’s like list blog posts digging their way through the internet.

Paul: (Laughs)

Christian: And it’s the same way there right now, like I can appear immensely cleaver if I just put loads and loads of effort comparing things to each other. Instead of saying ‘this’ means use ‘that one for this one’ and ‘use that one for this one’ cause the benefits of that one library is ‘this’ and the benefits of the other library are ‘that’.

Paul: Yeah.

Christian: It normally is like, ‘Oh yeah… that library won.’ or ‘All of the others are bad’.

Paul: Yeah.

Christian: And that’s never the case.

Paul: Hmmm.

Christian: We have to get away from this putting things together randomly and making up an application, to a proper web application design and I’m going to be in New York at the end of the month, no actually beginning of next month at AJAX Worlds and my talk there will be about how to do javascript design and javascript architecture of big applications.

Paul: Mmm hmm.

Christian: That’s going to be quite interesting feedback from the audience I’m quite sure about this, but it’s a matter that we grow up, we actually have to grow up as web developers and take our stuff serious and actually make sure that we don’t build for ourselves – but we build for the guy that comes after us cause that will always happen as well.

Paul: Yeah… and that’s really good advice.

Christian: If you think like that, then you will never write bad code and sometimes people just have to suffer that themselves before they start doing it.

Paul: Mmm.

Christian: It’s always clever to think of yourself as the javascript god that can do things better anyways, but some times it’s good to leave your superhero skills in the corner and just do something that works and that’s understandable and spend some time documenting for the next guy that has to take it over from you.

Paul: And I think that applies to everybody you know people, even people doing HTML or CSS or server side stuff thinking about the next person is, yeah, hugely important.

Christian: Yeah.

Paul: Thank you so much Christian. That was very useful and I really appreciate you taking the time to come on the show on Valentine’s of all days. Good to talk to you Christian and we’ll speak soon.

Christian: See you soon. Bye.

Listeners email:

Rolling out new features

Our first listener comment is from Alex who has come up with a clever little approach for educating existing users about new features…

I just listened to show 112, where you mentioned Christian Heilmann’s javascript walkthroughs. These walkthroughs reminded me that I wanted to do something similar for our website, except I wasn’t able to squeeze it in before the deadline.

My workplace decided on a total revamp of their website, and the final design had some substantial visual and navigational changes. Among other changes, disparate logins had been consolidated into one login button. Of course, now we had the problem of habitual users; because the website hadn’t changed for several years, how do we now try to avoid several hundred support calls asking where the logins have gone?

Well, the obvious solution is to not make such drastic changes. Going for evolution, not revolution and whatnot. Failing that, is something like Christian’s walkthrough popups. However, these would still show up for new users, for whom this information would prove totally useless.

Here’s the solution I had planned:

A couple weeks before the new site or feature launch, we use javascript to set a cookie. This accomplishes two things: 1) we target people who have javascript, so we know the popups will work for them, and 2) we’ll know they were at this page *before* we changed the design or added a feature. Now, once we launch, we check for that cookie using PHP (or other server-side scripting). Why do this on the server side? Well, it lets us avoid even inserting the popup code for people who don’t have the cookie. If the cookie exists, we can then delete the cookie (so they don’t see the walkthrough again), and then insert the walkthrough divs and javascript.

Even though I didn’t get a chance to implement it, maybe this will help other people prepare for site overhauls.

What a great idea Alex. Existing users rarely like sudden changes to the sites they use regularly and often need a lot of help making the transition. This is an excellent way of doing that without confusing new users with unnecessary information.

Content management and CSS

Our second listener contribution is a question from Adrian…

Thank you very much for the show – it has been so helpful!

I have been given the job of creating an Intranet site for a small business. After listening to your shows I would love to create this website using webstandards and have been learning CSS. As well as this it is important that the users of the site can modify the content via a CMS.

So my questions are; can both of these things be satisfied? Also is it possible to design the website using webstandards and then “plug” a CMS into the already created website?

It is definitely possible for content providers to update content built using CSS. In fact it is easier, and allows the designer to maintain more control over the design. Traditionally content providers had to make all kinds of design decisions when adding content. If they needed to add a heading they had to decide what that heading looked like. If they wanted to make a piece of content stand out, they would pick a colour and font size to make that happen.

However, when a site has been built with standards the content provider doesn’t need to worry about what content will look like. They simply say this is a heading by defining it as an H1 and the CSS will decide how to style this. Equally to make something stand out they mark it as strong and the style sheet does the rest. Simple.

The only problem is that some content management systems do not have WYSIWYG editors capable of supporting this approach. They are still focused on giving the content provider design control. Fortunately there are editors out there that do think in this way. A good example is xstandard although there are others. These can just be dropped into your CMS.

Finally, it is certainly possible to plug standards based code into a CMS. Infact, it is actually easier because the style and content have been separated. A content management system is (as it name suggests) primarily concerned with content. It doesn’t care about how that content is styled. Nothing makes integration easier than nice clean meaningful markup, unencumbered by formatting.

110. The mighty Meyer

Posted in Classic shows on February 6, 2008 by Paul Boag

On Show 110: Eric Meyer on version targeting, the business benefits of usability testing and do I have to have a blog?

Podcast: Download (36.0MB)

Download this show.

Launch our podcast player

News and events | The profit and loss of usability | Eric Meyer on version targeting | Listener emails

News and events

Before we kick off the news section today I should point out that I actually link to many more articles, tutorials and news stories than I ever include on the show. If you go to boagworld and click the links in the header you can receive all of these posts by either email or RSS.

CSS reference library

Raise your hands if you have ever used the W3 School. Okay put your hand down now because you are looking kind of stupid. For those of you who didn’t raise your hands the W3 School is a comprehensive reference sources for almost every web language around. It really is very impressive.

The problem is that it doesn’t provide the nicest user experience. If you are looking for CSS reference information then a possible alternative is the new Sitepoint reference section. At the moment it only includes information on CSS however they are obviously looking to expand.

Its design is a lot more attractive than W3 School and although it is not as comprehensive it will provide you with all the latest information on CSS properties including CSS 3. It also provides you with an indication of which browsers support that property.

Stay on :target

Talking of CSS 3 there is an interesting article by Brian Suda over at Think Vitamin entitled Stay on :target. Target is a new CSS pseudo-class being introduced in CSS 3. Although it has yet to be implemented by Internet Explorer it is supported by many other browsers.

Essentially what target does is allow you to style a target element in much the same way you can style on hover. So when you click on a link that goes to a fragment identifier (what used to be called anchor links) then it styles that fragment.

So for example a good use of this attribute would be to highlight the content that you have just been jumped to (like the fade to yellow technique) or to hide and show content when the user clicks on a tab.

Of course many of you might be asking why I bring this up when it isn’t supported in IE. Well, not only is it an interesting glimpse into what is to come, it can also be used right now when the functionality provided isn’t crucial. For example you wouldn’t want it to hide and show content but it might be okay to highlight linked content with it.

Read the article and you can see the potential yourself.

Search behaviour patterns

Another article worth reading is Search behaviour principles over at Boxes and Arrows. This article looks at how people search and the different types of searchers there are. It also looks at what things affect the way people search and techniques that can be used to accommodate their approaches.

As I have said before on this show, not enough attention is given to search and this article will really get you thinking about how to better accommodate it. Best of all there are still a lot of hints that can be applied here even if you are lumbered with an inflexible search mechanism that cannot be customised or tweaked.

10 principles of effective web design

Talking of search usability brings us nicely on to our final story of the day which is a post from Smashing magazine. We haven’t mentioned them in a while but this week they are back with another top ten list. This time it is the 10 principles of effective web design.

Personally I think it is a misleading title as actually the post is about basic usability techniques. That said, it is a very good list and contains some really solid advice. It also contains lots of examples which really helps you get your head around the issues.

I don’t think the post has a lot to offer seasoned usability testers but if you have always avoided the subject in the past then this is a nice simple starting point.

Feature: The profit and loss of usability

We have looked at the subject of usability testing relatively recently on the show and have mentioned it countless times before. However, never have we taken a step back and asked the fundamental question: why is usability testing important? This week we look at how usability testing can be presented to clients and dispel some of the misconceptions about it.

For more detail on what we cover read my post The profit and loss of usability.

Expert interview: Eric Meyer on version targeting

Paul: So on last weeks show we discussed Internet Explorer 8 and some of the plans Microsoft have for it and joining me this week is Eric Meyer. Hello Eric, good to have you on the show.

Eric: Cheers, hello.

Paul: Cheers, very British of you.

Eric: I try to localise my content.

Paul: Yes, very good. Most impressed! We’ve got Eric on the show really because this whole news surrounding Microsoft and what they were planning to do was broken on the A List Apart website, in 2 articles, one of which Eric wrote. The reason I think I wanted to get you on the show to talk about it is because I was kind of struck by the honesty of your article that a lot of what you were saying was very much ‘I really don’t want to like this idea but…’ kind of attitude. Which is the kind of attitude that I think goes down well with the people that listen to this show. So I was wondering Eric, could you kick off by giving a brief explanation of what it is that Microsoft are proposing doing, just so that we’ve got a bit of an understanding of it?

Eric: Um, well pretty much what they’re proposing is that Internet Explorer, Internet Explorer 8, and in the future will recognise a single element, a meta tag which can be used to say ‘This is the version of Internet Explorer that I want you to act like’ so that Internet Explorer 11 can act like Internet Explorer 8 did, or Internet Explorer 7.

Paul: Right.

Eric: So the idea basically is well they call it Version Targeting so that you can have your page actually targeted to a certain version of Internet Explorer even if newer versions have come out.

Paul: Ok. So, I mean at face value that sounds very much like browser sniffing, which is obviously something that has kind of become considered bad practice. How does it differ?

Eric: Well my perspective is that it differs because it actually reverses the direction of sniffing. Browser sniffing To date it has been a case of authors trying to figure out what browsers they want to sniff for and what should happen as a result. This was sort of the reverse side of. It would be the browser sniffing the page to say, ‘What do you want me to do?’, at least in the case of Internet Explorer. It should be clear that Microsoft has so far as I am aware anyway not proposed that anyone else has to do this, or that this has become any part of any sort of standard. They’re saying if it is what we want. This is what we’re planning to do on the browser. So they have the same echoes. I really feel like they are not the same thing. There are a lot of people who disagree with me but they are really very different because one of the reasons that browser sniffing by authors has become viewed as a bad practice is because it becomes fragile over time. First of all there’s a case of people saying ‘If this is Internet Explorer do such and so’, and they don’t consider that there might be a version this version of Internet Explorer that might change what I’m trying to work around. Another reason is that people make guesses about what will be in user agent strings which is usually what people browser sniff on and sometimes those guesses turn out to be wrong as when Safari first came out its user agent strings had the phrase White Gecko in parenthesis.

Paul: Yeah.

Eric: A lot of people had done browser sniffing scripts that looked for the word Gecko so all of the scripts thought that Safari was Mozilla, Firefox or whatever and so some of them broke. In a way it is hard to fault the authors because how are they supposed to know a browser from Apple, not based on Gecko, would have the word Gecko on it’s user agent string and yet that happened so this would be much more controlled it seems to me were it would be browser saying ‘What do you want me to act like?’ and that’s the other reason this has varied from browser sniffing usually tries to predict the future, whereas this version targeting that looks like it will happen in Internet Explorer it actually has to predict the past which is inherently easier to do.

Paul: Why has Microsoft decided to take this position? It seems to me like in some ways they’ve created a rod for their own back in the sense that they are producing I don’t know, Internet Explorer 11 and in that has got to be the rendering engine for 10, 9, 8, 7 and all the way back. Is that not just a lot of work on their part? What’s driving them in this direction?

Eric: I think it will be a lot of work on their part. I do not believe that the idea is to have completely separate rendering engines for each of those browsers, but to have effectively if then else statements in the rendering engine or cases or switch statements for a little more program language savvy. The reason that they’re doing this is that they really have a problem, well they have a dilemma, and they need to get out of the dilemma. The dilemma that they face is basically this: There are a lot of pages out there both on the public web and in private intranets that were developed to IE6 or IE7 let’s say and weren’t developed in an open standards way they weren’t developed the way a lot of people in the standards movement develop sites which is to code to the standards and then figure out how to work around the problems that they encounter. If you have an intranet, a massive intranet site, and your company standard is IE7 the default tendency is to develop it to IE7, you use behaviours that are not correct according to the standard, but are the way that IE7 acts. You have all these past mistakes which every browser makes past mistakes. IE7 it can be argued has made more mistakes than others, not an argument I want to get into. They have that situation where there’s this large legacy of pages. So they can’t have those break for a number of reasons, many of them business reasons, actual monetary reasons but at the ground level you could look at it as if the browser changes enough that those pages start to break it becomes a bad browsing experience for users of that browser. At the same time, the Internet Explorer team would like very much to improve their standards support. They did this for IE7; they fixed a lot of things. They went more towards the updating the browser and didn’t worry quite as much about breaking sites, and they got into quite a lot of trouble over it both internally and externally. There were people who took on the task for breaking the web. We’ve been here before as an industry back in 2000. This is how DOCTYPE switching became to be because the first few iterations of IE and Netscape did very badly at CSS support. They tried and more power too them but Internet Explorer got the box model wrong. Netscape got so many things wrong that they had to junk it and start off with a new browser. So DOCTYPE switching was basically invented as a way of being able to say ‘Given these criteria render pages the way they used to be rendered and give them these other criteria go the more standard route’. From the Microsoft prospective this is like a super DOCTYPE switch except in this case instead of hinging it on a DOCTYPE they’re hinging it on information about what the browser version is.

Paul: Yeah. It is interesting when I first heard about this and I first read your article and the other one on A List Apart, my initial reaction was oh no all this feels wrong and indeed which is what in the sense you said that you went through when you were writing the article and then we actually were discussing it on last weeks show with John Oxton and John Hicks, the same kind of thing came out that we felt very uncomfortable with this and we were reflecting on a lot of things that were said including Jeremy Keith who made this point of you’re actually in a position where you’re actively having to tell Internet Explorer 8 how to behave like Internet Explorer 8 and not IE7, which seems a bizarre set of circumstances but since then I’ve been thinking about it a little and I’m struggling to come up with a reason that I really object to this beyond a principle of the thing that I feel like I shouldn’t agree with it but I’m having trouble articulating why I guess. What kind of things are you seeing? You must have seen a lot of objections come up when you are brave enough to step up and say what you did on A List Apart, I’m sure there was quite a backlash. What kind of things are people saying and throwing against this?

Eric: Well I can see quite a few objections.

Paul: *laughs*

Eric: Well one of them is an objection that Jeremy brought forth which I think I am glad that were talking about that which is that the default behaviour is to default to IE7 as I understand. So when IE8 comes out, if it doesn’t see this version target meta tag in a page it will assume that page is to be treated as IE7 would have treated it, which again completely reverses what were used to. What were used to is when a new browser comes out the page will be interpreted according to the latest and greatest unless you’re using a quirks mode DOCTYPE switch but anyway, it’s bizarre, and yet I did go through the same thing when I first saw it I was like &#”;What!&#”; *laughs*

Paul: Yeah.

Eric: Good old WTF basically.

Paul: *laughs*

Eric: And when I first saw this it was at the beginning of January when Aaron Gustafson submitted the first draft of his article, I hadn’t actually heard about this before then, and I started arguing with him about it in the A List Apart editing forum and very quickly came to realise, &#”;Why am I objecting to this?&#”; and I took the time to step back and say &#”;What’s the deal here?&#”; and that’s were my article came from with the two of us going back and for and it was like, could you write an article about that because that’s what a lot of people are going to go through. So there’s the default behaviour, you have to have the meta to have the latest and greatest, yeah, I would like to see that changed, I would like to have Internet Explorer act the way browsers always have because that’s what I’m used too, but at the same time I have to be realistic about the problems that they face, that I was explaining before.

Paul: Yeah, because that wouldn’t solve their fundamental problem which is that people that aren’t aware of working to the latest standards aren’t going to be aware that they have to put meta data in there pages either.

Eric: Right, so people have said that Microsoft, of anyone, are in a position to educate people who are not aware of the need to do that one thing and that’s the point I made when I was talking to a member of the IE team about this. There are other objects that I think mostly have been related to that for example Bruce Lawson posted just in the last few days, the default behaviour means that from an accessibility point of view any page that doesn’t have this meta tag is stuck with IE7′s accessibility support which apparently is not were it should be, so he’s made the point that freezing pages to IE7 in the absence of any other information freezes them in this inaccessible state, I’m not an accessibility expert so I don’t know how best to categories that but, will have accessibility problems and keep them for years and years as opposed to, ya know, as accessibility problems improve in Internet Explorer, getting those benefits and that a very real objection and a very real concern, and I think one that needs to be made to the Microsoft people because accessibility is very important. There are other objections from the javaScript community, it’s actually been interesting in the javaScript community, there’s been a real dichotomy, there have been some javaScript library authors who’s been like &#”;Yes! Finally, thank god somebody is talking about versioning!&#”; right, and there’ve been others who have been like &#”;Oh my god, are you kidding, libraries will have to support all these backwards engines&#”;.

Paul: Yeah.

Eric: Again, I’m not an expert to know what side of that certain dichotomy I would come down on, in my own blog posts I’m saying, wouldn’t you just use object detection and not worry about what the version number is?, but I guess that doesn’t fully address the problem, or at least that’s what I’ve been told. Again it’s something that needs to be figured out, because there have been some fantastic javaScript libraries and fantastic things that can be done with those and if this is a move that will hamper the growth of that field then that’s something else that would also bother me. There’s also the security objects, the idea that every backwards versions that you have your complicating your ability to keep your security holes closed, that’s the kind of thing we’re I have to say &#”;Look that’s down to the browser maker to figure out&#”;.

Paul: I guess that the problem with the whole default behaviour thing is how badly it’s going to break things, how many sites are going to be broken if the default behaviour was the latest browser and how badly are these sites going to be broken, are they going to be unusable? Are we talking about some small changes? I guess there are a lot of websites out there as well that just aren’t supported at all, content has been put online, nobody is checking them, nobody is checking when a new browser comes along, and if when IE8 was released and those websites became completely inaccessible and unusable then obviously there’s a big issue there because your loosing vast amounts of content on the web. I guess a lot of it is unknown entities at the moment isn’t it? It’s guess work.

Eric: Yeah. There’s a lot of guess work and that’s part of the problem, I think if we knew, if there were some kind of statistics, like if the IE team were to come out and said we built a version were the default behaviour was latest and we tested it against these 1000 QA sites and 20% of them broke, 5% were completely unusable, that would be one thing, or if they said we tested and 2 sites were broken, you could still read them but they look a little weird, that would be different and nobody does really know and at least nobody outside of Microsoft and maybe not even them, I don’t know if they’ve done that kind of testing yet. And, I’m sorry, there is one other objection that come from a couple of other browser manufacturers that this is in affect, anti-competitive, whether it’s meant to be or not, but it has that effect because Internet Explorer has such a large market share they have to worry about what it does and so to them it becomes a lot harder to do that, so if they are going to keep up this effort it’s going to become a lot harder to do in this version targeting world after a few releases, of course the question is whether they would need to do that or not and there’s a lot of debate about that, there are people who are like, &#”;Just stop, stop making reference to Internet Explorer and just let it strangle itself to death&#”;. I don’t want to get into all the back and forth that’s happened but that is another objection.

Paul: I guess, is there some danger here as well that once you’ve got this version targeting in place Microsoft could go off on some complete tangent and start introducing all kinds of proprietary functionality into their browser that isn’t supported in the other and we end up in a situation were we’re having browser wars again with different browsers implementing different proprietary tags and stuff like that, or are we truly beyond that do you think?

Eric: Umm, It is certainly a risk and how much of a risk influences were people stand on this. I don’t see that personally as being much of a risk, because yes, the Internet Explorer team could introduce a load of proprietary properties that let an author change the colour of the browser kernel right or replace the backwards and forwards buttons in the browser, whatever, and if nobody else supports that, I think those efforts will largely support them strangling themselves, I mean, colours scroll bars we don’t really hear about anymore, people will still do them, but nobody else really cares.

Paul: Yeah.

Eric: So, I would not claim to be smart enough to see everything that could possibly be done but I think in a lot of ways that might not be a bad thing, because it would let Microsoft experiment with less constraints, they can do initial implementation of things that are in CSS3 and if the behaviour of those things changes, in a later version they can fix what they did, they can change to match the spec, and then still have backwards compatibility for pages that took assumption of that, there are people that would say &#”;Well they should never implement anything that hasn’t been completely nailed down&#”;, but that doesn’t really work, because one of the ways that you get yourself out of the candidate recommendation stages at the W3C is to have implementations and the only way to have implementations is for someone to implement them and if they find out during that phase, and this is what the candidate phase is about, if they find out in that phase that such and such property that has been specified, doesn’t work in the real world for whatever reason, they’re then able to go back and change it, but in the mean time if your Internet Explorer and 11′ty billion pages have been implemented to your particular version of the property.

Paul: So, you wrote this A List Apart article that went out of the 21st of January, and we should probably say that we’re recording this interview on the 29th of January and it’s not going to go out for another week, so things might move on in-between but there’s obviously been a lot of discussion since you released that article, have your views really changed in any way, are you still in favour of this approach or have there been more concerns raised that have made you doubt it?

Eric: Hmm, I’m still in favour of the general idea, the implementation I’m a little less, I guess I would say I’m more agnostic about, but the general idea of backwards compatibility so as not to break sites, whilst still being able to change and improve and fix the browser I’m all in favour off. The default behaviour still bothers me, and I’m still having trouble working out if there is a case of honest to goodness technical reasons or it just feels wrong, there has to be something, how’s it’s gone about is a different question, if the IE team and the people that they have to answer to effectively can be convinced that having the default behaviour switched and then educating people whole want to freeze their sites, on how to freeze there sites using the meta, they can be convinced to do that and that that will fix the problems that they face then I’m all for it. Accessibility concerns do bother me and I think that that’s another argument in favour of switching the default behaviour but at the same time I also have to recognise that switching the default behaviour, as you said earlier, from a certain prospective, completely negates the entire reason to do this, given a certain set of circumstances if they’re going to switch the default behaviour it might almost as well not even do it. Again though that also depends on how much breakage on how many sites and what kind.

Paul: Yeah.

Eric: The other unknown that we’re facing here is we don’t yet know just how different the IE8 behaviours are compared to IE7, we have a clue in that we already know that there’s an internal build of IE8 that can support the ACID2 test, which they weren’t even really very close too, well I guess that depends on who you talk to, but they didn’t support it before so in or to support ACID2 they have to have things like generated content with CSS which we completely don’t have in IE7 they have to have fixed some of there parsing bugs and so on and so forth that hints at a very large change, an even bigger change than that between IE6 and IE7, but we don’t know at this stage, it could be, and this has been one of my objects to ACID2 or one of my discomforts with ACID2 over the years, it could be that they’ve just implemented exactly the things that were needed to ACID2 work and not more, which is the wrong way to go about supporting ACID2 and I don’t know that they’ve done that, but it’s possible. So I may be that it’s not such a huge change, but those things came about as sort of a broader push towards implementing more advanced selectors and fixing bugs and implementing area content and really pushing into the areas of CSS2 that they don’t support and the areas of advanced CSS modules that they don’t support yet, then that could be an enormous change and in that case there’s more chance of them breaking a ton of sites if they don’t have a mechanism like this in place to deal with them.

Paul: So I mean in some senses, after discussing this for however long we’ve been discussing it, there’s very little at this stage that we can really do about this, for the average web designer, Internet Explorer 8 isn’t going to be out in the immediate, one presumes and even when it does we’re talking about relatively minor changes that they’re going to have to make to their site, I guess the biggest immediate concern is maybe how you think about building sites at the moment, do you worry so much about things like progressive enhancement if maybe the way that Internet Explorer works in the future, I guess they’re still good principles.

Eric: Yes, absolutely they’re still good principles and that is how I have developed sites and will continue to develop sites and really I think what it comes down to here is who’s going to have to add the meta tag.

Paul: Yeah.

Eric: Is it going to be people who do forward development, ya know forward compatible development, is it going to be standards aware developers or is it going to be people who aren’t in that sort of craft. It’s not fair in a way, that the people who have been doing things in the right way will have to take that on, but on the other hand it could well if you look at the numbers, there are a lot less of us.

Paul: And in some ways we’re much more equipped to do it.

Eric: Right, to understand why it’s needed and how to do it the right way and when not to do it for that matter.

Paul: Yeah.

Eric: Because when you develop a site for someone and it seems like a one off and they really not going to be keeping it up, you might want to keep the meta tag off because you know that that will default to IE7 and that’s what you want or you might explicitly include it because you want it to default to IE7 and IE8 or ya know on my site if this happens I’ll probably use the edge keyword of IE equals 1024.

Paul: Yeah.

Eric: So I’ll always get the latest and greatest and so that’s for me personally, but for a client I would have a much harder time justifying that because clients don’t care if it’s forward compatible development or not they just care about whether their site works and will continue to work right and so the point has been made, as you did, that in a lot of ways people who are sort of more clued in are better equipped to take this on as opposed to somebody’s grandmother who uses Dreamweaver or whatever to put together a site for her poetry circle and this happens all the time, they don’t even look at the mark-up let alone would understand why this would need to be done why there would need to be some kind of meta tag, first you would need to explain the concept of tags etc, etc, etc.

Paul: I mean a lot of these people don’t even realise that there are multiple versions of a browser, or indeed that there are multiple browsers.

Eric: *laughs* And those are also issues that will need to be faced, somebody is going to have to do this. A lot of these advances that IE8 seems to have ready to go as indicated by passing the ACID2 test may well have to come back out.

Paul: Yeah.

Eric: You can always back changes out of a code base and that really seems to me to be the dilemma and I’ll want to say again, there are people who reject that as being the choice, there are people who feel very strongly that that isn’t in fact a choice, even if you except that’s a choice that they should keep the changes in but be willing to break sites because sites always have to be updated anyway and that’s how browsers have always done it, so there’s a large amount of history that says that can happen but browsers can still advance.

Paul: We will see won’t we, that’s what it boils down to. We will have to wait and see. Okay, Eric, thank you so much for coming on the show and talking that through, it’s an interesting area and I think it’s an area that will have significant impact on how things develop in the future, so it’s good to have your perspective on it. Thanks very much.

Eric: Paul, thanks for having me on, I really appreciate it.

Listeners email:

Basic CMS options

As in last week’s show I so badly bastardised the name of our textmate reviewer, I decided it is only fair to allow him another go this week. He asks:

I have a friend who wants me to build a website that they can update. They don’t know how to write HTML or CSS. What is the best way to solve this problem?

The obvious solution is to use a content management system of some type. Indeed this is something we have covered before on the show back in show 24. If you were building a relatively big site that needs constant updating, then I would definitely encourage you to check out that episode. However if your needs are simpler a full blown CMS might be overkill. In such situations you should consider a simple blogging system like WordPress.

One final option maybe to use a tool like Contribute. That way you could build a nice simple static site but your friend would have a WYSIWYG tool to edit it.

The importance of blogs

Our second question is from Lauren:

My question is about starting a blog. Right now, my nights are filled with homework, but once I complete my program, I can truly dedicate my time to building my portfolio. Are blogs really that important now? I don’t know if I can come up with meaningful content to make my blog stand out. Does this mean that I won’t be able to find a good job in the industry without one?

You talk about a portfolio and blog as if they are separate things, but I would suggest they should be combined. As somebody who regularly hires web designers, I have to say I find portfolio websites frustrating. At worst they show me some pretty pictures, at best examples of fully functional websites. However, what they don’t tell me is the thought process behind the designs. Why did you choose the colors you did? Who is the target audience and how did this affect the design?

A blog can also be used as a portfolio but allows more depth into the designs you are presenting. Also, a blog allows you to link to other content on the web and express your views on that content. This shows me as a potential employer that you are well read and interested in what is out there.

As a student looking for your first job I wouldn’t expect your blog to include new CSS techniques or innovative approaches to user testing. However, I would like to see examples of work fully explained and evidence that you are reading other web design sites and have opinions on what you are reading.

104. Give us your money

Posted in Classic shows on December 12, 2007 by Paul Boag

On this week’s show: Paul shares 10 tips for getting designs signed off. Marcus looks at how to present to a prospective client and Michael Slater introduces us to Ruby on Rails.

Podcast: Download (25.5MB)

Download this show.

Launch our podcast player

News and events | Marcus: How to present to a prospective client | Paul: 10 tips for design sign off | Michael Slater talks about Ruby on Rails | Question of the week

Housekeeping

All change

I have a bit of housekeeping news before we go any further with the show. I am changing things around a bit with my podcasting line up. After a chat with Dan Oliver from .net magazine we have decided that I will no longer be doing their show. They have some great plans for it in the future but it just didn’t make sense for me to keep doing two very similar shows. Before people start emailing, no we haven’t had a falling out and I still love Dan very much… if only I wasn’t already married.

The good news is that this allows me to introduce some more guests onto this show and bring in a bit more discussion. In order to accommodate this we will be having just one feature section each week instead of my bit and Marcus bit. Some weeks I will do it and other weeks it will be Marcus.

The final aspect of all of this is that we are going to start recording the show together rather than over skype. This should deal with the audio problems we have been having as well as making for a much better dynamic.

Christmas giving

I thought it might be nice to use the mighty power of the Boagworld listeners to raise a bit of money this Christmas and wondered if you might all be so kind as to help.

We have been doing this show for well over 2 years and have never charged or done much in the way of advertising. We are therefore wondering if just this once you would dip your hands into your pockets and give a bit of cash.

I want to raise some money for a charity I have been personally supporting for a while. A friend I grew up with now runs a school and orphanage in a very rural part of India. The kids they work with have far from the best background and the school is the only hope they have of breaking out of their circumstances.

I wont emotionally blackmail you with sob stories (because I know you are hardened cynical geeks) but simply ask that you give me some cash in return for the two years of free shows I have given you.

Because I am unorganised and only thought of this a couple of days ago we are going to simply use my paypal account to collect donations. I will then pass the money on to the charity. So to give a donation just use the bottom below (be warned its not the most intuitive system ever but you are all clever chaps. I am sure you will work it out).

Give to the Boagworld Christmas Appeal

News and events

24 ways is back

My first story of the day is actually 12 days late because it is the re-launch of 24 ways. In case you haven’t come across 24 ways before I should explain that it is an advent calendar for web designers.

Each day in December leading up to Christmas they publish an article written by some of the leading lights in web design (oh yes, and me). The articles are somewhat random but also incredibly practical and hands on. Articles range from creating a never-ending background to working with online maps.

But don’t panic that you have missed the first half of advent. You can access all of the previous days. In fact you can even access the last 2 years of articles. Ample to keep you amused while we are away over Christmas.

Tips for development and design

If 24 ways isn’t enough to quench your thirst for knowledge then let’s throw two more articles into the mix both of which provide some top tips.

The first is for all you developers out there. The guys at Blue Flavor have shared their top 10 tips for a successful development project. The article includes great advice like, always create a functional spec and talk to your clients. Interestingly one of the suggestions is to use a version control system. This is also a tip in our second article which is aimed instead at designers.

Jina Bolton has written an interesting article for Think Vitamin entitled “creating sexy stylesheets“. Like the blue flavor article this one lists 10 tips. However this time they are for producing better stylesheets. Now, although I would argue that nothing makes CSS sexy this is still a very useful list. The tips for organising your CSS file and building your own framework are particularly good.

So if you are into top 10 lists then you should be happy this week whether you are a designer or a developer.

24 wayswhich post articles on web design over the Christmas period. Well, I was asked to contribute to the site so I wrote an article entitled 10 tips for design sign off. Although some of the tips have been covered on the show I thought generally it would make a good segment for the show.

The problem is that getting design sign off can be one of the most challenging parts of the web design process. It can prove time consuming, demoralizing and if you are not careful can lead to a dissatisfied client. What is more you can end up with a design that you are ashamed to include in your portfolio.

How then can you ensure that the design you produce is the one that gets built? How can you get the client to sign off on your design? (Question of the week

What tips do you have for getting designs signed off?

Quick and dirty wireframes

Posted in User experience on December 6, 2007 by Paul Boag

I am currently in the process of wireframing an internal project that we are working on at Headscape. It occurred to me that despite the fact that wireframes are a fundamental tool of web design, they are not something I have spoken about before.

What is a wireframe?

Fundamentally a wireframe is a tool for rapidly prototyping a website. They roughly approximate the layout, content and hierarchy of a web page as well as the relationship between pages. Effectively you are building a rough version of the site.

Wireframes don’t look attractive. They are not designed as such. Rather they give a sense of how things will be organised on your site. In many cases they lack colour and imagery, although there is no reason why they should. However, they do show visual hierarchy through layout, font size and shading.

Example wireframe

What benefits do they provide?

So why produce a wireframe? Well there are a number of good reasons…

They act as a reference point for the designer to work from, demonstrating the relative importance of various screen elements.
They can be used to test with. This enables you to ensure users can navigate a site and find key content on a page.
They help flush out the details of a site that are often missed. These include things like password recovery and error handling.
They help to define interactive elements such as AJAX and Javascript in a way a static Photoshop mockup cannot.
They help the client to visualise how the site will work.
They identify navigational issues which need resolving.

How to create a wireframe

Once you have recognised the benefit of producing wireframes the next question becomes how exactly do you build them? The answer is largely dictated by two factors; the time available and the complexity of the website.

If you are really strapped for time then simply sketching out some key pages is better than nothing. Even these can be used in testing and shown to the client. However, a sketch does not show interactive elements or the relationship between pages.

If you have a little more time you could produce key pages in a tool like Omnigraffle or Visio. Better still is powerpoint which allows you to link multiple pages together, so creating a basic navigable site.

However, probably the most common way to build wireframes is using HTML. Of course the downside of this approach is that it can take longer if you are overly precious about your code. Personally, when it comes to wireframes I prefer the quick and dirty approach. I create my HTML wireframes using the WYSIWYG editor in Dreamweaver, churning out the pages through a mixture of CSS and tables. I don’t care what is going on under the hood. All I care about is that I can get a sense of how the site would work.

Taking this somewhat cavalier attitude to HTML wireframes is not without its drawbacks. Because the underlying code is a mess, ultimately the wireframe has to be thrown away. A better approach would be to use nice clean semantic code which can then be reused for the final build. However, in my experience this rarely works in reality. The only time I do use this approach is when building a site on our content management system. In such situations it is as easy to rapidly produce pages in the cms as it is in Dreamweaver.

The key to wireframes is for them to be quick and disposable. Wireframes are the place for you to experiment and try out new ideas. They are the place for testing and adaptation, not for being overly precious.

If your site is a simple one then using sketches or a tool like Visio will probably be enough. However, if it is more complex with a lot of pages or interaction then consider using an HTML wireframe. In short use the right tool for the job!

Show 99: Don’t panic

Posted in Classic shows on October 23, 2007 by Paul Boag

This week on Boagworld: Paul looks at the growing importance of the favicon. Marcus talks about what to do when the work dries up and Rob Borley looks an alternative approach to storing data in your CMS.

Podcast: Download (24.9MB)

Download this show.

Launch our podcast player

News and events | Marcus: What to do when the work dries up | Paul: Favicons – small but significant | Rob Borley on an alternative approach to your CMS | Question of the week

100th Show

Just wanted to say a big thank you for everybody who came along to the 100th boagworld. For more information on the evening check out my 100th Boagworld blog post. A special congratulations to the 4 winners of a years subscription to .net magazine and to Anna who won a CSS beginners course run by Drew and Rachel at edgeofmyseat.com.

Also live on the show we announce the winner of the FOWD competition.

News and events

Shift in the web wind

Molly Holzschlag likes to generate discussion on her blog and has raised an interesting subject in her recent post “shift in the web wind“. In it she says:

The latest Dot.Com boom is declining as far as I can tell. Are we on the edge of another Dot.Bomb?

Its an interesting question and one that seems to be appearing on an increasing number of sites.

Personally I have to say that I have become concerned about the state of the web at the moment. Not because I believe we have necessarily reached the point of a collapse, but because the boom we have been experiencing is unhealthy. I am in no doubt that we are now experiencing a bubble very similar to that of the dot com era. There are far too many copycat companies out there and the share price of companies such as Google are disproportionate to their revenue. What is more, once again we are seeing the majority of these companies leaning on advertising as a revenue stream. Advertising is very fickle business model because any dip in the overall economy and advertising is the first area to be cut.

So is everything doom and gloom? Are we about to all be out of work? Certainly if you work for a web 2.0. company or the majority of your clients are web 2.0 companies, then I would be twitchy. However, for the majority of us I don’t think there is much to be concerned about. Even if the bubble bursts there is going to be no shortage of web work around. The majority of web designers don’t work on web 2.0. sites. We work with offline businesses that have an online presence. These sites are not going to stop trading just because some high profile web businesses fall. The web is too well established this time around.

If it wasn’t for the fact that it will mess up people’s careers, I would welcome the crash. I think the current state of the sector is unrealistic and the larger the bubble grows the bigger the ‘pop’ when it bursts.

Best practice in email

Most organisations rely on email to communicate with their customers on mass. Whether it is order confirmation, special offers or regular newsletters, email is an essential tool in our web strategy. The problem is that our emails have to fight there way past junk mail filters and increasingly they fail to do so. This isn’t necessarily because we are sending out spam. In most cases it is because we are just ignorant of best practice when it comes to email delivery.

Fortunately this week I came across a great article that suggests some best practice when it comes to using email. This isn’t a list of ways to trick spam filters, rather it provides all kinds of great advice about running any kind of email campaign. From technical advice about CSS and HTML to common curtsy like don’t attach large files, this article really does contain some excellent advice. Finally, it also contains an invaluable list of tools for checking how likely your email is to be classed as spam. If you send out email to your customers then check out this article.

Flash based galleries for your images

So everybody thinks I hate flash. I don’t! I just think we need to think twice before using it. Like any technology we need to use the right tool for the job. However, sometimes flash works well and can really enhance the user experience. One such occasion is when we are building image galleries. Sure, you can build nice static galleries or even produce something impressing using Javascript. However, flash can do some stunning stuff with images.

Even better is the fact that there many flash based gallery systems out there that you can just drop into your site with minimal effort. Whether you are showing off your portfolio or building an image gallery for a client you might want to consider one of flash based galleries reviewed in Smashing Magazine.

20+ tools for working with AJAX

If Flash is not your thing then you are probably into your AJAX and Javascript. If that is the case then check out mashable which has a list of over 20 great tools for work with AJAX. The list consists of a mixture of AJAX loading images, frameworks, reusable scripts but probably most usefully sources of advice. They include some great stuff for those starting out building with AJAX including a noobs guide and also a wiki of common AJAX mistakes.

If you know Javascript already but haven’t done anything with AJAX then take a look. It really isn’t as intimidating as some people like to make it out to be!

Marcus’ bit: Don’t panic

Marcus looks at those times when the phone’s not ringing, your inbox is empty and you just lost out on three pitches in a row. No matter how much you tell yourself not to worry, it starts to creep up on you.

Paul’s corner: Favicons – small but significant

In my section of the show I want to look at favicons. Favicons are those 16 by 16 pixel graphics that appear in your address bar, bookmarks and various other places. They maybe tiny, but they are becoming increasingly important. I look at why Favicons are worth your attention.

Ask the expert: Rob Borley on an alternative approach to your CMS

Paul: So joining us on the show this week is Rob Borley who is, what is your job title Rob actually, I should know this but I don’t?

Rob Borley: (Laughs) Ye you should I think you gave it to me.

Paul: Oh did I?

Rob Borley: Technical Manager officially.

Paul: Uhhh… But basically Technical Manager/Lead Developer/anything vaguely techie goes in his direction.

Rob Borley: Basically it’s my fault when it breaks.

Paul: Yes, so if you want to get pissed at somebody about the boagworld forum there’s your man.

Rob Borley: (Laughs) I knew this was going to come up.

Paul: Well obviously it was going to come up.

Rob Borley: (More Laughs)

Paul: So if you haven’t gathered, Rob works for Headscape, the web design company that myself, Marcus and Chris Scott run and no he shouldn’t be blamed for the boagworld forum, he is actually trying to fix it, but his skills just aren’t up to the job.

Rob Borley: Oh, I see, I see, I see… (Laughs)

Paul: (Laughs) But why I’ve got him on the show today isn’t actually to be rude to him about the boagworld forum, but it’s actually to talk about our content management system because I get a lot of questions asking why content management system Headscape use and what one we would recommend and stuff like that so we’ve just got through a kind of major rebuild of our content management system and so I thought OK lets get Rob on the show and have a little bit of a chat about it and how it works and what it does. So I guess Rob the question to kick off with is why did Headscape decide to develop its own CMS rather than go with an off the shelf one, because there are so many off the shelf solutions around it kind of seem absurd in some ways?

Rob Borley: Umm, ye I guess when you first look at the problem, as you say, there are lots of CMS solutions around but the reason we kind of work from our own is because it gives us complete control over what we’ve got so if there’s a problem with it, we know were the problem is and can go in and fix it but more likely if there’s some new functionality we need specific to our clients we’re able to just go and build it and develop it very quickly because we know exactly how the thing works. Often these off the shelf CMS’s are trying to do everything because they’re in competition with all the other products out there and so they’re vastly complicated, they do lots of things we don’t need them to do and they’re not generally as useful for the client as what we’ve got as a result, because they’re designed by techies, techies know how they work and they’re generally far too complicated for average Joe user out there. What we’ve build is tailored specifically for our clients needs and hopefully is intuitive and easy for them to pick up because it’s designed for them.

Paul: Would you kind of, you know, are you being more brash in that your saying all web design agencies should be developing their own CMS’s or is that something specific to our requirements and the type of clients we have?

Rob Borley: I think when you look at our client base and the sort of projects that we get, a vast majority of our projects are based on our CMS technology now and so, I mean, if we were doing just one or two projects here and there then it would probably make sense for us to get to know our favourite brand of CMS and use that, but as a vast majority of our clients are using this technology it’s actually more productive for us to develop with our own, because we can just keep reusing stuff and add any new development or any area that we can add to it, we can then use it for future clients as well.

Paul: Hmm… So we had a content management system, it seemed to work, why then did you, actually no it wasn’t just you, you and Chris persuade me and Marcus to spend huge quantities of money on re-doing it from scratch?

Rob Borley: (Laughs) Well the first iteration, well I say the first iteration, I think we’re up too officially CMS 3 before we started this new one, it naturally evolved, it came from the need of one client wanting a CMS and then we thought “hey this is a good idea” and things got tagged on and other things got tagged onto that and it just became this, evolved almost organic mess of Darwinian thing which worked and held together and did it’s thing but had never been properly designed, it had never been build for a specific purpose, it was all just kind of mashed together and so as we came to the conclusion that most of our clients are going to be using this we took the opportunity to build a new one from scratch to do it properly. That’s the general theory.

Paul: So what’s different with the new one to the old one?

Rob Borley: Umm… Well there where a few extra features like there’s a more complicated, well I say complicated, more in depth permissions system for pages and parts of the site, there’s also some work flow stuff we’ve added but the main difference is actually what goes on underneath and so this time around we build the whole thing on XML data structures.

Paul: OK.

Rob Borley: Which probably doesn’t mean a great deal to a lot of people out there, but what it means to Headscape, it’s actually changed the way that we develop projects and the way that we work, and it means a lot more less techie people can get down to the nitty-gritty of designing the data and the way things work.

Paul: So, give me an example of how that kind of works in practice?

Rob Borley: OK, so an everyday clients might come to us and say “We need a CMS to create” I don’t know, “hotel vacancies” and so what we’d have to do with previous versions of our CMS is go off, create the data structure in the database, write the logic in the server side pages and the database logic and techies would have to do that because your talking about writing ASP or .NET or PHP or using SQL Server and it’s a very techie orientated job. What we’ve done now by using XML is all the actual logic for the data structure is done in what’s called an XML Scheme which is basically a text document which describes the data. So it means that an average person in the company, who not particularly techie, so a designer or a project manager, a tester or someone can actually sit down and write a document that describes the data, feed it into the system and we’ve got our new area of data, our new “hotel vacancies” structure straight away. So it can be done much, much quicker.

Paul: So if I’m understanding this right, which I probably should do (Laughs)…

Rob Borley: (Laughs)

Paul: lah lah lah, so what we’re talking about here is basically that traditionally with a database you have a serious of hmm… well lets say for example in the “hotel booking” example you gave lets say the hotel had a name, a description and a price range, in the database that would have appeared as three fields basically, it would have been a name field, a description field and a price field.

Rob Borley: Exactly.

Paul: And then your code would have had to, on the back end, would have had to create form fields for each of those that would input into the database and on the front end you’d have to pull, ya know, your code would have to pull out those three pieces of information and display them on the front end, is that correct so far?

Rob Borley: Exactly right yes.

Paul: Right, so what your describing now if I’m getting this right is that basically you wouldn’t have three separate fields in the database, you would just have XML code for those three elements.

Rob Borley: That’s right.

Paul: And then the code both front end and back end looks at the code in the database and just pulls them all out and just displays them as form fields for inputting or text for out putting?

Rob Borley: Exactly, all the logic for that is already done so as soon as the XML is fed in, the back end displays the form fields to fill out the information, the front end pops out the raw XML which we can then style and apply your fancy CSS to.

Paul: I mean that’s quite incredible because like you say then, someone like Charlie who’s one of our Project Managers, can just go in and define, ya know, say we wanted to add, I don’t know, ratings to that list and then suddenly it will just miraculously appear on the front end and back end without any additional coding from you. Is that right?

Rob Borley: Exactly.

Paul: Wow.

Rob Borley: And often, so we’ll be half way through a project and a client will come along and say, “oh, well actually I don’t want that text field there, I want this text field” or “I want this drop down” or “I want this particular text field to be on the front end” and they’ve never mention it before, ya know, it’s typical client changing things as they go along and the Project Manager can just go in there and change the scheme and it does it, it’s done.

Paul: So there are lots of people using this XML/database technique?

Rob Borley: We like to think it’s quite new.

Paul: Oh really?

Rob Borley: Yes. I’ve personally not come across it being used before, but I’m sure there are people out there who are going to correct me on that. (Laughs) But it is quite new.

Paul: It would be quite interesting to know actually, if you are listening to this and you know of somebody doing a similar thing, drop me a line on [email protected]. It’s just kind of interesting to know. So what about, umm… have you kind of made any changes that have kind of made expanding the functionality more kind of modular or anything like that? I mean beyond this XML?

Rob Borley: Ye.

Paul: Is the architecture designed in a different way?

Rob Borley: Ye, so previously it was built on ASP Classic, which is not best for modular design, it’s quite difficult then to move functionality around and re-implant it else were. This time we’ve built it in .NET, in an object orientated way, so the theory being that when somebody else comes along and say “I want this addition to the form builder” or “I want to add a rating system” or “I want to add a product management system/stock management system”, we can literally just, that goes in as a block of code, we call it in an object orientated way, we can turn it off for some clients and so hopefully you build it once and it works for everyone that wants it.

Paul: So does that mean we’re going to have a consistent version of the CMS basically applied to, no we won’t because if a client asks for a new module that’s not going to be on the previous clients ones.

Rob Borley: No, so we won’t roll it back to previous clients, but there’s the potential, as we build stuff up, the potentials great for using in future projects because core of code to use as a base for all the projects.

Paul: So there’s like a core, what do they call it? Kernel of code that will stay the same and all the other modules are built around it?

Rob Borley: Ye, and the idea is that the kernel is kept as small as possible, so that the actual “guts” of the CMS are as tiny as possible and then it’s used to call all these extra modules when it needs it.

Paul: I’ll tell you another completely random question.

Rob Borley: (Laughs)

Paul: That I got asked recently, that you may be able to answer, you mentioned that we’ve built this CMS in .NET and that we do do a lot of .NET work, umm… the question that I got asked was somebody was going on about how it’s hard to produce standards based code out of .NET or Visual Studios, do you know what they’re talking about?

Rob Borley: No.

Paul: No?

Rob Borley: (Laughs)

Paul: Well it didn’t make a lot of sense to me because we produce standards based code don’t we?

Rob Borley: Ye, all of our code is output to your specification actually Paul.

Paul: Ye.

Rob Borley: (Laughs)

Paul: Anyway it just confused the hell out of me that one so I thought I’d ask you about it.

Rob Borley: (Laughs)

Paul: So, what next then is guess is the thing you would kind of ask? Is this a model you think is going to service for a long time going forward or are we going to have to go through this process again in a couple of years?

Rob Borley: I certainly don’t see us having to redesign it again for a long, long time. I mean this seems like it’s going to work and it’s easy to add and extend, I think that’s the key, it’s also very portable, because all the data structures are all XML based, if we for whatever reason decided to ditch Microsoft and move over to PHP and mySQL, all we’d have to do it re-write the logic that calls the XML in and out.

Paul: Oh OK.

Rob Borley: The data structure stays the same to the potential for importing it to other technologies as well as extending the functionality is there, it’s going to be a lot simpler than it would have been in previous versions of things we’ve done.

Paul: That’s very interesting isn’t it? I like that a lot. OK so just to wrap up then, if people wanted to learn any more about this kind of approach, I know your saying there isn’t much around about this kind of stuff but is there any way you would recommend people start having a look?

Rob Borley: Umm… Well the key behind it is storing XML so that’s were you’ve got to start, you’ve got to start with actually storing XML in a database and using the XML data types that the various database engines use now and then pulling the data out , so if you’ve got a good grasp of XML and XSLT then you can actually use whatever server side language you like so if you into PHP, or ASP or .NET or Ruby or whatever you want to do umm… getting to grips with the way the XML works is going to be the place to start, there are lots of places to check that out, W3 Schools is probably the easiest place to start, so the base technologies are standards it’s just what we’re doing with them that slightly different.

Paul: Ah… I think you need to write a blog post on this Rob so that people can access it.

Rob Borley: Your going to let me loose on boagworld Paul that very brave.

Paul: I’ll let you loose, if you write something I’ll put it onto boagworld for you.

Rob Borley: (Laughs)

Paul: Once I’ve read it, edited it and removed all the rude comments. (Laughs)

Rob Borley: Good idea.

Paul: Because you really need something else to do. You seem to be sitting around doing nothing so lets get you doing something constructive. (Laughs)

Rob Borley: I think so, hence I’m on this show.

Paul: Exactly, alright Rob thanks very much for coming in, that’s really interesting, a lot of that I’ve kind of grasped at some level because you’ve told me I need to understand it but ye, that’s really helped.

Rob Borley: (Laughs)

Paul: Thank you very much.

Rob Borley: No problem at all.

Question of the week

Are we facing another dot com bust and if so what affect will it have on you? Answers in the comments.

Show 95: In honour of the the RAF

Posted in Classic shows on September 25, 2007 by Paul Boag

On this week’s show: Paul shares some techniques for selling your services through your online profile. Marcus discusses project time scales and Ben Hunt talks about marketing your web business.

Podcast: Download (24.9MB)

Download this show.

Launch our podcast player

News and events | Project time scales | Social networking for sales | Ben Hunt on marketing a web business

News and events

The Rissington Podcast

For over 2 years now we have been doing this podcast and in that entire time we have reigned supreme. There have been other web design podcasts but lets be frank they have been shit ;) Obviously out of politeness I have pretended they had their place but I think it was obvious to all that only boagworld was really worth listening to.

However, like all great empires sooner or later they crumble and fall to a new rising star and I fear that maybe true with Boagworld. There is a new kid on the block called the Rissington Podcast. Not only is it hosted by two web design guru’s in the form of John Oxton and Jon Hicks but it is also professionally put together and at times really funny.

This rambling, question based show shares some great advice on web design in an entertaining and friendly manner. Definitely check it out, we promise not to cry. After all, it is even more British than us!

Net Promoter Score

On last weeks .net magazine podcast we got talking about how to measure the improvements we make to the user experience in order to prove their value to a client. Peter Merholz from Adaptive Path mentioned something called the Net Promoter Score which I have confess I had never heard of.

Fortunately I wasn’t alone in my ignorance because Andy Budd had not come across the term either. However, unlike me he took the time do some research into the Net Promoter Score and post his findings online…

To calculate your Net Promoters Score, you ask your customers “how likely they would be to recommend you to a friend”, and get them to grade their answers on a scale of zero to ten. Zero would be extremely unlikely while ten would be highly likely. Those who answer nine or ten are considered promoters, and are the most likely people to evangelise your services. Those who answer between zero and six are considered detractors and are the type of people who will spread negative views about your services.

To work out your Net Promoters Score, you simply subtract the percentage of detractors from the percentage of promoters. A good score would be in the range of 50-80%, while an average score would be 5-10%. A poor score would be in the negatives…

Andy then goes on to explain how this basic question can be used to assess the value of your service. I can see why Peter brought this up on the show as it would seem an excellent way of assessing improvements made to the user experience. By testing before and after a site redesign it would be easy to measure improvements in the experience.

Try it on your next project.

15 Excellent Examples of Web Typography

This is a bit of a random news story but I really wanted to mention it. I am excited to see that the movement towards better typography on the web continues to build momentum and I am constantly amazed at just what is possible with a bit of determination.

Typography can me an incredibly powerful tool in our design arsenal, as I have no doubt said many times before. However, if you still need convincing then check out these 15 superb examples of web typography which I came across this week. There really is some inspiring stuff in here and it should be enough to get even the most jaded web designer playing with type again.

Social net offers new perspective

Talking of being inspired, my last news story of today is a post by Bill Thompson on the BBC technology site. I am not sure it is directly to do with web design but it certainly went a long way to re-energising me about the work I do on the web.

The article focuses on how the social side of the web is transforming not just the way we interact online but also our world as a whole. While other journalists seem to be hammering the social net as a haven for child predators and terrorist trainers, Bill talks about how it is uniting cultures and making the news we see on TV real again.

Bill writes:

What will happen when these people (referring to online friends we have made) start dying in famines or wars, or when the climate changes caused by global warming lead to floods and droughts and natural disasters?

What happens when the photos on Facebook and Flickr show devastated crops and starving families – and these people are not just faces on the television but old friends, people whose likes and dislikes and reading habits and favourite films we know and share?

The world is different when it’s the people you know, and I do not think we will be able to resist the forces of change when our friends are dying on screen, in front of us, and we know that we could do something but have decided not to.

The article really grasps the power of the social web, a power I personally am all too well aware of. Running and developing an online community is a strange thing. Many perceive social networks as a numbers game (a way of attracting traffic). However at its heart are real people and real relationships. I will never forget a woman called Crystal whom I became friends with back in 1997 when I ran a virtual community. Crystal was dying of cancer and was housebound. For such a long time she was the heart of our community until one day she died. The grief that we felt was just as real even though none of us had ever met her face to face. She was a real friend to me, a real person.

I think that is why many online communities fail. They fail because they don’t grasp that communities are about people and relationship rather than features and technology.

Marcus’ bit: Project timescales

I have often rambled on about the importance of contracts on this podcast and, within those the contracts, the need for a detailed spec, a detailed task list and associated timescales and milestones.

I still think all of those things are important but I do think that often (me included) people go into a land of fantasy when it comes a) when they can start a project and b) how long each one of those tasks will take.

Clients are guilty of this too.

This is what usually happens:

The client, not knowing how long the project will take, picks a date for project completion because they don’t want it left open. Let’s call it ‘date x’.
Unless it’s patently impossible to achieve, agencies will agree to this deadline because they don’t want to adversely affect their bid.
A certain amount of back and forth over the delivery date happens because, for example, it takes longer than expected to agree on a contract, or maybe the scope has extended a little, etc. But the agency can’t really move the date to somewhere comfortable because they have already agreed to ‘date x’. So, all parties then agree to ‘date x plus 1 month’ or similar.
The project then slips and both parties start blaming each other for it – the agency feels that the client is overly pushy and, worse, the client thinks that the agency is unprofessional, inattentive etc.

Be honest from the start

Seriously, do it. I was just having a conversation this morning with a potential client (hi Graham) who is looking for a new site. He has an unrealistic delivery deadline of the end of October. With Headscape’s current workload, I felt that we could deliver the project, at best, by the end of January. This blew our chances completely but -

a) Graham appreciated the honesty and, who knows, may want to work with us again or recommend us to others;

b) If I had underestimated – a favourite at this time of year is to say ‘we can do it by Christmas’ – then I would have become very unpopular internally and also with the client when we failed to deliver.

Don’t forget you have other clients

It is so easy to think ‘standard CMS site redesign equals 10 weeks’ and then go and quote a date for completion 10 weeks from now! Don’t forget the following:

It usually takes at least 2 weeks to sign a contract
Do you have the resources to start straight away?
What other projects are imminent?
Staff holidays

Educate

I think the problems I am referring to relate to the fact that, even now, we are working in a relatively ‘young’ industry. This means that many clients simply don’t have an understanding of how long projects, and the tasks within those projects, can take.

This used to be a problem with pricing and still is in some cases. However, client expectations of cost seem to be a lot more in line with each other than they were, say 3 years ago.

If we can explain what we do and how long it takes right from the start with a potential client, then hopefully client expectations of project length will also balance out.

Paul’s corner: Social networking for sales

From time to time I get questions about how to build your reputation in the field of web design. How do you become well known so that you can attract more work in? Its a fair question and one that inspired an article I wrote recently called The Geeks Alternative To Golf.

Ask the expert: Ben Hunt on marketing a web business

Ben:

Ill be talking about marketing a web business. And the things that I cover will apply particularly to small web businesses, little shops, web designers. But, the principles that we will be going over will apply to the whole of web design and in fact the design of any site at all.

What I am going to be talking about I guess comes under headology, psychology. It will be stuff like: self perception, posture, attitude, and brand – which are really central things.

So, starting with brand… what is brand? Well, brand is how people perceive you. What do you offer, what can you do for them. And what differentiates you from alternatives. Differentiation is absolutely vital and you must not ever underestimate it. There is a couple of books that have been really influential in hammering this point home to me.

The first one I would like to mention is called Purple Cow. It is written by Seth Godin, the kind of godfather of marketing. And the core premise of Purple Cow is… whatever you do, you have got to stand out 241 you’ve got to be memorable. In the 22st century just fitting in with people’s general expectations, fitting in with the crowd simply doesn’t cut it anymore.

The second book that I really loved is called Zag and it is written by a guy called Martin Neumeier. And it comes at the same kind of thing, but from a different angle. It says, “When everybody zigs, zag.” You go in the other direction. What ever is going on around you, do whatever it takes to stand out, to be noticeable and to go against the flow. Zag is also full of brilliant examples that explain why and also how you can go about it.

So what I am going to be covering is broadly three steps that will help you to get into a really winning mindset. Okay, so let’s dive in.

These days so much to choose from that we are surrounded by so many brands and so many messages all of the time. What drives our decisions and our choices as clients and what drives our client’s choices. And I find that it really really helps me if I try and get into the head of my potential customers. So the first thing to note, which is really often overlooked, I cannot stress this enough is people who land on your website (generally speaking) want you to be the one.

No one really enjoys trolling search engine results. People say to you, “Oh you know, you competitors are only a click away.” And I would like to say to these doom-and-gloom merchants, “So what!”. You know, when somebody is on my website, we are half-way there. We are over the first hurdle.

And these people are going to fall into two categories. They are either going to be someone who is looking for what we do and if they are fantastic! All we need to do then is to communicate that, quickly and cleanly to them, without giving them any reason to click back to the Google search results. And if this people is in the other category of people who aren’t looking for what we offer, no problem! We have got nothing to lose. We’re unlikely to be able to turn them around at this point and they are probably looking for something else.

But what we might hope to do, is leave a positive impression so that one day when they are sitting there at there desk going, “Do you know what we really need is someone who does expert site reviews, or somebody who specializes in Web 2.0 design.” You might hope that hey remember you.

It is really important to get your head around this reality that people who are visiting your sites are your friends and they want you to be right, so all you have to do is not bugger-it all up.

Okay, so let’s take it for granted that your honored site visitor is in the first camp. They are here because they are looking for what you offer; they want you to be the agency for them. Moving on to step two… How to let them make a positive decision.

Now here my advice is, work out who they really are. Who are your real customers? I see a lot of small agencies and free lancers, who on their websites they try and betray themselves as something they’re not – either bigger or broader or more capable. We don’t need to do that. The absolute core of this whole blurb I am spatting at is don’t pretend to be a big corp megabucks agency, if you’re not. Yeah…

The whole trick is to be who you are, and portray that in a strong way that people love; that people connect with. I mean, you’ve seen all this stuff where people say, “We this and we that.”. You know, all over their website. When it is clearly one guy sitting in his bedroom. And there is nothing wrong with being one guy sitting in your bedroom doing work; there is a market for that kind of thing. And the other kind of stuff you find is people say is that, “Oh, we do work for clients ranging from 50-quid jobs (for small local businesses) up to mega-gazillion jobs for international blah-blah-blah…”. And you sit there going, you don’t do those kinds of jobs.

So who are you trying to win? Are you trying to win BMW and SONY and Disney? Do you think they… those guys are going to come along to your website and fall for this stuff? Let’s say they did.

Let’s go on a flight of fancy and say that the VP of Marketing for Disney lands on your website cause they just happens to find himself between web agencies, looking for a new one, and he goes, “Oh wow! These people seem to have a team although I can’t see them because there are no names and there is not much of a portfolio. And they say that they work with companies just like mine, a massive global conglomerate.” Let’s say you caught him on a bad day and he accidentally picks up the phone and calls you. How long is he going to be on the phone for, one minute 241 two minutes, before he realizes that you can’t possibly give him the security that he as a big-massive client needs. So we just need to accept that these aren’t the guys who will be paying your wage.

So think, “Who are the real people who want what you offer?” And then, we brand ourselves, we pitch ourselves for those people uniquely. There is no point in pretending to be what you are not. What you need to do is present what you are, in the best light possible, which brings us onto step three… How to show who you are in a way that wins customers.

So the trick is to examine all the aspects of what you are, what you do, and how you work whether you perceive it as positive or negative. And build those things into a brand, into a whole impression, that really delivers for you. So let’s get back into our customers head.

Who are they, first of all? So they are not BMW and Disney and all of these guys. They aren’t going to be paying your bills. Who is going to be paying your bills? Who needs what you have? This is a two-way match between supply and demand. You can’t just be what you are not. You can only offer what you can offer. You can’t sell to people who need something else.

Let’s start with the givens. Let’s start with what you are and what your capabilities are, what you can do. And then, picture a market for that. But the trick here is to select what to show that might make you memorable and create a connection.

Often the things that you might perceive as weakness… for example if you are stuck in that mindset of thinking, “You need to pretend to be a massive full service agency.”… the things that you think are weaknesses may in fact be real strengths if you can spin them right, if you can present them in a right way. But, fundamentally this is all about getting your head around it.

Branding isn’t about pretending to be something that you are not. Branding is about working out who you are and what you really do and then standing there and saying it with confidence in a way that really impacts people.

Okay, so let’s look at a few things. Ah, you might be thinking, “We are not based in central London.” Great! You’re nearer to your local customers. You’re nearer your local small businesses who want somebody around the corner. They don’t want a big kind of so-ho agency.

So you are thinking, “We are just one person.” Fantastic! You have no huge wage bills and that keeps the cost down. And very often, your clients can know that they can pickup the phone, and might even have your mobile number, and they can pickup the phone and speak to you. And that is worth an awful lot to a lot of clients, knowing who is going to be on the other end of the phone.

“What about if you haven’t got an office?” Who cares if you haven’t got an office? You go to your clients and meet at their premises. It also keeps the fees down. Your local clients will respect that.

“You don’t know everything about web technology.” Who does? You might be a specialist in PHP or CSS. Or you might have a particular passion for religious organizations or green issues or whatever it is, whatever really floats your boat is whatever you want to do. Let’s do that.

Nobody knows everything. So if you are a small scale agency, we talk about this a lot, everyone has a network of other professionals and amateurs in your area, or around the world, who can help. And even the big agencies do that – everybody does that.

So what we are talking about is, say what you are really about. Lots of people make a positive decision to work with my agency, after reading our ethical policy that we publish on our website. And that works great for us because the kind of clients that we love to work for are actually attracted by reading that stuff and the other clients who are in industries that we don’t do, they don’t bother to get in touch. Which saves everybody time and effort. So now you are getting your brand together. We need to build in, what your audience wants.

So if you are really suited to dealing with other local small businesses, say. Think about what signs, what signals they are looking for to be able to make a positive decision to take the next step.

There are two important things to remember here. Remember the customer in on your side. They want you to be the one. And also, here’s a new one, you don’t have to close a sale on your website.

They job of the website is to get a qualified visitor from the point of first initial contact, knowing nothing about you, to the point of taking the next step. That’s it. So focus your efforts on giving the right kind of visitor, the right kind of signals, that you probably right for them. That is all that you need to do.

Now generally, you’ll be looking to reinforce just a few points and I always think of these as like check boxes in somebody’s mind. I like to picture somebody; think of what they look like, where they’re working, sitting at their computer typing something into a search engine and clicking on some results. And thinking, “What are the check boxes, what are the three or four check boxes (there are not usually more that that), in this person’s mind that I need to tick-off?”

And if you can tick-off those check boxes without upsetting the person, or giving them any reason to go away, and not believe in you then you’ve probably done your job. Then what you do is, you say (here is a call to action)… “If you want to talk about this more, that is fantastic, pickup the phone and call me and I would love to speak with you!”

Let’s imagine, depending on the market you are talking to, what kind of check boxes might be in somebody’s head. I think very often that they are things like, “I can trust these guys.” or “They are not going to be too expensive and will fit my budget.” or “They like working with companies like mine.”

So they are looking for evidence of all of those things. And it might be like what we said before; “I can get somebody on the phone if I need help.” And clients aren’t necessarily super confident in their requirements. You know, if it is an engineering company, and they don’t really know anything about media or marketing in particular, then there is no reason to think that they are sitting there being really really cynical. What they looking for is a friend, they are looking for someone to be on their side and to help them through this process.

All we need to do is get them effectively to feel good about you 241 is really what we are saying. We have to get them from first finding you, to coming to a point where they have no reason to think you are not the right agency for them, then you give them a call to action and you say, “Let’s get together and let’s talk about we can do for you.”

The thing I would add here is to do with focus. You need to plan the steps from the home page through to that call to action. Now you know your website might only be one page. You might only need one page to do that. You don’t have to have a news section. You might not have news to give. Don’t put a news section on because it will be a dead pit.

You should put on your website only the things that you need to get that person from A through to B. And you need to be very very focused about it. So don’t put in more pages than you need. Don’t put in more images than you need. Don’t put in more blurb-bump-from-rhubarb, the more blurb-bump-from-rhubarb you put on your website the more you’re going to be watering down your message.

Get all of these steps right, you have done your job and you should see the difference in your bottom line.

Show 85: Bulletproof

Posted in Classic shows on July 3, 2007 by Paul Boag

On this week’s show: Paul provides some design advice for developers, Marcus provides so post launch pointers and we review Jeremy Keith’s Bulletproof AJAX book.

Podcast: Download (20.3MB)

Download this show.

Launch our podcast player

News and events

Unfolding the fold

The first news story today is actually not news at all. Well, its news to me (because I wasn’t previously aware of it) but the actual post was made back in December of last year.

The post relates to that most irritating of subjects; “the fold”. I have spoken about the fold many times before. The mythical point at which people have to start to scroll. I say mythical because this point changes depending on your screen resolution, browser type and toolbars.

The reason it is so annoying is because clients are obsessed with it. They are convinced that users don’t scroll (a perception rooted in the early 90s) and no amount of persuasion seems to change their minds.

However, hopefully the post I found this week will help. “Unfolding the Fold” is a post on the ClickTale blog that provides some hard stats about the fold and scrolling in general. It demonstrates that the vast majority of people scroll, with almost all of them scrolling right to the bottom of the page. Their conclusion is that there really is no reason to squeeze all of your content above the fold.

d.construct tickets on sale 10th July

If you are in the UK on the 7th September you should be sure to come to d.construct. d.construct is in my opinion one of the best web design conferences around. The reason I like it so much is that it works hard to maintain a grass root feel that is accessible to anybody.

For a start the price ticket is very accessible at £85 + VAT. Secondly, the whole thing happens on a single day so there is no need for expensive hotel bills if that is a problem. Finally, they have a great mix of speakers with many of the big names you would expect but also a lot of less well known people in order to “shake up the scene”.

The reason I mention it now is because the tickets are going on sale next tuesday (the 10th). Historically they sell out incredibly fast. Although this year they do have a larger venue and so that should help somewhat.

I really want to encourage you to attend this event if at all possible. I will definitely be there and it would be great for us all to meet up.

Fonts licensed for web apps

Talking of d.construct, Richard Rutter (one of the organizers of the event) has posted an interesting blog entry on “font licensing“. Admittedly font licensing, doesn’t sound very exciting but potentially it could be. Richard has spotted a press release from a prominent font provider. This press release talks about a new type of license…

Ascender Corporation announced a new licensing program for font software implementations with server-based applications.

Richard goes on to suggest this might be another move towards browsers supporting downloadable fonts. This would allow us to use whatever font we wished on a website rather than being limited to what the user has on his or her desktop.

Richard does warn that this might just be in reference to Silverlight, because Ascender does work very closely with Microsoft. However, personally within the context of Opera’s move towards downloadable fonts, I am hopefully this might be something more.

A new way to visualize your desktop

Finally today, I wanted to mention a technology called Bumptop. I recently watched a demonstration of the system and was blown away. Basically, Bumptop is a new way to work with files that mirrors much more closing the experience of interacting with your desk in the physical universe. You can stack files, throw them around and even crumple them up in a 3D environment.

When I first watched this demo it felt like a novelty, but the more I thought about it the more potential I saw to organize content in a more dynamic and flexible way.

What I like most about this interface is that it is not trying to teach us a new method of interaction. Instead it is trying to replicate something we are already familiar with. The idea of using metaphors we already understand is a staple of interface design and is what makes things like tabs, desktops and folders so successful.

I think as web designers we could learn from technologies like this. We should be looking to build on established conventions people understand rather than always seeking to do the next big thing or be innovative in someway. Bumptop is innovative but it does so in a way that is instantly accessible to everybody.

Paul’s corner: Design advice for developers

I received this great question from Simon that I thought worth addressing on the show…

I hear lots of questions about the technical and business side of Web design, but what I don’t hear is how do the already technical amongst us become better designers – maybe being a visual thing this just won’t work on an audio podcast, but at least you could give us your top 5 ways to grow artistically.

As has become tradition, I decided to blog on the subject a few days ago but unsurprisingly failed to stick to “5 ways to grow artistically”. Instead I managed to produce a long and rambling essay on “when designers design” which I bore you all with on the show.

Marcus’ bit: Post launch Protocol

Everyone, client and agency, seems to understand the principle of not letting a site stagnate. Content should be regularly updated and, ….and what?

We see a lot of client demands for content management systems that are then often not used for lengthy periods of time. Therefore I thought it could be useful to look at what options there are to a site manager after that big day when the site goes live.

Of course, not everything here will apply to everyone but hopefully some of it will.

News and events

Stories, articles, seminars, fun days, whatever. These are your opportunity to create new content very regularly.

Clients are invariably perfectly happy with their site when it goes live. This is understandable, they have more often than not spent months working on it, tinkering with this, fretting with that and a) they need to spend some time on other aspects of their job (that have been neglected) and b) the site really has never been more up to date!

But what often happens is that a couple of months down the line they realise that new content needs creating but they can’t remember any of the CMS training. The 50 page accompanying manual is too scary so things get left. This happens until we are asked to add the new content because we’re too busy and it’s urgent and often, later on, further CMS training is booked.

News and events provide a steady stream of new content that helps keep the site fresh but also the CMS skills of those looking after the site.

Shortcuts

Updating shortcuts to key content is again a simple way of refreshing a site’s content without putting that much effort in.

Homepage shortcuts tend to link to:

Latest news
Latest events
Repeated main navigation
Products
Special offers
Facilities e.g. login, subscribe etc
Important ‘deep’ content
Popular topics

I guess the point I’m making here is a lot of these shortcuts can simply be rotated giving a feeling of change on the site. For example, changing a link to a main section on a weekly basis is a simple task and one that does not require the writing of any new content.

Utilising usage stats may be a good way of seeing which areas of the site need further promotion. In fact, use everything at your disposal, stats packages, CMS, content suppliers, agency support contract, internal marketing team etc so that you are as informed as possible.

Imagery

Don’t just update copy. Adding new banner imagery can really rejuvenate a tired looking design. Always look to include appropriate imagery with news articles, events etc.

Communicate

Keep your eyes open to what’s happening within your company/organisation. There may be a new project/department/member of staff etc that might be outside your sphere, that would really add value to the website.

Make yourself (and your role) known to everyone. Send out questionnaires or surveys asking people what they want to see on the site or if they have any pertinent content.

Think big

Finally, don’t lose sight of the main purpose of the site while dealing with the smaller things. It may be that the main purpose of your site is to promote your brand so updating the look and feel of the site regularly may be a lot more important than updated content. In fact, continually evolving the design of a site over time is probably far more cost effective (not to mention the effect it has on keeping the site fresh) than ‘big bang’ redesigns every 3 years or so.

Alternatively, sales leads may be the site’s primary function. In which case, keep in touch with sales and experiment with ways to boost leads.

The other really big area that site owners need to look at is site promotion. This warrants a post of its own so I’ll look at that another time.

Review: Jeremy Keith’s Bulletproof AJAX

I have decided not to do “ask the expert” this week, so we can have a review instead. Unfortunately we don’t have the time to do both segments every week so I have to mix and match from time to time.

The book I want to review is “Bulletproof Ajax” by Jeremy Keith. I read it almost 6 months ago, but haven’t had an opportunity to talk about it on the show until now.

The book is designed to be the sequel to Jeremy’s previous book “DOM Scripting: Web Design with JavaScript and the Document Object Model” which was written as an introduction to Javascript for designers. Bulletproof AJAX is therefore written in a similar tone with the focus on making AJAX accessible to designers rather than providing the technical detail you would expect from a developers book.

I have to confess I found the book a little frustrating at first. As somebody that had bought and learnt Javascript through Jeremy’s first book, I felt a little annoyed that the first 2 chapters seemed to be dedicated to laying the foundations we had already covered in the first book. I am guessing the idea was that people could buy this book in isolation without first owning DOM Scripting, but in my opinion the amount of detail provided in Chapter 1 and 2 wouldn’t make that possible. For me those first 2 chapters felt like padding to make a short book feel slightly more substantial.

However, that criticism aside the rest of the book was definitely worth the very reasonable price tag. Jeremy has an excellent writing style that is clear and engaging. He seems to explain complex topics in such a manner that you wonder what all the fuss is about. You come away from the book thinking this “AJAX stuff” is easy and wondering what all of the fuss is about. Admittedly he only covers the basics, but it is enough to get you producing the kind of AJAX applications most designers would like to build.

But, Jeremy doesn’t shy away from the more complex underlying issues surrounding AJAX. In particular he talks about accessibility and ensuring your applications work with Javascript disabled. He does this through a technique called HIJAX. I will not endeavor to explain to you the details of it here, except to say it relies on the server doing most of the heavy lifting.

From applying the principles taught in this book I have to say the HIJAX approach works very well. All of the complex stuff is handled by the developers on the server side and I get to focus on how the information is returned to the user. AJAX is a funny area that sits between client side and server side and leaves designers and developers wondering who is responsible for what. Using the HIJAX approach taught in this book, the division is much clearer.

So would I recommend this book? As with DOM Scripting it depends on who you are. If you are a designer who has read Jeremy’s first book and would like to start producing AJAX applications then absolutely. However, if you haven’t read his first book then I suggest you do that first, unless you are already confident in producing unobtrusive javascript.

If you are a developer on the other hand then my recommendation is to steer clear. This book is not meant for you and you will find it frustratingly lightweight.