Tag Archives: redesign

No plans to redesign your site? Now is the time to hire a web design agency.

Posted in Web strategy on by Paul Boag

Many website owners hire their web design agency at the wrong time. Instead of hiring a web designer when you need work done, hire them when you don’t!

Traditionally website owners hire a web design agency when they are unhappy with their website and have the budget to do something about it. However, I have come to believe that the best time to hire a web design agency is when budgets are tight and you are reasonably happy with your website.

Am I mad? Well, possibly. However, let me explain my logic.

Flaws with the traditional model

Image of a web designer reluctant to stop working on a website

prodakszyn, Shutterstock

My madness began with a belief that the current way most website owners engage with web design agencies is wrong. Normally things work something like this…

  1. The website owner becomes unhappy with his site and decides things need to change.
  2. He concludes the site needs redesigning and so writes a brief before asks web agencies to pitch for the work.
  3. The agencies respond and one is selected for a expensive redesign of the site.
  4. The agency throws out the old site and builds a new one.
  5. The website owner pays the web agency and they go their separate ways.
  6. Slowly the site decays as the business changes and new features/content is added.
  7. Sometime later the website owner becomes dissatisfied again and the process repeats.

This approach of sporadic redesign is flawed for a number of reasons…

  • It is wasteful because it throws out the old site and begins again every few years.
  • It is financial painful as a considerable budget has to be found for each redesign.
  • The website owner defines the project alone without the advice and support of a web expert.
  • The user is confused by a dramatic change in the website. This often causes hostility (take for example the campaign against Facebook’s redesign).
  • Choosing the right agency is a huge risk thanks to the large financial commitment involved.
  • The chosen agency lacks the in-depth knowledge of the business required to create a successful website.
  • The site quickly degrades as the business begins to add new content and features. This means that for much of its life the site reflects badly on the business.

Surely there is a better way.

Working in long term partnership

The answer is for the website owner and web agency to work in a much more fluid, dynamic and ongoing relationship. This solves a lot of the problems with the existing system.

Instead of sporadic redesign with its intrinsic waste and enormous one off expenditure, you have an ongoing development process that is constantly tweaking and evolving the website.

Because both parties are working together regularly it gives the agency a chance to really understand the business drivers for the website and how the web can help meet organisational needs.

In turn it gives the website owner the opportunity to build confidence in the agency, so the next time a big project come along there is no risky decision about selecting a supplier.

Most importantly this partnership ensures the website is constantly being given attention, and that the website owner has an outside perspective when making crucial decisions. It also allows him to benefit from the agencies expertise and experiences cultivated from working on other sites.

Of course some of you may have an in-house team that fulfils this role. However do they really?

But we have an in-house team

In theory if you have an in-house web team there should be no need for a web agency who provides an ongoing collaborative role. However in my experience there is a big difference between theory and practice.

Most of the web teams I encounter are unable to fulfil this role for two reasons that are entirely beyond their control…

They are overworked

I am yet to encounter a web team who are not overworked. They are developing new features, dealing with support queries, adding new content and doing endless day-to-day tasks that prevent them from looking at their website from a strategic viewpoint.

Having an outside expert with whom they can discuss the future direction of their site is invaluable. Not only does it help maintain a broad vision, it also ensures that things stay on track and strategy doesn’t get crowded out by day-to-day details.

Let me give you an example. At Headscape we have an outside advisor called Brian who joins us at our board meetings. He serves three roles…

  • He provides an outside perspective that comes from working with many different companies like our own.
  • He forces us to look strategically at our business rather than discussing the delivery of our latest piece of client work.
  • He holds us accountable and will challenge us if we fail to do what has been agreed at previous meetings.

I would argue that every web team needs somebody like Brian.

They miss design details

Most web teams don’t have a full time designer. They are normally made up of content people, project managers and techies. In some way this is understandable. Once a design is set it normally doesn’t need to change very much.

However with the web team focused on content and features there is nobody ensuring the design is maintained. Changes to a website can undermines the consistency in a design that makes a website trustworthy. Suddenly things stop lining up, buttons are styled in different ways and the slick professional feel falls away.

It is also important to remember that design dates very quickly online because of the speed of innovation. It’s therefore important that somebody is keeping an eye on these design details if a major periodic redesign is to be avoided.

So presuming I have sold you on this alternative approach, how does it work practically?

How it works in practice

The key to this approach is one lifted from agile development and is built around a monthly meeting.

Whether our meeting needs to be monthly, weekly or quarterly is entirely up to you. That decision should be based on how much your website changes. For a busy website that is continually being developed you will need frequent reviews. For a more informational site that rarely changes, once a quarter maybe enough. What matters is that the meetings are regular.

The meeting themselves will focus on two areas.

Strategic aims – These meetings are a chance to step back and look at the bigger picture of what you are trying to achieve through the site. This discussion may raise questions (such as what is the competition doing?) or it may identify weaknesses that need addressing. However, whatever the case it is an opportunity to get out of the trenches and see the bigger picture.

Immediate goals – Each meeting should end with a series of immediate goals that need to be achieved before the next meeting. These are practical ‘next step’ actions. They might include a review of the competition or an A/B test on some piece of content. The point is to have some concrete ways of achieving the more strategic goals.

Some of the work to be done will fall to the outside agency, others to the website owner. There may also be times when a third party is required for certain work. Whoever does the work it has to be completed by the next meeting.

This timescale constraint prevents large, time consuming projects that often stall or slip. Instead each development cycle will focus on a few quick fixes.

At the next meeting the actions are reviewed to see if they have been completed before the next steps are set. Once that is done the next meeting is scheduled… and so on.

No strings attached

What is great about this ‘one development cycle at a time’ approach is that it limits the commitment the website owner have towards their agency. If the website owner wished, they could have a single session with an agency and decide never to schedule another meeting if they particularly disliked them.

Equally they could schedule a few meetings and then swap to another agency to gain fresh perspective if the original agency is not coming up with the goods.

Finally, they could choose not to use the web agency for all the work within a development cycle, but to do most of it in-house or even use a student!

There is no contract and no massive expenditure. It is the cost of the next meeting and nothing more.

Of course this is also great in the current economy where management is carefully controlling expenditure. Getting a large redesign approved maybe impossible. However, paying for an hour long meeting once a month is more achievable. The website owner gets all of the expertise of an outside agency, without the long term commitment or big budgets.

Take the first step today

The great thing about this approach is that you can start it today, even if you have no redesign planned and no real budget for your site.

If you have an existing web design agency, give them a call and ask whether you can schedule the first of a monthly meeting to discuss your website. Explain that you are happy to pay for their time, but you want to keep things light weight and flexible. Chances are they will be willing to accommodate you. If they or not, then perhaps it is time to look elsewhere.

If you’re existing agency can’t or won’t help then feel free to drop me an email at Headscape. Personally I relish the opportunity to work with clients regularly and ensure their site finds long term success rather than yet another redesign.

179. Affordance

Posted in Classic shows on by Paul Boag

On this week’s show: Ryan and Stanton are back and we are joined by Mr Marcus Lillington! We talk to Dan Rubin about making your interface invisible and answer your questions about working on multiple projects at the same time.

Play

Podcast: Download (30.8MB)

Download this show

Launch our podcast player

News

RTFM

The first post this week is an article on webdesignernotebook.com from Yaili, in which she has a little rant on the fact that we, web designers, like to complain about how little recognition our profession has, how everyone likes to think they can make a website, and how clients don’t respect our work. But when it comes to actually doing something that could make us a bit closer to any other “official” profession, we’re bored and dismiss it. It’s so much funnier to complain about IE6!

Yaili has made a point of reading through the W3C specifications for CSSS2.1 and 3, HTML 4.01 and HTML 5. While most of us claim to be familiar with the specifications, how many of us – hand on heart – can honestly say they’ve fully read all of them?

The W3C specs are the closest thing we have to a manual and anyone who works in this field should have read them at least once, we don’t have to know them by heart or be able to quote from them, but we should be familiar with what they contain and be able to use them as a reference like any other professional book, as Yaili says, “After all, those specs lay the foundation of what we work on every day, so we should at least have an overall knowledge of them and of what they address.”

I know personally, this post has acted as an encouragement to print off the specs and read them again on the commute.

Structural Tags in HTML5

If you’ve been inspired by Yaili’s encouragement to read the HTML5 spec’s, then the next post might be of interest to you also. The HTML5 specification has added quite a few interesting and useful tags for structuring your markup and will replace many of our typical DIV entries from our code.

Of course this is an audio podcast, so I’m not going to start reading code out for you, but this is a nicely detailed article which explains the new tags such as header, footer, nav, article and aside which you can start using today, and includes a couple of tricks to make current browsers treat them as they should by using the CSS display:block attribute as well as a javascript fix for Internet Explorer.

It’s a nice primer for anyone starting to play with HTML5, so give it a read!

Redesigning your own site

And finally we have an article on A List Apart which touches on those times when you have to deal with your most difficult client. Yourself.

Lea Alcantara discusses her experience and thought process of redesigning her personal site. Your personal site has to demonstrate proficiency in the very latest development and trends in the industry while remaining true to the brand which you may have taken years to establish. Cameron Moll’s mantra of “Good designers redesign, great designers realign” features heavily in this thought process.

The article details Lea’s process from start to finish, explaining certain dead ends – like thinking she could jump right into Photoshop and play – to starting with her branding and letting the design evolve from that. She explains how she consulted with some trusted design friends and urged them to provide objective design analysis instead of personal taste.

While the article is focused on a particular site design I think there’s some good tips in here that we can all take away, or at least keep in mind when we decide to work with our most difficult client.

Back to top

 

Interview: Dan Rubin making your interface invisible

Ryan: You did a really good talk this afternoon on “making your interface invisible”.

Dan: Thank You

Ryan: What does that mean then? *Laughter*

Dan: Select all…. delete

Ryan: Hiding the interface from your users

Dan: making you interface invisible, doesn’t mean what it sounds like. Thankfully. It’s about the idea of designing for the experience rather than for the visuals or particular features or anything like that. Making those blend so far into the background that users don’t even notice them. That’s what I mean by making the interfaces invisible.
It’s not a new concept if you do a couple of searches on The Google, you will actually find even A-list apart article back in 2000 covering the same kind of stuff. It just hasn’t seemed to sink in and one of the reasons that I’ve kind of thinking lately is that there just aren’t enough designers and developers talking about it. Usually you here about the concept of it an interface disappearing being talked about user experience (UX folk) designers or usability experts and consultants. A lot of the time designers and developer just don’t listen to people who are the same us, those who don’t do exactly what we do. We do listen to them but we just don’t listen in the same way. So if we only hear the same kind of advice from people who aren’t doing what we are doing it’s easier for us to dismiss it. I think it’s more important for people who do the actual design and do the actual development to be talking about it not just thinking about it, but doing it.

Ryan: You mentioned in your talk your talk was targets at not just people who design interfaces but (I can’t remember how you put it), not just designers who push pixels around who do the actual visual design. I’ve always associated interface design with that.

Dan: The thing that I’ve learned from clients (first of all) and then then I realised it applies to all of us. Is that when people hear the word “design” they think that it’s something visual and it’s not. The concept of design is much more basic, its creative problem solving. I mean it can be called a lot of things, but design isn’t just a purely visual task and you can design thing without any visual element. People who design applications aren’t designing the interface to the application; they are designing the interaction, that’s why we have so many. The answer to that the industry has come up with is to come up with a lot of different terms that your experience designer, that your interaction designer. The reason we have to come up with these terms is that people hear design on its own and they think visual. But that’s a visual designer, a graphic designer an interface designer. If were just talking about the process of design, it’s something that everybody is a part of. Whether you’re a developer, an information architect, an interface designer or you’re an amateur, it really doesn’t matter. Your part of the design process. It’s a much bigger concept, that’s why when talking about the idea of designing for the experience, trying to design the experience itself rather than specific parts of it and making sure those parts blend into the background. People just come away having a wonderful experience. That’s why everybody in the team on a given project has to be a member of the design process, otherwise that won’t happen.

Ryan: In your talk you mentioned mimicking physical interfaces and you were kind of talking about trying translate what we do in the real world into your interfaces and those kind of experiences, it’s that right?

Dan: yeh, well there is this concept that we all know, we all talk about look and feel. That’s a common phrase that’s used a lot. But a more specific concept and term that I recently discovered called “affordance” and it’s been around for ages. It’s not new to people who are cognitive psychologists or who are in product design and it really we do the same thing with interface design. Any that’s designed for the screen, especially if it’s designed to be used like applications are. What we are really doing is designing products and software designers again know about this, but for some reason in the web world we’ve got a lot of people who haven’t come up through the traditional lines of education, which includes a lot of that psychology background. Which is fine as long as we are open to learning this stuff and realising we should know it. It all exists and has been around for ages. It’s basically the principal that allows us to interact with objects and interfaces in the real world, outside of the screen, and understanding that we use the size the shape the texture and constancy of things that we interact with in the real world to know how to interact with them before we touch them. And that’s the concept of affordance. That’s what it’s about those aspects of an elements design and construction or what not, that us to know exactly what to do with it and how we can interact with it. There are a lot of great examples of this in Donald Normans book the design of everyday things, which is a product design book essentials but so many of the principals apply to what we do. Not just interface design but again the design of applications and design of interaction. People are using what we build and that’s no different to people using a product that you’ve designed and engineered. We are designing and engineering what ends up being a total experience, it’s not something we can hold in our hands like a physical product but it’s a virtual product.

Ryan: You mentioned that you shouldn’t have to describe your interfaces; they should be intuitive to use.

Dan: I’m very against instructions in interface design.

Ryan: this leads me catching you taking pictures in the men’s toilets earlier.

Dan: Yes, this could be seen as compromising. But …erm… (Ryan has a little giggle fit) I do that all the time.
What I’ve found once is that now that I’ve started looking outward because I didn’t start as a designer in interface design. I started as a graphic designer and doing print. And so I’m always looking at things in the real world for inspiration. For whatever reason in the past year or so I’ve started actually realising how many direct parallels, 1 to 1 parallels there are in the real world with these interfaces that are all around us, they are just 3 dimensional. We just interact with them physically instead of through the intermediary of the mouse or the track-pad and the keyboard. And really they are not that different and so the examples in the restrooms, they are full of them for some reason whether its public restrooms or private stall in a hotel where something clearly hasn’t been designed to be intuitive and thus it needs printed instruction. It doesn’t mean instructions are bad, there are something’s that are so complex that they can’t be simplified beyond a certain point, so they need some sort of instructional text. But far too often we use instructions as an easy out, where we design something that really should be more intuitive, but instead of going back and redesigning it we put a little help icon next to it (or a little bit of help text when someone hovers over it). Or we will just put up a help page, before someone begins a task, and we expect people to read this stuff. The fact is people notice it’s there, they don’t always necessarily read it but they know it’s there and so it’s adding visual clutter that is probably not necessary. If you redesigned that interaction you could get rid of the need for instruction, you make intuitive there is no need for explanation. I think it’s a good marker in the design process that if you find an element of your interfaces requires instructions then you need to redesign it and keep refining and redesigning it. It may not be a refinement it maybe redesigning it from scratch but if you’re always on the lookout for that, like “Is this intuitive? Does this work without someone explaining how it works?” if you keep on doing that you won’t dig yourself into a hole.

Ryan: sorry I’m just chuckling to myself about your toilet reference. Realising that the last person I interview was Elliot J Stocks and I began that interview with “Hi Elliot the last time I saw you were outside a men’s toilet” (fits of laughter) I’m going to be getting myself a reputation.

Dan: it used to be the water cooler and now apparently it’s the restroom.

Ryan: we have to clear up the reason the men’s toilet reference was because you were taking a picture of a diagram of the showing taps and a description.

Dan: the taps that we are all familiar with now that are motion sensitive that don’t have taps anymore to turn them on and off, you just put your hand under it. And that design is not new it’s been around, I’ve never seen one with instructions because it is intuitive. They haven’t broken this one the one in the restroom here just works but even though I knew how to use it, the fact that I saw that descriptive image and text next to it. And its next to every single sink, it was a distraction. So where I would have been able to just go and put my hands under it, for a split second I was distracted by oh what’s this instruction. It made me think that it was something that I didn’t know how to use and that’s where instructions can be bad as well. Maybe you’ve added it in because you mean well, not because you need the instructions but you think that it will help the user by having them there. That that extra bit of information never hurts and that’s actually the wrong thing to do. It has the opposite effect, it adds clutter. If something is intuitive then you’ve spent the time designing it well that people don’t need instructions, by adding them you are actually making it harder to interact with.

Ryan: its weird (repeated… 3 times?) weird occurrence isn’t it. You also mentioned looking at desktop application design and translating that to the web, I found that really interesting. Can you talk about that a little bit?

Dan: yeh, there is a lot we can learn about interface design from the desktop. We can’t do everything on the web and even with things like adobe air and flex we can’t do everything we can do we can when building desktop applications. The thing is that basic interface conventions have been around a lot longer than any of our interface conventions, that we tend to think of being created on the web. The fact is that they haven’t there are very few things that are web specific. One of the things being the silly little Mickey mouse hand icon that we mouse over a link, that’s one of the main examples that I gave. In the desktop we have a much more precise pointer mouse or the default mouse pointer rather (the arrow) whether you’re on a Mac windows or Linux it doesn’t matter. It’s consistent, it has a very specific point, you know at the very tip of that there is one pixel that we use to interact with whatever we are clicking on. It’s much easier to use and target something accurately. Whereas the Mickey Mouse hand is more vague, there isn’t a single point that is clearly defined in the icon and on top of that it only appear once you’ve already began your interaction with something. Developers and designers we tend to work with the web and applications very differently than most users. We’ll mouse over things because we want to see whatever hover effects there are, we appreciate maybe the idea of discoverability in an interface more than the average user. Whereas a regular user (if I can make such a general statement) will look at an interface and without moving their mouse around, they will decide what they want to interact with before they then go and interact with it. So if the only way of knowing something can be clicked on is mousing over it and seeing that hand icon appear it’s not intuitive. Something can easily be missed and so what I suggest is to take a cue from the desktop and only use that hand icon for what it was originally designed and that’s hypertext links. So if you’ve got a link that you’ve underline in your text on a webpage or in a web app, as long it’s an underlined text link in the body of text use it, leave it as the default. Everywhere else if you use that default mouse pointer it’s much more like using a desktop app and it’s much more precise and it forces you to design something that looks like you can interact with it before the mouse ever gets near it.

Ryan: do you think people are just possibly used to the mouse cursor changing to the pointer, and if you took that away, that could possibly have a detrimental effect rather than a positive effect?

Dan: I don’t think so, I think we are as the creators of the web. But based on the fact that I still see some users trying to double click things on the web for instance, that is a connection that none of us on the web “we don’t do that”, and that in some instances that we should. There are some instances through JavaScript where we can do that, basically if a convention exists we should try and use it because it makes for more intuitive experience. So if we have an interface in a web app that require folders for instance, and that are folders that are more like on the desktop rather than a list in a sidebar, it makes sense that we if it was a desktop app that we double click it. We wouldn’t just do a single click, so let’s make that web app respond with a double click because that’s what people tend to expect. The mouse point, that Mickey Mouse hand isn’t something people expect, because it doesn’t happen until they have already made a decision. Maybe they are used to it appearing but it doesn’t affect their decision making process and because of that if you eliminate it what you will find is people won’t notice it’s gone. You will be designing thing people know they can click on and all they are interested in is mousing toward it and clicking on it. If it looks clickable they won’t expect that cursor to change as much, otherwise people would not be able to switch from using a web browser to using a regular desktop app because that hand never appears. If they were reliant on that they wouldn’t be able to use the web for an hour and then use a regular menu-ed app, they would be confused about how the cursor wasn’t changing but that’s not how people work.

Ryan: I think as well how many times have you seen people where they look at a file structure and expect to be able to right click on a folder and have all the options that you normally have. And just because that’s they are familiar with.

Dan: exactly and that’s what I talk about learning from the desktop, that’s the kind of thing that I’m talking about. The desktop has been around and creating these conventions for a lot longer than the web has. Users have been using desktop apps longer than they have the web, maybe you can find younger users who are coming to the web first and barely using desktop apps, it doesn’t mean they don’t use their operating system, they do. They use their web browser too. Those are the first thing they interact with when they start up the computer. Until we get to the point where (and I hope this point doesn’t come) if we had a device that was only a web device and had no other interface than the web then maybe you could make an n argument for it. But I think that would be a bad thing, I would rather see the web and the desktop come together as far as interface conventions and how we work with them in applications. Rather than being web applications, I would rather see them just being applications and when you use them you don’t think about if you’re using something that’s running in a web browser or that’s communicating with a remote server rather than your hard drive. You’re just using an application to do a task, there shouldn’t be a distinction and I don’t think that users have as much of that distinction that we do as developers. We like to think that there is a huge difference between a web app and a desktop app, but the for users it’s likely they don’t think of it in those terms. This is where I complete this task they don’t think that Gmail a web app it’s not a necessarily a web email app it’s their email. It’s their inbox, that’s how they think of it and we have to understand that’s how users perceive what we do. It’s a very very different way to look it.

Ryan: Especially as the barriers are disappearing, things like adobe air for tweet deck and emailing to outlook and mail. And the walls are just fading away.

Dan: Which is a good thing, as those walls fade away we need to as practitioners on the web we need to take as many cues as possible from the desktop and help make that transition more seamless.

Ryan: you mentioned a few resources in your talk, and I bet you can’t remember them…

Dan: Actually I can. I remember…
Jared (I would remember him anyway) – he has uie.com has excellent resources about all sorts of things about usability and that’s ultimately …that’s what this is all about usability. The article I refer to at the end of the talk of Jared’s was one he published the exact same day that I came up with the description for the idea of this talk that I gave today. So it was an odd moment and it’s about the exact same thing that this talk was. Keeping your interface invisible.

Ryan: and your talk previously

Dan: well yes we have been doing work with Jared, we have been very lucky to do a couple of workshops with him. It’s always fun to share the stage with him; it’s even fun to chat with him over dinner because you always learn something. You always come away with a smile on your face even if all you learned was how to laugh and enjoy his magic tricks with the card deck. It’s always enjoyable, so hes a great resource, his site is great resource. And UIE as a company is great resource if you’re looking for information about user testing, usability it’s the place to go. And the article is very recent so look on his site and you will see it on the list of articles a specific lot about invisible interface design and the experience.
I also reference Steve crouges book don’t make me think, which is awesome, excellent, funny, good, and thin. All the things a book should be. Educational, easy to read and short.

Ryan: plane flights worth it isn’t it

Dan: exactly yes, if you don’t have it you will get it and read it and find yourself going back to it again and again and dog ear it and mark it up like crazy and you share it around and sometimes don’t get it back.
And the other book by Donald Norman, the design of everyday things. It’s really a product design book but it’s useful for anyone who deals with designs that are meant to be used by someone else.

Ryan: have you seen thedieline.com product design website.

Dan: no I haven’t

Ryan: it may have been Elliot J Stocks last time he was on I believe it’s just the thedieline.com And it’s looking at product design. They release a series of particular products like an aerosol can or packaging for a toy and look at all different packaging. It’s really interesting.

Dan: I will have to look it up.

Ryan: it’s a really good site

Dan: I eat that stuff up because the more I look outside of the web the more I find that everything that we are doing, that we feel like we are discovering for the first time has already been done. A lot of it has already been done, especially the basic concepts of product design or we talk about information architecture all the time, but we didn’t invent the term. It’s been around for decades and possibly even decades before the web was around. And it comes from architecture and way finding enviromatnetor graphic design, these are concepts that people have been thinking about for a lot longer than we’ve been thinking about them. Possibly for a lot longer than some of us have been alive. I think it puts what we do into perspective; first of all there is a wealth of information and knowledge out there that’s been proven which can help convince us and our clients. If we are going to someone and we are explaining the idea of information architecture to them and we’re not just explaining it as something new in particular for the web. This thing has been around since before the web was even thought of that making it a whole lot easier to gain credibility with clients. It’s not just information architecture it’s so many of these basic principles of interaction, they are all basic psychological principles of human interaction really.

Ryan: what was that word you’ve been using all day again?

Dan: affordance – look it up its good stuff.

Ryan: ok Dan, well thank you very much for taking the time to interview you.

Dan: thanks for letting me ramble on

Ryan: it’s been a pleasure to see you again

Dan: always. Thank you

Much thanks goes to Andy Kinsey for transcribing this interview.

Back to top

 

Listeners Questions

Stories of our failures

Dinu writes:

Looking from afar, established agencies like yours seem to be almost perfect. However, I’m sure you’ve had to deal with missed deadlines, over-booking, etc. I would like to hear about some of these #fail stories (just to get a “you are not alone” feeling for the rest of us), and also to know how you managed to overcome these common pitfalls.
Hope this question gets a chance of being aired.

Thanks and stay awesome….

Transcript coming soon…

Working on multiple projects

Emil Sundberg writes:

Hi,
I’m running a small web agency and I just found your podcast. Great show!

We’re a small team, 4 people, doing web development for clients and use Basecamp/Backpack/Highrise/Campfire (yes we’re 37signals addicts) and I think it would be interesting to hear you talk about how you work with your team in the big picture, not an individual project. How do you plan multiple projects with a limited staff? Who’s deciding what’s most important and what should be done next. Do you use and planning tools or an Excel/Whiteboard?

Transcript coming soon…

Back to top

 

161. In or Out

Posted in Classic shows on by Paul Boag

On this week’s show: Paul announces Micro-Boagworld, we discuss the pros and cons of outsourcing web work and see what recommendation the Boagworld forum has to offer.

Play

Podcast: Download (20.2MB)

Download this show.

Launch our podcast player

Housekeeping

For a while I have been toying with the idea of doing a Micro-podcast that works in a similar way to Twitter but with audio. It would provide the opportunity to share hits, tricks and reviews too short for the main show. My problem was that I needed an application which made this as easy as posting a tweet. Anything more and it would prove too demanding.

Fortunately a new iPhone application has launched that does exactly that. Called AudioBoo it allows you to record 3 minute audio snippets that then get posted to a website, twitter, facebook and a podcast feed.

I am therefore pleased to announce Micro-Boagworld…

View Micro-Boagworld posts here

Subscribe to the RSS feed here

Boagworld AudioBoo Homepage

Back to top

News

Pricing and projects

Alyssa Gregory has written two good posts this week both relating to the pricing of web projects.

The first post tackles the notoriously difficult subject of How To Estimate Time For A Project. After all, time is money.

Estimating how long a project will take is tricky and although this post doesn’t provide any magic formulas it does provide good solid advice.

As well as considering the obvious deliverables Alyssa also recommends time for project management, reviewing work, debugging and client turn around. Finally, she recommends adding a buffer for the unexpected.

Of course, she doesn’t discuss how all of this time translates into your final price. How much you charge is a matter of conjecture. However, in a second post she does explore a related subject – How To Raise Your Rates.

In this post, she handles the sensitive subject of how to tell a client that you will be raising your rates for future projects. She suggests five techniques you should employ…

  • Give Notice
  • Set a schedule (make increases annual for example)
  • Make it fair (keep the increments small and manageable by the client)
  • Send it in writing
  • Balance it out (Balance your increase with an incentive – e.g. a special, a one-time discount)

Its all good advice and important too. As your skills and experience increase, you will need to ensure your rates reflect that. Knowing how to hand those rate increases is vital if you want to keep your clients happy.

IE8 and IE6

Microsoft have announced that IE8 will be released via the Windows Automatic Update starting on the third week of April.

The final version of the browser has been available since March and yet adoption has been sluggish. Hopefully Automatic update will change this trend significantly. However, it does not guarantee universal adoption. Although the update will be marked as important users will not be forced to upgrade. In fact Microsoft has released a blocker toolkit so corporate users can avoid the update entirely.

Worst of all, it is likely that the update will impact the numbers using IE7 more than IE6. IE6 users tend to be hold outs and are unlikely to upgrade now when they did not upgrade to IE7.

The only hope is that many IT departments have a policy of running a version behind the current release. If that is the case, the arrival of IE8 may encourage some of them to adopt IE7.

The entire web design community is keen to reduce its level of support for IE6 and hopefully this update will allow that. In fact, another post this week entitled – 10 Cool Things We’ll Be Able To Do Once IE6 Is Dead – points out just what a wonderful world it would be.

Once IE6 is gone we will be able to…

  • Use child selectors
  • Make full use of 24-bit PNGs
  • Use attribute selectors
  • Use a wider range of display properties
  • Use min-width and max-width
  • Throw away 90% of CSS hacks (and 90% of the reasons for needing them!)
  • Add abbreviations that everyone can see
  • Trust z-index again
  • Save time and money
  • Enjoy ourselves again!

Simple and impressive design techniques

Last week I was doing a consultancy clinic with a developer who wanted advice on designing his website. He was a great coder but did not have much experience designing.

Although I recommended The Principles of Beautiful Web Design by Jason Beaird it would have been great to point him at the latest Smashing Magazine post – 10 Simple and Impressive Design Techniques.

This post has some easy to implement techniques that are ideal for developers trying to improve their design skills. Techniques include…

  • Adding Contrast
  • Using Gradients
  • A Better Use of Colour
  • Improved Letter Spacing
  • Changing Case
  • Use of Anti-Aliasing
  • Adding Imperfections
  • Implementing blurring
  • Careful Alignment
  • Trimming the Fat

Read the whole articles for more details and great examples of these techniques in action.

Influencing user behaviour

A big part of good design is guiding the user to complete the actions you want. Influencing user behaviour can be achieved through a variety of techniques. However, it can often be hard to know where to begin.

One resource that might help you influence user behaviour is The Design with Intent Toolkit. This is essentially a printable ‘cheat sheet’ that suggests a variety of techniques you can apply to your projects.

The techniques do not just apply to web design but all aspects of design. Consequently not all of the techniques will apply. However a lot do, ranging from the use of metaphors to setting up good default options.

Some of the techniques contained in this cheat sheet are also beautifully demonstrated in another post I wanted to mention. Entitled 12 Excellent Examples of "Lazy Registration" it addresses the problem of user signup.

Essentially it is a post that showcases methods for getting around the problem of user registration. As the post itself says…

Signup forms have long irked the casual visitor. During the process of discovery, nobody wants to stop and fill out details before they can "unlock" the rest of the site’s potential.

It has certainly been my experience that signup forms are a barrier and so it is interesting to see how different web applications have overcome the problem.

Back to top

Feature: When to outsource web work

Your in charge of your organisations website. It has become moderately successful and now you have a decision. Do you hire a full time web designer or outsource to a web design agency?

Read the full article

Back to top

Listeners feedback:

In this week’s listener feedback section we look at a series of recommendations from the Boagworld forum…

A good introduction to Javascript

Jake writes: I’m curious as to whether or not anyone on the forum has strong opinions on a good introductory javascript book? And by introductory I mean something that’s more about initial learning steps such as syntax, etc. and then talks about best practices.

Doug answers: You might want to look at one of the books out for coding in jQuery, if you’re planning on going in that direction anyway. As for how to learn javascript I usually push people towards Lynda.com.

Matt also replies: Awesome book – DOM Scripting – I’d start with this before jQuery as I think you need some javascript knowledge to use jQuery to its fullest.

A good but free survey tool

Simon asks: I want to create some simple(ish) survey’s to get clients to fill out after a training session. I know of some paid for solutions, but does anyone have any suggestions for any free tools?

Laura replies: For something short, I’d use the survey function on PollDaddy. You can get up to 100 responses, and I think ten questions. Ten isn’t many, but you can do conditional branching for free, which is rare, and good.

I’ve also used SurveyMonkey before, it’s clean and simple.

A review of Clicktales

Peter shares his experiences of Clicktales…

On the recommendation of Paul, I tired out ClickTales.com; and I have to say the results have been interesting (sad, in my personal case) to say the least.

For those of you not in "the know", or missed episode 141, ClickTales is an app that lets you record and review the actions of your website’s visitors. And I’d agree with Paul: inexpensive, revealing, but limited in essence because you can witness what a user goes through.

In my case it was most effective because my results have been telling me that I should redesign my website’s structure completely… so I decided I should start from scratch all together and redesign. :)

Web Design for ROI

Bill reviews Web Design for ROI by Lance Loveday & Sandra Niehaus…

Each year I find one or two books that really stand out. This book, Web Design for ROI, changed the way I look at current eCommerce projects and helped me identify better strategies for building web sites.

Rich adds: I agree this is an excellent book.

Not too much new for a seasoned pro like myself, but I did still learn a fair bit and I’d recommend it to anyone with an interest in websites that make money.

Pro Paypal e-commerce

Finally, Ian shares an extensive review of the book ‘Pro Paypal e-commerce‘. Ian writes a very thorough review but here are a couple of highlights.

I thought this was a great read. It’s not often you finish a book and feel confident you have all the information you’re going to need to complete your project. The book isn’t just technical but also has lots of useful nuggets on business practices and background on payment systems in general for those that are unfamiliar with them at this level.

I feel confident in recommending this book to anyone who is involved with developing E-commerce systems or is going to be in the future. The author Damon Williams has a very readable style that is mercifully faux-humour free but never dull and explains everything clearly and concisely and despite its relatively low page count at 260 pages or so, still manages to cover a lot of ground without ever feeling as if it’s being too terse.

For more reviews about everything from web design books to software visit the Boagworld forum. We are also going to do some cool new stuff on the forum over the coming weeks. Keep an eye on it. We have already added a Jobs category for those of you who are looking to hire a web designer, so be sure to check that out.

Back to top

 

Three secrets to simplicity

Posted in User experience on by Paul Boag

Many website owners damage their sites by continually adding features and content when they should be simplifying. In this post I reveal why that happens and how to simplify your website.

In my post ‘5 options when website budgets get slashed‘ I explained that many organisations waste money adding ever more functionality and content to their sites when they should be simplifying. Unfortunately it is much easier to add content than take it away. But why is that?

The 3 lures of complexity

In ‘10 harsh truths about corporate websites‘ I outlined 3 reasons why website owners shy away from removing content…

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

However, I think there is more to it than that. First, there is a general laziness. It is easy to leave content online. It takes effort to remove it. Second (and more importantly) there is a desire to please users. If a user asks for a feature or piece of content, we feel obliged to provide it.

3 questions that encourage simplicity

Adding functionality requested by users is not always a good idea. You need to ask 3 questions…

  • How many people are asking for it? – If only a few people request a piece of functionality, there may not be the demand to justify the time and money.
  • Who is asking for it? – If it is not being requested by your primary audience then you should probably not be building it.
  • How will it affect others? – With new functionality comes complexity. Will that functionality confuse some users? Will it distract from your main call to action?

What then do you do if your site has become overly complex? How do you achieve simplicity?

3 steps to achieving simplicity

According to ‘The Laws of Simplicity‘ there are three practical ways you can simplify anything, including your site. These are:

  • Remove elements
  • Hide elements
  • Shrink elements

Let’s look at how these steps work in practice.

1. Remove

Headscape Website

The first step to simplifying your site is removing unnecessary content. This is by far the hardest step for the reasons I have outlined above. However, it is necessary as Steve Krug explains in his book ‘Don’t Make Me Think.’ He identifies two benefits of removing content…

  • It reduces the noise level of your site
  • It makes the useful content more prominent

Removing content really does make a difference. We applied these principles to our own website at headscape.co.uk and saw a significant increase in conversions (those visitors who request a quotation for our web design services) and some amazingly positive feedback on the site itself.

In fact we took the principle so much to heart that we went from a 40+ page site down to a single page! Of course, that kind of radical approach is not for every site. However, even removing some content can make a huge difference.

2. Hide

Unfortunately, it is not always possible to remove as much as you wish. Sometimes you need to keep content to serve secondary audiences. That is where hiding content comes in.

It is important to cater for secondary users, but you do not want their content to distract or confuse your main target audience. Instead of removing their content, you can hide it deeper within your site or within the interface itself.

Menu on the Wiltshire Farm Foods website

An example of this is a recent homepage redesign we completed for Wiltshire Farm Foods. Most of their sales come from 6 categories of meals. However, they also offer a number of other categories. On their old homepage the 6 main categories were lost among the other categories. Users felt overwhelmed by choice and sales were lost.

One option would have been to reduce the number of categories to focus on the 6 big sellers. However, this would upset a sizeable secondary audience. So instead, we hid some of the categories under a show more link. This meant that their secondary users could still be served, without overwhelming the primary audience.

3. Shrink

Finally, there are occasions when content can be neither removed or hidden. This is often because the content is of critical importance to a secondary audience and needs to accessed quickly. In such cases the content can be shrunk.

Take for example University websites. Their primary audience is almost always prospective students. However, they also cater for staff and existing students. These people need quick access to intranet tools such as the institutions address book. The solution is to add a small inconspicuous link on the homepage that takes them quickly to this content. By keeping the link small (shrunk) the site serves their needs without distracting or confusing the primary audience.

A similar approach was used on the Wiltshire Farm Foods new homepage. However in this case the content was actually shrunk.

Because of the elderly demographic it was important that we provided lots of help to new users. We therefore wanted to dedicate a substantial amount of homepage real estate to meet their needs as they arrived. Our solution was this…

WFF get started guide

Unfortunately this became distracting once the users were familiar with the site. It became a usability hurdle. One solution was to remove it. However, this would make it impossible for users to refer back to if they became stuck. The next option was to hide the content elsewhere (for example in the help section). However, previous usability studies of this demographic showed they develop ‘habits’ in the way they navigate. If we moved these links that they relied upon, it could prove confusing.

Our final solution was to shrink the content. So instead of moving or removing it we simply collapsed it…

WFF get started guide, collapsed

This meant the content continued to be accessible but did not become a distraction or take up too much real estate.

Conclusion

Although the ideal scenario is to remove content, it is also possible to simplify in other ways.

This should not be mistaken as an excuse to avoid removing content. However, you could use hiding and shrinking as the first step towards removing. If these techniques do not alienate your users, then it maybe appropriate to remove that content entirely.

Whatever the case, we should all be looking for ways to improve our sites by simplifying rather than adding more and more content.

152. War?

Posted in Classic shows on by Paul Boag

On this week’s show: Daniel Burka and Joe Stump from Digg discuss the supposed war between designers and developers. Paul talks about using twitter effectively and we ask ‘are you placing too much emphasis on your homepage?’

Play

Podcast: Download (34.0MB)

Download this show.

Launch our podcast player

News and events

How to film video case studies

Increasingly your web strategy is about more than a website full of pretty pictures and well written copy. Video in particular is playing an increasing role, whether it is embedded in your website or shared via YouTube.

Video can be used in all kinds of ways from product demonstrations to viral marketing. However, a growing use for video is customer case studies.

This week 37 Signals have published a fascinating insight into how they created their customer case studies for Highrise. The article covers everything from…

  • How they chose who to interview
  • The way they shot the videos
  • What questions they asked
  • How they conducted the interviews
  • How they edited the videos
  • The time they spent preparing the whole thing

There is little written about producing quality videos and even less about customer case studies. Without a doubt these kinds of videos are extremely powerful and so it is great to read quality advice about their production.

Effective communication in web design

Smashing Magazine has posted an excellent article that I would highly recommend to all website owners. No, it is not my excellent Twitter article that I will cover later. It is actually an article entitled – Clear And Effective Communication In Web Design.

In essence it talks about how to communicate on the web through both copy and visuals. It is a comprehensive overview (if somewhat superficial) of all the key considerations of communicating effectively through your website.

The article focuses primarily on your website, largely ignoring broader communication issues. However it does tackle…

  • The different methods of communication – Images, text, titles, icons, design styling, colour, audio and visuals.
  • The challenges of clearly communicating – This includes the curse of too much copy, the need for personality and much more.
  • What you should be communicating – Your company vision, the websites offerings, the benefits to your users and calls to action.

It also nicely demonstrates how the design and copy work together to communicate your message. This is something I will be discussing with Jeffrey Zeldman in an upcoming show.

Do we place too much emphasis on the homepage?

Following on nicely from my recent post about where we invest our money, Christian Watson recently wrote about one of his clients who requested a homepage redesign.

In the article he writes…

Sure, I could refresh the colors and move some content around. But is this a good use of my time and her money when the home page represents 20-25% of page views?

It is a good question. Christian goes on to argue that we often place far too much emphasis on the homepage and that in fact it is little more than a gateway page to direct users to more important content.

He uses a nice analogy borrowed from Jared Spool. He compares the homepage with a hotel lobby…

When visitors arrive at your hotel, certainly they should find that the lobby represents the hotel favorably. It should be attractive, spacious, with elegant lighting, welcoming colors, and the odd feature here and there.

The lobby should make it easy for the visitor to orient themselves — to see where the front desk is and where the lifts are. It should make it easy for the guest to find out any important information at a glance — upcoming events or where the conference is being held.

However, hotels are ultimately judged by the quality of their rooms.

It is an excellent post that provides real food for thought.

Back to top

Interview: Joe Stump & Daniel Burka on War Between Designers & Developers?

Paul: So I am really excited to have joining me today Daniel Burka and Joe Stump from Digg. Hello Guys

Daniel: Hello

Joe: Hey hey

Paul: I have had both of you on the show individually and Joe you were on not long ago were you really…

Joe: ermhh yes a couple of months ago maybe

Paul: What can I say, we cannot survive without you. So erm but I though lets bring the two of these wonderful people together and talk about designer,developer relationships and how the two of them get on together working at Digg. I mean I have to say this is just a rip off really isn’t it, it’s a rip of a panel you did. Was that Future of Web Design (FOWD) you did that panel?.

Daniel: Yes it was Future of Web Design in New York. I think we are rehashing the panel at South By South West (SXSW) this year so if anyone is there it would be awesome if you dropped by.

Paul: Excellent, I need to persuade you two to come along to the SXSW live Boagworld as well, but I will hassle of of air so that you can back out if you want to without committing yourself live in a interview.(Paul laughs). OK so lets kick off by talking about the designer and developer relationship and really I think that it strikes me there is a lot of mythology around this that you know designers and developers hate one another and I am not convinced it actually works like that in practice. When you guys did your panel at FOWD you actually were agreeing on a lot of points so I though we would start of by maybe highlighting some of the differences and then look at ways of working together er mm further down the line so lets talk about to begin with what you guys see as the main differences in outlook I guess between designers and developers. How do you look at the world in different ways, do you think? Maybe Joe do you want to kick us off. How do you think developers see the world differently to designers?.

Joe: Sure I think erh developers are definitely, their default kind of response erm is that they would rather, I always make the joke that coders by default are lazy, good coders are extremely lazy people that’s why they’re good coders because they want to automate as much of their lives as possible. Ermm so I think that erm developers tend to get a little complacent when it comes to the actual erm product sometimes because they are so busy and so interested in and so worried about the actual code or the more nerdy side of things you know like are we running the latest greatest versions of different softwares. Developers also tend to be a lot more interested in what the new hip nerdness is as opposed to what’s actually going to make the product better for users, you know so like I have been in product review meetings where people are like “well Why isn’t this new version of some strange bizarre open web specification that nobody has ever heard of ahead of some major forward user feature” . (laughs)

Paul: (laughs)

Joe: So ermm I think that that tends to be like a big difference. The designers you know it is their job to be curators of the website in my opinion and kind of move the user experience forward and often times developers don’t have a whole lot of interest in that. (laughs)

Daniel: On the flip side of that if we are both going to slag our own professions ermm I think designers are often you know pushing unrealistic goals. They are interested in building you know the perfect product and you know aiming straight for that instead of looking pragmatically at doing things in steps and figuring out what is technically possible and I think there is also a gap where designers can only see sometimes what features that they can view and don’t understand, don’t see the vision, of where developers can see you know amazing things they can you know do pro grammatically that designers just aren’t envisioning.

Paul: Yeah

Joe: I think that’s er is another key difference that I know that there is a lot of, there have been struggles and tensions between Daniel and I in the past over this idea of a holistic approach to design where where Daniel designs his vision and his vision is normally version 10.0 and I am looking at you know the technical roadmap and things that I need to do and like I am OK well lets talk about version 1.0 and then we can start talking about 2.0 like, developers are much more focused on an iterative process as far as releasing, you know like small chunks, reducing risk etc. etc. and designers tend to kind of like go well erm you know it is like I wanna build a pyramid it’s like great well how about first we start out by finding some limestone and then we work our way up to building a pyramid.

Daniel: So what you are saying is we have got a fantastic optimism. (laughing)

Joe: Yes

Daniel: But I think that’s partly it. Developers are very interested, as Joe was saying,in mitigating risk and in a lot of ways designers are very adverse to even thinking about risk and want to think about opportunity. So I think this is kind of the crux of the whole thing and what we are trying to talk about on that panel is that both of those views are super valuable and if you manage to find the right mix of those two things then you can develop a fantastic product that is both concerned about risk and pushes the boundaries of what is possible.

Paul: Mmmm I remember one point that came out from the presentation which is one that you made erm Joe which is about the dangers of if that mix is not right. It is always the designer that’s in front of the client or the boss or whatever ermm the kind of realism of the developer is kind of left out of the process and ideally the developer either needs to be involved in those kind of meetings or there needs to be a conversation that happens between the designer and the developer before anything is ever presented. Is that kind of, do you still feel like that is that still a valid point?.

Joe: Yeah, I feel that is a extremely valid point for two reasons erm and this is a discussion that Daniel and I just had yesterday in fact. The thing is as a developer the reason I want to be involved early on in the development or in the design and like development of the product phase you know when requirements are coming together and when you know the first kind of formations come out of the clays so to speak is because two reasons. One ermm and they all kind of come back to this same kind of problem, is that the designers and the product people don’t know the system, the actual bits and bytes that like you know go into making the product, as well as the developer like the data and the code and the actual systems and stuff like that and how they are put together. So Often times two things happen Daniel comes up with a design and there is like one small minute detail on the page that would require you know one of the largest computer farms in the world to calculate in real time. Whereas in lots and just as often as you know that happens where it is like Daniel I can’t calculate that number in any meaningful way on a regular basis so you gotta remove that. But just as often as that happens because of you know as a developer I have such like intrinsic knowledge of the relationships in the data and what data we are storing and stuff like that just as often I am like well why don’t we expose this data or do this and Daniel is like I did not know we could do that actually I totally would have done that if I had known that that was possible or feasible.

Daniel: Yeah and that’s, especially that side of things designers often hear the first part Joe is talking about, the you know well that is just not possible or more difficult than you think. Any designer that has worked with a developer has heard that aspect of it you know and that is of course very valuable but it is the other side of things that I think people fail to leverage most frequently is the ability of developers to see different patterns than you in the data and come up with those suggestions, you know it might still be your call whether or not that is a valuable thing for the user but just hearing these ideas coming out is is amazingly valuable. That has shaped a lot of Digg.

Paul: So would you say that is a kind of you know a common mistake that maybe designers make with developers that they don’t communicate enough with them ermm

Daniel: Absolutely

Paul: yeah

Daniel: Designers often see developers as mules its like I made this thing go build it and that is a bullshit attitude, its terrible.

Paul: mmmm what …

Daniel: Its not just designers either all product people have a tendency to do that. In some ways, as Joe was talking about developers being involved in the process, at Digg we’ve got a pretty good structure where design actually falls under the marketing team and in some ways I see design as a bridge between marketing and business development you know product interests and the development team. Because I am often sitting over here and I hear you know someone from business development or marketing throwing around an idea and I am like “I’m no developer but I have a good sense of what the developer sees as important and you’re talking crazy talk like that is going to be nuts” and they are about to go and pitch that to a potential partner and you know like every week I put the brakes on from that kind of thing I am like listen you need to talk to Joe you need to talk to a developer because that what you are talking about is going to be months of development and you are promising it to a partner in two weeks that’s nuts and so I like that in you in some ways the design team can often be a bridge between product marketing people and the technical teams.

Paul: Joe from your perspective what kind of, you know as your communicating with Daniel and other designers within digg looking back where do you think you’ve made mistakes in your relationship with designers?.

Joe: Ermm I mean the mistakes that I often make ,its a not even a mistake are I don’t wanna say are what we do are like flat out mistakes it’s just more ermm you know being a bit more reserved and not necessarily defaulting your answer to no. Err You know I think that Daniel often talks about how a natural tension between design and product and development is actually good for the product because you have eventually, as long as you can keep that at a good tension and not you know bad or where things are breaking but ermm I think often times developers are quick to say no. You know they will be sitting in a meeting and it is just immediately no I am not going to discuss that when in reality if they sat back and let the idea germinate you know they would, Its kinda weird because I have in a lot of meetings where things were, where the developers were like be oh my god that is an amazing product but we will never be able to build it and so it is like they want to build it but their default is to avoid risk so they say no. So a lot of the times when I talk with Daniel now and this is something I like quit doing I try not to say no unless it is just like blatantly in black and white no way that is possible kind of thing. I might let the idea germinate more I might no say no immediately I might want to go back and spend a couple of hours thinking about it if it is actually feasible because maybe you know. That’s what engineers love doing they love solving difficult problems and if you are saying no to difficult problems then you are failing at what your passion and hobby is. Ermm so I think that ..

Paul: There is also an aspect is there not of not just saying no but explaining why you are saying no so that the other party is kind of educated into the kind of problems you face so as Daniel said earlier that they can be the bridge to you know business development or whoever else.

Joe: Yeah absolutely, I am the king of analogies at this point ermm but the other thing that developers erhh, this is extremely common that they utterly fail at is that they think for some reason that they are like the target demographic of the product so they will come into a meeting and say this product will absolutely fail because it doesn’t have key binding so I can keyboard shortcuts it’s like nobody uses keyboard shortcuts like in the real world, they are all mice people like you know. It is stuff like that that a lot of the time developers are like “this will never work unless you have least 14 completely nerdy niche features in it” you know and I think developers too often you know they do that and that is just silly.

Daniel: Hey guys that’s been a special problem at digg,since we started of as the pure technology side so it was seen as by developers for developers and you know we have obviously branched out from there and now we have got other interests I want to make sure peoples mums can use the website and that’s you know certainly a , you make different choices based on that.

Paul: I mean it is very timely from my point of view to have this interview with you because on Friday we had a internal meeting in Headscape where we talked about all kinds of production things and one of the things that came out of the development team was this desire to be involved in the process more and err to have their say more and just to be included earlier. So I am quite interested in you know because obviously you guys have been working together for a long time what kind of practical advise would you give to a , maybe this is just a question for me and not for anyone else, but what kind of practical advise would you give for designers and developers working together within the organisation. How can that relationship work better?

Daniel: Yeah, absolutely involving your development team earlier in the process but that doesn’t necessarily mean sitting around brainstorming right at the beginning of a feature with them. I mean I try to sit down work out an idea get it 20% of the way there, you know work out some of the basic issues figure out what this thing really means what’s at the core of it you know it might be ten different features together but what are we actually trying to achieve with it right so at least get that far even throw down so basic wire frames or some really basic comps and then present it to the developers its like listen this isn’t just an idea I came up with you know last night I just want to spill my entire brain out in front of you it is something at least I have thought through you know I have put a few things through my brain and now here is this totally unformed, not totally unformed, slightly formed idea but it is not baked you know don’t wait until you have got it baked and then you are so disappointed when the development team says well that’s not possible or have you really though about this and you have got this complete package already made up in your mind but come to them with a least you know the kernel of the thought out idea and get them to poke holes in it. Get them to push it in other directions and show you what else you could be doing and then go back to the drawing board again.

Paul: What about from your point of view Joe?

Joe: Well yeah, So ermm I agree with Daniel in some sense on that I think it is crucial to before you take it to developers to formulate a cohesive problem or hypotheses. Like if you come to the developers with a half baked problem that you are trying to solve you are going to get like, they are just going to run wild with it and it is like you know difficult sometimes to keep developers focused when they get excited about a problem. So have a formulated problem that you know you have a small idea of how you are going to fix but not fully baked. The other thing too and this goes on both sides of the aisle it shouldn’t be get developers plural involved and it shouldn’t be get. like a lot when you are first germinating that idea and you haven’t really moved it forward start small and then continuously expose it to more and more people errmh because I find if you involve too many people early on in a the process whether it is designers, developers, product people things tend to , you tend to loose focus quickly and everyone wants you know it’s kind of like port barrel spending and major bills its like everyone wants to piggy back extra features and stuff and pet projects that they have wanted for so long into like some major new feature.

Daniel: It is just simple death by committee

Joe: Right

Paul: Yeah Yeah OK That’s interesting a little random question I remember going to a talk once where, and I can’t remember who it was who was giving it, where they suggested that errmh designers and developers swapped roles for a while. Where you try and sit in the other persons shoes and I was just interested whether you two had tried anything like that?

Joe: That would be disastrous for me. (laughs)

Daniel: I I mean I appreciate development roles and I am you know somewhat technical for a designer but yeah I know I have never done that but I have always worked so closely with the development team like at silverorange where I worked previously to digg there was only ten of us and I sat in a room with developers all the time. I worked in their code with them and worked on problems as a group so I think I, you know I have never worked in a place like say you worked in a big enterprise and your in this classic where designers are in one office and developers are in the other office and you toss stuff over the wall yes then I think that would hold value at least go and sit in the other office, go work in the other office for a few months just hear the other discussions that are going on because there are a totally different set of concerns a totally different set of values than what you are doing and if you don’t at least appreciate and understand that, and not just understand it so you know what you are fighting against but understand it to know what is important and how you can work with it then you know you would be really missing out.

Joe: I think I am ermhh I think I am kind of spoiled at Digg because you know I work with two of the webs brightest, you know Daniel and Mark Trammell as well so I actually push back on my developers pretty frequently where they you know we will leave a meeting and they are like I really really completely disagree with what Daniel or Mark are doing with the design and you know I tell them all the time like look you are not a designer and you definitely not at the level that those two are at and you sometimes have to defer to them and trust that they are doing their job and they are doing it well you know and ermhh I think developers don’t do that often enough they make these assumptions that you know the arty-farty designers are doing stupid shit again and that’s not the case. I mean they would not be especially where we are at at Digg and what not I mean Digg is able to be very picky with who they bring on and the people Daniel has brought in to design are extremely competent at what they do err so I am probably not qualified to answer that question because I am so spoiled at Digg but that is a common problem I see from developers where ermhh they don’t let the designers do their job and they try and be designers when in reality you know they do not have the experience or the expertise so.

Paul: Lets talk about conflict resolutions, sounds very grandiose but basically you know how do you go around resolving a situation where you know OK you kind of respect each others skills and you respect each others competencies but you know where some feature is suggested by Daniel and you know and you Daniel from your point of view it is absolutely core to what you are trying to achieve you know it is extremely important and then from a technical angle Joe it just seems incredibly complex and very very difficult. How is the eventual decision made as to whether that feature should be implemented and in what way it is implemented? How do you go about resolving that difference?.

Joe: Ermhh Well I mean I think as far as making the decision whether or not the feature makes it in, because there is actually two possibilities when it comes to the conflict resolution. Whether or not a feature actually makes it into the product and in what capacity does that feature make it into the product and I think in the former whether or not the feature actually makes into the product if Daniel comes to me and he’s resolute like this feature has to be in the product the feature is going to be in product. I am always going to defer to Daniel on on, if he feels that strongly and is that passionate about it you know and it is not something completely hare-brained like I want magic ponies to come flying out of the screen I am going to defer to his expertise on the fact that feature needs to be in the product. Where the conflict resolution comes into it is what capacity is that feature going to come into the product like a perfect example of I think of something where there has been we have had a recent discussion at Digg and where this has happened we have, and I talked about this probably in our last talk but, there are these little green badges on the digg buttons and they indicate one of your friends has dugg that story and when you hover over the digg button it shows like a little sample of the people that have dugg it. Ermhh So those were causing significant strain and problems with our systems and our code and on our databases so I came to Daniel and of course again as my risk aversion developer brain was coming to Daniel I was like Can we axe this feature until we can figure out how to like fix it. He was like “No” that feature cannot absolutely be axed and then we came to a resolution which was a short term solution until we can get a better solution in place where operations now have knobs they can dial down so the green badges don’t show up on stories older than 48hrs, they don’t show up on stories that have more than say 5 or 600 diggs and stuff like that. So the conflict resolution came in basically making trade-offs in how that feature is surfaced in works ermhh at our scale more often than not what that means is that Daniel has to give up the notion that everything is in real time. The feature will work it is just that it may take you know thirty seconds to a minute for an action to be distributed across the entire system, that is probably more how things are now at Digg so.

Paul: What about from your point Daniel, when do you back down over something and when do you keep pushing on it? How do you decide you know how serious Joe is about something and whether you should keep pushing or not?

Daniel: Right I mean it kind of comes down to you know when I am looking at the product I am not thinking of any one feature, I am thinking about the whole set and I want it all to work together and so you know I know I want to push out six different features this month and if I push and push Joe to do the one really hard one well that is going to affect the other five I wanted to get done. So any feature is tied to other features and it is also based on a time line if I want something done in a certain time line and that’s just not possible well then I have to start making compromises so you know you have to be realistic and then at the same time you have to realise developers work well with shame and so if you tell a developer well I bet a good developer could do that (All laugh) they will go back to their cube grumbling at you and figure out a more efficient way to do it.

Paul: OK. So now we are getting into the realms of how to manipulate each other.

Daniel: Absolutely.

Joe: That’s definitely err one that I agree does work but is not a trick you want to pull out of your bag too often.

Daniel: No it is the same with designers too, it is like I want to do this really complex thing, no way I can explain that to users in a way they will understand. “I thought you were good” arhh shit I will go back and try that again.

Paul: That is quite interesting what you just said there because so far we have talked very much about you know designers initiating features and that kind of stuff I mean are there situations where the developer is the one initiating features you know just said there a developer wanted to do something really cool and you said you couldn’t explain it. Does it run that way as well? or is it always the designer who drives first?.

Daniel: No Absolutely that happens at Digg, it happens sometimes at Digg so Joe yesterday sent me an email that had two big feature ideas in it. They may not be things we implement this month but maybe later on this year. I was looking at them and you know it is easy to disregard well he is a developer he does not understand what’s going on with the product but you look at the ideas and they are strong and they fit in with what we are doing and now I am trying to figure out you know how they make sense in the big picture I guess. So we have got a brilliant development team a lot of people over there with great ideas and we try to sit down, you know I guess Kevin has been doing those where we do meetings once a month I guess where developers if they have been working on a side project you know something they have always wanted to build into Digg they can present this at the Digg ideas meeting.

Paul: Ah OK

Daniel: A bunch of those products will make it into the full Digg I mean its awesome these brilliant people go and throw around crazy ideas and show you what is possible.

Joe: I think err yeah I mean I agree with that you definitely have, it is a two way street erm largely stuff comes from product at this point the Digg ideas meetings is definitely helping that you know open that up and kind of what I would call level that playing field a bit. But one of the things I think developers are in a in a unique position just like Daniel I work with people across the entire companies so I know initiatives that are going on in marketing I know initiatives that are going on in PR and biz dev etc. and you know if nothing else developers are very good about noticing and pointing out and discovering patterns and err a recent product that made it out that err was a developer initiated product was Digg dialogue because basically I noticed this common pattern where business development and Marketing and PR were setting up interviews and then like reaching out to people to like conduct interviews using the Digg engine kind of thing and I was why don’t we bake this into like a cohesive feature that’s turnkey because you know business development like Daniel was saying earlier lots of times they are just making these one off deals you know and they don’t really recognise when there is a product to be had there erm so that is another one that recently went out. It was like I recognised a pattern and baked this into something cohesive and move it forward.

Daniel: That is a good example of where we are being lazy some people want to do this one off thing over and over again and it is a bunch of work to don it each time well like we will just build a system to do it and we won’t have to do all the work every time. It was great.

Paul: OK that is really good lets leave then with one final question or one thing from each of you. Which is if you could give you know one piece of advice to either designers or developers on how to kind of interact with their counterpart what would that one piece of advice be?. Lets kick of with you Daniel what would be your one piece of advice to designers about dealing with developers?.

Daniel: My one piece of advice would be to see the big picture, you know aim for version 10 like we were talking about earlier and know what you want to build in the future but be realistic enough to back it up and build it in stages. You know waiting and building a feature over six months and eventually launching it is a terrible way to develop and it’s a terrible way to design having an idea of where you want to be in six months but realising in one month increments is so much better you’ll end up in a different place but at least you know where you are heading and you can adjust that goal as you go forward

Paul: Yeah. Brilliant. Joe what about you?

Joe: Ermhh I would say to the developers out there that there is different shades of no ermhh that you know there is the, the default should not always be no and remember what I said about the conflict resolution you should be deferring to the people that are experts in their field by default for the most part and to work on compromise in how the feature operates and make your concessions and have them make their concessions rather than just defaulting to saying no to the entire feature.

Daniel: And as a developer push to be involved early in the process, even at Digg we struggle with that a lot and as a designer I appreciate when developers want to be involved I want to hear their opinions you know it is fun to have them involved I hear all kinds of crazy stuff I never even considered that’s awesome.

Paul: Excellent. Thank you so much guys that was really good I appreciate you coming back on the show yet again. It was really good to get your perspectives together on that relationship because it is one a lot of people struggle with. So it is good to hear that it can work most of the time. Thanks for your time

Daniel: Thanks for having us on Paul

Joe: Bye

Thanks goes to Shaun Hare for transcribing this interview.

Back to top

Listeners feedback:

With everybody from Britney to Obama now on Twitter it is safe to say the social networking platform has gone mainstream. But what does this mean for the service and how can we as website owners use it? Read More

10 harsh truths about corporate websites

Posted in Web strategy on by Paul Boag

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

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

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

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

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

1. You need a separate web division

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

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

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

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

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

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

Screenshot of Zeldman's website

2. Managing your website is a full time job

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

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

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

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

3. Periodic redesign is not enough

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

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

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

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

Screenshot of Cameron Molls Article

4. Your site cannot appeal to everyone

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

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

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

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

5. Your site is not all about you

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

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

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

6. Design by committee brings death

Illustration showing why design by committee fails

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

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

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

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

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

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

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

Post from Twitter complaining about being a pixel pusher

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

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

8. A CMS is not a silver bullet

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

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

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

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

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

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

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

9. You have too much content

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

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

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

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

10. You are wasting money on social networking

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

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

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

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

Screenshot of Microsoft's Channel 9 website

Conclusions

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

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

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

5 options when website budgets get slashed

Posted in Web strategy on by Paul Boag

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

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

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

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

1. Realign rather than redesign

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

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

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

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

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

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

My facebook profile

2. Simplify

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

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

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

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

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

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

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

Apple Homepage

3. Prioritise and phase development

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

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

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

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

Digg Technology Homepage

4. Reuse and recycle

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

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

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

opensourceCMS screenshot

5. Move beyond the website

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

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

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

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

Conclusions

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

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

150. User Manipulation

Posted in Classic shows on by Paul Boag

On this week’s show: Liz Danzico talks about user research. Paul explains how to create an effective call to action and we discover how one button cost $300 million in sales

Download this show.

Launch our podcast player

News and events

The $300 Million Button

Our first news story is an incredibly tale from usability expert Jared Spool, which really shows the power of usability testing.

In the post he writes about a client who had a fairly standard checkout process on his website. The process began with a login form:

The form was simple. The fields were Email Address and Password. The buttons were Login and Register. The link was Forgot Password.

It is the kind of form I have seen on many ecommerce websites. This feature, which had been designed to help repeat customers, created two distinct problems:

  • New users resented the idea of having to register. One user said: "I’m not here to enter into a relationship. I just want to buy something."
  • Repeat users rarely remembered their username or password. They wasted substantial time guessing, before eventually resorted to creating a new account. In fact after examining the database Jared discovered that 45% of all customers had multiple registrations. Some did go as far as clicking on the forgotten password link but of those only 25% went on to place an order.

In the end the site was redesigned, allowing the user to continue without registering. Within a year this created a $300 million increase in sales.

Of course $300 million is a meaningless figure in itself. It is the percentage increase that matters. In this case is was a 45% increase. That is a staggering number and one that really drives home the importance of testing with real users.

Read the ‘$300 million button’

The UK government and graded browser support

A couple of weeks ago I wrote about the importance of graded browser support. In my post I explained how we should not limit our support to the browsers we test and how it is unrealistic to push for identical support across all browsers.

This is an approach which has been adopted by the likes of Yahoo! and the BBC for some time, but which now also extends to public sector website in the UK.

According to The Web Standards Project the rules surrounding browser testing on public sector websites have been changed to better reflect best practice in graded browser support.

Changes include an emphasise on functionality over identical layout across browsers (paragraph 39):

You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.

As well as support for progressive enhancement (paragraphs 17-18):

You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.

This is excellent news and certainly provides a great reference for UK designers and website owners looking to convince others of the importance of graded browser support.

BBC Graded Browser Support Table

Read the UK government guidance on browser testing

50 Illustrator tutorials

List of Illustrator tutorials

From development to design now, and a list of 50 tutorials that help you get your head around Adobe Illustrator.

The list is compiled by UK web designer Chris Spooner. He echoes my own experiences when he writes:

Adobe Illustrator can be a little tricky to get your head around, particularly after getting used to the workflow as applications such as Photoshop. The difference between layer use and creating and editing shapes can be especially strange at first hand.

I am a Photoshop man and I have found it very difficult to make the transition to a vector based world, so this list was particularly appealing to me.

Its a great list that you will definitely want to check out, if like me you have never got to grips with Illustrator before.

Read 50 illustrator tutorials every designer should see

A new approach to PNG Support

Finally today I would like to draw your attention to a new technique that has been developed by Drew Diller for using PNG transparency in IE6.

Unlike previous techniques this one allows you to use PNGs as background images instead of just as IMG tags. This opens up a world of possibilities and overcomes one of the most annoying limitations of IE6.

This minor miracle is achieved not by using AlphaImageLoader as has been done in the past, but with VML.

Implementation seems fairly straightforward and involves adding a Javascript library to your page. Because this is for IE6 only you can embed the code within a conditional comment. This means other browsers will not even download it.

Although I have yet to use this approach myself, I have high hopes that this will finally solve the IE6/PNG barrier.

Download DD_belatedPNG now.

Back to top

Interview: Liz Danzico on User Research

Paul: So joining me today for our little interview is Liz Danzico. Liz, why don’t you start off by introducing yourself a little bit. Telling us a bit about yourself and your background.

Liz: Sure. Um, I am a user experience consultant, I am here in New York City, I have been developing web sites and user experiences online for about 12 years now. Um, I do a lot of work with Happy Cog Studios here in New York, with Jeffrey Zeldman and Jason Santa Maria. Um, I’m also chair of the new MFA interactions design program.

Paul: Okay.

Liz: At the School of Visual Arts in New York.

Paul: Excellent. I mean, so, to say that you’re an expert in user experience would be a slight understatement then, Liz.

Liz: Well I wouldn’t go that far.

Paul: You’d be too modest, obviously, to say that. Okay, so we got Liz on the show, I met Liz when I went to Future of Web Design and we got talking. Um, she’s got some fascinating insights into the whole area of user research, and usability generally, so I thought let’s get her on the show and let’s maybe, you know, try and cover things from, from the very basic level, a kind of introduction to this concept of user research. Um, so, perhaps a good place to start, if you’re okay Liz, um, would be, how would you go about defining the area of user research? What would you include, what would you exclude from that?

Liz: Right. So … user research, even today, we’ve been doing user research on the web since, uh, the very beginning, so it’s a very old concept but it’s still fairly controversial. So the basic concept is it tells you what really happens when real people interact with your product or service. So, there are no real rules about what it includes and what it doesn’t [inaudible]. You can basically speculate about what your users want, or you can find that out, um, you know? And uh, and the, uh, the latter is probably a more useful approach for you to take than speculation. But with either one, thinking about your audience is useful no matter what. And so, so there are no real rules, now um, when you disconnect thinking about your audience from your business objectives, and you start getting, you know, very excited about behaviors that they’re doing that are sort of disconnected from the real mission that you’re trying to sort of accomplish, then it becomes, um, a bit murky, and confusing. But thinking about your audience is, just in general, is an extremely useful approach.

Paul: Okay. I mean one of the things that, that, um, I’ve heard said before by, particularly cynical clients I have to say, but I’ve heard it said before, you know, ultimately user research, and all of this kind of stuff feels in some ways like, um, just another way for web designers to suck a bit of extra money out of us, you know that fundamentally how, I know my audience already, is the kind of attitude that many web site owners have, so why do you see it as an important part of the process?

Liz: Well uh, you know, as we’ve been seeing design flaws often translate to lost business opportunities, you know, usability is becoming more important than ever as the number of web sites and products is, you know, increasing more and more every day. So, we design these products and services, and we are at the same time users of them, but there’s no way that we can really tell what are users, um, might want. And the best way to, you know, usability research doesn’t cost a lot of money, so, the best way that you can help your clients kind of understand that you need to do usability research in some way is to let them know that usability research is important and it doesn’t need to, um, suck up a lot of time or money in the, in the process. So there’s a great fantastic book by Steve Krug, called Don’t Make Me Think, which I’m sure you’re probably well aware of.

Paul: Uh huh.

Liz: And in one of the chapters towards the end, he has a chapter called "Usability Research on a Shoestring", or it’s probably better titled, which talks of this approach of going out into the hallway and kind of grabbing people, and just sitting them down, and putting them in front of your product or service, and getting some feedback. So getting some feedback from people, no matter who they are, is better than getting none at all. And so, I think starting there with clients, instead of the, you know, $100,000 user research project that’s going to take you across 8 markets, you know, in the United States, the UK, and Asia, then, is going to be a much better approach than kind of intimidating them with the very extensive projects.

Paul: Mmm, I mean, when it, the kind of one scenario that I’ve come across before, um, is where we’ve come across with clients that say "Well we’ve already done user research, we already know our audience ’cause we’ve got somebody in to do this or that." Is there a difference between user research that’s been done primarily with an offline audience, and those with, you know, when you’re interacting with people online? Is there a difference in the kind of results and information that you’re after, and even the techniques, maybe, that you use?

Liz: So, they are probably, when they say that they’ve done user research, they’re probably talking about focus groups. I would venture to guess that when they talk about that they’re probably talking about either focus groups or surveys of some kind and those are not, well, I wouldn’t say that they are, those are bad things to do, but those are not the kinds of user research techniques that are going to give them feedback about their product’s usability. Those kinds of techniques are going to give them good information about, um, certain kinds of things but they are not going to give them information about whether or not people can use the product or service that they’re looking at. So, you want to find out exactly what kinds of user research they’ve conducted. If they say the words "focus group" then you know you want to move them towards something that is a one on one kind of interview. Focus groups tend to be conducted with groups of people, as the name might suggest, um, and when groups of people get together to talk about, you know, they put forth a question for these people, and when they, you know, groups of people get together to talk about the question they might influence one another in their answers, they’re typically aren’t talking about an interface, they’re typically talking about ideas, so you’re not getting good feedback, like in a one on one kind of scenario. So you want to sort of guide them to a more individual, one on one kind of experience. Surveys, on the other hand, are good, but they don’t get that kind of personal experience with a moderator, sitting with an individual, kind of looking at an interface in a kind of task-based scenario.

Paul: Okay, yeah that makes a lot of sense. I mean, let’s then talk about some of the techniques that can be used to better understand individuals, or how those individuals will interact with your product. What different kind of techniques do you use? I mean, there’s the kind of very basic usability session, but do you do, or are there other things above and beyond that, that you do?

Liz: Right. Well, the sort of big secret is that, there are names and there are certainly techniques, but the big secret is there are really no sort of techniques beyond knowing who your users are, kind of documenting what you’re seeing, and then kind of analyzing/prioritizing the results of what you see. So, you can, I’m gonna tell you a number of techniques that we can go through, but if those basic sort of constructs are there, then you’ve done sort of good user research. Now, that being said, the techniques that you can do are usability testing, usability testing traditionally has taken place in a user lab where a moderator is sitting with an individual looking at a screen, or a product, or a sketch of an interface and going through questions in sort of a task-based way, asking people "Show me how you would search for x" or "Show me how you would check out," or, you know, and seeing, measuring the success or failure of that kind of task. The clients are typically sitting behind a one-way, a one-way glass, or mirror, and observing these kinds of things. People have been not so thrilled about this technique recently, saying that it kind of, um, is not, it doesn’t produce natural reactions from users, but that is one kind of technique. There is, uh, kind of creating personas, and using personas, user personas which are an archetype of your site or product’s users, and getting everyone involved in activities around those personas, whether that be using those personas as your talking through features around, you know, a brainstorming session, and getting people to sort of role-play those personas. That’s another user research method. There are, there’s sort of the ethnography kind of take, where a lot of people have been doing kind of in-home interviews and observations recently. Ethnography, cultural anthropologists and people who have been doing traditional ethnography have been watching closely the design research that we’ve been doing recently, and wondering if we’ve been doing it right and so on, but ethnography, in that sort of observing users in their "natural environment", has been I would say a more successful way recently of watching people use products and services, um, so I would say that those three things, usability testing in a lab, sort of using personas and scenarios, and ethnography or kind of going out into the field and watching users, whether they’re in their homes or their offices, are the three kind of key ways to gather user research with users. The fourth way that I’ll mention, and we can talk about this in a little bit, is not with users directly, but it is certainly user research that’s available more and more now, and that is data on sort of analytics, which you can gather from Google Analytics, Shaun Inman’s Mint, these kinds of things. Watching site data and user behavior through site analytics is another form of user research that gives you, you know, some information, and you can watch these traffic patterns on your site. It doesn’t answer the question "Why?" but it does show you some evidence as to how users are behaving on your site.

Paul: It’s quite interesting that you bring up eth, ethnography, whoa I can’t even speak today, because, that’s of interest to me, because that’s an area that we’re beginning to explore a little bit more, and have kind of discovered the same thing, that there’s a real value of going into you know, somebody’s home, seeing the environment that they access the internet on, you know, do they have kids under their feet? You know, where they access their PC, can they sit comfortably at it? All those kinds of things. Um, I guess it’s also an advantage you don’t have to hire an expensive usability lab and all of the rest of it. But I have to confess, I’m a little bit new at it, so talk me through maybe some of the things, you know, how does it differ from a usability test that you would do in a usability lab, other than that you’re in a different environment?

Liz: Well, uh, it depends. It doesn’t have to differ at all — it depends on the goals of the test. I would say that you could construct a test that’s exactly like one that you’d conduct in a lab, it just happens in someone’s home or office, or in a different environment. But as you said, you get the more realistic interruptions, and that kind of thing, and are they going to be able to complete this task given the natural kind of occurrences of their day. And that, depending on what kind of test you are constructing, that’s either going to inform your results or not. If you are doing task-based testing, so I could maybe talk about the different kind of usability testing that you could do.

Paul: Yeah, that’s good.

Liz: Yeah so there are different ways that you could conduct a usability test. Um, traditionally there is task-based testing, where you set up pre-written questions, before you get to the test, that are based on the goals of the testing. So, if we were testing a photo site, we would test whether or not users could upload photos, could they task photos, you know, those kinds of things. So we would write those kinds of questions up beforehand, and then ask those questions during the test. Um, that’s one kind of test. You could do that in a lab, and you can do that same test in someone’s home. In a lab there would not be the children screaming, and the phone ringing, and that kind of thing, or, if someone say were uploading a photo, you would never be able to tell if sort of, timing out, would be an issue, or if anything with time or space or motion would be an issue. If those kinds of things are a goal of your test, then you might want to think about doing it in real time, in someone’s home environment. Another type of testing is something that, I’ll say it was first coined by Mark Hurst, who is a user experience consultant at Good Experience, I think he coined it, it’s called "Listening Labs". Listening labs are, I’ll call them experimental, but they’ve probably been going on long before I was aware of them, where people are designing usability tests in real time. So in other words, you go into the test with absolutely nothing written down, and you sit down with users, and based on your initial interview with them, you hear who they are, and after understanding a little bit about how they use photos in general, say, then you kind of write the questions on the fly, and then sort of develop a test around who that person is and their behavior, with your product, or product type.

Paul: Which I guess, makes people more engaged with the test, because it’s about what they specifically interested in. Is that the idea?

Liz: Exactly. So it’s a more natural way of doing the test. That’s the idea. That kind of thing you could do either way, and probably is even more rewarding if you’re doing it in someone’s natural environment. And then the third type of test is sort of a web, a web wide kind of test, where you have people just surf the internet, as it were, and uh, and just have them think out loud, and that kind of thing is also, I’ve found, more rewarding and fruitful in someone’s home environment, because they have their bookmarks there, and they have their post-it notes. Whereas you put them in a sort of artificial setting and they don’t have those things around them. So, if you, it kind of just depends on the type of testing that you’re doing. If you’re doing just the first kind I talked about, just task analysis and having people go through that kind of task-based testing, doing it in a traditional usability lab is great, you know, I mean you really do get the answers that you’re looking for, and it just depends on your goals.

Paul: I mean, it’s interesting, going back to Steve Krug’s book that you mentioned, I mean he talks about, I guess his agenda in that book is to get people to do testing who perhaps aren’t previously, and so, you know, he really downplays the demographic of who it is that you test, and that it’s more important that you test than that you get the right people, you know and all of that kind of thing. Um, but when you’re going into somebody’s home, and interacting with them, I’m guessing it’s more important to get the right demographic? Is that right?

Liz: Yeah, I mean one of the, um, I think it’s always important to, it’s always important to get the right demographic. Um, but, well I would say that there is a hierarchy of common mistakes around usability testing that kind of has a trickle down effect. You know, the number one mistake is not conducting any research at all, um, and conducting research on the wrong audience is kind of further down the list. So, you know, yeah if you’re doing research on the wrong audience, it’s not going to affect, whether you do it in a lab or you’re doing it at your desk, or at the water cooler, or at home, it’s going to affect your results and your analysis, you know, no matter where it takes place. So, you know, I think that the drawback is you are going to waste more time going out to that person’s time going out to that person’s time, so it’s going to be a drawback for you, but I don’t think that, it doesn’t matter really where it happens, because if you’re testing on the wrong audience, you’re testing on the wrong audience. Um, you’re probably going to get more information out of that experience if you’re in someone’s home, than if you’re not, so if you’re going to test on the wrong audience, do it in someone’s home, because you’re going to, it’s a richer experience, you’re going to get more information out of it than if you’re just testing in a lab.

Paul: No that makes perfect sense, I kind of see that. No, it’s difficult, isn’t it? Because, uh, obviously finding the right demographic of people, and picking the right people to test on is tricky, you know, it’s a more difficult thing and it can be time consuming. So have you got any advice about that? What really matters here? You know, for example, if you’re designing a web site for an over-60s audience, you know, are you, do you want to concentrate on the age aspect of that? Or the technical literacy aspect of that? You know, is it okay to have somebody younger if they’re not as good with the internet, if your audience is, do you, I’m kind of not wording this very well, but you get the idea — what’s important when you’re trying to match demographics?

Liz: Um, well, it’s very specific to your clients. Developing a, so, whenever you are trying to match demographics, you want to work with your clients to develop what’s called a screener, and a screener is a, I would say, whether you’re trying to develop a pretty rigorous recruiting demographic with a professional recruiter, to say, recruit 300 people for an extensive study, or whether you’re going to go out into the hallway and grab some people, or whether you’re going to recruit from something called Craigslist, which a lot of people are familiar with, um, which a lot of people do, I would say developing a screener which kind of outlines your demographic is a really good idea.

Paul: And what kind of things would that include? Sorry I interrupted you.

Liz: Yeah, what a screener is, it kind of goes through, it’s a questionnaire that outlines a number of questions that you would ask a potential recruit, that says, if this person can answer a particular question we should keep them in or out, so it’s actually a really good exercise to go through that allows you to kind of think through the type of demographic that you would have. So that doesn’t answer your question in any way.

Paul: It’s very interesting, though. Can you give me an example? Sorry, I’m interested in this screener thing, cause I haven’t come across it before. Can you give me an example of the type of questions? I mean obviously they’re going to be specific to the individual client, all the rest of it, but what kind of questions?

Liz: Um, what kind of questions? So, let’s see, would this person, so, let’s see, has this person, I mean typical questions could be around financial demographics, age demographics, you know the sort of typical things. But let me think of some more interesting things. So, is this person a full-time student? Has this person been fired from a job in the last 6 months? Has this person participated in usability research in the last 6 months? Those types of things, so if the person answers yes or no, then they’re not a good candidate. But there are other kinds of things you could put into that screener that would be more specific to the project.

Paul: So could it include something like is this person aware of a certain brand, because you want to associate with that brand?

Liz: Absolutely, so does this person drink Coca-Cola on a regular basis, yes or no? That kind of thing. But I’ve found that the screener, because the clients that you work with are often kind of speaking in those terms about their audience, the screener is a really good way to kind of help them understand how you’re recruiting audiences, and a good tool to kind of work together with them to narrow down who you want to be in the target audience for your testing, or your research in general. So, that said, how do you develop a good kind of set of participants for a research study for, say, a product for people over 60? Um, what’s most important, you know it depends on, and I know I hate to say that it depends, but you’re going to develop a goal for the testing, right? And the goal might be about usability, the goal might be about navigation, it might be about design, it might be about, it’s going to have, you have to first identify the goal, and depending on what that goal is, then you can identify the audience. So, the audience, you know the goal might have nothing to do with age, although the product has to do with age. So you can kind of strip away, you can pull apart the product from the goal of the testing a bit, and sort of just focus on the goal of the test. That’s why developing goals for user research is so critical, um, because often times you can separate those and therefore develop a better set of participants for that user research.

Paul: Mmm, that’s really good. I think what we’ve done here, is, a lot of people that listen to this show probably have a basic understanding of user testing. Maybe they’ve done some basic user testing before, or maybe they’ve even written a persona before, but I think what we’ve done, or what you’ve done, is push people a little bit further to kind of consider it in a little bit more detail what they’re doing in order to kind of refine the results that they’re getting back, and that’s really, really great. I mean, if somebody has just kind of done the very basics, you know, they’ve grabbed some people, they’ve done some user testing, maybe in their own office in front of their own PC, and they’ve got a few people in, um maybe they’ve created a couple of personas, what’s the next step for them? What should they be pushing? Is it through this screener? Is that the number one thing they should be doing? Is the goals more important? Is getting a better demographic more important? What’s the kind of next step for them?

Liz: Mmm, that’s a good question. I think that one of the most, well, doing the research is really key. Analyzing the research and connecting the research to the next iteration of a design is also key. We haven’t talked about that at all.

Paul: No, we haven’t, we ought to.

Liz: It’s often a grey area, um, you know there are lots of reports that are produced, you know, diagrams and things, but there’s a lot of kind of intuition that happens between sort of translating the research and putting that research, feeding that research back into the design. There are hunches, leaps of faith, um, you know kind of between that analysis and design. I mean there are clear cut recommendations that one can make, but then there are a lot of more grey areas. So I would say that, I still think, even though I mentioned we’ve been doing this kind of research for at least, you know, more than a decade online, and you know quite a long time offline, I think we still need to get better at the rigor at which we translate those recommendations and findings. So that’s one place I think we need to focus. Um, in terms of the actual research itself, uh, you know, there’s something, I think there are other sorts of techniques. I’m interested in these kinds of emergent, I would say emergent techniques like the listening labs, um, you know where the kinds of things that we’re looking at today with kind of mobile research, where people are, we need to be looking at how people are using our sites not just in the browser on their desktop but, you know, in the browser on their phone, and how their context is changing constantly and how we need to sort of look at that adaptation. So how do we develop tests that are more emergent and can be a bit more flexible, rIght? So I think there’s something interesting about that listening lab, where we kind of understand the person, and then develop the questions around a person and how they use a product, rather than having a pre-written set of questions. So, something that’s more emergent, I think that’s an area that’s interesting to kind of look at. Then, uh, ethnography, really understanding, goes right along with this sort of, emergent, as you said you’ve been getting more excited about ethnography as well, so, thinking more about kind of fine-tuning our approach to people’s own context, whether that be ethnography, going into their homes, their offices, you know, where people are using our products, whether that be on the street, in the hallway, wherever it is, but really understanding how to find people where they’re using our products and test them or do some research around that, I think that’s really exciting and a really interesting opportunity. Um so that, that’s the next step for us, uh, and I think that the way that people are designing tests and doing some usability testing now, is, you know, is good, I don’t think that there’s a big next step that we can all take together, but I think these are three areas that I think as a discipline that we’re going to see people moving forward together in.

Paul: Excellent. Let’s finish off, then, with a kind of where people should go if, you know, they’ve been excited by this interview, they want to learn a little bit more, um, about user research and user testing. You’ve mentioned Steve Krug’s book. What other resources are out there that people should be looking towards?

Liz: Well, let’s see. You know, I was thinking about, I was thinking about that and there are physical places that people can go, but they’re all in San Francisco in the United States, so that’s not going to help anyone. There is, you know, A List Apart has a User Science topic that often publishes user research related methods-like articles, there’s always BoxesandArrows.com which publishes user research related topics, um, Adaptive Path, which is a user research consultancy, or at least one aspect of what they do, they have published a number of articles but they also do events. A lot of events are in the United States right now, but they may have international events as well. But they do kind of give away a lot of their content. Um, and then last but not least, there’s a new-ish publisher called Rosenfeld Media, and the books that Rosenfeld Media publishes are about methods in user experience and, one recently in web form design, was about the usability of web form design by Luke Wroblewski (called Web Form Design: Filling in the Blanks).

Paul: Yeah, I saw that. That looked very good, I have to say.

Liz: Yeah, so that’s something to keep an eye on as well.

Paul: Excellent. Thank you so much, Liz, that was absolutely superb. And I will be fascinated to get you back on the show in the future to talk more depth about some of these issues. Thank you very much for your time, Liz.

Liz: My pleasure.

Thanks goes to Jason Rhodes for transcribing this interview.

Back to top

Listeners feedback:

Every website should have a call to action, a response you want users to complete. But how do you encourage users to act? How do you create an effective call to action. Read More

Back to top

Snape and Keith, separated at birth?

147. Ho Ho Ho

Posted in Classic shows on by Paul Boag

This week on Boagworld: IT’S CHRISTMAS!

Play

Podcast: Download (29.5MB)

Download this show.

Launch our podcast player

Watch the behind the scenes video

This week’s Boagworld is our live Christmas special recorded via ustream.tv. It is our last show before the Christmas break. We return on Wednesday 14th January 2009!

News and events

Kevin Rose’s Christmas Shopping list

Later in the show we are going to share your top geek gifts. However, before we do that I thought we would start with Kevin Roses’ list to Santa.

Kevin has posted his top 10 gifts for geeks and it makes interesting reading. His list includes:

  • Amazon MP3 Gift Certificates – Notice this is not iTunes
  • A USB Drive that can go through the wash and survive to tell the tale
  • A clever little box that can stream Netflix films to your TV
  • A kit for getting you into building your own electronics
  • A HD flip camera
  • Some awesome luggage that is perfect for conferences
  • An insane all in one printer with touch screen
  • A Drobo
  • A micro tool with 19 different functions
  • A Casio slow motion camera

I whole heartedly support the inclusion of the Drobo in this list and I love the look of the luggage. However, personally I would prefer iTunes vouchers because then I can waste even more money buying Apps for my iPhone.

20 signs you don’t want that web design project

Admittedly this next post is not very festive but it brought a smile to my lips and isn’t that what Christmas is all about?

Zeldman goes all ‘ba humbug’ this week when he shares 20 signs that you do not want that web design project. There are some real gems in here. My favourites include:

A previously uninvolved marketing guy starts telling you, your client, and your client’s boss that the minimalist look “doesn’t knock me out.” A discussion of what the site’s 18-year-old users want, backed by research, does not dent the determination of the 52-year-old marketing guy to demand a rethink of the approved design to be more appealing to his aesthetic sensibility.

At meeting to which you have traveled at your own expense, client informs you that he doesn’t have a budget per se, but is open to “trading services.”

Client begins first meeting by making a big show of telling you that you are the expert. You are in charge, he says: he will defer to you in all things, because you understand the web and he does not. (Trust your uncle Jeffrey: this man will micromanage every hair on the project’s head.)

Very funny stuff and sadly, depressingly true. Nice to know even the mighty Zeldman has to deal with this kind of thing!

2008 on the Web: The 20 Key Events

Our final story for this Christmas show comes from Mashable. They share with us the 20 key events that have shaped the web in 2008.

You get a lot of these retrospectives at the end of the year but this is actually a very good list.

According to Mashable some of the key events of 2008 include:

  • The presidential election being fought online
  • The growth of data portability
  • The Apple apps store
  • Citizen Journalism
  • The Facebook redesign
  • The economic downturn
  • Streaming TV
  • Twitter
  • Microsoft and Yahoo!
  • Justin.tv suicide
  • Rick Rolling

The complete list and more detailed analysis can be found on Mashable.

It makes interesting reading if only to reinforce how fast things move online. In one year so much has happened. It makes you wonder what 2009 has in store. No doubt we will have a plethora of predications in January.

Back to top

Geek Gifts this Christmas

On last years Christmas show we shared our ideas for the perfect geek Christmas gift. This year we thought it might be more fun for the Boagworld community to share their ideas.

You guys have submitted and voted on some great suggestions and here is the top 10:

  1. A new Macbook Pro
  2. Adobe CS4 Design Premium
  3. iPhone 3G
  4. Marcus to play his guitar
  5. A Nintendo Wii
  6. A moleskin notebook and Lamy 2000 pen
  7. Apple TV
  8. Nikon D300 DSLR
  9. New iMac
  10. USB slippers

I was a bit gutted to see that ‘A decent joke from Marcus’ didn’t quite make it into the top 10 list. However, I thought it deserved a mention anyway :)

Other entries worth a mention include a netbook, A job and the Website Owners Manual!

Back to top

Boagworld Christmas Appeal

Last year I decided at the last minute to raise some money for a charity on the Christmas show. The Charity we chose to raise money for was called the Bethesda Project. It is a school and children’s home in rural India. The children who attend the school or live in the home come from very deprived backgrounds and the project provides them with a unique opportunity to better their lives.

The Boagworld community last year raised over £1000 to help this project and our money was able to buy an entire new building for the school. It was an incredible achievement and one that you should all be proud of.

However, over the last two years the project has doubled in size and they continue to need our help. With that in mind we are providing you the chance to give again.

I know you guys are constantly bombarded with appeals for money from various faceless charities. Its hard when you feel no connection to the people involved. I am lucky because I grew up with Sarah who helps run the project. I know her and her husband. I know the amazing sacrifice they have made to help these kids.

I therefore thought it might help if I shared a short video interview I did with them last Sunday while at church. Apologises for the poor quality but this was a spur of the moment thing and recorded on my little digital camera.

Occasionally I get emails from people asking who my ‘web design heroes are’. It always strikes me as a bizarre question. The web is an amazing place and I am honoured to be involved in developing something that is the pinnacle of human achievement and knowledge. However, in my opinion it does not generate heroes.

My heroes are people like Sarah and Simon. These people are intelligent and talented. They could have earned a fortune in the commercial sector. Instead they have devoted their lives to serving others. That is to be admired and respected. In my opinion that should be supported.

That said, I know times are tough and people haven’t got a lot of spare cash. SO, I have decided to bribe you. If you give something to the Boagworld appeal no matter how big or small we will give you the chance to win a GetSignOff T-Shirt. As an added bonus I will get Marcus to sign it (he used to be a popstar don’t you know!) and I may even sign it myself.

So can I ask everybody to give something even if its just a few dollars. The majority of last years £1000 was made up to tiny individual gifts. Simply go to http://justgiving.com/boagworld/

Back to top

Question time

The remainder of the show was dedicated to answering questions either sent in by listeners or asked directly in the chat room. Questions included:

Paul asks – What would be you’re ultimate (non-electrical/non-computer related) Christmas present and why?

Doug asks – what’s been your favorite site redesign, either that you have done or you’ve seen done on the internet in the last year or so?

Paul asks – For someone interested in getting into the Web Design industry, what would be the 1 piece of advice you give them?

Matthew asks – What would you be doing, career wise, if the web did not exist?

Jamie asks – How much do you think technical competency counts for or against a good sales team.

Matthew asks – What is your innate age? Have you alway been a 42 year old in spirit? Or a 12 year old?

Paul asks – What Christmas present did you really want that you never got as a kid?

Back to top

145. Baby Jack

Posted in Classic shows on by Paul Boag

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

Download this show.

Launch our podcast player

Watch the behind the scenes video

Housekeeping

Two pieces of housekeeping before we begin:

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

News and events

Google goes social

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

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

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

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

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

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

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

In browser web development tools

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

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

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

Other tools featured include:

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

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

From tables to CSS and back again

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

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

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

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

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

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

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

Advice for long term success

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

From reading the article I took away three lessons…

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

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

Back to top

Feature: Successful communication

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

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

Back to top

Listeners feedback:

Sign-off and payment

We have this question from an anonymous listener:

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

Ok, so picking this apart from the top:

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

Contracts should be made up of two parts:

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

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

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

Ok, more detail… the contractor wants final payment:

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

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

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

Back to top

 

144. Scale

Posted in Classic shows on by Paul Boag

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

Play

Podcast: Download (28.3MB)

Download this show.

Launch our podcast player

News and events

How much should you charge?

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

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

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

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

A plethora of accessibility posts

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

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

A business case for deleting content

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

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

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

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

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

12 principles for keeping your code clean

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

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

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

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

Back to top

Interview: Joe Stump on Building a Scalable Site

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

Joe: Oh, good to be here.

Paul: Have we had you on the show before?

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

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

Joe: Sure

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

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

Paul: OK

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

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

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

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

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

Paul: Wow.

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

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

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

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

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

Paul: Ah, OK

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

Paul: Wow

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

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

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

Paul: Laughs

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

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

Joe: Aha

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

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

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

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

Paul: Wow

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

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

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

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

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

Paul: Laughs

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

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

Joe: Sounds like a plan.

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

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

Paul: Yeah?

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

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

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

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

Joe: It’s not in San Francisco.

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

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

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

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

Paul: Wow.

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

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

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

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

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

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

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

Paul: Oh, yes yes.

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

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

Joe: Laughs.

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

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

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

Joe: Thanks Paul, bye.

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

Back to top

Listeners feedback:

Top web designer applications

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

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

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

Sending out bulk emails

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

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

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

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

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

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

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

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

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

Back to top

142. Community

Posted in Classic shows on by Paul Boag

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

Download this show.

Launch our podcast player

News and events

Typeface.js

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

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

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

Sell Your Web App

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

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

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

Lessons learned while building an iPhone site.

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

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

Free Site Validator

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

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

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

Back to top

Interview: Mark Boulton on Design by Community

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

Mark: Good to be here.

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

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

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

Mark: I have really yes.

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

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

Paul: Three hundred users?

Mark: Three hundred thousand!

Paul: Ah ok.

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

Paul: Ok.

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

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

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

Paul: Yeah, totally.

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

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

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

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

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

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

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

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

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

Paul: You prefer to create a strong reaction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Paul: No, I can imagine.

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

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

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

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

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

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

Mark: Great! Thanks Paul!

Paul: Bye bye.

Mark: Cheers. Bye.

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

Back to top

Listeners feedback:

Keeping Positive

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

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

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

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

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

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

Are these people worth your time?

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

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

Talk money

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

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

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

Ask/listen

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

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

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

Stick to your guns

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

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

Be gracious

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

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

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

Back to top

141. Feedback

Posted in Classic shows on by Paul Boag

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

Download this show.

Launch our podcast player

News and events

Working from home

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

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

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

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

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

Everything you know about CSS is wrong

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

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

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

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

Reduce your business costs with free stuff

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

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

Ideas include:

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

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

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

HTML Email: What mail clients are people using?

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

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

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

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

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

Alex goes on to summarise the key findings which include:

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

Interesting stuff.

Back to top

Interview: Paul Annett on Pushing the Boundaries of CSS

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

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

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

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

Paul Boag: Yeah that counts. I guess..

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

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

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

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

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

Paul Boag: Obviously not.

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

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

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

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

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

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

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

Paul Boag: All hell broke loose.

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

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

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

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

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

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

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

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

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

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

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

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

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

Paul Boag: It’s that graceful degradation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks goes to Troy Oltmanns for transcribing this interview.

Back to top

Feature: Improving your site with user feedback

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

Back to top

136. Stagnation

Posted in Classic shows on by Paul Boag

In this week’s show we talk about overcoming stagnation and Ed Merritt shares a technique to achieve fixed footers without the use of javaScript.

Download this show.

Launch our podcast player

News and events

Design by committee vs design by community

We all know that design by committee sucks, but why? What is it that makes the process fail and what would happen if you took it to the extreme, and opened up the design process to an entire community?

That is exactly what Mark Boulton has done with the redesign of the Drupal website. With over 200,000 registered users this is a significant community and not the kind of environment where you would feel inclined to design in the open.

However, according to Mark it has generally been a success.

The key would appear to be scale. In design by committee you typically have a handful of decision makers, and one or two dominant individuals who overwhelm the others. It is an environment of conflict and compromise.

However when designing by community, the sheer scale of the community drowns out anybody who seek to dominate the process. You move from an environment of personal opinion to one where you are monitoring emerging trends.

So next time you have a client wanting to design by committee, consider opening up the process rather than locking it down to one or two decision makers.

Self Directed Projects

When was the last time you worked on a personal or internal project? Do you do anything that is not paid client work? If not, then according to IdeasOnIdeas you should start.

This post interviews several designers about their their non-client work. It becomes obvious as you read that self directed projects offer real tangible benefits. These include…

  • R&D – The chance to experiment with emerging technologies and techniques, that otherwise you would not get to try out.
  • Build visibility – Higher exposure online as people are attracted to your work.
  • Prove capability – Demonstrating your ability to deliver solutions not in your portfolio of client work.
  • Increase skills – Allowing you to improve your skills in areas where they are weak or have not been maintained.
  • Team building – Building a sense of common purpose among your team in a way that is more engaging than client work.
  • Creates passion – Allowing you to work on a project that generates excitement rather than ones that simply pays the bills.
  • As a release mechanism – The chance to play, and let off steam after the limitations of client work.

    • After years of spending all my time on client work, I have now reached a point where most of what I do is self directed and I can honestly say it is a joy. I also think it has been hugely beneficial for Headscape.

    Understanding Disabilities when Designing a Website

    Back when I was a teenager the government launched a massive campaign warning of the dangers of unprotected sex and in particular the risk of contracting HIV. It was a very powerful campaign and led to a generation growing up much more aware of the risks. However this campaign wasn’t followed up for the next generation and the rates of sexually transmitted diseases increased.

    Why do I bring this strange analogy up? Because I believe we are in danger of doing that with web accessibility. Many of us are getting bored of talking about accessibility. It feels like we are covering the same old ground. Why do we need another article about accessibility basics? We have heard it all before, right?

    Well maybe some of us have, but there is a new generation of web designers who have not. They need to know what we take for granted. Also, it wouldn’t hurt us to be reminded every once in a while.

    That is why I was so pleased to see Digital Web publishing an introduction to accessibility this week. Sure we have heard it all before and you might be tempted not to bother looking it up. However, I would encourage you to take the time. I guarantee it will give you at least one piece of advice which you fail to implement currently.

    More ways to find inspiration

    I often talk about how we need to look for inspiration beyond the web. In fact in this weeks Smashing Magazine, they post some incredibly inspiring graffiti that is worth a look. But, can we be inspired by other websites or does that always end in plagiarism?

    It’s a dangerous game when you start turning to gallery sites for inspiration. Before you know it you can find yourself lifting far too much of the design.

    How then can you be inspired without ripping off somebody else’s website? One way is to look at the design and ask yourself which specific elements you like. Is it the navigation, their styling of bullet lists or the way they handle the footer. By looking at individual elements rather than the whole you remove the temptation to copy the entire thing.

    This is what a designer from Portugal has done. He has made screen grabs of websites and placed them in his flickr account. However, rather than grabbing the entire site, in most cases he captures only a fraction of the page. He removes the temptation to steal a whole design and yet provides himself with inspiration next time he needs to design a comment form or build an online calendar.

    Take a look at his inspirational flickr feed and hopefully it will encourage you to take a similar approach.

    Back to top

    Feature: Overcoming Stagnation

    For many websites the days of rapid growth have passed and they have slipped into stagnation. How then can you re-energise a site and start it growing again? We look at this in this weeks feature.

    Back to top

    Listeners feedback:

    Fixed Footer without javaScript

    Ed Merritt (one of our very awfully clever designers at Headscape) has come up with a innovative little CSS technique I have encouraged him to share with you.

    Ed begins…

    A client recently asked me if it was possible to have a page footer which would stick to the bottom of the browser window if the content didn’t fill the window, but behave normally (i.e. be pushed down by the content) when the content was tall enough. Read more here.

    Back to top

    135. Libraries

    Posted in Classic shows on by Paul Boag

    In this week’s show we talk with John Resig on javaScript libraries and address the question what is more important when we release an app: speed or quality?

    Play

    Podcast: Download (27.5MB)

    Download this show.

    Launch our podcast player

    News and events

    The complexity tax

    Don’t you hate it when somebody beats you to the punch? I recently finished writing a report for our biggest client (Wiltshire Farm Foods). It talks a lot about the need to simplify and remove complexity. It is a lesson we should all learn and so I am in the process of turning extracts from the report into a blog post which we will cover in next weeks show.

    However, it would appear I have been too slow and that Gerry McGovern has beaten me to it with an excellent post on the cost of complexity. However, where I focus on why simplicity is important, he addresses the underlying causes of complexity.

    For me his post is summed up in the following quote…

    Most organizations are producing far too much content. Too many emails, too many PowerPoints, too many reports, too many webpages. All this content creation activity keeps a lot of people busy.

    If you are part of a large organisation or work on a substantial website you need to read this post.

    10 Rules for Driving Traffic Using Forums

    What do you do if you have no marketing budget but have some free time to promote your site? Well, there are a number of guerilla marketing techniques you could use but contributing to forums is one of the most effective.

    Sitepoint has posted an article explaining why forums are a great way of driving traffic to your site. It goes on to suggest 10 rules for doing so effectively. These include…

    • Build your profile
    • Follow the rules
    • Start by responding
    • Contribute your expertise
    • Don’t be a ‘me too’ poster
    • Don’t self promote
    • Explain yourself, but be brief
    • If you’re wrong, say so
    • Write intelligently and correctly
    • Negativity is a no-no

    This is an excellent article and one that you should definitely read before using forums as a marketing tool. If you do not, you are in danger of damaging your brand, rather than driving traffic.

    Accessibility in suit and tie

    The life of the corporate web worker who cares about standards and accessibility can be a frustrating one; hampered by office politics and archaic content management systems. In an article on the Think Vitamin site, Bruce Lawson looks at what you can do to make sure your projects are as accessible for your users as possible.

    Its a very pragmatic article, which I love. Bruce works from the premise that this is going to be tough and makes suggestions like "some accessibility is better than none". He also talks about the need for ‘buy-in from the top’ but goes on to provide practical tips about how to get that buy in. What is more, his arguments for accessibility were backed up with facts. For example…

    Finally, he looks at how to get content providers onboard through education and getting them writing HTML rather than relying on the WYSIWYG editor.

    UK Government Browser Guidelines

    Our final story raises an interesting discussion; should you decide which browsers to support based on popularity or capability?

    Apparently, the UK government believes we should test on the basis of popularity. In a draft document advising public sector websites, it suggests that if a browser appears in visitor logs as being below an arbitrary percentage of total “unique visitors”, then it should not be listed as being “fully supported”.

    On the surface this appears very sensible. However, as Jon Hicks points out on his site, this can create problems. He writes…

    It isn’t clear how the supported browser list would be enforced, but I’m concerned that this approach will encourage browser sniffing, a move that will exclude browsers like Omniweb, Shiira and iCab, simply because their name isn’t ‘Safari’. They share the exact same rendering engine, and therefore require no further testing. You can be more inclusive without spending any extra resources.

    In other words we should be defining our list of supported browsers based on capability rather than popularity. This is the approach used by Yahoo! and it is one that I would fully support.

    The Yahoo model supports all browsers through progressive enhancement and graceful degradation, without the need to test on every browser. Its a neat solution but one that the UK government guidelines specifically say they do not advocate…

    These guidelines do not advocate specific development methodologies, for example graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open web standards such as XHTML and CSS are more likely to work well across a wide range of browsers.

    How come if they are widely accepted, do they not advocate them?

    Fortunately there is an opportunity to change things before this is set in stone. I recommend reading the WaSP article on the recommendations and then sending some polite feedback to the powers that be.

    Back to top

    Interview: John Resig on javaScript Libraries

    Paul:Joining me today is John Resig, who is famous for jQuery and the work that he has been doing with jQuery. John, it is great to have you on the show.

    John:Well, thanks for having me.

    Paul:I have to say this at the beginning. I have to get this out of the way. I absolutely love working with jQuery, and it’s an absolute pleasure. I remember twittering just a few days ago that every time I start doing anything in jQuery it makes me smile, so that’s got to be a good sign.

    John:Well that’s good. I’m glad to hear it.

    Paul: What I wanted to do today is get you on the show and not just for me to suck up and say how great jQuery is, but to kind of look a little bit broader at the subject of JavaScript libraries. Because I have to say from a personal point of view my opinion has changed quite a lot about JavaScript libraries and I’m kind of interested in your perspective on things as somebody that’s actually created one. I think the place I want to start is for a long time I had the attitude that you shouldn’t use JavaScript or indeed any library and that you should know the underlying code yourself and all of this kind of thing. Let’s start with the question of how do you know if it’s appropriate to use a JavaScript library? When is it appropriate to use it? What’s your opinion on that?

    John:Well, I guess my opinion is it’s always appropriate, and I mean the simple fact of the matter is that there’s two things. One is that when you’re developing, you’re trying to support, generally a large number of browsers simultaneously. This is the same as if you are doing CSS development, JavaScript development, you want to support a large enough market share and you want to make that development process easy. The problem is twofold that you’re going to be encountering weird browser bugs and the APIs, the different utilities the browsers provide, will be different. For example, Internet Explorer provides different ways of handling events from all the other browsers. So what libraries do is that they remove you away from dealing with browser bugs, which is huge. And at the same time they provide a simple interface that you can interact with that will just work ubiquitously.

    Paul:Is there a problem there in the sense of, you know, somebody came along and they basically learned to write jQuery for example from scratch, but never learned the kind of underlying JavaScript? Is there a problem there, do people need to know JavaScript before they start using a library?

    John:It depends on the library, but I don’t think you do. I don’t think you have to know JavaScript. In a lot of ways, at least in my experience with jQuery directly there’s a lot of people who have used jQuery who have never done any programming whatsoever. jQuery does embody a lot of advanced concepts but you don’t necessarily have to know them in order to make good use of jQuery. I know this sort of translates well into some of the other libraries but one point of concern you brought up was what if someone learns a library but doesn’t learn JavaScript? I used to be more concerned about that, if someone only knew a library and I guess from a purist perspective, that’s a bad thing. Fundamentally, you want people to be getting better at programming JavaScript, not this specific thing. However, I think the reality of it is, is that so many people are just using JavaScript or CSS or doing web design, they just want to get their job done. It’s not really a matter for them of becoming an excellent JavaScript programmer or awesome CSS user, you want to get from A to Z and finish their work in an effective manner that works everywhere. So I think it’s important to realize that this market, so to speak, exists. It’s a very large one. And that ignoring it completely will just leave users frustrated and going back to the simple cut and copy paste scripts that they used to use. So, I think what libraries are doing is they are instilling good standards, they are instilling good practices, even though the users don’t necessarily know about it. And then eventually what’s good is that since these libraries have these good practices that users can always open up a library and read about it and try to understand better what’s going on.

    Paul:I guess that’s always been a little bit of my concern with relying heavily on a library is that if you come across something that’s a problem or a bug or something like that, you can’t fix it yourself because you don’t necessarily know your way around the library. What’s your response to people that say stuff like that?

    John:Well by the same token if you encounter a problem with a browser you are far less capable of fixing that issue. There’s really no way about it other than that ultimately it would be good to have that knowledge, absolutely. I fully support people who want to do that and I’m writing a second book now encouraging people to do that, to dig into libraries, to learn more, to build their own. What’s important here is that you just don’t, you can’t force people to do it if they, one if they don’t want to or if they’re just not capable. There’s no reason I feel to force a designer, someone who’s a designer by trade to learn the fundamentals of object oriented programming, or functional programming. Theoretically that can help them some way in the future but what’s more important to them is doing good design and I think by helping people keep their focus where it should be. Obviously if a library is able to help programmers program better, that’s good as well. It’s all about helping people keeping their focus and making sure they aren’t down a rabbit hole getting sidetracked.

    Paul:I think that’s the thing that really attracted me to jQuery is as a front-end interface designer was the fact that I could pick it up and run with it very easily. The conclusion I came to is, “OK. Well if I do by some chance find a major problem with it, there’s a massive community of very clever people out there that I can ask and I can get help from.” So, that kind of reassured me, I think. If then, we’ve kind of come to terms with the fact: “OK we want to use a library.” There are so many different ones out there. Run us through some of the different options available and the pros and cons and how do you go about picking which library is right for you?

    John:Well it really depends a lot. There’s a coupe questions you need to answer. Probably the most important of which is you need to ask yourself, how do you want to write JavaScript? Because libraries end up augmenting or really changing the style of how you write JavaScript. So, finding a library that you like how it looks. It sounds very superficial, but you like how it looks, you like how the code feels is a great place to start. There’s obviously a lot of libraries to choose from. There’s a select group of libraries whose quality is generally above the others and the popularity of those libraries generally reflects the quality as well. Out of those I pick generally jQuery, Prototype, Yahoo UI, dojo, then also MooTools and sometimes XJS. What’s interesting is all those libraries are open source and they are all the most popular JavaScript libraries. I don’t think that’s a coincidence. It’s just a matter of fact that in the web these open source frameworks are going to improve better and attract more users and generally have better community to surround them. So out of these libraries though you break down into a lot of different paradigms for development. I’ll try to summarize as best I can, but it really is not substitute for trying it out yourself. Looking and seeing some examples you can have a pretty good feel right away. So, Prototype and MooTools, they both extend the native objects of the language. They both try to improve the JavaScript language itself. So they add new methods to arrays, they make strings better, at the same time they provide things like object-oriented code
    , and all the way out to doing things like events and AJAX. The normal things that you would expect. But at a very broad level they are trying to improve the overall quality of the language and of the experience. Then you have Dojo, Yahoo UI, and XJS and they are generally very modular, very package oriented and they have components you can easily snap in and out with nice ways of handling dependencies and it can end up being a very cleanly architected style of coding. They really support object-oriented code, and additionally events, AJAX, all the normal stuff you would expect. I would tend to group jQuery a little bit differently in that jQuery is more oriented toward improving the relationship between JavaScript and HTML and that it’s highly focused on searching through an HTML document, modifying some things, just getting in and getting out. Unobtrusive, and it doesn’t provide any language features, it doesn’t provide any object-oriented code writing features, it’s just hyper-focused at the task on hand.

    Paul:It strikes me from my experience with jQuery that it’s very much a tool that’s primarily focused at helping front-end interface people implement the kind of functionality that they require from a usability point of view rather than necessarily doing, I mean would you build massive applications in something like jQuery?

    John:It’s absolutely possible and people do it all the time. For example, T-Mobile’s T-Online in Germany, they built their entire user area so like their mail, their calendar, and everything using jQuery. So it’s absolutely used for very large projects. What I think is very interesting for jQuery at least is that while we don’t explicitly provide the object-oriented styles that most hardcore developers are used to we provide some very interesting alternatives especially they way it, like functional programming that I think actually end up suiting development very well. It’s very different, I will completely grant that, but it’s still very capable of scaling quite large.

    Paul:So if people go out there and they have a kind of play around with these different libraries and try each of them out as you say to kind of find what fits their style of coding, once they’ve found something that kind of codes in the way they would like to, for example for me the similarities between jQuery and CSS made it a very natural fit, but what are the kind of things that you should look for from a functional perspective? What kind of things should be included in a JavaScript library? Does that make sense?

    John:At the very core there should be a set of features. Of the libraries that I listed previously they all have methods for doing DOM traversal, so traversing through an HTML document, modifying an HTML document, events, so handling user interaction, animations and AJAX. All of them have some support for that to one degree or another. You can be fairly safe in knowing that if you pick a library you will have that base level. In my opinion those sets of features are probably the most important features and the ones that you end up using the most with your applications. Some people might say in their particular case that maybe animations aren’t as important, or maybe that they aren’t using AJAX, it really depends but for most of the time that set of features is fairly comprehensive. On top of that you really have to start to, once you’ve tried to use it, and once you’ve played around, there’s a whole set of secondary features that you kind of have to dig into, ones that aren’t immediately code-related. Things like the community around a library, the documentation for a library and even the health of the projects themselves.

    Paul:What do you mean by that last one, the health of a project?

    John:There’s a lot of things. In health, do they have an active development team? Are there developers? Are there multiple developers? It’s the famous hit by a bus; if a developer is hit by a bus will the project still continue? Is there a team will continue? Can you view the source code? Is there a repository where you can go? Is there a bug tracker where you can submit bugs? And finally is there a test suite, is what you’re going to be using going to be tested and analyzed to make sure it stays working. Another point that’s important to bring up is that a lot of browsers now are starting to integrate the test suites of these libraries into their test suite. So for example actually this is a lot of my work at Mozilla, was integrating the test suites of Prototype, Scriptaculous, jQuery, MochiKit, a bunch of libraries into our test suite such that if we ever added a change that caused a regression to happen in a library we would catch it and we would fix it on our end. Obviously we would do this in a very smart way, we wouldn’t just blindly be like, “Oh something broke!” We would communicate to the library what the issue was or whatever and this has been very big because now you can, there’s an extra level of safety and security here, in that you’ll know that if you’re using a library like this that it’s going to continue to work going forward in these browsers. That’s an extra level of safety that your personal code can’t provide. I think that’s very interesting. I want to jump back here really quick to the other issues I mentioned.

    Paul:Sorry, I distracted you there and we took you off topic.

    John:It’s OK, it’s OK, of community and documentation. So community, it can be usually be pretty easy to determine the health of the community. All these libraries will have some sort of a mailing list or a forum that you can go to. Just hopping on there, seeing how many messages are posted, seeing what the typical response is like, how they treat new users, just stuff like that it can be really useful because if you’re just starting out, you know you’re going to have some pretty basic questions. Do they understand your problems? Do they help you out? Doing some searches on Google for example to see how many people are talking about it, or using a service like Technorati or something. Are people blogging about it? Is it positive? Are they having problems? The other thing is documentation. This is also pretty easy to tell. If you are starting out with a library, you’re probably going to start out by doing a quick test, running a simple application just to get a feel for it. When you’re doing that you’re immediately going to be in the documentation trying to figure out how things work. I think you’ll be able to determine pretty quickly if the documentation quality meets a standard that you, because if you aren’t, if the documentation just isn’t that good, you’ll immediately have problems and I guess you will have to resort to the mailing list or the forums or whatever. Secondary is, do they have good examples? Do they have books if you want to learn from a book? Do they have books that you can buy to learn from? So again there’s a whole lot of issues here but what a lot of it boils down to is looking at the libraries, looking at their style of code, does it seem alright with you? Then just doing a quick test with each of the libraries that you’ve picked out, building like a menu or just a basic form of interaction. How easy is it? How hard is it? Does it in fact mesh with you well? This is something you can do over the course of a single day and it definitely shouldn’t take you any longer th
    an that. If it’s taking longer than that then you probably want to try a different library. Ultimately you should be trying to use these libraries to make your development simpler and easier. If it doesn’t improve your productivity, if it doesn’t improve the quality of your code then you probably shouldn’t be using it to begin with.

    Paul:Tell us a little bit about the kind of plug-in architectures that exists around many JavaScript libraries. Certainly I know there’s a strong plug-in architecture with jQuery. Does the same kind of thing exist with other libraries?

    John:It depends. What jQuery has is a little bit unique in that we provide a number of plug-in points that plug-ins can snap into and extend how jQuery works. So they can add in new CSS selector behavior, or they can add in new events or all sorts of intricate additions. Other libraries have things that aren’t quite of the same vane, in that they’ll have modules or packages that you can use. Also another thing that varies is how do the various projects treat these plug-ins? At least with jQuery there’s a dedicated plug-in repository that’s used that plug-ins are listed in that you can browse through, you can see ratings, comments, discussions and things like that. Currently no other framework has something similar to that to the best of my knowledge. It’s much looser, just people uploading, putting things to their websites or Google code or some such. So again, at least to me, what makes plug-ins, jQuery-style plug-ins important is that they are, that there’s extension points and that they are supported by jQuery fully.

    Paul: The only thing that I think that I kind of struggle with a little bit about plug-ins, you know I love the idea that there are other people out there that can do the hard work for me in that they can develop something I was looking for, and I love the fact that I can go to jQuery, I can type in whatever I’m looking for and it will pull back stuff. I’m always a bit unsure mind about how reliable those plug-ins are, you know as you’ve been saying with the kind of, the core jQuery library that you’ve created I know there’s a big team of developers working on it, I know that it’s thoroughly tested, I know what browsers it’s tested against, all of that kind of stuff. Plug-ins are a bit more of an unknown entity. Is there any kind of advice that you can provide about judging whether a plug-in or module or whatever is reliable or not?

    John:I mean you sort of have to use the same standards that you would use in looking at a library. Looking at, what you mentioned, is it tested? Is there good documentation? Are there, how many developers are working on it? Like for example in the jQuery project we started a sort of, sub-project called jQuery Glide in which we’ve taken a whole bunch of plug-ins and actually blessed them and proved them, given them themes, excellent documentation, examples, all this stuff and made them sort of official. We’re doing this more and more, trying to bring in more plug-ins, improve their quality and make sure that they’re up to our standards. There’s still tons and tons of plug-ins that are just excellent, but the issue comes down to that you have to sort of train your eye to look at, and be able to spot when something has good quality. The thing that’s easiest for a plug-in author or a library author to do is to just set up a page that has their code on it and has a basic example. At the very least every single library is going to have that. If you dig in and see that it has documentation, that it has tests, you begin to realize that that plug-in is a much higher quality, at the very least. I think it’s really starting to dig in to these side issues, that you begin to get a better picture of how, of the true nature and of the true health of a particular library.

    Paul:Excellent! That’s really useful and I think it’s easy to just look at these libraries and indeed the plug-ins as well and ask, “Well do they have the basic functionality that I require?” But, like you say, looking at things like the community and documentation and things like that are equally important. It’s been very useful John. Thank you for taking the time to come on the show. No doubt we will get you back in the future to talk about some of the specific things going on with jQuery and maybe this book that you’re writing as well, sounds very good. Thanks for your time.

    John:Thanks for having me, Thank you.

    Thanks to Todd Dietrich for transcribing this interview.

    Back to top

    Listeners feedback:

    Quality or Quickly?

    What is more important, to reach market quickly or to launch with a quality product?

    I received this question from Pete in South Africa…

    I have been working on a small web application, which I hope to launch soon. My problem is that I am spending ages tweaking and improving it before launch. I fear that if I spend much longer on it somebody will beat me to market. What is more important, getting the product right or launching it quickly?

    It is a good question and one with no single answer. It is certainly something we have been struggling with as we prepare to launch GetSignOff.

    To read the rest of this blog click here.

    Back to top