156. IE8

Posted in Classic shows on March 11, 2009 by Paul Boag

On this week’s show: Ryan talks to Andy Clarke about Internet Explorer 8, Paul looks at how to simplify your site, and Michael argues that marketing should run the company website.

Podcast: Download (27.7MB)

Download this show.

Launch our podcast player

Housekeeping

Don’t forget our SXSW coverage

Just a quick reminder that next week is our live boagworld show from SXSW. If you are attending the conference please sign up on upcoming and come along. If you aren’t then you can watch via uStream. The show is being recorded at 6.30PM (CST) at the Hilton Hotel, Room B.

Whether you can attend or not we would love to receive your questions for the panel. Email them to me ASAP!

You can also follow coverage of SXSW on the boagworld website, so check that out too.

A Website Owners Manual Discount

For those who don’t already know I have now finished the ‘Website Owners Manual‘. This means the book is moving into production where they give it the final design and replace my terrible illustrations. Hopefully this process should be finish by July when the book will finally be released.

However, the entire draft manuscript is available now in ebook format for those who cannot wait. Also with Manning’s early access programme you can preorder the printed book and get a copy of the draft ebook to read immediately.

To further sweeten the deal you can get a massive 40% discount if you use the code ‘AUPROMO40‘ at checkout.

To order go to boagworld.com/websiteownersmanual.

News and events

If only IE played nice

Let’s kick off with two posts that really makes you wish IE played nicely!

First up isFluid Grids, an A List Apart article that discusses fluid layout and the limitations of IE. In particular it focuses on IE6 and its failure to allow page scaling. When combined with the smaller resolutions of many netbook PCs, it is apparently that fluid layout remains an ongoing requirement for many sites.

The article takes you step by step through the process of creating a fluid grid system. Although it is very comprehensive, it does involve some serious maths and leaves you with an even deeper hatred for IE.

The second post I wanted to mention is written by Rachel Andrew and is entitled Developing CSS for IE6 and 7. This is a great introduction to building websites using CSS and surviving to tell the tale!

The emphasis is on the development process and how to address common IE problems. It is a very pragmatic article that is not afraid to mention the use of conditional comments and hacks. In fact in many ways it is the total opposite of a recent post on Sitepoint entitled SitePoint » 5 Reasons to Avoid CSS Hacks and Conditional Stylesheets. That post borders on naivety.

Its nice to see a resurgence of posts on CSS. They disappeared for a while and yet I believe there is still room for improvement in how we build sites.

Why Friends Reunited Failed

In last week’s show I talked about the harsh truths of running an online community. If that was relevant for you, then you should visit Andy Budd’s site and read this insightful post – Why Friends Reunited Failed

In his post Andy compares the failure of "Friends Reunited" compared to the success of Facebook.

The gist of Andy’s argument is two fold. Firstly, the site provided little to keep users coming back. Andy writes…

So with Friends Reunited once you’d registered, seen what your old friends were doing, connected with the ones you’d wanted to and had a laugh at the (hopefully) tragic lives of your childhood tormentors, there was very little reason to stick around.

Second, they decided to charge for membership, thereby changing the relationship…

Charging for a service changes the whole dynamic of a site and causes people to game the system in order to get the maximum return on their investment. So it becomes less of a community and more of a commercial relationship. Like a lot of commercial relationships, once the value runs out, people will stop paying and leave.

Its an interesting read and helps emphasis the importance of providing tangible value to your users.

WordPress overload

As you will know if you follow me on Twitter, I am currently in the process of moving Boagworld from Movable Type to WordPress. The primary reason for the move is WordPress’ vibrant development community. There are literally thousands of plugins available and endless tutorials and supporting material.

Although Boagworld does provide some marketing benefits to Headscape, it is still a side project. As a result, the time I can invest in it is minimal. Plug-ins allow me to add functionality and make usability improvements with minimal effort.

Interestingly as I have been making this transition, I have noticed a substantial increase in the number of WordPress related posts in our news stream. I am not sure if this is because I am more aware with them or Paul Stanton thinks I need a bit of help. Either way they have been useful reading.

Three in particular have caught my attention…

11 Non-Traditional Uses of WordPress – A great little post that demonstrates the flexibility of WordPress. It shows the blogging platform being used for everything from a Wiki to Contact Manager.
More than 10 "Must Have" WordPress Plugins – A collection of plugins which helps (among other things) to keep your content fresh, improve SEO and manage comments.
15 Useful Twitter Hacks and Plug-Ins For WordPress – Some great code snippets and plug-ins that allow you to do everything from encourage people to tweet your content to create an entire twitter page.

Interview: Andy Clarke on the release of IE8

Ryan Taylor: Joining me today is Andy Clarke. Hello, Andy.

Andy Clarke: Hi, how are you doing?

Ryan: Not so bad. And we’ve asked you on today to talk about the upcoming release of Internet Explorer 8.

Andy: Browsers, my favorite subject!

Ryan: Yes, well you seem to blog a lot about browsers at the minute, you seem to be talking a lot about Internet Explorer 8 especially.

Andy: Well, I’m kind of a bit of a grumpy old bastard, really, when it comes to browsers. And, so the topic of the moment, certainly of the last couple of weeks has been what are they going to do with IE8.

Ryan: Yeah, so should we be excited?

Andy: I don’t know whether we should be excited or whether or not the thing is a little bit of a anti-climax, to be perfectly honest. I think that there’s a huge difference between people like me who develop websites for normal people out there, conusmers who use the internet, and people like me who are aware of standards and passionate about CSS and maybe thinking about progressive enhancement and some of these other things. A huge difference between people like me and the army of people I know who work inside corporate environments. People who develop big banking finance applications, for example, where Internet Explorer is usually the vehicle that people access that content with. And I think that for those people, IE8 is a big deal. Particularly over what happened with IE7. So I think that for those kind of people, it’s going to be a ride again. But for people like me, you know it’s kind of a bit of a non-event, to be perfectly honest.

Ryan: And do you think they’ll start changing the way that they build websites because of IE8 then?

Andy: There’s an interesting kind of back story that goes on with what Microsoft did with IE, and generally speaking a lot of the problems that they have in developing that browser come because the people who build applications that are predominantly used by IE8 are not the people who are generally standards-aware. And this is why Microsoft has gotten themselves into so much trouble in the past when they have, let’s face it, done the right thing in improving the browser, particularly with IE7. And of course IE6 was famously full of colourful bugs, and all credit to the guys at Microsoft, who I know fairly well, in, you know they were very passionate about getting those things fixed. But of course when IE7 comes along and people that developed code for IE6 all of a sudden found their applications breaking, they didn’t look in the mirror and think, “Why is this stuff breaking? Is it my code? Is it something that we’ve done wrong or that we need to fix?” They blamed Microsoft. And Microsoft has this big thing about not releasing something that is going to, say, break the web. Well it won’t break the web, but what it might do is break applications and break websites that were based on a broken browser. So it’s not a simple issue, unfortunately, and this is something that Microsoft struggled with for quite some time, and I know that they’re going to be struggling with again in IE8.

Ryan: You mentioned that the way that you build websites for your blogs isn’t going to change, but CSS tables are going to be available in IE8. Do you think that we’re going to see CSS tables more widely spread and adopted in web design?

Andy: I’m sure we are, I mean I’m always really pleased whenever there’s a piece of CSS that’s more widely adopted. IE in itself has been dragging its feet about CSS tables behind all other browsers. I think that, where appropriate, yes CSS tables are going to be useful, but I think there was a lot of excitement, I think wrongly, to do with CSS tables, in people thinking that all of a sudden we had a good way, or a new way of making CSS layouts. Something that was perhaps more reliable than using floats of positioning, and I think that the more and more that I look at that, the more I think that it’s essentially going down a wrong and a backwards route, if we think that mentally we start thinking about table cells again. What we do is we again start to tie what we see on the screen, in terms of the presentation, to form the structure of our markup, and that is always, always wrong. CSS tables do require that we order markup in a certain way, just like HTML tables did, and I think if people start to go down that route, then I think they’ll soon find that really there is absolutely no advantage, in effect, in replacing HTML table layouts with a bunch of divs and other structural elements and styling them like tables.

Ryan: Ok, so there’s going to be some improvements in IE8 over the previous browsers, but they’re introducing this compatability feature. Can you explain what that is? And share your views on it?

Andy: Aw, the famous compatability feature. Well, for those people who haven’t been following this thing for a while, and this goes back to what I was saying at the beginning about Microsoft’s core market, they have to be very careful that they aren’t seen as the ones who are, in their words, breaking the web when they fix some of the problems that they introduced before. So a little while ago they introduced this idea of using a meta element which would essentially tell the rendering engine inside of IE which version of IE that you wanted a page to look like. So, for example, if you were to use the IE7 meta tag inside the head of your document, IE8 would render your page as if it were IE7. Which, of course, is a great idea for these people who build these enormous IE-based corporate applications, because they don’t have to worry about IE8. They can simply stick this plaster on, this band-aid on, and go away and think “Great, I don’t have to think about IE8 now.” It gives them a little bit of breathing room. Now Microsoft originally wanted to introduce this thing as an opt-out process. Basically, the browser would render like IE7 unless you told it that you actually wanted it to render like IE8, which was completely backwards. So, a bunch of people – Jeremy Keith was the most eloquent as always – argued that this was a complete crock of shit and would essentially hold back any incentive for people to move to a better way of working, to use CSS and markup in better ways because of IE8. So Microsoft changd their minds, and they made it an opt-in rather than an opt-out. And
certain people took credit for them making that decision. I think only Microsoft know why they made that change. But interestingly in the last couple of weeks, it came to light over on the IE blog that they’re introducing this compatability feature which would essentially mean that anytime anybody pressed the “View in IE7” button, or used that feature, it would talk back to Microsoft. And then Microsoft would compile a list of sites that people clicked compatability-mode on, and then automatically, and perhaps without the viewers asking if they’d already opted into this thing, the browser would then hit a certain site and render as IE7 rather than IE8. That’s an interesting thing. A lot of people have been talking about the standards implications of that, and about the incentive for corporates to switch to coding in better ways. One of the things that hasn’t been talked about much is the privacy thing, the privacy angle. Essentially your browser is talking back to Microsoft in Redmond every time you look at a page. So I wonder, I’m a little concerned about this. I can understand why Microsoft do it, and I can understand why they want to try to find a way of not upsetting their core marketplace. And Chris Wilson, who’s a friend of mine and head of the IE team, wrote on Twitter, “Well can you think of a better idea for our customers, so that they don’t think,” I’m paraphrasing here, “so that they don’t think that we’ve broken the web when we launch a new browser?” And my answer to that is – it’s not your problem! If you make the browser, if Microsoft make the browser the best they can possibly make it, with the best of their efforts, and they are really smart people, then if websites break in IE8 that’s not their problem! It’s a problem for people like me, and it’s a problem for website owners and web designers that need to make their sites work in IE8. So I think, again, Microsoft are kind of barking up the wrong tree, but I can see why they have to think that they do it.

Ryan: Okay, well IE8 is also missing a few of the other more popular CSS3 selectors that are available in other browsers, like border-radius and things like that. Is this a setback for CSS3?

Andy: No, I mean it’s a shame that Microsoft haven’t introduced more of the CSS3 features to date, it’s frustrating for me because I do like to do the whole progressive enhancement/progressive enrichment type of thing, that I can’t have something that looks fantastic in Safari or Firefox, or possibly Opera, looking as good in the browser that obviously most people use. But I think that there’s a bigger issue here in that there’s a technique available for browser makers, to implement some not quite ready features of CSS3 at the time that they choose. That’s this whole kind of “-moz, -webkit” thing. And it’s a very good way, it was designed obviously for browser makers to test implementations of CSS3 properties so that then they wouldn’t break when they switch to the real thing. So if you do –moz border-radius, you could then switch to border-radius and it would do the same thing. So it’s a great way for people to be able to test these features. The interesting thing, though, and this is the wider issue, is that there’s no strategic plan, either from the browser makers or, most importantly, from the CSS working group, where they plan in a timetable implementation of these new features. Now we’re not talking about the big design of CSS, and when are we going to get new layout features and things like that, but simple things like for example CSS columns? Webkit implements CSS columns, Mozilla implements CSS columns, but they do it independently, they do it when they want to on their own timetable, and what I’d really like to see is for these browser makers to get together and say “You know what in September, we’re going to introduce these columns across the board, and in October, or in our next release, we’re going to implement this across the board.” I would like to see them working together so that actually we can start to look at different implementations of, for example, columns. We can look at them in Firefox and we can look at them in Webkit, and we can go “He gets it right, that one’s slightly wrong” and then they’ve got a playing field to work on. And it’s much wider than the overall kind of “Is IE going to implement this or not?” The wider issue there, as I keep going on about over the years, is the whole process of developing CSS3 and the role of the working group.

Ryan: Yeah, it’d be nice if they’d collaborate on more things, not just CSS! So there are some new government guidelines in place which you blogged about recently for cross-browser testing. Is this going to affect the way you approach building websites, especially now that IE8’s coming out, and with looking at IE6 and all that. Are the guidelines going to affect you in any way?

Andy: Day to day, probably not. First of all, because I don’t build websites for government institutions. I don’t tend to do any kind of public sector stuff, for various reasons. And these are guidelines for government websites. So no, in terms of them affecting me on a day to day basis, no, because irrespective of my clients, I try to push as hard on the CSS progressive enhancement thing as I can. I think it’s very, very interesting and it’s a nice and mature approach that whoever’s drawn up these guidelines is taking, to actually understand that websites don’t need to look the same in every browser, and in fact they shouldn’t look the same in every browser. I think that’s a mature approach, and I think the one thing that these guidelines will do to help me is when, on the rare occasion, I perhaps haven’t explained something properly to a client and they come back to me go, “Do you know what? I’ve looked at this thing in Firefox and Safari, and it’s got these rounded corners on the boxes, but I’m looking at it in IE7, and they don’t have rounded corners. Why is this?” And then the whole topic of progressive enhancement comes up, and sometimes people get it, and sometimes people don’t. But actually having something there as a little bit of a thing in your armory, to be able to say, “You know what, websites aren’t supposed to look the same in every browser, and if you need more than my opinion on that, then take a look at these government guidelines.” Then yeah, I think that’s really, really good news for people who want to take this approach with CSS.

Ryan: Ok, that’s great! Thanks for coming on the show, and good talking to you.

Andy: Yep, my pleasure, nice to talk to a northerner for once, rather than that soft southerner that I sometimes get to speak to.

Ryan: Haha, okay, thank you very much.

Andy: He’s naught but a shandy drinker, you know that!

Ryan: He is but a shandy drinker.

Andy: Take care, see ya.

Thanks goes to Jason Rhodes for transcribing this interview.

Listeners feedback:

Should the web team sit under marketing?

Michael from Leeds recent me the following email which I want to share with you. I am not sure I agree with everything he says, but he puts together a good argument and I thought that was worth sharing.

I just wanted to drop you a line about your blogpost, 10 harsh truths about corporate websites that you featured on your podcast as well. I was sat listening to that and wanted to pick up on harsh truth #1.

You and Marcus were debating the issue of separate web divisions and whether web responsibility should lie within IT, marketing or your preferred option of a separate web division.

There is no doubt in my mind that a corporate website has to remain the responsibility of the marketing department. There is no other place for it.

The role of marketing is to assess a market and identify a need. Marketing then drives product development and the positioning of the product, developing the messages that convey what the product or service does. The final step is to choose through which channels these messages are best put in front of the target audience.

The website is part of that communication mix. The website for any business needs to be created with a view to acknowledging that a problem exists and convincing the visitor that it has a solution. It then needs to convince that visitor to act. Where else then can the website sit? Who else should be approving the messages the website conveys?

Where I think you guys are coming from (and your experience is not one that is alien to me after over ten years in digital on the agency side) is this. Often the person in marketing responsible for the website doesn’t have the knowledge, vision, experience or perhaps understanding to brief, specify, approve or even give a valid opinion on whether a website does the job. That is a problem with marketing, and not a reason to set up a separate web division.

I believe wholeheartedly that marketing needs a digital specialist within it. If a website is to be developed in-house then a specialist team (certainly not in IT) should be developed, but responsibility for the website needs to remain under the control of marketing. Just because someone in marketing hasn’t done a TV commercial before doesn’t mean that IT should handle that project!!

Even in seemingly non-commercial websites such as charities or universities there is a communication message and the comms team (marketing) is still responsible for the story and positioning.

My feeling therefore is that if a client doesn’t have the skills in marketing it is beholden on us as the agency to guide them through the process. I’m sorry to say though that many web agencies have a lack of marketing skills and can’t relate to the marketing team.

If you need finally convincing about this, think back to the copy interview you did with Relly in issue #154. In writing copy for the web and indeed for any medium Relly needs to understand what a product or service can do. She will be guided by a brief from marketing, not IT, not the web team. As an integrated agency we have five copywriters and the words are the message, the visual is the support and the dramatisation of that message. The copywriter is a key member of our web team.

Hope you find these thoughts interesting.

I debated as to whether I should respond to what Michael has written. In the end I decided not to. I want to leave it to you guys to decide what you think. In either case it is probably something we will be unable to influence, so to a large degree the debate is academic. Nevertheless Michael makes some good points which I can respect.

Keeping it simple

The second listener contribution this week is from Oliver in Kent. He writes:

One of my latest clients (I won’t mention who) has the website from hell. It is far too complicated and full of pointless unintelligible content. I have tried to encourage him to simplify things but with little success. You have spoken about simplicity before, but I was wondering if you might be able to provide some advice on how to get this client to throw out some of his pointless content.

It is a good question and needs answering in 3 ways. You need to understand the lure of complexity, how to identify it and finally how to go about reducing it.

In fact this questions led to a blog post entitled ‘3 secrets to simplicity‘.

154. Top Ten

Posted in Classic shows on February 25, 2009 by Paul Boag

On this week’s show: Relly Annett-Baker talks about good copywriting, Paul learns how to be a more efficient designer and we look at the ultimate website launch checklist.

Podcast: Download (31.8MB)

Download this show.

Launch our podcast player

Housekeeping

SXSW

Boagworld is doing loads of good stuff surrounding this years SXSW. The full details can be found here. However, the highlights are…

A live Boagworld show on Saturday 14th 6.30PM at the convention centre – With guests: Andy Budd, Daniel Burka, Joe Stump and Jeremy Keith. Please sign up on upcoming or follow via uStream.
The Great British Boozeup on Monday 16th at 7:30PM at Shakespeare’s Pub – An evening of great beer and an all British soundtrack. Again please sign up on upcoming.
Boagworld SXSW coverage – Instead of spamming both twitter and your RSS reader with content from SXSW, we are bring it all together on one handy streaming page.

So whether you are actually attending SXSW or not, hopefully there will be something for everybody.

News and events

The ultimate website launch checklist

Making a website live is a scary process. There is so much that could go wrong. However worse still, there is so much you could forget. When it comes to launching a website, you can’t afford to take chances.

Well, BOX UK has been compiling a website launch checklist that takes some of the risk out of the process. This list includes everything from validating your HTML to announcing the launch on Twitter.

If you are responsible for launching websites, then this post is a good starting point for your own checklist.

Mr Budd is on fire (not literally)

Normally when I write about the news, I focus on specific posts that have appeared over the last week. However, instead I want to draw your attention to Andy Budd.

In case you are one of the three people who haven’t heard of Mr Budd,let me give you a quick summary. Andy is a user experience specialist and founder of ClearLeft – an agency that does a mixture of web design work and training. Andy is also author of CSS Mastery, an excellent book that I highly recommend.

The reason I want to focus on Andy is because he has really started to churn out some superb posts recently. Although an accomplished author and speaker, Andy has written less on his blog over the past year or so. However, in this last week he has released two cracking posts.

The first is entitled "Don’t treat your website like a commodity" and focuses on how we approach the market. It warns against trying to artificially create a need for your site. Instead he suggests shaping your site around user requirements.

The second is entitled "Is your website like a leaky bucket?" and is in many ways a continuation of the previous post. In this one he warns against the mentality of continually driving new users to your site and instead encourages us to focus on retaining the users we already have.

With these kinds of quality post coming from Andy again, now is the time to add him to your RSS reader (if you have not already).

A win for the generalist

I am very much a jack of all trades and master of none. Others have accused me of ‘having enough knowledge to be dangerous’.

In the world of web design, specialists are the order of the day. As a result I am beginning to feel obsolete. However, perhaps that is a false perception.

If like me you are a generalist, then you may draw comfort from ‘Bringing Holistic Awareness to Your Design‘, a post on Boxes and Arrows. In the article they explain that if you want to build websites that score high in user satisfaction, you need a team with a good general understanding. In particular they wrote…

The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment "a holistic view" the more successful the project. In contrast, the more each team member was "siloed" into knowing just their piece of the whole, the less successful the project.

Now, the article does not apply that specialists are wrong. It merely points out that in order to build a successful website you need to see the bigger picture.

It goes on to identify 5 ways that you can ensure your team keeps this broad perspective. They are…

All team members conduct at least some user research
Team members participate in work and task flow workshops
Team members share and discuss information as a team
Team members prioritize information as a team
Team members design together in collaborative workshops

This is certainly something we have begun to take on board at Headscape and we would encourage you to do the same.

Interview: Relly Annett-Baker on Copywriting for the Web

Paul: OK, so joining me today is Relly Annett-Baker who is a copywriter over at poppycopy.co.uk. Hello Relly, how are you?

Relly: Hello, how are you?

Paul: So here we are, on the phone, after a false start.

Relly: I know, it’s good for an internet-based podcasting that we end up using the phone, but there you go. It’s reliable, I like it.

Paul: Yes, all that digital technology, it’s nothing but trouble. Good old analogue.

Relly: Yes, analogue beats everything.

Paul: OK, so we’ve got Relly on the show today to really talk us through some of the kind of fundamentals of copywriting, and copywriting specifically for the web and how we go about doing that. So, Relly, I guess the best thing to do is start with the absolute fundamentals here, and we’ll start by asking you what do you think makes good copy, how do you define good copy?

Relly: Erm, good copy starts with good writing, which sounds, you know, really obvious, but erm, really, unless your spelling and your grammar and your sense is not there, you’re not going to write good copy. So, that’s, you know, the start of it, so if you’re going to write copy, make sure you can write prose well, to begin with. Erm, beyond that, it’s then about… The difference between copy and normal writing is that you’re selling something, essentially, whether it’s a service or, er, an actual product, or, erm, even, you know, just an entire, just an idea. Erm, so, it’s about benefits, rather than specifications. A specification is, you know, what you put into your brochure when someone wants to know whether a dishwasher is going to fit in their kitchen. But, the benefits is much more about the time they’re going to save and be able to spend with their family, using your fantastic, very quick, very efficient dishwasher. Erm, and the other thing that good copy should do, above everything else, is entice a reader to investigate. Especially on the web, your copy has to earn it’s place; it has to earn an extra second of eyeballing, because people just scan on, we get so much information thrown at us, especially on the web, that your copy need to be clear enough that it can be easily understood and also enticing enough that someone wants to stick with you and find out more, rather than flick on to the next thing they can look at.

Paul: Umm. I mean, you talked there about "especially on the web", what do see as being the, kind of, primary differences between writing for the web and any other medium?

Relly: I guess the biggest difference is that print mediums are fixed, that’s why we have different editions of books or magazines that come out, whereas the web is fluid, so, the difference between wikipedia and the Encyclopaedia Britannica, and there are pros and cons for both of those mediums, erm, that they use, but mainly that you can alter things as you go, nothing’s ever sort of set down as "right, that’s what we said and we can never go back and change it". So, erm, the other thing is the web is used primarily for people that skim-read a lot of information and use it to gather information before they decide to go on and request a brochure or find out more about what it is that you’re offering. It’s usually the first point of contact for people looking up, so it needs to make a good first impression, erm, and as such it also needs to communicate what your company is like, what sort of, you know, erm, formalities you have, erm, how big you are, how small you are, and how you like to operate and convey that, er, which print very rarely needs to do, it’s often, by then, erm, when a print brochure comes into someone’s hands, they’re already aware of your brand and they’ve got a better idea of who you are.

Paul: Mmm, I mean, there’s the kind of one issue that often comes up with the differences between the print, er, printed medium and the web, is that, you know, that because people scan, copy on the web should be kept short. I mean, is that something that you would agree with? I know that I’ve seen, you know, some articles written on A List Apart written before, that say "no it’s not about the length of the copy, it’s about how engaging it is". So, I’m quite interested in your opinion on that.

Relly: Yeah, I would very much agree, that it’s much more about, erm, engagement rather than length. Often with print, you get told you have, you know, space for 250 words and that’s how long your copy has to be. With the web, your copy can be as long as it needs to be, but that’s not necessarily as long as you’d like it to be. But as long as you can keep people engaged and keep them with an interest to keep on reading, get more information about you, and then, er, essentially they can read 5000 words about you, but if they don’t press the button at the bottom that says "get in contact" or "ring us" or "do something", then that’s kind of all for naught. What you want is to, erm, your copy to be long enough to persuade someone that they want to take the next step and get in contact with you and make a, you know, make that step towards doing business with you.

Paul: Mmm, I mean you talk, you’ve talked a lot about engagement already, how do you go about engaging people as you write copy? What kind of tricks and techniques are there, or is it probably a lot more complicated than that?

Relly: (laughs) Erm, I wouldn’t say it was the sort of thing where there’s, erm, there’s one way to do it; there are different, different, erm, styles and it really depends on your audience. Erm, often when we think of copy we think directly of advertising, and when we think of advertising we think of billboards. Billboards have, literally, two seconds to engage you and fix a message in your head. So, they have to have a certain amount of shock-value, and that’s usually accompanied by a large image that ties that together. The web is a very different beast in that respect, in that you’re making a one-on-one relationship; you don’t have to talk to everyone in the street, you can concentrate on who you think your best customer is. You do research about you customers and your users, and then you write for them, and you write in a way that’s going to, erm, keep them reading. Erm, so it comes down to a lot of research about who you’re writing for.

Paul: Mmm, that’s really interesting, you talk about writing for a specific person or, er, a specific group of people, because, it sounds then like you guys suffer from the same problem that designers would suffer from, when a client turns around and says ‘our target audience is the general public’, and they won’t narrow it down any. So, er, is it fair to say that you’ve got the same need to prioritize audiences that a designer would have?

Relly: Absolutely, you cannot write something that is going to engage everyone all the time, you have to know who your audience is. Erm, and that often involves doing, you know, research that, erm, the clients themselves don’t necessarily take on as part of the need for copy, but, erm, often the product tells you what sort of copy you need to write. If you’re, erm, writing about a teddy-bear shop, it’s quite obvious that you’re not generally writing for a, sort of, you know, middle-aged, managerial businessman; you’re writing for either, erm, older women who collect them, or younger children and therefore you’re writing for parents. But when you get into services, it gets a bit more complicated and so you have to do more research about the people who make contact currently on the website, if there is an existing website, or, you know, what business they’re going for and who actually makes them, makes that next step, you know, and who predominantly makes up their sales; those are the people you should be writing for. I often say to, erm, to people who are writing, who are starting to write their own copy, to have a style guide and to practice that – try writing a letter to your best customer; obviously, you don’t have to send it, but, you know, as if you were going to address them, face to face, what would you talk about and how would you introduce your product, and what specifically would they be interested in about it. And once you’ve practised writing about your products in that manner, it feels difficult ‘coz it feels like you’re cutting off 50% of your potential audience, but if you can target on, you know, the 10% that make up your actual, erm, sellable audience, then your erm, your returns will be much higher.

Paul: Mmm, very interesting. I like the idea of getting people to practice by writing a letter. I can imagine that works very well. Let’s talk about, umm, some of the common mistakes when it comes to copywriting, ‘coz let’s face it, you know, the majority of websites aren’t, er, produced and written by, you know, er, trained copy-writers, or even (Relly laughs)… they’re either written by, erm, the designer when he gets completely fed up with waiting for content from the client, or it’s written by the website owner. Umm, in either case, you know, they’re not obviously as experienced as you, so I’m interested in some of the really bad mistakes you see coming up again and again.

Relly: Erm, the obvious one is when people take their brochure copy and just move that straight across to their website and say: "that’ll do, that’s perfect, that’s exactly what we want."

Paul: OK, we we always say that, why is that wrong?

Relly: Why is it wrong? Because, erm, your brochure should really be for when people have made contact with you and have an interest in your product. So then you can, you can work on selling them, you can, you can work on, er, getting past any of the objections that they might have, through a longer length of copy when they’re ready to address those issues, when they’ve already seen the positives. So, erm, your website should be… As an example, if you take, erm, say a hotel that’s, erm, setting itself up for events, or weddings, what a bride wants to see when she goes to the website is she obviously wants to see pictures of a lovely wedding, but she wants to know how the day is going to work for her, and why it’s going to be her, you know, perfect day. A bit further along the line, she wants to know how much glass hire is and how much it costs, you know, to have rooms in the hotel and she can be really direct in those. But, initially that first bit of copy needs to be one simple paragraph explaining why your hotel is absolutely perfect for her wedding day, as far as she’s concerned, the biggest day on the planet, and you have to make her feel she’s the most important person. Once she’s, once she feels like she wants to make the contact and book, the brochure can explain in far more detail what the liability insurance is, what the room size is; she needs to have a rough idea of these things, but they don’t need to be laid out for her, then and there.

Paul: Mmm, are there any other mistakes that you see quite a lot?

Relly: Yeah, people don’t revise or keep on top of their copy; so they kind of treat it like it’s been printed, and that’s it, they can’t ever go back and change it, or they feel they can only change it if they also change the design.

Paul: Yeah.

Relly: We’re starting to get past that a little now, erm, companies are getting a bit more used to the idea of blogs, and so they can keep updated in that respect. Erm, other mistakes people often end up writing for their client or their boss, rather than the actual audience, which goes back to, you know, what we were saying before, which is, you know, that’s a difficult one, everyone faces that where, you know, their boss says: "I think it should be like this", and if you know better, that’s, you know, that’s you having to then lay out why I think this works better because. Erm, but don’t, you know, be afraid to make the point that you are writing for the audience, the people that are going to buy and here are their needs and here are their requests, and this is how the copy has addressed that.

Paul: Umm.

Relly: And, I guess the other thing is that, erm, people (laughs), people who, er, don’t write very often, they fall into two categories, erm, especially with designers, this is so true, that designers either did art at school, because they wanted to get out of essay writing (Paul laughs) and therefore they haven’t written anything for a long time, and so they’re a bit rusty and they kind of need to maybe practice a bit before they lay something out and, you know, maybe hand it onto someone else and say: ‘does this make sense to you? Can you, can you read this out of context and understand, you know, where I’m going with it?’ Erm, I often talk about, erm, people using, er, text readers for the same thing; you know, I know they’re used in website design to check, erm, accessibility, that someone, you know is, er, able to have the text read to them and understand what’s going on they should be able to navigate around the website. It goes perfectly well for copy as well, copy is very much part of your navigation: it’s the information you’re imparting to that person. So that’s always a good way that, you know, if someone, if someone can read or be read the copy out of context and they get, you know, 70%, 80% of the idea of what’s going on, then you’re on a, you know, good track that way. Often you find that people, the other thing that happens is that people start writing and they get so excited about the fact that they’re writing, the prose just flows from them, like they were actually Lord Tennyson reincarnate (Paul laughs) and they come to the end and they’ve built up to a massive, dramatic conclusion (Paul laughs) about why their product is the best thing since sliced bread and actually that dramatic conclusion generally needs to be the opening statement, because it’s what catches hold of people and gets them to read onwards.

Paul: I mean is, I’m fascinated by this whole area of kind of trying to create a tone in your copy, er, because I’m not a copywriter, I write quite a lot, but in the sense of blog posts and things like that and so, whenever I’m writing, I’m writing in my own voice, if that makes sense. But, obviously when you’re writing for another site, when you’re trying to reach a very specific audience, when you’re writing within that tone of the website, that’s a very different kettle of fish and I’m interested in how you do that, how you go about setting a tone; how you go about sticking to a tone, you know, how do you do it? (laughs)

Relly: Ah, the creation of a style guide is very, that’s probably most important here. There are two things that I recommend when, umm, coming up with the, sort of the voice, the tone for a site, is to think about the persona of who that person is that’s writing, that’s especially true if you have multiple people who are writing as the same person, erm, often you find this now with companies that have begun to use Twitter streams and so on to communicate stuff and they they need to remain the same person, the, erm, NASA rockets do that very well, Discovery and the rest of them, they they’re able to communicate very well, both scientific facts and just, you know, prosaic information about the fact they’re bored of sitting on landing pads, launching pads and things like that and it’s quite nice because it’s able to communicate a human voice to something that essentially is a very complicated machine, erm, and the way that they’ve done that is to think: "well, if I, you know, it I was going to be a person talking about these experiences, what would I say?" and sometimes, you know, the most complicated, fascinating machine on earth, saying the most mundane things communicates more about their team that it could do than take a very long, scientific specification of what they were doing. So, it’s again going back to understanding your audience. NASA have understood that their audience on Twitter, they’re not space buffs, they’re people who are gererally interested, because most human beings are interested when a rocket goes up to space, it’s, you know, it’s an amazing thing, it doesn’t matter if you’re 6 years old, or 36 years old, it still seems, you know, astounding, that it happens. So, they’ve gone back and they’ve thought about, you know, how can we communicate to people every day and they treat the rockets as if they’re just people hanging around doing their jobs. just like everyone else uses Twitter. So, the first step is to understand your audience, and it takes a certain amount of, erm, it is quite cool to say but dissection, it is cutting out the people that you don’t want to talk to; people often know who their customers aren’t, even if they can’t quite focus on who their customers are and who their customers are becomes clearer with more and more research. Erm, a lot of what a copywriter does as research, right at the beginning, crosses over with information architecture, it’s a lot of looking at, erm, how best can we communicate these points and who really needs to know them and in what order? So you kind of, you go back and you assess, so this company is, erm, is selling er… they might be selling, we used dishwashers and washing machines earlier, so who’s the primary researcher and purchaser? It’s probably going to be, erm, it’s split probably 50-50 between female and male, as for the initial research, but they’re probably going to be above the age of 24, averagely; they’re probably going to own their own home and they might well have children and that gives you the sort of insight to the sort of family life that they have and what they, therefore, want to get out of that product. Erm, so then it’s erm, then it’s a case of looking at, I often go back then to erm, manufacturers, look how manufacturers’ websites work, how they describe their own products; what sort of visual advertising they’ve used to communicate these things and how that can be translated into words, what benefit are they selling with the visuals, often if I’ve been supplied visuals for the website, they can tie in together quite well. And then I create a persona, the person that is writing, you know, being the person who is writing for the website. So sometimes I’m a middle-aged man, sometimes I’m a teenage girl, sometimes, you know, I’m a cool, skating dude, it really, you know, it really depends on what, erm, angle I’m going for

Paul: Sure.

Relly: With the copy. I keep a swipe file, which is basically things that I take from magazines, from newspapers, from other advertising literature, from books, from articles, that I think has been written really well and I take it away and I say, I kind of take it apart and say: "what about that headline functions so well?" and "what about, what is it about this piece that talks so well to the audience that it’s that it’s going for?" that, erm, that’s especially good if, even if you’re not the target audience and you’re still engaged enough to read it; that’s, you know, often quite fascinating. One of my favourite places to, erm, take, er, hints and tips from, of all places, is the Daily Mail and the Sun (Paul laughs), believe it or not, because they are so good at putting across an emotive idea in very few words, there is nothing like a Sun headline for giving you a kick in the pants, for feeling, you know, and often you read it and you find yourself, erm, agreeing with the statement, out of hand, before you pull yourself back and go: "now hang on, no, hang on this is the Sun, I’m going to read this story first before I make up my own mind." (Paul chuckles) But, you know, they’re very good at doing that, and, erm, I mean it’s not ideal for everyone’s website, obviously, but to have the ability to do that, to take just a few words and make an emotive statement is really useful in copy, because what you want people to do, more than anything else, is feel that they must do something about getting hold of your product, they must find out more, they must buy it then and there, they must, you know, whatever is appropriate, you know, you’re not going to find many people who are going to one-click buy a conservatory so that’s not necessarily, you know, going to work so well, but you might well be able to get them to arrange to have someone to come round and measure for a conservatory and that’s the next step to getting them to do what you want them to do. Copy is all about behavioural management, essentially.

Paul: Yeah. I mean, it’s got a lot in common with design, you know. As I hear you talk, there’s so much overlap. I mean, but what’s so fascinating is that, you know, a client will spend a fortune on design and they will spend a lot of time and effort and forever express an opinion over look and feel and design, yet they don’t seem to want to invest money in writing good copy and they’ll say things like, you know: "content is king", yet they, there is this perception, I don’t know, is it a perception that they can do it themselves? Why isn’t it? Why is it so hard?

Relly: I don’t know. We, we poor copywriters, we are the Cinderella’s stepsisters of the web design world. Er, it’s especially true in web design, more than anywhere else that I’ve seen, erm, probably because the medium is that much newer, that, and it sprung out of interactivity, as opposed to, erm, books are about staid reading and advertising sprung from that; television and radio sit somewhere in the middle, but essentially it’s a written script, sometimes with pictures added. The web is a different medium altogether, it’s much more about doing, interacting and as more and more social media stuff springs up, you know, that’s more and more true and don’t get me started on the amount of companies that have got terrible facebook pages and so on. Erm, but again, it is that belief that it can be done by yourself; that’s not necessarily, you know, not true, you know, people can write their own copy, in the same way I can design a website – it might look like a dog’s dinner when I’m done, but I can do it. It depends, I can, I can start off, to turn it around, I know enough, I have enough of a little, you know, little amount of dangerous knowledge, to be able to put a blog up, design my own blog header in Photoshop and upload it and be able to update my blog day to day, but that doesn’t mean to say that I’m necessarily ready to design a site for a, you know, big multinational company that wants to sell direct from its website to multiple places around the world. The same goes with, erm, with copywriters. I think partly the reason that we get so little investment put in at the beginning of projects is that, erm, we’ve come to see creating a website as a visual thing, clients very often ask about how a site looks and they don’t care so much about how it works underneath, providing it works, which is the equivalent of asking a baker to bake an amazing cake and you get it delivered and it’s four tiers and it looks fantastic and it’s got these, you know, subtly crafted sugar-craft dancers on top and flowers trailing all around it and you cut it in half and it’s sawdust. And, you know, the copy very much does come under the sawdust category, we kind of get a bit left behind because everyone can write a bit and it doesn’t take that much, erm, knowledge to at least lay out something that makes sense, erm, I think it does kind of get neglected; erm, I often sort of say to people that, you know, that the copy is as much part of the navigation and the function of the site as anything you do with the menu buttons or whatever else, erm, and what we really need to do is to have designers… there are some designers who have the attitude that whatever happens after sign-off is no longer their concern, so the amount of sales that happen, whatever else, that’s not their problem, they’ve done their bit, they’ve designed a site, it works and it goes out. Whereas, really what we, what you’re then doing is designing for your client, erm, a very pretty picture-book of all their products, but that’s not necessarily a sales tool, so we need to look now much more at, erm, at websites as sales tools for companies and to people, you know.

Paul: So, I mean, where’s the line here, mind, because, umm, you know, I can imagine website owners sitting listening to this now going: "well, I mean she seems to be suggesting that we get a copywriter to write absolutely everything on our site", umm, but, you know, when you get into the realms of, you know, corporate blogs and things like that, I mean it’s going to cost a fortune, is it not, to get a copywriter involved at every stage. Where should a copywriter be involved, where shouldn’t they be involved, how do they fit in to the process?

Relly: Right, that’s a really good question. I don’t believe for one minute that you need to have, unless you have a site that need constant updating, you don’t need to have a content editor on-site all the time; in the same way that you don’t need to have a website designer on-site all the time, unless your website is constantly evolving. If you have a web team and your content changes a lot, then you might well want to think about getting a content editor in.

Paul: OK.

Relly: If you run an online shop and you change a few products a week, and you might introduce a few new products, er, via an email marketing, whatever, you might want to consider how much of that you want to give to a copywriter. If you’re updating a company blog and you’re sending, occasionally send out, erm, emails to old clients and invitations to new clients, you probably don’t need to get a copywriter, unless you feel it’s a better use of your time, and I think that it is the division a lot of the time, is that if you’re, if something really needs to sell, if it needs to make an impact, erm, I guess you wouldn’t find an advertising agency going ahead and taking on a billboard campaign, without getting a copywriter in, or their own in-house copywriter; it’s not going to be the managing director going: "well, we’ve got the artist to do this fantastic picture and we’ve bought all the advertising space, we’ve got a whole campaign rolled out, so I’d better think what we’re going to put on the, er, on the advert then." It just doesn’t work like that and that’s exactly, that should be exactly the same with your website. If you’re looking to launch a new campaign, if you’re selling something specifically, if it’s going to make a big difference to the way your company’s going to go, you want to get professionals in, and in this case it would probably be a copywriter would be the professional that you require. Erm, you know, you probably wouldn’t want to go and fiddle with your own plumbing, unless you have a very deep interest in DIY. It’s the same thing. Erm, but on the flipside of that, is that it’s, copywriting isn’t some arcane art that people can’t learn, in the same way that most people started learning web-design by sitting down in front of a computer, you know, bashing something out in Frontpage and going: "well, that kind of works", and then four years later cringing at what they’ve done. I think it’s very much the same for me, when I started writing copy and content, I was a radio producer and I have been responsible for some the worst chart hits in history (Paul laughs), you know, ascending to the chart because of the copy that I wrote, you know, to persuade people to buy the singles, you know, the competitions that we came up with, you know; it was my job, it paid my bills, buy I can’t say, you know, getting the cheeky girls to number 1 is my proudest achievement.

Paul: Oh dear.

Relly: And I was at least partly responsible for that (Paul laughs). I have to take my part in history on that one. Erm, you know, again it’s that thing, you know, anyone can go back and do it if they want to learn, you know, how to write copy. Just be aware that your first few attempts probably want someone to look through, but don’t be disheartened if you get to the end of it and think: "that’s not really what I wanted." You can always go halfway with a copywriter; I run workshops where I go into companies, talk to them about what their needs are, help them come up with a style guide, so they can say: ‘we’re going to write, it’s going from really simple stuff, like we’re going to have abbreviations and we’re not going to us the Oxford comma (Paul laughs), if that’s of any interest to any of you punctuation geeks out there, erm, right through to these are the sorts of people we’re addressing, these are there interests so we’re going to work these into this piece of copy, and, you know, I can then work with your staff members who will continue to write and then you’ve got, you know, a trained battalion of copywriters in-house ready to write things for you, on your behalf. And that’s often, you know, I often say to people that it’s not impossible to write copy, it just takes time to do it. As with anything else, it takes time to code a website well, properly and so that you can make a job out of it, it’s exactly the same with copywriting, but nothing stops you from building those skills up as you go.

Paul: That’s brilliant. That’s absolutely brilliant. It’s really good to hear a copywriter’s perspective on all of this stuff, because I don’t feel there’s enough really said about that part of the website and it’s been great to have you in on the show, Relly, and I really appreciate you taking the time.

Relly: Thank you very much.

Paul: So, thank you very much.

Relly: Thank you.

Thanks goes to Simon Douglas for transcribing this interview.

Listeners feedback:

Being a more efficient designer

Adam from Wales has written in with an interesting question:

Adam: With the economy tanking and client’s squeezing budget, can you give us any tips about being more efficient so we can turn around projects quicker.

It is a good question and one that got me thinking about creativity and its relationship with productivity. I also thought a lot about myself and how I work. All of this eventually led to…

10 Tips for Efficient Design

10 tips for efficient design

Posted in Design, Mobile on February 19, 2009 by Paul Boag

Being a good designer is not always enough to survive hard economic times. You need to be efficient too.

I don’t want this to be another ‘recession’ post. Sure, being more efficient in the way we work as web designers, makes us more competitive and keeps us employed. However, that is not the only reason we should endeavour to ‘work smarter’.

Working as efficiently as possible brings other benefits too…

More time – The faster you can turn around work, the more time you have for personal projects, family and friends. I don’t know about you but this is a major motivator for me.
Better promotion prospects – It takes more than good design skills to be promoted. You need to demonstrate that you are proactive and efficient in the way you work. Management will value you more if you generate a higher return.
Increased profit – If you are a freelancer it is all about maximising profit. The smarter you work, the more money you earn. It’s that simple.

So how can you be more efficient and begin to work smarter? Here are 10 tips that will get you started.

1. Use snippets

Let’s start with the obvious technical stuff. First make sure you have a library of code snippets that can be easily reused. These could include Eric Meyers CSS Reset or your own code for dealing with common HTML content such as news listings or pagination.

These libraries of snippets provide two benefits. First, they save a lot of typing. However more importantly, they ensure consistency across projects. Because you are using the same code for each project, all of the IDs, classes and structure remain consistent. This will save a lot of time when trying to remember why you built something in a certain way or how it works.

2. Use a Javascript library

In a similar vein to snippets I would highly recommend you adopt a Javascript library. Personally, I am a huge fan of jQuery because it is designed for those familiar with CSS. It is also amazingly easy to learn and very lightweight.

Using a library like jQuery has proved a massive time saver for me. It has allowed me to avoid endlessly battling with browser inconsistencies (at least in Javascript!) and avoid reinventing the wheel.

jQuery (like most Javascript libraries) also supports a large number of plug-ins produced by third parties. These too can be a massive time saver. However, a word of warning – be careful using a plug-in you do not fully understand. The quality of plug-ins varies massively and if you discover a problem with one, you can waste many hours trying to fix it, if you do not understand how it works.

3. Configure your tools properly

Often in our haste to ‘get on with a project’ we fail to take the time to prepare properly. One example is in how our software is configured. We settle for working with tools ‘out of the box’ when some minor modifications could improve our efficiency.

Photoshop is a good example of this. It has all kinds of configuration options from keyboard shortcuts to palette layout. Take a few moments to set these up for your workflow, and you could save hours of unnecessary clicking over the long run.

Look at whatever tools you use to build websites and consider how their interface can be tweaked to your needs.

4. Have one system for tasks

For fear of reinforcing a stereotype, designers tend not to be the most organised people. Not only do we need to organise the structure of our software tools, we also need to do the same for our projects.

Fortunately, not all of us have to manage entire projects. However, we do all have tasks that need completing. How we organise those tasks can dramatically affect our efficiency.

A common mistake with task management is to have tasks spread across multiple places. Some tasks exist as emails, some in a todo list, still more in a notebook or on your mobile phone. The result is that things get overlooked.

In order to efficiently manage your tasks they need to be gathered into a single central location. For me that is a task organiser called Omnifocus, which syncs between my desktop and iPhone.

Tasks are still collected using multiple methods. However, once a day I transfer them to Omnifocus. If I attend a meeting and take physical notes that include tasks, I put the notebook into my in-tray until I can add the tasks to Omnifocus. If I receive an email with a task, I drag that email into Omnifocus. Ultimately everything ends up in Omnifocus.

By being this regimented about the way I organise tasks, I ensure nothing ever gets missed. I also avoid wasting time trying to track down the details of a task I have lost.

5. Embrace and manage admin

Part of the problem we face is that answering email and organising tasks feels like a waste of time. Its not ‘proper work’. This is especially true when the pressure is on and deadlines are tight. We arrive at work in the morning and launch into our projects without checking our task list. The result is that we prioritise the wrong work and miss deadlines.

I begin each day by doing two things. I answer and file all my emails (I always achieve inbox zero). I then review all of my tasks and identify the ones that I wish to complete that day.

However, I don’t stop there. I have designated admin time. Once I am done my morning review I close my tasks and email until lunchtime. I focus solely on work and avoid admin entirely. This prevents email and other admin from interrupting the flow of my production work. It keeps me focused.

6. Distractions must die

Of course it is not just email that distract us from work. There is instant messaging, Twitter, Facebook, RSS and… lets face it… the entire internet!

Don’t misunderstand me, some distraction is good. I have a very short attention span and so if I work on a single thing for more than about 30-40 minutes I start to ‘zone out’. However, there is a difference between ‘having a break from work’ and ‘getting distracted’.

Every 40 minutes or so I will take a 5 minute break and fire up Tweetdeck or Google reader. What I try to avoid is keeping these applications permanently open (although with twitter I have to confess I often fail).

By leaving an application open that can distract you with notifications (‘You have a new tweet’, ‘You have mail’, etc.), you risk it interrupting your flow of work. These constant micro-interruptions make it hard to ‘get into the zone’.

7. Keep a tidy environment

Distractions extend beyond your PC as well. Your work environment can also have an impact on efficiently.

If you work from home, endeavour to keep your personal and work life separate. Ensure you can close the door on the rest of the house and that the rest of the family know not to interrupt. Also if possible, try to keep your working area separate from the rest of the house. A garage or loft are ideal. I used to work in a small room directly between our lounge and kitchen. It was impossible to focus on anything with the constant noise from the two rooms.

Pay attention to your desk as well. Keep it clean and uncluttered. This reduces distractions but also creates a better mental state conducive to work. Ensure your physical files and disks are easy to find. Knowing you took some notes that are in a notebook somewhere does not make them easy to find. This is especially true when your desk is three feet deep under paper work!

Personally I scan what notes and physical paper I can. What I have to keep in physical form, I file in a single filing cabinet organised alphabetically.

8. Avoid multi tasking

There is a myth that multi tasking makes you more efficient – it doesn’t! As designers we like to ‘flit’ from one thing to another. However, ultimately this is damaging to productivity. We need to learn to focus on a single task and follow it through to completion.

As I have already said, I find it hard to focus for any length of time. In order to help me focus I break my tasks down into smaller ones. That way I rarely have to do one thing for too long. Take this post for example. To write the whole thing from beginning to end would take a couple of hours. That is longer than I could focus for. So, in order to stop me getting distracted and jumping onto another task, I break it down. This post was made up of three tasks…

Once I complete one task, I switch to another project for a while. Once I have completed a task on that project I may switch back to this post.

Although this is a kind of multi-tasking, it is more structured and ensures I spend as long as my attention allows on each project. I do not simply drift between projects.

Depending on your character this might be too extremely. You may find it easy to concentrate for extended periods. However, if you struggle to concentrate, do not use multi-tasks as an excuse to be distracted.

9. Don’t do excessive hours

Another widely held myth of productivity is that the longer you work, the more you get done. After all, on face value this makes sense. However, I sincerely believe this is not true, especially if your job relies on you generating ideas and being creative.

Obviously we have to put the hours in, if we want to pay the bills. However, do not allow your boss or clients to force you into excessive hours. The occasional all-nighter is one thing, regular 12 hour days is another.

It is incredibly easy to get burnt out as a web designer. You are expected to continually be creative, as well as keeping up with one of the fasting moving sectors on the planet. Things are continually changing and evolving and it is a struggle to stay current.

Working long hours damages your capability to take on board new information and cripples creative thinking. Ensure you limit your hours and book regular holidays. Do not push yourself too hard or you will fail to deliver.

Finally, accept your natural cycle. When you are ‘in the zone’ work every hour God gives you. However, you must also accept that sometimes you need to just stop and rest. Don’t feel guilty about the days when you hardly do anything.

10. Communicate better

I would like to end this post with possibly the best efficiency tip of all – If you want to avoid wasting time, learn to communicate better.

So much of our time is wasted because of miscommunication and misunderstanding. How many times have you had to redo a design because you misunderstood the client or showed them work too late in the process.

Take the time to really engage with the client and understand their requirements. Make sure that you include them in the design process and show them work often and early.

Finally, use tools such as gallery sites, mood boards and sketches to ensure everybody has the same understanding and is working towards the same goal.

By effectively communicating with clients, you can potentially save days on each project that would have been wasted on reworks and amendments.

If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.

Boagworld at SXSW

Posted in News on February 16, 2009 by Paul Boag

Once again myself and Marcus will be attending SXSW. However, this year we are organised and have some great stuff lined up for you!

SXSW is probably the biggest event in the web design calendar and so we are going to be there covering everything that is happening. If you are going to be there then we have a couple of chances to meet up. If not, we still have you covered!

Boagworld live show

The thing I am most excited about is the live boagworld show we will be recording from the floor of SXSW.

We are not exactly Diggnation, so do not expect massive crowds. However, it should be a nice opportunity for those Boagworld listeners at the conference to get together and harass Marcus and myself as we try to record the show.

My biggest fear is that nobody will turn up, so I am tempting you with a stunning line up of guests! As well as myself and Marcus there will be…

Andy Budd (Author of CSS Mastery)
Daniel Burka (Creative Lead at Digg.com)
Jeremy Keitth (Author of DOM Scripting and Bulletproof AJAX)
Joe Stump (Lead Architect at Digg.com)

The show will be mainly listener driven so come along with loads of questions. We will get through as many as we can.

Finally, if you are unable to make the live show, we will try our best to stream it live via uStream.

To reassure me that we will not be recording alone, please signup on upcoming!

Great British Boozeup

Those who have been at SXSW the last couple of years will be pleased to hear that the ‘Great British Boozeup’ is returning.

This is the third year ClearLeft and ourselves have thrown the Great British Boozeup and this time we are joined by Naklab. Together we will be treating our American cousins to a good old fashioned knees-up to a soundtrack of great British tunes.

For information on where and when the boozeup will occur, check out upcoming.

Boagworld SXSW coverage

Last but by no means least we have something for those of you not attending.

I know how annoying it can be when you are not attending a conference. You want to know the highlights but you do not want your RSS reader full of endless posts or your twitter feed overwhelmed by chatter.

That is why we have created a SXSW coverage page where we will live blog the entire conference (or as much as we attend). Hopefully this will keep you up-to-date without it becoming annoying!

View our SXSW live coverage page

Our First AIR App

Posted in Development on February 13, 2009 by Paul Boag

With Adobe AIR now up to 100 million downloads, being utilised by big name players such as the BBC and increasingly invading our desktop Headscape decided to give it a go.

This is a guest post by two of the Headscape developers – Craig Rowe and Dave McDermid

Setting up

Adobe Air is Flash + WebKit + SQL Lite on the desktop. As a Flash developer you can dive right in and use the Air extension for Flash to publish your beautifully crafted swfs and AS code into an installable cross platform desktop app. However, the flash projector has been around for a while doing similar things and we wanted to put our hard earned web development skills to productive use. So we went the HTML/Javascript route.

The SDK is free for download but Aptana provides a rather neat eclipse based IDE in which to work. Handily the new project wizard allows you to import a multitude of Javascript libraries making it incredibly easy to get a new project up and running with your preferred initial setup (we went for jQuery).

The Problem

To make the exercise worth while we needed a real world problem to solve. Trivial examples usually do very little other than increase your ability to copy/paste example code and do your best fireworks night ‘ooo’ ‘ahh’ impression at it. Instead, we chose to add to our server admin experience…

As loving, caring web developers we actively monitor all our servers, and most of our live websites. For a while this was a DOS script, this was then migrated to a Bash script on a Cron job. It worked great, but required a computer science degree to maintain. So here was our problem: we needed a pretty, maintainable and reliable app to monitor websites. All it had to do was let us know when one disappears or throws a nasty error.

Download and try our site watcher AIR application

The Journey

Step 1: The wireframe

A new Adobe AIR project in Aptana comes with an html file named after your application which acts as your main program window. Creating a basic layout with a few buttons, titles etc can be done in a snap. The html, css and javascript are dealt with in exactly the same way as if intended to be deployed as a website (with no browser compatibility worries as we are only targeting the Adobe AIR WebKit rendering engine).

Step 2: The magic

The wireframe identified the main viewer as comprising of an unordered list of sites, each with their current status and edit/check/remove links. This list needed to be persisted, but editable by the user.

If this was a website we may be looking to server side scripting and a database of some nature. However, we had only jQuery and the air libraries. Although SQL Lite was an option we decided it was an over complication for what is a relatively simple, first AIR app. So, knowing that we could use jQuery to manipulate a DOM and the air libraries to save and open local files we opted for XML as a data source.


<?xml version="1.0" encoding="utf-8"?>
<sites>
<site address="http://www.headscape.co.uk/" status="200" frequency="30">
Headscape&#146;s website
</site>
...
</sites>

Looking back into our application html file we can see that we are given a readLocalfile() function that returns the string contents. This can then be passed into a jQuery object and manipulated in the usual way.

[The canny among you will notice that this readLocalfile() function is merely a few calls to the flash filesystem classes (using the AIR aliases). In fact at some points I directly call the flash library rather than using the AIR alias. There’s no functional difference, I’m just used to the flash namespaces]

With this ability added to the jquery ajax capabilities the application flow could be easily envisaged as follows:

On DOM Ready read the local xml file
For each site element in the xml create an LI element with the appropriate display and action elements
Fire off a jquery ajax call for each site
Use the response code to formulate a class for the LI to change its display
Fire off any notifications if the response code has changed i.e. e-mail, notification window, twitter post
Set a timeout before checking again
On window close parse the unordered list back into xml and write it to the persistent file

The Stumbling Blocks

Viewing the source of an installed AIR app can be done by nipping into program files (or Applications for the MACs amongst us) and looking in the application name directory. Here you will see the html, css and javascript files that make up the app (so we can continue to learn from others deployments just as we would with a website).

A brief look at the sitewatcher source and the flow described above becomes immediately clear. ‘Sitewatcher.html’ is our main form and it includes script.js as the main driver of the application with the #sites ul as the main containing element. The rest is GUI. ‘PopulateUIfromXML()’ directly completes steps 1-2 and fires off the 3-6 process via ‘CheckSite()’. However dispersed within this are the unusual non-front end website development bits, so we’ll look at those now:

Acting as a System Tray App

Many AIR apps, particularly those to do with notification (twitter, yammer etc) seem to want to run as system tray applications, we were no different.

The process of doing so is relatively easy, and encapsulated in the appropriately named SetUpSysTray() function of script.js. Essentially what we need to achieve is an override of the minimise behaviour, the setting of an appropriate icon and the associated window toggling behaviour.

Window.nativeWindow gives us access to the OS window holding our html window, and we can listen to events on it in much the same way. ‘nwMinimized’ is set to fire on display state changing and, if being minimized, instead docks (hides) the window and prevents the default behaviour.


if(air.NativeApplication.supportsSystemTrayIcon)
window.nativeWindow.addEventListener(runtime.flash.events.NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING, nwMinimized);
function nwMinimized(nativeWindowDisplayStateEvent) {
if(nativeWindowDisplayStateEvent.afterDisplayState == runtime.flash.display.NativeWindowDisplayState.MINIMIZED) {
nativeWindowDisplayStateEvent.preventDefault();
Dock();
}
}
function Dock() {
window.nativeWindow.visible = !window.nativeWindow.visible;
}

This works fine but on its own will actually just hide the window from view/the taskbar leading the user to have to use task manager to close it. To ensure that an icon for your application sits in the system tray we need to set an icon for the nativeApplication (the mere presence of which will cause windows to display the app in the systray).

Back to SetUpSysTray() and we’re using a content loader to load the icon graphic into memory, with an iconLoadComplete handler waiting to do the work:


var iconLoader = new runtime.flash.display.Loader();
iconLoader.contentLoaderInfo.addEventListener(air.Event.COMPLETE, iconLoadComplete);
iconLoader.load(new air.URLRequest("../icons/AIRApp_16.png"));
function iconLoadComplete(event){
if(air.NativeApplication.supportsSystemTrayIcon){
air.NativeApplication.nativeApplication.icon.bitmaps = new Array(event.target.content.bitmapData);
air.NativeApplication.nativeApplication.icon.tooltip = "SiteWatcher";
air.NativeApplication.nativeApplication.icon.menu = new air.NativeMenu();
// Create Menu Items
var openCommand = new air.NativeMenuItem("Toggle");
openCommand.addEventListener(air.Event.SELECT,function(event){
Dock();
});
var sep = new air.NativeMenuItem("", true);
var exitCommand = new air.NativeMenuItem("Exit");
exitCommand.addEventListener(air.Event.SELECT,function(event){
air.NativeApplication.nativeApplication.exit();
});
// Add Items to menu
air.NativeApplication.nativeApplication.icon.menu.addItem(openCommand);
air.NativeApplication.nativeApplication.icon.menu.addItem(sep);
air.NativeApplication.nativeApplication.icon.menu.addItem(exitCommand);
}
}

We simply set the native application icon to be the bitmap data before finalising the sys tray setup by creating a menu to appear on click.

Note for MACs: The minimised event listener is not applied if the system does not support system tray icons. This is to avoid confusion on MACs where a minimise goes to the MAC dock anyway.

Notification Windows

So the app can now run in the system tray and use jQuery to check the sites listed in an XML file at regular intervals. However we need a process of notification. The App could be running on an actively used machine in which case we want messenger style pop-ups. Or it could be running on a separate machine/server from where we want it to send e-mail/other notifications.

In the case of window notifications we took a short cut and used some example code from Adobe Developer Center. This is encapsulated within the DisplayManager.js and Message.js files. Display Manager acts as a queue, dequeuing and displaying on a timed basis if the user is present. This is an important requirement as you do not want a user missing a notification prompt merely because they were away from their desk for a while. It can be easily achieved via the USER_IDLE and USER_PRESENT air events – in this case stopping and starting the poller.

‘CheckSite()’ simply queues message HTML when the response code received is different from the previously stored code. When the queue poller is running (the user is present) the message is dequeued and displayed via Message.js.

At this point it is worth remembering that notification windows are no different to any other native window. It’s just a name we’re giving to the way we are using native windows. They therefore have their own events, contents, position etc and this can be seen by the Message.js code where a new chromeless, transparent native window is created and its contents loaded from the message.html template.

The display process is then as follows:

Message.js stores the message content in a variable on the new window
MessageScripts.js, then running once the message.html dom is ready, sets a listener on the HTML_BOUNDS_CHANGE event before setting the message variable content as the body – ultimately firing the bounds change event
This event is handled by setting the native window height to match before firing the layoutComplete event
On hearing this Message.js makes the window visible, finds an appropriate resting position (in relation to any other messages) and animates it in.

E-mailing

A key feature of any site watcher is to let us know when something bad happens. The combination of emails and an email-to-text service allows us to be notified the minute we spot trouble. This was easy enough in the bash script, using sendmail on the Mac. Not so straight forward for an AIR app. We can’t run sys commands and there is no built-in SMTP server. The solution is to use sockets in AIR. A little hardcore, but it keeps the solution nice and tight.

Anyone who’s sent an email with telnet will know that the principle of SMTP is, as the acronym suggests, simple. Adobe gives us plenty of clues for opening sockets and listening for messages. All we had to do was make sure we sent the right info. There are some restrictions in opening sockets from scripts outside the application sandbox, but for our purposes it worked a treat. With a little trial and error we were firing off emails left right and centre.

The icing on the cake was adding twitter support. With a one-line AJAX call in JQuery and a little config it was a no-brainer. This allows us to keep an online audit in the form of a private tweet stream. For people who check twitter more frequently than their email, it’s handy for notifications. If Twitter let us UK folk receive updates via SMS again then we can ditch email-to-text in favour of Twitter.

Step 3: The makeover

One of the nice benefits to working in the web-kit world is being able to use some CSS3 styling such as rounded corners. So we went to town. The more design that is CSS based and the less that is image based the better.

JQuery UI allowed us to make the entire list sortable in a sweep of the mouse, and the prefs popup tabbed in a blink (suddenly there was heaps to customise!).

The End

Hopefully this post has given you an understanding of how quick and easy it really is to make a useful AIR application. We’ve shown how you can implement a system tray application that utilises notification popup windows and sends e-mails as well as uses local files as a data store. This is not intended as a best practice discussion. It was our first AIR app and developed in a very small amount of time as a proof of concept and so that we could share our experiences with you. We welcome any feedback.

Download and try our site watcher AIR application

A demonstration of graded browser support

Posted in Design on February 12, 2009 by Paul Boag

In my post ‘Effective Browser Support‘ I explained how we should not be looking to make sites identical in all browsers, but rather focusing on usability and accessibility. In this post I demonstrate how that works in practice.

I recently launched a new Headscape service called the Consultancy Clinic. As part of this launch I created a small single page website. Let me use this site to demonstrate how graded browser support can work.

Remember – the idea of graded browser support is to support all browsers so that your site is usable, accessible and at least reasonably attractive. With that in mind lets start with the lowest common denominator.

Starting with the basics – HTML

All web browsers can support HTML. So as a bare minimum I needed to ensure my new website was usable and accessible in raw HTML format. To test this I used the free Lynx Viewer and it returned this…

Consultancy Clinic site viewed in Lynx

So far so good. But what about those browsers who think they understand CSS but don’t render it properly?

The pretenders

Unfortunately when it comes to CSS support things are not black and white. Although some browsers support styling flawlessly, others think they know what they are doing when they do not.

Poor implementation of CSS is the curse of older browsers. Browsers like Netscape 4 and IE 5 offer very limited CSS support and badly implementing what it does provide.

Instead of ignoring these browsers I create a basic CSS file which does some simple formatting. Instead of compromising the design to accommodate the limitations of these browsers, I deliver a simplified version which is usable and accessible.

Consultancy Clinic Website viewed in IE 5

As you can see the design focuses on some simple layout and typography. That way it avoids anything IE 5 may have trouble displaying correctly.

Dealing with IE6 and above

The next step was to create a more sophisticated design for browsers such as IE 6,7 and 8. These browsers understand CSS well but lack some of the more modern enhancements.

It was necessary to hide this enchanced stylesheet from ‘the pretenders’ who would render it badly. To do this I had to use a CSS hack, which was unfortunate. However, older browsers now completely ignore it.

How I did that is outside of the scope of this article. However if you want to know, view the source on the site and look for default.css.

This new design now renders perfectly well in the more modern versions of IE.

Consultancy Clinic website in IE 7

A watermark image is highlighted in this screenshot

There are however, subtle differences between the versions of IE. For example IE6 does not support transparent PNGs and so in IE 6 the watermark on the form does not appear. Although it would have been possible to force IE6 to display this image, it was more sensible to simply not show it. After all the watermark is an embellishment to the design, not a fundamental part of it.

The bells and whistles

Finally I have added some further embellishments to the design for more advanced browsers. For example both Firefox and Safari support border-radius. This allowed me to add curved corners, which are simply ignored by browsers who do not support that style.

Consultancy Clinic Website in Firefox

I was even able to go a step further in Safari because it supports dynamic shadows.

Consultancy Clinic website in Safari

Conclusions

Design enhancements like drop shadows and rounded corners are important, but not to the same degree as usability and accessibility. With finite time and budget, we are better spending our time making sure the site is usable on all browsers rather than getting it looking identical in a few.

With the time I saved not trying to force IE6 to display a rounded corner correctly, I was able to ensure the site looked good in older browsers with a limited understanding of CSS.

Once you accept that your site will not look identical in all browsers, you will be able to build sites faster, cheaper and ensure a broader range of devices can access them. Surely that is worthwhile?

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!

151. Budget

Posted in Classic shows on February 4, 2009 by Paul Boag

On this week’s show: Paul shares 5 tips for when your website budget gets slashed. We have a review of Dropbox and discuss ways to improve the typography on your site.

Download this show.

Launch our podcast player

Housekeeping

Two pieces of housekeeping this week.

WCAG2 Video

A couple of weeks ago I did an internal presentation to the guys at Headscape about WCAG2. The idea was to bring them up to speed on the new accessibility guidelines and also to put accessibility back at the centre of our processes.

At the last minute I made the decision to record the session and put the video online. Although the audio is awful (hence not using it in the show) it maybe useful if you have not read up on WCAG2 yet. There is also a transcript if the audio becomes too much.

You can watch my Introduction to WCAG2 here.

Win a copy of ‘A Practical Guide to Designing for the Web’

Mark Boulton has just released a book that covers the underlying principles of all good design. Whether it be online or in print, good design is governed by certain best practices. This book introduces the reader to these principles, including subjects such as…

How to start the design process
Research and ideas
An introduction to typography
The basics of colour theory
The rules of good layout

The book is unsurprisingly beautifully designed. However it is also well written and engaging. I can highly recommend it.

You could go and purchase a copy right now for only £12 (and I would encourage you to do so). Alternatively you could win one of three free copies by entering our twitter competition.

For your chance to win a copy of this inspiring book, twitter your top design tip using the hash tag #designTip. For example your tip might be…

#designTip – If you wish to draw attention to a design element surround it with whitespace.

The closing date for this competition is Friday 27th February, so get your tips in before then.

The winners will be chosen by Mark and we will direct message them shortly after the 27th. To ensure we can do so please subscribe to the Boagworld Twitter feed.

The winners will also be announced over twitter and on the boagworld podcast.

See the excellent tips that have already been submitted here

News and events

IE8 Cometh!

The big news this week is that IE8 has taken one step closer to being officially released by announcing their first release candidate.

According to the IE blog:

The IE8 product is effectively complete and done. Our next step, after listening to feedback from the final testing feedback from the community, is releasing the final product.

Although they do not provide a release date it is fair to say that it will not be long now.

Whenever I talk about IE8 people immediately ask if they can stop supporting IE6. My recent article on graded browser support should make my opinion on that clear.

However, the more important question is are you ready for IE8? Do you know what CSS properties it supports and have you tested your websites in it?

Microsoft provide a handy table of CSS selectors and properties that IE8 and indeed all other versions of IE support.

Once you have looked at that check out the IE8 readiness guide for developers. This has loads of information about IE8 support for CSS, Javascript and various proprietary features.

It also has a small piece of code you can fall back on if you are experiencing serious rendering issues on existing websites. By inserting this code into the head of your HTML document it forces IE8 to render in the same way as IE7. I am sure this will be a useful stop gap measure for website owners unwilling to pay for updates to their sites.

15 Tips for Freelancers Starting Their Own Business

Next up some great advice for web design freelancers. Think Vitamin have published a post entitled ‘15 Tips for Freelancers Starting Their Own Business‘.

In actual fact the advice applies to all freelancers, not just those starting out.

It is a fairly arbitrary list, but it has some good stuff in there. Just a few of what has been included are…

Move Out of Your Back Bedroom
Don’t be Afraid to Pass
Work on your Sales Technique
Learn About Personality Types
Maintain a Verbal/Email Relationship

If you are a freelancer looking for advice I can also highly recommend FreelanceSwitch.com, which is an entire site dedicated entirely to helping freelancers. Check it out.

Facts and Figures

This last week seems to have been a week of facts and figures.

The first figure that caught my eye was that Adobe AIR has been installed 100 million times. That is an impressive figure, even if it is being overstated as some believe.

Moving web applications to the desktop is an area I find particularly exciting. I am not sure it is always necessary. However, platforms like AIR make it scaringly easy, as we discovered when we did a proof of concept recently at Headscape.

The same announcement from Adobe also stated that Flash 10 has a 55% market penetration on Internet connected computers and they expect that number to rise to 80% by Q2 2009. This is an improvement on the adoption speeds of previous versions.

Other facts and figures to appear this week came from the "state of the web" survey carried out by Web Directions South. This is a survey of professional web designers and developers. Some interesting figures pulled out of the survey by Roger Johansson included:

The number of Mac and Windows users are almost equal â€“ both are used by 46.8 % of respondents
As many as 4.7 % use some version of Internet Explorer as their primary browser
Only 29.5 % test their sites in IE 8
Many more use XHTML than HTML
Over 10 % still use tables for layout
Almost 70 % still use presentational markup
Only 69 % create print stylesheets

Not sure these figures are particularly useful, but interesting none the less :)

Sprite Optimization

Finally today, I
would like to draw your attention to an interesting post by Dave Shea on ‘Sprite Optimisation‘.

Let me briefly explain what CSS sprites are in case you are not aware. Let’s say you have a button with three states – unvisited, visited and hover. Instead of having one image for each state of button you can use a single image containing all three states. You then use CSS to position the image in such a way that it only shows the current state.

In fact Dave Shea wrote an excellent article on ‘CSS sprites‘ back in 2004.

Dave’s new post demonstrates that this technique is now being taken to the extreme with sites like Amazon, Google and Apple cramming large numbers of sprites into a single image.

Whether this is entirely necessary for the types of sites most of us are involved in is debatable. The technique also has some drawbacks on devices such as the iPhone, where performance can be effected.

That said, it is a way of substantially reducing the number of calls to the server so causing pages to load faster.

If you are suffering from performance problems or have a project that requires lightning download then check out Dave’s post and also a CSS sprite implementation guide he refers to.

Feature: 5 options when website budgets get slashed

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? Read More

Listeners feedback:

I am very conscious that I have not been encouraging listener contributions and that is slack of me. This is a part of the show I really want to grow. As I have said before, Boagworld is about the community, not just my personal opinion.

With that in mind you can contribute in three ways…

Email – I cannot always respond personally but I read everyone.
Phone – You can either Skype ‘boagworldshow’ or call 020 8133 5122 and leave a message.
Forum – I often take questions from the forum, so make sure you join that too and get involved.

Talking of the forum, both of this week’s listener contributions come from there.

Listener Review of DropBox

From time to time we do listener reviews on the show and there is a section of the forum dedicated to reviews.

This week I have selected a review from the forum by Dave Redfern. He reviews DropBox, which although not strictly a web design tool will be useful to all.

Dave writes:

I came across dropbox last month thanks to the good people over at the mac roundtable podcast. Because i work on several computers from windows and mac machines in the same house, windows machines at work and at uni i am paranoid about making sure my files follow me around.

The basic concept of getdropbox.com is you install the software on each computer you have, then any files you wish to keep synced between them all you drop in this folder. If it is a public machine you can still access your files from their website although it is a little more clunky. You don’t need to set it to upload changes at a certain time or activate it, the software will automatically sync the folders whenever anything is changed.

A nice feature is within the dropbox folder there is a public folder and anything put in here can be accessed by anyone via a website link. the get the link all you need to do is right click on the file and select ‘copy link address’ and then paste it where ever you need. it is great for sending things to friends or showing clients screenshots of mock ups.

Preferences are very limited to limiting the bandwidth used at anyone time and changing the foler (although when i tried this feature i kept crashing my finder!) but simple is good sometimes.

It is free to sign up and you get 2gb of webspace free. you can upgrade to 50gb for $10/month or $100 for the year which seems reasonable.

the software is available for mac, windows and linux so perfect for anyone.

I will give it 3.5/5 at the moment. there is still some work to do on the software but a great start and very promising.

Personally I think 3.5/5 is a bit harsh but I know what he means. I love dropbox and have just paid for the 50gb account, but the web interface could do with some improvement. Also a native iPhone application would be nice.

That said we use it loads at Headscape to share files privately. It is perfect for that and online backup (including versioning) and I would highly recommend it to everyone.

Font Embedding on the Web

There is an interesting thread on the forum about font embedding that I also wanted to mention. Started by Dven he writes:

It’s a pretty popular subject but wanted to raise this to hear what your thoughts are on it all.

Basically a designer in our office found this link: http://www.fontburner.com. Thought that it be a good idea to maybe use in the near future. Now personally, I’m against embedding non-standard web fonts in this way.

The designer’s reaction. "its pretty much the way the design on web is going – limitations in type have always been a problem – not anymore. Its not the best solution, but pretty soon there will be a better one."

Be good to hear your thoughts?

After checking out Font Burner I discovered that it was a quick and easy way of adding sIFR to your site. We have talked about sIFR before on the show. It is a technique that uses flash to replace HTML text with your desired font.

I was pretty impressed by FontBurner but as Laura said…

It’s not the most semantic way to embed different fonts, as it requires <div class="font-name">text</div> if you want to change anything but <h1>.

Later in the thread Dvan went on to say…

These types of solutions are always prone to not working somewhere along the line. Guess I am kind of a very semantic guy and prefer to do things the ‘standard’ way.

Personally I do not feel that strongly. I think techniques like these are sometimes necessary to overcome browser limitations. That said, I do share his concern about these things not always being very reliable.

I actually rarely use sIFR. My preference is to make better use of font-stacks. These can be very powerful if used well. It is basically another variation on progressive enhancement. If the user has the nice font they get it, but if they don’t they get a substitute.

The reason most designers resort to sIFR is because the client insists on a
particular font. I would prefer to educate the client than resort to sIFR. By educating them over this issue you are laying the ground work for conversations about graded browser support and various other progressive enhancement issues.

On the subject of web typography, let me leaving you with a smashing magazine post that has come out this week – 50 Useful Design Tools for Beautiful Web Typography.

Video: Introduction to WCAG 2

Posted in Accessibility on January 26, 2009 by Paul Boag

I recently gave an internal presentation at Headscape about WCAG 2. A number of people expressed an interest in seeing it so I made a point to record it.

At the end the presentation I references a stripped down version of the guidelines found here.

I also refer to a quick reference guide to WCAG 2 that can be found here.

Apologises

Apologises for the poor audio quality of this video. Unfortunately the decision to record the presentation was made at the last minute and so we didn’t have a proper mic setup arranged. You can also tell it is not quite as slick as my normal presentations :)

~~I would also like to apologise for the lack of transcript of this video.~~ Again, it was not my initial intention to put this video online as this was an internal presentation containing my initial thoughts on WCAG 2. I am still learning a lot about the new guidelines and will publish a more considered article when I have a better understanding of the subject.

Feedback

On that subject, I would be interested to hear your feedback on the thoughts I present. Do you agree with my interpretation of the new guidelines? Have I misunderstood anything? Are there other elements I should have addressed? Your thoughts would be appreciated in the comments.

Update: We now have a transcript!

Thanks go to Anna Debenham who braved the horrendous audio to transcribe the presentation. If you cannot face the video we do at least now have a written version!

Paul: Ok, this has worked out a little bit weird because the idea initially with this presentation was that it was really about bringing us up to speed with WCAG2 now that WCAG2 has been released. But I made the mistake of mentioning it online and several people said "ooh, can you record that?" so now it’s a little bit of both, a little bit of a presentation to you guys and a little bit of a presentation that will go on the web.

Paul: So as you guys probably know, WCAG2 has now been released, and as accessibility is a big part of what we deliver and we talk a lot about accessibility, we need to be up to speed on it and we need to know what we’re doing. Obviously accessibility has become such a part of what we do day in and day out that we don’t necessarily think too much about it, it’s almost an intrinsic part of what we do, but with changes to WCAG2, or with the arrival of WCAG2, there have been differences, changes, things that have altered, so I want to make sure that everybody is up to speed with it. Feel free to butt in with questions, that’s absolutely fine.

Audience: Will the video be able to see the screen?

Paul: The video will be able to see the screen. Ok, so, WCAG2. Basically, WCAG1 came out in 1999 which is a good old time ago, in Internet terms that’s like forever, and there was a real need to make some changes and improve WCAG1. Let me just pop back and just explain.

The Journey to WCAG2

Paul: So, yeah, like I said, WCAG1 came out in 1999, it quickly dated as technology evolved, and some of the guidelines actually became harmful in a way. So you guys know that for example, we don’t always take note of what they say about Access Keys, we don’t always take note of what they say about "make sure you put text in an empty form field" and things like that. And WCAG1 was very much built with HTML in mind, and obviously the web is a lot broader than that and there are a lot more formats about. But unfortunately development of WCAG2 was very slow, and also fraught with controversy. I mean, famously with Joe Clarke who is an accessibility expert wrote on A List Apart "to hell with WCAG2" because it basically had become a bit of a joke, because it was very generic; they were trying to write a set of guidelines that really made no effort to mention specific technology because they didn’t want it to date like WCAG1, but the result is it became unreadable and nobody could understand it.

WCAG2 Reborn

Paul: But, things did change. Major changes were made to the WCAG2 draft and things did improve dramatically. They really listened to the community, and the language in it now is much clearer. So what I want to do now is talk a little bit through what WCAG2 includes and what it doesn’t, and how we’re then going to go about implementing it and how it affects us.

Principles

Paul: Ok, so let’s look at the structure of WCAG2. Basically WCAG2 has 3 tiers to it that you need to know about. Tier number 1 is the idea of Principles. So this is kind of the most generic of the tiers, you know, it’s really kind of aimed at the kind of things you would tell a board of directors that doesn’t really understand anything technical, that doesn’t really understand accessibility at all. And there are 4 principles which are the foundations of web accessibility and these principles I’ll come onto a little bit later.

Guidelines

Paul: Underneath each of those principles are Guidelines. So, within each principle there are 3 or 4 guidelines or a number of guidelines that is different for each principle. But there are a total of 12 guidelines, and these are goals that you should be working towards in order to make your content more accessible to users.

Success Criteria

Paul: Under each guideline, there are Success Criteria. So now we’ve really hit the nitty-gritty, these are kind of specific, measurable goals that you’ve got to achieve. And this is how you judge whether your site is WCAG2 compliant, if you like. So, this is the really important level if that makes sense, but it’s organised within this hierarchy of guidelines and principles.

Techniques

Paul: Now, actually, there is kind of a 4th tier as well which is techniques. So you’re trying to, maybe as designers, you’re trying to conform to the Success Criteria, well there’s a whole load of different ways and different techniques that you can do that and you could read about those, and you could make up your own techniques if you wanted to, but there are some laid down that can help you get going.

Working with WCAG2

Paul: So those are the 3 levels that WCAG2 is built around. Now let’s dive into those a little bit. I had to think about how much detail I want to go into in this room. Obviously we don’t want to go into every technique that you could possibly apply and we don’t even want to go into necessarily every success criteria. That’s really for you guys to look through afterwards. What we are going to do is look at those guidelines and those principles, and hopefully help you to understand where WCAG2 stands over stuff.

Perceivable

Paul: Ok, so, the first… heh, totally illegible text, isn’t that great. Very accessible!

Audience: (laughter)

Paul: So the number 1 principle is Perceivable, and that’s 1 of your 4 principles that you’ve got here. And perceivable is basically talking about "information and user interface components must be presentable to users in ways that they can perceive"

Audience: (laughter)

Paul: Unlike that! (points to presentation)

Audience: (laughter) Is the rest of the presentation like this?

Paul: Yes.

Audience: (more laughter)

Paul: You actually don’t need to read this anyway which is very useful. So, Perceivable is basically about "can you see it?", that is it as far as the principle is concerned, and the answer is "no you can’t". But perceivable then breaks down into a series of guidelines. So, let’s have a look at what these guidelines are. So basically, perceivable is broken down into 4 guidelines. And if we talk through each of those it should give you an idea.

Text Alternatives

Paul: The first one is text alternatives. So this is stuff we already know. "Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language." So this really applies to things like video, audio, forms that you create, and interestingly CAPTCHA is particularly mentioned here. And that is a particular accessibility problem that hasn’t been particularly well solved I don’t think.

Time Based Media

Paul: The next way that Perceivable works itself out is in time-based media. What we’re talking about here is that you need to provide an alternative for anything that is time-based. So here we’re talking about captions for video, sign-language maybe, media alternatives, but it also applies to live and pre-recorded video. So if you’re streaming stuff, then you need to think about this as well as with stuff that’s pre-recorded. Now, it does take into account the difference between "crap, how are we going to make streaming video accessible?". If you read into the guidelines it does give some good advice there. So that’s not quite as scary as it first sounds.

Adaptable

Paul: Anything that we produce needs to be adaptable. In other words, content can be presented in different ways. For example, a simpler layout maybe for people with cognitive disabilities for example. Really, this boils down to things like using semantic markup, meaningful order in your HTML so that if the CSS is stripped away it still makes sense in the order that it is presented, and not relying on colour and other sensory elements to convey information.

Distinguishable

Paul: And then finally it’s got to be distinguishable. So it’s about making it easier for users to see and hear content including separating foreground from background and that kind of stuff. So we’re talking here about contrast, colour, and control over things like audio and video, that kind of stuff. So that’s where we’re at with perceivable.

Operable

Paul: Let’s move onto the next principle which is Operable. So, Operable is about user interface components and navigation, and making them easy to use so that somebody can use them whatever disability they may have. So this again breaks down into 4 different guidelines, the most obvious of which is Keyboard Access. So everything that we produce has to be accessible via a keyboard. So, for example, the Flash video that we’re currently creating for the Wiltshire Farm Foods home page needs to be keyboard operated, alright? Which I bet it isn’t at the moment! And to be fair, it’s part of production, I’m sure they’d put that in at the end if I hadn’t reminded them. That existed under WCAG1, so there’s nothing different there. So everything needs to be keyboard accessible.

Enough Time

Paul: You also need to provide enough time for people to take in the information that they’re being presented with. So giving the ability to pause, stop and control time based material is really important as well.

Seizures

Paul: You’ve got to take into account seizures, some people can have seizures triggered by animation and that kind of thing, so there are various limits that the guidelines lay down about flashing objects and stuff like that.

Navigable

Paul: And then finally it’s got to be navigable. So this includes things like skipping content, having descriptive page titles, tab order, links that make sense out of context, lot’s of headings, that kind of stuff. Is this all making sense?

Audience: Yes, apart from time-based media, I don’t understand that.

Paul: Time-based media, we’re talking about video and audio. So let’s say you had… one of our podcasts. So, there are certain things we need to ensure. One is that it is operable, in other words, a user can pause the podcast if we get annoying, or they want time to take in the information that we’ve said, but the other thing is that we also need to provide an alternative way of them getting it which is why we provide the show notes that we do and the transcripts and stuff like that.

Audience: Ok, well that kind of fits under Text Alternatives and giving it control so it’s under Operable… I just don’t get where it is under perceivable, as a perceivable thing, it has to be perceivable?

Paul: Yeah, basically.

Audience: Video, audio… all has to be perceivable then?

Paul: Yes. Some of these principles and certainly some of the guidelines do overlap to some degree. But when you draw down to the Success Criteria level, of how you actually apply these things, then there are more specific techniques. I think what they did is create a load of success criteria, and then kind of chunked them together in meaningful groups, but sometimes they’re not so meaningful. But it is a vast improvement on WCAG1 as far as being able to understand it.

Understandable

Paul: Ok, talking of understanding it, our next one is Understandable. So this is the next one of our 4 top-level principles, so everything you produce has to be understandable. So what does that mean? Well that results in 3 guidelines. It has to be Readable, Predictable and has to be able to provide Input Assistance. So how does that work itself out in practice?

Readable

Paul: With Readable, we’re talking about making content readable, text content mainly. So this works out in things like setting the language in your HTML, you know, setting what the language is in the header, avoiding using jargon, finally we’ve got a decent reason to go back to clients and say, you know, "you can’t use that kind of language, nobody understands it!". Also things like abbreviations need to be explained, and also reading level as well, and that’s something I really want to get through to a lot of our clients because a lot of our clients, especially the public sector clients that we have, have this attitude of "well of course, people that look at our site are of post-graduate degree people, and they have excellent reading level", but that doesn’t take into account things like people that speak English as a 2nd language, who can be very intelligent but not particularly good at reading, also people with Dyslexia can be incredibly intelligent but not particularly good at reading. So reading level is an important aspect of it.

Predictable

Paul: For it to be understandable it also needs to be predictable. So with this we’re talking about things like consistent navigation, and no uninitiated changes. And this is a particularly important one in our world of AJAX and JavaScript and all this cool stuff that we’re doing where we can often trigger events without asking the user’s permission first. When I say "asking for permission" I mean they haven’t clicked on link or they’ve not initiated it in any way. Users need to initiate these actions… and no pop-up windows without them clicking first to trigger a pop-up and being aware of what’s going to happen. It’s all about making it understandable and making them aware of what’s going on.

Input Assistance

Paul: The last guideline under Understandable is Input Assistance. So this is going into the realms of when we do forms, how do we handle errors, what kind of feedback do we give to the user, what labels – are things clearly marked up as labels, are they descriptive of the fields and the forms and that kind of stuff. We’re also talking about help, what additional help are you provided in terms of tool tip and contextual help and anything else that you care to mention. So that’s Understandable, that’s what that principle is driving at.

Robust

Paul: The final principle is Robust. "Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies." In other words, what we build has to work on everything.

Audience: What about AJAX?

Paul: I think that’s where we get into the realm of progressive enhancement, that it’s fine to use something like AJAX as long as, if the AJAX is taken away, it still operates. Or, you provide an alternative version, the guidelines do actually accept that you can do alternative versions of something. So Gmail is a good example of that, Gmail, it actually doesn’t work if AJAX is turned off but they do provide an HTML only version of it which does the same thing. I’m not a great fan of that because it’s twice as much stuff to maintain, and one version become out of date and all the rest of it. My preferred technique is to build it so it works normally, and then to layer on the JavaScript and AJAX on top of it to provide enhanced functionality, which is what we guys have been doing pretty much all along and we need to continue in doing that.

Compatibility

Paul: So that Robust principle actually only comes down to one guideline which is Compatible, so that’s about maximising compatibility with current… listen to the wording of this… Maximise compatibility with current and future user agents, so we also need to be looking forward as well and predicting the future which is always good. But that’s where it comes back to using solid, good code that is’nt reliant on lots of hacks in order to get it to work, and it goes back to the conversation that we’ve been having recently about browser testing, upgraded browser support and that kind of stuff as well. So Compatibility and Robustness is the last principle. The other thing I should have mentioned with Compatibility is this also includes things like validation, making sure that your code validates, and just generally other markup type stuff.

What, no AAA, AA, A?

Paul: Ok, another thing that might have occurred to you is AAA, AA, A.. Priority 1, 2 and 3. Priority 1, 2 and 3 are still there, there are still those levels of conformance, but I get a real sense from the tome of this document, and this is just my personal opinion, people watching this video who know a lot more about accessibility might jump all over me on this, but my sense is that they were playing down those 3 levels of conformance. To be honest, I think I’m pretty keen on that. I don’t think those levels of conformance have done a lot of good generally speaking, because I think it’s kind of developed a checkbox mentality amongst some of our clients "We must be AA compliant" or "We must be A compliant" and they’re not actually thinking about the needs of the users, they’re just ticking the boxes so they meet some quota that has been established somewhere. One of the things that’s quite interesting, and I’m not sure if it’s a change from WCAG1 or not, I couldn’t find the reference in WCAG1 but again someone will correct me no doubt, but conformance in WCAG2 seems to be on a page-by-page basis. So you’re no longer in a situation where you want to claim conformance so you’re claiming conformance for an entire site, but you’re rather conforming on a page-by-page basis. And this allows you to basically pick-and-mix the level of conformance you want to reach on any particular page which is much, much more sensible because there are some elements where you might be building a particularly complex application that really isn’t going to manage being AAA compliant, whereas the rest of the site is AAA, and this one page isn’t. So it’s giving you the ability to mix and match. In fact, in the guidelines it says "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content. In other words they’re saying it’s just not possible to be AAA in some situations, so don’t even try.

Start With Basics

Paul: So how does this relate to what we do on a day-to-day basis? Well, I think the language we use with our clients pretty much will remain consistent with how it was with WCAG1 which is that we need to start of by encouraging all our clients to start with the absolute basics. A lot of people are put off of accessibility because of the enormity of it, of all the things they’ve got to do. And even to be single A compliant there is quite a lot to do if you’ve got a site that has never been built to be single A compliant before. So I think our attitude has got to be that you work towards this over time, it is an ongoing process, you don’t need to do it all in one big go and that you need to start with the absolute basics, the quick wins, the stuff… you know, it’s the 80/20 rule, 80% of the problems that people are going to encounter from an accessibility point of view is caused by 20% of the accessibility issues if that makes sense. So we can solve a small number of issues but have a big impact on the site. So we’ll start off with some real basic stuff. Things like putting in "alt" and "title" attributes, providing alternatives to media, things like video and audio, being aware of JavaScript and the problems that JavaScript can create if it’s not implemented correctly, providing resizable text so that the user has the ability to either increase or decrease the text size on sites, to build everything to be standards based because that makes it so much easier in future.

Audience: Aren’t we moving away from resizable text?

Paul: We’re moving away from the resizable interface where the whole thing scales up and down, but there’s no reason why we can’t keep the text itself rescaleable. The layers should be able to push up and down. It has to be said with resizeable text, it is becoming less of an issue. The reason it’s becoming less of an issue is because browsers now have this zoom functionality built into them. But I don’t think we’re quite there yet to be able to drop resizable text entirely is my current feeling… I’ve got mixed feelings about it. But the obvious aim we’re going for here is to be single A compliant.

Build Over Time

Paul: So all of this is about building accessibility over time. Taking the guidelines by themselves is not going to be enough, and taking this checkbox mentality that I talked about earlier is not going to be enough. Once you’ve done these quick fixes, the next step on from that is to start consulting with your community. We need to encourage our clients to start talking to their users and find out what accessibility concerns they have. I also think, which I think we’re quite poor at, that we need to start testing with real users some of the accessibility stuff that we do, and the big problem there is persuading clients to pay for that. It’s really hard to get clients to pay for that kind of testing but I do think that it’s a really useful thing to do, and there are organisations out there that provide people you can get in to do testing, or that you can send sites out and they test with them. So, testing with real disabled users is really worthwhile. I think it’s about identifying major issues and dealing with those first, just pragmatic kind of prioritisation of issues, something you do with usability. With usability you look for the quick wins and the showstoppers and those you deal with first, exactly the same with accessibility. Now, what the major showstoppers are for those navigating the site need to be dealt with. And over time you build towards AA and AAA compliance if you can. But you only do that maybe on some pages. The big concern clients have and the reason they get into this check-box mentality of saying "we’ve got to be double A or we’ve got to conform to the WCAG guidelines" is fear, a fear of litigation. Especially our bigger clients, they’re really worried they’re going to get serious issues. But I think it’s important to stress with clients that litigation doesn’t happen overnight. You don’t suddenly have come through the post a writ saying "you need to come into court about this accessibility issue on your site". It doesn’t happen like that. What happens in reality is the user complains. And if the user is repeatedly not heard and not listened to, and not responded to and not cared about and rejected, they get angry enough to maybe approach someone like the RNIB who then take it on into litigation for them. That’s the reality of what happens.

Quick Response

Paul: So as a result, you can diffuse that by responding to complaints quickly. So as you’re building up over time with the accessibility policy, if someone does complain, you need to write back to them and you need to deal with that issue straight up. Ok, so that’s how the client should be dealing with all this and there’s loads more I could say on this but I don’t want it to go on forever.

Headscape’s Approach

Paul: Let’s briefly talk about Headscape and our approach and how we should be approaching the subject of accessibility.

Establish Approach With Client

Paul: Well first of all I think everything that we do in our approach should be in conjunction with the client. I don’t think necessarily we talk enough to the client about accessibility. Some clients are just so bamboozled by it that they want us to take control, others want a say in it and what to be reassured that we’re doing something about it. So I think there’s a dialogue that we need to make sure happens. And if a client just wants us to take control of it, that’s great. If they want to be involved in the process, then that’s great to but we need to engage with the client and talk to the client more about it.

Remain Pragmatic

Paul: The second thing and I think this is really important is that we need to remain pragmatic in our approach to accessibility. Everything I’ve been talking about before like building up accessibility gradually, about doing the quick wins first and the show stoppers and that kind of stuff, that’s all pragmatic. I don’t want us on one hand to ignore accessibility, and it needs to be an integral part of everything we do, but on the other hand you can become extremist about it. We could spend hours and hours trying to get something to work in every conceivable user agent in the world and we can worry about every type of disability to the point where it becomes like a paralysis that stops us actually doing anything. So there’s a real balance that we need to strike here. And we need to strike that with our clients and working with our clients.

Have a rationale

Paul: Now I think it’s worth saying that if we decide not to comply with a guideline for whatever reason, we need to have a rationale for that. So we might not conform even to single A compliance in certain situations, although to be honest I can’t think of any off the top of my head, but if we do decide not to conform, we need a damned good reason why not. In other words, we need to have thought about it. And the other thing about accessibility is that we always think about it at the end of the project. It’s too late by then, we’ve built everything. So it really needs to become an intrinsic part of everything that we do.

Responsibilities.

Paul: Let’s talk about the idea of responsibility here and whose responsibility accessibility is within Headscape. Basically I’m going to say, everybody. One of the absolute great things about WCAG2 is because it’s got this 3 tiered approach, it is "accessible" to everybody. It’s understandable by everybody. So therefore it can be everybody’s responsibility to keep an eye on accessibility. And so this is how I think it should split down.

Sales/Client – Principles

Paul: Marcus and Chris and the Client should be worried about principles. The Operable, the Perceivable, those basic top-level principles. And you should be looking at anything that goes out from the company and going "well is that really operable?" So you can take a very top-level approach to it. And I think as you talk to clients as well you take this very top-level approach to it. That’s the level you guys should be working at.

Guidelines – Project Managers

Paul: Project managers, I think you need to be looking and understanding from the guidelines point of view. So you need to go in and read what those guidelines are, and you need to be sure that you understand them. And as you look at any work that goes out from the company, you need to be thinking "does it conform to those guidelines?" You don’t necessarily care about the nitty-gritty of how those are measured, or the nitty-gritty of how they’re achieved, but has that guideline been met? That’s the level you need to be working at.

Success Criteria – Designers and Developers

Paul: Then when it comes to the designers and developers, you need to get right into these guidelines. And you need to understand the success criteria and how to apply the guideline and how to make them work in practice.

Check Everything

Paul: So basically, we need to be checking everything that goes out the company for accessibility. And I have to say I’m making the mistake of saying this on camera, but I think we’ve got a bit lax recently when it comes to accessibility. We reached a point where it was becoming quite intuitive to us, and we were doing it quite naturally, and then as a result of that, we stopped checking because it was the natural process of what we were doing, and then bad habits start to seep in again. So WCAG2 is a great opportunity for us to say "ok, we need to start reviewing everything we’re doing as it goes out again". So I’d really, really encourage you to check everything.

Needs to be second nature

Paul: basically we need to get to the point where this is second nature to us, so that we’re doing this intuitively again, but not to the point where we’re no longer checking.

Audience: Clients often say "what’s the difference? If I just got for single A compliancy, what won’t my site be reaching?"

Paul: I have to say that I think I would stop talking about double A, triple A and single A compliancy. I don’t think there’s really any value any more in talking about that to the clients.

Audience: I think there is because having the page by page conformance is a really good thing and that we can now argue that yes, we can now make the majority of your site triple A compliant, but for a page full of videos, we can make it single A compliant.

Paul: Ok

Audience: Clients will continue to reference it in briefs. You can’t not talk about it.

Audience: I think it’s actually quite a strong thing.

Audience: is it a page by page compliance, or template by template compliance?

Paul: I think it has to be page by page because the content that goes into the page, into the template, could invalidate it. This is why I think it’s something that should be downplayed. I accept the clients will still talk to us about it, but clients still talk to us about doing speculative design, it doesn’t mean we do it. I think there’s an education thing there whereby we need to move clients away from being obsessed by double A, single A compliance, and to start thinking about accessibility policies. What is there accessibility policy and what is it that they are trying to achieve on their site? Our base mark is going to be single A, it’s always single A, and I think it should continue to be single A.

Audience: but if you don’t talk to them about it, you could argue that less caring clients would just say "well why would I do anything about it, bottom line?"

Paul: Yeah, I said you shouldn’t talk about single A, double A, triple A, but that doesn’t mean you can’t talk to them about accessibility and the improvements that accessibility brings because for people that have got that sort of attitude you don’t want to talk about the disabled if they don’t care about the disabled, you talk about search engines, and that’s the best way to sell accessibility, by talking about search engine placement. That’s the reason you want to be accessible for people who have that kind of attitude. For those that care, and are talking about single A, double A and triple A, you need to say to them "well actually, conforming with any level, it’s great that you want to do accessibility, and certainly single A should be an absolute minimum, but we’d encourage you to start working up an accessibility policy and looking at your site as a whole and say could this area do more in your site, your accessibility policy should do real world testing with real users…" all kinds of things.

Audience: So you think that we should be encouraging large organisations that have accessibility policies themselves that refer to double A, triple A, to try and persuade them to kind of move away from that?

Paul: No, not necessarily, I wouldn’t go that far. Don’t get me wrong, I’m not saying that they’re a bad thing, I’m saying they’re not the be-all and end-all. And at the moment I feel like the vast majority of clients think they are the be-all and end-all. They’re obsessed with putting that little badge on the bottom of the page. And it’s not about putting badges on the page. The trouble with institutions that have these policies of single A, double A and triple A is that these policies are in place for the institution, not for the user. And that’s my problem with them. That’s why I think we should try to break that mentality with clients. And I accept that sometimes we’re going to lose, and that’s fine. Exactly the same goes when we were talking about browser support. I accept sometimes we’re going to lose that battle as well. But it doesn’t mean we shouldn’t try and fight it.

Audience: I just wondered why WCAG2 still does it, because yes, you’re right basically, and accessibility requirements should be based on user requirements and not ticking boxes, so why is it still in there?

Paul: I think it’s in there because… my impression… I hate talking about accessibility on camera! You remember what happened last time in the podcast? It was just a nightmare! I think the reason it’s still in is because some of those success criteria are hard to meet. Some of them are damn difficult. When you start talking about streaming video, you’ve got some difficult challenges there that need to be met. So I think as a result, what the W3C is saying there is that we accept that some of these things are difficult to do. And we accept that you’re not always going to be able to do them, so we’re going to make them triple A. But come on guys, some of this stuff is dead simple and we should be doing it, that’s single A. That’s my impression of the mentality behind it, and that’s a great mentality, but it’s when someone changes that to being guidelines, which is what they are, to being rules, really instilled by Moses and presented to the people. You know it’s not that and I think that’s an important differentiation to make.

Where to Start

Paul: I know what you guys are like, especially designers. Ok I’m making sweeping generalisations here. But, if you guys go along to the WCAG website and you look at the WCAG2 guidelines, it’s horrible! It’s intimidating and it’s scary and it goes on for pages. And there’s a lot of text around it.

Audience: There’s no pictures? (laughter)

Paul: There’s no pictures! The design isn’t even very good. So what I’ve done is I’ve taken that page, I’ve literally all I’ve done is I’ve stripped out the explanation text in front of it, and the waffle at the end of it, and I’ve left you with just the set of guidelines so it looks like a slightly less intimidating list. Not much but slightly. So that’s up at http://www.headscape.co.uk/WCAG2 so if you go to that, you can get just the actual list of criteria. There’s also, on the WCAG2 website, there’s a thing where you can go and you can say my site uses tables, my site uses video, my site has this and that, and you untick the ones that it doesn’t have and it narrows down the list of success criteria to only show you the ones that you need to care about. So you might want to check that one out as well. Ok, so that’s basically all I have to say, are there any other questions before we wrap up?

Questions

Audience: Clients are going to ask us the 1 minute elevator pitch. What’s the difference between WCAG2 and WCAG1? What would you highlight as differences?

Paul: I think there’s a bigger acceptance of things in the world other than HTML, so things like Flash, PDFs, all that kind of stuff, there’s much more reference to that kind of thing. It’s much better written, much better organised. I think it’s more pragmatic. It’s a little bit more… I think it will last the test of time more. It’s hard to pin down exactly what I mean by that. There is actually a document out that talks about the specific differences between WCAG1 and WCAG2 if you wanted to get into that level of detail. And to be honest, I couldn’t tell you what that is yet because I haven’t looked at it in that much depth myself.

Audience: I think you and I do need a couple of the more detailed stuff, to get the guidelines, just one or two examples basically. Something that’s new between WCAG1 and WCAG2, and also some of the differences between single A, double A and triple A. The streaming video is an excellent example.

Paul: Just go along to http://www.headscape.co.uk/WCAG2 and you’ll be able to see those different levels.

Audience: It seems like, an almost unwritten principle, or unwritten in your list of principles. It’s technology agnostic.

Paul: WCAG2 started off as so technologically agnostic that it wasn’t understandable.

Audience: WCAG1, the first line is all about "it must be W3C technologies".

Paul: Yeah, it will pretty much accommodate anything. You know, it talks in terms of audio and video. It doesn’t mention Flash for example specifically, at least I don’t think it does, but it refers to those kinds of things. It refers to documents that are not HTML. I’m saying this as much for the video as anything else, I’m still learning about it as well. So I think it’s going to be a learning process for a while for us to really get to grips with this, and truth be told we probably should have started a little sooner than this, but it’s not radically different from WCAG1. This is as much getting us back into the habit of thinking about accessibility as anything else really. Ok?

Audience: 1 more question. Are they new Keynote animations?

Paul: Yeah, they are new Keynote animations.

149. White Hat

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

On this week’s show: How to become number one on Google *cough*, are customer testimonials worth it and how do you create a reassuring website.

Download this show.

Launch our podcast player

Housekeeping

Some housekeeping to kick off today’s show I am afraid:

Web Design Introductory Training

Drew and Rachel over at EdgeOfMySeat.com are running two training courses next month that look ideal for those starting out in web design. What is more they are offering boagworld listeners 10% off if they enter the promo code ‘boagworld’ at checkout.

The two courses are…

HTML and Web Standards for Beginners – 19th February

a one day course ideally suited to those wanting to get into web design, or perhaps for clients who have to format content with HTML for their websites. Covers the basic web standards principals of semantic markup and separation of content, structure and presentation.

Beginners CSS – 20th February

a one day course for learning CSS from the ground up. We go from zero knowledge right through to building floated, positioned and fixed width layouts.

For more information visit edgeofmyseat.com/training/

Bamboo Juice

Next up is a conference I am really excited to be speaking at. It called Bamboo Juice and is a one day conference taking place at the Eden Project in Cornwall. There is a growing line up of speakers that currently includes people like Jeremy Keith and myself.

It is great to see conferences happening further afield in the UK and I really want to see this one succeed. Please support it if you can. Cornwall is a stunning place and the Eden Project is a must visit. You ticket includes entry to the Eden Project so you will have a chance to look around.

Best of all the entire conference only costs £99! Please, please join us. Its going to be great fun and it should have a nice intimate feel with lots of time for chatting.

You can book your ticket now at bamboojuice.co.uk.

Consultancy Competition

Just a reminder of our free consultancy competition. Headscape are giving away a free days consultancy to a lucky winner. Email us with your name, URL and why you want us to help you out. We will pick a winner at the end of the month.

If you can’t wait that long Paul has started running mini-consultancy clinics via Skype. You can buy 30 minutes or more of Paul’s time and he will chat with you about your site, career or anything else (within reason). Its a bit of an experiment at the moment so if you are interested in trying it out visit the Boagworld forum where he talks more about the idea.

News and events

More on jQuery

If you listen to this show regularly then no doubt you will be aware of what a huge jQuery fan I am. I was therefore super excited this week to see the release of a new version of jQuery that builds on what is already an excellent Javascript library.

Most of the improvements are in performance. This is remarkable as jQuery was already one of the most lightweight and speedy libraries available. However, they seem to have made some significant improvements.

The main new piece of functionality is something called Live Events. Live Events allows you to bind events (such as a onclick event) to all elements even if they have yet to be created. Let me give you an example. Let’s say you wanted all links with a class=’external’ to open in a new window. Previously you would create a function that added an event to all links with that class so that when the link was clicked it opened a new window. The problem was that if you added more links dynamically to the page you would have to rerun the function if you wanted them to behave in the same way. With live events this is no longer necessary. This is a huge improvement and one that will streamline a lot of code.

I really cannot say enough good things about jQuery. It really is enormously powerful and a real time saver. What you can do with it is quite amazing as is demonstrated by a post from Smashing Magazine this week entitled "45+ New jQuery Techniques For Good User Experience". Whether you use jQuery already or not, check this post out. It will definitely give you loads of ideas for enhancing your sites.

Getting started with HTML 5

Talking of new releases, there is a significant amount of buzz surrounding HTML 5 at the moment. This is somewhat surprising considering it is a long way from being finished and some even argue we do not need it in its current form.

Cameron Moll does a nice job of providing a round up of what is currently being written about HTML 5 including a nice little summary at the beginning…

The world isn’t ready for HTML 5 at large just yet, but we can begin preparing for it by using common, semantic selector names (header, nav, section, etc.)

To be honest it is still early days for HTML 5 with ~~some estimating it will be released in 2022~~ some estimating that it will not be fully implemented by browsers until 2022. With those kind of timescales we can afford not to care. Jeff Croft puts it up nicely in his post "Two Thousand and Twenty Two" where he says…

It ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use.

Jeff came under a lot of attack for his post but I have to say I agree with him. What matters to real web designers and real website owners is what browsers will support now. So my advice is to ignore HTML 5 now and brush up on your WCAG 2 instead!

Web design trends for 2009

We turn now to the more immediate future and a post by the people over at Smashing Magazine. "Web Design Trends of 2009" endeavours to look at emerging trends that could become mainstream over the coming year.

To be honest I am not sure these are some much web design trends of 2009, as a look back at the end of the last year. However, it makes interesting reading none the less.

The trends listed include…

Use of letterpress typography, where text is ‘punched out’ of the background
An increase in the richness of user interfaces through the use of Javascript
The general acceptance of PNG transparency
Big bold typography
An increased use of font replacement using tools like sFIR
More sites than ever using overlay boxes to display images and video
A proliferation of video and screencasts
Blogs adopting a more magazine orientated design aesthetic
Lots of Javascript slideshows wherever you look

Nothing particularly surprising, but the article does provide some inspiring examples of these different trends and analysis about wh
y they are becoming fashionable.

Your website can thrive in a recession

We conclude today with another post about the recession. To be honest I am getting sick of talking about it. In fact I suspect it is turning into a self fulfilling prophesy. However, Gerry McGovern has written an interesting post about how your website could thrive in a recession.

The article mainly focuses on the cost savings that can be made by bringing customer interactions online. He quotes research which states:

the average cost of a web interaction is 27 pence, the average cost of a phone interaction is 3.76 Sterling and the average cost of a face-to-face interaction is 9.34 Sterling.

He goes on to say:

So, it is 14 times cheaper to allow a customer to complete a task on a website than to have the customer complete the same task over the phone. The Web is 35 times cheaper for completing such a task than a face-to-face interaction. Isnâ€™t that a compelling business case for a website during a recession?

It is an interesting argument and one that may sway some of the people holding the purse strings. However it fails to take into account the upfront development cost of moving customer interactions online. For better or worse companies are focusing on short term cost savings at the moment rather than long term expenses. As a result some web design projects are being put on hold.

Nevertheless if you work for an organisation that deals with a large number of customers then this article is a powerful arguement. It is certainly something that you need to show your boss.

Feature: Becoming Number One On Google

‘Become number one on Google’ – The dream of every website owner and titles like that grab people’s attention. What can you do to help achieve that dream without resorting to black hat techniques? Read More

Listeners feedback:

Customer testimonials – Are they worth it?

Question from Dave Rupert –

“Client Testimonials” – whenever some marketing aficionado comes up with these they want them on the site. When was the last time you thought “OOOOH CLIENT TESTIMONIALS!! OMFGWTFBMXBBQ!!1!” and clicked to go see a whole page of them? Are these out of date? Does anyone care about them? Are there examples of good implementation? Do you use Client Testimonials on your site? If so, why?

This is a good question because it has made me question something that I have always considered to be a really good thing on websites.

I think someone in Dave’s position – who I assume is a web developer/owner – won’t ever get excited about a list of client testimonials. Let’s face it, they’re not for Dave. They’re meant for visitors to the site to try and persuade them that buying a product or hiring a service is a good idea. The idea is that customers are far more likely to trust a testimonial from an existing client than the marketing speak on a website.

But this is where I have started to question my thinking. For example: “I am Mr X from company Y and I have to tell you that after using these people’s services I am now a better, more rounded person and I have decided to name my first-born after the MD”… this rather points to the fact that Mr X is the MD’s brother/drinking buddy/receiver of folding in a reverse handed way (delete as appropriate)… or even the MD himself!

So, do potential customers place any value in testimonials or do they instantly think they are fiction. In my opinion, I do still think they have value, particularly if you back up an online testimonial with that particular client’s contact details in a proposal. I also think that video testimonials have more value than written ones because (unless they are a complete setup) you will be getting the client’s real feelings and you can watch their body language.

Slightly going of point, regarding providing client contact details for inclusion in a proposal, I have started to ask potential new clients which of our existing clients they would like to talk to rather than simply providing a list chosen by me. I think this adds a further degree of trust.

Fundamentally, I do still think testimonials are a good thing and we will continue to use them on our site. But I don’t think I will be placing so much importance on them as I used to.

How do you make your site feel safe

Kevin Dees asks an interesting question on the forum:

I don’t know if this question has been asked before but I’m interested in what other designers have done to help make a site "feel safe".

Many times I find myself leaving e-commerce sites… because they do not feel safe. I find that this is due to poor design. Big flashing buttons and the like make me wonder if I’m going to get scammed.

So, I guess what my question is "how, as a designer, do you make your site feel safe, welcoming, and secure with the design itself? What are good practices? How do you make users go were you want them to, yet make them feel like they are still in control? What do you suggest adding or even keeping way from when it comes to design"

The answers he got in the forum didn’t really address his question. They focused on the realities of making a site safe (security and technology) rather than on the perception of security.

A site maybe the safest in the world but if the design isn’t right you are left with doubts. Take for example the new US government site that allows people to apply for visa waivers every time they travel to the US. One would hope that a site collecting that amount of personal data would be extremely secure but the design leaves you wondering if it is legitimate. It just doesn’t ‘feel’ professional.

I have spent a long time trying to come up with an answer for Kevin. However, I have found it hard to define what provides that sense of security. Part of the problem is that I think as a web designer I am more sensitive to the ‘vibe’ a site gives off than the average user. I am not sure I am best placed to judge.

Also, a lot of the things that occurred to me where content issues more than design. Delivery policy, site security, returns policy etc. are all content issues and so do not answer Kevin’s question.

However a few things have come to mind…

An attention to detail – Sites that lack an attention to detail always make me nervous. Poor browser support, bad grammar, inconsistencies and ill considered design reek of unprofessionalism. If I am going to spend my money on a site, I want to know that money and time has been invested in its creation. If an organisation is shoddy in the production of their own site, then I can probably expect the same attitude in the way they interact with me!
Structure – I think a strong grid structure is very reassuring. It conveys a sense of order that is disconcerting when not there. I think that is the problem I have with the US immigration site. The form you have to fill in is all over the place. Fields don’t line up and the site lacks any sense of order.
Colour – Misjudging colour can have a serious physiological effect on how we perceive a site. Some colours ar
e naturally more trustworthy than others. Blue for example has a very safe reliable quality. However using a conservative blue on a site aimed at young girls will project entirely the wrong image and make the audience suspicious of your site.
Trying too hard – Some sites just try too hard, shouting for attention. Flashy graphics, heavy sales copy and advertising orientated imagery all scream desperation and manipulation. People do not like to be manipulated or pushed into responding. They like to move at their own pace. Push them too hard and they will run away.

I am not sure I have done particularly well at answering the question either, but hopefully there is something in there you might find useful.

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.

Effective browser support

Posted in Development on January 5, 2009 by Paul Boag

Most web design contracts address browser support. Many agencies still treat support as a black or white decision – a browser is either supported or it is not. If the browser is not supported the site is often unusable. However, this approach fails to acknowledge the diverse and evolving nature of the web. We should be supporting all browsers.

What does ‘support’ mean?

Although we support all browsers, that does not mean every user will have the same experience. For example, it is unrealistic to expect a user accessing the web through a text only browser to have the same experience as somebody using the latest version of Firefox.

As Yahoo states in their own browser support documentation:

Requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.

Supporting a browser should provide the best experience possible within the constraints of that browser, and should exclude none.

Expecting pixel perfect accuracy across browsers is unrealistic and not cost effective.

The problem with pixel perfect design

With browser technology improving all of the time it is unsurprising that modern websites do not always render the same in older browsers such as Internet Explorer 6 (released 2001) as they do in more contemporary counterparts. In fact even modern browsers differ in the way they display HTML.

Many web designers go to extreme lengths to ensure consistency across their ‘supported browsers’. However although this is achievable if the number of supported browsers is limited, it comes at a cost. This includes:

Significant overhead in the time required to overcome limitations in older browsers.
Increased likelihood that unsupported browsers cannot access the site. This is because of hacks and excessive code employed to ensure consistency.
A tendency to design for the lowest common denominator.

A better approach is to ensure that the site works well and looks reasonable on the lowest common denominator browser, and then ‘enhance it’ for more capable browsers.

For example, modern browsers support design enhancements such as:

rounded corners
drop shadows
Improved typography

and various other styling not supported by older browsers without additional code and effort. However as Andy Clarke explains – because these design elements are not intrinsic to the usability or functionality of the site they can be safely dropped.

If this approach is adopted, it is less likely browsers will render sites incorrectly and so the level of testing can be reduced.

Testing

When a black and white approach to browser support is employed, testing can become expensive and time consuming. While website owners want to support as many browsers as possible, web designers want to limit the number supported to make testing manageable.

However, if a modern approach is adopted the burden of testing is reduced. This is because instead of testing focusing on pixel perfect precision across all browsers, the focus is on usability and accessibility.

Obviously, when claiming support for all browsers it becomes impossible to test in every browser combination. Instead it is necessary to prioritize browsers based on website statistics and ensure accessibility by testing in these.

The number of browsers and versions that a site is tested on will vary depending on the budget available for testing. However, even testing on a handful of browsers will normally cover the majority of users experiences (as a relatively low number of browsers dominate the market). In addition, those browsers that are not tested should reliably render the page because no unnecessary code or hacks are used to build the site.

Conclusion

In conclusion, building websites that are enhanced for more capable browsers – improves accessibility, reduce costs and ensure every user gets the best experience possible within the limitation of their choice of browser.

145. Baby Jack

Posted in Classic shows on November 26, 2008 by Paul Boag

On this week’s show Paul looks at how to communicate better with your users. Marcus examines ways to improve your contracts and Ryan has a baby (not actually on the show).

Download this show.

Launch our podcast player

Watch the behind the scenes video

Housekeeping

Two pieces of housekeeping before we begin:

First, congratulations to Ryan Taylor our producer and Michelle on the birth of their first child. We want to send our love to them all and welcome Jack Taylor to the world!
Second, just a quick note to say we will be holding our live Christmas special on the 8th December at 2.30PM UK time. The show will be an open question and answer time so either send in your questions in advance or come along and join us in the chatroom. We will also be doing a feature on this years top Christmas gifts for geeks. You can vote for your suggestions over at UserVoice.

News and events

Google goes social

The biggest and most controversial story of the week is the addition of SearchWiki to Google search results.

SearchWiki is a way for you to customize search by re-ranking, deleting, adding, and commenting on search results. You can move the results you like to the top or add a new site. You can also write notes attached to a particular site and remove results that you don’t feel belong. These modifications will be shown to you every time you do the same search in the future.

However, most controversially you can also share some of these changes with other users. This has led to fears of spamming and negative commenting as users attempt to manipulate the results.

Personally, this feels like a storm in a tea cup. It is an interesting new feature but I really do not see it catching on in any significant way. Only the most extreme power users will bother using these features and the majority will never see the change.

For example, even if website owners do attempt to manipulate users by spamming notes or adding negative comments about competitors, the vast majority will never see these notes. Users have to actively choose to view other users notes from a tiny link in the footer.

I say let stupid website owners spam these comments. It will keep them busy doing something which ultimately will make no difference to the popularity of their site.

Where this could be useful is when I can identify friends who I trust. Being able to see their notes or reordering of results would be of interest to me. Until then, this is non-starter.

In browser web development tools

In last week’s show we listed your top web development applications. Interestingly several of those applications were browser addons such as the web developer toolbar and Firebug.

This week Smashing Magazine has reviewed 15 in-browser web development tools that offer a variety of debugging and coding features.

The list ranges from the web known like FireBug to the more obscure like Fangs (for showing how a screen reader might read a page) and ColorZilla (for quickly listing all the colors on a particular web page).

Other tools featured include:

YSlow – a Firefox extension that analyzes a Web page for front-end performance.
Fiddler – an Internet Explorer extension that analyzes and profiles a Web page’s HTTP traffic.
DebugBar – a debugging extension for the Internet Explorer.
Web Accessibility Toolbar – an extension for Internet Explorer and Opera that quickly evaluating and analyzing your Web content’s accessibility.

If you are regularly coding this list is a must read.

From tables to CSS and back again

Kevin Yank, the co-author of Everything You Know About CSS is Wrong has written an excellent article on Think Vitamin telling us it is time to build websites using tables.

Before you all start sending Kevin hate email I should point out he is referring to CSS tables.

Let’s face it, the worst thing about CSS is its support for column based layout. Sure, it does a great job at absolute position but floats just make no sense! As Kevin writes…

You couldn’t come up with a more convoluted way of expressing page layout if you tried!

Fortunately with the imminent arrival of IE8 all major browsers will soon support CSS tables. This means any group of elements can be made to display like rows and columns within a table. Suddenly designing layout in CSS is as easy as using HTML tables.

I know what you are thinking… ‘what about IE6 and 7?’ Kevin addresses this in his article. He suggests that because it is so easy to layout using CSS tables we will have the time to design in CSS tables for modern browsers and the fall back on floats for IE6 and 7. He goes on to suggest that perhaps it is worth simplifying your design slightly for these older browsers to further speed up the process. He believes (and I agree) that clients would agree to this if they understood the cost savings.

Overall, I think this is a very exciting transition and one that will help bring across those hold out ‘table based designers’.

Advice for long term success

Our final news story today is some advice from the founder of Amazon. Jeff Bezos has done an interview with the ‘US News and World Report’ on how to run a successful business. The advice he shares is something that applies to all of us whether we are running a website or building a freelance career.

From reading the article I took away three lessons…

Have a long term strategy – Whether in business or running a website, you need to look ahead. Too many of us are thinking about the short term. What feature should we implement next? Where is the next salary is going to come from? Jeff encourages us to look further and work towards long term and visionary objectives.
Do not be distracted – Jeff also encourages us not to be put off by others who do not ‘get’ your long term vision. Stick to your guns and keep going. It is easy to have your confidence knocked by the criticisms of others or problems you encounter along the way.
Take risks – I am a great believer in taking risks from time to time. A part of this is excepting failure. If you want to double the amount you succeed you must also double the number of times you fail. As Churchill once said Success is the ability to go from one failure to another with no loss of enthusiasm.

Sure, the interview is not about web design and is written by a guy who can afford to think long term, ignore others and take risks. However, it is still good advice and something we need to take on board both as web designers and website owners.

Feature: Successful communication

We put a lot of time and attention into the content on our sites, but what about our other communications? We send out newsletters, post blogs, participate in forums. All of these reflect on our brand and the way we are perceived.

In this week’s feature Paul examines how to improve our communications with users.

Listeners feedback:

Sign-off and payment

We have this question from an anonymous listener:

I have a designer’s contract in front of me and I am getting a ‘feeling’. The contract doesn’t discuss much in terms of scope; just really limits risk for the designer. Though I can understand the need, I raise an eyebrow to focusing more on ‘not getting burned’ than ‘providing a good design’ … so here is the big question. The designer wants 50% upfront and 50% on an arbitrary completion date or “prior to file relinquishment, or upload and/or assembly of website on clients web server.” My thought is I am not paying $X for a pdf mock-up … I am paying for a site redesign and would like to see it work live prior to getting signoff. (or payment) Inevitably, there is a trust issue; I believe we have both been burned in past client/ designer relationships and are treating each other cautiously. Is there an industry norm which could help the situation? My perspective is how it will look live, especially considering different browsers, am I off base as a client to see the design work live prior to payment?

Ok, so picking this apart from the top:

Firstly, having a contract is a good thing. Full stop. But, you don’t have to blindly agree to whatever is put in front of you. If you don’t like what you’re reading then amend and send it back. This may also mean that you want to get legal advice – I guess that depends on your confidence dealing with the legalese involved in most contract documentation.

Contracts should be made up of two parts:

the terms and conditions (the legal stuff) that should cover obligations, deliverables, rights, liability etc.
the Schedule that should be a detailed description of the project – tasks, timescales, price, payment terms etc. It should also include detail on what the testing process is, what browsers/operating systems etc.

Ideally risk should be limited for both parties. A good contract makes expectations clear for both sides and lays out what should happen if something goes wrong.

Regarding payment terms, it is perfectly normal for a contractor to ask for a percentage of the total cost up front. But, it doesn’t necessarily have to be half up front, half on completion. We often spread invoicing over 4 or 5 different points over a project. This is good for our clients as it is an incentive for us to reach certain milestones along the way. One question I have here is – does this particular designer want payment literally on commencement? We provide 30 days for our clients to pay bills, so even though we may invoice on commencement, we will be a month into the project before we receive payment.

Ok, more detail… the contractor wants final payment:

On an arbitrary completion date – you should not agree to this. Payment by a particular date is not acceptable as the work may not be completed and the delay may not be down to you.
Or “prior to file relinquishment” – this is not unheard of. Basically, they are saying ‘you pay us and you’ll get your stuff’. Which is fair enough as long as you (quite rightly point out) have witnessed the site operating correctly in a ‘live’ environment. I’ll come onto this shortly.
Or upload and/or assembly of website on clients web server – this is what you want I believe.

A ‘live’ environment doesn’t necessarily have to mean your web server. We test all our web development work on our own development server prior to making it live and we ask our clients to sign-off on this environment prior to pushing live. We do, however, rarely invoice until the site is live because there are possible issues with the live environment that we may not have envisaged. Particularly, hosting platforms often need to be able to support certain technologies – if they don’t, you have a problem. If the designer is providing the hosting then that is unlikely to be an issue. It also gives them an option of taking your site down if you don’t pay. That way, they can happily make the site live prior to sending you the final invoice. Do they offer hosting?

So, in conclusion, I would push for the final invoice to be on live and tested release of the website. I would also propose that payment is split into 3 points – on commencement, on design look and feel sign-off and finally, on live and tested release.

144. Scale

Posted in Classic shows on November 19, 2008 by Paul Boag

On this week’s show Paul talks to Joe Stump from Digg about scalable websites, we review the best apps for web designers and investigate services for sending bulk emails.

Podcast: Download (28.3MB)

Download this show.

Launch our podcast player

News and events

How much should you charge?

If you are starting your freelance career the number one question you will have is ‘how much should I charge?’ It is important and yet strangely it is not something you are taught at college. Perhaps they don’t teach it because it is a damn hard question to answer. It is certainly something we have avoided talking about on this show.

Fortunately an article entitled ‘Six things to consider when setting your freelance rate‘ has been released this week. Although the article does not give a magic number, it does provide 6 valuable insights that will inform your final decision. These include…

Young freelancers and recent grads almost always ask for too little.
You can do things your clients can’t.
Your rate influences your perceived value.
You don’t get to keep it all.
An hour worked is not an hour billed.
The higher you start, the less you’ll need to increase.

I couldn’t agree more with everything said in this article. However, the one that really resonated with me was ‘You do not get to keep it all.’ Your rate has not only got to cover your billable hours but the cost of sales and marketing, as well as your various overhead. The article has a link to a superb rates calculator that helps you work out your chargeable rate based on these various costs. Definitely worth checking out.

A plethora of accessibility posts

With the implement arrival of WCAG 2.0. we are seeing a resurgence of interest in accessibility. This has led to a plethora of accessibility posts over the last few weeks. These include…

Writing good ALT text – This is a simple post about the use of the ALT attribute. It suggests two rules of thumb when it comes to writing ALT text. First, if you were to describe the document to someone over the phone, would you mention the image or its content? If you would, the image probably needs an alternative text. Second, does the alternative text of any images in the document make sense if you turn off the display of images in your web browser? Simple advice, but well worth remembering.
Designing for Dyslexia – This is a series of 3 in depth articles that look at the subject of Dyslexia. It asks what Dyslexia is and how we as web designers can improve our sites to accommodate the needs of Dyslexia users. Its interesting stuff. Part 1 defines what Dyslexia is. Part 2 looks at some of the conflicting requirements with users who have visual impairments. Part 3 suggests some specific things you can do to improve the legibility of your designs.
Accessible forms using WCAG 2.0. – This extensive post aims to provide web developers and others with practical advice about the preparation of accessible HTML forms. It compares the WCAG 1.0 accessibility requirements relating to forms with those contained in WCAG 2.0. Important stuff but not a 5 minute read!
Too much accessibility – The RNIB explains how the LEGEND tag can cause more harm than good if not concise and relevant. The reason? LEGEND text isnâ€™t read at the start of the FIELDSET, it is read at the start of the label. It repeats at the beginning of every single text label in that FIELDSET.

A business case for deleting content

I find myself using the word ‘simplify’ a lot when I talk to clients these days. So many website owners are constantly wanting to add features or content to their site. However, in reality we should be removing not adding to our already bloated websites. This is particularly true for large institutional websites. However it does also apply to smaller sites.

Take for example the Headscape website. When we started the redesign process for our site, I sat down and really thought through what information prospective clients wanted. The answer was very little. In the end our large text heavy website was reduced to a single page. That is the power of simplicity.

Gerrry McGovern summed it up perfectly this week in his post entitled the ‘Business case for deleting content‘. He wrote:

The more you delete, the more you simplify. The more you simplify, the more you increase the chances of your customers succeeding on your website.

We may think that we cannot delete content because ‘somebody might want it’ or because we believe ‘it will help our search engine ranking’. However, bloated sites bring complexity and with complexity comes confusion. The more content on your site, the less chance a user will be able to find the content they need.

12 principles for keeping your code clean

We finish today with a great post for those who need help with their HTML code. Whether you are a student learning HTML or a designer who is more comfortable in Photoshop than Coda, this is a very useful article.

The post provides 12 excellent tips for keeping your code clean. These include…

Use a strict doctype
Set your character set and encode those characters
Indent your code
Keep your CSS and JavaScript external
Nest your tags properly
Eliminate unnecessary divs
Use better naming conventions
Leave typography to the CSS
Add a class/ID to your BODY tag
Validate
Order your code logically
Just do what you can!

The article explores each of these points in depth and communicates clearly current best practice in coding HTML. Well worth the read even if only as a reminder.

Interview: Joe Stump on Building a Scalable Site

Paul: Ok, so joining me today is Joe Stump from Digg. Good to have you on the show Joe.

Joe: Oh, good to be here.

Paul: Have we had you on the show before?

Joe: Ah, not that I’m aware of.

Paul: Oh, wow, well we need to rectify that then. It’s good to have you on. Well, I have to say, this interview was arranged by Ryan, who is our producer. And he’s a developer, and I’m a designer. And he suggested we got you on the show, not that I wouldn’t like you on the show, obviously. That we got you on the show, obviously about scaling websites. Now, I’m going to be out of my depth very quickly here, so you’re going to have to be very gentle with me Joe.

Joe: Sure

Paul: So, in fact, it was so bad, that as I sat down to write questions I thought: "I don’t know what I’m doing here" , so I went and talked to some of the developers at headscape, and I asked some of the Boagworld listeners, and so we’ve got a little selection of questions for you, that, hopefully we can learn a little bit about how you go about doing things at Digg. Lets start off, what’s your job title, what is it that you do at Digg?

Joe: Ah, I have a really fancy job title that doesn’t mean a lot of anything, but ah, my official job title is "Lead Architect" and um, I think what best describes it, is that I manage the technical implementation on the code side.

Paul: OK

Joe: So, Digg’s broken up into a lot of different arenas on the tech side, we’ve got, R&D, which is headed up by Anton Cast, we’ve got operations, which is headed up by Scott Baker, and then under that are the people that I work with, ah, probably most closely in implementing solutions for Digg. Ron Gorodetzky is our lead systems engineer, Tim Ellis, also known as timeless, is our chief DB wonk, and then, Mike Newton is our lead network guy. So I think us four kind of steer the technical implementation along. The managers, ah, the manage, and handle the strategy and partners, and stuff like that.

Paul: You managed to say the word manager with real distain.

Joe: Oh, no actually, I have a great manager, John Quinn, he’s our VP of engineering, he’s by far the best direct manager I’ve probably ever worked with. Yeah, he’s really good.

Paul: OK, well lets go back in time a little bit. And start by, well, when was the point when you realized, that you were going to start having scaling issues with Digg? When did you start thinking about the whole subject of scaling?

Joe: Um, well Digg was pretty big when I came on board, so Digg was about 10 – 12 million uniques when I joined on.

Paul: Wow.

Joe: And I think we’d just cleared 35 million last month. So scaling was obviously an issue, but the big difference is that, I think sites generally go through a few different levels of scaling, where like the first one’s like, "I’m just going to throw it on a virtual server, or an Amazon server, you know, you’re basically just seeing if things are going to just "stick to the wall", and then they do. Ah, so the first thing you normally do is start breaking services off onto separate boxes. I want to put my DB on one box, my server on another box, and maybe memcached on each of them. And then you hit, read saturation on that one DB server, so then you go to the kinda next level of scaling. Which is where Digg was when I started, where you start dangling, a whole bunch of read slaves, off of your DB master, so, and for those who are not familiar with the master / slave terms, you send all your writes to one database server, and then that disseminates those writes to a whole bunch of slaves, and then you send all your read traffic to those slaves. So that’s where Digg was when I started. It’s write http traffic across a whole bunch of servers, its read traffic across a whole bunch of slaves, and then we have one master. And we’re now going through, what I think is the third phase, where you hit write saturation on your master, which is a bigger problem, because you then need to start sending some write traffic to some masters, and we’re actually going with a strategy that’s common with Facebook, and Flickr, and those kind of websites, where it’s called horizontal partitioning, where you put some of your records on one server, and the other records on another, so it’s like, you can say, for users, all users whose names start with A through J, would go on this database server, and K to Z live on this other database server. So we’re in the middle of implementing the first swipe at that. So we’ll be pretty aggressively into where everything will be federated and partitioned across a whole bunch of servers.

Paul: OK, one of the questions which kinda came up, which kinda relates to that, is, once you start spreading things across multiple servers, how do you handle things like user sessions, which have obviously got to be persistent.

Joe: Aha, so there are a couple of ways to handle that which, I’d say most people are handling it by.. There’s two ways, probably that you can do it easily. One of them, is if you have what they call "session affinity" on your load balancer, so the load balancer will say: "Oh, well this person, last time I had them here, they went to server A, so we’ll send it back to that server". So the session always lives on only one box. That’s one way to do it, we don’t do that here, we have a custom session handler in PHP which sorts the session in Memcache, and that allows you to.

Paul: Can you just clarify what memcache is, for idiots like me who don’t know.

Joe: Sure, memcache is a distributed caching system that’s actually, basically what it allows you to do, is expose a machines RAM over the network, and cache stuff into another machines RAM across the network.

Paul: Ah, OK

Joe: Yeah, it’s insanely fast, it was developed by Danga back in the day, and Brice Fitzpatrick, yeah so it’s heavily used by anyone whose scaling with LAMP, even a lot of people who aren’t. They all use memcached.

Paul: Wow

Joe: So, yeah, we store all of our session data in memcached, so PHP creates a unique session id, and we just stuff session data into that in memcached, and we can distribute that across, I don’t know, 50 or 60 memcached servers, and what not.

Paul: So how many servers do you guys have, it must be a staggering number by now.

Joe: Um, yeah, it’s kinda funny, every time I ask Ron that, he’s always like "Ah, I don’t know"

Paul: Laughs

Joe: Because we really can’t I mean, I couldn’t give you a specific number because on any given day, we’ll pull or push into production, a dozen servers, so, hundreds, there’s definitely hundreds in production. So.

Paul: I mean, with that many servers, so obviously you’re talking about taking servers on and offline, and all that kind of thing, I mean, making updates to the site, when Daniel comes up with some stupid idea, that you’ve got to apply to the site, of a new feature that he wants to apply on the site, and you’ve gone through the process of making it work. And you’ve then got to push it live.

Joe: Aha

Paul: How does that work? How do you go about pushing something like that live when there are so many servers involved.

Joe: So we have Ron Gorodetzky our lead systems engineer guy. So us developers have a bunch of M4 make files, that, when you check the code out, you run basically Make, Install, and it, for lack of a better word, it builds or compiles the website into a cohesive package, and then Ron pushes that to each server, I think he is still doing it by rsynch, but I know we are migrating over to Puppet, so it may happen via Puppet soon. The production side of things, is something that’s handled completely by operations, so I couldn’t tell you specifically how it happens, but generally, we make a tag of the website, and tell Ron, we need you to push "9.4.15" or something like that, and he does a checkout, builds it, and pushes it to all of the different servers.

Paul: So is that – do you actually have to take the site offline to do those updates? How do you minimize the downtime that’s involved with that.

Joe: Oh, well there’s a bunch of different ways. Um, we don’t bring the website down normally for pushes, it depends on the size and complexity of the push. But like, day to day pushes, we probably push I guess, a minimum of once a day, just little bug fixes and stuff like that. And those happen generally in the middle of the day, and nobody notices, it’s no big deal. Ah, the outages these days, are completely dependant on database activity, you know, like database fixes and stuff like that. And the ways that we’re getting around that these days, is using a different method of partitioning called vertical partitioning. Where, like for instance, like I think our comment Diggs table, of like, who’s dug a comment, up or down, that’s like 15 billion records in it.

Paul: Wow

Joe: that’s like, yeah, if you’re like to alter that table, you’d probably crash mysql, but if you were, it would probably take a week to alter it. So instead we probably create another table, where we have like comments, and then we have another one called comments_made_up, or something like comments_diggs, comments_diggs_beta, and that has a couple of extra fields in it. And so we’ll say, OK, we’re about to push the code, at the end. When we push the code, the first comment id that was added to the table was 15,000,000,001, so then you start at 15,000,000,000 and work my way back in the table. So we do some of that live as well. For the next push that we’re doing, we’re using a migration table, which will tell us how far along each record is, and which records we’ve actually migrated, and stuff like that. And then we’re going to use this package called "GearMan" which is a queuing system which we’ve had in production for a while. And we’re basically turning our servers into a giant BotNet, so we’ll back fill all those partitions quickly.

Paul: Wow, that kind of amount of data, it must create huge problems, even adding a new piece of functionality onto the site, to actually code it in a way that’s not going to have a momentous impact on the database. This must be something that’s always constantly on your mind I guess?

Joe: Yeah, I’ll tell you a really funny story that highlights that perfectly, we have these little green badges that are on the Digg button, and they indicate, that a friend of yours has dug that story. And when you hover it shows the last four friends to dig it or something. So that’s a pretty knurly query, against a very big table, and we’ve actually had to, what I would call "dial it down a bit", so that it only shows up on the stories that are 48 hours old, and it won’t show up if there are more than 500 diggs or something. So the features fairly usable, but it’s not like… Well before if someone went to the top of 365, it was basically crashing our servers. So we’ve been rewriting that, and we basically, the way that we’re rewriting it is: If you write something, we take that Digg and we drop it into each of your followers buckets. So we make a bucket for each story for each person. Any time one of their friends digs it, we drop that dig into their bucket, but the problem is, like Kevin Rose is followed by 40,000 people, so every time he digs something, I need to drop 40,000 things into 40,000 different buckets. And we did the math, and just to get that feature up and running in a vast sane manner, so that it will scale, so we can bring it back in full capacity so everyone can use it all the time. We need 1.25 GB of storage, and we need to be able to sustain 3000 writes per second in order to keep just that small feature online.

Paul: So that really kind of illustrates that a relatively small feature that someone comes up with, has massive ramifications from your point of view.

Joe: Yeah, this is something that has kind of been something that I always talk about. I mean even back when I was doing consulting, I’d kind of have clients come to me, and it would be: "Check out this awesome design", and I would be like "that designs awesome, but that little feature down there, that’s going to cost you know, $100,000 in servers, and 500 man hours. But it’s, like, well the designers think of sizes and shapes, and so Daniel always jokes around and says: "Well I can make it purple" if that will make it easier for you" you know, it’s like…

Paul: Laughs

Joe: Laughs – well that doesn’t make it easier!

Paul: Well, we’re going to get you and Daniel back on the show to talk about this whole design / developer relationships, so you can lace your side of it now, and get your side in first. Before he defends himself.

Joe: Sounds like a plan.

Paul: So are you at the point now where you’ve got an architecture that’s kind of infinitely scalable, or are you going to have to go back to the drawing board if Digg just goes even more, you know off the scale than it already is?

Joe: Yeah, well we’re actually at the drawing board right now.

Paul: Yeah?

Joe: Yeah, Ron, myself, and some of the other senior peeps, about 8 or 10 months ago, we started putting together… well we knew that we were going to start to have serious limitations, especially since we were going to be scaling internationally. You know there is a problem with latency. With you guys across the pond hitting the west coast and other things like that. So we want to be in multiple data centers. We want to be actively serving traffic from multiple data centers, so we’re are, well we need to horizontally partition, we need to make sure we can do that. And we need to live in two different data centers. We need to be able to survive one data center disappearing. So we spent basically a week in front of the white board, and we created this thing called IDDB, which is kind of an elastic storage engine, built on top of SQL, and memcachedb, that we’re going to be putting the first bits and pieces into production, probably over a month or so. And really, the whole partitioning thing isn’t the difficult thing to figure out. The difficult thing is basically spanning multiple data centers, and also we’ll have a couple hundred gigabytes of data, and I need to spray that across, you know, a couple dozen different servers, without bringing the site down. So we have a couple million – 3 or 4 million users, and I need to take all of their records, and all of their auxiliary records, here’s like your user record, and there’s also a bunch of cruft related to that. So I need to take all of that, and migrate it to different partitions. But I need to do that while the site’s still up and running, and I need to do that without breaking the site for you. So, that’s the more complex problem at this point.

Paul: I mean you talk about spreading across multiple data centers, and if one of those data centers goes down, the site does too, and whatever. How are you currently handling redundancy? How are you making sure the site stands up at the minute?

Joe: Right now, our only single point of failure at this point, is our actual data center, so if the data center falls off the planet, then we’ve got problems. But we’ve got a general architecture. We’ve got a couple of general balancers up front. And those two have, what we call a "heartbeat" between them, and if one of them falls off, the other instantly takes over traffic for it. And that balances traffic across, I couldn’t even tell you, dozens and dozens of web servers, and of course, the load balancer does help checks on those, so if any of those falls over, it will drop it out of the pool. Behind that, we have, I think, 4, I guess our masters are technically single points of failure, but we have multiple masters as well, and we have dozens of read slaves hanging off of them. I think right now it takes about 10 minutes to bring a new master into production if one fails. So, and then we have, to store our files, we have a thing called MogileFS, which is a distributed web dav storage engine of sorts, and we can loose multiple nodes on that, and not have any problem with that as well.

Paul: Yeah, so at the moment it’s a physical problem that you have, that if your data center gets hit by an earthquake or whatever, then you have problems. Please tell me it’s not in San Francisco?

Joe: It’s not in San Francisco.

Paul: Ha ha, yeah, you’re not actually going to say where it is are you?

Joe: No I can say we have one on the west coast, and we have one on the east coast.

Paul: Oh, well that’s at least something. Um, I mean so far we’ve concentrated a lot on scaling technology, but there’s kind of another side to this, as well, where you get something like Digg, that has grown incredibly rapidly, over a very short length of time, and that is, kind of scaling the team behind it. You know, I don’t know how many developers were working on Digg when you joined it, but there would certainly be a heck of a lot more now. And I’m quite interested in how you went about growing the team. And how you deal with that kind of rapid growth, and making sure everyone knows what they’re working on, and not overwriting others work, and all the complexity that goes along side of that. How have you dealt with that?

Joe: Sure, I guess, to put things into context a little bit, when I was hired, we had both Kurt Wilms and I, were both hired on the same day, and were respectively employees 18 and 19, and developers, I think there were 7 of us. So, now we’re at the low 20′s as far as developers, and we’re in the mid 80s, as far as total employees, and that’s been in a year and 9 months. So as far as scaling the teams go, some of the building blocks were well in place by the time I got here. Like, source repository, stuff like that. But I think the crucial things that we’ve done, since I’ve come on board, that were, we had some coding standards that were out there, but they weren’t really in force. And then we had, we didn’t really have any frameworks in place. I think one of the problems, you know, when Jay, our CEO, was asking, where do we find more senior developers, I told Jay, like that’s not the right question, the right question is like, how do we get the code, and how do we get the technology, in a position, where we don’t have to hire really senior people. So I think the keys to that are, we do have pretty strict coding standards, so we do enforce those rigorously, through continuous integeration environment, and code reviews. Every piece of code that gets pushed to production has to be reviewed. And that’s literally 4 or 5 coders, sitting in a room, going line by line through change sets, and stuff like that. And that sounds really time consuming, but without question, on every code review I’ve sat in on, we’ve found one show stopper bug. So, those have been crucial, in getting things put together. The other things we did as we grew, is we broke the team up into smaller teams, so we have a development team of 20 – 25 developers, but that’s broken up into teams of between 3 and 5 developers. This really helps in a couple of areas. 1, it enforces code ownership. So everybody has this problem. I code this, then I go and work on something completely different. And 6 months later I come back to this code and I’ve forgotten. I don’t remember any of that. Where as if you’re always working in the same area of the sites, not only do you remember a lot more, you’re a lot more familiar with that. But also, you feel a bit more of a sense of ownership over that. You’re not just this hired gun that’s come in and ploughs through this feature then moves on to something else. You have your own territory that you need to keep track of. You need to keep really nice and what-not. So we did that, and then we have a bunch of core frameworks, that we’ve built. We have a small application framework, we have an AJAX framework, and now, we have this data access layer that we’ve been building up called IDDB. So I think those are pretty crucial too. It’s difficult to find coders that are intimately aware of memcached, and race conditions that exist in memcached, and um, we have to be very selective about what fields we add indexes on in mySQL. We also have to be very selective about how we store that. Normalization flies totally out the window, if you’re a DBA guy. A lot of concepts, they are not bad developers, by any means, they do great AJAX work, they do great application level PHP work, but if you don’t have frameworks in place for them to not have to worry about the super-super complex stuff. It’s going to be really difficult to hire, and it’s going to be really difficult to, you know, get a lot of stuff running in parallel and stuff.

Paul: Wow.

Joe: Yeah, and then we also, another one of the things we’ve adopted, is the agile SCRUM. So we’re doing sprints, and we’re running those in parallel now across all the teams. So right now we have 4 major projects going on right now.

Paul: Ok. So you talk about a sense of ownership there, and the developers are split down into multiple certain areas. You know, does that not get boring, for the developer, having to work on the same bit of code long time, or do you rotate people?

Joe: Well, we don’t currently rotate people, the team structure’s been in place for about 4 or 5 months now. And you know, most of the work they get is fairly immediate, and we’re moving major projects like Facebook connect, so the "Tools and integration team", their doing facebook connect now, and after this, they will maybe work on a new version of the API and so on. It’s written out to wide swaths of the site, so that we have "Site Apps" which does like, all the different applications on the site. And then we have "Tools and Integration" where we have the external projection of Digg, then we have "Core Apps" which is like, search, R&D stuff like recommendation engine, and what not, and then we have "Core Infrastructure".

Paul: So it’s probably enough to be interesting?

Joe: Yeah, we have pretty broad teams, and also, when we put people on those teams, even if someone has an amazing core infrastructure background, but they say, look, like, one of our UI guys, used to be really heavy into core infrastructure stuff when he worked at Quest, and managed massive warehouses, but he says, like, "That’s not what gets me up in the morning any more". It’s like, "Javascript UI interfaces are". So we try to put people on the teams where, you know, where their passions lie. And that’s kind of another thing that people need to recognize. And that’s like, not all developers are driven by, or interested in the same things. We have some, what I would call "UI / Frontend" developers, where like, they could care less about PHP, but we have PHP guys who could care less about Javascript. So I think, recognizing strengths and weaknesses, and capitalizing on those, is pretty important too.

Paul: OK, one last question to finish off, and that is, well you know, the kind of things that you’ve been talking about are fascinating to hear, about the kind of challenges that you have to face with the size of Digg, and the amount of traffic you have to handle. But obviously a lot of people who are listening to this podcast, aren’t at that stage. They are not working on massive projects like that. So I’m really interested in what advice you would have, for those who are just beginning to suffer from scalability problems, and they feel that it’s coming, and it’s something they need to be paying attention to. But it’s not on the enormous scale that you have to deal with. What things can they do right now to prevent problems down the line?

Joe: Um, I think, the easiest things you can do, is you need to re-think the LAMP acronym, because that stack is actually no longer really that stack. I would take Linux, and I’d take Apache out of that stack, and it doesn’t matter, as long as you’re running on a Unix. And as far as Apache goes, Lighty and EngineX are much better at getting a lot more money out of your box, as far as scalability goes. The two areas, that I think people, they sound hard, but they are really easy. One of them is installing and using Memcached, and the other one is installing and using a queuing system of some sort. And I think, like, recently I went through this with a little side project, called "Please Dress Me" which AJ and Gary Benashack and I did.

Paul: Oh, yes yes.

Joe: And we had a very small virtual server at MediaTemple, that survived pretty crushing blows from TechCrunch, Digg, BoingBoing, with almost no load. And that was like, beforehand, memcached is so second nature to me at this point, that I was just like, "Oh, well I’m just going to cache everything in memcached", and it was literally just like this RAM spewing machine. It didn’t actually hit the database. Actually my sysadmin at MediaTemple was like "Something’s really weard, MySQL is only doing like 1 query a second, and you’re doing like 500 requests per second from BoingBoing. So I’m cached. Yeah memcached is just like, it takes literally 10 minutes to install, and probably another hour or two to implement.

Paul: Wow, that sounds excellent, that’s really good advice. Joe, thank you so much for coming on the show, and I can’t wait to get you and Daniel fighting with one an other in the not too distant future. I’m hoping to get a good violent argument about designers and developers, just because I can.

Joe: Laughs.

Paul: I was a little bit disappointed when you guys sat down at Future of Web Design, were far too nice to one another, compared to the evening before, when you’d had a bit to drink, and you were talking in the restaurant. That’s the kind of conversation I want, that real vicious session.

Joe: OK, I’ll make sure that Daniel and I get liquored up before coming on then.

Paul: Yeah, that’s the answer. Ok, thank you so much Joe, that’s really good advice, and we’ll talk to you soon.

Joe: Thanks Paul, bye.

Thanks goes to Nathan O’Hanlon for transcribing this interview.

Listeners feedback:

Top web designer applications

Often this section of the show consists of questions for myself and Marcus. However for a change, I thought we should ask the questions. Via the forum, the boagworld site and twitter I recently asked you to vote for your ‘favourite web designer application‘. The response was overwhelming and you can see the complete list of suggestions on UserVoice. However, here are the top 5…

Firebug – Firebug is a Firefox addon that puts a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. A less popular suggestion was the Web Inspector in Safari.
Web developer toolbar – The Web Developers toolbar is a Firefox addon that provides a variety of web development tools. You can disable CSS and Javascript, visually highlight elements, manage cookies and much more. A less popular alternative was the IE developers toolbar.
Adobe Photoshop – A professional image-editing and graphics creation software from Adobe. It provides a large library of effects, filters and layers. This is the grandfather of such applications and many (like myself) use it out of habit more than anything else. Less popular suggestions included Fireworks, Illustrator and Inkscape.
Coda – Coda is a one window development environment for the mac. It includes FTP, text editor, browser preview and even terminal window. A beautifully designed app it appeals to the more visual web designer. Simple, easy to use and elegant.
TextMate – TextMate is a powerful text editor for the mac with an extensive plug-in architecture. From its code highlighting in near endless languages to support for numerous version control systems, TextMate is probably the most powerful text editor out there.

If you disagree with the Boagworld Listeners top five or want to see the other entries then head on over to UserVoice and vote for yourself.

Sending out bulk emails

My second listener contribution comes from the forum. It is a question from Richard about sending bulk email.

Richard writes: I need to send out bulk emails to approx 200k registered (opted in) users on a monthly basis.

Does anyone have any recommendations for an outsourced bulk email provider?

As with the previous contribution I want to focus on your responses rather than my own. This is what the Boagworld community had to say…

Jamie was the first of a number of people to recommend Campaign Monitor. Judging by the feedback from the forum they offer an excellent service but are expensive when compared to others.

As well as recommending Campaign Monitor Nick mentions Silverpop, which he described as ‘an enterprise affair’. Apparently it is not as polished as campaign monitor but considerably more powerful.

Phil recommended two more, Mail Chimp and Mad Mini. He hasn’t used them personally but the prices look good and he says the user interfaces appear polished.

Doug doesn’t recommend a specific service but does refer Richard to a post on Creative Tips which provides a comprehensive review of Campaign Monitor, MailChimp, AWeber, and Constant Contact.

If you have suggestions for Richard or would just like to share your experiences of using bulk email services then contribute to the thread in the boagworld forum.

143. Partnership

Posted in Classic shows on November 12, 2008 by Paul Boag

On this week’s show Paul and Marcus discuss how to promote your web application, ways to improve the client/designer relationship and tools for managing your font library.

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Obama top technology promises

One of the most exciting things about being at this years FoWD conference in New York was that I got to witness the election of the next U.S. president.

Whatever your political persuasions it was a landmark election. Not only will Obama be the first African American president he is also probably the most technically aware.

Obama campaigned aggressively online, from a dedicated YouTube channel to Obama pages on Facebook and MySpace as well as Twitter feeds. He even had his own iPhone application.

So what can we expect from this tech-savvy President? How will he shape the future of U.S. online presence and possibly that of the entire web? An article on tgdaily entitled ‘Barack Obama’s Top technology promises‘ gives us a roundup of various technological promises from Obama’s speeches. These include:

A commitment to Net Neutrality
A desire to expand broadband penetration in the U.S.
A review of the current wireless spectrum usage
Tougher legislation around online security.

Of course, promises made on the campaign trail are one thing. We shall see what the reality turns out to be.

Could Microsoft consider adopting Webkit?

Talking of things that may never be, a young (and very brave) developer at Microsoft recently asked Steve Ballmer:

Why is IE still relevant and why is it worth spending money on rendering engines when there are open source ones available that can respond to changes in Web standards faster?

Ballmer’s response was surprising to say the least:

There will still be a lot of proprietary innovation in the browser itself so we may need to have a rendering service. Open source is interesting. Apple has embraced Webkit and we may look at that, but we will continue to build extensions for IE 8.

Although some have seen this as a sign that Microsoft may adopt Webkit, personally I am sceptical. Were Microsoft to completely change its rendering engine it would inevitably break large numbers of sites and cause outrage among many of their large corporate clients.

The backlash when moving from IE6 to IE7 was massive. Moving to Webkit would conflict with Microsoft’s mantra of ‘not breaking the web’.

That said, we can dream. Without a doubt the real innovation and competitive advantage among browsers is in features, not rendering engines. This would in many ways be a smart move allowing Microsoft to concentrate on differentiation through ‘extensions’ and functionality, rather than wasting time on getting pages to display correctly.

WCAG 2.0 resources

Something that is definitely going to happen very soon is the release of WCAG 2.0.

WCAG 2.0. has now become a proposed recommendation. This means it is not only technically complete but has been successfully implemented on a large variety of sites. In short, it has been proved to work.

According to the Web Standards group this means it could therefore be released before Christmas.

This is hugely significant and very exciting from an accessibility point of view. WCAG 2.0. has come a long way from its controversial beginnings and is now a very good set of guidelines.

Now is the time to start building compliant sites and the Web Standards Group has provided some useful resources for implementing WCAG 2.0.

Prototyping with XHTML

Our final story is a post on the Boxes and Arrows website encouraging us to ‘Prototyping with XHTML‘.

The article lays out an approach to wireframing and prototyping, which is based entirely around the use of XHTML. Starting with the XHTML itself, you build up the structure and elements within your site. You then add CSS and Javascript to further refine the concept.

It is an approach with a lot of merit. Unlike other methods, the prototype is not thrown away but becomes apart of the final deliverable. It is also an approach particularly suited to multiple iterations, allowing you to refine the design over time.

In a world of web applications it is becoming increasingly important to demonstrate user interactions in a way static comps cannot. However, although this approach is appealing I do not believe it replaces the Photoshop mockup. Client’s like to see ‘finished’ looking designs. That said, it is another useful tool in your arsenal and you should be sure to read this post.

Feature: A Partnership of Cooperation

At this years FoWD I shared how the relationship between web design agency and client is fundamentally broken. Where there should be mutual respect and cooperation, there is negativity and mistrust. Read More.

Listeners feedback:

Marketing a web application

Nick Charlton writes: Long time listener, havenâ€™t asked a question before though..

Apart from your blog, the podcast and twitter, how else have you marketed GetSignOff?

To be honest, I have done very little marketing yet. However, I know that has got to change. The problem is that I am not a trained marketeer and so don’t really know what I am doing. That said I do have a rough plan:

Free pro accounts – While in beta we gave away numerous pro accounts to ‘web celebs’. However, to be honest it was a waste of time. These guys were either too busy to review it or just didn’t feel it was worth writing about. This time I intend to give free accounts to those who blog about the application. Not entirely sure how I am going to do this yet but I think it might generate some buzz.
Offering discounts – Discounts are an effective way of spreading word of mouth. Again I am not entirely sure if or when we will do this, but offering the occasional discount should encourage people to tell their friends.
Targeting appropriate publications – I am in the process of writing a number of articles either directly or indirectly related to GetSignOff. I have also asked some sites to review the application. I have approached sites like Digital Web, Think Vitamin and printed publications such as .net. Having a product aimed at people like myself makes identifying appropriate publications easy.
Producing supporting video content – I have already produced the ‘Getting design sign off‘ presentation but also intend to make some shorter tutorials for YouTube. These will contain valuable content in their own right, but will also promote GSO.
Utilising CSS galleries – Because my audience are web designers we have submitted GSO to several CSS galleries. We know that many web designers use these sites and so this gives our application a lot of exposure.
Use speaking opportunities – Speaking opportunities have been a great opportunity for promoting GSO and I have started tailoring my speaking slots around the subject of sign off.

In time we may consider advertising through things like Google Adwords or the Deck. However, until we are confident in the return on investment we are not willing to invest more money in anything other than development.

Font management

Aurel writes: I would realy like to know how designers deal with fonts? From personal experience, I have alot of fonts and it takes me time to find or manage them. So I was wondering if you know of any way to group the fonts, e.g. when you go through the drop menu of fonts in photoshop, they apear in groups (or something along those lines).

The solution I use was recommended on the Rissington Podcast (oh the shame of admitting that.)

It is a piece of software called FontExplorer X which is available for both the mac and PC. It has some superb features if you are serious about fonts. These include:

Organising your fonts – Organise using a library, folders, tags and even smart sets. You can directly access all typefaces from a certain foundry or all fonts tagged with a certain keyword? You can even view all italic fonts.
Auto activation – FontExplorer allows you to decide which fonts are available in which applications. This is ideal if you want to avoid scrolling through large numbers of fonts in applications like Photoshop.
Font information – FontExplorer gives you a clear customisable preview of your fonts as well as detailed information on the character set and usage restrictions.

The application also has an in built store that allows you to buy additional fonts within the same intuitive interface. I am guessing this is how they manage to offer the whole application absolutely free.

142. Community

Posted in Classic shows on November 5, 2008 by Paul Boag

In this week’s show Ryan and Stanton cover the news in Paul’s absence, we’re joined by Mark Boulton to discuss design by community and Marcus reminds us to keep positive.

Download this show.

Launch our podcast player

News and events

Typeface.js

There are many solutions to insert custom fonts into your designs, whether it’s the good old CSS image replacement techniques, SiFR or FLiR, we’re really just biding our time until font-embedding through the @font-face rule becomes widely supported in the browsers (we’ve covered font-embedding before in show 129) But for now, there’s another technique on the block called typeface.js which uses browsers’ vector drawing capabilities to draw text in HTML documents.

Browsers have, for a while, supported vector drawing – Firefox, Safari and Opera support the canvas element was well as SVG, and IE supports VML. The Typeface.js project uses this vector capability to ‘draw’ the fonts within your webpage.

There are a couple of caveats, while the ‘drawn’ text is selectable, it’s not highlighted (though this should be remedied in future versions) and the fonts have to be converted first through a tool available on their website. But this might be a nice little fallback if the users browser doesn’t support @font-face.

Sell Your Web App

In our next news item Ryan Carson, owner of Carsonified, has this week published a blog entitled “Sell Your Web App: Lessons I Learned From Selling Dropsend” and as you would expect from that title he shares his tips and mistakes when selling his app and it’s a very interesting read.

He talks about considerations like choosing the right merchant account, anticipating high lawyer and accountancy fees and off course being discreet, don’t blog about your sale!

He’s also prompted for people to leave their own tips in the comments so if you’ve sold a web app yourself head over to thinkvitamin.com and share your experiences as well.

Lessons learned while building an iPhone site.

Theres a nice article on the Flickr Blog which details some of the lessons they learned while building the popular iPhone version of the Flickr site. They go into detail of subjects such as “don’t use a javaScript library or CSS framework”, “Load page fragments instead of full pages”, “optimize everything” and making sure to tell the user what’s happening through visual indicators.

If you’re developing iPhone apps, or are even just thinking about it I’d recommend giving this article a read before you start work, it may save you a lot of time down the line.

Free Site Validator

Our final news item brings our attention to a service blogged about by Roger Johansson at 456bereastreet.com. Roger was looking for a way to validate his site without having to do every page individually and what he found was freesitevalidator.com.

The service automatically craws each page of your site and checks it for validation, as well as giving you a report of any broken/dead links. Also known as Link Rot!

The service looks really useful so be sure to check it out.

Interview: Mark Boulton on Design by Community

Paul: So as I said at the start of the show, joining me today is Mark Boulton. Good to have you on the show Mark.

Mark: Good to be here.

Paul: It’s nice to finally talk to you, we met up for the first time just a few days ago now.

Mark: Yeah, it was it was about a week ago.

Paul: It was great to do so. I talked about you a few weeks ago on the show as well when we were talking about a recent blog post that you wrote. But we will come on to that in just a minute. What we are going to talk about today with Mark is that he has done the unthinkable from a design point of view. Haven’t you really?

Mark: I have really yes.

Paul: You’re totally insane and so I wanted to pick you brain about why you have chosen to do the unthinkable. Before we get onto that, all of this resolves around some work your doing for Drupal. Tell us a little bit A) about what Drupal is and B) what you are doing.

Mark: Drupal is a Content Management Framework I guess, that allows people to build websites and its an open source project, it’s been going for quite a while now. I think seven years or so. The software is on version six now and it has a very large user base. Probably three hundred or so registered users.

Paul: Three hundred users?

Mark: Three hundred thousand!

Paul: Ah ok.

Mark: So it’s a pretty enormous project really, and with it being Open Source these are all very passionate developers. It’s quite a developer centric platform.

Paul: Ok.

Mark: The community, with it being open source the community contribute quite a lot to it, with modules and themes and that kind of thing, plugins. Our involvement in the project is redesigning drupal.org, which is kind of the home on the web of the framework, so you can go there and download and read documentation. But it’s also the home of the community, which is a pretty huge one. So it’s very exciting.

Paul: So tell us a little bit about the design process that you’re using, and this is what you blogged on and what kind of caught my attention and struck me as a ridiculous idea and what on earth were you thinking about?

Mark: Yeah, well I’ve been working with Lisa Raquelt who is a user experience researcher and kind of strategist. She started very early on in the process. She started blogging about it with the Drupal Association, who represent the Drupal community, who engaged us on the project. They are very happy with this being an open source project. They’re very happy with us to talk about it. Which is completely opposite to the way you normally work with a client.

Paul: Yeah, totally.

Mark: Normally you sign NDAs and it’s very closed doors. You don’t want to tell the competition, its the complete opposite, which is terrifying. Lisa started blogging about it and got really really great feedback from the community, really valuable feedback. Then I then started blogging about some of the design work we were doing. We are redesigning the wordmark and the branding currently. And I thought I may as well just jump in feet first here and see how this goes, which is totally contrary to the way I’ve been working in the past and the way your mind tells you you should work. You just shouldn’t openly talk about design because you’d think that it’s very subjective and everyone is going to have their own opinions, which is true. But we blogged about it a couple of weeks ago and it’s where my blog post on my own site, markboulton.co.uk, came about was I had a lot of people including yourself Paul. Who were saying I was insane, why are you doing this? And it’s this notion of design by community that’s very different to design by committee. Which is what a lot of people was telling me, "You can’t design by committee, it never works." Which is true, it never does.

Paul: So why do you think we are so hesitant as designers to talk openly? Is it fear of the subjective, is it that we don’t like people looking at our designs before they are finished? Why are we so hesitant do you think?

Mark: It’s a really interesting question that. I had an interesting conversation with an architect a couple of weeks ago about the exact same thing. A lot of architects don’t open up. A lot of designers, maybe product designers. An insight into the way somebody works and as designers we all work very differently and sometimes it’s a very private process. To expose that it’s almost like going out shopping with no clothes on. Suddenly you’re exposing the way that you work to everybody, to judge you, and people will judge you. It is a terrifying thought. I think part of it is also schooling. If you’ve done art at school, which most designers have done, most visual designers. You slave away on a piece of art and it’s not finished yet and it’s not finished and you don’t want anyone to look at it until it is finished, so I think there is an element of that as well. When I released two versions of the Drupal wordmark, for feedback they were very much just sketches. They were right in their first iteration. I would normally never do that but I thought let’s see what the community thinks.

Paul: So what happened when you released those two sketches?

Mark: It was carnage. Initially it was quite painful sometimes to listen to some of the comments to be honest. I think anybody takes their own work personally. If someone then attacks some of your own work with necessarily seeing any of the context and that kind of thing, then it can smart a little bit. But I’ve written my own blog for a while now and I’ve got reasonably thick skin, so it wasn’t that bad. What did come out through all of the comments were trends. Trends started to emerge. So from people’s subjective opinion, if enough people were having the same kind of subjective opinion, then that becomes less of an opinion and more of trend. And it was really those trends were looking to identify, that we could feed back into the development of the design.

Paul: It’s interesting there you talked about the fact the people who were seeing this stuff didn’t have the context. Did you not prepare the ground in any way? Did you not tell them why you took the approach you did? Or did you literally just put out the branding there and go, "What do you think?"

Mark: Yeah, there is a reasonably sticky situation with Drupal, particularly with the wordmark. They have a kind of logo at the moment, which is a kind of drop with a face on it. And that logo at the moment is under GPL so it can’t be trademarked which means the Drupal Association can not protect their own property, as it were, because this logo is under GPL. Which means that anybody can take it, change it, completely mess around with it. Which is fine, the community have been doing that for a long time now. So when I took on and blogged about this redesign of the wordmark, there was not the context, the business context, was perhaps lacking because I felt that I could not provide that business context. Because I was the designer and that should really come from someone else, and that was a little late in coming. Which is why the first blog post really didn’t go down too well, because I assumed the audience knew that this project was happening. As it turned out, it actually wasn’t. They didn’t know and it was all a bit of a mess, but it’s kind of smoothed over now, with later iterations and there’s been more blogging done by the Drupal Association. Which has provided the rationale for redesigning the branding.

Paul: Right, so there is a lesson to be learned there I guess of the importance of providing context and why stuff is happening and why you are taking the approach you are I guess.

Mark: Absolutely yeah, I think context is really important, especially for branding and logo design and that kind of thing. Just providing, and I was very aware of this when I blogged it. We all saw what happened with the London 2012 logo, when that is released very early without any context, it’s either misunderstood, or just hated or really liked. I’d rather have that kind of opinion anyway, than somebody kind of going, "Yeah, its alright."

Paul: You prefer to create a strong reaction.

Mark: Yeah, either positive or negative, because those are the reactions you can act upon. Anything in the middle is kind of gray, middle ground. That’s actually very very difficult to take on board and move forward with. So any kind of negative or positive reaction, you can take that on board, which we did. But the context for the Drupal logo is going to be the other stuff around it, which is the branding, the tone of voice, what is said on the page, the design, the other design elements around it, how it interacts with the existing kind of drop because they are still keeping that as a mascot. So it’s how all of that works together was perhaps lacking at this early stage. Which is why perhaps, going back to your initial question, designers don’t actually release very early on because the context isn’t there yet.

Paul: Yeah, which makes a lot of sense. When it came to the feedback, so you were obviously asking for feedback here, were you setting any kind of constraints on that feedback? From time to time I’ve talked on the subject about how to get design signoff and that kind of thing and one of the things that I always say is, "Don’t just say, ‘What do you think?’" but actually kind of try and guide the type of feedback you want and give a context to it, is that something you did?

Mark: Yeah. Not initially, which was why we had to.. The initial blog post didn’t really go down so well from an actionable sort of feedback point of view. Because I felt that a lot of the design questions I wanted answered. I think it was too early and I hold my hands up for that. I think it was too early in the process for me to blog about that. The second post that I put up I asked for specifics on whether or not the word mark needed a capital D or a lower case d and whether or not it needed, we were developing the idea of a secondary icon with it which is a splash and whether or not it needed the splash or not. We got some really great feedback because that focused people’s attention. That provided a really great selection of trends which have fed back into the next iteration. The first post was a bit of a free for all to be honest. Nothing really useful came out of it, which was a shame.

Paul: I mean you kind of, you talked about trends. Do you think that that is kind of, those trends that you see emerging, have the way that you have taken those on board has it been a kind of anecdotal trends or are you talking statistics here? Were you kind of marking down how many people you know said, "Yes, there should be an uppercase D." or whatever or are you just kind of taking on a feeling? Does that make sense?

Mark: Yeah. It was kind of taking on the feeling. More qualitative than quantitative at this point. However, for the cap D or lowercase d we could have just run a poll which in hindsight we should have done, is just had a tick box for each question as it were. However I’m always a little, I actually quite like a lot of the qualitative feedback because people were saying, "Yes cap D and splash," but then they go on to say something else. If we just reigned it into a simple poll then we would have lost all that really great, valuable feedback, because it’s that that provides context for their answer.

Paul: Yeah, I mean you won’t necessarily know why they’re saying a capital D.

Mark: Exactly, and there was enough of people saying the same kind of thing in those comments for it to be a pretty good trend for us to act upon. And it also throws out more heads about them on as it were. There was a lot of valuable comment from the Drupal community especially. And that we would have spent six months trying to research the ins and outs of that community, the history and the culture because there is an awful lot, you know. It’s been going seven years and there’s a lot of people in there. I would have been around â€˜til next year trying to fully understand that community if I hadn’t adopted this open way of working.

Paul: It’s quite interesting, isn’t it? I mean when they were coming back and you were seeing a trend emerging very definitely one way or the other over something, were you always going with that decision or were sometimes you saying "Well actually, although everybody’s saying we should go with a capital D or whatever, I’m not going to because of X, Y and Z."

Mark: Yes. I think there does have to be somebody who is willing to make a decision on something that needs to be decided upon. If fifty percent of people said, "I like a black website," and fifty percent of people say, "I like a white website," the compromise is that you end up with a gray website and nobody wants gray. So, what we’ve done especially with the cap D and lowercase d for example there was pretty much an overwhelming response to, "Yes it should be lowercase d," because it’s kind of more attractive aesthetically and all the rest of it. However we’ve chosen to go with uppercase D and that is because of business requirements and also because of the ties in with the documentation. We’ve revised the word mark now where the uppercase D is actually a lot better than the previous version. Perhaps when I posted initially the lowercase d and the uppercase D were not really on an equal footing design-wise. The uppercase D needed a lot of refinement and again perhaps that skewed the results, skewed the comments and so we’ve actually reversed the general trend there and said, "Actually no. We think we should go with the uppercase D for this reason and this reason," and that will continue throughout the whole process. We’ve got to remember, and it’s very important, that the Drupal Association hired us for our expertise and if we feel strongly about something then hopefully we’ll go ahead with that and we’ll push back on any feedback.

Paul: I mean it’s quite interesting. You talk about, "as we go through this process." So it sounds like you’re gonna keep going down this line, that you’re gonna, you know, as you create say, the website interface that you’ll expose that.

Mark: Yeah we are. If you have a look on groups.google.org and do a search for the redesign group in there we have set in a bunch of dates in the calendar for gathering community feedback. So we will be posting up a link on Thursday to the prototype we’re developing and we’ll be doing that for the next six to eight weeks. Every other week we’ll be posting a link up there to gather feedback throughout the weekend. So we’ll be posting it up on Thursday/Friday morning and then we’ll be kind of locking off comments on Monday and then all of those comments will hopefully try and establish some trends and feedback. That’ll then feed back into the next iteration. So we’ve pretty much set a precedent here and we’re gonna be designing in the open â€˜til the final curtain call, as it were.

Paul: Excellent! So how do you feel this differs from design by committee? Because from chatting to you when we met up whenever it was I got the distinct impression from you, you saw this as a very different kind of experience, but why, what makes it different?

Mark: Yeah, well I’ve been involved in design by committee quite a few times. I’m sure a lot of designers have and generally in those instances you’re in a boardroom or a meeting and there are several people, maybe twelve tops, and they all have very strong opinions. Generally, as I said in my blog post, there might be an alpha male in there or two sometimes. People can rally around the loudest voice, so all of a sudden that becomes the opinion. It can be a very, very difficult environment to work in because there are so few people, all with a very loud voice. Design by community is a different kettle of fish really because we’re designing for essentially 300,000 clients and the wider web community as well, we’re not just asking the Drupal community for feedback here, we’re also asking the wider web community for feedback. Anybody can get involved in this, it’s not just for the Drupal community. So anybody can. So if you feel like, talking to the listeners here, if anyone feels like weighting in with their comments, please do. Because it’s very important to us that the wider audience is reflected in this redesign and not just designing for the Drupal community. So it’s a very different process I think, because we’re kind of staffing back a little bit. We’re not in a meeting room with twelve people trying to come up with a solution. We’re putting stuff out there. We’re asking for comments from a lot of people who are thankfully providing comments, which is great. Really thoughtful feedback, then we can try and establish trends and then it’s those trends that we act upon. It becomes a little less subjective. That’s the idea anyway.

Paul: It’s the scale that turns it into trends rather than just an opinionated person I guess.

Mark: Yeah, that’s right. And you do have to, like I said initially, sometimes it’s difficult to read a bit of a flaming going on on your blog posts, you know, because there are quite a few people out there who will be very passionate about this project. They’re very passionate about Drupal because they’ve got a lot of time and money, a lot of people their livelihood is dependent upon this platform. So we have to really take that into account that this is serious for a lot of people. We’re not just redesigning a website here, we’re actually providing a platform for a community to do their work. So it’s pretty important stuff.

Paul: So, I mean do you think that this is a kind of a peculiar situation? You know, is the Drupal project unusual or would this be a kind of approach you would encourage for other designers working on other types of projects?

Mark: It’s a really interesting question. I mean I’ve worked waterfall methodologies in the past so you get your, you do your research, you do your initial designs, they get signed off and then you build your website, it’s very linear. And after working at the BBC for so long I realized that, because we worked very iteratively at the BBC that actually a more iterative approach was actually more valuable so to take that client-side approach, and the agile software development approach, to take that commercially with design is actually very difficult. But with the clients we are currently working with, that’s the way that we work. So we don’t work in a waterfall methodology, we work very iteratively upon fixed time scales. So we have a week per iteration for example. Now the feedback thing, the only difference really between Drupal and any other big project is the fact it’s open source and has a very, very big active community who are used to working in this way. I think that’s the critical thing is that they’re used to people putting software updates out early, feedback and they get changed and honed down until the final version is released but it’s just the way that they’re working so we have to kind of slot into that culture and it’s not a culture that design thrives in actually.

Paul: No, I can imagine.

Mark: No it’s a very difficult environment for design because, and it goes back again to one of your initial questions about wanting to sit there and craft a solution until it’s finished. Well that goes counter to the way that this open source culture works. They want to see stuff early. They want to feed back. They want their say. So as long as you kind of understand that and they’re not being grouchy or attacking you in any way they just want the very best for the project. So yeah, it’s worthwhile considering it as a working approach. Certainly the iterative approach is worthwhile considering for any project but the getting feedback early, if your audience is big enough then give it a go and see how it works. You know if you speak to me in six weeks time I may have a completely different conversation. This is really very much a work in progress and we’re just seeing how it’s going. It’s not been done as openly in the public before. I can’t really remember any projects from a design perspective that have been like this. It’s fairly unique. Which is really great, it’s exciting. So we’ll just see. We’ll see what happens.

Paul: Yeah, very interesting stuff Mark. Thank you very much for coming on the show.

Mark: Thank you for having me. It’s been a pleasure.

Paul: And we will wait with baited breath to see future blog posts as to how the experience goes to the bitter end.

Mark: Please do because I’ll be blogging about it pretty much constantly throughout the life of the project.

Paul: We’ll keep an eye on that. Thank you very much for your time and we’ll get you back on soon enough.

Mark: Great! Thanks Paul!

Paul: Bye bye.

Mark: Cheers. Bye.

Thanks goes to Todd Dietrich and Andy Kinsey for transcribing this interview.

Listeners feedback:

Keeping Positive

Got this question from Bill (remember him?!)….

I have just found out that the potential new project I have put loads of work in to winning is not coming my way. I wrote an extensive proposal, did some unpaid mock-up work, attended a presentation and jumped through every hoop thrown my way.

I was told by the client that it was ‘very close’ but on this occasion I had not been successful. Gutted.

How do you guys at Headscape cope with these types of rejections?

To be honest, and this is from a lot of bitter experience, it’s hard and some are harder to take than others.

I do, however, have a few thoughts and pointers that may help. Firstly, you can help yourself by weeding out the enquiries that you will never win.

Are these people worth your time?

Check out the email address of the enquirer. If it’s gmail, hotmail, yahoo or similar then chances are your potential client is just looking for free consultancy from you. I.e. they have an idea and have no idea what’s entailed in making that idea happen. And they certainly will not pay you to research it.

Secondly, and I am only aware of this possibility in the UK, but you can check up on a company through the Companies House website. This tells you all sorts of useful information about how long they’ve been around, their liquidity etc. You may change your mind about responding to a tender sent from a dissolved company.

Talk money

There is nothing more frustrating than being told that you are ‘way out of the ballpark’ after putting hours, even days, of effort into a proposal.

Ask people, up front, what their budget is. Explain that you need to know it to respond with the most appropriate solution for them. An example I often use is usability testing. Everyone knows that testing, preferably many times throughout a project can only be a good thing. But that said, not doing any testing doesn’t automatically mean that your client will get an unusable turkey for a site.

If you don’t get anywhere by asking then create a 2 or 3 paragraph solution with associated tasks (a mini proposal I guess) and email that to the potential client with an associated ballpark price. If they still want you to deliver a ‘full’ proposal then, chances are, your ballpark is within their range.

Ask/listen

Ok, so assuming you think that responding to the proposal is a good use of your time, you now need to read their brief in detail noting questions you have along the way. You will make a number of assumptions about what is the correct solution for this client while you are reading.

You need to talk to the client to confirm their answers to your questions but you also need to listen to their responses to ensure that your assumptions are correct. It’s very easy to arrogantly assume that ‘you know best’ because you’ve been doing it for years.

This also applies to your written proposal. Don’t describe and price up what you think the client needs – go through every point in their brief and respond to it accordingly. If it is plain obvious that something they’re asking for makes no sense at all, then tackle it head on and explain why they shouldn’t be doing it.

Stick to your guns

We decided, quite a while back, and for very good reason, that we would not do any unpaid mock-up design work. In some cases this has been seen as a positive thing (once it has been explained) but with other potential projects I’m sure it has adversely affected our chances of winning the work. However, we should stick to what we believe is right. Chopping and changing presents a negative image to both potential clients and our staff.

If you do decide to present initial mock-up ideas don’t be tempted into iterating them further. Any client who asks for is again asking for free work and is most definitely to be avoided.

Be gracious

Sometimes you just have to accept that you’re not the right fit with certain companies – even if the initial phone call or meeting went really well. It may well be that someone else delivers just the thing that really swings it for the client – sometime you just don’t know what that is.

If you do lose then you need to accept that you win some, you lose some. It often happens that these things happen in streaks which can be very frustrating. We found ourselves turning away superb opportunities earlier this year simply because we were too busy.

But always try to bring a positive attitude to any rejection because it is possible that these people will contact you again for further work (though beware that you are simply making up numbers!) or they may recommend you to others. They won’t do either if you react badly to the rejection!

141. Feedback

Posted in Classic shows on October 29, 2008 by Paul Boag

In this week’s show, Paul Annett joins us to discuss how he pushes the boundaries of CSS and we look at how to improve your website through user feedback.

Download this show.

Launch our podcast player

News and events

Working from home

I suspect the vast majority of people listening to this podcast spend at least some of their time working from home. In today’s world, doing the type of work we do, there is no reason not to.

However, home working is not the utopia some believe. It has its own challenges and problems. For me it is a constant sense of guilt that I am not pulling my weight in the business. For others it is a lack of motivation or fighting the distraction of housework and family.

With some many of us struggling with the relatively new environment of home working it is great to see people sharing their experiences in a new A List Apart article (Working from home: Readers respond).

This article has some great advice and although it contradicts itself in parts (different people deal with home working in different ways) it is full of ideas that I either already implement or will be soon.

While I am talking about A List Apart I want to quickly mention "Progressive Enhancement with CSS". This is a follow up article to "Understanding Progressive Enhancement" an article we mentioned in an earlier show. It is a great article that explains one possible technique for ensuring your CSS squeezes the best out of as many browsers as possible. If you have a chance, give it a read.

Everything you know about CSS is wrong

Talking about CSS, yet another book on the subject has been released this week. However, this one is different. Written by Rachel Andrews and Kevin Yank, "Everything You Know About CSS Is Wrong" is aimed at web designers who already know CSS well. The emphasis is on emerging techniques and future CSS support.

I haven’t read this book yet (although I do have it on order), but it looks very exciting. It has been a while since I have got to experiment with CSS and so this will hopefully point me in the right direction.

It tackles subjects like Internet Explorer 8, CSS tables and CSS3. These are all topical subjects and so the book appears to have a lot of potential.

I will review the book once I have read it and we intend to get Kevin on the show to talk about some of the techniques.

Reduce your business costs with free stuff

With the economy in tatters and a general sense of impending doom, we are beginning to see posts on how to cut cost and tighten belts. One such article is "Reduce Your Business Costs With Free Stuff" on the Think Vitamin website.

The article is a mixture of ideas on how to save money in your business. Some will save you thousands and apply only to larger companies, while others save only a few pounds a month. However whatever type of business you run, from a humble part time freelancer to a multi-national design agency, there is something in here for you.

Ideas include:

Cutting costs on your phone system without reverting to VoIP
Subletting office space
Open source versions of basecamp, Microsoft office, campfire and much more
Moving email and hosting in house

Although I think some of the suggestions are somewhat short term (Managing email internally would quickly become an expensive headache) I generally agree with most of what is suggested.

If you are beginning to feel the squeeze then this one is worth the read.

HTML Email: What mail clients are people using?

Finally this week there has been an interesting evolution in our understanding of HTML email clients. This has been nicely summarised by Alex Walker on the Sitepoint blog. He writes:

There are lots of reasons for hating HTML Email, but perhaps no#1 on most people’s hit list is having to produce HTML Email to deliver to potentially hundreds of different mail clients and configurations.

Now, clearly it’s completely impractical to test your work on hundreds of mail rigs, but the question is, where do you draw the line? Generic browser usage statistics are reasonably common, but mail clients stats?

In the past you could confidently make up whatever numbers you liked on those question without fear of being caught out. But that may be changing.

Litmus, who produce an excellent web-based browser and email testing suite are now publishing email client usage statistics from their new Fingerprint email analysis system. It makes very interesting reading.

Alex goes on to summarise the key findings which include:

60% of people use web based clients
Just over 80% of the HTML email market is dominated by Outlook, Hotmail and Yahoo!
Business still generally stick with Outlook although they seem reluctant to upgrade to 2007

Interesting stuff.

Interview: Paul Annett on Pushing the Boundaries of CSS

Paul Boag: Joining me today is Paul Annett from clear:left, good to have you on the show Paul.

Paul Annett: Thank you very much. Nice of you to have me here.

Paul Boag: So Paul is, with a few others from his company, the people who really make clear:left happen, rather than Andy and Jeremy and Rich, which we know, well Richard does work, but Andy and Jeremy certainly don’t do anything do they?

Paul Annett: Well, you know, they fly around the world a bit you know?

Paul Boag: Yeah that counts. I guess..

Paul Annett: No, we all chip in, obviously. Everyone does their fair share, so we say.

Paul Boag: Very diplomatic of you. I feel like I can insult them over this as I do the equivalent of no work in my role as well.

Paul Annett: I was going to say… Well there’s eight of us at clear:left, yeah we all just chip in. We’re all caught making the tea, that sort of stuff.

Paul Boag: Cool. Well tell us about your role. What is it you do at clear:left?

Paul Annett: Well, I’m a user experience designer. So that means, well it’s more than just making a web site look pretty, which were are accused of sometimes in the trade; to make sure that the sites are easy to use, as well as a pleasure to use really. That’s something that’s often overlooked with some web site design companies, obviously none of your audience.

Paul Boag: Obviously not.

Paul Annett: It’s a vital ingredient in the mix really. My job does overlap with some of the other guys in the office. Basically, we all know each other’s jobs fairly well so we chip in and share some responsibilities. My main focus is UX design. We’ve also got the others guys doing information architecture, they tend to start the project off with handing over wire frames or prototypes to me. Then once I’ve finished my bit I then hand over the designs to our front end developers who then code up the HTML and CSS. As I say we do overlap a bit more than that but that’s basically how it works.

Paul Boag: I’m quite interested in how that works. You are saying you don’t do too much HTML and CSS, or how does it work.

Paul Annett: I don’t do a lot right now, I used to when I was freelance before joining clear:left. I used to do pretty much everything on a project. I don’t do a lot now; I don’t really have time to. The occasions when I do get time to are when we are working on our own projects. I especially seem to have had a bunch of project holding pages or client holding pages in the past where Natalie and Jeremy who do the front end are busy doing other projects and we need to just get something up there while the design is being made. So I will code up that kind of thing. I don’t really get to work on a lot of the big life projects, but then I’m no where near as proficient as Natalie and Jeremy are at those kind of things. I think they would have a fit if they considered my code going live.

Paul Boag: See that’s quite interesting, isn’t it? You’ve begun to build a bit of a reputation as somebody that does-I don’t know-CSS embellishments for want of a better word on some of your designs. You know the kind of thing that other web designers go oh. The most kind of well known example would be the Silverback holding page where you have the clever resizing background How did that come about? Where did that idea come from?

Paul Annett: It comes from… it’s fortune, really, that I happened to be building that page because it was one of the holding pages. I always look for something unusual to do, or something that’s going to catch someone’s eye, that kind of thing. That particular technique was quite appropriate because the site has quite a niche audience, in terms of web designers. People who wouldn’t necessarily pick up on the subtleties and things that I like that are in there, they’re like hidden gems, wouldn’t care. Web designers seem to catch on to that, it’s something they haven’t seen before. The particular technique itself was just a happy accident, really, because I virtually designed the site, it’s a very simple little holding page with the gorilla icon, designed by Arch Nemesis podcaster, John Hicks.

Paul Boag: Well he designed our logo as well so he can’t be that arch nemesis

Paul Annett: That was fantastic drawing on it’s own. But then when I put the vines there, I was just thinking finally give it some kind of depth. I was fiddling around with some of the CSS, and because I don’t know, this is a benefit, because I don’t know CSS like the back of my hand. I do sort of dip in and out. I might make mistakes. Those mistakes might accidentally do something that makes me go oh hang on maybe I can actually use that for something, which is what happened in this case. I happened to position the only layer of vines that I had a percentage off the screen. It moved in relation to the grid. That got me thinking, well maybe I can do this with multiple layers of vines. I didn’t think much of it at the time, but I happened to mention that I had launched the holding page on twitter and a few people.

Paul Boag: All hell broke loose.

Paul Annett: Yeah the few people that follow me thought oh that’s nice and they twittered it, and other people twittered it. Before we knew it, a day later, we had 25,000 views on the web site and we were thinking wow we’ve hit something here. 50% of those people signed up for more information about our product, which it didn’t even exist yet, and the web site didn’t even say what it’s about. So they were just intrigued to find out more based on the what they had seen.

Paul Boag: So that caught you very much by surprise then?

Paul Annett: Oh yeah We were kind of overwhelmed. If it had been, in an anyway, some kind of planned INAUDIBLE machine, then we would have waited until we had actually started building the app probably. We had over 10,000 people signed up for something we were thinking we’ve really got to pull something out of the bag here. Hopefully we did.

Paul Boag: Well you do have very good feedback on it. That really demonstrates well the power of design, that even something that, let’s be honest, is maybe, gimmicky is not the right word but you know, isn’t fundamental to the functionality of the site, yet had a huge marketing impact. So it was very worthwhile.

Paul Annett: Exactly. These things, they are gimmicky. They’re things that people come back to and play with and just want to fiddle around and look at it again. They don’t mean anything. The idea is that they entertain me and maybe some other web designers. It just happened that it entertained 25,000 web designers.

Paul Boag: Is this something that you do regularly? Do you sneak things like this in a lot?

Paul Annett: It is something that I like to do, as I said, to entertainment myself. But I do now look for places where I can sneak these things in. I think I’ve always done it really. I always strive to do something unusual. Back in the days of my freelance site, which is nice-design.co.uk, which is still there but not updated since IE8 so if you are using IE8 it will break. Even then, that was one of the first sites where the header and the sidebar were fixed and it was only the content that scrolled. It’s an unusual thing to see, other than the framesets, obviously, back in the day. I always try to sneak these things in. And when I’ve been working here at clear:left, last year’s de-construct site where we snuck in an Easter egg. There’s a style switch on it, I don’t know if you saw it, but when the site launched it was like a wire frame and along the top there a time line which said the progress of the site as it was being built. It was played as if it was being built live as the event got nearer. The time line at the top was actually a style sheet switcher and we deliberately hid the mouse cursor and made it not look like a bunch of links so that if people found it by chance then they would be pleasantly delighted at the surprise of these extra designs on the site that they’d found. Actually we had a few people email us and say terrible usability, they don’t look like links and the mouse cursor doesn’t look like a hand when you move over them. They kind of missed the point, it wasn’t supposed to look like a link, it was supposed to be a hidden little gem for people to find. That got good feedback as well.

Paul Boag: It’s that creating a sense of satisfaction from a user that they found something special or you know, it’s that little bit of wow factor.

Paul Annett: Yeah. When people are then able to say their friends oh go on look at this, then they feel like part of an exclusive little club of people that are in the know. Definitely.

Paul Boag: You talked a lot of the Silverback example of how basically that came about because you were fiddling with CSS and then something didn’t behave as you expected it to and you saw some potential in there. So that was very much a technology driven way of coming to it. Is it always like that or are sometimes these things planned in from the start. I guess in others words, do you have the ideas and implement them or how does it happen?

Paul Annett: It really varies. Sometimes it’s design driven, like with the de-construct site last year, that was design driven and we wanted to have something which resembled the process that building a web site out there. The silverback one was kind of technology driven but also slightly design driven because I wanted to give it that depth. To take that one step further, I’ve used the same technique on the UX London site. UX London is another conference were running next year in June, uxlondon.com. The technique that I used on silverback is reimplemented there. There’s no three dimensional movement or anything like that, but as you resize the window, the logo changes color. That’s just done by having a transparent window through the logo in the shape of the U and the X, so as you resize the window, the background color behind the whole page slides sideways and changes the color of the logo. This kind of this could be done with Flash, it could be done with Java Script, but I don’t know Flash, and I don’t know Java Script, so it is me trying to find my own little work around and quirky way of doing things really.

Paul Boag: I guess the thing that you know when you start thinking about these things is browser support. Some of these things you are doing are kind of either very advanced CSS or very hackerish CSS so either way you come up with browser support issues. Do you worry about that or is it just that they’re extras and it doesn’t really matter.

Paul Annett: Well fortunately because the audience for the sites that we’ve done in this sort of extreme way are web designers so you know they are going to be using the latest browsers. They’re going to be using firefox and they’re not going to be using IE6. We wouldn’t go to that sort of an extreme on a client web site and everything that we do, everything that leaves our doors is valid CSS, valid HTML. It wouldn’t be allowed not to be if you know what I mean. We’re very standards aware as a company, but I do like to kind of push the boundaries on things a little bit and see what I can get away with. Not in anyway inaccessible, but just not very conventional and if it doesn’t work in IE6 and doesn’t work in other browsers then as long as we implement something that looks the same but without the effects then that’s fine. The silverback site, if you look at it in IE6 is just a gorilla in front of some vines, no movement, nothing lost. Nobody coming to that site will be like there’s something missing here, but they just won’t get that extra little embellishment.

Paul Boag: It’s that graceful degradation.

Paul Annett: Progressive enhancement really. Most people that do have the technology get the extra stuff. This isn’t a company policy, but personally I’m usually in the favor of, I’ve seen quite a couple of sites recently that had a browser upgrade nag bar where if you’ve got IE6 then it says hey just upgrade your damn browser, you’re missing out on stuff. We’d never do that, we wouldn’t put that on a client site here, but I might put that on my own site. I haven’t, but I might.

Paul Boag: Sounds like a good idea to me. What’s the kind of process you go through in getting these extras added in? Are they kind of planned in from day one. When you, say for example, did the UX London web site, did you have it in your head right from the beginning that you wanted to do this with the logo, or something occurred to you further down the design process? When did it happen, is it in the design stage, the build stage?

Paul Annett: With that particular one, that was something that I tried out on a previous site. It didn’t really work 100% and we thought we’ll do something else with the site. But I had it in the back of my mind that I wanted to do it from the start on that project. But in general, again it varies really. If, sorry to be so vague and unspecific.

Paul Boag: No no, that’s the nature of design isn’t it?

Paul Annett: One thing I do advocate is that with all our client’s stuff, as well as our own stuff, I always present mock ups in a browser. I never send out a JPEG of mock ups to clients because for start, they are going to view it at the wrong size, they are going to look at it in preview or some kind of windows equivalent, image viewer, and it’s going to be resized to fit their screen, so they’re not going to see it in the context of the web site anyway. Not only that, but it also gives you the opportunity to actually build part of the site so you might have the header as a flat JPEG and the footer as a flat JPEG and the left hand side as a flat JPEG but the right hand side, where you want some kind of interactivity, you could spend a little bit of time building that so that it kind of explains to the client that this is what I want to happen here, roughly. Obviously it wouldn’t be the final thing because you don’t want to invest that much time up front, to give them that little bit of insight. That’s what I do when I am building holding pages or whenever I do get the opportunity to do something like that in house here is that I’ll code up some bits I think is the unique, gimmicky bit of it, and all the rest will just be a flat JPEG. It’s just to sell the idea internally, if you like, and to have everyone gather around my Mac here and ridicule me and laugh at you.

Paul Boag: It makes sense that more and more web design that we are doing these days has got so many interactive elements with use of Java Script and various other things, that a static JPEG doesn’t always cut it anymore does it?

Paul Annett: No, exactly. Another thing we do to combat that here at clear:left is that we often build prototypes of a site, instead of having like a paper wire frame which we often do as well but if there are interactions that need to be explained to the client we’ll build a flat wire frame of it in HTML just using framework and Java Script libraries and simulate the AJAX side of things just with hard coded Java Scripts. It’s also not production quality code, but the prototype wire frame and the flat JPEG combined will give the client a better idea of exactly how the finished site will be.

Paul Boag: Sounds good. We’ve talked a couple of time about is this gimmicky, is this not you know… I’m quite interested as where you feel the line is drawn between good design here and tipping into that naff gimmick area. Do you know what I mean?

Paul Annett: Yeah. There are a couple of things that haven’t seen the lights of day yet, which maybe they will one day. I guess it depends on how much time it’s going to take and how much value it gives us at the end of the day. Using a similar kind of thing with positioning elements we’ve got these great big letters in the clear:left office and we regularly rearrange the letters that spell clear:left to spell different words on the shelf at the office. To simulate this online I’ve built a little page which has got the word clear:left across the page when it’s at full screen at 1024 pixels wide and as you resize the window all the letters swap places because they’re all positioned at different places at different percentages off the screen, blank bits of image and all this complicated CSS positioning going on. When you reach 800 pixels wide it says elf:cartel. So it doesn’t have any fundamental reason or… it doesn’t do anything, it’s pointless, so it’s not going to be anywhere probably. But that is too, possibly gimmicky. There are some ideas which are not necessarily web based which are gimmicky but do work like when we were planning this year’s de-construct and INAUDIBLE wants to get some silverback promotion in there. I talked to him why don’t we just have a gorilla one day running around dishing out silverback branded bananas. Everyone laughed and thought it would be stupid, and then we did it. And then it was really successful and everyone loved it. Yeah, it was a bit of a gimmick but again it kind of fitted with the brand so it worked.

Paul Boag: It’s a fine line isn’t it, you walk in things like that? Because you know you could have been absolutely ridiculed for something like that. How do you know what is going to go down well and what’s not? I guess you don’t.

Paul Annett: Yeah, luck. I was ridiculed for that here in the office but we went with it and it seemed to work. It was great fun.

Paul Boag: I’ve seen pictures. It looked entertaining if nothing else. Going back to the online stuff, even if you develop something like that, it never sees the light of day, you never know that technique may come in use in a future web site that you develop and it might be appropriate.

Paul Annett: Yeah there’s always like a library of that stuff that we’ve kind of half developed and ideas that we’ve got, notes, that kind of thing. It might well see the light of day in the future

Paul Boag: Let finish off with just a kind of general advice that you like to give designers out there that they look at some of the cool little things that you do and they think I’d really like to do that but I don’t want to just go out and copy him because there’s nothing imaginative in that. I want to kind of get into that mentality of looking for opportunities to do this kind of thing. What advice can you give them? How can you start them off?

Paul Annett: There’s loads of stuff that’s come out as a result of the silverback hype, if you like. There was an article that I did on ThinkVitamincom which kind of explains how to achieve that technique. People have taken that and done all sorts of other things with it. I’ve seen someone creating moving 3d images and that style of a zoetrope(?) toy thing, which uses the same kind of principles but applied in a different way. So by all means, the best advice in all cases of web design is to look at the code, see how someone else has done something and see how you can adapt that to your own stuff. One thing that I really rely a lot on is, especially in these hidden Easter eggie things, is alpha transparency and thinking of how you can create a window through the front layer of a web site so you could have, instead of having a white background on the web site, put a white foreground layer with a window through it, shaped in the shape of whatever, and see how you can make that interact with the background layer so as you perhaps scroll down the page something becomes visible through this previously invisible transparent window. There’s a site called webleeddesign which does this brilliantly. That’s my ultimate, I would have loved to have made something like that, it’s really good. Only that one page, but it’s really nice with that alpha transparency in the front there. Think about what you can do with resizing the text on a browser so-we redesigning the clear:left site at the moment, hopefully it will be online soon-now I’m giving up an Easter egg that’s coming up on it.

Paul Boag: No one listens to this podcast so it’s fine.

Paul Annett: There are certain things hidden on certain pages and if you bump the text size up a couple of points then those things would become visible because of course you can control the position of things based on ems. As you resize things, your font size gets bigger, it perhaps moves in relation to the other things and things begin to peak out from behind something that was previously in front of it. I play around with that kind of thing a lot. That’s the advice I’d give you in terms of this particular way of doing things.

Paul Boag: That’s some great advice there, there’s lots of possibility. I like what your saying that it only takes a small number of techniques, you talked about transparency there, you talked about the background stuff, and you talked about the font resizing, but the possibilities of just those three things are endless really. You could do all kinds of things with them.

Paul Annett: Exactly, combine them in different ways. Again someone take this and do something with it, but imagine a line going diagonally across the screen but in font of that you’ve got a completely white page and across that white page is a very narrow slot of transparency, so if your line starts at the top right hand corner all you see is a dot in the top right hand corner but as soon as you start scrolling down the screen, that dot moves to the left because it’s visible through that hole. That’s a very basic example of how you could use windows of alpha transparency interacting with the background to do something which moves horizontally as you scroll vertically. I haven’t done anything with that yet as I haven’t thought of anything good to do with it but maybe someone can.

Paul Boag: That’s absolutely brilliant Paul, there’s some really good advice in there and thank you for taking the time to come on the show. I hope we can get you back on before too long.

Paul Annett: Thanks. Thanks very much for having me.

Thanks goes to Troy Oltmanns for transcribing this interview.

Feature: Improving your site with user feedback

Users can be invaluable when deciding how to move a website forward. We should always listen to what they say. However, sometimes that is easier said than done. Read more here.

140. Launch

Posted in Classic shows on October 22, 2008 by Paul Boag

In this week’s show GetSignOff has finally launched, we talk about how to use web stats to improve your site and we answer your questions about roles with web design and should you help clients with hosting.

Podcast: Download (25.2MB)

Download this show.

Launch our podcast player

News and events

Acid3 receptions and misconceptions and do we have a winner?

The team that develop WebKit, the open source web browser engine that Safari and the new Google Chrome are built on, have just announced that the engine passes the Acid3 test developed by The Web Standard Project (Wasp).

So what is Acid3?

Acid3 runs a series of tests against a given browser and produces a score, the goal being 100/100. This score is generated from how "standards compliant" the browser is. For example whether it supports CSS2.1 styles such as "inline-block" and "pre-wrap", if it supports SVG-Fonts, what DOM features is supports and a whole range of other criteria.

So WebKit passes!

Does this mean we should ditch Firefox, IE and all the other browsers in favour of Safari or Chrome, well no, and that’s what Lars Gunther is talking about in his article over at WaSP.

It’s great that tests like Acid3 exist and that browser developers endeavour to build better browsers because of them. All in all it results in a much better experience for the average user and makes our lives as Web Designers much more hassle free.

6 Things To Like About Dreamweaver CS4

So Dreamweaver CS4 became available this week, 15th October to be exact and Alex Walker over at Site Point has been having a play and has shared with us 6 thinks he likes about the new release. Check out his article for details of each, but a summarised list is:

UI/Workflow Improvements
The Related Files Toolbar
Code Navigator
Live View
Advanced JavaScript Interpretation
Making JavaScript Unobtrusive

From reading the article these improvements over the previous version look really promising. One feature that really caught my eye is "intelligent code completion" for JavaScript and the most popular libraries such as jQuery, MooTools, Prototype etc, the same way it does for HTML!

It would also appear that Adobe are making big improvements to the "Display View" of Dreamweaver, which has historically been the stigma plaguing most "professional" designers who use it. The "Display View" now has integrated code navigation, so you can use it to jump to specific elements within the page and Adobe have also built WebKit into Dreamweavers core so you can run your site through the software to test JavaScript, rendered CSS, server-side code etc.

So will these new features encourage more people to use Dreamweaver?

7 Ingredients of Good Corporate Design

Smashing Magazine has published a great article that discusses 7 ingredients to good corporate design. They break the discussion into two elements:

Design as artistic representation, which consists of:
- Logo
- Typography
- Colours
Design strategy, consisting of:
- Brand
- Quality
- Community
- Culture

It’s important to understand that corporate design isn’t simply of a graphical nature but is intrinsically linked with your strategy, the goals that you set and how you implement them and this article is well worth the read.

Launch: GetSignOff Goes Public

Monday GetSignOff finally opened to the public. It has been an interesting journey read more here.

Feature: Using Web Stats for More

We all use web stat tools like Google Analytics for tracking marketing campaigns. However, they can also be used to improve your site. We discuss this in this weeks feature.

Listeners feedback:

Salesman seeks designer/developer

Got this audio question from Andrew:

Hi Paul, hello Marcus and hi to all the people who work at the show. I live in Canada so hearing your nice English voices through my headphones is great. My name is Steve and I’ve done some freelance web design for clients in the past, but the part I enjoyed the most was the selling cycle; being able to explain to the client what a standards based website could do for them and then persuade them that investing in such a site would be wise for their business. I bet there’s a lot of designers and developers out there who are absolute Jedis when it comes to coding CSS and HTML but really hate the selling part. And then there are people like me who can really sell well but I wish I could work with people who are amazing at building websites.

My two-pronged question is as follows:

Is there a website or another resource that would allow people like me, who love web design, but are more business/marketing oriented to touch base with people who are in the opposite situation? And I’m thinking more than just a job board here, I guess the best analogy would be something that Marcus might be familiar with – adverts in the back of music magazines that would say something like ‘band seeks drummer’ or ‘talented singer needs people to play instruments’.

My other question: how did you guys do it at Headscape, were you all great at coding and someone had to get pushed out the door and start selling or were there very separate roles from the beginning?

Ok, part one first (I’m original aren’t I)… the ‘band seeks drummer’ analogy is good but I much prefer a dating agency analogy! Cuddly, financially sound salesman WGSOH seeks quiet, intense, practical developer for fulfilling relationship. :-)

As far as I am aware, sadly, this service does not exist. Forums, like the Boagworld forum, have got to be your best bet.

Right, part two. Much as I would love to claim that I used to be great at coding before they kicked me out of the door to do the selling, it would be a blatant lie. When Headscape started, the three of us came from different disciplines – Paul was designer/tech (it’s true!), Chris was project manager and I was salesman. We soon didn’t have enough design/tech resource and started to recruit but the fact that a) Chris was organising and pushing projects along and b) that I was concentrating on bringing in new work meant that we were running things like a larger agency (more efficiently and with less risk) very early on.

I have banged on about how important effective selling is in the past many times so won’t repeat myself here. The only thing I will say is that having totally separate roles is not necessarily a good thing. Even now, we don’t have very separate roles. Chris and Paul are both heavily involved in the sales process and always have been. In my view, it is the responsibility of the company directors to se
ll.

But, added to that, Chris and I also do a lot of consultancy work (requirements analysis, IA work etc), and Paul still does design work. This is important because it keeps our ‘hand’ in. Getting too involved in one role can often lead to a lot of potentially out-of-date talking, and very little ‘doing’.

Do/should you help clients’ with hosting?

Hi all

I’m just about to do a ‘simple’ website for a friend (aka my 1st client) which will try to market something he is looking to rent out. Whilst I’m confident I can do the website, I’m not sure how far I should go with helping/organising his hosting. The client doesn’t know anything about hosting and doesn’t have any hosting space with his broadband provider.

Now I don’t really want to get into organising hosting unless I have to, so I’d just like to know what the ‘norm’ is in this regard? As a web developer/firm do you automatically sort out hosting, do you get the client to do it and then give you the hosting password so you can upload the site? Is it even a good/lucrative idea to get involved in sorting this out as part of the ‘service’? Can people suggest what they do please?

Thanks, Alex

This question came from the Forum and there are already some interesting posts in response. The biggest issue here is:

Can you support this website?

Can you provide support if the site goes down in the middle of the night, on Christmas Day, or even when you’re on your two week break to Spain?

If you decide to sell hosting then you become a middle man between your client and the hosting company. Your client is contracted to you to provide and support hosting, not the hosting company. Of course, you have a relationship with the hosting company where they will provide an agreed level of support but… you are still the person that has to deal with your clients’ issues as and when they arise.

At Headscape we are completely open about this with our clients. We tell them that we only provide support (of any kind) on working days between 9am and 5.30pm. We’re not set up to do anything more than that.

However, we do offer hosting for those clients that feel that the level of support that we offer is enough. We have our own managed platform and we also act as a reseller for a large hosting company.

The solution for those clients that require a superior level of service is simple. The client buys the hosting directly thereby taking you – the agency/freelancer – out of the loop. We specify technologies, discuss the level of support required, amount of bandwidth etc with client – we will also set up the site on the web server – but the client orders and pays for the hosting.

This has worked really well particularly for the larger, busier sites that we have developed.

All that said, if you act as a reseller, and you have enough clients, you can make a decent profit via hosting. However, don’t be fooled into thinking that it doesn’t involve any work keeping all those clients happy and up to date. If you have enough clients to make money out of hosting then it’s very likely that you will have regular hosting issues to deal with and constant renewals to deal with.

My friend and colleague, the long suffering Mr Scott, has many times said that he wished we had never touched hosting simply because it often ends being a constant irritation that gets in the way of project work and rarely pays for itself.

GetSignOff goes public

Posted in News on October 20, 2008 by Paul Boag

Today GetSignOff finally opens to the public. It has been an interesting journey.

Part of my reason for writing this post is obviously to pimp GetSignOff and to encourage you all to check it out. However, I also want to take a moment and reflect on the lessons learnt so far. This is Headscape’s first application and we have got some things right and some wrong. I wanted to share all that I have learnt.

However, let me begin with the blatant advertising…

What is GetSignOff?

GetSignOff is an application aimed at web designers. It allows you to present designs, manage feedback and handle multiple iterations of a design concept. However, most of all it is designed to help you get sign off from clients.

It has loads of cool features…

Can be used to approve mood boards, interface elements, imagery, personas, storyboards, site design concepts or any other element of the web design process
Fully customisable CSS and visual appearance
Use your own customised domain name
Up to 30GB of storage
Manage unlimited numbers of clients, projects and designs
Create and manage multiple versions of each design
Add notes directly on your designs
Check to see if a client has viewed a design
Receive notifications via email and RSS
Each client can support multiple logins
Restrict client logins to specific projects
Easy to use interface (ideal for clients!)
Clear sign off procedure to ensure everybody knows when a design is approved

Okay, I have pimped it enough now. Signup for a free account and try it yourself.

What we have learnt?

Building a web application is nothing like building sites for clients. It has been a real eye opening experience and we have learnt a lot on the journey. At the minute my head is spinning but I wanted to share a few random thoughts. Apologises for their rough and ready nature…

Beta users rock! – The best thing we did was release a beta. Getting feedback from real users blew away our carefully laid plans and ‘all knowing’ attitude. Our beta users came up with some awesome ideas, and found horrendous bugs. However, even when they criticised the application they were amazingly encouraging. I can never thank them enough and would encourage anybody building an application to take a similar approach.
Cherish your users – I know saying ‘customer service is important’ has become a cliché but that is because it is true! People are so grateful when you answer their enquiries quickly and efficiently. You can defuse an angry customer by simply being helpful and attentive. It is not difficult.
Keep it simple – The temptation to add more and more features is overwhelming. People come up with great ideas and you have the overwhelming desire to use them. However, resist this temptation. I am so glad that I have read both Subject to Change and The Laws of Simplicity while developing this app. Both have encouraged me to keep things simple.
Don’t rush into features – There is also a desire to implement great ideas quickly. Somebody suggests something so good that you just have to add it. The trouble is this can lead to all kinds of complications. I have learnt it is better to consider an idea for a couple of weeks before implementing.
Pricing is a bitch – I hated this part. We looked at the competition, considered the value to the client and still couldn’t settle on a price. Unfortunately, it was hard to rely on feedback from beta users in this area. After all, they wanted it to be as cheap as possible. In the end it was Ryan Carson who helped the most. He warned against under pricing and rightly so. I think we all have a tendency to devalue our own work.
You only get one chance – This is currently terrifying me. You get one chance to make a first impression. I know the current wisdom is to release early, but if you release crap then users will never come back. Hopefully we have struck the right balance between quality and getting to market quickly.
Treat it like client work – This project stagnated for ages. It was something we wanted to make happen, but slipped because of paid client work. The way we kick started the project was by pricing and running it as a piece of client work. Only then did it get the priority it deserved.
Don’t fear competition – The first time we heard about a competing product we were gutted. By the third and forth we were in danger of slipping into despair. However, actually there was no need. Competition is good. It spurred us on and we even learnt from mistakes our competitors made. However, most importantly of all it made us focus. Until then we were trying to build an application that met the needs of anybody wanting design sign off. After we became aware of the competition we focused our app on meeting the needs of web designers. We decided to go niche and it was the best thing we could have done. While our competitors struggle to meet disparate needs, we focus on the requirements of a single target audience.

In reality we are just at the beginning of our journey. We have so much more we want to do with GetSignOff. However, there is no doubt that today is a significant milestone.

All I would ask of you is that you give the product a chance. If after signing up for a free account you like it, tell your friends and blog about it.

137. Adobe

Posted in Classic shows on October 1, 2008 by Paul Boag

In this week’s show, Aral Balkan joins us to discuss the release of Adobe CS4 and we discuss how not to get blacklisted by google.

Download this show.

Launch our podcast player

News and events

Adobe CS4 is released

The biggest news of the week is the release of Adobe’s CS4 suite of products. This includes new versions of Photoshop, Flash, Illustrator, Dreamweaver, Fireworks, the list goes on.

This leaves every web designer asking the question, is it worth forking out over one thousand dollars for the latest set of enhancements? As always it depends on how you use the products.

The most significant changes are in workflow and interface. Adobe have been adding features to their applications for years and some of the interfaces have become unwieldy. This release addresses a lot of these issues. They have brought buried features out of the menu and into palettes and toolbars.

Also, if you tend to work entirely in the Adobe universe, you will be interested in the workflow improvements. It is now easier than ever to move work between applications and manage your entire workflow throughout your site development process.

However, workflow and interface improvements are probably not going to make you upgrade. After all how excited can you get about that kind of stuff?

What may tip the balance are the new 3D features. For example in Flash you have substantially improved animation tools for 3D objects and in Photoshop it is now possible to import 3D objects into a 2D image and manipulate them. I can see many web designers moving from buy stock photography to entire 3D models because it provides substantially more control.

However, if you are still debating about whether to upgrade to the latest version of Photoshop, go and check out a feature called ‘content aware scaling‘. It will blow your mind.

For more on the new features in Adobe CS4 listen to our interview with Aral later in the show. Also check out Adobe TV for video demonstrations of all the new features across the entire range.

Fire Vox

Next up is a Firefox extension that allows you to transform Firefox into a screen reader.

We all know accessibility is important. We all know we should develop with screen readers in mind. However, many of us fail to test in screen readers because they are expensive and time consuming.

Well, now you have no excuse. Fire Vox is an open source, freely available talking browser extension for the Firefox web browser. Think of it as a screen reader that is designed especially for Firefox.

In addition to the basic features that are expected of screen readers, such as being able to identify headings, links, images, etc. and providing navigational assistance, Fire Vox provides support for CSS speech module properties. It also works on Windows, Macintosh, and Linux.

Installation is slightly more fiddly than your average extension but if you follow the instructions it is easy enough to get up and running.

Once installed, it is probably one of the easiest screen readers I have used. They also provide some excellent tutorials on their site to get you up and running.

I highly recommend it.

Irresponsible content publication

According to Gerry McGovern, on the 8th September, a story about the bankruptcy of United Airlines parent company began circulating on the Web. Within hours of the story’s being released, their shares had dropped by 76 percent.

What has this got to do with web design I hear you ask? The answer; the story was 6 years old. Somehow it had been picked up by Google News and quickly caused panic among share holders.

Gerry uses this as an example of the dangers associated with out of date content. He goes on to talk about how our ‘content management system mentality’ has led to an online environment without editorial control.

The production of content for our sites has become so distributed and unregulated that nobody is responsible for reviewing or removing content. We put content online without considering if it is needed or whether it has an expiry date.

The content of our websites has been largely neglected and I believe the time has come for website owners to put the same investment into content as they do into the build of a site.

For those of you who are web designers, I would encourage you to start talking to your clients about how they plan to manage the content on their sites. Who will be responsible for the relevancy of what they place online?

Code CSS the clear:left way

It is always interesting to see how others build websites particularly when it is a high profile company you respect. One such company is Clearleft who are known for the quality of their CSS and Javascript.

One of the developers at Clearleft is Natalie Downe. She recently spoke at Barcamp London about the methodology Clearleft use when coding in CSS.

Although I didn’t get to hear her speak she has put her slides and notes (PDF 64.2mb) online. Fortunately, her notes are extremely comprehensive and it gives a real insight into her approach.

Obviously, there is not a single approach to building websites. However, Natalie shares some interesting ideas about ensuring your CSS remains maintainable and can be easily handed to other developers.

Interestingly we follow a similar approach at Headscape although we do differ in a few key ways. Nevertheless it is fascinating to see how others do it and there is a lot to learn from what Natalie shares.

Interview: Aral Balkan on the new Adobe Products

Paul: Ok, so joining me today is Aral Balkan, good to have you on the show.

Aral: Oh, thank you Paul, it’s always great to be here.

Paul: It’s been a little while, but it’s good to have you back, and we’ve got Aral on the show today, really to talk about a couple of random things really…

Aral: The story of my life!

Paul: …yeah, the story of your life, yeah, um, one of which is the new Adobe suite of products that are coming out, but before we get onto that, let’s talk about <head>, previously Singularity, what’s all that about for a start, what happened there?

Aral: Uh, with the name change?

Paul: Yeah.

Aral: It was quite unfortunate, about 2 weeks ago or so, I got a letter from a company called Singularity Ltd, and they’d apparently trademarked "Singularity" the word, and you know how trademark law works, it’s got different categories apparently, and these categories are really wide, so a single category coul
d include things like training and conferences, so this company was not actually doing a conference called Singularity, but they trademarked it under the same class, and so they weren’t too happy that we were using the name, and we had a talk as well, I called them up because I was like, oh crap, might as well just talk it out, and it just seemed like they wanted to have a legal conversation through the lawyers and stuff, you know, I’m not really into that, we only had 2 months to go and, you know, we’re a first year conference so I didn’t have the budget or the time really to get into that sort of a conversation and so I was like, yeah, you know what, this is going to hurt but let’s re brand, so I took a weekend out, redesigned the site, redesigned everything, and then we decided to go with the new name. I actually really like the new name…

Paul: Yeah, it’s a good name.

Aral: …it’s kind of edgy, it’s short, it’s memorable, and you know, given everything else, I probably wouldn’t have changed the name 2 months ago if I’d had a choice, but still, I like it.

Paul: These things happen don’t they.

Aral: These things do happen apparently, yeah.

Paul: So tell us a little bit about <head>, what is it? You know, it’s obviously a conference but tell us a bit more about it.

Aral: Well, it’s this conference and we have this amazing guy; Paul Boag speaking at it.

Paul: Well, obviously, yeah!

Aral: And that’s really all I need to say! How do you like that one?

Paul: That’s perfect. Keep going, you’re doing well.

Aral: It’s a virtual conference, so all of the sessions are streamed live over the Internet, and they’re interactive so you can ask questions as you’re viewing them, and the speaker can answer those questions. We’re using Adobe Connect Pro in order to do that, so it’s a tried and true system that’s been around for quite a few years actually, surprisingly. Also we have a couple hubs in London, in Manchester, we’re going to have one here in Brighton, one in Belgium, and there are a few more that still haven’t been finalised, but we may have 1 or 2 more hubs, and the one in London for example is taking place at the Magic Circle which I’m very excited about, it’s a lovely venue. Have you been there?

Paul: I’ve heard of it, but I haven’t actually been there, I’ve heard of other people talk about it.

Aral: It’s awesome, I was there last week, and it’s basically like the magician’s society in the UK, so it’s been around for about 100 years, and it’s got a museum where you can see actual items from Houdini and other people. Did you know that Prince Charles apparently is a member of the Magic Circle?

Paul: Oh, that doesn’t surprise me.

Aral: And he apparently had to do a little trick to get in with these cups and this ball, and he got accepted into the highest order of the magic circle, just kind of crazy!

Paul: There you go! So when is this conference?

Aral: The conference takes place October 24th to the 26th, and it’s everywhere, so you sign up to attend, and you can watch it from home, or if you’re in one of the cities where we have a hub, you can go from there.

Paul: I mean, why virtual? Why did you decide to have a virtual conference rather than the traditional get-together kind of thing?

Aral: Personal reasons Paul! No, um, actually seriously I do a lot of talks at conferences, so I fly around a lot, and the flying around bit and staying in strange hotels, sometimes it’s a great experience but depending on the hotel that you’re in, that’s not the bit that I really enjoy. You know, you go to a hotel, you don’t have wi-fi, the wi-fi costs 3 billion dollars or something, and I got to thinking whether that was actually part of the conference experience, the positive part of it for me, and I thought maybe not, and we do stuff on the web, that’s what we do, that’s the line of business that we’re in. So I thought why not try and see if we can create a conference that’s virtual, but yet try to keep some of the aspects of conferences that we like the most, like the social interactions, and that’s where the idea of the hubs came from, and that’s why it’s interactive and people can ask questions and communicate during the conference. And it’s an experiment, you know, it’s a first time conference so we’re trying it out, we’re going to see what works, see what doesn’t, and then we’re going to evolve it next year.

Paul: I mean what I find incredible about it is, I guess because people don’t need to travel, you’ve got an absolutely incredible line-up of speakers.

Aral: We do have some great speakers!

Paul: And you’ve got so many of them as well, there’s, what is there? Over 70 odd speakers?

Aral: Yeah, yeah, we’ve got 70 plus speakers, we’ve got amazing people; Tim O’Reilly for example is speaking, he’s doing a keynote in the London hub in person, we’ve got Jason Fried, and we’ve got yourself of course…

Paul: I don’t think you could put me in the same category as those 2, but keep going. I like the sound of it, that’s good.

Aral: Course we can! Dude, I’ve seen you in so many conferences, you rock! Um, and we’ve got Molly, Jeremy Keith, we’ve got so many people, I mean Rafi Haladjian, he’s the father of the Nabaztag bunny… I have one here! Yeah you saw it, when I came over with you guys.

Paul: Yes, I know how obsessional you are.

Aral: So, I mean, we’ve got amazing people. Gary Vaynerchuk, Wine Library TV, he’s awesome, I’m going to see if we can try and get a live video hook-up during the London hub with him, he’s just awesome, and just a whole bunch of people, I’m forgetting half of them, Richard Moross from moo.com, another one of my favourite companies.

Paul: It’s just a stella list, absolutely unbelievable. Do you think people are going to miss out from the fact that they’re not going to have that face-to-face experience?

Aral: I sure hope not, you know, we’re trying to build things that compensate for that, and next year especially I’m going to concentrate much more on the hubs. You know, I’m thinking of scaling it down next year because we’ve kind of gone for everything this year, which is exhilarating, but at the same time for a first year conference it’s a lot to do. Next year I’m thinking of maybe scaling it down a little bit, concentrating on 1 or 2 hubs, and try to build new interactions for connecting those hubs. I’ve got some really cool plans for it.

Paul: I mean, one of the kind of interesting things about this as well is the kind of underlying technology of all of this. I mean, how is it working, how are you going to connect all of these people? I mean, you’re talking about thousands of people, 70 speakers, you know, here I am sitting in the middle of Dorset in the back and beyond, you know, and how are all these people going to see my presentation?

Aral: Well, we’re using Adobe Connect Pro, so that does have a limit currently of 2,000 people in a room, so that’s where we’re limiting our attendance, we’re definitely not having more than 2,000, and I don’t think that’s going to be a problem. But Connect has a lot of features for basically connecting people. You can see the streamed audio and video of a presentation, but you can also interact both by typing, or you can send your own video feed. We’re probably not going to use that because of bandwidth concerns, but people can interact with other people who are in the session, they can chat with them and with the speaker, and so at the end of every session we’re going to have a question and answer, and the speaker will go through all of the written questions that they’ve received during the talk and answer them, and that format has really worked in the past as well for meetings that we’ve done.

Paul: So, this is not a technology I’ve come across before, this is something that’s kind of publicly available from Adobe is it?

Aral: Oh yeah, totally, Adobe Connect Pro has been available for several years. I think the full name, and it’s got one of those really long names, is Adobe Acrobat Connect Pro.

Paul: Right.

Aral: I know, I don’t know where they come up with them. But it’s a really cool piece of software for doing meetings and these sorts of virtual presentations. It used to be called Breeze.

Paul: Ahhh, that’s the name I recognize.

Aral: Yeah, there you go. It’s been around for years and years, so it’s really really stable, and Adobe actually has a new version of it, I don’t know what they’re calling it, I remember it’s beta name I think, but they have a free version for up to 3 or 4 people, so if you Google for that, or like in the transcript or something you guys can find it and link it, that’s really cool because you can just start playing with that. It used to be called Brio. I don’t know what they’re calling it now it’s been released.

Paul: The other thing that I noticed from Twitter was that you mentioned that you built the website using Google’s App Engine.

Aral: Yes.

Paul: Tell us bit about that.

Aral: Wow, it’s been a fun ride!

Paul: You sounded somewhat stressed at certain points through the period.

Aral: It has been really great.

Paul: What is it first of all? Explain to people what it is.

Aral: So Google App Engine is Google’s foray into providing access to the cloud; to its infrastructure. So basically Google has this massively scaleable infrastructure that hosts, it’s search and on it’s various applications on. So Google’s App Engine is Google’s way of saying "ok, here’s the technology that we have for building these infinitely scaleable applications, and we’re going to make it available to you in a very simple manner so you can build your applications on it and host them on it". And it’s really cool, the idea is awesome, and you’re going to be hearing so much more about it as they add more features to it. It’s currently in pre-release, so of course it was quite a gamble to base the website on a pre-release technology, but I’m still convinced that that gamble is going to pay off because basically the way I see it, there are the most intelligent developers in the world working at Google basically working for my application. Every feature they add basically adds a feature to my app in a way that I can use. So once they integrate things like the Google APIs, once they integrate other features, not that I have any insider information, but it just makes sense that they would do that, I think it’s just going to become a more and more powerful platform.

Paul: But you found it a little bit painful at times.

Aral: Well of course. It’s pre-release, right? And pre-release technologies have issues, so they’re figuring things out. It’s not something that, again, has been done before, Amazon has a really cool platform with simple DB, S3, S32 and those technologies which provide the same thing, but in some ways, Amazon’s platform is much more tested, much more tried, but it’s also more difficult to develop on, I mean, you need a lot of skills, you need to be a system administrator in order to build on EC2, or at least have some knowledge in that area. You need many more skills. With Google App Engine, if you know Python, you just download this SDK onto your machine, you install it and you have a local version of their environment on your machine and you can write a few lines of Python and start running your application on your local machine, and then you just enter one command and suddenly it’s on Google’s servers, and the theory is that a million people can hit it immediately and it’s not going to go down.

Paul: Yeah, which for a conference like this where a large number of people are all going to be using a site at the same time, it’s vital.

Aral: Yeah, and I mean we’re not going to stress it at all with our numbers, but you know, if you think of the next Flickr or the next Twitter, although you can’t currently build a mess
aging app on it, but apps that will get those numbers, that might get those numbers, they won’t have to go through the standard stages of development. Because these days, today, what happens is you build an application, you build it using some sort of rapid framework like Rails or Django or whatever, you build it, you put it up there, and if it gets really popular, then you basically have to go in, you have to re-architect a lot of things. You know, for some apps like Twitter, they’ve basically had to rebuild the application as it’s running. And that’s a lot of work. Google App Engine turns this on its head. You have hurdles to get by when you’re building the application, but you can test it, just with yourself, and if your application runs correctly for you, if you can get it to that point, then it will run that way for everyone that hits it. Or at least, that’s the idea, that’s where they’re heading for.

Paul: That sounds really exciting, I look forward to seeing that develop.

Aral: It is.

Paul: You’re very brave taking it on so early.

Aral: Well you know what, that’s the thing. A few people have told me when I was bitching and moaning when we had a few issues, and let me tell you, Google have been amazing, I have direct contact with a couple of engineers on their team, and they have been amazing in helping me out and working with me, and I’m working with them to try to improve it. But a few people when I was bitching about it were like "well, you know, you just got what you deserve for using pre-release technology". But the thing is, someone has to, right?

Paul: Exactly, yeah.

Aral: Someone has to, so the next time somebody tries a beta piece of software, tries to build it and provides feedback, instead of going "ha ha, I told you so!" kind of think, well you know, I’m probably going to end up using this in a few years time and I’m going to benefit from the lessons you’ve learnt. So some people have to be early adopters, and yeah, getting burned with certain things is part of it. But it’s just how it goes. But what interests me the most, Paul, about Google App Engine, and about like, EC2 et cetera, is that we’re kind of entering the age of the commodity web, where the web, where building scalable applications on the web becomes a commodity just like electricity or water. You know, so we won’t have to worry about things like hosting and this and that, it will just be like another meter reading, you know,um, I’ve made my app, here it is on the web, and I get charged for it by CPU cycles, by the amount of resources that I’m using, just like electricity.

Paul: I mean, that will be awesome. If we can reach that point where we don’t have to worry about scaleability and things like that, that would just be incredible.

Aral: Yeah, I think we’re nearly there.

Paul: That’s superb.

Aral: Yep.

Paul: Talking of you working with people, you said you were working closely with Google over this, I know you’ve got an excellent relationship with the guys over at Adobe, and no doubt you’ve been playing with CS4, tell us a little bit about it. You were over at the launch of it were you not?

Aral: Yes I was, I wasn’t actually speaking about CS4, but I was at the launch and I got to see some of the demos there. It’s a huge suite, you know, I didn’t have the chance to play with everything, so seeing some of their demos, it’s really cool, it looks like they’re really concentrating on integration between the products, they’ve been doing this for a couple of releases now, but it’s really starting to pay off. When Adobe bought Macromedia, everyone was like, well you know, how are they going to integrate things, and people were fearing it was going to be an instant process and some of the tools would be ruined. That hasn’t happened. But they have been integrating the products over the years with these release cycles. So, one of the demonstrations that I saw that was really cool for example was in In Design, which is a desktop publishing tool that they have, you can build a magazine, and then you can click a button, and then have that be an interactive magazine in Flash that you can put on the web with like a page turn effect and stuff like that.

Paul: Wow.

Aral: And that’s actually quite awesome.

Paul: Yeah.

Aral: I spent a bit of time a couple of years ago to build an app that did that from PDFs, and that software is still going strong and being used on the web, but now you can just do that with In Design and Flash. And things like that, it really worked on the workflow between various tools, and it makes a lot of sense because web video is such a big thing now, and being able to take things from After Effects and Premier into Flash and back and into DreamWeaver and put it up on your site, they’re really working on these workflows so they’re not joined to tools. I think that’s really for me the most exciting thing, apart from some of the cool stuff in Flash.

Paul: What have they done in Flash then that’s so cool?

Aral: Some of the cool stuff in Flash? Well, we have bone support now, IK support. You can draw like a stick man for example and then you can take this bone tool and trace over its various limbs, and then have this puppet that you can play with, and the cool thing is, you can publish this and this puppet is interactive once you’ve published your movie as well, it’s not just an authoring. So you’re going to see some amazing advances in like online games that use this, and in animation. For animators, it’s just going to make their lives so much easier. And that’s just like one of the new things they have.

Paul: Did you get a look at Photoshop and whether there have been any major changes in that?

Aral: Yeah! Well they’re really concentrating on the 3D stuff in Photoshop from what I can see. There’s a lot of 3D tools, you can bring in 3D models into it, you can paint into them, they stay 3D as you’re painting into them and outside of them. There was this one demo which I thought was really cool where they took an old-fashioned car and it was like a 3D model, and they just rubbed off the roof, and then it became like this convertable, but it’s still 3D, and they started painting the seats, which is kind of cool. I think that’s going to, again, it’s an integration with your
other tools, with your 3D tools. It does look really cool, I can’t wait to play more with it.

Paul: I guess the only other one that’s directly relevant to web design would be DreamWeaver. Did you get a chance to look at that?

Aral: Yes. Yeah, I did, and it seems to have gotten a whole bunch of new features as well especially with the CSS and their live preview of CSS. But to tell you the truth, I don’t really use DreamWeaver. I started out with, well no, ok, I started out with Front Page many many years ago.

Paul: You should be ashamed to even admit that.

Aral: Forgive me, I know, but I switched to DreamWeaver right away! But recently, you know, I just do a lot of my stuff in Text Mate, and I don’t know why that is, but I just find some of these tools to be way too heavy, especially for HTML, and I really like to have control over what I do. And Text Mate is light, I’ve begun to favour lightweight tools a lot.

Paul: Yeah, I must admit, I use DreamWeaver for a very long time as a text coding tool, not as a WYSIWIG, but in the end, it was just so slow to open up compared to other stuff and it just seemed to be chunky.

Aral: Yeah, I kind of went through the same thing, and I really, like I say, I really enjoy Text Mate. It is such a simple simple editor and it just works.

Paul: Ok, so that’s really great Aral. Going back to the conference just very briefly, by the time this comes out, people are going to have missed unfortunately the early bird discount, so how much are they looking at for this conference?

Aral: Well the main tickets are $149, but who knows, maybe we can do something special for listeners of your podcast.

Paul: Oooooh!

Aral: If they are going to miss it.

Paul: Ok, well you let me know that, and we’ll tag that on after this interview, I can do that easily enough.

Aral: Ok, cool.

Paul: You can find out about the conference over at headconference.com and I’ve got to say, this does look absolutely incredible. Am I right in saying that also people that have attended the conference, there’s no way you’re going to be able to listen to all 70 speakers over those couple of days. So they can go in and watch the videos after the event? Is that right?

Aral: Yep, all of the videos are going to be recorded and you’ll be able to watch them at any time.

Paul: So I mean, absolutely superb for a $149 or whatever it is, that’s an incredible deal and you will never come across a conference that’s got quite this line-up of speakers, and certainly of course, you don’t have to pay for hotel bills, you don’t have to pay for travelling, and you don’t even have to pay for time out of work.

Aral: Exactly, yep.

Paul: Sounds pretty good. Aral, thank you for coming on the show and we’ll get you back again in the future.

Aral: Thank you Paul, oh it will be great, I love being here.

Paul: Ok, good to talk to you.

Aral: Take care, Paul.

Listeners feedback:

Review of Stackoverflow by Teifion

I’m a developer not a designer so if you understand my incoherent babbling please keep in mind that this review probably won’t be as useful for designers but please, fall asleep after I stop talking.

About a month ago I joined a site called Stackoverflow. Essentially it is a cross between a Forum, Digg/Reddit, Wikipedia and a Blog; you ask questions and answer questions, you also get answers to your questions and you generally get them very fast. It is now in public beta.

It’s a simple idea that could be great and could also be completely useless. Jeff Atwood and Joel Spolsky have managed to make it very useful.

Now it’s time to add some actual content to the review or Paul will call me silly names again. Questions in Stackoverflow are allowed to be on any language or topic related to programming and here’s where the designers might be interested, this includes source control, HTML, CSS and even things such as keyboard layouts.

The question that you should ask yourself right after "why am I listening to Teifion" is "Why is this better than google?". The answer is a simple one, Google cannot look at your site and tell you why a div is wider than you want it to be while a site with 8000+ members probably can. I am given answers to my questions within 5 minutes bar I think 2 obscure questions.

Don’t feel that you are too new for the site either, you can ask anything from very simple to very complex questions, anything from "what is a class?" to "how do I benchmark a PHP or Python script via the Unix terminal and not from within the script itself?".

I strongly recommend that everybody check it out.

Don’t Get Blacklisted By Google

Jason from Toronto recently wrote to me with a questions about search engine optimisation:

I am desperate to improve the search engine ranking of my company website but I am confused by the contradictory advice online. We have even considered hiring an SEO company, but aren’t sure who is reputable. The last thing we want is to be blacklisted. Do you have any advice which might help?

It is true that Google comes down hard on sites who disregard their webmaster guidelines. Probably the highest profile example of this was when they effectively removed car manufacturer BMW from their search results for using doorway pages.