115. sxsw

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

On show 115: Lessons learnt at SXSW, Garett Dimon on form design and how to find usability test subjects.

News and events | Lessons learnt at SXSW | Garrett Dimon on form design | Listener feedback

News and events

Microsoft launches beta of Internet Explorer 8

The big story over the last couple of weeks has been Microsoft’s release of Internet Explorer 8 as a beta. This has sparked a flurry of posts from various bloggers on the pros and cons of the new release. However the two that caught my attention were Kevin Yank at Sitepoint and Roger Johansson.

In short, IE8 looks like an impressive update with significant improvements in standards support. It would appear we can finally say good by to HasLayout, while at the same time welcoming decent CSS table support. This will open up a lot of possibilities for layout.

There are too many updates to go through here so I would encourage you to check out "what’s new in internet explorer 8" over at the MSDN blog. You might also want to look at the Internet Explorer 8 readiness toolkit that tells you all you need to know about the new browser.

Designers agnst

There seems to be a lot of designer angst flying around the tubes this week including two posts on A List Apart and one at ideas on ideas.

As designers we seem to spend too much time fretting over the creative process, always looking for inspiration and techniques to improve the quality of our work. Andy Rutledge piles on the pressure in a fascinating article about creativity where he redefines the word. A second post on A List Apart twists the knife further by arguing that as designers we need to be superhuman obsessives, willing to work late into the night to produce the truely exceptional.

It maybe the case that to be a truely outstanding designer we need to live in a world of unrealistic personal expectations. However, personally I like the down to earth reality of "Six suggestions that can make you a better designer." In this post Eric writes…

Your project doesn’t have to do everything. It doesn’t have to win awards, make you look good, or have a wry subtext. Getting something simple to work is hard enough. Concentrate on the basics, and see if your idea holds up when shown to the audience.

In my opinion there is too much written about being outstanding and not enough on just being better.

Usability challenges associated with web applications

The final story of the week is a post by Jared Spool. Jared is a truely exceptional usability expert and I can highly recommend his Podcast. He is also an excellent speaker that I had the pleasure to hear again this year at SXSW.

The reason I mention him is because of a post entitled "3 important usability challenges for designing web applications." What I find so refreshing about this post is that it focuses on the web applications we all have on our sites rather than the trendy web 2.0. apps we hear so much about.

Sites like delicious, gmail, of even the up and coming getsignoff (shamless plug!) are somewhat unusal in terms of web apps because the whole site is the app. Most web applications are a part of a greater whole. They are contact databases on corporate intranets or ticket reservation systems on airline sites.

The challenges associated with these types of web apps are different from their trendier cousins and Jared addresses these problems in his post.

It is definately worth reading if you have web applications on your site.

Feature: Lessons learnt SXSW

Marcus shares his impressions of SXSW and the lessons we can all learn.

Interview: Garrett Dimon on form design

Paul: So joining me today is Garrett Dimon. Good to have you on the show. How are you?

Garrett: Pretty good.

Paul: Now I have to say I’m really excited about having you on the show because I have to say I’ve become a bit of a fan. I’m sorry to admit this and I know it’s horribly embarrassing when people say things like this to you. But ever since you’ve released your website which so impressed me I’ve been kinda following your work since then, some of the stuff you’ve been doing. You’re everything I’m not. You’re minimalistic, you’re clean and considered and well thought through while I’m chaotic, over the top and brash. That’s why I’m attracted to your work I think because you’re the
opposite of me.

Garrett: Everything I do from my apartment and everything is just the less I have, the simpler things are, the better things seem to turn out for me.

Paul: If only I could live that way. I’m just not… my brain just doesn’t function in that way. But that’s really cool. So I wanted to get you on the show to talk about forms of all things. It’s something that we’ve touched upon a couple of times in the show but mainly as passing comments in news stories and things like that. In actual fact a couple of the times we have mentioned it, it’s your name that’s come up. It seems to be something that you write a lot about from time to time. You see different articles popping up in different places. Why forms? What is it about forms that seems to attract your attention?

Garret You know it’s hard to give an answer. I really don’t know. But in thinking about it probably my first bet is that I really don’t consider myself to be a designer per say in terms of the more traditional, more artistic design orientated type of visual designer. But with forms it’s more about the interaction design and the more logical aspects of design which are things that definitely work better in my head. So how do you write error messages; how do you label fields; what order do they go in; how should they be grouped; do they go on one page or two pages. Some of the more logical, more interaction issues. Then using what little design knowledge I have to supplement that and make it visually easier to digest the form and see and understand the pieces of it. Basically to me it’s basically the one thing that I feel like I can comfortably design and layout because there’s a lot more to it than just the aesthetics.

Paul: Yeah that kinda makes sense. Why do you think forms are so important in a way? It’s obviously something you consider important but there doesn’t seem to be huge amounts written on the subject. What is it that makes them worth of that kind of attention as far as you’re concerned.

Garrett: I think part of the reason is precisely because they don’t get enough attention. Any real attention you see to forms, I haven’t seen it recently but it’s how do you skin your forms to completely control how they look. Which to me is one of my huge pet peeves. It seems like such a waste of time. To worry about what the forms look like in the browser as opposed to how they actually work, I’m thinking if you’re going to invest the time worrying about how your forms looks it’s probably better to spend that time worrying about how they are going to work. Are you using the right form field for that job and some of the more critical things about forms. Really forms, especially now with web apps being what they are, forms are such a huge part of your everyday interacts. Things like efficiency, learnability, accuracy, all the vasts of usability that matter. It’s not just a matter of “Is this form efficient?”. Well it’s easy to make an efficient form but it’s not necessiarly going to be something that somebody else could learn and use or you might be able to learn it but will you remember how to use it next time you come back. Balancing all the different kind of vasts of usability that Nielsen identifies and really working them out so that you don’t dumb the form down so that it’s so simple that anyone can use it that it’s just a cumbersome process to fill out. Really kind of massaging it with all those things in mind.

Paul: You’re right when you say that in the world of web applications certainly forms are amazingly important but they pretty much appear on every site. It’s hard to thing of a site where they don’t appear.

Garrett: Well you think about a magazine site or anything like that where it’s more content orientated, it’s definitely a lower priority.

Paul: Yeah but you’ve still got contact us forms and things like that.

Garrett: Yeah, comment forms and…

Paul: Ok. So you touch there on the fact that one of your pet peeves was the fact that people worry about the design of their forms rather than how usable they are. What over common mistakes are you seeing from people about how they design and implement forms?

Garrett: I think there’s a whole slew of them and I think a lot of it is just worrying about the wrong things or not giving thought to things that matter. My main reason with the designing the form fields is that people are used to seeing form fields and what they look like in their browser, in their native rendering. Sure as a designer having pixel perfect control would be nice but I would hope that most of us who are now designing on the web would have forgone that state of mind where we have to have complete control over everything, it has to look exactly the way we want. A lot of time not only is it a waste of time but it actually hinders usability when those form fields don’t look like what someone expects a form field to look like or button for that matter. When the design becomes design for design’s sake it actually hinders usability in addition to just wasting time. When I initially started developing things it was all about consistency because consistency is easier to implement. If every form field looks the same, behaved the same, is the same size etc. it’s easier to implement because you use the same CSS and you don’t have to put as much thought into it. So while consistency is valuable there’s definitely an aspect of context that a lot of people don’t necessarily pay attention to. In some situations, I think 37 Signals have done a good job on this, they’ll make some fields larger than others relative to the size. In particular in Backpack, their headings aren’t just a form field they are actually bolder and look a little more like a header. They are a little larger font than the body of the note. It adds a little bit of context so that it’s more intuitive as to what the purpose of that field is. There’s a lot of different ways to do it. That’s just one of the more tangible ones. Basically the mistake being focusing too blindly on making everything consistent when there are appropriate situations to break the rules and use context to make some changes. Another one is just dumping a whole form onto the page without breaking it up into logical sections or groups. A lot of times people are afraid of making a form any longer visually because of scrolling. While you don’t want somebody to scroll 80 screenfuls, scrolling one versus eight screens is neligable.

Paul: So you wouldn’t suggest splitting forms across multiple pages then?

Garrett: Well there’s definitely context for that if it’s appropriate. Amazon is a great example there because you’ve got your payment screen and your address screen. It actually can be a fairly complex process but the time you’ve selected several addresses or updated an address, updated a payment method, changed the items in your cart. As you’re jumping around the different screen’s you definitely wouldn’t want all that interaction to try and be contained on one screen. It depends on the size of the form and the context of the form and how interactive it can be, how many potential branches off of that path are there to take. Another would be poor labelling. A lot of the time people label things. This goes back to just naming conventions in general. Just basic information architecture stuff. Whether it follows a corporate naming convention that may not be the right word for somebody that’s not inside the company wall or just simply flat out the wrong word for international [???]. Really anything. Just not putting enough thought into the label. The first thing that pops into your head isn’t always the right thing. Using the wrong kind of inputs so a lot of times whilst… and I have no idea in the world why people would do this… People who for instance who use checkboxes when they won’t use radio buttons and instead they write Javascript to control the radio button. Checkboxes as if they were radio buttons. Thinks like that where I just have no idea what these people were thinking in some of these situations. Just a lot of things like using a radio button or having a yes/no radio button where a checkbox could work. Multiple select lists which are an absolutely terrible interface element to use because a lot of people don’t know you can control+click. If there are small lines and you accidentally slip off that control key and click on a new one, it’ll select that new one and erase all your other selections in that list. There’s different things that kinda get abused and misused in situations where they really aren’t necessiary. A much simpler solution usually exists.

Paul: Yeah. I’ve seen the radio button, checkbox problem and it’s always very amusing.

Garrett: And vice-versa. Where it’s radio buttons and they try and make them checkboxes just because they think it looks prettier sometimes.

Paul: How bizarre.

Garrett: Which I guess is another great example – over using Javascript in forms. It’s one of those things. I don’t know where I heard it but the best description I ever heard of Javascript, Ajax or any of that stuff is that it’s really a spice. If you’re cooking you wouldn’t just dump a whole bottle into your pot. Or you wouldn’t start with a bottle of curry and dump it into a pot and say “OK, now what are we going to make?” You would decide what you are going to make and then think “You know this could really use a bit of curry here”. A lot of people just don’t use Javascript as a spice. It really starts to define the experience and in a lot of situations actually makes it worse or more confusing.

Paul: I presume you would encourage some use of Javascript for example. Things like doing some client side validation as long as it falls back on a server side validation. That kind of thing.

Garrett: Yeah absolutely.

Paul: OK so let’s turn that question around. We’ve been talking very much about the mistakes that people make, but what advice would you provide people about approaching forms? What are the things that they should be doing rather than shouldn’t be doing? I know that in some ways this is going to overlap but is there a particular approach that you take?

Garrett: One of the biggest things I guess is when ever; doing consulting for custom applications or things like that a lot of times we don’t realize that a lot of the complexity from forms comes from the complexity of the business. Whether it’s somebody doing markup or somebody designing a form, a lot of times you know if a business analyst or whoever creates these form requirements and says “here you go design this form.” It has 100 fields and this is out contact form and 80 of the fields are required. A lot of times people just say “okay, it’s my job to implement this. In my experience a lot of business analysts aren’t really familiar with principles of the web and what makes sense. A lot of times the real effort to creating a good form is in educating everybody else about what would be involved. Pushing back in situations like that. Not in a bad way but in a very professional productive way. “You realize that this is going to be a really bad contact form. Nobody’s acutually going to use it. I’ve even heard response like “That’s the point. If people contact us we have to take time a respond to them.” The problem isn’t with the form there, its with underlying things. Obviously that’s a little bit of an exaggeration. The idea is that the best place to start with forms and any kind of interaction like that is with the principles that are underneath there kind of guiding it. With the issue tracker that I am developing, I started out parring back the process of what’s the lifecycle of an issue. Trimming out parts that I didn’t think would really be necessary. I was just looking at it in the context of the lifecycle. I hadn’t even thought about what are the forms going to look like? How am I going to communicate this lifecycle within the context of the application? When it came down to the point when I had to explain how that actually worked, because I had trimmed the proccess and the lifecycle down so much, and it was only 3 steps really, I was able to translate that concept directly into the interface. If I had never actually gone and trimmed the lifecycle down and it had 6 different states that were very cross dependant and this state only is an option when you are in this state… It gets so complicated that even if I could express it in an interface, the code to build it would have been so absolutely unweildly that I could have never created a natural and intuitive inteface. So, I guess really challenging the underlying things rather than just thinking about the things on the surface. And then really just look at every form on it’s own. In it’s own light. What is the goal of this form? Should it be laid out like a traditional form? With one set of “label” “field” all the way down the page and a submit button. Should there be other buttons? Another thing when, I have a fairly consistent model that I am using when I am designing forms in my new application. The main form is for submitting issues and that one form is probably going to get 80% of the useage in this whole system. That and commenting. In the context of submitting issue alot of times you will be in a meeting capturing things as people are talking, capturing issues cause it’s an issue tracker. You want to be able to capture and issue, save it, and move on and capture another one really in kind of rapid succession. So I added an extra button at the bottom that I wouldn’t put on any other page, cause it doesn’t make sense, to save and add another. So it immediately saves that one and takes you back to the data entry screen. You can just continue in a circle and just keep on adding and adding. So really looking at forms and thinking about how are people going to be interacting with this? What are they doing in the real world while they’re using this form? Are they copying data from another application into here? Are they in the middle of a meeting just capturing items in rapid succession. What are they doing? Are they just quickly jotting it down from their iPhone? Understanding that context helps illustrate ideas and different sublte variations that you can do to forms and make them very very practical without adding a whole bunch of extra overhead on the implementation.

Paul: I remember you wrote an article at one stage redesigning eBay registration form. When you wrote about that you talked about the fact that this is a registration form. It is a one off form, and all of the ways that that then informed the way that you built the form. How it affected the positioning of things, and the layout and things, simply because it wasn’t going to be a form that people were using again and again. That’s the same kind of context that you are talking about.

Garrett: Yeah exactly. There’s always a different context to a form and it matters. It is easy to overlook it but that context, and really any design for that matter, context is so important but it is something that…I think that main reason that people don’t pay as much attention to context is because it requires a lot of extra work. A lot of times it’s easier, and it makes sense for kind of a first pass, to make every form look the same. It takes a lot more work to go through and re-invent the wheel every time you look at a form even though, re-inventing the wheel is probably a little bit extreme, to really give it some custom attention. Some tender loving care, just takes a lot more effort that lot of projects don’t have time for.

Paul: You mentioned earlier 37signals that you liked some of the stuff that they were doing. Are there any other good examples out there of forms that you really think are getting it right and are worth us having a look at?

Garrett: Probably the one thing that always jumps to my mind any time anybody asks me about forms is all of the work that Luke W is doing. I hate trying to butcher his name. The stuff that he is doing and hopefully his upcoming book is just really incredible. In depth. He’s done a lot of eye tracking research about label placement and button placement and he’s talked extensively about primary and secondary action buttons. All of his stuff is really incredible.

Paul: So where can people find out about him?

Garrett: I always just google for Luke W to get to his site. Functioning form is his blog. He’s the first hit for Luke W.

Paul: I’ll add it to the show notes. People can get to it via that. That’s interesting. I must admit I hadn’t hear of him so I’ll definitely check that out.

Garrett: He’s one of the, I don’t know his exact title, but he works at Yahoo and he’s got a plethora of presentations about form design and all of the kind of stuff. Really sharp guy.

Paul: And he’s writing a book you say as well?

Garrett: Yes he is for Rosenfeld Media. It’s due out early 2008.

Paul: Excellent. So just to finish us off. A little bit of bile at the end of the interview. Is there any forms that you want to name and shame? Any site that do things really badly that we can all go and laugh at and sneer at?

Garrett: You know that’s a very tough thing to do.

Paul: (lauging) So many out there.

Garrett: Well there are so many out there. But at the same time too there are a lot that seem like they could use improvement but they’re companies that are investing a lot of money and research to improving their forms. So I’m hesitant as an outsider, somebody who isn’t exposed to some of that data, to try and call them out, when they’re probably acutually right on the money. The top two that come to mind that I know are successful are eBay and Amazon. I think Amazon succeeds on the interaction design of their buttons and the flow of their checkout is natural and intuitive but I feel like a lot of their page designs, and it could be a very intentional thing in order to, although I hate thinking that Amazon would acutually do that, to kind of trap people and confuse them almost. If you look at each page in and of itself I think there is a lot of design things that they could make adjustments to that would make the pages easier to understand and comprehend at a glance. I feel like right now their design of their checkout process, or most of their site in general, is very busy and intense. It’s difficult to focus on one element because there’s so many elements. There is very little very intuitive page hierarchy within each page. And they’ve made leaps and bounds, watching the site evolve over the years. But, it still feels like there’s a lot more room for some design consistency for them to introduce. They’re slowly getting there. eBay is another one who, I know they acutually, I forget their CEO’s name, but she declared 2008 the year of user experience at eBay. They’ve acutually invested a lot in trying to improve their forms and really their user experience period. eBay is one that I’ve only successfully purchased something on there once and everytime I try to swim through there I get lost and just give up. Too me any situation like that is just begging for help. I think any form, even the best of the best, even 37signals, everybody is still learning. This is all so new that even the best forms have so much room for improvement. Even my stuff, I come a month later and say “what was I thinking there?” There’s so much work that needs to be done. I think that Luke’s work that he’s doing is probably some of the best and most important work that we’ll see in forms in the near future. He’s starting to really put down facts about what really is good and bad and why it is good and bad. Up until now most of us have just been pontificating based on “well this form is hard to fill out because of errors.” Or you know, the form breaks, or the error message isn’t helpful. Very obvious things. He’s tracking the much more subconcious things that until now nobody’s really dug into and made claims about. It’s kind of a cop out on your question.

Paul: No No. You gave two example there and you gave constructive reasons why they should be improved or could be improved. No I don’t thinks it’s a cop out. You’re just so much nicer than I am. You didn’t go for the jugular that was the only thing. Garrett it’s been great to have you on the show. I think that you’ve given us some real good hints to get going I guess and make some imrovements. It was good to talk to you.

Garrett: Yeah likewise.

Paul: No doubt we’ll get to talk again soon before too long. Especially when you’re issue tracker comes out. We’ll have to get you on hear all about that.

Garrett: Yeah. I’m hoping it will be sooner rather than later but it’s definitely tough to balance the feelancing and paying the bills and making progress on it.

Paul: I know exactly how you feel, we’re doing the same thing at Headscape at the moment. It’s always difficult. Client work is so tempting because it pays the bills here and now.

Garrett: Yup, exactly.

Paul: Okay good to talk to you and we’ll talk again sooon.

Garrett: Sounds good.

Thanks to Lee Theobald for doing the transcription

Listeners feedback:

Finding usability test subjects

Our audio question comes from Clare who asks…

"Where do you find your test subjects for more formal user testing"

It can be hard to find good test subjects and I am not aware of any agencies out there that source people for you (although I am sure somebody will correct me).

I think it is worth stressing that finding users who match the demographic of your target audience is not a huge concern. As Steve Krug points out in his book "Don’t make me think" most problems are encountered by any user. That said, where possible it is good to find people that roughly match the specification.

To be honest our approach it is very adhoc. It normally consists of both Headscape and the client scrambling around to see who you can find. The client often has "tame" customers they can ask and we fallback on family, friends and other clients for recommendations.

I should also say my local church has been very handy! A church seems to have a good cross section of ages and backgrounds and an advert in the church newsletter often does the trick. Equally advertising in your local newspaper can attract people, but you have to be willing to pay for their time.

Accessible tables

This week’s email is from Daniel and takes the form of a recommendation rather than a question…

"Could you cover the tips discussed in this article [about accessible tables]? I have seen a lot of tables on the web. Almost none of them uses any of these tips."

The article Daniel is refering to can be found on the Opera developers site, which is a great resource covering all aspects of web development (not just stuff relating specifically to Opera). The specific post looks at how to markup data tables in an accessible format. Since designers have stopped using tables for layout they have become largely ignored. However, if not marked up correctly they can prove a real problem for speech readers. A simple table such as this…

Day	AM	PM
Monday	Meeting	Travelling
Tuesday	Free time	Meeting

…can become impossible to understand when read back because it is read in a linear fashion…

Day, AM, PM, Monday, Meeting, Travelling, Tuesday, Free time, Meeting

However, if marked up correctly it suddenly makes sense…

Day Monday AM Meeting
Day Monday PM Travelling
Day Tuesday AM Free time
Day Tuesday PM Meeting

Great find Daniel. These are tips we should all be implementing.

113. Hiring

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

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

Podcast: Download (29.9MB)

Download this show.

Launch our podcast player

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

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

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

News and events

Highly extensible CSS

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

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

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

Video tools

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

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

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

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

Microformat boost

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

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

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

Feature: Hiring new staff

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

Expert interview: Christian Heilmann on common Javascript mistakes

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

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

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

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

Paul: Um hum…

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

Paul: Yeah…

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

Paul: Um hum…

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

Paul: Yeah.

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

Paul: Umm…

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

Paul: Yeah.

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

Paul: Mmm…

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

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

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

Paul: Um hum…

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

Paul: Yeah.

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

Paul: Mmm hmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

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

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

Paul: (Laughs)

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

Paul: Mmm.

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

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

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

Paul: Mmm…

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

Paul: (Laughs)

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

Paul: Mmm.

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

Paul: Okay.

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

Paul: Oh okay.

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

Paul: Mmm.

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

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

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

Paul: Mmm…

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

Paul: Mmm.

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

Paul: Yeah.

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

Paul: (Laughs)

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

Paul: Um huh.

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

Paul: Yeah.

Christian: And that’s great because now I can go fifty levels deep in my CSS selector and the javascript finds what’s in there. While this is already an indicator that your HTML is not necessarily good structure

Paul: (Laughs)

Christian: …and it also means that if you change your HTML in the future you also have to change that path, or if you don’t change that path then your javascript will break.

Paul: Yeah.

Christian: And a lot of libraries break silently as well. So instead of just getting the error in your face that you’ve basically screwed up, you will not know what’s going on and will wonder what’s going on.

Paul: Mmm.

Christian: And when that happens that’s normally when people, like you, fire up emails to the library developers and tell them that their product is rubbish.

Paul: (Laughs) Yeah… I can’t disagree with that. That’s the kind of thing that I’d do probably. Um… what about, I’ll tell you the one thing that I’ve come across is that… I’m kind of competent enough to write functions to do a lot of the things that I need to do. Nothing really complicated, I couldn’t build anything too sophisticated, but you know enough to get me by. But then as I’m kind of looking at other people and what they’re doing um… a lot of them are using object orientated type techniques in the code that they are writing. There’s me hacking away with little functions and there seems to be some transition across object orientated approach when you kinda hit a certain level… you know why, what’s the benefits of that? Why do people take that kind of approach?

Christian: (Laughs) Um… It’s been very beneficial in other languages, and other environments, especially when the environment is rather sophisticated.

Paul: Mmm.

Christian: Then ah… you seen for example action script. Action script has been as much as a hacky javascript. Yeah, look what I can do if I do it this way language and now with the Flex frameworks, and Adobe opening up more and more to the java world, um… it’s getting more and more into structured ways. And the structured ways are hard to understand for somebody who is not from that background.

Paul: Mmm.

Christian: And I can safely say that, I’m not myself. So I um… I have a lot of problems with like properly, or massive structures, and frameworks. But when you see people do proper action script, for example, or do Rhino applications for the server in javascript, or some of the things that are happening with javascript 2… that there is a reason for that and the reason for that is the scalability is just so much bigger.

Paul: Right.

Christian: It’s uh… basically you can extend an object and I can reuse a class and I don’t have to worry about that. It’s like I start building these little small components, all of them in themselves tested and unit tested, and I know they work. And then I can build a bigger application from them.

Paul: Mmm.

Christian: Basically without really needing to know to test these things ever again.

Paul: Yeah.

Christian: That’s how things like PEAR and PHP and Perl libraries work as well. It’s people extending these kind of already existing bits, and bobs, rather than starting from scratch every time.

Paul: Mmm hum.

Christian: Most of the time for the little web development things that we do like the AJAX form or the Constentina navigation that’s not necessarily needed, but when you write a library for example, and it grows, like YUI is growing or like jQuery is growing as well… then you need to adhere to these standards ’cause otherwise everyone will just submit their own code in forms that are just terrible.

Paul: Yeah.

Christian: And there’s not much magic to it. I mean I get annoyed when I see javascript guys going on stage and saying like: ‘Well guys, this is a function and when it’s an object it’s a method and…’ and why should I know this? Well you should know this because you need to communicate with other developers as well sooner or later.

Paul: Umm hmm.

Christian: And these people speak that lingo and rather than you having to explain yourself for 15 minutes you could communicate in 3 minutes.

Paul: Mmm.

Christian: And that gives you more time for lunch break.

Paul: (Laughs) …or drinking…

Christian: So the worlds of hard core programming and javascript are actually getting closer and closer and seeing some of the things that browser vendors come out with and some of the other software that builds on web technologies that is being built at the moment, I don’t think that we can actually rely on our being the cool cookie web developer anymore.

Paul: Mmm.

Christian: It’s a bit like we have to have broaden our horizons the same way that backend people have to broaden their horizons when it comes to using javascript, but you can only make someone understand your problems when you understand how they tick.

Paul: Mmm.

Christian: Otherwise you start preaching to the choir.

Paul: Yeah. Okay here’s the last question to wrap up with. I’m going to open it up and let you rant uncontrollably. What are the worst mistakes that you’re seeing at the moment made with javascript, just generally.

Christian: Uh. The worst mistakes that I see are that people write little scripts for tasks over and over again.

Paul: Okay.

Christian: The same task and I see them actually tying the interface a lot to the javascript. So…

Paul: What do you mean by that?

Christian: Instead of making a javascript that actually creates the things it needs, there will be HTML that is just not necessary where the is not javascript available.

Paul: Okay yeah.

Christian: So instead of starting with the proper HTML and CSS structure, you basically have this whole gumph of HTML because there’s the javascript to clean it up anyways.

Paul: Yeah.

Christian: So um… basically the main tip is you will never ever be able to replace a proper HTML structure. It doesn’t matter where technology is going because technology will go away from that sooner or later, but at least a human could actually go there and see that there is a structure.

Paul: Mmm hum.

Christian: And that there’s a way to convert this to something better in a second step. If you’ve created a lot of spaghetti code with like HTML and javascript mixed in and lots of little scripts in there, then you will never be able to convert that to something better in the future and this is what we’ve been running in circles for years and years. We’ve never been improving things, we’ve just been fixing things and adding little bits, and bobs, to it.

Paul: (Laughs)

Christian: The other thing that I keeps seeing is well the fan boy thing, about javascript libraries and of the academic way of some people measuring javascript. You have all these like, I mean there’s people that spend like weeks finding different javascript includes and script libraries and measuring how fast they are on their computer…

Paul: (Laughs)

Christian: …generating twelve thousand objects and trying to put them on dominoes. Show me the application that needs that done, then your comparison actually makes sense.

Paul: Yeah.

Christian: It’s the same as CSS. You have like ’10 Most CSS Tricks That You Never Knew’ or ’10 Most Beautiful Naviagations’. It’s like list blog posts digging their way through the internet.

Paul: (Laughs)

Christian: And it’s the same way there right now, like I can appear immensely cleaver if I just put loads and loads of effort comparing things to each other. Instead of saying ‘this’ means use ‘that one for this one’ and ‘use that one for this one’ cause the benefits of that one library is ‘this’ and the benefits of the other library are ‘that’.

Paul: Yeah.

Christian: It normally is like, ‘Oh yeah… that library won.’ or ‘All of the others are bad’.

Paul: Yeah.

Christian: And that’s never the case.

Paul: Hmmm.

Christian: We have to get away from this putting things together randomly and making up an application, to a proper web application design and I’m going to be in New York at the end of the month, no actually beginning of next month at AJAX Worlds and my talk there will be about how to do javascript design and javascript architecture of big applications.

Paul: Mmm hmm.

Christian: That’s going to be quite interesting feedback from the audience I’m quite sure about this, but it’s a matter that we grow up, we actually have to grow up as web developers and take our stuff serious and actually make sure that we don’t build for ourselves – but we build for the guy that comes after us cause that will always happen as well.

Paul: Yeah… and that’s really good advice.

Christian: If you think like that, then you will never write bad code and sometimes people just have to suffer that themselves before they start doing it.

Paul: Mmm.

Christian: It’s always clever to think of yourself as the javascript god that can do things better anyways, but some times it’s good to leave your superhero skills in the corner and just do something that works and that’s understandable and spend some time documenting for the next guy that has to take it over from you.

Paul: And I think that applies to everybody you know people, even people doing HTML or CSS or server side stuff thinking about the next person is, yeah, hugely important.

Christian: Yeah.

Paul: Thank you so much Christian. That was very useful and I really appreciate you taking the time to come on the show on Valentine’s of all days. Good to talk to you Christian and we’ll speak soon.

Christian: See you soon. Bye.

Listeners email:

Rolling out new features

Our first listener comment is from Alex who has come up with a clever little approach for educating existing users about new features…

I just listened to show 112, where you mentioned Christian Heilmann’s javascript walkthroughs. These walkthroughs reminded me that I wanted to do something similar for our website, except I wasn’t able to squeeze it in before the deadline.

My workplace decided on a total revamp of their website, and the final design had some substantial visual and navigational changes. Among other changes, disparate logins had been consolidated into one login button. Of course, now we had the problem of habitual users; because the website hadn’t changed for several years, how do we now try to avoid several hundred support calls asking where the logins have gone?

Well, the obvious solution is to not make such drastic changes. Going for evolution, not revolution and whatnot. Failing that, is something like Christian’s walkthrough popups. However, these would still show up for new users, for whom this information would prove totally useless.

Here’s the solution I had planned:

A couple weeks before the new site or feature launch, we use javascript to set a cookie. This accomplishes two things: 1) we target people who have javascript, so we know the popups will work for them, and 2) we’ll know they were at this page *before* we changed the design or added a feature. Now, once we launch, we check for that cookie using PHP (or other server-side scripting). Why do this on the server side? Well, it lets us avoid even inserting the popup code for people who don’t have the cookie. If the cookie exists, we can then delete the cookie (so they don’t see the walkthrough again), and then insert the walkthrough divs and javascript.

Even though I didn’t get a chance to implement it, maybe this will help other people prepare for site overhauls.

What a great idea Alex. Existing users rarely like sudden changes to the sites they use regularly and often need a lot of help making the transition. This is an excellent way of doing that without confusing new users with unnecessary information.

Content management and CSS

Our second listener contribution is a question from Adrian…

Thank you very much for the show – it has been so helpful!

I have been given the job of creating an Intranet site for a small business. After listening to your shows I would love to create this website using webstandards and have been learning CSS. As well as this it is important that the users of the site can modify the content via a CMS.

So my questions are; can both of these things be satisfied? Also is it possible to design the website using webstandards and then “plug” a CMS into the already created website?

It is definitely possible for content providers to update content built using CSS. In fact it is easier, and allows the designer to maintain more control over the design. Traditionally content providers had to make all kinds of design decisions when adding content. If they needed to add a heading they had to decide what that heading looked like. If they wanted to make a piece of content stand out, they would pick a colour and font size to make that happen.

However, when a site has been built with standards the content provider doesn’t need to worry about what content will look like. They simply say this is a heading by defining it as an H1 and the CSS will decide how to style this. Equally to make something stand out they mark it as strong and the style sheet does the rest. Simple.

The only problem is that some content management systems do not have WYSIWYG editors capable of supporting this approach. They are still focused on giving the content provider design control. Fortunately there are editors out there that do think in this way. A good example is xstandard although there are others. These can just be dropped into your CMS.

Finally, it is certainly possible to plug standards based code into a CMS. Infact, it is actually easier because the style and content have been separated. A content management system is (as it name suggests) primarily concerned with content. It doesn’t care about how that content is styled. Nothing makes integration easier than nice clean meaningful markup, unencumbered by formatting.

HTML snippets

Posted in Development on February 18, 2008 by Paul Boag

If you are part of a web design team or skip constantly between projects, then you might want to consider an alternative approach to writing your HTML.

At Headscape efficiency is king. If you are efficient, you increase profit margins and keep prices competitive. You can only charge as much as the market allows. If you want to increase your profits you need to complete projects faster, while avoiding lowering quality.

As part of our efficiency drive we identified 4 problems…

Designers have to work with each others markup. We all code in different way and this creates a learning curve when a project gets passed between designers.
Integration HTML markup into server side applications was time consuming. Because designers coded in a different way and change their markup for each project, it was time consuming to apply that code to web applications like our in-house content management system.
Designers were constantly reinventing the wheel. Each project was built from the ground up with little reuse of markup across projects.
It was confusing switching between multiple projects. In order to ensure the most efficient use of time, designers are expected to work on several projects simultaneously. Unfortunately, switching between project is confusing because each had different markup.

We required some way to standardise tour markup.

Templating doesn’t work

At first, we produced templates for the different types of pages. For example, we had news listing, text and FAQ templates. Although this worked, they were not very flexible. As soon as the content or functionality began to deviate from the norm the templates had to be heavily customised. This undermined the benefits they provided. They also didn’t allow flexibility of design. Although content and design should be separate, it rarely works that way. Sometimes content needs to be marked up up in a particular order. Other times extra divs are required. The templates didn’t accommodate either scenario.

We needed a more flexible approach.

Using snippets

The solution was HTML snippets. Content such as news listings, forms, navigation and FAQs appear in a vast majority of websites we build. By coding these in a consistent way each time they appear, we solve all of the efficiency problems mentioned above.

Take for example news listings. Most news listings look the same. They have…

Title
date
link
description
and sometimes an image

Because of this consistency you can code in the same way each time. Content will change, each will have its own unique id and sometimes an element might be dropped (e.g. the date or image). However, fundamentally the snippet is consistent

This consistency allows…

A designer picking up the code to instantly understand what is happening.
A developer to quickly integrate it with server side code because the integration is consistent every time.
Pages to be built faster because you are dropping in pre-generated markup

In affect all the designer has to do is build an HTML framework. This consists of the overall containers (main content, secondary content etc.) He then drop snippets into that framework in whatever order he requires.

However, the benefits don’t stop there. You can also associate CSS with each snippet of HTML.

CSS fragments

If your HTML snippets are consistent, you can also build up a library of CSS fragments to support them. Take for example our news listing. Not only does it often contain the same content it is also often laid out in the same way. The image sits to the left while title, date and description sits next to it on the right. Because we know what the markup looks like, we can create this layout as a CSS fragment that can be dropped in whenever this HTML snippet is used.

We are not limited to a single CSS fragment per HTML snippet. Over time you can build up a variety of different CSS layouts for each snippet that can be used as the design dictates.

This approach provides a huge productivity benefit as the HTML and CSS can be built up in a ‘pick and mix’ fashion. However, you can also take the principle one step further and apply it to Javascript.

JavaScript functions

Each HTML snippet can have associated Javascript functions. These can be dropped in just like CSS fragments. These functions carry out common behaviour associated with that HTML snippet.

Take, for example, a FAQ snippet. A common behaviour with this snippet is to only display the answer when a question is clicked. Because we have consistent code in the snippet, it is easy to build a function that works with it and can be dropped in as required. Where possible keep your functions generic and not tied to a particular HTML snippet. However, where that cannot be done, we have standard HTML that allows us to reuse functions across projects with no editing.

Conclusions

In many ways this approach is a cross between microformats and frameworks and so in itself is not groundbreaking. However, from an efficiency standpoint, the impact is overwhelming. Without a doubt it will speed up development times and allow you to turn around projects quicker.

Yahoo Live!

Posted in News on February 11, 2008 by Paul Boag

Yahoo have launched a new live webcam broadcasting service that has some real potential.

Yahoo! Live enables you to quickly and easy start broadcasting live video streams. As you can see from the example below it is also incredibly easy to embed in your site. What is more they provide an API that allows for the creation of more sophisticated web applications. It will be interesting to see what people do with it.

The profit and loss of usability

Posted in User experience on January 31, 2008 by Paul Boag

We have looked a number of times before at user testing but have never really asked why it is important.

The subject of usability seems to generate a dichotomy between what we think and what do as website managers. On the one hand we know that a focus on usability is good. We need only look at companies such as Apple and its iPod to know that usability can have business benefits.

However, when it comes to putting our principles into practice we often shy away. The realities of a production environment make a focus on usability seem impossible. We either feel that timescales are too tight or budgets will not stretch to the extra expense. For one reason or another user testing gets pushed to the bottom of the agenda. It is as if the perceived losses of testing outweigh the potential profit.

But, are these assumptions true? Is user testing time-consuming and expensive?

The perceived losses of user testing

Even if we are fully committed to user centric design we often need to convince others of its benefits. The perception that user testing is time-consuming and expensive, is wide spread and to some extent with good reason.

Traditionally user testing has been a huge undertaking with many organizations still spend millions. For years it took place in expensive usability labs with two way mirrors, computer suites, and video surveillance. Large numbers of test subjects were required to provide statistically relevant data. Also, the selection of these subjects was time-consuming because each would have to conform to a specific demographic profile. Testing was expensive and took considerable time to setup.

This approach was certainly effective but prevented most companies from running sessions. Although a usability consultant, testing in a lab, with demographically selected subjects is nice, it is beyond the budgets and time frames of most organizations.

However, user testing does not need to be like that. In-fact, it can be lightweight and inexpensive. Best of all it is something you can do yourself. It may not be quite as effective, but it is certainly a lot better than no testing at all.

However, even the most lightweight approach to user testing will require some additional time and budget. Do then the benefits outweigh this cost?

The real profit of user testing

The benefits provided by user testing cannot be understated. Even the most lightweight of approaches can have a profound affect on your web presence.

The benefits of user testing include:

Fast issue detection
Increased user satisfaction
Reduced support costs
Increased efficiency

Let us address each of these in turn.

Fast issue detection

If user testing is properly implemented throughout the life cycle of your web project then the chances are you will identify potential problems faster. Regular testing will certainly find usability issues but could also pick up on technical bugs too.

If you can identify these kinds of problems early, they are much easier to fix. The further into the project the more expensive and time-consuming changes will become as more code has to be rewritten.

Increased user satisfaction

It will come as no surprise that an easy to use site increases user satisfaction. However, it is worth pausing for a moment to consider just how important that is.

Users who become frustrated with your site do not simply leave; they never return. That user is probably lost for good no matter how much you improve in site in future. What is more they are unlikely to recommend it and could even actively criticize it.

In the competitive world of the web, repeat visitors and customer recommendations are crucial to success.

Reduced support costs

Perhaps you are in the fortunate position of facing little competition, or your users have no choice but to use your site. Even if that is the case you still cannot afford to ignore usability.

If site visitors finds your site hard to use and yet cannot just walk away they are left with one option; to ask for help. Sites with poor usability will attract large numbers of support calls and complaints.

Usually, it is far more economical to user test than to continually answer the same questions in support calls.

Increased efficiency

Finally, an easy to use site can provide real monetary benefits through efficiency.

This is most easily seen if your own staff use your site. An easy to use web application allows users to complete tasks quicker and as we all know “time is money.”

To a lesser extent, this principle also applies to others using your site. If they can complete tasks quicker then they are more likely to turn to you as an efficient source. They will see a timesaving that will encourage them back.

There is no doubt that user testing can provide a real return on investment. However, these can only be realized if the cost of running test sessions can be kept to a minimum.

108. Future of

Posted in Classic shows on January 23, 2008 by Paul Boag

On show 108: The differences between work for an agency or being an in-house designer. Hosting bandwidth intensive content and what happens when Paul designs a web design conference.

Podcast: Download (22.7MB)

Download this show.

Launch our podcast player

News and events | Daniel Burka and Leslie Chicoine | Listener emails

Unfortunately Marcus is not on this week’s show. His Father died a few days ago and obviously he has lots of stuff to deal with. Hopefully he will be back next week. However, if you are desperate for your Marcus fix then check him out on Nevermind the Buzzcocks.

News and events

Future of Web Design

Imagine for a moment if you will that an email lands in your inbox asking you to create your perfect web design conference. Who would you invite to speak? Daniel Burka from Digg, Andy Clarke maybe? What about Jon Hicks or Jina Bolton?

Well that is exactly what happened to me when the guys over at Carsonified asked me to chair this years Future of Web Design conference. They asked me who I thought my dream line up would be and together we worked on assembling them. Sure, there were some restrictions, apparently raising the dead caused a problem and hosting the conference on the moon was out of the question. However, overall we did pretty damn well.

So on the 17th and 18th of April in London I get to attend (and contribute to) my dream conference. The line up includes all the people I have already mentioned and more. The only thing missing is you guys. It would be really cool to have a bit of a boagworld meet-up while we are there so get on over and sign up today. It will cost you £145 including VAT or £480 if you want to attend my workshop as well.

However I know some of you are poor students or have tight ass bosses so we are also giving away two free tickets. If you want to win the two tickets email me with FOWD in the subject line with your name and contact details. We will pick a winner in a couple of weeks.

Advancing advanced search

My second story of the day is an excellent post on the Boxes and Arrows website. It tackles the subject of advanced search. Search generally is possibly one of the most neglected aspects of website navigation. This is amazing as it is the primary means of navigation for 50% of those who use websites.

I have seen some stuff written about search results but next to nothing on advanced search. What is more advanced search is not only ignored by writers but also by users. Few choose to use the functionality it provides, only turning to it as a last resort if all else fails.

In this article Stephen Turbek suggests that we need to re-design advanced search from the ground up. Instead of advanced search being a tiny link often overlooked, it should be an integral part of the search results page where complex filtering can be carried out through a graphical interface. Its hard to explain exactly what he is talking about without seeing the examples he gives so definitely check out the post.

If you ever have to work with search then this is a must read.

Starting from a blank canvas

Next up is a blog post from Cameron Moll on how to start a new design. We have spoken before on this show about how hard it is to come up with a design from scratch. Nothing can sap your creativity more than a blank sheet of paper (or empty Photoshop file!).

Cameron gives some good solid advice including sketching rather than diving into Photoshop and also drawing from previous work. However, he also suggests some less well known approaches such as starting with a grid and (most interestingly) working on the core content first. On the latter point he is referring to the fact that we often tackle things like headers and navigation first only coming back to the content at the end. Moll suggests this should be the other way around. This is good advice as it focuses the designer on what the site is really about rather than the interface used to navigate it.

You suck at Photoshop

My last find of the week is a really superb set of tutorials I found on youtube. I am not entirely sure how useful they are but they are definitely entertaining.

Most screencasts maybe informative but are often deadly boring. Not so with “You suck at Photoshop”. These basic Photoshop tutorials have a twist as the person recording the screencasts vents his rage at a cheating wife. Check out the video below and you will see what I mean.

Expert interview: Daniel Burka and Leslie Chicoine

Paul: OK so joining me today is Daniel Burka from digg.com, hello Daniel.

Daniel: Hello Paul.

Paul: Nice to have you on the show again, it’s been a while.

Daniel: Well thanks for having me again.

Paul: We’ve also got Leslie Chicoine joining us as well from satisfaction what’s the url again, remind me.

Leslie: Sure it’s getsatisfaction.com.

Paul: getsatisfaction, that’s the bit I was missing, I should have been prepared and had that on my screen, but there you go I’m badly organised. And of course how can we do an interview without having Marcus here as well, hello Marcus.

Marcus: Hi Paul.

Paul: laughs

Marcus: getsatisfaction.com, you must be able to sell that for millions to a porn agency.

Paul: laughs

Marcus: laughs Sorry, I’m off on one already.

Leslie: I’ve heard those jokes so many times.

Marcus: Yeah, ok, I’m so predictable.

Leslie: laughs

Marcus: I always have to ask people from America were are you and what’s the weather like? I know it’s a really boring English thing to say but it really is horrible over here at the moment.

Leslie: Well we’re in sunny San Francisco, I think the weather about 55 Fahrenheit right now.

Paul: Yeah, that’s so unfair isn’t it? Why do we live here, I just don’t know why we continue to live in Britain in winter.

Daniel: I was just in Canada last week and it was like 20 below freezing so it’s really nice to be back.

Paul: I bet laughs

Marcus: Not that cold here that’s for sure, it’s just wet, it rains all the time in the winter.

Paul: So Daniel, I’m dragging it back to the subject now Marcus if you hadn’t actually noticed while you go off on weird tangents that’s fine. Daniel we’ve had you on the show before and so hopefully our listens will be familiar with your background and if they haven’t heard of digg.com they should be ashamed of themselves. Leslie your new to the boagworld podcast so maybe should kick off with you, and if you could just tell us a little bit about getsatisfaction and a little bit about yourself and your own background if you would.

Leslie: Sure, well let’s start with getsatisfaction, basically I’m trying to re-do what customer service is there’s a lot of depressions happening on line about companies and how companies aren’t getting involved so we’re trying to get companies and customers together in the same space. Talking about products and issues and ideas for the future and yet we’re also trying to make sure it’s a level playing field so that neither side has control of the conversation so we’re acting as an intermediary allowing true conversations that are open to the public and that everyone can see and anybody can get involved in, but we’ve actually got people talking about customer service for companies, the companies aren’t there yet but getsatifcation.com/apple is a very popular section and there’s nobody from apple on the site yet. But there are also sections like the one for google and the one for twitter and we have google employees and twitter employees involved. It’s a very different take on customer service because it’s not just customer service rep it’s people who are programming, people who are designing, people who are in the HR department, all getting involved and having much more direct contact with customers

Paul: So do the companies all have to pay in order to participate in this or is this a free service? How does this work, what’s your business model?

Leslie: Well, all the features we have right now are free; our business model is still being developed, not to say that we don’t have one, we just have a lot of different directions and we want to make sure that whatever direction we take fits them in our philosophies, but we’re hoping that in the future for us, we see the potential in the analytics and the data that we collect. Your on the site are your telling us a lot about the different products and the services that your using and can tell companies to make connections between what products you use and like, and what other products and service you might also be interested in.

Paul: Yeah, of course.

Leslie: We start collecting more information about who you are and why your there in the first place.

Paul: Well I guess the other great thing, if you thinking of building a web app of any description then this is a great mechanism that already exists to handle the customer services enquiries you get without having to build all the functionality that is needed to do that as well so I imagine your attracting a lot of smaller companies as well?

Leslie: Yeah, it’s actually been a really interesting display, we’ve got small web apps, we have larger web apps such as google, digg.

Daniel: Even pounce is on there, I mean when we set up pounce originally and we wanted a way to communicate with our users and we immediately just set up a satisfaction page, signed up and it’s been great for use.

Paul: Yeah.

Leslie: Yeah, that’s all pretty easy, another thing actually too I forgot to mention, what’s truly great about the service is often times there customer service issues that span multiple companies so a great example was a guy who was having trouble getting a refund on an airplane ticket and he wasn’t sure if it was American Airlines or expedia.com so through the site he was able to post the issue to both sides and have them both look at it and communicate together there.

Paul: Personally Leslie what is it you do at satisfaction?

Leslie: Sure, I’m a designer, kind of an open title primarily I do a lot of UI design, I do a fair amount of contact development, I actually design a little bit of the business strategy as well we have developers who actually do the coding but most of what I do is wire framing.

Paul: Oh.

Leslie: My background though is actually game design.

Paul: Really?

Leslie: Really. laughs

Paul: So, that seems an interesting leap to go from game design into kind of a web app like this. Is it a big difference?

Leslie: It’s not really, because so much of what I learned in games design was how you design mechanics that let you create particular types of dynamics so you want people to act a certain way or, well in our case we want people to have a really positive attitude and there’s actually things in the design that makes people happier and make the conversation more open and positive, everything from the wording that we use to how we break down the steps, try and keep it all simple, if you go to the site you’ll notice it’s all very white and clean and light and that again add to that kind of feel and it helps people be more communicative.

Paul: Hmm… Interesting stuff, so the reason we thought we would setup this call today is really so we could talk a bit, well it was a conversation I had pervious with you wasn’t it Daniel about the fact that you come from an agency background and you used to work for a company, what’s the name of the company again?

Daniel: Silver Orange

Paul: Yes, that was it and they were what you would call a normal web design agency and while you were doing that digg was one of your clients is that correct?

Daniel: Yeah, so I helped found Silver Orange there were six of us what started the company back in 99 I think, but yeah we were a pretty typical boutique web job.

Paul: And what interested me about the conversation we were having previously, was the way you kind of when from working at Silver Orange across then to working for digg so you’ve kind of gone from working at an external agency were you had lots of clients and that kind of stuff, to working as an in house designer on a single project and I thought that was quite an interesting discuss and quite an interesting area to cover and you mentioned Leslie to me, and that you’d been having a similar conversation in a coffee shop somewhere with her and we though lets setup a few minutes and have a chat about some of the kind of ramifications of that and I guess the good place to start is, perhaps Daniel that you kick us off, what you see the difference being between working as an in-house designer somewhere and working for an external agency, is there a big difference?

Daniel: Absolutely, I mean it was actually quite interesting, I was back in Canada last week for some awards, kind of a yearly state of the union meeting and I’m still involved with the company a bit, I went back there for that, again this exact same discussion with one of our designers, and he was really jealous that I’m currently re-designing the digg comment system and he thinks it’s really interested that I’ve designed it twice now and I’m coming back again and doing it a third time and that kind of iterative development is something you frequently don’t get to do in the agency environment. That’s one of the real pro’s of working, I think as an in house designer is that you don’t build something and just hand it off you get the chance to build it, received feed back, watch how people use it gage some metrics over time and come back an re-design it and continue to improve something.

Paul: I mean, would you agree with that Leslie? Is that one of the things that attracts you working at satisfaction?

Leslie: Definitely, there’s something about being able to see a project through and then check back on it again and again, but I think that’s one of the things that makes it difficult, you no longer have and perspective, so we’re were talking about, particularly at the coffee shop, when you working at the agency, you come in and what makes you special is your new perspective and when your working at a company, you no longer have that so you need to make sure you can somehow come back fresh to the same project and when you iterating, bringing in new eyes, trying to see what needs to be changed becomes a challenge.

Paul: At one point in the sentence there you said again, and again…

Marcus: laughs

Paul: And I heard Marcus snigger at that, he obviously picked up on that as well. I mean that’s the thing, as somebody who works for an agency I have to confess, I think I would go absolutely crazy working on one website over a long period of time, probably because I’ve got the attention span of a newt, ya know do you ever long for that variety of work to work on?

Daniel: Yeah, absolutely, it’s usually really fun when you’re working for an agency especially clients who give you a lot of leeway and a lot of respect, that you walk through the door and you immediately see 80% of the problems on there site and you say, listen this is what you need to do, this is what you should fix and you get immediate reaction, it’s really fun right?

Paul: agrees

Daniel: You can bring so much change so quickly and somewhere like digg for instance, I mean I only have one or two sections of the site now that I’m looking at were I’m like, ok there’s still huge room for improvement here I know want to kind of tear it down and think of it from scratch and in all the other places there’s kind of refinement, refinement, refinement and it’s way more challenging and that’s what makes it fun but it’s also a bit more tedious, it’s not something fresh.

Marcus: I was gonna ask what the different skills you need, but I think you’ve kind of answered that, maybe being more dog-eared and determined, are there any major different skills between working on multiple projects and working on the same site all the time?

Leslie: Definitely, I think especially when your working at a company verses an agency the projects your working you have to have a better understanding of there application though out the rest of the business so when we’re iterating and we’re working on small details, the changes we make are for business needs or metric things that we’ve gotten so that kind of judgement is not something that I personally had as much experience with when I was working at an agency, and actually the team that works on getsatisfaction was initially a consultancy but it was weird have the whole team have to switch over.

Paul: Oh right.

Leslie: So initially when we were a consultancy the actually people who weren’t really involved with what projects we chose or really even finding out that much about the company, the founders were the one who really had to do that research and now we all have to do that kind of research.

Daniel: I was interesting because I was in a different position at Silver Orange as one of the founders, ya know I did have quite a say on which projects we take especially the UI projects were I was working more solo with a client, ya know, if I didn’t want to take a project we wouldn’t take it, working with clients I kind of got to know there business a lot before I started to get into it, you learn as much as you can, kind of a week or two to get into a project but at somewere like digg or like pownce, it’s a lot more about thinking strategically and thinking much more in the long term because if you pin yourself into a corner it’s literally yourself and you’re the one who’s gonna have to be able to dig yourself out of it later on.

Paul: Do you guys every, digg and getsatisfaction, ever bring in external specialists from time to time?

Leslie: Definitely, we were talking about needing fresh perspective and bringing new people in is always a great way to do that. We occasionally, what we do is we have design sessions and we have guests whom we get their opinions and show them what we’re doing and see if they have new ideas.

Paul: I mean it’s quite interesting that isn’t it because I mean we do a lot of work for a whole variety of different clients and you go to these different companies and they have internal design and development teams and you think why are we actually being brought in here were they’ve got the skills in house but they’re not really utilising what they’ve got and there’s a perception that if you bring in someone from the outside they’ve somehow got more skill than perhaps an in house team, do you feel more or less valued as an in-house employee than you did perhaps externally?

Leslie: laughs You don’t get that same sort of shiny, new feeling as an in-house designer I definitely feel more valued at this point than I did in the consultancy because one of the burdens of getting things right is on my shoulders now. So you really just can’t throw my ideas out the window. But it is actually interesting when people coming into a company, you can see in people’s eyes; they get a little nervous right? That the person coming in is gonna be more valuable than them right?

Paul: Yeah.

Daniel: I’m so excited, I’ve just hired another designer at digg, so there’s three of us now, and he’s awesome and I’m so excited to get someone in here who, a, can code better than me and b, he’s bring an entirely new perspective to the site, so ya know, it’s really nice to have fresh eyes so this is the best of both worlds because a, he’s now an in house designer and b, he’s just joined so he’s like completely fresh too it and I’m gonna capitalise on that as much as I can in the next couple of months before ya know he gets too deep in it a get’s into the aquarium.

Paul: I suppose you haven’t really been doing it that long, being an in-house designer but do you think there’s a point were you have to move no, when you think perhaps you’ve been there too long and been institutionalised into a certain way of thinking?

Daniel: I don’t think so, I mean I know this older guy who used to be the creative designer at apple, and the creative director a Polaroid ya know a bunch of really big companies and he’d been in the same job for a decade I think, but he was able to think incredibly creatively and leverage the people under him too bring the best into projects. I think as long as your able to adapt, I mean you can’t just keep coming through the door and doing the same kind of work all the time, I think your able to adapt to that in-house philosophy, I think you can definitely keep at it.

Leslie: Yeah I don’t have that much experience with that, but I think that’s the way too do it. Even with just the year that I’ve had at satisfaction you find yourself having to play a lot of games or do things to freshen the project or freshen the work.

Daniel: Right. I find too, like at somewhere like digg there’s so many different projects within the whole. It’s not like I’m working on the homepage every single day this year, that’s one very minor part of the site, you break down projects into components, like re-designing the comments is very different to re-designing the user profiles, I see them as very independent projects obviously tied stylistically and ya know from a user interface strand point they’re tied together, but they’re very different challenges which mixes up your job a lot.

Paul: What’s quite interesting with both your experience is that you’ve worked for agencies that worked on these applications your currently full time involved with and you saw that point with digg and satisfaction were you thought, ok, it’s not the right business move to have an external agency now, we need to bring that in house and I’m just kind of quite interested as to what happened in that process and whether you’ve got much of an idea of what that tipping point is, were you go from thinking yeah we can use an external agency for this to a point were we really need to do this in-house?

Leslie: I’ll let Daniel answer that one.

Paul: laughs

Daniel: So for digg it really happened that, originally it was a project Kevin had and was just throwing it around and wanted to see if it would get traction, and when it started to get traction he hired Silver Orange to come in and re-design the interface so it was a lot more usable and the site was gaining momentum gaining momentum and it kind of got to a point were they started thinking ok, this is a serious business, it’s got viability and they decided to start a company around it, in a much more serious and methodical way and that was kind of the point were they decided, ok, one of those positions is gonna be a designer, I’d been coming down, probably once a month down to San Francisco from Toronto and I one point Kevin was like, you should really move here, so he convinced me to move down and even for the first bit it was kind of interesting, I hope a lot of companies can do this kind of thing, it was quite flexible, I was working one week a month on Silver Orange project, so it was good for digg because they didn’t have to pay me as much and at the time there wasn’t enough work for a full time person and that way for me it was a nice period of time because I had the best of both worlds, I’d work on a bunch of client projects one week a month and then long term in house designer three weeks out of the month.

Leslie: It was a totally different situation for getsatisfaction because we had the whole company as a team look for a project to start, so for us it was really letting go of our client work.

Paul: Okay.

Marcus: I bet that’s hard.

Leslie: At satisfaction we let go of most of our development work first and let go of our design work and then turned this completely into satisfaction. But I did have that period like Daniel were I was saying were your working on lots of projects and along side your long term project.

Marcus: I can’t imagine slowly giving up project work; I guess it’s the sales man in me. I find it hard to turn any business away.

Leslie: Yeah, it’s actually very difficult to let people go when they want you and they still need you to do work for them.

Daniel: Silver Orange have actually got an idea for a project and they’re thinking of totally scaling back, and I don’t think, well we’re definitely not gonna drop all client projects but we’re talking about cutting down and a few people on the team, ya know kind of pumping other projects and drawing in other people as they’re required, and I think that’s also an interesting strategy as long as you can be disciplined enough to commit enough time to it.

Leslie: Yeah, I think our team decided up front that there was a stopping point that we would not be disciplined enough and that we would have problem with time being spent on things that were interesting or new instead of the core project.

Paul: I mean we’re looking, ya know we obviously knock around different ideas and web applications, we perceive, are a way of expanding the business rather than necessarily replacing one with the other so well I guess there are lots of different ways of slicing the cake I guess.

Daniel: Yeah, that’s the same philosophy Silver Orange is likely to follow.

Paul: It’s interesting.

Daniel: I mean it’s frustrating when you’re building other peoples projects all the time, you know you’ve got the skills in house to build something awesome, but smart people come up with ideas why should we be building for them when we can do it ourselves. laughs

Paul: Yeah, completely.

Marcus: This is so familiar, we’ve been having, well since day one I guess the simplest example is your own website in an agency, that always gets put to the bottom of the pile and we’ve been thinking about developing different applications for quite a while now but just trying to get people off paid projects and onto that, is, well it’s impossible.

Paul: laughs

Marcus: Well were we’ve got to now is, proper contracts have been written up between two different departs within Headscape if you like so that it is an official project, these set applications we’re working on at the moment.

Paul: When you say it out loud like that Marcus is sounds so pathetic.

Leslie: laughs

Marcus: But it’s true.

Paul: laughs But that’s how we’re getting around the problem. But I’ve got to admire this all or nothing approach or right we’re gonna go for it, but anyway.

Daniel: I think there’s actually something really curious about the bay area, I think it’s really different in attitudes here like ya know, figure out what’s the worst that can happen, ya know and if the worst that can happen means things don’t go so well in 6 months and you can barely pay your rent, if that’s the worst that happens then what ever just go it. And I think that’s why so many projects here get off the ground. I think that’s great. There’s a real sense of optimism here.

Leslie: And a lot of support too, if you’ve got an idea. There’s very few people here who are secretive with there ideas. They’re always talking about all their ideas and sharing and talking about building something rather than trying to hide it.

Daniel: But it’s competitive too. The people here, ya know there’s such a big audience for a lot of these products it’s like why should we quibble over the similarities of our projects lets just find a way that we can do stuff together and throw around ideas and it’s really fun.

Paul: Yeah it’s good. So for a lot of the people that are listening to this show, some of them are students that are coming out of university and are looking for their first movement into the web design world. We’ve got other people that are, what I would call enthusiastic amateurs who are looking to move full time into web design, you’ve got lots of different ways you could go these days if you’ve got web design skills I guess choice number one if you go say go for it I’m gonna build my own web application, choice number two is you could go a join a web agency and work on a variety of third party work and choice number three I guess is to become an in-house designer for a company, whether that be a trendy web 2.0 company or whether it be an in-house designer for I dunno on-line banking or whatever, how do you go about making that decision and what advice would you give people about were to begin? Are you going to damage your career if you start off by working in one place? Should you be doing lots of different types of work, ya know, what’s your advice?

Leslie: I think we both sort of agree that the real thing your looking for is good people, so whichever of those situation gets your around other great designers, other great teams with projects that your excited about, it probably doesn’t matter as much as you might think that it would.

Daniel: Right.

Marcus: It’s a bad question Paul.

Daniel: If I was getting into the industry right now, I wouldn’t want to get into a huge agency were I don’t know what sub-section of that agency I’m going to be in, what team I’m gonna work on, I mean joining a group of less than 15 you can get a good idea of who your actually gonna be working with and that kind of apprenticeship with really brilliant people is easily the best way to advance.

Paul: Yeah, I like that, I like that a lot. I must admit I hadn’t thought of it from that perspective and yes Marcus it was a rubbish question.

Marcus: laughs

Leslie: Well that’s the one that everyone’s asking.

Paul: Well yeah, we get asked that question all the time. My mistake is I should have asked what advice do you have for people starting out in there career, I shouldn’t have constrained you by giving you these different options.

Leslie: I don’t think this is just starting out. This is something your constantly asking yourself, am I in the right spot and I doing the right thing to advance my career, but as for actually starting, once again come back to this all the time, if there are good people around me then I’m in the right spot.

Paul: Yeah.

Leslie: If I’m inspired by the people around me I’m in the right spot.

Paul: I’m gonna have to move Marcus I’m sorry. I work with you…

Daniel: laughs

Leslie: laughs

Paul: laughs He’s used to it, he likes my abuse. laughs

Marcus: I’m also not a designer so.

Paul: No, your not, that’s very true. Although I don’t think I consider myself a designer anymore either.

Marcus: You took the words right out of my mouth Paul. laughs

Paul: I just thought I’d beat you to the punch.

Marcus: You did.

Paul: Okay, thank you guys for coming on the show, that was really, really interesting, you came up with some really good stuff and yeah I’m sure we’ll get some really good stuff back after listening to you. Thank you for coming and we’ll get you on the show again soon.

Marcus: Thank you.

Leslie: Thank you.

Daniel: Thanks a lot Paul.

Listeners email:

The cost of bandwidth

Eric: How do you deal with high bandwidth sites without bankrupting your clients? Is the quality of downloads compromised with these “unlimited bandwidth” sites?

Well Eric I have to confess that I have largely avoided the escalating costs of hosting this podcast thanks to the kind sponsorship of switchpod. However, for those of you who haven’t managed to gain sponsorship or who are looking for solutions for clients then there are numerous options available.

As Eric said in his audio question there is Libsyn which is a well known multimedia hosting provider that has amazingly competitive rates. I am not quite sure why Eric has an issue with them as I have heard very good things about them.

Another option is to host your video or audio with the Internet Archive. This service is free although I hear reports that performance can be an issue.

Of course if you are dealing with video then there are a whole host of possibilities from youtube to viddler. Some services are better than offers so be careful. For example some resize your video or limit the file size and length.

If you are hosting for clients be sure to check the terms and conditions of these sites as some of them preclude their use for this purpose. Also check ownership as you can be signing over the rights to reuse your video to the site owner.

Lastly in response to Eric’s concerns about the download quality of unlimited bandwidth sites, I have to say I have yet to experience any. I can see how this could be a problem when you get to really big numbers but that is not something that has effected me. Sounds to me that Eric might have been talking to companies trying to justify their own inflated prices and limited offers.

Working with audio

Harry: Given that you like to receive questions in audio format, can you, or any other boagers recommend any software that does the job?

We certainly do like receiving audio questions Harry (I notice that yours was an email!) Also now we are doing a listeners email section it is even more important. That is why we have made it even easier. I have signed up for a skypein account which means you can send me a message either by skyping boagworldshow or by calling 020 8133 5122.

However, lets just presume for a moment that you want to record and edit audio for another reason beyond commenting on boagworld. As a web designer or website owner you probably don’t have to do much audio work. As a result you won’t want to shell out a lot of money. I would therefore recommend you check out Audacity. Its a free audio editor for both the mac and PC which is as good as many of the professional packages. It provides all of the basics you need and exports to a number of different formats. Definitely worth trying out.

So now you have no excuse not to send an audio question, comment, or suggestion into the show.

104. Give us your money

Posted in Classic shows on December 12, 2007 by Paul Boag

On this week’s show: Paul shares 10 tips for getting designs signed off. Marcus looks at how to present to a prospective client and Michael Slater introduces us to Ruby on Rails.

Podcast: Download (25.5MB)

Download this show.

Launch our podcast player

News and events | Marcus: How to present to a prospective client | Paul: 10 tips for design sign off | Michael Slater talks about Ruby on Rails | Question of the week

Housekeeping

All change

I have a bit of housekeeping news before we go any further with the show. I am changing things around a bit with my podcasting line up. After a chat with Dan Oliver from .net magazine we have decided that I will no longer be doing their show. They have some great plans for it in the future but it just didn’t make sense for me to keep doing two very similar shows. Before people start emailing, no we haven’t had a falling out and I still love Dan very much… if only I wasn’t already married.

The good news is that this allows me to introduce some more guests onto this show and bring in a bit more discussion. In order to accommodate this we will be having just one feature section each week instead of my bit and Marcus bit. Some weeks I will do it and other weeks it will be Marcus.

The final aspect of all of this is that we are going to start recording the show together rather than over skype. This should deal with the audio problems we have been having as well as making for a much better dynamic.

Christmas giving

I thought it might be nice to use the mighty power of the Boagworld listeners to raise a bit of money this Christmas and wondered if you might all be so kind as to help.

We have been doing this show for well over 2 years and have never charged or done much in the way of advertising. We are therefore wondering if just this once you would dip your hands into your pockets and give a bit of cash.

I want to raise some money for a charity I have been personally supporting for a while. A friend I grew up with now runs a school and orphanage in a very rural part of India. The kids they work with have far from the best background and the school is the only hope they have of breaking out of their circumstances.

I wont emotionally blackmail you with sob stories (because I know you are hardened cynical geeks) but simply ask that you give me some cash in return for the two years of free shows I have given you.

Because I am unorganised and only thought of this a couple of days ago we are going to simply use my paypal account to collect donations. I will then pass the money on to the charity. So to give a donation just use the bottom below (be warned its not the most intuitive system ever but you are all clever chaps. I am sure you will work it out).

Give to the Boagworld Christmas Appeal

News and events

24 ways is back

My first story of the day is actually 12 days late because it is the re-launch of 24 ways. In case you haven’t come across 24 ways before I should explain that it is an advent calendar for web designers.

Each day in December leading up to Christmas they publish an article written by some of the leading lights in web design (oh yes, and me). The articles are somewhat random but also incredibly practical and hands on. Articles range from creating a never-ending background to working with online maps.

But don’t panic that you have missed the first half of advent. You can access all of the previous days. In fact you can even access the last 2 years of articles. Ample to keep you amused while we are away over Christmas.

Tips for development and design

If 24 ways isn’t enough to quench your thirst for knowledge then let’s throw two more articles into the mix both of which provide some top tips.

The first is for all you developers out there. The guys at Blue Flavor have shared their top 10 tips for a successful development project. The article includes great advice like, always create a functional spec and talk to your clients. Interestingly one of the suggestions is to use a version control system. This is also a tip in our second article which is aimed instead at designers.

Jina Bolton has written an interesting article for Think Vitamin entitled “creating sexy stylesheets“. Like the blue flavor article this one lists 10 tips. However this time they are for producing better stylesheets. Now, although I would argue that nothing makes CSS sexy this is still a very useful list. The tips for organising your CSS file and building your own framework are particularly good.

So if you are into top 10 lists then you should be happy this week whether you are a designer or a developer.

24 wayswhich post articles on web design over the Christmas period. Well, I was asked to contribute to the site so I wrote an article entitled 10 tips for design sign off. Although some of the tips have been covered on the show I thought generally it would make a good segment for the show.

The problem is that getting design sign off can be one of the most challenging parts of the web design process. It can prove time consuming, demoralizing and if you are not careful can lead to a dissatisfied client. What is more you can end up with a design that you are ashamed to include in your portfolio.

How then can you ensure that the design you produce is the one that gets built? How can you get the client to sign off on your design? (Question of the week

What tips do you have for getting designs signed off?

Show 101: Delusional

Posted in Classic shows on November 6, 2007 by Paul Boag

On this week’s show: Paul finally looks at the subject of intranets. Marcus delves deeper into the subject of rates and Andy Budd discusses getting design sign off.

Podcast: Download (28.8MB)

Download this show.

Launch our podcast player

News and events | Marcus: Rates (Part 2) | Paul: Intranet delusions | Andy Budd on design sign off | Question of the week

News and events

OpenSocial from Google

The big news this week is the launch of OpenSocial, which is a new way for developers to build widgets/applications for a number of high profile social networks. At the moment the line up includes Google, MySpace, LinkedIn and many more. It really is an impressive list of partners.

This is exciting news for those who wish to deliver content to existing social networks as before OpenSocial it was necessary to re-code your application for each site it was delivered to. In many cases this just wasn’t worth the effort and a lot of developers just focused on the big name that is Facebook.

Now developers can build once and deliver to any number of social networking sites. However what is even more interesting is that you can build these applications using nothing more than HTML and Javascript. Unlike building an application for Facebook, coding for OpenSocial looks like it is going to be extremely easy.

The development community is still trying to get their head around what exactly all of this means but it would appear that OpenSocial does not go as far as some would like. For example (as Jeremy Keith points out) it does not solve the problem of having to re-enter your personal details and friends on every site you sign up for.

Content and presentation

I came across an excellent post by Mark Boulton this week that looks at how designers engage with content. He comes at it from the angle of typography, arguing that it is about a lot more than just typefaces. However, his underlying point is much broader.

How often do we really engage with the content on the websites we design? Does the content inform our designs? Are we just building templates that get populated or are we really working with the content in the same way art directors do?

If you look at traditional ad campaigns the design and content work hand in hand. The design reinforces the message and the message informs the design. Although we see this all the time on TV commercials, billboard ads and marketing campaigns we rarely see it on the web.

In many ways we have cracked a lot of the technical challenges of the web. We have best practice for coding, accessibility and usability. We know how to make our sites available and usable for all. But do we know how to really engage with users? How to interact with them on an emotional level? That is the next big challenge.

Online calendars and date pickers

The final news story for today is another great list from Smashing Magazine. This time they list the top online calendars and date pickers. I don’t know about you but I seem to spend a lot of time working with dates for various reasons. Much of the information we put on the web is date specific, from events to blog posts. It is common to want users to be able to search by date or access a calendar of events.

This post from Smashing Magazine offers a plethora of date related tools from online calendars you can embed into your own website to date pickers that avoid those difference in date formatting.

If you ever need to work with date related information this list is worth a look.

Marcus’ bit: Rates Part 2

This can be a tricky subject and, because of that, I’m not going to go into what Headscape charges. I’m going to look at some survey figures and talk about charging for different services and when and how you should go about raising your rates.

This topic is of interest to both clients looking for an agency as well agencies and freelancers – we all want to know if we’re competitive. To save myself writing about this from both angles, and probably confusing everyone, I’m just going to concentrate on this from an agency standpoint. However, each point is easy to switch round to the client angle.

Enough rambling…

You get what you pay for

So using my favourite car analogy, are you offering a Bentley, a BMW, a Ford or a Lada! I guess the point I’m making is don’t over or under sell yourself. Recognise what you can offer and go hard for that market.

Have you got thousands of happy clients being serviced by a hundred staff in marble clad offices in central London? Or are you and your mate from Uni just kicking off your business in your dad’s garage?

You might not like it but talent, in this case, doesn’t really matter one jot. No big spending client is going to go for our second option above. This is fact of life. Accept it, move on.

If you want to charge top dollar then you need to show the following:

Relevant, high quality portfolio
Reliability and flexibility
Wide range of services
Innovation or at least ‘keeping up’

So, what do people charge

Right here, right now – I don’t know. However, I have got details of a UK survey carried out a couple of years back that, with a bit of an uplift, are I believe still relevant.

These are daily charge out averages across all agencies that submitted to the survey:

Director – £750
Consultant – £650
Creative lead – £670
Designer – £570
Project manager – £600
IA/usability consultant – £610
Developer – £610

Of course, the actual figures varied greatly even within certain disciplines. For example, creative lead rates were as low as £370 and as high as £800.

Pricing roles

At Headscape we used to have one flat rate for all services provided. At the time, this felt fair and was certainly easy to manage.

As we have grown, we have found that the pressures on some staff, particularly the directors, have grown markedly and therefore we have had to charge more for those roles.

Regionality

The survey suggests that regional price differences are, pretty much, London and ‘everywhere else’. Notably with the South West coming a strong second! (We are based, more or less, in the South West).

Large city based agencies will always be able to charge a premium but I expect this is less so now due to ease of communication. We have had a number of clients over the years that we have never met.

Raising prices

This is a balance. We should all raise our prices to keep up with inflation but, we should only do so if we think the market will take it. Also, it’s possible that a particular service that was seen as ‘cutting edge’ and therefore got a high price tag, may later become ‘run of the mill’ so it’s possible that you may need to cut the price for that service.

Paul’s corner: Intranet delusions

I have been asked a number of times to talk about Intranet development and I have always avoided doing so. This is partly because I am not an expert in the field (although that doesn’t normally stop me talking about something!) However, it is also because intranets are a massive area and one in which so many mistakes are made. There seems to be a huge amount of naivety about developing and running Intranets. Against such a backdrop I am somewhat unsure where to begin.

In the end I have decided to take 5 of the most common misconceptions about Intranets and see if we can shed some light on why they are wrong.

Ask the expert: Andy Budd on design sign off

Paul: Joining me today is Andy Budd, hello again Andy.

Andy Budd: Hi Paul, how are you doing?

Paul: Not bad, it’s been a little while since I’ve had you on boagworld, I think?

Andy Budd: It has, I think it’s been a couple of years now, I think it was d.construct 2006 was the last time I remember chatting to you.

Paul: Unbelievable, I’ve spoken to you since then on the .net podcast mind, so, we’re keeping in touch.

Andy Budd: Yeah, and also just hanging out together, and doing, ya know, things.

Paul: I try and obviously avoid you, because whenever I meet you, you seem to be horribly rude to me but I will forgive you.

Andy Budd: What?!?

Paul: (Laughs)

Andy Budd: Oh Paul, you know that’s not true, that’s not true.

Paul: Ye, but I want to paint you in a bad light and get a bit of sympathy for myself.

Andy Budd: Oh okay, that’s your tactic actually isn’t it?

Paul: Yeah.

Andy Budd: I also heard that you try and play dumb, so ya know, everybody else comes across as being smart and you get the sympathy vote.

Paul: You’ve been listening to the Rissington Podcast haven’t you?

Andy Budd: (Laughs) I have indeed.

Paul: (Laughs)

Andy Budd: I’m not sure I’d buy that but, ya know, it sounds good.

Paul: You think I’m just naturally dumb?

Andy Budd: … So what was the first question?

Paul: Okay.

Andy Budd: (Laughs)

Paul: First question, no, what we’re going to talk about today with Andy is just looking at maybe processes, ya know, when you run a website company how do you go about dealing with getting things like design sign off and this was something that came up quite a lot in the 100^th episode that we recorded a little while back and is also some we talked, we vaguely talked about running a web company on the .net podcast recently but I kind of wanted to home in more on design, because design is a hugely subjective area and getting design sign off is quite a challenging process. So Andy lets kick by just, if you could give us a rough sketch about how clear:left go through the design process, what are the steps that you go through?

Andy Budd: Yeah absolutely, it’s kind of interesting because it has changed, ya know, a small amount anyway from when when we started to what we’re doing now. I guess one of the main differences from what we do to what a lot of other agencies do is we generally only present a single design concept. It’s very common, particularly for companies that come more out of a print background to do this whole idea of like, we’ll show three design concepts to a client, I think that partly comes from a desire of print design companies too sort of make a bit more money rather than just showing one design, they do three designs a let the client pick. I’ve always found that this is kind of an odd way of doing things because, well first of all I don’t think you really giving your client good value because what your ending up doing is your doing three times the amount of work and the client only get a third of the value, they get to pick one of those three designs.

Paul: (Agrees)

Andy Budd: The other thing I’ve found is whenever I worked at agencies that have taken that process and I’ve been the designer developing the designs invariably what happens is you, say you’ve got a week to produce the designs, you spend maybe three of four days on one design and it’s working really well and your happy with it and it’s moving in the right direction, you only spend one or two days on another design which you kind of fine with, if the client picks it then your happy because it looks nice and then you’ll do something quickly for the last half a day just to kind of fill up the space.

Paul: Yeah.

Andy Budd: And then you have this horrible situation were by, even if the client picks the design that your least convinced with or what more than likely happens is they’ll pick elements from each design and create a bit of a Frankenstein’s monster, and I kind of do think that clients come to professional design consultancies for their design knowledge and their design experience and I think that from my perspective and from my experience the design that the designer feels most happy about is probably the design that fits closest to the clients goals, because that the one they’ve been spending the most time and effort on, thinking about, so really the first thing we tend to do at clear:left is only ever show our client an initial design or one design. That doesn’t necessarily mean that we’ll only create one design, quite often, for instance, Paul one of our designers, our lead designer might create a couple of different versions initially and we’ll have a design review and I’ll look at what’s going on and we’ll chat about various pros and cons of the different designs and he might spin off in another direction but we tend to show the client what we think is the best bet rather than something that is half finished or just something that we don’t think is quite right.

Paul: Yeah, I would agree with that, that the whole principle of if you show a client a multiple designs they inevitably pick a little bit from each of them and that never quite works as well as it sounds. I mean, have you ever tried with multiple designs, having more than one designer work on those designs so you do like one each with three of you or something like that?

Andy Budd: Well again, I think this goes back to giving value to the client and I don’t think it makes sense for the client to pay for two or three designers time and expertise to give them the opportunity to only pick one.

Paul: (Agrees)

Andy Budd: I think what tends to happen in that sense is design stops being about solving problems and starts to become much more subjective and almost a beauty competition.

Paul: Yeah.

Andy Budd: So what happens is rather than the client picking a design or understanding the design from a technical point of view, ya know, why you’ve, ya know, what mood your trying to create or what feeling or sensation or how the hierarchy works and how the hierarchy that you’ve created matches the hierarchy of use that you need a user to flow through. Rather than it being more scientific it becomes much more subjective and it becomes much more about, ya know, whether the client liked particular colour, they had a particular colour on their bedroom wall and they hated it or they loved it or it’s their favourite colour, so I think, again, just having that kind of three design approach makes it much for subjective and much less scientific.

Paul: Yeah.

Andy Budd: I do agree that if a clients got lots of money, ya know, your talking with a big client and they’ve got months and months of design budget available then it does make sense, the kind of clients that myself and most of my colleagues sort of deal with, they got reasonable budgets but they haven’t got budgets to burn so they want to see as much value as possible and the idea of pitching two designs just kind of, ya know, seems… it just doesn’t in an environmentally sort of, ya know, challenging world that we live in at the moment, where people want to recycle and people want to see usage. Throwing two designs away always seems a bit, kind of wasteful.

Paul: I mean, talking about the thing of making the process more scientific and less subjective, how to do you go about encouraging the client to set aside personal preference and focus on how they should really be judging the design? And, sorry, there’s a spin off question now which is how should they really be judging the design?

Andy Budd: Well, it’s a really difficult question …. I think everybody feels that they have a good understanding of what design is. Everyone’s got their own personal opinion, everyone’s got their own personal tastes, so everyone feels that they’ve got an understanding of design. We’ve all watched changing rooms, we all know that a fancy designer comes along and he’s got big cuffs and ya know paints, crazy colours on the wall, sticks vases all over the place and that’s design, but I think what people actually see is not design but the manifestation of design. The actual design process is much less creative than people like to think, it’s much less throwing bits of colour on the wall and using your creative juices to see what colours and shapes match. It is much more the processes, much more the starting off with a central problem or a central set of problems that you’re trying to solve and using design techniques: hierarchy, colour, weight, positioning, to create a design that solves a solution, and again, and you have to look at design works within constraints. If you are asked to sit down in front of a blank canvas and just create something, that’s much more than an artistic endeavour than a design endeavour. Funny enough, we were having this conversation in the office today, a couple of minutes before we had this conversation and it’s much easier for good designers to have constraints, to have content to design around to have an idea who’s going to be using the site so I think design is much more the scientific process than a number of clients give it credit for. In answer to your first question “how do you get clients to feed back in the right way”, it’s very, very difficult. Ideally, what I’d like to say is, we sit down with every single client and explain the design process in detail, explain how it all works and stuff but unfortunately, design is very subjective and also feed back is very, very difficult to interpret. If a client comes to you and says “I want it more wizzier, more zingy” their using the vocabulary they have at hand to describe something they have an idea of in their mind and our job as designers is to try and understand what it is they are actually trying to say. They are trying to communicate a visual thing or a motional thing with words and quite often it’s not possible, quite often, you will have to try two or three different approaches before you actually figure out what “zingy” means. Does “zingy” mean bright and colourful, does “zingy” mean they want motion and so it’s difficult having design discussions with people who aren’t trained in using ya know, having design discussions and frankly, I find it difficult enough sort of having internal design reviews with our designers and trying to describe what’s right and what’s wrong with the design. So I do, ya know, I do really understand from a clients perspective, how difficult it is to try and deal with their designers and get their designs or get their sense across. I think we always try and take it back to first principals. We try and encourage our clients, no to sort of worry or obsess too much over the details but to kind of think more of the broad picture so not more whether you like this particular colour or whether you like this particular shape but ya know, what kind of sense of feeling you’re trying to have this design communicate ya know, we’re doing some work with an environmental website at the moment and they really wanted to create a sense of a feeling of nature and openness and warmness but really avoid the kind of clich233s ya know, let’s have pictures of trees and ya know, it will all be green and kind of earthy. So they communicated the sense and the emotion they wanted to get across and then we obviously translated that and put it into graphical format and I think in reality, that’s what the designers’ job is. It’s translation, except instead of translating one written language into another, we’re translating a written language or an oral language into a visual language and so it’s interesting but yeah, it’s setting the boundaries and saying to people, this is not, ya know, we’re not asking you at this stage to comment on the details or on the general sense, the layout or the feeling and as you move along, get more and more specific.

Paul: You talk about how sometimes a client uses a different language to describe what they’re seeking from a design so do you ever use things like mood boards or what other sites do you like as a way of kind of getting an idea of their personal tastes? And should you be catering for their personal tastes anyway?

Andy Budd: It’s a fine balance, I mean, yes and no. Ultimately, it’s not the client that will be using the website, it’s the clients’ client, so the clients’ customers so really the ultimate goal is to create something that, ya know, the customers or the visitors are going to use, the visitors are going to love and their going to feel as though it’s their own but obviously, you are also dealing with human emotion and if a clients paying you money to create a design, you want them to be happy with it as well. Again, it’s an interesting challenge. We used to in the past, really encourage our clients to go out and have a look at different websites that are out their and we’ve actually got a, sort of a flicker group of inspiring websites that we can point clients to and say, look, here’s some of our favourite websites. Why don’t you go and have a look at some of these, ya know, use those as a basis because it’s really useful instead of asking people to off cold to describe what they want and to actually show you stuff and say, I like the typography of this site or I like the colour scheme of that site. A lot of designers will actually say, you shouldn’t ever show sites, ya know because then it kind of gets a bit derivative but I think, ya know, as we’re working on the web it is helpful to show clients similar designs in that same medium so I think it is useful for us anyway to show clients sites. And that’s always a good starting point, ya know, we like this site because and we like that site because. Unfortunately is sometimes backfires and sometime, particularly if the client isn’t as, sort of embedded in the design community as we are, they will pick some sites that they use on a daily basis that don’t necessarily show good design as designer might preserve it and then we have to kind of work round the edges and show kind of show them what we think they might be kind of thinking about, but the mood boards is a really good point it’s something that we’ve started using more recently and it’s a really good kind of first step, rather that jumping straight to the design process and possibly missing a translation, we have started showing clients mood boards, and if some of your listeners don’t know what mood boards are, they’re essentially a very quick way of explaining a mood or a sense or a feeling or a colour scheme on a design without actually having to do visual design, so what you do is take elements of design that you might have seen elsewhere, you might take some interesting photos you’ve seen on flickr, and maybe those photos have an interesting colour scheme or they might have a particular theme or sense that your trying to get across, ya know, maybe take some navigation elements from one site or a t-shirt you particular like the colour scheme from, a whole bunch of different things, put them down on a piece of paper, I mean in the old days it was a piece of paper in advertising, they would cut out bits from magazines. These days we tend to do digital mood boards which are more graphic art and photos and present them to the client, and that gives the client a kind of basis in which they can spin off their opinions, so they can look now at this mood board and say well, we said we wanted it clean, we didn’t mean we wanted it sort of white, we meant we wanted it sort of, ya know, some other adjective that works with clean, and it kind of gives them a discussion point, rather than just sitting around words you can now look at something physical and tangible and the good thing is mood boards only need to take an hour or two. And again we’re working with a client at the moment and we initially created some mood boards for them and it sparked a discussion and they weren’t sure about some of the things on the mood board but some of the things on the mood board they really liked so we worked out a second iteration which was even closer to what they wanted and when we finally sort of got to a level that we felt both of us understood what we expected from a design point of view then you can move onto the next stage.

Paul: Yeah, I mean it’s quite interesting, I think design from my personal experience is as much about what you do before you site down in front of photoshop or whatever than it is actually in the actually putting pixels on the page. I’d be interesting in what other things you do before you get to the design stage, you’ve said you use mood boards, what about things like personas what business background information do you tray and get before you start? Do you get people to personify there company and describe what kind of person it would be, ya know all the kind of techniques that people use, what do you guys use?

Andy Budd: Well again, that’s really interesting, I mean your right, a majority of people kind of think design is a visual thing, ya know, so, ya know the first thing they think about or expect when they’re getting designs is to see some kind of photoshop comps or some pretty pictures, clear:left we are a user experience design consultancy and what that essentially means is we kind of do meta design, we don’t just do the visual stuff but we design the systems and so what we do from the outset of dealing with our clients is we have workshops with them we ya know, a big discovery period to find out exactly what it is that they want, ya know, requirements gathering, we’ll do research into their users so quite often we’ll go out and we’ll interview potential users, their potential kind of market, we’ve done work in the education sector we’re we’ve spent a few days in schools and we’ve talked to teachers and pupils and school secretaries to find out how they do their day to day work, what kind of features and functions they would require off a site, using this information research we might create personas, and personas are a great way of capturing a rough demographic I guess of users and it allows you to start thinking in terms of how people will use the site because what tends to happen is people will sit down and think of the stereotypical user but each users got different needs and the nice thing about personas, is if you’ve got your personas fairly accurate it can then help you work out what features and functionality you need by following on the scenarios, a scenario is say your buying shoes or you doing a shoe store, so it might be that I want to buy a pair of dress shoes because I’m going to a formal function so I want to get a pair of smart shoes to match my suit so then what you can do is you can sit down and plan out on this system, how would I get from the homepage through to the purchasing process, how to get from a to b to c and that kind of helps design the system. The problem with personas is quite often you will do personas and they’re sitting in a draw, so personas aren’t right for every single project, and we’ve had a couple of experiences recently were we have done personas and we probably shouldn’t have done because the client already had a fairly good understanding of what they wanted to do but it’s kind of trial and error.

Paul: Yeah.

Andy Budd: Most of the time we find personas work really, really well, but they do work best when the client doesn’t really have a set idea of how their website is going to function and ye we do wire frames and wire frames are a big part of what we do, a big part of information architecture and big part of the user experience and design and again if your listening are you aren’t aware of what a wire frame is, it’s kind of somewhat like a story board in movies, so in a movie rather than just going and filming everything because celluloid’s really expensive, they’ll get some artist in to draw out scene by scene, frame by frame almost, how the story is going to progress and that’s a way of planning the shots, planning the locations and you can sit down in front of the story board and get a real sense of how the movie is going to flow and to work before you ever need to set up on set, and so we do something very similar with our websites, we create wire frames, which they can be on paper, they can be in HTML and it’s literally kind of a wire frame a kind of rough representation of how the site is going to fit together, and so when it comes to visual design and it come to the interface design the designer isn’t working from a blank sheet, they’re working from a fairly details blueprint, no so much on layout terms but on content, ya know, we need to have this block of content here, this is what inside this block of content, this is the hierarchy, this is more important, this is less important and so basically once the client has seen the wire frames and understood how the process is supposed to flow, they’re already signed off and they’ve already agreed to lay off the design decisions were as more traditional visual designers would try and do that on a photoshop document and I don’t really think you can capture, ya know, if you doing a fairly flat design or a fairly simple brochure website, you can probably capture that sense in a photoshop document but if you doing a more advanced, if you doing a more complicated site that has more interaction, maybe a, like a sort of social software, web applications site, you can’t show all this stuff in a flat document so you need to have this click through process.

Paul: No that’s cool. Okay to rap up I just wanted to ask about the subject of iterations because it’s something that we’re asked quite a lot and basically what people do or are concerned about is how many iterations do you go through when the client comes back to you and says I want this changing and then you make that change and then they want something else changing and it kind of can go on through this endless cycle, were do you draw the line do you have a contractual arrangement, we’ll do three versions of this or how do you deal with it?

Andy Budd: Again a very interesting question, the way we tend to work a clear:left is we tend to sell our services based on time spent rather than some kind of end point, because design is very subjective and as you say, you can’t sort of keep going on and on and on and keep making changes because not only will the project spiral out of control in terms of time but also in terms of budget and stuff, so what we tend to do with our clients and with our project is we specify a certain amount of time, we’ll spend 20 days on visual design and ye 20 days on a template build or whatever and we are a little bit flexible and this kind of almost goes back to something I was talking about on my blog recently about deadlines and stuff, ya know, if design takes a couple of days more and templates take a couple of days less in the end it all kind of balances it’s self out, but we do tract time to make sure we’re on track, we tend to say to clients that we’ll offer two iteration, again sometimes it requires more sometimes it requires less, but all along we track the time so to make sure we’re not going vastly off. What we try and do is kind of make the iterations increase in size so going back to what we where say before about the mood boards, you can do a mood board really, really quickly and you can get to a point a lot faster, understanding what the clients needs are by giving them a mood board or a couple of mood boards, a couple of quickly little iterations and, ya know you get significantly further down the line. Something we’ve been doing recently which I think is a really interesting idea and seems to be working really well is this concept of a one day design concept.

Paul: Okay.

Andy Budd: And so what we do is, in the olden days we’d spend like maybe a week coming up with an initial design concept and it was really good and it was really high level and it was really detailed and we’d give it to the client and if the client wasn’t sure about various elements, we’d be a little bit, because we’d spend so much time and effort into the design we’d be a little bit more resistant to making changes, were as we realised that if we did just a quick design iteration, that was just one day or one and a half days we’re much less kind of stuck on the design because it will be rough, because it will a bit rough and ready, which means that we’re much more flexible and happy to make changes and go in different directions also it means that if you are only given a day or a day and a half to do a design, you don’t obsess on the details, you work on the more broad brush strokes, you get the feeling and the sense and the layout right, you don’t worry about how the text is aligning or how the icons are place and that give clients first of all some instant feedback and rather than the old days, you’d go away and do a design, magic would happen and two weeks later a completely finished product, it gives clients a bit more of an insight and a bit more input into the process.

Paul: Yeah.

Andy Budd: They’ll see after a design they’re getting something that’s already start like a real project and they’re getting really excited, they sort of start inputting and feeding back. The difficulty is managing the right kind of feedback and getting the right kind of feedback at the right time because obviously in the early phase is what we really want is our clients to feedback on is just the overall look and feel. Is the layout right, is it giving the right sense, and not obsess about the details because we haven’t spent any time on the details.

Paul: Yeah.

Andy Budd: And then we iterate and once we’ve got an idea we’ll do another iteration which is more finessed and then maybe a third iteration which is more finessed. And then normally by that point because we’ve gone through a bunch of different steps and we’ve kind of had client buy in on the way by the time it gets to the second, third round of iterations, it usually is just dealing with the details.

Paul: Yeah.

Andy Budd: The problem is that almost all clients obsess about the details more than they really need too. And it easy too, I understand, if someone puts a design in front of you and they say, give me feedback clients obviously want to be really helpful, and they’ll jump into the design and say well that buttons miss aligned or I don’t like that orange I think it should be a different colour or whatever and really obsess about the details and I think at that point, ya know, that’s our job to obsess about the details I think. As designers we are more obsessive and we’ll sit there and we’ll move things a couple of pixels or ya know, play around in the colour palette and make sure things are exactly right and so what we’ve been tending to do is once we’ve got the initial direction of the project, once we know that the client likes the overall scheme, we kind of go ahead and build it and don’t necessarily go ahead and design it and while we’re not necessarily, not asking for feedback, so we’ll present our designs and if clients look at them and say oh well this is wrong and that’s wrong, that’s fine we’ll go and make the changes, as the client looks at them, I think basically what I’m trying to say is if you ask for detailed feedback you’ll get detailed feedback, if you present something to a client then if there is an issue they’ll feed back and if there isn’t they won’t. I think this has come about from a lot of usability testing, we sit down with test subjects and if we ask them for an opinion they’ll always give us an opinion, trying to be helpful whether that opinion is something they really think or something they’ve thought, well I’ve been asked to say something so I better say something.

Paul: Yeah.

Andy Budd: And so we’ve been trying to be a lot more subtle with feedback and rather asking for a definite cut off time, a definite sign off, we now expect a long list of stuff, it’s like here are the design, if you have anything to say that’s fine but if you don’t that’s great we’ll just get on and implement them.

Paul: Yeah, I like that. That’s a really good approach. Thank you very much Andy that was a really interesting conversation. I think every agency does things in a slightly different way and it’s good to hear the clear:left methodology.

Andy Budd: Excellent, well actually, sorry can I just jump in there and say something.

Paul: Yeah.

Andy Budd: Because I think this is an interesting point and it is a problematic thing, I don’t think a lot of companies have a process and a lot of companies will, ya know, every single project they will do the same thing time and time again and that’s good because you know at the start of a project exactly what your going to do step 1, step 2, step 3, the problem is not all projects and not all clients want all those step or all of those steps are necessarily valid for the thing they are trying to do.

Paul: Yeah.

Andy Budd: So I think what we’ve learned over time really at clear:left and it’s something we’re still learning and I think everybody’s still learning is rather than having a process have a methodology have a bunch of tools that you can use on a particular project, so if a certain project requires wire framing we do wire framing, if it doesn’t, drop it. Ya know, if a certain project needs a mood board, we do a mood board if a certain project doesn’t, we don’t do it. And so I think a methodology is the right point here rather than a process because a methodology keeps you flexible and a methodology means you don’t get stuck doing the same stuff over and over again.

Paul: Excellent, Okay, thank you very much Andy and I’m sure we will have you back in at least before the next two years are up. (Laughs)

Andy Budd: Yay, well thanks very much Paul delightful.

Question of the week

What tips or techniques do you use to smooth the process of design sign off? Answers in the comments.

Show 97: FoWA

Posted in Classic shows on October 9, 2007 by Paul Boag

On this week’s show: Paul proposes tactics for overcoming design by committee. Marcus talks about extracting a budget from clients and Dan Cederholm compares pixels, ems and percentages.

Podcast: Download (27.0MB)

Download this show.

Launch our podcast player

News and events | Extracting a budget from your prospects | Avoiding design by committee | Dan Cederholm on ems vs pixels vs percentages | Question of the week

About 100th episode

We really want the 100th episode to be as interactive as possible while keeping the format of the normal show. So with this in mind here is what we have in mind for our live show…

News – This will be the top 4 news stories that have most effected web design since the shows launch in August 2005
Marcus – Most unreasonable client
Paul – The worst web design mistakes of all time
Ask the expert – Ask Paul and Marcus any question you want whether it is related to web design or not

You can either turn up on the night and contribute or send us an email or MP3 with your contribution to any of the above areas.

News and events

Gossip from FoWA

I wanted to share a little about the FoWA conference I have just attended. It was absolutely superb and I am extremely glad I attended. The speaker line up was excellent and the subject matter was inspiring. There was a good supporting expo which was great as it prevented the problems that have occurred previously of sponsors touting their wares in the speaking slots.

However, I am not bringing it up simply to gloat that I was there and you weren’t. I got to speak to some great people and leant a few things that is worth passing on. Firstly, it is very apparent that the power of podcasting as a marketing medium is really on the rise. I had a long chat with David Prager and Jay Adelson about Revision 3 the company that produces Diggnation among other shows. It sounds like things are going great for them and they are pulling in some big name advertisers. However, the advertising model is not the only approach that is working within podcasting. The other is the promotional approach where you showcase products that subscribers can then buy. This is perfectly demonstrated by Wine Library TV hosted by Gary Vaynerchuk that allows you to purchase the wines reviewed in the show. I was fortune enough to meet Gary at FoWA and it is obvious that it is passion for the subject and strength of personality that makes the show work.

Of course the real power of podcasting was demonstrated in the live taping of a diggnation episode. I estimate that approximately 1200 people turned up for the recording and it was more like a rock concert than a geek conference. Kevin Rose and Alex Albrecht (the hosts of the show) were pretty much mobbed after the show by insane fans. It was almost scary and drove home the power of the medium.

I could talk about some of the great speakers I got to hear including a stella performance by Daniel Burka who gave his first ever conference presentation. However, I don’t have the time to cover it all so want to share instead a couple of rumors surrounding Google. The first is that the fabled gPhone from Google is in fact going to be an operating system rather than a specific hardware device. If this is true it could well introduce yet another platform for creating cool web based mobile applications. Finally I wanted to mention the imminent announcement of Google in relationship to its APIs. It would appear Google is about to open up its many online offers from Gmail to Docs allowing third parties to build web applications based on them. This will really open up the opportunities for developers to really innovate.

The average website visitor

The next news story of the day is yet another list from Smashing Magazine (this is getting boring now). This one attempts to bring together some general stats on website users from various sources. Although the article acknowledges that really you need to look at your own stats it does explain that from time to time you want a more general picture of the average web user.

The post therefore lists 8 facts you should know about the average user. These include (but are not limited to)…

The most popular browsers (bet you can’t guess!)
Most common screen resolution
Most popular operating system
Most popular browser family worldwide
Most popular browser in Europe
Most common browser size

Getting started with Photoshop

We know that not everybody who listens to this show are web designers. Some of you are developers, clients or students. Some of you are just starting out in web design. If you fall into any of the above but want to get a better understanding of a key tool of the web designer then you maybe interested in a new article by Sitepoint. This detailed tutorial is an introduction to using Photoshop.

This is an amazingly detailed introduction that covers everything from the user interface right the way through to working with Alpha Channels. As you can imagine it is a long read but if you have the time I cannot think of a better introduction to this hugely powerful image editor.

Waking the sleepers

Last up today is a post by the guys over at 37 Signals. The post is primarily written for those running web applications but actually the principles apply to a much broader audience. It is looking at the subject of sleepers. Sleepers are those users who sign up for your service but never use it (or stop using it). This clearly applies to web applications but is also applicable to ecommerce sites or even sites that offer newsletters or other registered features.

It asks how these users can be reinvigorated and encouraged to become active again. Using an email from StumbleUpon as an example the post suggests so good ways of breathing some life back into your users.

If you are struggling with an apathetic user base this is worth a quick look.

Marcus’ bit: Extracting the budget from clients

So here’s the situation: I receive an invitation to tender in my inbox from a potentially good client. The brief is well written and, for the most part, the requirements are clear. The first thing I do is check the timescales, second is to see what the budget is. But what if the brief does not include a budget? How do you extract the budget from the client?

Paul’s corner: Avoiding design by committee

So I have now reached chapter 4 of my book writing marathon and in line with my commitment to recycling I want to share with you some of the content from my initial draft. Chapter 4 focuses on the role of the client in the design process and one of the big challenges that they face is design by committee. Of course, avoiding design by committee is something designers want to avoid too which is why I thought it would be a good subject to cover on the show.

Ask the expert: Dan Cederholm on ems vs pixels vs percentages

Paul: So one of the most common questions that I seem to get time and time again as far as CSS is concerned, revolves around working with ems and pixels and percentages and what to use when and how to work out what you should be using and all of that kind of thing. So, I thought, “Let’s get an expert in.” And so, I have Dan Cederholm joining me. (Dan Snickering) Hello, Dan.

Dan Cederholm: Hello Paul!

Paul: Don’t snicker! You are the expert for today.

Dan Cederholm: (laughing) I’ll try to be. I’ll put on my “expert hat”.

Paul: Just go with the flow, its fine.

Dan Cederholm: I will. (laughs some more)

Paul: Okay. So Dan, like I said, this is a common question that we get asked and I’m just interested in your opinion about “When’s the right time to use what combination? Should we mainly be using ems? Should we mainly be using percentages? Should we be going pixels?” What’s your take on the discussion?

Dan Cederholm: Well I think it, in a very politicianesque way, I’d say it depends. (Paul laughing) And this call is over. I could just hang up now (Dan laughs).

Paul: Okay

Dan Cederholm: No, I’m just kidding, it depends.

Paul: Depends on what then? (Paul laughs)

Dan Cederholm: Yeah, so it depends. Now are you referring to strictly font sizing or units in general for boxes and things?

Paul: I mean, there’s lots of different things isn’t there? (Dan: Yeah) There’s kind of, do we make, you know, when we design a whole web site, should the web site be fixed width? Should it be hybrid? Should it be fluid? Should it be built so its elastic? Let’s start with that as the discussion.

Dan Cederholm: Okay. Width in general… Well, I think, like I said, it does depend. It’s a tough decision to make depending on the site and depending on what’s in the site and the design and that kinda thing. It can be tricky. I love EM based design. And that’s what I use currently on SimpleBits and a few other sites that I’ve done recently. But, I’ve actually been sort of re-thinking that because its difficult to do… to drop in say an image or something that’s fixed width in that design and still account for that fixed element to be cut off or to look odd when the text is re-sized or if the text, the base font size is different. To me, the difficulty with an em-based layout is sort of the fixed image problems. So, for instance, on SimpleBits, for my blog posts I’ve been wanting to do more visual stuff like drop in an image from Flickr or a photograph or something.

Paul: Sure.

Dan Cederholm: But that becomes difficult because its em-based. If the image is a fixed pixel width, obviously its hard to just drop that in and design around it so that it looks like its meant to be there, you know?

Paul: Mmm Hmm

Dan Cederholm: And now there are tricks that people have experimented with, with em-based and setting the image width as well.

Paul: Right

Dan Cederholm: But that, of course, gets tricky when if the image is blown up it looks, you know, it will look terrible or shrunk down or won’t look as nice as it would if it was re-sized properly. To me, that’s the biggest drawback to em-based layouts. So, depending on the site, if the site is not image heavy or if you’re not going to be doing a lot of that sort of image stuff, then em-based styles can be excellent and they can provide, sort of that flexibility, almost like zooming in and out just by changing the font size.

Paul: So would your recommend that over, say, a percentage-based layout?

Dan Cederholm: Well I think that… I like the… They each have their own, sort of pros and cons. The percentage-based layout is great as well. So that’s fluid, or liquid, right?

Paul: Yeah.

Dan Cederholm: And that, that gives a little more control to the reader, because they can stretch their window out. Now, the main problem there is the “max-width” and “min-width” in Internet Explorer 6 and below. So, the common problem with that, or why people don’t use liquid layout is if you stretch the window out really, really wide, then line length becomes a problem with readability.

Paul: Mmm Hmm.

Dan Cederholm: But, that can be solved by setting a max-width to certain things. So in IE 6 and below, that’s not supported aside from some javascript hack or something. But, liquid layouts do offer that extra control for the reader. Some people… its weird, its like a religious sort of divide. Some people hate liquid layouts. Some people love them or swear by them. Its interesting how people can get. It can be a heated debate with designers. I found… it’s interesting with uhm… so, the iPhone came out over here in the US and I found liquid layouts actually look far better in the iPhone because of that small window width and that becomes even more of an advantage on a smaller screen. As opposed to fixed-width layout or even an em-based layout, the viewport isn’t necessarily computed correctly and you don’t take advantage of the full screen, whereas with a liquid layout, it does.

Paul: So when you do, say an em-based layout or a full liquid layout, what about things like margins and padding? Do you do those in the same settings or do you do those using pixels, or how do you work with those?

Dan Cederholm: Yeah, that’s a good question. So, one of the … the tough parts of a liquid layout or percentage-based IS margins and padding, because often times you need to add extra elements to add padding around, say if you want a fixed gutter width between columns. Unless you’re specifying percentage, like let’s say its a simple 2-column layout. The left column is 70% and the right column is 30%, which equals 100%. You can’t say the 70% block has a margin right of 10 pixels because now its 100% plus 10 pixels, which doesn’t work.

Paul: Yeah.

Dan Cederholm: So, you could either… there’s a couple choices… You could do a percentage gutter, so you have like 70, uh sorry, 65% with a 5% right margin and then 30% on the other side. Or, the other option would be to add another element sort of like a div that’s inside of each and the add a pixel amount to that without a width at all. So, there’s extra markup involved there. One of the things I like about ems is that instead of worrying about percentages, ems are… you can add… its easier to add gutters and padding with ems because the math works. (Dan Laughs, Paul agrees) So, you’ve got a whole width for the layout of say, 70 ems, or whatever it is and then you can break that up doing the math properly with the width of the columns and the width of the gutters as well. So, percentages are tricky because you can’t go above 100% and you can’t take away from a percentage with a pixel amount.

Paul: Yeah.

Dan Cederholm: Take away, or add with a pixel amount. So if you want fixed width gutters with liquid layout, it often requires extra markup to do that.

Paul: What about when it comes to typography? Are you suggesting always go with ems in situation like that? Because you’ve then got to add just more complexities too. You’ve got keywords that you can kind of throw into the mix there as well.

Dan Cederholm: Right. Right. Yeah, I prefer… in my own work, I prefer to use the keyword as a base. So, I’ll use “small” as a base on the body.

Paul: Right.

Dan Cederholm: And then use percentages for going up or down from there. So, headings may be 120% for a heading or whatever and then paragraphs would be 90 or that kind of thing. I like that because to me its sort of, ok, this is a base line. I know its not going to be the exactly the same in all browsers but I’ve had good luck with getting pretty damn close cross-browser sizing that way. The other way to do it is with ems and there’s a great article by Richard Rutter, actually, about sizing text with ems that he wrote a few years ago. And he explains a way of using a percentage as a base to knock it down to.. oh, are you familiar with it?

Paul: Yeah.

Dan Cederholm: And then that sort of… you can relate em units to pixel amounts. So, if you’re used to sizing text with pixels but want to use ems, he explains a way of sort of knocking down that base so that the math becomes simpler and using… specifying ems but thinking what that would be in a pixel amount.

Paul: Yeah, which is the approach that I normally use. The only thing that kind of (Dan: It is? Okay.) does my head in about that is that obviously ems inherit from one another.

Dan Cederholm: Right, exactly.

Paul: And that’s where it gets really confusing.

Dan Cederholm: It really does, doesn’t it? I mean especially if you’re nesting more than one level deep. Then the math becomes mind boggling.

Dan Cederholm: And so that still happens with the keyword percentage model that I use often… the same problem… so when you’re nesting percentages, things start to get a little weird. It becomes a little difficult to do the math but I found that I’m not often nesting too far… you know, more than maybe two levels or so when I’m sizing things. And if I am, then unfortunately, I have to do the math or try a different approach but, yeah, that is a tricky part of ems or percentages. In a perfect, ideal world, I think the designer could specify pixel, right, and then the browser would resize it from there but, you know, IE actually 7 and 6 and 5 don’t let you resize the text and I’m kinda baffled why its still a problem in IE 7. So, that would be ideal because the designer can say, “Look, this is what I intended to be as a base and this is gonna look the same across browsers for the most part for most resolutions and then the user can always over-ride that.” I mean, the user should always be able to over-ride that. But, unfortunately, for baffling reasons, they chose not to let someone do that in IE. So, that goes back to, I guess, your site statistics and if IE is a low percentage, which is probably not going to be the case for most sites, you could sort of weigh that and can say, “Well, I’ll go with pixels.” And, I mean, a lot of people do go with pixels now anyway, and just not worry about it. But I tend to, you know, I bump up si… I don’t wear glasses, for instance, and I bump the text size up on a lot of sites.

Paul: Yeah, I do too.

Dan Cederholm: And so, if I’m doing that, and I have pretty good eye-sight, I imagine a lot of people would as well.

Paul: Ok so what…

Dan Cederholm: Having that control is important.

Paul: Yeah. So, one last question before I let you go (Dan: Yeah) and get back to your normal work… You were talking about browsers there. And so, Internet Explorer 7 has come along with sort of this zoom page functionality.

Dan Cederholm: Right.

Paul: How does that enter in all of this? Does it change the landscape in any way?

Dan Cederholm: I think it definitely helps. That’s what sort of baffles me even more. I’m using the word, “baffle” a lot today. (Paul laughs, Dan chuckles) Why they would add the page zoom to IE 7 but not allow you to re-size font set in pixels. So, I think it helps in a way but the problem there is that it will… your viewport stays the same. So, when you zoom the layout, you’ll start to get horizontal scroll bars and you’ll have to sort of navigate the page that way, whereas just zooming the text, the viewport stays the same and you can read the page a little easier, I find. I mean, it’d be interesting to talk to someone that has low vision and uses, you know, zoom or text bumping up on a regular basis. I think that that’s sort of the… the downside I see to it is that its, it can help but, let’s say that you’re looking at a block of text and you use the page zoom feature and you’re window is small. Let’s say you’re on a small screen device or something or at least you’re monitor is small or whatever. So, zooming in will make it easier to read but you might have to do some extra navigating of the windows to keep reading that. Whereas bumping up the text, you shouldn’t have to do that. It should stay within it’s container and the window should just… yeah, you’d be scrolling down but you won’t be scrolling horizontally.

Paul: I mean that’s a particular problem, isn’t it? With fluid designs, I’ve noticed, with a zoom function that as soon as you start zooming on a fluid web site,

Dan Cederholm: Oh, right.

Paul (continues): you immediately get horizontal scroll bars. Which to me, is ridiculous.

Dan Cederholm (laughing): Right, right. Exactly! Right, so in bumping up the text in a fluid design, should be, I think, should be a lot more… better an experience. That brings up a good point though, with em-based design. Now, when you’re bumping the text with an em-based design, the entire layout, if they layout is set in ems as well, the whole layout will expand. Sort of like zoom, but… So, that’s something to consider as well. Where the layout could go beyond the viewport, you could get horizontal scroll bars as well there. So if you have an extra wide layout in ems, that can be an issue. Just bumping it up one notch or two notches could cause that sort of scrolling problem.

Paul: Yeah. So, the long and the short of this, is there’s no right answer, is there?

Paul: There’s no perfect solution here.

Dan Cederholm: Yeah, there really isn’t.

Dan Cederholm: I mean, like a lot of things in web design, there’s not… yeah, it sort of just depends on a case-by-case. I mean, people fall into sort of things that work for them, you know, like I use the “keyword/percentage” thing and that just seems to work. Other people like the em-based approach to text sizing. But neither one is really right. I think you’re correct in saying there is no real right answer at this point. It will be interesting to see how CSS evolves and affects the way we layout pages. Just the other day, I was looking at the CSS 3 grid layout draft.

Paul: Bleh!

Dan Cederholm: Yeah. (laughs) Which is pretty amazing. And maybe we’ll be able to use it in the next fifty years.

Paul: Well on that cheery thought, (Dan (laughing): Sorry) I’ll have to grapple with CCS 3.

Paul: Thank you so much for your time, Dan. I appreciate you coming and explaining the different options that are available.

Dan Cederholm: Ahh! Its my pleasure. Thanks for having me.

Question of the week

Pxels, ems, percentages… which do you use the most? Answer in the comments.

Show 96: Moll on Mobile

Posted in Classic shows on October 2, 2007 by Paul Boag

On this week’s show: Paul suggests some ways a client can pick which agencies to ask to tender. Marcus asks when is speculative design okay and Cameron Moll explaining how to get started on the mobile web.

Podcast: Download (31.0MB)

Download this show.

Launch our podcast player

News and events | When is speculative design okay? | Who to ask to tender? | Cameron Moll on the mobile web

News and events

Social Participation as a business tool

Back in 2006 I spoke at refresh06. One of the presentations I gave there has since proved a popular subject and I have been asked to speak on it again a number of times in various forms. It is on the subject of social participation and how to use it as a marketing and business tool. Social networks and communities are often seen as the domain of the teenage crowd with sites like YouTube and MySpace dominated by this demographic. However, community based applications are applicable to all audiences and can be a powerful tool for businesses.

After preparing the latest incarnation for a presentation I am giving at IBM, I thought I would do a run through (as I have only limited time). Discovering the new record feature in keynote I decided to record the whole thing and upload it for all to see. Hope it is useful.

Test your website for mobile compatibility

So this week we have Cameron Moll on the show talking about some of things covered in his new book “Mobile Web Design”. In his book he mentions an interesting site that I would like to pass on to you. It is a web application that allows you to test how well your website would appear on a mobile device. You simply enter your website address, wait while it calculates your results (it even gives a random mobile web development tip while you wait) and then view a complete breakdown of any issues with your site.

The report is distilled down into a single score but you can also see performance in each of the individual areas including:

Speed
Cost in terms of data access
Quality of code

and a whole host of miscellaneous tests. However, best of all is the fact that it also provides an emulation of what your site would look like on a whole host of mobile devices.

Laying out inline images

My next story tackles one of the mixed blessing of content management systems. Although it is great that content management systems allow clients to add content themselves they almost always fine a way of screw up the look of a site in the process. One way that they manage this is adding inline images. They are often required to add specific classes to images for them to be displayed correctly. Unsurprisingly the client sometimes fails to do this and the design becomes broken.

This week the List Apart website proposes one way to slightly reduce this risk. They use javascript to detect content images on a page and then apply different classes based on the width of the image in relation to its containing tag. In other words the Javascript detects whether the image is a full column, half column, or quarter column image and lays it out appropriately.

Its not the perfect solution and there are still ample other ways clients can screw up a design but it is a nice use of javascript that enhances a design without being mission critical. I think seeing this kind of use of Javascript and we should all be looking to use it for this type of thing.

10 Usability nightmares you should be aware of

My last story this week is another top ten list from the guys at smashing magazine (they do like their lists!). This one is a list of the top 10 usability mistakes and I have to say it is an entertaining list focusing on some big name sites. The list includes:

Hidden log-in links
Pop-ups for content presentation
Dragging instead of vertical navigation
Invisible links
Visual noise
Dead end
Content blocks layering upon each other
Dynamic navigation
Drop-Down Menus
Blinking images

Each mistake is explained in detail including some offending screenshots. A worthwhile read for us all.

Marcus’ bit: When is speculative design okay?

I have decided to talk about speculative design work this week because we have recently produced a couple of designs and, although we recommend that it should be avoided, sometimes you simply can’t.

Unpaid prospective work is the bane of all of graphic based agencies and freelancers. It’s also something we have looked at before, but it’s such a significant subject I think it’s a good idea to look at it again.

The worst case

Some ‘clients’, and I use the word loosely, are simply looking for free work. It seems that they think ‘art’ or ‘drawing’ is not real work and is something that only fools pay for. They usually ask for a number of different page designs and concepts and will often ask for revisions on delivered designs.

The project often ends up being dropped by ‘the board’ and then mysteriously, a few months later, something very similar to your design appears for all to see.
These people are effectively stealing from you. Don’t do it.

When is it ok?

If you take the line that we should never do unpaid work then the answer is ‘never’.

However, life simply isn’t like that so you need to make some choices. You could argue that as long as the client is genuine i.e. it’s a real project that someone will win and subsequently get paid for, then it’s ok. It’s a fair fight and the best design will win.

But, this isn’t just about getting paid.

Educate (how many times do I use that as a heading!)

Speculative design is a beauty contest. The whole point of the exercise is to impress the client. This can possibly be seen as taking a somewhat derogatory view of a client’s ability to make the distinction between a design for them versus a design for their users. But even for those that understand the distinction, I don’t think it is possible to separate ‘what I like’ from ‘what is right for our users’. If there is a choice, then people can’t help picking the one they like best.

Added to this, there’s the big issue of designing in the dark. Even if a client has supplied a detailed brief and they’re happy to chat on the phone, the guy pitching still doesn’t really know what the requirements are. The early part of any design project involves detailed discussions about an organisations USPs, target audience, brand values, site statistics, site goals, etc etc.
User interface design is a collaborative process between the agency and the client that goes through an iterative cycle based on user feedback. This simply doesn’t happen with speculative design work.
So, in summary, always have this conversation with prospective clients. I know for a fact that on one job, we won the work by doing so. The client saw it as the most professional and well thought through approach taken by the agencies pitching for the job.

However, sometimes you have to do it or you will jeopardise your chance of winning the work – but still have the conversation and ask whether or not producing an initial concept will adversely affect your bid.

Paul’s corner: Who to ask to tender?

With literally millions of web design companies worldwide where do you begin when trying to draw up a list of potential agencies? Who do you invite to tender?

Ask the expert: Cameron Moll on the mobile web

Paul: Okay so joining me today is Cameron Moll. Good to have you on the show Cameron.

Cameron Moll: Hey, thanks Paul.

Paul: I think this is your first time on Boagworld, is it not?

Cameron Moll: Yeah it is.

Paul: Ah that’s good stuff we alway like to get new people on instead of having the same old boring people on every time. Nice to get someone from the States as well. Which is good.

Cameron Moll: Yeah absolutely and I’m kinda bummed you didn’t pick me for your hundredth episode.

Paul: Well if your in London you can come to our hundredth episode and join in the show. Do you happen to be over then by any chance?

Cameron Moll: Uh, when’s that gonna be.

Paul: Uh, October 20.

Cameron Moll: Um, unfortunately not.

Paul: Argg.Shame, what a shame. Yeah, so we’re looking forward to our hundredth that should be fun. So I mean the reason we’ve got you on the show today is because you’ve just produced a book called Mobile Web Design. This you already know I’m sure. So we thought it would be good to get you on the show just to talk about some of the things that you kind of cover in the book, and give a bit of an introduction, um, to the world of developing mobile websites. And um the question I wanted to kick off with is in your book you dicsuss kind of four different responses to kind of mobile web. In other words four different approaches people could take when they start thinking about the subject of mobile web design. And I just wondered whether you could talk us through those four different approaches that people could use.

Cameron Moll: Yeah that’s probably a good place to start. Um, most of these are straight forward right. It’s I think a pretty simple thinking to understand how one would approach the mobile web. And uh, you know I produced these about two years ago as I was trying to understand how someone like myself, you, how we would make that leap over to mobile. The more I was researching it the more it became apparent that you know there is really these four methods, and what they boil down to is, uh, is this. So one, you essentially do nothing. Two, you reduce the number of images and styling therby reducing the file size, uh, the page weight and so on. Three, handheld style sheets and then four, mobile optimized or what some refer to as content adaptation. And uh, the breakdown is essentially this, if you’re going with that first approach your saying “You know what, I’m going to do nothing.” I’m either lazy. I assume that my users have devices that can support the content I already developed and uh, you know when you think about the mobile web obviously the question that comes to mind is what technology am I going to use? How am I developing content for mobile devices? And fourthly, most devices out on the market today will support well structured mark up out of the box. And so most of the devices being sold, most of the devices that people have in hand today are going to support your html markup. So a lot of user will take that approach, I guess developers that is, take the approach to say you know what, what I have developed it good enough. I’m going to push it out there. And with things like the iPhone and some of the higher end Nokia devices that are out on the market, most of those devices can support a full desktop experience. Right, so it’s this idea that I refered to as content zooming. And so with the iPhone I can see the full website. I can pinch or zoom in. With some of the Nokia devices and Oprea mini 4, I can have that same experience. And so the thinking with that first approach is, lets just leave the content as is and allow those higher end devices to access them.

Paul: Sure (thoughtfully like he is paying attention)

Cameron Moll: Uh, the second approach. This essentially takes the existing markup and content and says lets pull out the images. Lets pull out the styling and allow users to access that raw content. And the thinking there is we’ll reduce the file size. We’ll take out all those big images, that unnecessary styling. Most of the devices out on the market today, well I shouldn’t say most, but alot of them don’t support the styling that you and I are used to using on the desktop. So, the thinking here is just to pull all that out and allow the device to see the raw content. And after all people are after the content not necessarly the background images and colours and things like that. Now the third approach is perhaps right now the most controversial, and that being handheld style sheets. I mean these have been promoted as kind of this poster child of all things web. So any device whethe it be a mobile device, a car a watch or what have you should potentiall be able to take the same markup and with a style sheet specific for that device, again it might be a printer it might be a mobile device. Being able to attach specific style sheets that render the presentation differently for that given device. So the idea being, you know if I just attach a handheld style sheet to my markup. I don’t touch the markup. I don’t touch anything else. I just add that handheld style sheet then great it’s going to display it differently and so on. Of course there are drawbacks to this approach and I guess what I’m skipping here is there is drawbacks that I cover in detail in the book to.

Paul: Yeah (thoughtfully like he is paying attention)

Cameron Moll: To each of these approaches. They all have pros and cons. The biggest one here with handheld style sheets, cutting to the chase, is the fact that not all devices support it. I would guesstimate, I don’t have any exact figures, I don’t know that they exist. But is guesstimate only about half the devices out on the market will support handheld style sheets. And even of those that do the support is somewhat shotty. In that some of those devices will correctly obey a property such as “display none” but they’ll still in the background download the associated content with that. So if you’ve got a large image for example, and you attach to that “display none” it won’t show it but it’s still gonna download in the background that image or that content. So right now, at least, using handheld style sheets is a bit of a pipe dream. It’s just we’d love to be able to have the power to access those, that capability. But right now it’s just not all that feasible.

Paul: Hmm. (thoughtfully like he is paying attention)

Cameron Moll: Finally, on the fourth point, mobile optimized content. This is where you say “You know what. I understand that the environment of being mobile, this idea of context is different that it is when I am sitting at my desktop.” It’s different because I might be using one hand for data entry. I’ve got a much smaller screen and naturally I’m out on the street. I’m out driving or something along those lines. So we say what’s different about that experience, then sitting at one’s desktop. Proponents of this fourth approach essentially say, “You know what the other approaches, especially the do nothing approach completely ignore context.” And that is what is the user doing when they’re out walking. When they’re on the tube or the subway and so on. So this last approach says, okay the context of being mobile is different than anything else. People want to do things differently when they’re out and about. So we’re gonna reformat our content to cater to that experience. We’re gonna present and entirely different experience, and altered experience perhaps to that of the desktop that addresses the specific needs of being mobile. The arguement I make in the book, I guess coming full circle with these approaches is, I often get asked the question “Well what’s the best approach then Camerson?” I don’t know. And you ask 20 different people in this industry and you’ll get 20 different answers. Right now I think the most feasible approaches moving forward are the first approach, do nothing, and the last approach, to create mobile optimized content. The arguement being is one, you need to understand first of all the context of mobile users and therefore adapt that experience to that context. But at the same time you have alot of capable devices out on the market that may be able to render a full experience that users are used to elsewhere.

Paul: I mean you talked there about context and in particular the fact that peole might be using it one handed or whatever else. What are kind of the major differences that you are seeing between kind of a user experience designed for the desktop compared to user experience designed for the mobile device? How do they alter? What should we be doing differently?

Cameron Moll: Well I think that the key phrase here is mobile right. So Barbra Ballard, I quote her in the book, I love her quote that essentially says that when we’re talking about mobile it’s referencing the user not the device. And I think if we start there saying okay mobile is about the user not necessarily the device that they are using but the user. We then start to understand. Okay what is this user trying to do? Where are they? What are the limitations that they confront? And what are the oportunities that are provided through mobile that might not be provided elsewhere? So, it’s not about how do we make this experience similar to the desktop, but how is it different? How do we make it different and how do we welcome that different experience? So this idea of context, it’s this idea, you know, you have this great content, and we hear this phrase “content is king.” Well I argue that context is king. Cause when a user is mobile that content is of little value if you ignore the context in which it is being used. That inevitably leads to the question. What are the needs? What are the problems? What are the tasks that users may encounter in an environment of mobility. Then that leads to what are the opportunities that mobile provides for that given context. For our content, for our company that the PC doesn’t.

Paul: Yeah. I mean it’s a very interesting area because it’s almost somethign you need to address on almost an individual project basis. Looking at what content you’re working with, and working out what of that content is actually relvant to a mobile device and which isn’t. I mean you use an example about that somebody’s probably not going to want to look at your portfolio page on your personal website on a mobile device. It’s just not the right context. I guess that’s what your getting at there.

Cameron Moll: Right. You bring out a very interesting point and that is, let’s say a given company. Let’s say you and I as developers are working within an organization right. And we’ve got 20 projects that we manage. Something you said earlier keys to the point of looking at those 20 applications or websites and saying okay first of all which of these 20 apps might be relevant to someone being mobile. We cut that down to say 5 or 6 or whatever the number becomes. Within those applications or sites if we’re talking about existing content here within those applications or websites it’s those 5 or 6 as being perhaps suitable to mobility. We then look within those entire applications, so within a given application for example that might have 20 different tasks that a user does with that application. We then say okay which of those tasks are relevant to someone being mobile. So it’s this process, at least with existing content, looking at what are the applications we provide and within those applications what are the features that are going to be relevant. Now what that also ignores though is the fact that we’re not saying what are new opportunities? What applications have we not developed that might cater to mobile? Or within an application that we have developed, what opportunities such as location awareness might be provided to a user that we just haven’t even thought about it.

Paul: Yeah. I mean that whole about the fact that you get into this mentality that a mobile device is a cut down version of what you provide on the desktop. Actually, there are opportunities to do stuff on a mobile device that isn’t actually possible on a desktop and the location aware stuff is a good example of that I guess.

Cameron Moll: Right exactly.

Paul: Okay. So lets say as a web designer I’m beginning to get a bit excited about the mobile web. It’s obviously the way that things are going. You provide some excellent statistics in your book about take up levels of mobile devices and I’ve cribbed those and used them on the show before. So I think that there is a lot of people that are listenin to the show and going yeah this is something that I am really quite excited about. But where do I start? What kind of technical skills to I need to develop mobile websites? Is it enough to just know standards based design? Or is there other thins I need to know as well?

Cameron Moll: You know that’s a perfect question. If you look at where we are at now today it’s totally different then say 4 or 5 ago. I remember the same hype 4 or 5 years ago where people were saying mobiles coming. Developing websites for mobile devices is the next big thing. It just kind of died out. I think largely it was due to the fact that back then you still had to develop in WML, which is not a cryptic language. It actually provided a lot of clarity and unity to the mobile web environment 4 or 5 years ago. But at the same time it required that a lot of us had to learn a new language in addition to HTML or CSS. That’s no longer the case. So this second time around when we hear this hype about the mobile web, to me at least it feels much more real. Because now we have again, as I mentioned earlier, most devices out on the market, in fact nearly all of them support HTML, XHTML, and some level of CSS. So that means that you and I, we already know HTML. We already know CSS. We can take that knowledge and start developing content for mobile devices. Whereas 4 or 5 years ago we had to learn a new language just to get over that barrier of providing content. So the good news is, for the most part, really if you know standards based design and development techniques, you are 90% there. I think the other 10% is left to understanding context. So trying to understand what those limitations are with mobile devices and mobile users. And also looking at the opportunities. so again we’re talking about smaller screens, data entry. Those being limitations but at the same time location awarenes. Users just want to do things different. They’re out on the go, which can be a great advantage depending on what kind of content you’re providing. So I think the good news here, long story short, yes. You and I can just build on the knowledge we already have if we just start to understand just a little bit about what the users are doing.

Paul: I mean you say. It’s interesting some of the words you use. You say ‘for the most part.’ Or ‘some browers understand CSS.” And I think that’s the other big fear that people have when they start investigating the mobile web, is the huge plethora of different browsers and devices and all of this kind of stuff. And it seems like how the hell am I supposed to test on that. It’s impossible to test on every conceiveable device and every conceiveable browser. Where do you start? Where do you put your initial efforts?

Cameron Moll: You know when I first started talking about mobile I think I was a bit to pessimistic in that I would stand up, say in a conference or in an article, and say okay if you’re going to test for mobile devices be prepared to test on dozens of browsers and if you think 4 or 5 desktop browsers. And getting consistency right for those is difficult. Wait till you see the mobile web. I’m a bit more optimistic now. I hope the book at least comes across that way and when I talk about it at conferences it comes across that way. And the reason being is this. There are some pretty easy ways to deal with that challenge of consistency. Of testing for mobile devices. Of just developing content period for mobile devices right. So you and I, you use probably the web developer extension for Firefox. We both probably at some point used Opera. Both of those browsers with those extensions and plugins can, at least at the very start, render and initial small screen preview. They both have options to be able to do that. So starting at the very least we can develop, again because we’re developing in XHTML rather than WML, we can within the browser at least do a very quick test to see roughly how it’s going to show up for the user. After that, once you’ve got at least the markup structurally sound you can then jump over to emulators. Now there are plenty of online emulators. .moby provides one. Opera mini provides another and there’s several others out there. But also there’s desktop software that you can download to be able to emulate mobile devices. So then taking 5 or 10 mobile devices I can now test how my content’s going to render, and it’s very close to how it will actually render on the device. But you can’t stop there. The last step has to be actual devices. And I think this was what was insurmountable for me starting out as a mobile developer. At least a beginner saying oh gosh do I have to go out an purchase 100 devices to be able to test my content. Well fortunately you can get away with 5 or 10 devices. If you can get 5 or 10 devices that vary widely. By that I mean one being a very basic phone, another one being a PDA,another one being a popular device such as the Razor. If you can get 5 devices that vary widely, 5 to 10, the chances are that that content is going to render well for most devices out there on the market. That will get you close enough. A lot of that is based not just on my personal preference but on the case study that I offer in the book. That is the Yahoo! website for the FIFA world cup last year. They took that approach. They said you know it would be difficult to test on 100 devices but we think if we can get 5 to 10 widely varying devices that chances are our content is going to display well for a global audience. Which indeed it was for that particular website. So that’s the arguement that I’ve made. I’ve hear others make that arguement as well. And it’s not difficult to get that number of devices right. So you can probably get 3 to 5 from yourself, from friends, collegues and so on, on loan for a couple hours. If you’ve got a blog you can ask for volunteers to do testing. I’ve done that before and it works pretty well. And then finally anyone can hop on eBay and do a search for unlocked mobile phones and purchase phones for an affordable price and get you know 5 to 10 devices. That’s how I did it. You know I hopped on eBay. I bought about 5 phones that were unlocked and then I just take my SIM card and swap that around the phones when I am doing testing. So it’s really not that difficult once you’re done developing your content to make sure that it renders well for mobile devices.

Paul: What do you think about the kind of growing thing that we’re seeing at the moment about designing mobile sites for specific devices? Like the iPhone. Do you think that is a bad route to go?

Cameron Moll: You know I’m not going to say it’s a bad route to go. But I do question it’s integrity. Three years ago or so, when I bought, well this was a little bit after I bought my Treo, for example which is a feature rich PDA. There were all kinds of Treo specific sites that had been developed. So you had something like, lets just say you had something like ESPN.com/mobile/pda/treo would be the web address for that content. And it was formatted just for that device. When you think about all the devices that are out on the market you then realize that that becomes a big chore to try to develope content for X number of devices. Now I think with the iPhone at least you have that same experience being repeated. For me it feels in part like you know years ago when we hit up a website and it said best viewd with Internet Explorer 4.0 or something like that. You know that is what we’re seeing now with the iPhone. Granted the iPhone provides a much different experience and a much richer experience, which is great, but at the same time I worry that we are spending a lot of effort on a device that 1. Is not a market majority and 2. The device itself, the iPhone itself might change at some point in the future. I might have a larger screen. It may render content differently. Which then will require that we go back and rewrite that content yet again. So the arguement I’ve made is if it makes business sense to develop and iPhone optimized site well more power to you. Go for it. But I advocate as a default creating content that can render on as many devices as possible. Not necessarily just one device.

Paul: Cool. Thank you so much Cameron. That is incredibly useful. Where can people find out more about your book then?

Cameron Moll: The web address is mobilewebbook.com or they can find a link from my website cameronmoll.com.

Paul: Excellent. It’s a .PDF book that you can download instantly. Now waiting around for delivery at $19. The best thing of all is it’s nice a short. Just over 100 pages. Isn’t that right? Something like that?

Cameron Moll: That’s correct. And I’ll give your listeners a heads up that we’ve got a print version coming out in October to be announced soon.

Paul: Oh that’s excellent. So you’ve got the choice either way. Alright thank you very much for coming on the show Cameron. We’ll get you on again in the future no doubt.

Cameron Moll: Hey thanks Paul.

Show 91: God Bless America

Posted in Classic shows on August 28, 2007 by Paul Boag

On this week’s show: Paul gets to grips with the fact that the whole world isn’t British, Marcus explains how to deal with the client from hell and Julie Howell shares her expertise on accessibility

Podcast: Download (32.3MB)

Download this show.

Launch our podcast player

News and events | Dealing with the client from hell | The international web | Julie Howell on Accessibility

News and events

There are tons of news stories which have sprung up since I last recorded a show. In fact I have spent all morning wading through my RSS feeds. Unfortunately as always I can only squeeze a few into the show so you will have to check out my delicious feed for the rest.

Gerry McGovern on Intranets

The first story I wanted to mention is a couple of posts by Gerry McGovern concerning intranets. I am constantly getting emails asking for me to talk about intranets on the show but somehow have never gotten around to it. Fortunately Gerry has and if you are somebody who works on intranet sites then you should take the time to check them out.

The first, tackles the basic problem of how to get senior management engaged with the intranet. Gerry observes that generally speaking management don’t consider the intranet an important asset to the business and so the site never gets the backing it deserves and requires. In the post he suggests the solution is in how the intranet is portrayed to management and goes on to propose a better approach.

The second article Gerry has posted on intranets is a breakdown of a report on what staff really want from their intranet. Basically, staff overwhelmingly want a better organized intranet where they can quickly find people, policies and procedures, and forms.

Gerry goes on to look at the numbers behind this conclusion and links to a summary of the results in PDF form.

SXSW Panel Picker

Probably the biggest web design news since I have been away is that SXSW have launched their annual panel picker. For those of you who do not know, SXSW is the biggest web design conference of the year and takes place in Austin Texas. The massive event has democratized their selection of panels by opening it up for you to vote on.

By going to the SXSW panel picker you can browse over 680 suggested panels and vote for the ones you like the look of most. Although this sounds great in principle, as Andy Budd points out, it can turn into a popularity contest for the speakers and not necessarily an assessment of the quality of the subjects.

That said, I need you to all vote for the three panels I am associated with whether you think they are any good or not! I don’t even care if you are attending SXSW or not, just get on the site and vote. Hell, I have crafted this podcast lovingly for you every week for over two years the least you can do is vote for me :)

Seriously though, I am hoping to be on three panels (yes I know this overkill) and am really excited as it is my first year speaking at the conference.

My panels are:

Selling your web design services (which will hopefully be me and marcus doing something very much in the style of boagworld)
Running a Successful Web Design Business (which will be a panel made up of myself, Andy Clarke, Jon Hicks and Alun Rowe)
Social networking as a brand (made up of a massive panel including Jina Bolton, Steve Smith, Mark Norman Francis, Bryan Veloso, and Steve Ganz)

Hopefully at least one of these will come off.

HTML characters lookup

My next news item that I wanted to mention is a useful little tool which has recently been launched. I love this tool because it solves a really simple problem in a very easy to use way. Basically all it does is allow you to look up the HTML code you need to include ampersands, spaces or other characters which need to be escaped.

Let me explain the problem in case you don’t know what I am talking about. In HTML certain characters are reserved for use in the code. For example if you type an & it will interpret that as code and not text. It is therefore necessary to code up these characters in a special way. This online tool will tell you exactly how to do that.

You simply type in the character you wish to use and it returns the code you have to use. The site uses AJAX so results return incredibly quickly and if you are a mac user you can even download a dashboard widget.

Very useful indeed.

Moving from Print to the web

My final new story for today is some help for you print designers out there who are struggling to make the transition to the web. It is not always an easy process not just because of learning the technical side but also the mental shift involved.

Well, if that is you I would like to make two suggestions. First up, I would like to recommend an article I came across that takes you through the process of moving from print to the web. Its extremely good and makes some excellent recommendations about where to start.

Secondly, you might want to think about getting some training on CSS and XHTML. There are a number of courses out there but if you are UK based I would like to particularly recommend a beginners CSS course being run by Rachel Andrews and Drew McLellan. These guys are both experts in their field and they have a session coming up in October. Of course this course is ideal for anybody starting out with CSS, not just print designers!

Marcus’ bit: Dealing with the client from hell

Found this rather frustrated boagworlder (Cadore) in the forum – read on&#…;

Hello everyone, I was wondering if I could get some feedback on how to proceed with a problematic client.

I have a small business client who contacted me about a website. After talking with her she decided she wanted a basic two column layout with some navigation, she would provide language, etc. All was good, but here is the main problem: I design the header or banner, whichever you call it, and she says it looks great, she loves it. Then we move onto the navigation, she likes the navigation, but now the header seems “too busy” – take a step back. One thing that cracks me up is she said in emails she wants to have a large amount of leaves throughout the design. So, I incorporate leaves and she says she is thinking of not having any leaves at all now. It’s like she wants to do the design for me? Me designer – you client. Do you understand what I am saying, every step forward she wants to go a step back. Now she has a problem with the navigation, and the background image, that she has loved and hated 4 times already. Does anyone have any advice how to deal with a client like this. I was thinking of having her sign off on every little things, but this doesn’t make for a happy working relationship. Any advice on you have proceeded with a client like this would be appreciated.

I have talked loads about getting contracts in place, making sure everything’s agreed up front etc etc. But, agreeing on the look and feel of a site is not so easy to nail down before you start working on a project.

Certainly do all of the following before you start:

Find out who will be signing off the design.
Encourage the client to make this as small a group as possible.
Talk to these people. Obviously, talk to them about project specifics (see below) but try to get to know them a bit. Get an idea whether they’re conservative in their outlook, arty, whacky&#…; whatever. I remember seeing a panel at SXSW where a Swedish creative director said that he insisted on getting drunk with his clients before starting the job&#…; there is some wisdom in that!
As them for examples of favourite sites, particularly in their sector. Ask them why they like them.
Ask them for any other marketing material that they have, particularly items they like.
Discuss their brand (even if it’s just their logo) and the importance of continuity. Make sure that you are aware of any limitations.
Discuss colours.
Discuss imagery. Ask for imagery that you can use.
Discuss layout.
Finally, when you’re discussing these items, make sure that you provide examples, choices, potential solutions etc. Your client is almost certainly not an expert web designer therefore they need ideas from you; alternatives if you like.
However, you must explain why you’re recommending a particular idea. You need to communicate that you are an expert. This is actually the crux of the problem I think. Successful designers communicate their ideas before they ‘put pen to paper’ and provide solid reasoning for their choices afterwards.

Summarise all of your discussions in an email. Insist that they agree (or not) upon all of the points in the email before you start.
Ok, so that’s all done, now you have a choice:

Limited iterations

This is when you say to the client:

‘Ok, we will put together a design concept for you. You can come back to us with any modifications/comments once that will be incorporated into the design concept, anything after that is chargeable’.

I think this works well for small client, low budget work because everyone knows where they stand and possibly expectations are lower. Also, constantly going back over a design can affect the bottom line of a small project a lot more than a big technical project.

Averaging things out

The problem with this approach is that it can piss off your clients. You can end up looking petty or, even worse, you can end up making changes for free after the agreed cut off point (“it was only a 10 minute job”)&#…;

The approach that we have ended up with at Headscape takes the view that clients won’t pay time and materials for design concept work (they need a fixed price), so we have estimated what we think the average time spent on this work and charge that to all clients. This price is per concept but effectively allows unlimited mods to that concept. If a client wants multiple concepts then they pay accordingly.

Paul’s corner: The international web

Just before I went on holiday last week I posted an entry on boagworld. On my return I was gob-smacked to see it had generated the most comments of any post I have ever added to my site.

The whole thing started with an email I received from a first time listener to the show. He was complaining about a joke I made at the expense of my american listeners. Those who listen to the show regularly will know that this is not uncommon and this listener felt the comments were inappropriate. I posted a throw away line on twitter about this and accidently started a debate on political correctness and international differences. Overnight I found myself thinking a lot about the subject and this lead to a blog post on the international web.

I started by apologizing if my humor caused any offense but the main thrust of the article was looking at the broader issues of engaging with an international audience. I found the challenges of working across multiple cultures fascinating and felt it applied to all aspects of web design (not just podcasts).

However, unfortunately the majority of comments I received focused on the apology rather than the points I was trying to raise. I really appreciated the encouragement found in the comments but would like to come back to this issue of culture and cultural differences when designing for the web. This is a challenge that we all face and I want to cover the 5 points I mentioned in my blog post again for the sake of those of you who do not read my blog.

Ask the expert: Julie Howell on Accessibility

Paul:
Today I’ve been fortunate enough to grab a few minutes of Julie Howell’s time. Julie is the director of accessibility at a digital design agency called Fortune Cookie and is also the former digital policy development manager at the Royal National Institute for the Blind. She has also been involved, I believe if this is right Julie, that you were involved as the technical author for the PAS-78 or do you call it P.A.S 78?

Julie:
It’s pronounced PAS. Also RNIB is for Royal National Institute of Blind People if you want to…

Paul:
Oh, I missed out the People didn’t I. Oh well, there you go.

Julie:
Well it’s a recent change anyway.

Paul:
Ah, it’s to keep me guessing. Anyway good to have you on the show.

Julie:
Thank you.

Paul:
And obviously, unsurprisingly we have Julie in here to talk about accessibility [laughs]. You know, it’s kinda a no-brainer really. So I thought the best place to start is, well Julie, it strikes me, and I know a lot of the people that listen to our show, that the world of web accessibility seems to be a bit of a mess at the moment. We’ve kinda got WCAG2 that seems to be taking forever to come out. We’ve got now this thing called the WCAG Samurai, what’s all that about? They seem to be in competition with WCAG2. Then whenever you go into or if you are brave enough to venture onto an accessibility forum, they all seem to be fighting over tiny details and you are terrified to say anything incase you get jumped over. Do you think that accessibility is in trouble and if so, what can it do to dig itself out of the hole? What can the accessibility community do?

Julie:
You know, I don’t think there’s as big a problem as is being suggested. I think that what you have to keep in mind is perspective and context. There is heated debate on some areas of the web about accessibility, how accessibility will change or how the guidance might change moving forward in the great big wide world of web design. But in the much bigger world of commercial companies posting content on the web, there isn’t that concern. Everything seems quite stable. It doesn’t worry me at all that the techies or the geeks, and I mean that in the nicest possible way, are having heated debate because it’s really important. That’s how things change and improve and move forward. What is important is that we as people who are part of what I call the accessibility movement, who care about accessibility and who care about the lot of disabled people, keep presenting consistent guidance to the people who really can make the difference to disabled people. That’s businesses who are putting their services onto the web. The fact that there is heated debate about the technicalities I think is positive not negative.

Paul:
It strikes me that there is a little bit of confusion among the business community about what is actually expected of them. Things like the Disability Discrimination Act. They’re not sure how it should be interpreted in reality. Do you think there’s a case or there’s a need for more legal cases to be taken up so that the boundaries of accessibility are better defined?

Julie:
I think there’s a few things in there. I think that the greatest problem that we have, rather than it being arguments about the technicality, is actually a PR issue. We have guidance. We have the Web Content Accessibility Guidance and the other two separate guidance published by the Web Accessibility Initiative. We also have the document published by the British Standards Institution, PAS-78, and I guess we’ll talk about that a little bit more. What we lack is any consistent and well resourced drive to raise awareness of those documents among the community that needs to now about them and that is businesses. That for me is the missing part of the puzzle. Of course the guidelines will keep changing because the technology is changing at such a fast rate. So that I think is healthy. But what we really do need is more effort put into helping businesses understand the guidance that we have. Businesses should not be engaged in the technical discussions because that’s not where they fit into all of this. Businesses want clear, succinct, and that’s a huge problem I have with WCAG2, succinct guidance so that they just know what to… Businesses are saying to us, and I’m saying “us” as in the voluntary sector, the government, the Disability Rights Commission (DRC), that they care about the disabled peoples access and they want to do something about it. They just don’t know what to do. They are confused about which guidance to follow and to my mind, that is due to poor PR and not having any single government department or agency in the UK responsible for pushing the guidance. We’ve got individual organisations and voluntary organisations such as RNIB and RNID doing great work on their own but there’s no government force or business force behind it. Championing the guidance that we have and saying “Actually, there’s no confusion here. The guidance has been published, it is stable and this is all you have to do to follow it. Go forth and get on with it”.

Paul:
Let’s talk about PAS-78 a little bit in context of the business community and what they need to know. Correct me if I am wrong but my understanding of that document is that it was meant to be advice for people that run websites, website owners, to really get them up and running. Is that a fair assessment of what it was about?

Julie:
Erm… I’ve never heard it described that way.

Paul:
[Laughs]

Julie:
[Laughing] I would say that it’s there to provide clarity. We were concerned by the feedback that we were receiving that people in the business community were confused about the range of accessibility guidance that was available on the web. If you go to a search engine and type in “web accessibility”, you get all sorts of stuff back and some of it seems to be conflicting. So what we wanted to do with PAS-78 was pull all of the web accessibility guidance that’s produced by WAI, and also that’s produced by the software developers such as Adobe and others like Microsoft, all together into a single document that can be read within a couple of hours if you want to sit down and read it end to end or could easily be dipped in and out of, which was the definitive guide to the process of making a website accessible. The existing technical guidelines are not for business managers so we have written a document that is in a language that business managers can engage with, can digest, and puts everything together as a process. So it talks about guidelines and it doesn’t seek to create any new guidance. It points to guidance that’s already been published by WAI and others. But it also explains this is a process. This is what you do at this stage and it’s very important to involve disabled people at this stage; at this stage you should write an accessibility policy, later an accessibility statement. These are some of the questions you might want to ask when you are appointing a web design agency. So it puts all of that together in one document. That’s what we were seeking to do really. There’s a few words I used when I was launching it. Two of those words were harmonise and consolidate. It was nothing new. It was bringing together all of the guidance so there was absolutely no doubt. If anyone in the business says “I don’t understand what to do to make my site accessible”, PAS-78 is the only answer they need.

Paul:
OK. So where would they find and get hold of that?

Julie:
Well PAS-78 is free. Now it’s freely available because of the Disability Rights Commission. If you go to the DRC, the DRC have a licensing agreement with the British Standards Institution. So if you go to the Disability Rights Commission website you can download a PAS-78. It’s available in a variety of formats including accessible PDF. After all the medium is the message. The website address for that is http://www.drc-gb.org/pas.

Paul:
Well that brings us nicely onto WCAG then doesn’t it. What are your impressions are of WCAG2, how the WCAG Samurai stuff fits into that and what your current thinking is on all of this?

Julie:
Yeah, we live in interesting times as they say. I’ve been involved with WAI to a lesser and greater degree since 1995. A long time. I’m very conversant in the processes that are there. Now I’m a policy person and a disability rights campaigner. I’m not a coder. I’m not a geek, meant in the nicest possible way, and I’ve got no interest in become one either. I used to design websites but that was back in the day and it’s all very different now. What I care about is disabled people getting access to the web. I care that businesses are enable to make that happen. So as your listeners know WCAG2 has been in development for a really long time. That in itself troubles me because that makes it seem like disabled people are a huge nuisance and very, very difficult to cater for because an organisation catering in specialising to disabled peoples needs on the web takes many, many years to come up with guidance. I don’t like the message that puts out and I think that fuels some of that kind of confusion and misunderstanding and hence that’s why we did the PAS. It was so much quicker and it puts out, I feel, the right messages. People joke about it now don’t they. How long it’s taken WCAG2 to appear and that is because it’s subject to a very rigorous process of course but taking a long time. Now it’s in its latest drafting stages and I have to say… I’m sure you’ve read it or at least looked at it. I haven’t read it because I don’t have the time to read a document of that size. However, it’s not for me. It really is a technical manual now and as a technical manual, what is important is that those of you who are developing code and need to read the technical stuff are engaged by it, will read it and use it effectively. So that’s where the checking needs to be done. I think in the past where we’re getting some of these struggles at the moment, is because WCAG1 was a document for all. So you could read it if you were a developer and you could also have a good read of it if you weren’t and get something out of it. Looking at it now, it looks like a technical manual. Then, for me, it comes back down to PR. If it’s a technical manual then they to call it such and make it clear. If you put that on the desk of any business director general / CEO and well you can imagine the reception that you’ll get, who wants to read that? That said WAI always produce very comprehensive guides to their guidelines and curricular to help the various groups to apply the guidance correctly. They will do so in this case and again for me it’s down to PR. It needs to be made very clear to each individual group, developers, business owners, advocates as well, which guidance is for which group so that we don’t get people belly aching “Oh this is too long”, “I don’t have time to read a document of 100+ pages”.

Paul:
What hadn’t occurred to me there until you just said it, the fact that this applies not just to people like Adobe and Microsoft but also applies to me potentially. If I’m developing a web application that enables users to contribute and upload content then in effect I’m being an equivalent of a Facebook or a Myspace and I need to be aware of those kinds of accessibility issues there are well. It’s quite interesting.

Julie:
It is and then it gets more interesting when you look at it in the context of the law in this country. We have the Disability Discrimination Act and that puts, and I choose these words very carefully, a legal duty on “service providers”. Now software developers are not covered by the DDA. However, the line is blurring. If a website is inaccessible, say a blind person goes to a site to do some shopping and it’s inaccessible, who’s responsibility is it? Whose legal duty is it that the site is accessible? Well it’s the owner of the business because it’s their service. But there’s an argument that the developer who coded the site has aided and abetted the discrimination. But we don’t have any case laws so this is all theoretical until we do get some case laws to back up what were saying. However software developers are not subject to the DDA. There’s a blurry of the lines, in my opinion, between a service provider and a software developer. But if I was to take an educated guess, if a disabled person experienced an instance of discrimination as defined under the Disability Discrimination Act and that happened because they tried to utilise a server via somebody’s page on a social networking site, who would be responsible? That would be very interesting. We also have the DDA, the Disability Discrimination Act. I have Multiple sclerosis. Everybody knows this. I’m very open about it and it really informs my work. Being somebody who stands to benefit, stands to live my life as I choose to and prosper because of the DDA, I can tell you from this side of the fence that the DDA is a very weak piece of legislation as it is. We don’t to date have any case law regarding websites but even if there was a case, it would take quite a number of cases to have any useful body of guidance other than what we already have and know as is published in PAS-78. Really that is your best guide. So yeah, interesting times that we live in. What I would say is that would hope that anybody who is responsible for social networking has a social conscience and cares very much about the ability of every member of society to be able to use the content, to both access it and create it. Unfortunately, disabled people don’t always figure in the planning process when people are putting together solutions and this is again where the web accessibility needs to keep on ramping up that awareness effort to get everybody to understand and to be thinking about disabled people at the earliest part of the conceptual process for new technology. It’s an issue we’ve always had that with web accessibility we’re always running to catch up because new ideas that come to market on the web really, really quickly and the trick to it, in my opinion, is getting close to the innovators, throwing in their face and keep on reminding them. Today we’re talking about accessibility of social networks, tomorrow it will be something else but I’ve got no idea what it’ll be.

Paul:
OK. So just before we wrap up let’s bring it back down to the more mundane day to day level. There will be a lot of people that are listening to this podcast and listening to our conversation thinking “Wow! This seems really overwhelming. It all seems very complicated. There seems to be talking about us having to get disabled people in to do testing, that sounds very expensive. There are legal obligations here and that sounds very scary. There are these various technical guidelines and they all seem very confusing.” Just to those people that are web sites owners that have perhaps buried their head in the sand so far about accessibility. What little step would you suggest to them? Just to get them going. Just to make the first tentative steps into the world of making their site more accessible.

Julie:
The first document to read is PAS-78 which is free of charge. It’s only about 60 pages and that’s in large print. It really is quite an easy read. We made sure of that when we wrote it. PAS-78 sets it all out in plain language. It’s very much written with the business audience in mind. I’d also offer some encouragement. Have a look at some of the case studies, you can easily find them on the web, of big companies that have applied accessibility and are profiting from it. An example being Legal & General, the one that I talk about a lot at the moment. Legal & General had a 300% increase in the take-up of one of their financial products via their website after they made the site more accessible.

Paul:
Wow!

Julie:
300% in a matter of months. You wouldn’t dare set that as a business target. It astonished me and I’ve long believed in this stuff. 300% is amazing. There’s also been a lot written about Tesco. Tesco take millions more in extra business away from their competitors because they’ve made their site more accessible. Accessibility is a good news story. There is money to be had through accessibility. If you make your website content available to the biggest possible audience that you’re tapping into a much bigger pot of money. Disabled people as a group in the UK alone are estimated to have an annual spending power in the region of £85 billion! An incredible amount of money that someone needs to exploit, to capitalise one. Disable people are very happy to be marketed to. Perhaps more so than other groups because disabled people, in particular blind people, are not exposed to advertising and therefore not exposed to a lot of choice that those of us that can see take for granted. Accessible sites are also interoperable sites. They work well on different platforms. If you make your site accessible for a PC you’re making it accessible for many other technologies including a mobile phone which people are using increasingly more now in the UK. Yes, there is a legal imperative as well. I wouldn’t be afraid of that though. There’s a long process involved in that. The DDA to safeguard disabled people’s rights to participate in society. Now indeed when a disabled people feels and finds that they have been discriminated against because of the way a web service is presented to them, of course they are going to feel angry and upset. I have long said I have never understood why I should be able to use a product or service to buy some tickets online because I can see but my blind friend can’t. To me that’s completely unacceptable and unnecessary discrimination. However it’s not a case of “Oh I’m not happy” and we’re all in court. There’s a process there of conciliation. The DRC is involved in that process or it can be, as well as a number of disability organisations because what we want is not to take anybody to the cleaners. It’s to make the web more accessible. The key to that is my mind is dialog. When I used to work at RNIB, if a blind person contacted me having found a website they couldn’t use and it was one of the bigger ones. This is what happened with Tesco. 40 blind people got onto us saying they couldn’t use Tesco and they wanted a legal case to be taken. This was tremendous because it’s alerted Tesco to this issue and it meant that we were able to start a dialogue, the result of which is hundreds if not thousands of blind people are now able to do online shopping for their groceries and delivered to their home which is wonderful. Tesco is not unhappy because it’s bringing in a lot more money through that channel where it wasn’t bringing in any previously from disabled people because it was inaccessible. What we are trying to achieve here is sustained change that will see disabled people included in society to the degree that it would seem outrageous and ridiculous not to do so. Big changes happen. I never thought I’d see smoking banned in public places. I can’t believe it. My goodness if we can do that as a society we can change the way we behave towards disabled people, stop belly aching about the issues and talk to each other about working towards solutions. I’m optimistic that in 20 years we’ll see disabled people much more included in everything that we are all doing now to keep the debate about disabled people and accessibility alive, contributing to a brighter future for disabled people. We should just keep on doing what we are all doing.

Paul:
Excellent. Thank you so much Julie for taking time to come in and talk about that. It was really interesting. I hope to get you back in again in the future before too long.

Show 90: Digg

Posted in Classic shows on August 14, 2007 by Paul Boag

On this week’s show: Marcus abandons Paul to go on holiday. Paul talks about competitive analysis and does an in-depth interview with Daniel Burka, the creative director at digg.com.

Podcast: Download (22.1MB)

Download this show.

Launch our podcast player

News and events | Daniel Burka talks about Digg | Competitive analysis

Hello? Is anybody there? I am so lonely, nobody to talk to, nobody to rant at, nobody to take the piss of! Your listening to boagworld.com, the podcast for all those involved in designing, developing and running websites on a daily basis. My name is Paul Boag and this week, I am sad and alone as Marcus is away on Holiday (or should I say vacation?).

I have to say it is not the same without him. Of course on the upside in many ways its a lot better. Less waffle, no interruptions, no skype problems and you get to hear my undiluted genius. So thats okay then :)

Because we don’t have Marcus around this week, todays show will be a little different. For a start Marcus wont be saying much, which should make the show shorter. However, in his place we have an extended interview with Daniel Burka the creative director at the social news website Digg. We cover loads of stuff from the difference in designing for social networking sites to working with AJAX and designing for the iPhone.

I will also be doing my segment as normal. This week I will be providing a quick and dirty introduction to competitive analysis. We will be looking at what you can learn from your competitions websites and how you go about extracting the maximum amount of information.

But before we can get into all that good stuff we first need to look at what has been happening in the world of web design over the last week.

News and events

Eric Meyer tries to prevent history repeating itself

First up in the news segment of the show today is a passionate call to action by Eric Meyer. Like myself, Eric has been working in the web for a very long time and is all too familiar with the problems of the past. He is a veteran of the browser wars (how dramatic does that sound!) and remembers the many problems that period caused.

During that time many web designers simply gave up trying to support multiple browsers and instead displayed the now famous message…

“Your browser is not compatible and must be upgraded”

It is therefore particularly disturbing when we thought those days are over to see the return of a similar message. As Eric points out in his post, those types of messages are returning in the form of…

“This site is for iPhone users only.”

As Eric says: Stop it! Stop it right now. He is absolutely right. There is no reason whatsoever for shutting out users from viewing iPhone optimized pages. Sure they might not look as good on a non iphone browser but other than that they should work fine on a compliant browser. To be honest, even if they don’t, that is still no reason to block non iphone users. If I choose to look at an iphone site on my Windows mobile device or even on my desktop browser, I am not going to expect it to look perfect. However, I could have all kinds of reasons for wanting to do it from wanting to check out the functionality to using an alternative mobile browser that is just as capable of displaying the content.

In Short, Eric argues (and I whole heartedly agree) that the “best viewed in…” approach to web design is a fools errand. Whether it is the iphone or something else, make sure you avoid that road at all costs.

6 Keys to Understanding Modern CSS-based Layouts

Talking about best practice, Jonathan Snook has posted a helpful article for those of you still struggling to move across to modern CSS-based layout.

As Jonathan says in his post…

Much of CSS is pretty straightforward and, I suspect, quite easy for most people to grasp. There’s font styles, margin, padding, color and what not. But there’s a wall that people will run into… that point where a number of key elements need to come together to create a solid CSS-based layout that is consistent cross-browser.

Jonathan addresses this challenge by talking about 6 key principles that will help you get over this hump. He talks about; the box model, floating columns, sizing with ems, image replacement, floated navigation and sprites.

Its an interesting list although I am not entirely sure I would include the same items. For example there is no mention of HasLayout or IE conditional comments. However, Jonathan does say it is just his take on things and encourages people to add suggestions in the comments so they are definitely worth reading too.

How to mix fonts

So you might be listening to this feeling smug about your CSS skills but how are you with typography? Working with type is a challenging area and one that is very easy to get wrong. That is especially true when trying to combine multiple fonts together in an effective way.

Fortunately, David who listens to the show, has sent me a link to a cheat sheet on mixing typefaces. Not only does it provide specific examples of typefaces that work well together, it also gives you some basic information on typography.

I am a great fan of cheat sheets and have a number pinned to my wall including my much loved microformats cheat sheet. So, if you are looking for some advice on typography add this to your collection.

Making money through forums

My final news story for this week’s show comes off of the back of a story knocking around here in the UK. A number of large companies have pulled their advertising off of Facebook following the discovery that those ads were appearing on the profile of the BNP (a pseudo- fascist political party in the UK). These companies were unhappy that their brands being associated with the organisation.

This Facebook story is indicative of a wider problem that advertisers seem to be having with social networking sites and forums in particular. So the question then arises, can you make money from a social networking site?

For most of us this is not a question we have to deal with. Most of us don’t run social networking websites. However, many of us do run forums and we are looking to make a bit of extra cash from them.

If that is you then you might want to check out “Can forums still make money?” on sitepoint. This post suggests a load of ways you can improve your return on your forum and make some cash to cover hosting costs. The post is very realistic suggesting that the vast majority of us are not going to get rich from our forums. However, it might help pay for your cleaner (which is what I spend my Adsense revenue on!) and so it is worthy of your attention.

As a slight aside before I wrap up the news segment of today’s show, the article also links to some useful tips from Google about maximizing your return from Google Adsense, so you might want to check that out too.

Talking of social networking websites, that brings me on nicely to my interview with Daniel Burka from Digg…

Daniel Burka talks about Digg

Paul: Okay. So joining me today is Daniel Burka the lead designer/creative director/God of all things user interface at Digg.com. Is that a fair way to describe you Daniel?

Daniel: That was a very polite introduction. Thank you very much.

Paul: Well, it is always good to butter up the guests at the beginning…

Daniel: [laughs]

Paul: I find it goes down better that way. [laughs] So Daniel, I thought that it would be great to get you on the show, simply because you seemed to have worked so extensively with web projects centered very much on social participation and web applications, you know, and various other Web 2.0 buzzwords. Obviously Digg.com is a good example of that. And a lot of listeners of this show are still working on content heavy brochure-ware type sites. But, they seem to be really interested in more interactive elements to their site. And so we thought, let’s get an expert on the show that seems to specialize in this area. So, here is my first question Daniel. What do you see as being the main differences between designing and social networking sites, compared to more traditional content heavy sites that I am sure you have worked on in previous lives, so to speak?

Daniel: Oh yeah, I mean absolutely. I worked on those kinds of sites in the past. The big difference with something like Digg is that all of the content on the site, pretty much, is provided by users and so we're building conduits as frequently as we can where people can provide their input, provide content you know foster discussion, these kinds of things so I guess wherever possible we're not only designing the technically areas that they can do it but focusing the design on encouraging them to participate.

Paul: So how to you do that? How do you encourage someone to participate in using kind of design tools and design approaches?

Daniel: Right. I guess the big thing is to make it obvious that other users have provided content to the site. So, making it clear that the Digg count went up because other people you know dug the story. You know, showing which users submitted certain things or which user made a comment. You know that indicates, Oh okay. Other people, like me, have participated and that might be something I might be able to do too.

Paul: So how did you deal with the kind of early days before Digg had really taken off? Where perhaps you had less content than you do now and you kind of want to give the impression that there is loads going on, when perhaps here isn't?

Daniel: Right. I guess by the time I got involved in Digg which is about 4-5 months after it had started. So Kevin and Owen originally developed the site.

Paul: Oh okay

Daniel: And then they hired the company that I work with in Canada. They hired us to come in and basically do a design review and redesign of the site and that was the primary focus of the redesign was to look and say, Okay, what is this site about? And what the site is about providing input and so the original design which was more definitely designed from an engineer's perspective. It had all of that content, it had all of the facts and the bits and the place to Digg something, but it wasn't very clear at all what you should do or why you should do it.

Paul: Hmmm.

Daniel: And so, you-know probably the most interesting thing I have ever done on Digg was to take the Digg count, to make it really big and stick it on the left and stick a really explicit Digg It button under it. So, I mean that's clearing indicating X number of people already participated.

Paul: Yeah.

Daniel: And if you want to participate hit the big button.

Paul: Yeah. The kind of putting right in front of peoples face where they can't possibly miss it, so to speak.

Daniel: Right. I mean that is the entire purpose of the website is to, you know, say you like something.

Paul: So what other kind of things did you implement in those early days when you came in and started redesigning the site?

Daniel: The original focus, I actually thought this was a kind of interesting approach to take. Steven and I were looking at the site and trying to determine that. It already, in some ways, had a fairly large scope to the website. So we were trying to determine where do we get started. Often that is redesign the look of the site or redesign the home page. We looked at it and what is the most important thing here and the story format, I think, was probably the most important thing about Digg. And so we looked at each individual story in the list. There is a whole row of them on the homepage. We got about 15 on there now. And kind of a singled one of those and dissected it and said, What is important about a story? Why did the user submit it? Why is another person going to be interested in it? How do I encourage them to participate into that story? And so, that story format counts for a few different iterations since we started.

Paul: Hmmm.

Daniel: I think that being the primary focus of ours.

Paul: I mean what about the kind of more rich elements that you started to introduce? Where there is a lot less page refreshes that perhaps there once was and you kind of changed the way the people interacted with the site by introducing AJAX and things like that. I mean was that a big shift? What kind of thinking went into that process?

Daniel: Absolutely. I mean that is critical to Digg's success. Owen and Kevin had already started playing around with AJAX and this was before anybody like Jesse James Garrett that coined the phrase, AJAX. So, we were still calling it Asynchronous Javascript and XML request. Thank God someone has shortened that. And the fact that you are requiring mass participation to make something interesting would be entirely stymied if we had forced a page reload every single time a person wanted to participate.

Paul: Ummm.

Daniel: So we are using that all over the place. The Digg It button is the one real obvious place. And then you know especially in the comment system. There are various other areas where we're basically allowing you to have a really low-threshold of participation. No long page loads. Immediate reaction that what I did I got a reaction back from that, so I get that positive feeling.

Paul: So how does that kind of process work within Digg? I mean are you actually involved in coding the AJAX elements or do you just do the user interface? How do those kinds of accountabilities split up?

Daniel: Right. I guess we've got a really good balance I think between the development and the UI design. We are really tightly integrated with the different teams. And we are getting big enough now that we can actually speak about them as teams. So generally the flow at Digg starts with it's great we have a really design focused process here that Kevin will come up with an idea and then he and I will bounce the idea back and forth usually and figure out what the pros and cons are and then kind of rough out the design aspect. And then, basically take it from the conceptual stage code it statically and then work with the developers in terms of coding the functionality into it. So I don't do a lot of PHP or very much Javascript, but I provide with them XHTML and CSS and obviously the images and work with them implementing the basic flows.

Paul: I think a lot of the impression I get is a lot of organizations is still struggling to work out whose responsibility is the AJAX elements. It's kind of client side stuff that is very user-interface oriented. So should it be a designer job or is it kind of so intrinsic in the kind of connecting to the database and pulling out the content and that kind of thing which is actually a developer's job? It's quite interesting to hear how different people do it.

Daniel: Right. We probably fall into the developer's side of things. You know, it is submitting content to the database which is not horribly different than a normal form submitting to the database.

Paul: Yeah.

Daniel: So that is probably how we line it up.

Paul: Yeah. You guys seem to be doing some interesting things at the moment. One of the things that I imagine is particularly challenging is that you got a tech-savvy audience which is where Digg started. But you're constantly at the moment in this process of broadening that audience out to be more of a mainstream audience. And I'm just interested from a kind of design point of view, and user-interface point of view, what challenges that has presented you as far as shifting that audience. You know kind of in-mid process if you want. Most websites have a fairly good idea of who their target audience is upfront. But you are having to adapt that as the site evolves and I imagine that must be tricky at times.

Daniel: Oh, absolutely. I mean we started off as you said as very a tech-heavy site at about this time last year. I guess just over a year ago we broadened out very explicitly by introducing other content areas to the website. As we grow, and as a less tech-savvy audience comes in, there definitely is a real dichotomy between the perceived power-user who understands the very complex form type systems versus people who barely used a comment system on a weblog. On different areas of the site that level of experience I guess really comes to the fore. Although, I think I really take inspiration from the FireFox Project in that regard – particularly in Van Gudgers response. He is one of lead engineers on the FireFox Project. One of his best qualities being saying No! during the FireFox development and a lot of power-users perceive that they want all of these options at their finger tips. They want a hundred different options, if there are a hundred possibilities. Where as, in reality, having a simple system actually works better for both the power-user and the relative novice. I think the correlation between what happened with the Mozilla Suite, which was the previous iteration before FireFox which had a lot of different features and a lot of different buttons and customizability, versus FireFox which is really the torn-down simple browser. Which really ended up serving both audiences better.

Paul: So have you had the kind of guts to take functionality away or are you more kind of hiding it away so that it is still accessible to the power-user wants to go and get it?

Daniel: Well that is definitely the balance that we try and make. I think hiding the functionality is actually I was just reading a book a friend lent me. John Maeda’s book The Laws of Simplicity and he covers this subject. I think that it is really interesting that you can hide functionality as long as it doesn't feel intimidating and as long as you are not obscuring the functionality. I think you can actually, quite successfully, create a simple site by tucking functionally under the right areas, I guess.

Paul: That struck me. This whole idea of dealing with different types of audiences is a very challenging area. You have been at Digg for a while now, what has been the most challenging aspect from your point of view?

Daniel: Well, I think managing user feedback is definitely one of the big points of working at Digg. It is very intimidating working on a site where, every time you want something new, you have about 2 million people seeing it the next day and giving you their feedback on it. It is fantastic! It is really inspiring and exciting – and at the same time horribly intimidating. It is hard not to get frozen-up when you are about to launch something in two days and you kind of have to brace for the criticism because you know that people are going to be critical. And I mean that in the positive sense. They are going to critique what you have done. And so, being able to basically listen to a wide range of opinions and make sure that you are listening to everyone. But, you don't necessarily do what everyone says because there are obviously people with conflicting opinions and there are people who have very specific interests that may or may not be reflected by other people. I think managing those expectations that people want to know that you are listening to them and they want to see their suggestions reflected in what you are doing. Balancing those types of expectations is a really challenging part of the job.

Paul: So how do you go about that? How do go about deciding which suggestions you are going to implement and which you are not? Do you have some kind of process for that?

Daniel: I'm not sure if it is horribly formalized. I think the first and really important thing that we've learned at Digg, and I have learned on other projects being worked on, is taking a really deep breath. People will immediately ask for feedback on something, the minute you launch it

Paul: Yeah.

Daniel: They will ask for change. So don't make a change for the first week, unless they point out obviously drastic problems that you didn't anticipate. Take a deep breath. Let people give their feedback. Let them get some experience with the change because people are adverse to change generally. Their first reaction is going to be, Well I was familiar with it the other way, now it is different and I don't feel comfortable with that. And so, you will get a lot of feedback in that regard. And then carefully go through and filter and look for themes of feedback from different people. Try to determine why they were giving that feedback. And then iterate from there. I think that iterative process is so important.

Paul: One of the things that I think everyone has noticed recently about Digg, is that you released this iPhone interface. Everybody is going on about the iPhone endlessly and I am hugely jealous that we don't have it over here in the UK. And so, I am obviously bitter and twisted about it.

Daniel: [laughs]

Paul: But, putting that aside there is this plethora of iPhone applications coming out and Digg is one of the people who have done it. Were you involved in that putting it together?

Daniel: Yeah, absolutely. Joe, who is one of our developers, kind of came over and he was talking about it and was thinking it would be a great idea. And we both kind of got excited and pumped the whole thing out over our weekends.

Paul: Ahhh.

Daniel: Big props to Joe Hewett, who is not the Joe who works here, but Joe Hewett has made this great framework basically to start developing for iPhone applications in Safari.

Paul: Ahhh.

Daniel: He actually released a prototype of it on Friday afternoon. I think? And we started off from there and started developing. That is what does the sliding effects in our interface.

Paul: Okay.

Daniel: And we kind of took what he had done and I think we launched on a Tuesday the next week and on Wednesday Joe had already refined it and made into a kind of framework more people could use. So it was very useful to us.

Paul: So how do you feel about that, because that is a very different interface to be developing? It is much more controlled. You know the browser you are aimed at. You know the screen size. Was it a pleasant experience?

Daniel: Oh, absolutely. It was really really fun. I mean, there were a few things that were really fun about it. One, you are absolutely in that controlled environment. I mean people aren't resizing there fonts. You have a controlled number of fonts. You know the resolution. You can accommodate for when you flip the screen and it goes to wide-mode. And plus you are working with a rendering engine that doesn't suck.

Paul: [laughs]

Daniel: So it is really fun. [laughs] I mean you can even use advanced Webkit only type rounded corners and all kinds of fun stuff like that so, that part of it is really liberating. I can just imagine if all web design was like that. You know if all browsers were actually as standards compliant as they think they are. So that was fun. But, I think the most interesting thing is that you're working with an input device that is this big-fat-honking finger. And so, everything you do you have to be thinking about that. I think it will be interesting to see who succeeds at developing applications like that. But, you really have to think about pairing things down.

Paul: Yeah.

Daniel: When you are clicking with a finger there is no way you can have four or five buttons in a row and expect the person to be able to pick one out when they are sitting on a bouncing bus, with this phone in their hand. And so, buttons have to be really big. The Digg button on the source pages for instance is about two and a half times bigger than one on the normal site. And the links, we considered two different links. One to go to the source and one to go to what we call the Permalink page, the story page, of that particular item. But you know, even having just two buttons per story was much too difficult on the iPhone so we just have one you just can't miss which is a big finger button and it slides over and you get the story.

Paul: Yeah. Do you think you will be doing kind of more with Digg where you are kind of delivering the content, through other various mechanisms; such as the iPhone? I mean, could you imagine doing stuff with desktop applications like using AIR or anything else? Is that an area that you think you would get into?

Daniel: I think the really exciting thing is that we are finally getting a proper API out there. And so, I guess we launched the API maybe two or three months ago. Maybe longer than that, I forget, but I think it will be really interesting to see you know if a desktop experience of dig is really valuable somebody is going to pick up that project and go with it.

Paul: Sure.

Daniel: And they'll develop it on the API. So, I'm not sure if explicitly if a desktop application will be great, but I could see it having certain benefits and maybe toying around with the idea ñ for sure.

Paul: Is there something personally you are interested in as a web designer doing, you know, it's a different medium again isn't it? You're going from a browser based environment to a desktop environment. Is that something that interests you personally?

Daniel: Oh, absolutely. I think it is interesting that those lines are really blurring. I mean, AIRs is that first salvo, in that regard, you really are to a large degree developing a web application. You can develop it in HTML and CSS with basically the same skills it takes to make an iPhone application, or a basic website, you can build an AIR app. That is pretty exciting. I think that once that platform matures, it could open up a whole range of things.

Paul: From a personal perspective, what is the area of your job that you most enjoy?

Daniel: I really enjoy trying to make things easy for people. Sometimes is really irks me if Kevin describes my job as making things pretty.

Paul: [laughs]

Daniel: I think it is such a minor part of design. You know it is an interesting one. But I think sitting down trying to determine, when you are looking at a fairly complex system you are trying to build, and trying to figure out how to not be complex. What to takeaway, how to design something so that it feels simple by putting the really important things upfront. And throwing it by some users and watching them how they do it. I think it is really exciting to see somebody participate in something that is under the hood really complex, but which they have fun and they feel that they are participating. And they do not put a lot of thought into what they are doing, they are trying to achieve what they came to do.

Paul: What about the fact that you kind of have been working on Digg for a prolonged period of time and it is that one site you have been working on continually? I guess because I work for a web design agency where I have a series of clients back-to-back and I am doing different things the whole time. Sometimes it strikes me that we're working on a project for a prolonged time is both a blessing and a curse. I just kind of wondered, what you think? Do you really enjoy being able to spend time digging into that one area?

Daniel: That is a very interesting point, because I also come from the web design company background where I basically would do a different project every month. And until December I was still fairly heavily involved in the day-to-day affairs of my previous company, so it has been a reasonably new experience for me

Paul: Oh I didn't know that.

Daniel: To be working solely on one site, with Pounce on the side. [laughs]

Paul: Yeah. [laughs]

Daniel: Another site I have been working on. So this is really very interesting. Absolutely, there are so many things fantastic about it. It is really fun to be able to go into great detail and have the time to go back into something you designed previously, and to alter it. It is not necessarily that you made a mistake, but a month later you suddenly realize that a big improvement to that would be if I did X. And so you actually have the opportunity to go back and do those kinds of things. Where as I am sure, if you were working with a client, it has happened before that you know six months later you see something you say it is obvious to me now but it is kind of out of your control. The contract is over. You know

Paul: Yeah

Daniel: They're working with a different firm. There are all kinds of things like that. And so, working on something as big as Digg it is really fun too. Within Digg there are lots of different projects. There are different pages. There are new things we are working on. And so you kind of I guess segment them into kind of different projects you can go around in a circle and come back to later on.

Paul: Do you ever envision a day where you throw out the existing user interface and apply a new one? Or do you think it will always be a kind of evolving iterative process?

Daniel: Oh, I think an iterative process for sure.

Paul: Yeah.

Daniel: I don't want to second guess what is possible in the future. We may have some brilliant idea or new technology that blows our minds. But, I think there is no reason to throw out something that is working pretty well. I think there is a kind a rush sometimes to you know, to start from scratch that real desire to start from scratch sometimes. But something like Digg, I mean it has changed fairly significantly over the last two years, but I don't know if too many people notice

Paul: Yeah.

Daniel: Other than a few big pushes we made, that things had changed much. I think that is really healthy that people become familiar with systems. They learn how to interact with them. And to really shake them up, you really better have a damn good reason to do it.

Paul: Yeah. Okay so last question then before we finish up. Is there any stuff that you are working on with Digg that you are allowed to talk about [laughs] because obviously there are things you are not allowed to talk about.

Daniel: Right.

Paul: But the stuff that you are allowed to talk about, what is really exciting you and what are you really enjoying getting into at the moment?

Daniel: Oh, there is a bunch of things. I think I am allowed to talk about that Kevin mentioned the other day that we are working on the images section.

Paul: Cool.

Daniel: So we are going to do right now you can do news and videos. And we are pretty confident we are going to get into images as well. And so we are working on a couple of projects to kind of lay the framework for doing that. So, some people think it is as easy as adding a section

Paul: Yeah.

Daniel: And putting a title on it. But if we want to do that, we want to do it the right way. And lay the ground work first. I am working a couple of things I cannot go into great detail unfortunately there so much secrecy here that we can't

Paul: [laughs]

Daniel: Layout too much of what we are up to. But, I am really excited that we are headed in this direction.

Paul: Yeah. The trouble is that you guys get ripped off so quickly, don't you, that you need to keep things quite.

Daniel: Well. I think it is a combination of problems. One is that we are obviously concerned with people duplicating our features and the other one is that we want to be careful setting expectations. Because if we say we are going to do something, we really want to do it.

Paul: Yeah.

Daniel: And I think people will get disappointed if we say, In two months we are going to launch such-and-such. and you know lot's of stuff happens in two months. And unfortunately if that had to get pushed back, and that two months was a totally random date that I pulled out of my head

Paul: [laughs]

Daniel: [laughs]

Paul: See know, we all believe that it is all going to happen in two months.

Daniel: Shoot! [laughs]

Paul: [laughs]

Daniel: [laughs] People will be disappointed or they will feel like we haven't lived up to their expectations I suppose.

Paul: Yeah. Okay. Well that was really great. Thank you very much for coming on the show Daniel. No doubt we will try and crowbar you again in the future to come and talk to us about Pounce as well. Because that is an exciting project.

Daniel: That would be fun.

Paul: Okay thank you very much for your time and talk to you again soon.

Daniel: Thanks so much for having me.

Paul’s corner: Quick and dirty competitive analysis

Great stuff from Daniel! It was really fun to speak to him even though I managed to offend him after we stopped recording by calling him an American (he is Canadian). Hopefully he will forgive me for the ultimate crime!

Okay, so before I wrap up today’s show lets take a quick look at the subject of competitive analysis. Its actually a segment I have just written for the book I am working on and so I thought I would share what I have covered. The idea is not to make you an expert in the field but simply to allow you to extract as much information as possible from your competitions websites in a quick and easy manner.

As always I have written this up as a blog post entitled “Quick and dirty competitive analysis” so check that out in the show notes if you want to see exactly what I covered.

No show next week

So that is about it for this week’s show. Remember that there will be no show next week as I am going away on holiday too! Yippee! However, if you need your boagworld fix don’t forget you can check out the forum and chat with other people about the poor quality of Marcus’ jokes.

Show 86: Boagworld Book

Posted in Classic shows on July 10, 2007 by Paul Boag

On this week’s show: Paul talks about taking a brand online, Marcus gives some advice about reviewing your information architecture and Ian Lloyd introduces us to the challenges of designing for screen readers.

Podcast: Download (44.6MB)

Download this show.

Launch our podcast player

Paul’s personal news

Just a bit of personal news before I get into the industry related stories. I want to let everybody know I have signed a contract to write a book. The book is going to be primarily for website owners rather than web designers, however to be honest I think it could appeal equally to both. I intend to look at what “client’s need to know about building and running a website” so hopefully it should show by example how best to communicate and work with clients.

The most exciting thing about this book from my point of view, is the fact that I want to write it as a collaborative process with you the boagworld community. I am going to release chapters for you to see in advance of publication and also blog on various aspects of what I am writing. I really want to encourage you to share your thoughts and make suggestions as we go along through comments and the forum. I have already set up a forum thread dedicated to book ideas as well as an initial blog post on the book.

Obviously writing a book is a really slow process, but hopefully it is something that we can all get excited about.

News and events

Building for the iphone

Unsurprisingly there is a lot of information appearing relating to building web applications for the iphone. There is an iphone gallery consisting of hundreds of screenshots of the iphone. This is great if you want to mirror the look and feel of the iphone as closely as possible. There is also the iphone developers guide from Apple which provides loads of great advice. Finally there is iphoney, a piece of software that replicates some of the iphone’s web browsing functionality and lets you see what your application will finally look like.

Of course whether it is worth developing for the iphone at this stage is another matter. I guess if you are trying to reach the tech-savy audience who are iphone owners then maybe. Otherwise it might be better to wait until the iphone becomes more mainstream or other phones start offering the same level of web experience.

@media podcast

I was gutted to miss @media this year. Well, I say gutted, I was actually on a really pleasant family holiday, so I cant complain. However, I did miss a great line up of speakers talking about some amazing subjects. I was particularly depressed to have missed Jesse James Garrett’s keynote on “Beyond AJAX” and “Diabolical Design: The Devil is in the Details” by Jason Santa Maria.

Fortunately the recordings of the @media sessions are beginning to filter out for me to download and listen to. However, note that I don’t call them a podcast. There is no feed that I can find which is extremely frustrating.

Setting that little moan aside, it is great to be able to listen to these speakers even though I did not attend the conference and I would strongly encourage you to download and listen to a few yourselves.

Common mistakes in web copy

Although we would prefer to avoid it, the reality is that as web designers we write far more copy than we would like to admit. As for those of us who are website owners, a substantial part of our responsibility is writing good web copy.

We have talked on the show before about writing good copy but our focus has mainly been on style rather than technical detail. This week, I came across a post about common grammatical mistakes. However what I liked about this post is that it wasn’t focusing on the silly details of grammar that don’t really apply particularly well to the conversational tone of the web. Instead it looked at errors such as when to use “me, myself or I” and the difference between “i.e. and e.g”.

If you ever have to write copy then spend a few minutes to check it out. It only covers the worse offenders so doesn’t take long to read.

A department dedicated to the web

Jeffrey Zeldman has written a post entitled “let there be web divisions“. If you are responsible for deciding who should manage your corporate website then you simply must read this. If you are a mere foot solider then it might not be as relevant but it is still a good read.

Basically Jeffrey proposes that a company website should not sit under IT or marketing (as is traditional) but should be a division in its own right. I am not going to repeat all of Zeldman’s logic, but I have to say I wholeheartedly agree with it.

Websites are simply too multi disciplined to sit comfortably under either department and too important to be caught in an endless tug-of-war.

Paul’s corner: Taking a brand online

About a week ago, I had to give a presentation to a board of directors ,explaining the process we went through to develop a new design for their website. A large proportion of that presentation focused on the issue of brand identity. This organisation had a very well developed style guide and we spent a lot of time and effort getting that guide to work online. My presentation talked about the various steps involved and it occurred to me this might make an interesting podcast section.

I have also put together a blog post on the subject of “taking a brand online” and it is this that I cover on the show.

Marcus’ bit: Information architecture review

I am currently in the process of carrying out an information architecture review for a new Headscape client. I have done a fair amount of IA work over the years but I have found myself particularly enjoying this one so I thought I’d waffle on about what I’ve been doing.

We have covered the various aspects of IA work in previous podcasts – Expert Review, Stakeholder Interviews, Card Sorting and Wire Frame testing. This section is looking at the first of these, expert review, in a bit more detail.

I think it’s worth explaining what I mean by Expert Review. When we carry out an Expert Review we are effectively analysing a client’s existing site content, site structure and naming conventions with a view to creating a new IA based on our experience of using and developing websites. This is a collaborative process with the client – it has to be; we can make logical, usability based decisions but cannot claim to be experts in the client’s particular field.

First things first

I make sure that I have a good grasp of a number of things prior to carrying out an IA review. At the kick off meeting make sure the following are covered:

Target audience – this is crucial for the development of the IA. It may be that the existing site caters for one group well but another poorly.
Site aims – is there a stepped process that the client wants their users to go through.
Design – things like horizontal over vertical navigation can affect the IA.
Homepage requirements – find out what the killer apps and content are as these will need to be linked to from the homepage.
Finally, have a general discussion about content and site structure. See what the client thinks is important and what’s not.

Map out the existing site

The first thing I do is map out the existing site’s IA. This is a fairly slow and laborious task but it is the best way to not only learn about a site’s content and structure but also to understand what they do and what they offer.

Be logical, captain

Usually, the goal of this type of exercise is to streamline content into groups and name those groups so that users will understand what’s inside them.

Site’s that have grown organically over a period of time tend to spread content all over the place. It is usually fairly easy, though time consuming, to group content together. There are various methods for doing this; I tend to print out the existing site IA (that I usually create in Excel unless it’s a particularly small site, then I might use Visio) and scribble all over the printout until I’m getting somewhere. Some people like to use cloud/cluster diagrams (either on paper or using software) or there is always the age old method of creating ‘cards’ where each page name is written onto a scrap of paper. This is a bit like doing card sorting on your own where you group the cards into piles and give names to each pile.

Naming

We come from the ‘it does exactly what it says on the tin’ school of page/section naming. Marketing departments often don’t! A good example of this is the trend to verbs as section names over nouns. I remember one client wanting to call a site section ‘Enjoy’ when the section covered ‘Leisure Activities’. No prizes for guessing what we recommended!

Labels should be as descriptive as possible. Sometimes this can be difficult when:

there isn’t much space, for example, ‘How to register for our newsletter’ won’t fit on the average button, even ‘Newsletter Registration’ would probably be too much for a top level, so I would go for just ‘Newsletter’. It’s fairly obvious that the content underneath will relate to the organisation’s newsletter and should logically include registration, whereas ‘Register’ leaves the user asking ‘register for what?’
Sometimes sites are so big that main sections can include too much differing content to be labelled descriptively. In this case, I would recommend either shortcuts on the homepage replicating the main sections that include descriptive words or create drop down navigation that displays the lower level links.

Section ordering

This should follow some sort of desired path through the site. For example, the client may want users to get a bit of background, followed by an understanding of what the organisation offers, followed by some examples of previous work with a view to finally making contact. This would translate to:

About Us | Services | Case Studies | Contact Us

Conventions

Users don’t want to have to think (that sounds familiar!); they want to look and understand straight away. Following conventions helps with this process. For example, many sites include an About Us section as the first main section. This usually includes some history, annual reports, job vacancies and contact details. Users looking for this type of information don’t want to have guess that this information might be under, for example, ‘Company Background’ which is located at the far right of a horizontal navigation.

Collaborate – to a point

When you have created your first draft it then needs to be reviewed by the client, discussed and iterated until everyone is happy. Take on board any changes that are based on your lack of understanding of what the client does but be prepared to stand your ground on issues relating to web conventions and usability – after all, they’re paying for your expertise.

Ask an expert: Ian Lloyd on screen readers

On this week’s show we have Ian Lloyd giving us an introduction to the world of screen readers. I vividly remember the first time I heard a screen reader being used. I was gob-smacked by how painful an experience it was and I am still amazed that anybody manages to use them effectively.

It struck me that many of you listening to this show might not have heard a screen reader before. Hearing what blind people have to work with really makes you take their needs seriously and so I thought I would get Ian on the show to give you a taster.

In his segment, Ian takes us through some classic problems that screen reader users experience. Unfortunately to best understand what is going on in some of the examples you need to see what he is doing. In order to get around this problem Ian has made a screencast to accompany the audio. There was too much detail to make it available online or via your video pod but you can download the screen reader .mov file here.

What follows is a transcript of Ian’s section of the show…

Hello Paul, Hello Marcus and hello to listeners of Boagworld. This is the ‘Ask the Expert’ section and today I’m going to be talking about screen readers.

Now, I don’t actually qualify [meant to say classify!] myself as an expert screen reader user simply because I don;t use one on a day-to-day basis, because I’m not forced to; I do have good vision. As such, the way that I would use a screen reader would be different from someone who has to use it on a day-to-day basis. That said, I still think it’s useful to demonstrate to people what a screen reader sounds like. And the reason for this is that as far as I am aware on your podcast although you’ve talked about accessibility a lot and mentioned screen readers I don’t believe we’ve ever had a demonstration of what they actually are like for people when pages are built incorrectly.

So, today I’m going to be showing a few problems using a screen reader. I’m also going to be doing this as a video, so this is a screencast. I understand that at the end of this you will be providing a URL for listeners so that they can access this and view what’s happening on screen. Because of course it’s all well and good to listen to this stuff but to get the full context it would be good to actually see the video as well. I will try my best to describe what’s happening on screen throughout this podcast though.

Now the first example we’re going to look at is Amazon dot com. And somewhat cheekily I’ve brought up the page for my own book on Amazon. And, er, just having a look around at what I can find on the screen and there are some issues there. So, let’s have a look at this.

[Screen reader reads out page graphic correctly 'Build your own website the right way using HTML and CSS, Link graphic']

Oh, so that’s not too bad. I’ve just found an image there and it’s announced it correctly because it’s found a suitable alt attribute but underneath there are a couple of thumbnail images which, if I want to access those, it gives me a whole different … well, hear for yourself:

[Screen reader announces: 'See larger image, Link' then moves to next link, the thumbnail image and reads an unintelligible string of characters - numbers letters and underscores - out to the listener].

Mmm, doesn’t make an awful lot of sense does it? Let’s try the next image:

[Screen reader reads out more unintelligible characters and takes almost 8 seconds to read it out]

So, what’s happening there? Well, it’s quite simple: there’s no alt attribute defined for that image and so JAWS tries to fill in the gap and, er … oh I didn’t mention earlier that JAWS is the name of the screen reader that I’m using. So it tries to fill in the gaps because it doesn’t have an alt attribute it uses the file name instead and the filename, as is often the case on Amazon, is a right load of old gobbledegook! So it doesn’t give it any useful information about that image.

Here’s another example of the same thing.

[Screen reader reads out an image gallery as 'thumbs slash zero, thumbs slash one, thumbs slash two' etc]

So this is actually a photo gallery, erm, with a bunch of thumbnail images hence it’s reading ‘thumbs’ because that’s the folder where the thumbnail [image] is actually in and it’s reading them sequentially as well. It doesn’t sound quite as painful as the Amazon example but it still doesn’t tell you any useful information about the images on the page.

[Screen reader announces more examples from the same page]

So let’s listen to a slightly improved version of that:

[Screen reader announces the same images but with appropriate alt attributes, e.g. 'The Mystery Machine, driven by Scooby' for a photo of a camper van that is painted like the Mystery Machine from the cartoon Scooby Doo]

If we were to look at that on the video I’m showing that page with the style sheet disabled and the alt attributes displaying inline next to the image. As you could hear in the second example it was far more usable – you could actually understand what the image was about (as long as you understood some of the VW terminology used in there), whereas in the first example none of the images actually had alt attributes so it was just trying to read out the location of the file.

So let’s look at another example.

[Screen reader announces content of new page 'Page has no links' and then starts reading subsequent page content before I stop it]

What I’m looking at on screen is a page that seems to have a page full of links. But if you were listening carefully to the beginning of that, the screen reader thought otherwise. I’ll just try to find that again for you.

[I scrub back in the video clip to find the part where the screen reader says no links]

According to the screen reader the page doesn’t have any links. And the reason it thinks that is, well, there *aren’t* any links. What’s actually happening … is … we have a whole bunch of text on the page that is styled using CSS and the behaviour for the link is added using JavaScript. So, we have a <span> element that has an onclick event, location.href=’somewhere.html’ and that’s [the span] wrapped around the text that says ‘This is a link – click me’. Um, but of course it’s not a link. The screen reader can’t find it because it’s not an <a href="">, it’s something else that’s been styled to look like a link and behave like a link. But it’s not. Thankfull that’s not too common but you have to just be aware that what may look great on screen for you may not be any use to someone using a screen reader. You have to use the right markup for the job.

So, you could have a page that’s full of links that say ‘click here’ but of course that’s another problem all in itself. Let’s have a listen to that:

[Screen reader reads 'Click here to view' repeatedly as I tab through the links on the page]

Yes, so … the problem there is that it doesn’t give you any information at all. And this is actually still quite common. In fact just yesterday I was looking at Facebook dot com (for my sins) and, er, I was quite shocked to find that they were using a lot of this where the link phrase was ‘click here’ as opposed to the phrase that you would really want to have, so for example instead of saying ‘click here for more information’ and having ‘click here’ as the link phrase you would have ‘for more information about our products’. That would be the link phrase. Erm, but if you just use ‘click here’ and you’ve got a whole page of links that reads ‘click here’ this is what you get:

[Screen reader once again reads 'Click here to view' repeatedly as I tab through the links on the page]

Basically, completely unusable.

Now the next example I have is of a form, and in this example, er, the form has been laid out using a table. Thankfully, these days, tables are being used less for layout and people are using CSS for page layouts. However, for forms it’s still not uncommon to see someone put a table in there. And, er …

[screen reader interrupts as page loads]

OK, so in this example what I’m looking at on screen is what appears to be, um, well … four text inputs, and then there is a radio button and it’s basically asking for some personal information, first name, surname, your age, place of birth and then a question ‘Do you have a nut alergy’, the answers being ‘no’, ‘yes’ or ‘don’t know’. So let’s see what the screen reader makes of this.

[screen reader says 'table with two columns and four rows'. I tab to the first input and it reads 'surname/family name - edit']

Already we’re hitting a problem. Because the first field that I tab to I can see on screen is *actually* [the one for the] the first name . But the screen reader believed that to be the surname.

So I’ve now tabbed to the second field which is the surname and it didn’t announce anything. So let’s tab to the next field:

[screen reader announces field as 'town/city - edit']

Again it’s getting it wrong. I’ve actually tabbed to the field that says ‘Age next birthday’

[tab to the next field, screen reader announces 'tab - edit']

And *now* I’m in the ‘town/city of birth’ field and it hasn’t told me anything.

[screen reader announces 'yes - radio button', then 'don't know', reading the radio button choices]

This is all a bit confusing here. OK, so it’s asking me the question ‘Do I have a nut allergy?’.

[I tab to the next field, screen reader announces 'Yes - radio button - unchecked']

OK, so … that thinks I’m at the yes radio button but I’m looking at it on screen and it says ‘no’. So, what’s going on here? Now this is going to be a difficult one to explain on the podcast; this is one of the sections where you really need to see the video. But what’s actually happening here is we’ve got a table to lay out the page and the text sits above the text input, so for example where we’re asking for first name, the text that says first name is in the first column and the input that relates to that is in a column underneath, sorry, I mean a table cell underneath it in the next table row. Now the reason this is causing a problem is because if you were to actually linearize that table, in other words look at it in the order of the source code you get a very different view of it. And this is what happens with the screen reader. So if I were to look at this form and read it out in a linear fashion, it goes like this:

First Name [text]
Surname [text]
Form input for First name
Form input for Surname
Age [text]
Town/City of birth [text]
Form input for Age
Form input for Town/City of birth

And so on. The problem is that the screen reader expects the text for that input to appear before that input, and because of the way this has been laid out it really really gets things confused. As I said, this is quite a difficult one to explain on the podcast but if you look at the video clip you’ll see why this is causing a problem.

[screen reader blurts a few things out as I try to manipulate it ... poorly]

Sorry about that, that didn’t add anything useful at all. Hopefully Paul can edit that out!

OK, so …. the big problem here is that you may be asking a question as we have here that says ‘Do you have a nut allergy?’ and the answers are ‘no’, ‘yes’ and ‘don’t know’. But if you do put the form elements in the wrong order you’re gonna have a problem. And the reason is obviously that with a nut allergy that could be a life or death situation. You could be filling out a form as a blind user and you select what you think is the ‘yes’ radio button but because the form has been poorly laid out and doesn’t have <label> elements that are actually helping to enforce the accessibility you may actually have been selecting the no checkbox [meant to say radio] and it really could be a life or death situation. It may *not* be as bad as that – it could end up with you booking the wrong hotel location or date. So you have to be very careful with the form layout.

OK, one final example. Now everyone’s talking about AJAX, it;s the buzzword of the moment. Unfortunately it’s also not very good for screen reader users. And the reason for this is that, er, anything that is updated on the page after page load is very very problematic to pass on to the screen readers. now the example I’m going to give here is a fairly simple one, and it’s the Google Suggest page. What Google Suggest does is let you type in your search phrase and as you type it’s calling back to the server, finding suggestions for you which it then populates in a list underneath the search input. So let’s have a listen to that.

[screen reader announces: 'google search - edit, type and text' then reads each letter of search term 'this is a test' as I type]

So I’ve just typed ‘this is a test’ and on screen underneath that is a whole bunch of suggestions that it has found. But if I try and actually access any of those using the keyboard:

[screen reader announces 'Google search - edit, Google search - edit, Google search - edit, Google search - edit' with each keypress on the down arrow]

It’s actually doing nothing. On screen I can actually see that it’s going up and down the options but the screen reader, it’s getting nothing back at all, nothing useful at all.

[more screen reader confusion]

Well thankfully with Google Suggest this is something tat you can opt out of – you don’t have to use Google Suggest, it’s not enforced on you. But it’s a very simple example and it just goes to show that a very simple technique like this can be, basically, completely unusable for someone using a screen reader.

So, that was just a few examples. Hopefully you’ve had an indication of how a poorly built website or web page can affect a user. the bottom line is, keep listening to the podcast, keep doing things right, keep using good markup and, if you can, test your own web pages or web sites using a demo version of JAWS. It really does pay dividends to find out how this works – or doesn’t work. So, thank you very much, I hope this has been useful, and I look forward to the next podcast, Paul. Thanks guys.

No show next week

Unfortunately there will be no show next week as I am away speaking at the Institutional Web Management Workshop. However we will be back the week of the 23rd July.

Show 83: iphone bollocks

Posted in Classic shows on June 19, 2007 by Paul Boag

On this week’s show: Paul talks about the importance of undo, Marcus explains the benefits of stakeholder interviews and Struan Robertson highlights some legal deathtraps waiting for us online.

Podcast: Download (19.3MB)

Download this show.

Launch our podcast player

News and events

Safari for Windows

Probably the most talked about story of the last week is the fact that Apple have released Safari for windows. To be honest I am a little surprised just how much has been written about this considering I don’t think the impact is going to be that significant. Will Safari cut into Internet Explorers market share? Probably not. Will it undermine the market share Firefox has developed? Almost certainly.

If safari under windows rendered exactly the same as under OSX then there maybe some benefit to windows based web developers. At the moment it is impossible for them to test on Safari without buying a mac. This has the potential of changing that. However, in all likelihood differences will emerge and if they do then this is just another browser that we have to test against.

We will see.

Applications for the iphone

At the same time Steve Jobs announced Safari for windows he also talked about the iphone. The biggest criticism of the iphone to date has been the fact that it is locked down so third parties cannot develop applications for it. Apparently Apple have been thinking long and hard about the problem and have come up with a solution. They are going to allow developers to build web 2.0 applications that can be accessed by iphone users using the built in Safari browser.

What a load of bollocks. They are telling us something we already knew. As soon as Steve Jobs announced that the iphone carried a full safari browser we knew that web applications would be developed for it. Sure, they are now saying that methods are going to be provided to automatically access iphone features such as dialing and google maps but very little detail was given. As far as I can see Apple is not giving people anything more than they already had.

Jason at 37 Signals is excited about what this means for web apps. He says…

This is the coming out party for web apps. We are very excited about this. These are exciting times.

…and he is right. It is exciting for us web developers. However, I am not convinced the user will see it that way. David Shea mirrored my own reaction at this news when he simply posted a graph showing the astronomical cost of data calls on mobile carriers. Web applications are great for web designers but for users of mobile devices like the iphone they could quickly be prohibitively expensive.

Web Design-isms: 7 Surefire Styles that Work

I found a great article on Think Vitamin this week that talks about design trends on the web. One of the things you learn early on as a designer is that despite your desire to produce something completely original you never will. Everything has been done before and in this article Larissa Meek takes us through 7 styles of design that appear again and again on the web.

The article very much reminded me of design meltdown, an excellent site that showcases different approaches to design. However, what I particularly liked about this post is that the author showed examples of how these styles occur in art as well as online. This is nice because it encourages us as web designers to look beyond the web for inspiration, a subject I have spoken about before.

CSS frameworks

The final story caught my eye because it is an extension of something we have been doing for a while. A while back I talked on the show about the fact that Headscape work with standard XHTML templates. We use these templates as a starting point for development. They allow you to jump start the build process as well as ensure consist naming conventions across the entire design team.

In a new post on the List Apart website Jeff Croft proposes a similar approach for CSS, based on the concept of Frameworks. Jeff argues that certain aspects of CSS development are often repeated across multiple projects. From browser reset styles to creating horizontal menus and standard grid layouts, it seems absurd that we generate these from scratch each time. Jeff proposes that instead we create a series of CSS files that we can be reuse again.

Its a great idea and one definitely worth exploring if you work on lots of similar projects or are part of a large team where you are looking for consistency.

Agony uncle: The importance of undo

A couple of weeks back I received this email from Tom in Texas:

I am a designer currently working on developing a web 2.0 app. The developer is doing some really cool AJAX stuff but unfortunately most of it breaks the back button in the browser. He is arguing that it doesn’t really matter as there are lots of other ways of going back. What is your opinion on the subject?

Once I had recovered from the naivety of the developers comment and finished counting slowly to 10, I started to think through the role of undo. In the end this very simple question from Tom evolved into a blog post on the importance of undo. It is this subject I am looking at in todays show.

Client corner: Stakeholder interviews

Got this question from Dusted.

I’m about to begin a project to help an organization evaluate its current web site and web site management. I’m also going to perform some research and planning to help them start developing a new web site.

The organization is quite complex with a lot of different departments – marketing/events, sales, information/press, youth and more. Each person responsible for each department will be interviewed and I need some advice about what questions to ask them.

Starting off with a few…

Describe your department’s needs of the web site.

What can be done in a better way?

The results of the interviews will be used when I present my evaluation (and research/planning) to the board.

Any advice, links to articles, books… help of any kind would be deeply appreciated.

We have done quite a lot of stakeholder interviews over the years so this question seemed like one I could help with.

Stakeholder interviews can often be confused with user interviews, as they can often happen during the same process. I tend to differentiate the 2 by calling them internal and external stakeholders. These groups will always require a very different set of questions.

This piece refers to internal stakeholders only; those people that:

Will be paying for the project!
Are content owners
- Some won’t know or want to be content owners – “that’s X’s job”
- Some will consider their content considerably more important than everyone elses – “there should be a tab called ‘Corporate Accountancy’ and a big ad on the homepage”!
Will be users e.g. sales

There are a number of good reasons for talking to stakeholders, as follows:

Politics

Most organisations involve some sort of tension between departments/stakeholders/teams/whatever. Giving representatives from each of these groups (make sure you don’t leave anyone out!) provides everyone with a voice. It ensures that everyone has said their piece and it’s down in writing. Ultimately, it gets buy in on the project from all parties thereby creating a better end product.

Education

This applies from both sides. The interviewer is looking to be educated regarding the various points and specialisms that the interviewee has (that’s the point of the interview!). However, the interviewer also has an opportunity to educate a whole raft of internal staff about the web. A good example would be why it’s not a good idea to name site sections after departmental structure. In fact, teaching users to think of their end users early in the interview will probably affect what they have to say.

Verification

Talking to internal stakeholders can often highlight the need to develop certain functionality/facilities/micro-sites/etc that web managers only thought might be useful. Interviews can also be used as a test bed for ideas as well as feedback.

Semi-structured

Following on form the last point, make a point of telling interviewees that they can go off track. The questions are useful as guides but don’t stop writing down what someone is saying if it doesn’t fit with the script.

So, finally on to some good questions to ask&#…;

Questions will, of course, vary depending on the organisation, end user requirements etc, but looking back through a number of scripts, these seem to crop up regularly:

What does your department do?
What are your ‘processes’?
Who is your client and what do they want?
How do you think the web can help you deliver?
What is your role?
What is the biggest pain about your job? What takes the most time?
Describe your Internet understanding/usage?
Describe your software understanding/usage?
Name applications that you are a confident user of.
Do you store any information in databases? What?
The current website – what’s good and bad about it, what’s bad about it?
Are you tasked with providing content for part of the website? If not, do you want to be?

Ask the expert: Struan Robertson on Legal Issues

Today’s guest expert on Boagworld is Struan Robertson a corporate lawyer who specializes in IT law. I first met him on the .net podcast and thought it would be great to get him on the show to give us a small taster of the kinds of legal issues encountered by web professionals. In the show he answers three questions on particular scenarios to give you a taster of the kind of issues that can arise. These include:

What are the dangers of working on websites for illegal companies
Some of the issues surrounding using images when you aren’t sure about the licensing
Storing private data

Although the particular scenarios are quite specific hopefully they communicate some underlying messages and encourage you to take your legal obligations seriously. If you are interested in learning more about the legal issues surrounding web design and IT in general then check out Outlaw.com where Struan provides a lot more advice. Also Struan writes a column in the .net magazine where he covers different legal issues each month.

The importance of Undo

Posted in User experience on June 13, 2007 by Paul Boag

An easily available undo function creates a sense of simplicity because it instills in the user the attitude of “what the heck, I can always undo it”.

Many internet users lack confidence when interacting with the web. It is our job as web designers to try and reassure them and provide a safety net when things go wrong. Providing various methods by which users can undo actions is a useful crutch to the less confident user.

Benefits of undo

Undo functionality seems to be in increasingly short supply on the more recent raft of web 2.0. websites, especially on sites that make heavy use of AJAX. This is a sad day for web design as the ability to undo provides three crucial benefits:

Alleviate apprehension

I have said this many times but it always bears repeating; the majority of people do not like computers. It is so easy for us to forget that, as we live and breath computers everyday. I have to confess that I am more comfortable working with a computer than the real world. After all, how many times have you tried to CTRL Z reality!

However, although we are comfortable with computers the majority of people aren’t. They are intimidating, impersonal and far from intuitive. This is not only true for the PC but also for the web. After all who would design a system where the interface changes when you move between sections (sites).

The ability to undo, go back or escape is a lifeline to many users. It is immensely reassuring to know that you can always undo something if you get it wrong and when that option is not available it can be incredibly disturbing. Take for example the first time you ever bought something online. Do you remember a feeling of apprehension when you realized that the next click would place the order and that there was then no going back.

A way to overcome complexity

I am a huge fan of simplicity, largely because I recently finished reading “The Laws of Simplicity” by J Maeda. In his book he talks about the fact that the ability to undo creates an impression of simplicity even in the most complex applications.

An easily available undo function creates a sense of simplicity because it instills in the user the attitude of “what the heck, I can always undo it”. Once the user has that attitude they perceive things as simpler than they actually are.

A method to build confidence

The “what the heck” attitude is largely about confidence. A confidence in the power of undo to do its magic, is what allows us to play and experiment with an application. Through experimentation and play we learn and with knowledge comes a confidence in our own abilities. That is the power of undo.

Opportunities to provide undo

Now that I have established the importance of undo the next step is to look at what options are available to us as web designers to provide undo to our users. I have come up with four ways this is possible, however the sad reality is that we continually undermine these different methods in the way we code and design.

Back Button

I must have sat through hundreds of usability sessions over the last decade and I do not recall one where the user did not use the back button at some point. The back button is the primary life line used by most people to correct problems and yet in more and more sites it does not work. The problem lies in the use of AJAX and Flash which break the page metaphor on which all browsers are built. The same problem occurred with frames and was one of the major reasons that the use of frames died out.

Although there are fixes for this problem in both flash and AJAX, they are far from perfect and rarely implemented. Serious attention needs to be given to this problem when developing modern web applications as a failure to do so not only undermine usability but damages user confidence.

Breadcrumbs

There was a time when users didn’t really understand breadcrumbs. However as has been suggested recently by Jakob Nielsen, that is no longer the case.

Although breadcrumbs should never be seen as a replacement for the back button, they do work as a handy alternative for more experienced users. What is more, although they have traditionally been used on page based websites they can also translate well onto web applications.

Favorites

In usability sessions I have also occasionally seen favorites and bookmarks used as an undo tool to go back to a previous page. However as with the back button this functionality is often broken in modern web applications that update sections of pages instead of the entire page. Favorites provide the valuable ability for the user to quickly return to marked “safe points” in their surfing and as a result we should be doing our upmost to ensure that this ability remains.

Home

Almost all websites have a link back to the home page, however not all of them make that link very obvious. A common practice is to make the logo a link back and although in itself this technique is fine, it is not obvious this link exists and so many users are not aware of it.

Having a link back to the home page is a great way of letting the user “start again” but if you are going to provide that functionality it needs to be obvious.

So there you have it; why undo is important and some techniques to undo easier on your website. Hope it helps.

Show 79: Despise the listener

Posted in Classic shows on May 15, 2007 by Paul Boag

A great line up this week with Paul, Marcus and Andy Clarke.

Podcast: Download (21.4MB)

We have a great lineup this week: Paul talks about getting things done in web design and an alternative approach to your reading list. Marcus explains the exciting area of insurance for web designers and we have Andy Clarke on the show to give us an update on CSS 3.

Download this show.

Launch our podcast player

News and events

Google Analytics gets interface upgrade

Like so many who join Google, Jeff Veen has been forced to be somewhat tight lipped about what he has been working on. However in the last week we have finally been able to see the fruits of his labors with the relaunch of a new and improved Google Analytics. You would be forgiven for thinking that a load of new functionality has been added to the service. In fact that is not the case. The only changes have been to the user interface. The difference is that you can now find everything quickly and easily.

If like me you found the old Analytics service confusing and difficult to use then you might want to take a look at the new revised version. It is a definite improvement.

Great new articles on A List Apart

For a while I have been a little disappointed with the articles coming out of A List Apart. Perhaps they were simply too “high brow” for the likes of me but they lacked any practical application. However this issue is different. It has two great articles about handling clients.

The first entitled “Stand and Deliver” provides some superb advice on presenting your designs to a client. The second called “Educate Your Stakeholders!” talks (unsurprisingly) about educating the decision makers in a web project so they make more informed choices.

Both are really superb articles and I would definitely recommend you check them out.

Teaching the traditional web

We are all acutely aware that the web is changing at a rapid rate. At the moment the focus is very much on web applications however we cannot afford to ignore the massive number of page based sites that still need to adapt to the changing way people are interacting online. In a post called Teaching the traditional web, Keith Robinson discusses how we need to alter our approach to page based websites based on deep linking, RSS feeds and mobile access. A very enlightening read.

Baselines and vertical rhythm

Having Richard Rutter on the show a few weeks back made me acutely aware of my shortcomings when it came to web typography. Although I promised myself I would look into the subject in more depth I was a bit vague as to where I should start. Fortunately Richard has given me a starting point with a list of resources on his site that look at the subject of baselines.

I know that many people find web typography an uninspiring subject but good typography can have such a profound impact on how people perceive design that it really is worth your attention.

Client corner: Getting things done in web design

I have just finished reading “Getting Things Done” by David Allen. Not only has it seriously helped me to get control of my workload but its also made me rethink how I approach web design projects with clients. In this week’s client corner I suggest some techniques that designers and clients should use when a new project is starting.

As seems to be the default approach these days I blogged on this earlier in the week so if you want more information on what I said in the show then be sure to check out that post.

Ask the expert: Andy Clarke on CSS 3

Following Andy Budd’s recent criticism of the W3C CSS Working group it seemed appropriate to have Andy Clarke on the show to talk about the progress of CSS 3. Andy is an invited expert on the CSS working group so has the inside track on what is really happening. In the show Andy talks about…

Some of the cool layout features available in CSS 3.
The modular nature of CSS3.
The slow progress made by the group.
And the need for the web design community to contribute in the process.

Agony uncle: Insurance for web designers

We received the following question from Brian last week:

As an avid listener to your podcast – and having spent the day catching up on them while travelling! – I was very interested in a particular segment where your good self and that Lillington chap mentioned your Terms and Conditions and having, ‘…all the right insurances in place…’, with regard to setting up a business.

I’ve recently done some work with a mate – a few hopefully not-too-shabby websites – and although we think we are getting the hang of sorting out contracts now, we have never been able to settle on what to put in our Terms and Conditions. Every time I start to do it I either glaze over or start putting stupid things in due basically to boredom!

As for insurance we never assumed that we would need any for web design. Its not like we’re making nitroglycerine or heart bypass machines… so we assumed the basic rules of common sense prevailed.

To this end, if you have any advice on what insurances might apply or what sort of thing should be covering in T&C’s?

Firstly I’ll cover the terms and conditions issue, much as I don’t want to appear protective over our ts & cs, we have reached the conclusion that by providing them we are in effect providing legal advice.

This is not what we do and it’s not a path we wish to tread!

We suggest speaking to your lawyer or maybe a local chamber of commerce who could provide a standard terms and conditions contract template. I also droned on about the different aspects of terms and conditions in episode 65.

Insurance, however, is another matter. Though, again, I am concerned about making stuff up here (as is often the case!) so the majority of the following content is from Business Link. This is what we currently pay good money for:

Professional Indemnity

If you are in the business of selling your knowledge or skills, you may want to consider taking out professional indemnity insurance.

This protects your business against compensation sought by a client if you have made mistakes or are found to have been negligent in some or all of the services that you provide for them. Professional indemnity insurance will also cover any legal costs.

Public Liability

If members of the public or customers come to your premises or you go to theirs, you should think about taking out public liability insurance. This type of insurance covers any awards of damages given to a member of the public because of an injury or damage to their property caused by you or your business.

Product Liability

In product liability insurance (PLI) terms, a product is any physical item that is sold or given away.

Products must be “fit for purpose”. Under the Consumer Protection Act 1987, you’re legally responsible for any damage or injury that a product you supply may cause. PLI covers you against compensation awarded as a result of damage to property or personal injury caused by your product.

Employers Liability

Employers’ liability compulsory insurance (ELCI) enables businesses to meet the costs of compensation and legal fees for employees who are injured or made ill at work through the fault of the employer.

Key Man Insurance

Key man insurance is designed to cover you for the financial costs of losing key personnel. We still have this for Paul….goodness knows why! ;-)

Review: Looking beyond web design books

This weeks review section isn’t so much a review as a recommendation. At SXSW you are really spoilt for choice as to what to attend. In fact there is so much choice it is overwhelming. After much consideration I decided to take an interesting approach. I decided to mainly attend panels on subjects I knew nothing, or little about. Instead of going to panels on CSS or design I went to sessions on marketing and strategy. The result was an incredibly enjoyable and enlightening week.

On my return to the UK I decided to take a similar approach in my reading. Prior to this the majority of books I read where either on CSS or Javascript. However I am now trying to broaden out the range of books I read to encompass other subjects like productivity, business process, and even some sociology. As with SXSW it has been an incredibly rewarding experience and something I would encourage others to do. I have been amazed at just how much of what I have read has related in someway to my job and I believe it has genuinely improved the quality of my work.

I would really encourage others to try the same thing and would like to suggest three books to break you in gradually. Although none of these books are directly to do with web design they all include valuable lessons that you can apply to your work on a daily basis…

Show 76: Clients and Agency

Posted in Classic shows on April 24, 2007 by Paul Boag

Marcus talks about setting up a web design company while Paul talks about the role of the client and Derek Featherstone talks about making your web application accessible.

Podcast: Download (27.5MB)

Download this show.

Launch our podcast player

News and events

Eric Meyer’s reset style

I have talked before about the idea of having a CSS file that removes all of the browsers styling in order to allow you to work from a clean slate across multiple browsers. Well, over this last week Eric Meyer has picked up on the idea and has been collaboratively developing a reset CSS file via his blog. If you do a lot of CSS work, this is definitely worth getting your hands on.

Microsoft Silverlight

Microsoft are gunning after Adobe on all fronts at the moment including a flash competitor called Silverlight. Like flash, Silverlight offers animation, interactivity and cross browser compatibility (although I don’t seem to be able to get it working on a mac). However, their real focus is on video where they trump Flash by offering high definition quality. It also appears to offer more “standards friendly” methods of inserting and manipulating movies, however as I said I have been unable to test this so far.

The biggest hurdle Microsoft faces will be take up. At the moment Flash dominates partly because in many cases it is installed almost invisibly in the background. In contrast, at the moment, Silverlight is a separate installation that takes place outside of the browser. No doubt this will change in the future.

35 Designers, 5 questions

Smashing magazine are certainly on a role at the moment, publishing a range of superb web design articles. One of the most recent is a post where they asked 35 designers (of which I was one) 5 questions about their approach to web design. The resulting article is a fascinating read and gives you a real insight into how other web designers work. The questions included:

1 aspect of design you give the highest priority to.
1 most useful CSS-technique you use very often.
1 font you use in your projects very often.
1 design-related book you highly recommend to read.
1 design magazine you read on a daily/weekly basis (online or offline).

CSS tools

Another Smashing magazine post. This one lists some very useful CSS tools including form builders, list makers, CSS layout templates and much more. If you are starting out in standards based coding some of the tools here will produce you some brilliant examples of clean code.

Client corner: The role of the client

Myself and Marcus swap roles this week and I take a look at our client corner issue; the role of the client. There is a lot written about the role of web designers but very little written about what part website owners play in the evolution of their sites. It is an area I have been thinking a lot about recently and I wanted to share a few thoughts with you. It is a subject that I have recently blogged on so if you want more information on what I consider the role of the client to be then I suggest you check that out.

Ask the expert: Derek Featherstone on ARIA

We are lucky enough to have accessibility expert Derek Featherstone on this week’s show talking about making web applications accessible. He talks about how HTML is not designed to support web applications and that the methods used to make it work are often little more than hacks. He then introduces a new standard from the W3C called ARIA and explains how this will assist in making web applications more accessible. If you want to know more about what ARIA is and how it can make your applications more accessible then Derek recommends a recent article on the List Apart website.

Agony Uncle: Setting up a web design company

Marcus takes on the lofty role of Agony Uncle this week responding to a question on the forum about setting up a web design company. The question, from Stanton, starts with him setting the scene of someone wanting to break out on their own but worrying about how they will cope without that guaranteed income.

Marcus gets all nostalgic about the early days of Headscape and then provides advice about starting up. He covers all the boring bits about incorporation, insurance, funding and documentation. He then talks about getting business in and not forgetting that someone has to be the salesman!

Show 68: Tagtastic

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

This weeks show includes hints on email campaigns, writing Web design contracts and site navigation approaches.

Podcast: Download (23.1MB)

On this week’s show; Matthew Patterson from Campaign monitor shares some handy hints on sending an email campaign, Marcus finishes his series on web design contracts and Paul looks at some interesting alternative approaches to site navigation.

Download this show.

To subscribe directly within itunes click here

News and events

Diversity in web design

This week the web design blogosphere has been dominated by discussions about the lack of women speakers at conferences. Jeffrey Zeldman, Eric Meyer, Jeremy Keith, Tantek… the list goes on and on. Frankly, I find the debate less than helpful. It is interesting to note that all of the women I have seen post on the subject have seemed very defensive almost as if they are under attack for not speaking more!

More on Open ID

Open ID continues to build momentum with both AOL and Digg.com saying they will support the standard. Dan Webb also provides a guide on how to support Open ID in your web applications.

Validation: why it matters

Ethan Marcotte has just published an interesting article on the List Apart website looking at the business benefits of validation and why it continues to polarise the web community.

The sorry state of web accessibility

The subject of web accessibility receives another body blow this week with Mike Davies posting a damning criticism. What is probably most disturbing is that I am yet to find a post disagreeing with him.

Client Corner: The statement of work (final chapter!)

This week sees the end of Marcus’ series on the statement of work (I know, it is distressing for us all!). In this final segment he takes a look a:

Milestones and timescales
Project management
Testing
Deliverables
Pricing

Ask an expert: Matthew Patterson on email campaigns

Matthew Patterson works for campaign monitor one of the best email management sites about. Their site is stuffed with great advice for those thinking of running an email campaign and so it seemed only natural to get him on the show and get his thoughts on how best to run a successful campaign.

Non hierarchical navigation

Headscape was recently approach by a potential client who had literally hundreds of thousands of web pages which were almost impossible to organise into a traditional information architecture. They wanted us to suggest some alternatives and so I thought this sounded like a great issue to cover on the show.

Instead of trying to stuff everything we covered in those show notes, I have instead posted a separate article on non hierarchical navigation which includes everything I said and the links I mentioned. Hope you find it useful.

Show 64: Hosting

Posted in Classic shows on January 22, 2007 by Paul Boag

This week on Boagworld we explain all you need to know about hosting , look at how to interpret other people’s CSS and review an excellent HTML email testing tool. Oh yes… and Marcus drones on about client stuff.

Podcast: Download (22.3MB)

Download this show.

To subscribe directly within itunes click here

News and events

Heuristic Testing

This week seems to be the week of Heuristic usability testing. Andy Budd kicked us off with a post on how Jakob Nielsen’s classic article on heuristic testing needs updating to take into account the new generation of web applications. Lisa Herrod then followed up with an excellent article on the sitepoint website looking at how heuristic testing can be used by web development teams.

The Future of Web Design

I know that a lot of people cannot afford the time or money to go to web conferences but I thought the Future of Web Design one day conference was worth a mention as it is only £59. It has a great line up of speakers including people from 37Signals, Flickr and Adaptive Path.

Tips for better design review process

You maybe the best designer in the world but if you cannot “sell” your designs to the client then more often than not they will be rejected. Many designers hate the design sign off process and are often frustrated with the final result. Keith Robinson has written a superb article that will help you better manage the successful sign off of your designs.

Seven Accessibility Mistakes

A while back Chris Heilmann wrote two articles on typical accessibility mistakes that people should avoid at all costs. I am sure that they were great articles but I never got around to reading them. Fortunately Roger Johansson has taken the time to summarise them in a nice easy to digest format.

Client corner: Questions for designers

How do you know which is the right web design agency to go with? Proposals are important but what questions do you ask at the presentation? This week Marcus gives website owners the inside track on what to ask prospective web design agencies. Here are some of the main points he covered:

Get a detailed breakdown of rates and pricing.
Understand what happens if things go wrong.
Ask about the contractual arrangements.
Request financial information on the company.
Get detailed information on the work they have done.
Know the team who will be working on your project.
Always ask to speak to existing clients.

Agony Uncle: Understanding other people’s CSS

There is nothing worse than working on a site built by somebody else. This especially true when it comes to the CSS. What styles affect which elements? How do the styles cascade down? What is going to be effected if I make a change to a style? This week in the agony uncle corner we look at some of the tools which can help solve these issues. In particular we take a look at the Firebug Firefox extension and the CSS panel in Dreamweaver.

Ask an expert: Mark Crawley on hosting

One of the things that has been requested for the “ask an expert” section is that we try and get on some new names rather than the normal “web celebs”. With that in mind this week’s guy is an old work colleague of mine; Mark Crawley. He talks about an area we should have covered a long time ago… hosting.

Review: Testing HTML Email

Although many condemn HTML emails as truly evil, the reality is that many of us are occasionally forced by clients into producing them. Setting aside the appalling support for standards, the next biggest headache with working on HTML emails is testing. Fortunately Site Vista, a UK based company has solved the problem by producing a testing suite very similar to Browser cam but for email.

Podcast 61: Christmas Special

Posted in Classic shows on December 11, 2006 by Paul Boag

In our Christmas Podcast Special; Skype murders Marcus rendition of Silent Night, Paul shares his list to Santa and they both look at the successes and failures of the web over the last year.

Podcast: Download (24.1MB)

I know what you’re thinking; “not the most riveting subject”. However, don’t let that put you off. Although return on investment might not float your boat, it is still extremely important and you should take the time to listen to this show.

Download this show.

To subscribe directly within itunes click here

So another year is done and boagworld finishes for its Christmas break. We will be back in January but until then you can enjoy this extra special episode of the show.

It’s been a real pleasure working on the show over the last year. We really want to thank you all for listening. We never anticipated that the show would prove such a success and hopefully we can continue to keep it fresh and exciting in the New Year with our new format.

This year’s Christmas special is slightly more structured than last year’s so I figured a few notes on what we covered maybe appropriate. Enjoy!

Special offers to boagworld listeners

A couple of companies that listen to boagworld wanted to give something back to the boagworld community. Although I haven’t purchased from either site yet myself, I thought it was nice they were enthusiastic to share a small token with you all.

Houlton Wines will give you a 10% discount if you quote the coupon code “boagworld” when ordering. Equally Seams will offer 25% off any tshirt if you quote to code “boagworld001” when you checkout with paypal.

News

I tried to give the news a Christmas theme this week by ensuring all the stories had a Christmas slant. Guess which one fails to meet the criteria!

Biggest Tech Mistakes of 2006

Thank you to everybody who nominated a tech mistake of 2006. Below is the shortlist. You will have to listen to the show to hear who Marcus announced as the winner.

Best web applications of 2006

Also in the show we look at the best web sites and applications of the year. Nominations include:

Dear Santa

I thought it might be fun to share some of the gadgets I will be asking Christmas for this year. Of course if you want to buy me any of them I am sure Santa won’t mind!

Finally, we do a quick review of the services offered the Shaw Trust. If you haven’t come across these guys before then definitely check them out. They offer some very interesting web accessibility services which is ideal if you want to test your site with real disabled users.

Thanks for listening, and we will speak to you all in the New Year. Happy Christmas!