Britt Selvitelle from Twitter talks about passion

Britt Selvitte from Twitter talks about enthusiasm, passion and just getting your web application up and running.

Paul: So joining me is Britt Selvitelle from Twitter, good to have you on the show.

Britt: Thank you very much

Paul: I have just listened to your talk at the Future of Web Apps, which was excellent by the way, and just wanted to have a bit of chat with you about passion. Because that was the thing that really came across in your talk. You obviously started with this very melodramatic, on your knees “I love Software development” moment, which is always a good way to start when people have come in with hangovers.

Britt Selvitelle

Image Source

Marcus: I can honestly say I have never done that, gone down on one knee and said “I love software development”, ever.

Paul: Oh I thought you meant just generally speaking. I hope you did when you proposed.

Marcus: Yeah, maybe once or twice after a heavy session

Paul: “I love Alcohol”, “I love everything”

Britt: It is really is something I remember from years ago at school a professor of mine got down on his knees and spread his arms to the whole classroom of college students and said “I love Algorhythms!” and it really stuck in my mind.

Marcus: I wonder how many teachers are like that.

Britt: I know it was fantastic. He made such a great impression on me and I think that I would like more people to proclaim their excitement for creating these innovative bits of software.

Paul: Yeah and you gave us a quote as well which was really interesting, just tell us about that.

Britt: Yeah, Lars was one of the two authors behind Google Wave, which is of course getting huge amounts of press right now. And he said “I have been accused of being pathologically optimistic about it (google wave)” and that quote really struck home with me because, how funny or ridiculous it that being optimistic has actually become a derogatory term to people and something that people consider as being a jab.

Lars

Image Source

Paul: But that should be the ultimate compliment in a way.

Britt: of course.

Marcus: Sorry, if you are born as English person then that is just normal. We are all cynical and pessimistic people, although I am not personally…

Paul: But most English people are. You have this American dream thing going on.

Britt: Well y’know, I tell you in software development and in general there’s this fear of being overly optimistic because people have dealines and they don’t wanna promise too much because they will miss their deadlines but you have to have deadlines and you have to have structure. But the kind of energy about not being creative and excited about what you are doing is really stifling to people.

Paul: Yeah, that is what drives you and motivates you. If you don’t believe in what you are doing then it is going to be a job.

Britt: Exactly and I think a lot people end up not doing the thing, like they have an idea for the start up and they do one, and people accuse them of failing, then they do another and it doesn’t really work out, and they have this third idea, and maybe that is the idea that is really brilliant

Paul: Actually it was interesting in another interview where I gave this quote where Churchill talk about success is ‘going from failure to failure, with no loss of enthusiasm’

Britt: Yeah, absolutely. I couldn’t agree more.

Paul: And it doesn’t just apply to start-ups and things like that. A lot of the people that listen to this show are in-house developers in some corporate entity somewhere. And so often when we go in to companies and start working with them their in-house teams are ground down by politics and stuff like that and they need to re-kindle that enthusiasm.

Britt: Yeah, and I actually have a suggestion on that, something that works well for us is we currently work with a company called Pivotal Labs. And there are some contractors that are friends of ours who are really fantastic developers and of course twitters code base has been around since mid-2006. And so there is definitely some legacy, like when there is a new person they are pairing with they are always apologising, “I am sorry about this code, it is so terrible” and what’s really fantastic is when that new person (young blood energy) and say to the jaded person that has been looking at this code for three years and say “Chipper up little fella”, instead of grumbling about it, lets take thirty minutes or an hour out of our day, write some new tests and clean it up and actually touch on little bits of the code so that it improves overall and after three months, that guy will be bitter and jaded, so you need some new excitement. And often we find by moving people around, this isn’t something we have totally solidified yet because we are still working on a lot of our processes, but by kind of having some motion in the company and people looking at different things you often get some of that excitement.

Paul: Yeah, the other thing that really came across from your talk was, almost giving people permission, not that you are gonna have crap legacy code. It was this idea that it doesn’t all need to be perfect out of the gate, just get it out there, get going and lets streamline it later. That kinda thing.

Britt: Yeh, a lot of people, Front-end development specifically, at a certain point has to scale, but it doesn’t matter when you are by yourself. When you are doing a small project then the best thing to do is, like it’s the same in software, in general some people are for and against Google Optimisation, I am very much against it, I think you should just do something and rock it out and then worry about optimising it if it takes off. With scaling your front-end development team, that is not something you have to do until you have five or six people. The problem with Front-end development is that the language that we use is so expressive that they allow people to write, not necessarily good or bad code, but different code. Javascript allows you to write in hundreds of different styles, but they are all different. So it is not until now that we are all writing guidelines for how you should architect the look and feel of your JavaScript code within Twitter. But if you are just starting something, do not worry about that, get it out there for people to use.

Paul: Because you can get bogged down in that kind of stuff and you lose the momentum and the enthusiasm again. We are back to the same subject again. And talking about the whole thing of enthusiasm you struck me as someone who gets inspired by other stuff you are seeing online and you talked about different places and different things. What is it that really inspires you and what is some of the stuff out there.

Britt: I can give you one really geeky example, I don’t know what the limit is either 8 or 10 pages of apps on your iPhone. I have them all full, I have downloaded more apps than anybody I know. And those are the ones I have got on my phone. I have got several hundred sitting on the computer at home. I download these things because the concept of the iPhone and the way the user interface is constrained such that you have to innovate. I download them and I don’t really use them after that, I just want to see how they have got around these kind of constraints. Because constrained development is fantastic. That’s what I love about Twitter, because 140 characters makes you really choose your words. I sometimes spend 30 minutes authoring a 140 character tweet.

Paul: Okay, that’s obsessive!

Marcus: Basically, you hit enter and then you do the next one.

Britt: I start with a paragraph and then I slowly wittle down, until I have that core function that I want to get across.

Paul: But it is funny because so many people grumble and moan about the constraints on them. “Oh, the client wants this”, ” the client wants that”, “I can’t do what I wanna do” but, actually those constraints can be inspiring as well.

Britt: Absolutely, they are really inspired and I have done consulting and like we did a start-up in Kentucky where we did consulting for contract work and I think those constraints are necessary because the person that you are dealing with in those sort of situations just doesn’t know what you are working with so putting these constraints on them early on is often a really successful tactic.

Paul: Share the Tweetie 2 example, because I really loved that.

Britt: That’s just fantastic. Lauren is brilliant and his Tweet 2 is in Beta right now and I am helping him Beta test it. He has got this one feature where you are composing a reply to somebody, often the reply takes up the entire screen of the iPhone you lose the context of the message. So if you are trying to reply to a specific bit of the message it is only 140 characters but still you might want to check what you are replying on. And on Twitter that is fine because you can just look at the page. So he has this thing where you literally drag down the edit box, you can see a video of me doing this on the talk online, but if you drag down where you are typing it show in a de-emphasised form the tweet you are actually replying to. And then letting go it pops back up. It is something you really have to see to appreciate. It is an example of beautiful design and development that is what gets everybody at Twitter excited about what we do, creating these things.

Paul: You must find things people do with the Twitter API amazingly inspiring, because some of them are wild aren’t they.

Britt: Crazy, how inappropriate can I be?

Paul: You can be inappropriate, we can always remove it.

Britt: Yeah so, at SXSW in 2007 somebody had made a dildo-couch that vibrated whenever you got a tweet. So you put in your user name and sat down and whenever you got tweeted the dildo vibrated and I was like “Oh my God, what have we created” , it’s fantastic but good Lord.

Paul: I was in South-by and I don’t remember that

Britt: and something like that is really important to us, not only because it is inspirational and it feels good to have all these things that are changing the world. I had a guy came up to me when I was in a Rails conf in Germany in 2007, and he came up to me in a bar afterwards and said “I just wanted ask permission, because I don’t know if you allow this. I am using Twitter to send AIDS medication reminders to my patients in South Africa.

Paul: That’s incredible!

Britt: and I was like, “do I mind?, I couldn’t imagine a better way to use something”

Marcus: So it’s not just inane banter.

Paul: No, and it’s not just inane banter and dildo’s.

Paul: …and that’s amazing isn’t it that you start off with this really simple little idea. Because on the surface 140 character, because you put an API behind it’s being used in all these unexpected ways that you could never have planned.

Twitter

Britt: and that’s a really good point because there are people now doing things that we could never have possible envisioned. I mean it would be ridiculously egotistical to think that we are going to come up with all the great ideas, or even a fraction. So, empowering other people and being able to feed off that and get back inspiration from those ideas!

Paul: On the subject of API’s on your talk you did talk about Alpha 1, the very first version you put out there, make sure it has an API. So, obviously you see it as a fundamental part of any decent web app.

Britt: I really do, and it something, that just came up last night when we were talking about API’s and I said “really it would be a shame to release an App, even the first release without an API” because, even if you release it and you don’t get adoption based on however you promoted it or something and then some other guy finds it and they’re like, this is what I have been waiting for my entire life. They can have access to that data and work with it and I really think that from day 1 it can define success or failure for that project. It is so easy with modern web-frameworks to toss in a basic API. It is worth the hour that you would delay the launch.

Paul: And that was the interesting thing about what you said, was that, y’know, it doesn’t need to be fancy full featured API, just do something basic, get that up and running,

Britt: It’s just amazing how people take twitter data. Even when we were small, everyday there would be an email sent out about some crazy thing somebody found online randomly. People do not give enough credit to how many people get excited about these things, they think ‘it’s just me, I’m weird’ and they do it and all of a sudden there is this big community being built around it.

Paul: and it’s quite interesting, obviously you are very much focussed on Web Apps and maybe a lot of people listening to this show aren’t building Web Apps and building more traditional web-sites, but I think even on a lot of these sites have got a lot of valuable data they could be opening up, for example we do a lot of work with Higher Education web-sites and they have lots of data in terms of courses that they run and stuff that’s going on, even that kind of stuff.

Britt: There is no doubt, I mean Twitter by no means now is a Web App, we are moving in that direction, but for the longest time we just had static pages with a bit of JavaScript spruced in. We are moving towards a sort of G-mail-esque sort of App. But, education, how many Colleges have really shitty web sites and where you have to dig through all the stuff, and how many students that are working on projects and could take this stuff and make that API and maybe create some brilliant way to, I mean, I remember being in College and trying to plan my classes and getting overlaps and classes and teachers that I didn’t know I was good or not, education is a perfect example.

Paul: This whole area of API’s, a lot of people go ‘oh API’s, that is for Silicon Valley start-ups’ y’know it is their kind of thing but actually I really don’t believe that I think it goes a lot wider than that. Y’know everybody should be looking at it.

Britt: If you have data you can make public, I think that is what a lot of people look at. This concept of an API, the idea of a public consumable API on the web is relatively new, I think a lot of people see the effort to build in, they don’t realise they have the data to put out there. They think, that’s really simple there is no reason for me to write and API. But even if you have just a little bit of data it just amazing what people will do with that. So if you are listening to this and working on something, even if you think just a little bit of the data is there, just do an API.

Paul: Of course the other thing is, that people are combining your bit of data with stuff from elsewhere and all these mash-ups and you might be contributing to something bigger.

Britt: And the other thing is that people think their data is not going to be useful to anyone else and that’s also a huge mistake and you cannot possibly imagine, like I said, it would be ridiculous to imagine that I could imagine even a tiny portion of any cases that you could use Twitter data for, so even if you think it’s useless, it’s an hour of work to throw in an API and do it.

Paul: Excellent, that’s superb and a really good message to end on, so thank you very much for coming on the show.

Britt: My pleasure, thank you so much for having me.

Thanks goes to Ben Hardcastle for transcribing this interview.

188. Clearscape or Headleft?

On this week’s show, Richard Rutter, Jeremy Keith and Andy Budd join myself and Marcus for a round table discussion.

Play

Download this show.

Launch our podcast player

Every once in a while it is good to do something different. This show is one of those occasions.

Spy Vs Spy Image

This week Andy, Richard and Jeremy from Clearleft came to the Barn to hang out with Headscape. While they were there we decided to record a podcast.

The show is largely unscripted and it seemed unfair to ask our team of volunteers to transcribe an hour long 5 way conversation! As a result, I am afraid we are lacking our normal show notes. I hope you understand.

That said, I can tell you we covered the following topics:

  • The differences between the working practices of Clearleft and Headscape
  • The beginnings of the two companies
  • The pros and cons of being a total service company like Headscape or specialising like Clearleft
  • The importance of passion in what we do
  • Deciding when to adopt new innovations
  • Whether locations affects success
  • Our plans for the future

We really hope you enjoy the show and we would love to hear your thoughts on the subjects discussed. Please make use of the comments below.

Hampshire Web Developer required

Are you a web developer living in the south of england? Once again, Headscape is looking for a talented, enthusiastic developer to join our team. We really need to stop expanding ;)

It was only 5 minutes ago we hired Helen but we are already looking to hire a new developer. We are looking for somebody with a computer science background, who is passionate about the web and can work out of our Hampshire offices.

Who we are looking for

We are looking for a server side developer who is absolutely passionate about the web and keen to develop new skills and experiences.

We are looking for somebody that loves finding innovative solutions to problems, enjoys working as part of a creative team and excels under pressure.

We need somebody with a computer science background preferably with a first or upper second degree.

Although Headscape is almost exclusively a .net development house, we do not require you to have specific experience in this language. As long as you can write great code, we will teach you the rest. (Anti-Microsoft Bigots need not apply!)

What we can offer

Headscape has a lot to offer employees. Just some of the benefits include…

  • A great working environment (watch our recent tour below)
  • The chance to attend industry conferences
  • All the training and careers development you need
  • The opportunity to work with an amazingly talented team
  • Loads of challenging and complex work that will stretch your skills
  • Some great client work to add to your CV
  • A decent office chair! :)

As for salary – Headscape always try to pay well and also pass on our success in the form of bonuses when things go well.

Where you would work

One of the best things about working for Headscape is our offices. Check out the video tour below. This was originally recorded to show people the room we have for rent. However, it also gives you a nice idea of where you would work.

The office is based in Lockerley, Hampshire. This makes it well placed for those living in Bournemouth, Winchester, Southampton, Romsey, Basingstoke and Portsmouth. However, its such a damn nice place that it is worth relocating for!

Interested?

So are you interested? If so (and you are not a recruitment agency) then email your CV to [email protected] or call him on 01722 320596.

160. Education, Education, Education

On this week’s show: We speak to Aarron Walter about teaching web standards. Ryan Carson starts a series on web applications and Paul talks about remote user testing.

Play

Download this show.

Launch our podcast player

Housekeeping

A couple of quick pieces of housekeeping to kick off with…

  • Huge thanks to Ryan Taylor, Paul Stanton and Sarah Parmenter who did a stellar job standing in for myself and Marcus on last week’s show. They were actually far too good and I have already started receiving requests that they become the permanent hosts! Anyway, if you didn’t hear last week’s show then make a point of downloading it.
  • My second piece of housekeeping is a quick plug for Bamboo Juice, a grass roots conference taking place in Cornwall on the 24th April. Myself and Jeremy Keith are just two of the speakers in what will be a packed day. It’s so good to see smaller conferences like this springing up outside of London and so I would encourage as many of you as possible to attend. Best of all its only £99 (£79 for Boagworld listeners!)

News

To be honest, what with SXSW and my week’s holiday I am feeling completely out of touch with the web design world. Fortunately, Mr Stanton is continually updating our twitter feed with juicy stories. I have therefore picked 4 that caught my eye.

How to create a great web design CV

Poor old Smashing Magazine. People do like to tease them (myself included), but they write some damn useful articles. A recent example that caught my eye was ‘How To Create A Great Web Design CV and Resume?‘.

This post is essentially two articles in one. It starts by asking 10 designers to design a hypothetical CV for a fictional individual. Each designer writes a short paragraph about their chosen approach and you get to look at some nice examples.

The second part of the post provides 10 useful tips for creating a great CV. Suggestions include…

  • Make it printable
  • Have a summary
  • Link to online projects
  • Show your personality
  • Keep it simple and understandable

For the complete list of tips read the whole post.

Its a good post, but I am not sure whether producing a ‘designed CV’ is entirely necessary for web designers. If I was hiring a print designer then I would expect a CV to look impressive. However, if I am recruiting a web designer I think I would be just as happy receiving a cleanly designed CV that links to a stunning portfolio website.

There are a lot of differences between designing for the web and print. It is possible to be good at one and not the other. Therefore, a printed CV doesn’t tell me much about a persons capability as a web designer. That said, a well designed CV isn’t going to hurt your cause!

Design: Make it Memorable

One tip that could have gone in the Smashing Magazine article, is to make your CV ‘memorable’ and not just ‘flashy’. This picks up on the theme of a post over at 37 Signals entitled Designers: Make it Memorable.

The post talks about the difference between making something visually appealing and actually memorable. Too many sites are impressive but fail to leave a lasting impression. At one point in the post the author writes…

I started to recall those amazing Flash Sites of the Day. You know those sites that get passed around via IM in your office on a slow day? Simply amazing design and programming. Problem is: I can’t for the life of me remember what those URLs were much less the company/product that was being featured! Isn’t that the point with those sites? That the impact should be profound so that you remember Product or Company X?

This is a lesson that all those involved in the web design process need to learn. Whether we are designers or website owners, we have a tendency towards thing that provide the wow factor. However, often it is the thing that makes us go wow we remember rather than the message being communicated.

Statistics and website owners

Our next article of the week is an ‘all too brief’ post on web stats entitled How to Sell Statistics to Clients.

The post focuses on a common problem – most website owners know they should be tracking website statistics, but don’t really know what they are looking for. In fact the author writes…

In my experience, the loudness or frequency of a person’s request for web statistics is inversely proportional to their understanding of them.

That has often been my experience too.

He goes on to identify three ways that we as web designers can help rectify this problem. These are:

  • Providing cheat sheets that help the client understand terms like ‘hits’ ‘page views’ and ‘unique users’.
  • Add web metrics training into the budget of your projects.
  • Provide summaries and reports for the client on key metrics such as conversion rates or sales.

To be honest this is a much bigger problem than can be covered in a short blog post. Too many website owners think that having Google Analytics will solve their statistics needs. However, having the data is not the same as understanding it. If this information is misread it can lead to bad decisions about the future development of a site.

Specialist vs. Generalist: Who Wins?

The final post this week is of interest to pretty much everybody who listens to this show. It asks which is better – the Specialist or the Generalist.

This is an important questions for both web designers and website owners. As web designers we need to know whether we should be specialising in a specific area of web design. It is important for our careers and our businesses.

As website owners we want to know whether the pain of dealing with multiple specialist suppliers is worth the increased expertise you would receive over a generalist.

It has to be said the article is written mainly from the web designers perspective. However, I think there are lessons to be learnt for all sides.

The post outlines the pros and cons of both approaches, but ultimately comes down on the fence when it says…

There are advantages to being in both groups, but I think the only way to be truly successful is by being a little of both. You can be a specialist, but in order to be able to develop a profitable business, you may need to be able to supplement your specialty services with some add-on services that may not be exactly in line with your focus.

Personally, I think it depends on how you define specialist. The type and level of specialisation can vary massively and the way you position yourself will define your success. For example, you may specialise in a certain discipline (e.g. Ruby on Rails development) or in a specific market (Higher Education).

Ultimately, whether you are a website owner seeking an agency or a web designer forging a career, it is all about balance.

As a web designer, if you specialise too much you will not find work. If you generalise you cannot differentiate yourself.

As a website owner you want a web designer who is enough of an expert to deliver an outstanding solution, but you do not want so many specialists that your project turns into a nightmare.

Back to top

Interview: Aarron Walter on Interact

Paul: Hello, and so joining me today is Aarron Walter. Good to have you on the show, Aarron.

Aarron: Thanks for having me.

Paul: And the reason we have Aarron on the show is because he is going to talk about a new initiative.. is ‘initiative’ the right word, Aarron?

Aarron: Yeah, yeah.

Paul: Let’s go with that. A new initiative from the web standards project, called Interact. Now, let’s kick off, Aarron, by maybe you telling our listeners a little bit about what Interact is.

Aarron: So, whilst Interact is an open curriculum framework, basically we’ve been recognising that the Web Standards Project has been around for a long time and we’ve done a lot of things to try to get standards into industry. And to a certain degree we’ve made some big triumphs in that respect, but there are still a lot of websites out there that aren’t following standards and people that are sort of behind. And we saw the Achilles heal as to why that’s not happening, as really, education. So, you know, our medium’s really young and it hasn’t really found it’s bearings with how we’re going to marry industry and education, so whilst Interact is a curriculum that has a series of courses that teach not only web standards, but best practices.

So there’s of course the stuff that you would expect from WaSP which is the front-end development courses that teach progressive enhancement and semantic markup and that sort of thing. But we have six learning tracks that include foundations; there’s a course in there that’s like an intro to internet concepts and how people can use the internet to teach themselves and use RSS, that sort of thing.

So there’s front end development, there’s a design track, there’s server side development, there’s user science and then there’s also professional practice. So what we’re trying to do is create a collection of courses that are very modular, to try to get these into schools. And we recognise that not every school is just going to take the entire curriculum and integrate that into their program. You know, if you’re a Computer Science program maybe you’ll take a course or two, if you’re a design program you’ll take a course or two, or even just grab the assignments or look at our competencies.

Each course is based on competencies, which are the things a student has to master before they can pass a course. And then the evaluation methods: So each course has assignments, it has exam questions, it has readings that come from Operas own web standards curriculum – we’ve been collaborating with them. It has textbooks, it has pretty much everything that an educator could need to teach a particular topic.

Paul: Okay, so is this something that is then aimed entirely at educators, or if somebody wanted to get into web design and they were trying to learn it in their spare time, could they just go to this and use it in isolation by themselves?

Aarron: To some degree, I guess they could, but Operas web standards curriculum is really learner-centric, so if you’re trying to teach yourself, that’s probably the place to go. But ours is very much focused on educators, because we feel like there’s a lot of great resources out there on the web if someone wants to teach themselves, but there’s not a lot of great stuff for educators to get stuff into their courses.

Paul: So, when you say ‘educators’, I mean what kind of level are we looking at here? Earlier you mentioned schools. Are we talking about school age, or are we talking about higher education? What are we covering here?

Aarron: I’d say our primary target is higher education, colleges, universities, even training programs to some degree. But we are also seeing some of our content in high schools as well and we’d like to see that more. Especially foundations courses like the web design one course or the internet fundamentals course. If students could go into college with a solid foundation, then they can start to focus more on "What can I do with these techniques?" than theory and concept.

Paul: So is this design to be fairly international or is it quite U.S centric in the way that it’s written.

Aarron: We want it to be very international and the people that have worked together on this are from lots of different places. We’ve got some folks in Europe, Canada and of course some folks in the U.S, so it is in an international group that’s coming together and we’re actually working with WaSPs ILG group – that’s the International Liaison Group. And we’re working on, this year one of our big goals is to try to get a lot of our content translated to different languages.

Paul: Okay, so there will be multiple language versions of all of this as well at some point?

Aarron: That’s the direction we’re heading, yes.

Paul: So, I mean, how did this come about in the sense of, you know, well, how did you get involved in it for a start and what was the motivation behind it?

Aarron: So, I’ve been teaching for the past ten years in different schools in the U.S and colleges and universities, but I’ve also been working in the industry as well. And I got on WaSPs mailing list, I just joined the mailing list and started to talk to some folks and then they invited me to join – it was a year ago, I guess it was at the very beginning of 2008 – and so I joined the education task force who created the Interact project. And basically there were ideas about the curriculum and I’d heard lots of people say "Yeah, what we really need is, you know, education’s way behind" and they’re happy to point fingers and "We need a curriculum", but it just never was really transpiring from anyone coming from the industry and so we kind of just decided we need to do this. And I’ve helped create curricula before as a faculty member at the Art Institute of Atlanta and so I had some ideas and we had a really great group of folks that are in the education task force – people that are educators and people that are experts from the industries. So, yeah.. actually South by South West was where this all started, which is pretty amazing, of course there are lots of great people there. So Glenda Sims, who’s one of the heads of WaSP these days introduced me to Chris Mills from Opera who was working on his project and we kind of had some drinks at the Geeks Club bowling event and we just kind of went crazy talking about these ideas. And Steph Troeth then Leslie Jensen-Inman and we all had these ideas, and then we just set a goal for ourselves in 2008 at South by South West and we said "In a years time, we’re gonna be back and we’re gonna have a curriculum." and that’s what we did. This year we launched our curriculum at South By.

Paul: That’s quite an impressive turnaround for the amount of information that’s in there. How did you draw everything together? Where did it all come from?

Aarron: Well, we met every week online and we talked and we established a course template, which really helped us. The stuff that we really needed to put in these foundation courses, we all know what needs to go in there. It’s just a matter of getting around the pedagogy or the educational part of it. So we developed a template for assignments, a template for a course and a template for learning modules which are basically like, you know, a teacher could teach a concept like let’s say, HTML forms in a weeks time. So we developed those templates and then from there we just assigned courses to different people and we used a wiki and we just met regularly and.. I gotta say, you don’t have to have a huge group to develop a curriculum.You just have to have a few people who really have their heart in it and.. we have some amazing folks, so..

Paul: So, what kind of response are you getting so far from H.E institutions? Are they interested in adopting it? If they are, how are they going to go about that, because, I mean, my impression is that it always takes forever to get a curriculum approved at a university or whatever. So I’m just interested in how that process is going.

Aarron: Yeah, education is.. one of it’s benefits is that it’s slow to move, so once it gets a solid foundation it keeps that solid, but you know, one of it’s drawbacks is that it’s slow to move. And so we’ve got some schools that are really excited about it and generally the folks that.. you know, it’s only been a couple of weeks that this has been live, we’ve got some folks that are really excited about it and those are folks that were kind of headed in the same direction themselves. So we’ve gotten some responses from schools in Europe and some schools in the United States that are interested in pulling some stuff in. And we have a school that’s looking at using a lot of our content right now. So we’re in the early stages of trying to get this out there. I think the easiest part is building the curriculum, because we know what needs to go in there. The hardest part is getting it into schools. So one of our strategies is to get the endorsements of folks in the industry, so we’ve gotten endorsements from Google, from Yahoo, from Adobe, from W3C, from Opera, from Mozilla – they’re all just super excited about what we’re doing and that sort of brand recognition can help us get our foot in the door with schools. And of course going out to conferences, we’ve got folks at the European Accessibility conference right now, talking about it, so we’re just trying to get out there and let people know.

Paul: Excellent. That sounds brilliant. I mean, I know that a lot of people that listen to the Boagworld podcast – there’s a large number of students that we’ve got listening and I often get complaints about this, that what they’re being taught at university bears no resemblance to what they’re hearing on this podcast. And I’m hoping that that’s because the podcast is right and the university is wrong and not the other way around. So if they’re listening to this and they’re getting really excited about it and, you know, they’ve gone to your website and they’re seeing the curriculum – I’ve got it on front of me now and it does look really exciting – how do they make this happen in their institution? What would you encourage them to do?

Aarron: So, this is the interesting thing – that so many of us have complained about a problem, but there aren’t a lot of people that will take that complaint and turn it into action. So if you’re a student or if you’re an educator what we need you to do is, there’s a page that’s called Advocate Standards (http://interact.webstandards.org/advocate/) – you can get to it from the homepage of http://interact.webstandards.org. It kind of just describes what standards are, why they’re relevant to you and we need people to share that information with their teachers, we need people to share just this website with their colleagues and show them the testimonials of the people who believe in this and want students to come out of schools with these skills. So we need people to act in a bottom-up sort of way, you know, grass roots. Take this to your classroom, take this to your teacher, take this department chair and just let him know. That’s the most powerful thing that people can do right now.

Paul: I mean, what I’m quite excited about from looking at this curriculum is that it contains a lot more than "Here’s how you code in X language" or whatever and even has got more in it than just design and user experience stuff. All this stuff about professional practices is very exciting too. Could you perhaps tell us a little bit about that?

Aarron: Yeah, so professional practice, we want people to not only get the concrete skills of "I can code a standard compliant page" or "I can construct a usable website", but we want people to be able to present their about their work and you know, be able to survive in a real career in the web. And so professional practices is going to have a series of courses to do that. We’ve got some pretty exciting ones that are coming up. There’s ‘writing for the web’ – it’s going to be a really cool one, that Alan Hussain from a List Apart is going to be creating. And we have a presentation course that’s coming down the line. So, we’ve got a number of those coming up.

Paul: That’s quite interesting, you just said something that I hadn’t grasped which is that there’s more to come here. That this isn’t the end of the line. It sounds like you’ve got lots more that you’re still developing. Is that right?

Aarron: Yeah. We call it a living curriculum, because you never write a curriculum and then you’re done. Especially in our industry, things change so fast. is what of course we’re going to be working on this year. Our design track is light right now and we want to try and address that ASAP, so we’ve got Dan Rubin and Ethan Marcott, are working together to create a foundation design course, that is specific to what web designers need to understand. And we also have Dan Mall is going to be helping us with a Flash course and Aral Balkan is also going to help us with some flash stuff too. We have a lot of stuff going on this year for new courses, so we hope next year at South By when we see everybody that we’ll have a brand new stack to add to Interact.

Paul: Excellent, so do you kind of envisage, from an institutional point of view that, like we were saying, it takes a long time for a curriculum to get approved and that part of the problem has always been that, by the time it’s approved it’s out of date, when it comes to the web. So is the idea that you’re going to get institutions to buy into the Interact curriculum in its evolving nature so that they always get the most up to date version of it. Is that the kind of plan? They’re not grasping one moment in time from it, if that makes sense?

Aarron: Yeah, exactly and we want to take some of the hard work out of being a teacher. I speak from experience, there’s so many things you have to keep track of and trying to keep pace with a lot of changing technologies and concepts, that’s hard on top of the umpteen other plates you’re spinning. So that’s exactly what’s going to happen, is that our courses, they’re not chiseled in stone, they’re published on the web, they’re in an expression engine and we’ll change those as they need to be changed. But that said, we need to strike a balance, because we can’t be chasing every new technology all the time, we have to evaluate and there has to be foundational concepts that remain steady. Separation of presentation and content, that’s steady foundation concept. But new technologies or techniques, they might change.

Paul: Okay, I mean, the whole area of education and web design is massively exciting and there’s so much going on at the moment in so many different fields. I mean, from your perspective, what else out there is really exciting you at the moment that you’re seeing.

Aarron: There’s so much, I just feel like last year that I just saw so many companies, organisations, individuals that, it seems that everyone just was pissed and they just walked out their house and they were headed in one direction until it was like everyone sort of meets up in one big mob. And so, what Opera’s doing, what Chris Mills has done with the 55 articles that he’s brought together and edited for Opera Web Standards Curriculum, that’s huge. Those are all rolled into WaSP Interact as our recommended reading, so that was fantastic. Yahoos Juku project, if you’ve heard of this it’s quite amazing. Nick Fogler, who’s the running Juku – Yahoo actually has a training program, where they bring students that are not employees, they’re not hiring them. They bring them in and they train them to be front end engineers over the course of a few months. And they’re doing it because they’re trying to solve this problem on their own. So, we’re talking with them about how they’re solving problems and looking to collaborate and discuss what we can learn from them. John Allsopp who runs Web Directions (the conference series), he brought myself and Chris Mills and Steph Troeth together with a number of other experts and we did Ed Directions, which was a day long workshop that taught teachers how to teach these concepts in their classroom. So there’s just so much stuff that’s happening right now and that’s just the tip of the iceberg.

Paul: Exciting stuff. It sounds like it’s a really good time and it’s great to have you on the show. How you manage to fit all of this in alongside earning a living too is quite beyond me, but it’s really good that so many people are volunteering and pitching in. That’s great. Okay, let’s get you back on the show, I guess in a years time and sees what’s changed. But thank you very much for coming in now and I will talk to you again soon. Thanks.

Aarron: Thanks for having me.

Thanks goes to Andrew Marquis for transcribing this interview.

Back to top

Listeners feedback:

We have two emails this week dealing with two totally unrelated subjects.

Remote user testing

Our first email is from Steve. He writes…

Catching up on past podcasts, I listened to the episode on User Testing (#150). A method I’ve used that I haven’t heard tossed around much is remote user testing using a screen sharing program like GoToMeeting.

I used this for usability testing of our Intranet and it has several advantages:

  • No need for people to come to central testing facility, or you to go to them.
  • The user is at their own computer, so more comfortable.
  • Ability to record the entire session (screen and audio) so others can look at it later.
  • Tester can conduct testing while in his underwear only (I didn’t do this, but you could.)

What do you think of this method?

Sounds interesting although it would not be my preferred approach.

It’s easy to become a snob when it comes to usability testing and so let me make it entirely clear – any usability testing is better than none.

If you have no budget for user testing, test on friends and family. If time is tight, test on a colleague sitting nearby.

In the same way, if you are having trouble arranging sessions then use Steve’s approach. Something is always better than nothing.

That said, I do have some concerns with remote testing. These include…

  • It sets a minimum bar of technical competency. A user has to be able to connect to the system in order to participate. I know this would have been beyond the capabilities of some test subjects I have worked with.
  • It is less personal. Face to face usability testing puts users much more at their ease and allows you to build a relationship that facilitates honest feedback.
  • It does not allow you to read non-visual signals. Users will often pull a face or shift their positions when they are frustrated. As a facilitator you need to be able to see these signals and ask what they mean.
  • You are not seeing exactly what the user is seeing. You can only see their screen. You cannot see other distractions such as TV in the background. You cannot see the position of their keyboard and mouse. You have a limited field of view.

My preferred approach is to test in people’s homes. Not only are the users more relaxed, you also get a unique glimpse into their world. You see where they access the web, you learn about their home environment and even gain a better understanding of their character.

However, we do not always live in a perfect world and so would definitely use remote testing if better options were not available.

Finding a job

Our second email is a rather despondent one from Andrew…

I have one question, In the past you’ve talked about hiring new for staff, but as far as I can tell you’ve never discussed how to look for a job. I’m currently looking for a career in the industry, but I can’t get a resume to any company or even talk to someone of said company. Almost all the businesses I’ve approached (or at least tried to) either work from home, are no longer at that address, or no longer in business, and actually are just freelancers. And when I find a job posting online its for someone far more experienced then I am. I’m completely demoralized.

You have my sympathy Andrew and I have to say its a tough time to to break into any new sector including web design.

I am also probably not the best person to answer this question. I have been completely unemployable for some time now due to my ill defined skillset and opinionated character :)

So, I am going to try something different with this question. If you have some advice for Andrew, post a comment below. That way we can get the Boagworld community helping each other.

In the meantime here are a few random ideas from me…

  • Give up on the cold calling technique. Randomly contacting agencies is largely a waste of time. You have to get amazingly lucky to contact an agency who happens to be currently recruiting.
  • Try for an internship. Admittedly you will not get paid, but it is a foot in the door. You get a chance to improve your skills and also get to know the people in the industry within your area.
  • Be willing to move. There are jobs out there but they are often further a field.
  • Put yourself in a neat little box. Potential employers need to know what you do. Are you a designer, a coder or a server side developer? Companies don’t know what to do with people who know a bit about everything.
  • Start networking. The best place to find job opportunities is by attending conferences and meetups. Even if you cannot afford the conference itself, turn up at the parties and stand in the halls. Just get yourself out there.
  • Register with recruitment agencies. As an employer I hate recruitment agencies because they cost me money. However, we do still sometimes use them and it doesn’t cost you anything to be listed with them.
  • Ensure your website is perfect. The first thing I do when I look at a potential employee is check out their website. Their site has to be outstanding. It needs to look amazing, be well coded and rich with great content that demonstrates a passion for the web.

Hopefully that helps Andrew and keep an eye on the comments for more advice.

Back to top

Series: Building A Better Web Application by Ryan Carson

Ryan Carson: Hi I am founder of Carsonified a small web company in Bath, England. I am an American as you can probably tell, as for living in England I have been here about nine years. So a little bit of history about us real quick so you know who I am. I have a computer science degree and I have been involved in building four web apps and we are building a fifth truvay.com which will be released later in 2009, and we have sold two of our webapps dropsend.com and heyamigo.net. So the stuff that I am going to share with you today are lessons I have learnt the hard way basically as we have built web apps.

So the first thing I want to talk about is the Admin area that you will build for your web app. What a lot of people don’t know is that the Admin area is really the key to good customer service. If you haven’t enabled really easy customer service then it makes it hard to actually please your customers when they have problems so the first one to make sure you build into your admin for your web app are one click refunds so if someone calls and complains and says hey I am having trouble this month I am really frustrated please help you want to be able to just go into the admin do a search for their email address, their name or their company or anything and bam one click and refund their last invoice and what this does is it gives you, it gives you the ability to just make them happy right away. With a lot of web apps these days on recurring billing you will probably be charging people 5,10,15, $20 a month so losing that amount of revenue in return for really making a customer happy is super important. So make that easy for yourself to refund that money.

The second thing I would make it easy to do is have one click password reset that automatically sends out email with the new password, so with Dropsend it was really hard to reset people’s passwords and that was the number one request people had problems with, they couldn’t remember their password. So if I was to do it again what I would do is I would actually build the admin so I could forward an email from somebody presuming they had sent it from the email address of the account, forward it into Dropsend or the admin and it would automatically know that what it needed to do is reset the password for that email and then it sends out a new one so literally you do not even have to visit the admin area to reset someone’s password you just forward an email that would be amazing, so that’s the way I would do it next time.

The next thing I would do is also doing a one-click resend invoice. So a lot of people they don’t understand they can go into their "My Account" area of a web app to see their past invoices and what they will do is they will just email you and say hey you know I need last month’s invoice. If it is hard for you to find that or send that it is going to make you less likely to help that person so I would do a search on the email address show a list of invoices bam one click and it emails them a pdf version of the invoice. That’s another, that leads me onto another area that I would like to talk about that is invoicing. If you are doing recurring billing sort of every month billing your customers make sure that you are not re-inventing the wheel I would recommend a web app called Spreedly.com and what it is basically it is a web service for recurring billing they have done all the hard work, written all the code, the code for the Dropsend recurring billing was at least I think 1200 lines of PHP and it was good solid code but it was really hard and painful to write. So I would recommend don’t re-invent the wheel use a service like Spreedly because it is making calls to an API if later you decide you don’t want to use a service like Spreedly any more that layer has been abstracted out so you could replace it with your own billing system or another one and it won’t kill you, but I would say hands down don’t rebuild reoccurring billing it is a real pain in the ass.

The last tip I would say about your admin area is make sure that it is easy to give your customers credits. you want to be able to login search for an email address and just give them, hey I want to give them five bucks towards next month, ten bucks just to make them happy and you will have lots of happy customers. So that is my five minutes of tips, thanks Paul for letting me be a part of this. Take care Bye.

Back to top

159. Special Guest

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

Play

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

Download this show.

Launch our podcast player

News

Alkaline

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

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

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

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

16 design tools for prototyping and wireframing

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

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

10 Lessons every freelancer should learn

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

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

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

Back to top

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

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

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

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

Sarah: Yup

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

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

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

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

Sarah: Really?

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

Ryan: To spend in the pub (laughs)

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

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

Paul: Yeah, pays the bills.

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

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

Sarah: Really?

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

Ryan: and a mac to develop on

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

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

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

Sarah: the app store!

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

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

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

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

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

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

Sarah: No, he was an old man.

Ryan: Oh, right. OK

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

Paul: Was he in just a pair of shorts?

Sarah: Yeah

Ryan: A pair of shorts and a smile?

Sarah: No, and a newspaper.

Paul: Strategically placed.

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

Paul: That’s OK.

Sarah: Oh, sorry.

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

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

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

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

Ryan: Yes, we only like the nice clients.

Sarah: Yes, we all like nice clients.

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

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

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

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

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

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

Sarah: Yeah.

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

Sarah: Do you skim-read them?

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

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

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

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

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

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

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

Sarah: Of course! (all laugh)

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

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

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

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

Sarah: Exactly.

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

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

Ryan: Er, yes.

Paul: Yes, ah the Nettuts, oh yeah.

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

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

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

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

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

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

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

Back to top

Listeners Questions:

Is Using Off-The-Shelf Software Wrong?

Jon Writes:

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

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

Thanks and keep up the good work!

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

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

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

Therefore, the pro’s are:

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

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

Don’t implement something you don’t understand!

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

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

How do you price and quote different projects?

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

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

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

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

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

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

158. Home

On this week’s show: We share the highlights of SXSW, discuss home working, and interview Rob Borley about project management.

Play

Download this show.

Launch our podcast player

Housekeeping

Headscape still recruiting!

Headscape is still recruiting. We are looking for an enthusiastic, talented developer to join our team, working from of our offices in Hampshire. For more information see the job advertisement on Boagworld.

Back to top

News and events

The best of SXSW

Well, SXSW is over and I am back in the UK. But what happened at the conference? What was the big news this year?

That is actually a hard question to answer. There is so much at SXSW that it is almost impossible to get a sense of everything that is going on. Even if you could attend every panel that isn’t always where the real action takes place.

The real conference often happens at the parties and in the corridors. In fact, more than one spontaneous panel was started via Twitter, thanks to official panels being full.

Panels this year ranged from the downright dull to all out flame wars! One that I unfortunately missed was "Is Spec Work Evil!". However, Marcus attended and tells me it was particularly fiery. Personally, I am very much against speculative work as I have said before. However, not everybody would agree and the panel seemed to reflect this diverse opinion.

One panel I did make was Paul Annett’s amazingly inspirational talk on Easter Eggs and design twists. The talk focused on the little things you can add to your site to make users go ‘oooo that’s clever’.

Too often I neglect such ‘bells and whistles’ in favour of usability and accessibility. Paul demonstrated how these different priorities can sit side by side without compromising each other. He showed some great examples including the hidden arrow in the FedEx logo and the vines on the Silverback website.

fedex logo

The final panel I want to mention is ‘Being a UX Team of One‘ by Leah Burley of Adaptive Path. To be honest the title of this one was a little misleading (at least from my perspective).

What I took away from this session was that design should not be a solitary activity, solely reliant on the creative inspiration of one individual. Leah seemed to be arguing for a more collaborative approach especially at the wireframe stage. She proposed that all of those involved in the project should sit down together and hammer out the wireframe designs.

This addressed two separate problems we have been having at Headscape

  • The developers concerns at not being involved early enough in the process.
  • The question of who should do wireframing – the designer or the IA person.

Best of all Leah’s presentation was very pragmatic. She provided lots of practical approaches that encourage idea generation and collaboration. I highly recommend listening to the podcast of this when it is released.

Browser testing and IE6

In other news, there seems to have been a lot written about browsers this past week. Three stories in particular caught my eye…

  • .net Magazine seems to have hopped on the ‘dump IE6′ bandwagon – My opinion is the same as that of Jeremy Keith as expressed in last weeks show. It is not a matter of dropping IE6. We should instead being deciding whether we wish to offer it the same level of support as modern browsers. I am entirely in favour of providing IE6 with a basic stylesheet that avoids its shortcomings. However, I dislike the idea of dropping it entirely.
  • Microsoft has released SuperPreview this week that allows Windows users to test different versions of IE simultaneously. I have to say this looks like an impressive tool. It allows you to view IE6 and IE7 side by side. It also has many other tools that may also be useful. Support for IE8 and other browsers will follow and although it is currently in beta, I think it will quickly become an indispensable tool for Windows based web designers. Just a shame there is no mac support!
  • Finally, Sitepoint have written a brief outline of how to create the perfect browser testing suite. Ideally for those starting out it lists various online browser simulators, virtual machines and desktop browser emulators.

Browser testing continues to be a pain in the neck and I for one would be willing to pay for a decent way of streamlining this whole process. This is especially true now that IE8 has been officially released and we have another browser to add into the mix.

Screenshot of Superpreview

A simplicity case study

A few weeks ago I wrote about the importance of simplifying your website. Well, this week Gerry McGovern has written the perfect case study to support the argument I was putting forward.

Removing poor quality content increases customer satisfaction‘ talks about how the Microsoft website consists of a staggering 10 millions pages. Of those pages 3 million have never been viewed!

The post goes on to explain how the Microsoft Office team took a different approach with their site by removing irrelevant pages. According to McGovern…

By weeding the garden, the top task pages became easier to find. But just as importantly it became harder to find a minor task page when you were looking for a top task page.

In short, removing pages reduced noise. Disturbing though it sounds, I think we could all learn something from Microsoft’s example.

An introduction to Microformats

My final post today comes from Richard Rutter’s blog. It is basically an introduction to Microformats aimed at the non-geek. He wrote the post because he recently found himself trying to explain microformats to a client and could not think of a good post that covered the subject from their perspective.

Personally, I am not sure it is necessary to tell a client you are implementing Microformats. The cost of adding them is so small and the benefits so hard to explain, that you maybe better off just doing it.

That said, this is an excellent post and if you are struggling to understand the point of Microformats, this is certainly worth reading.

Back to top

Interview: Rob Borley on Project Management

Paul: So, joining me today is Mr. Rob Borley. Hello Rob.

Rob: Hi Paul, how are you doing?

Paul: Very well indeed. Good to have you on the show. It’s been a little while.

Rob: It has, It has. It’s weird hearing the show above you, um rather than being below.

Paul: Oh yes, because you sit upstairs, don’t you?

Rob: Indeed.

Paul: Do you actually hear it?

Rob: I do. It’s like have a little base bin ?

Paul: Awh. So, um, we have kind of been thinking for a little while that we need to get someone on the show to talk about project management. And the idea was we’d get some high profile web design project manager to come in and talk about web design project management. Then I realised, um, that I can’t actually think of any. You know, I really don’t know of any kind of web design project managers out there, other than obviously the people that work at Headscape.

Rob: Well, maybe there’s a gap in the market.

Paul: I think there is a gap in the market.

Rob: (unintelligible) celebrity project manager.

Paul: Well I think that’s somewhat of an oxymoron, but setting that aside, lets shift around a bit, yeah, so, um, so we thought, lets get you on the show. Um, now, you’re quite and interesting case because you started of as a techie.

Rob: Yes.

Paul: And you became a project manager.

Rob: Yes.

Paul: And, so, um, let’s start by talking about the role of project manager. How would you describe your core role? What is it that you do? I should know this I guess.

Rob: Well, you mean other than manage projects.

Paul: Ok, you just have to make a joke out of it. But you know what I’m getting at.

Rob: Yeah yeah. I mean, I guess, um, the main thing that we do is shovel shit, really. We deal with crap. You know, the main thing project manager would do is a filter between clients and the production team for the project. I mean, there are a couple of stages I guess. So you’ve got the planning part of the job, which is essentially working out what it is you need to do, um, making sure you got the results to do it, plotting a nice time line so they can all fit as far as having deadline. And then you’ve got the people said, because really project management is a people job. You need to know how to get the most out of all the people that are in your project team, um including the client. You need to include the client in your thinking, always. Yah, that’s essentially what we do.

Paul: Yah. It’s a people person thing. I always thought you were so charasmatic. Ok, so, I mean, I guess the question is, if you look at the kind of, if you look at Headscape, and the way that we’re organised, we’ve got four developers, four designers, and three project managers. I mean, that’s a lot of project managers. And, you know the question is, why, why have project mangers at all? Why couldn’t the designers and the developers do the job? Why couldn’t it be spread across multiple people? Justify you exsistance, Rob.

Rob: Yeah, this question kind of makes me nervous here. I feel like I’m re-interviewing for my own job. Not that I interviewed in the first place, but, I guess in one sense, if you were in a small project environment, you could almost get away with one person. If, you know, its a one person job, you could get away with them managing themselves for a limited amount of time. Um, but, as soon as you get beyond jobs which are more than one person, um, and go on for an extended period of time, you start needing to provide some glue to stick things together. You need someone whose got an overview of everything that’s going on. You know, the developers have got a very developer mindset about the way things happen. Designers are the same way, they know about the design stuff. Um, but actually translating what the client wants and feeding that into both areas and bring them together is what’s missing, if you don’t have a project manager.

Paul: So, to some degree, project management becomes necessary with scale. The bigger the projects, and the more complex the projects, then the more a need for a dedicated project manager.

Rob: Yeah, definitely. I mean, I guess the real role of a project manager in these situations is the facilitator. You’ve got all of these tools which are basically your resources, your developers, your designers, um, and you need to be able to enable them to work effectively together to produce what the end product is going to be.

Paul: So here’s a question that I didn’t pre-give you, in advance, which is always the best type. Why, why, why become a project manager? What made you – because you were heading up our technical development team, you were, you know, you were doing very well. Why did you feel the need to get involved in what you call shit shoveling?

Rob: Well, I think my main motivation was, Headscape was growing, and we started employing all of these younger, more dynamic, much more talented, better looking developers, that were basically going to show me up. So I figured that before I got shown in true light that I was going to need to move somewhere else. Um, no, well that’s partly true. Really, I think, its the people’s aspect that I’m really interested in. A good project manager is someone who is able to understand how his resources or how her resources work and how your clients work, and joining the two together. Um, while I quite like writing code really, I’m not passionate about it. So that side of it, you know, I reached as far as I wanted to go, and I really enjoy the people thing.

Paul: Ok. So what other, I mean, what other kind of characteristics do you think make a good project manager, obviously the people skills you talked about, what other, I mean if there are other people out there going well actually I’m not that passionate about coding, or I’m not that passionate about design, but I am passionate about the web, I do like the web design process, perhaps project management is the way I ought to be going. You know, what skills, what characteristics do they need, what personality traits do they need?

Rob: I think well, you need to be able to plan. Um, you know, planning is very very important. If you plan well, then your project will usually go well.

Paul: I like the cornification in that.

Rob: You have to be able to predict the future is helpful.

Paul: Yes.

Rob: A major part of what we de in the planning stages is assessing risk. You know, so, we’ve got what we’re starting with, we’ve got what we want to achieve, and we’ve got a time scale, now we need to work out what things might appear that are unforeseen, which are going to affect us reaching the time scale. So being able to foresee the future is helpful. Um, and so planning, being quite analytical and thorough. The logical background I have from being a programmer, a developer, is really helpful because you have to approach project management in a very analytical way, to make sure you don’t miss things. So there’s that side of it. And then there’s communication skills. You not only need to be able to communicate with a client affectively so they show that you understand what they want, um, and they understand where you are with the project, and they’re happy because a happy client makes everyone happy. But you also then need to communicate that with the various personalities in your team. You know, whether thats the developers locked up in a dark room with no social skills, or the crazy charismatic designers who…

Paul: You’ve just gone with stereotypes that so don’t apply. If I look at our team, no offense to our designers, they’re the ones that sit in the darkened room with their nose right pressed against the screen. And the developers are the ones that are crazy and never do any work.

Rob: (unintelligible) something about reading personalities. No, but you see my point. You’ve got these almost extremes, especially in the web, I guess, in the web world, you’ve got these extremes of personailities which somehow you need to be able to communicate with and put it all together and so, yeah, that’s an important skill. I think the third area, is to be quite relaxed about life. Because things will go wrong and do go wrong, it doesn’t matter how well you plan and how good you are at predicting the future. Stuff will appear that is completely unforeseen and will completely throw (unintelligible). And everyone gets really upset and people will shout at you and it goes a bit nuts. Um, and if you go nuts as well, you project team falls apart, because they look at you as the calm rudder in the storms of life. I can feel my other project manager buddies laughing at me, um, but if you’re calm and you can not get stressed at that but actually see, try and find a clear path through a very stressful situation, then really helps.

Paul: I would so be the worst project manager in the world. I’ve got the attention span of a newt, I’ve got no organisational abilities and I get stressed at everything. So overall, I think I’d fail.

Rob: Yeah, stick to web celeb.

Paul: Yes, I’ll come up with some other title that sounds good. Um, ok, so you talked about this really is, I can honestly say, a foreign area to me. Right? You talk about planning a project upfront. I’m not a planning person. Right? And there seems to be so many variables involved in a project and so much as you say, that can potentially go wrong. How do you plan it? I mean, you know, the kind of thing that you always talk about, when you talk about project management is endless gantt charts that seem to be outdated in about 5 minutes, sort of kicking a project off. How to you effectively plan a project?

Rob: Um, well, we do use a gantt. We always start a project with a gantt. And, um because it seems like thats what project managers are supposed to do, so we justify the time with a gantt. Um, but you do need, um, I think assessing risk is something that is vital in successful project management. Its something that we’ve been doing at Headscape, um, increasingly more over the last year or so otherwise this need to actually spend time highlighting what could actually go wrong here. So, you look at, I’m not going to be able to think of any examples now, but a particular, let’s say you building a shop or something. So potential things which could delay that project would be: the client not getting around to telling you what the products are on the shelf and content population is a big risk on meeting a project deadline, because it is out of your control. So, its like, I need the content by this date, and he needs to put the content in by X date. If the client doesn’t do it, there’s nothing you can do about it.

Paul: I’m guessing integration must always be a big risk. Integrating with third party applications.

Rob: Exactly, so if you’ve got some sort of third party database or a web service you’ve got to pull in, something that you’ve done a bit before, but you don’t know anything about, that’s a risk. Because you can guesstimate what’s going to happen, but its unforeseen. And so, the trick is basically, to find all the tasks that have these risks and then multiply (unintelligible) an hour by some random number. And then make the rest up as you go along.

Paul: So what about once the project gets going, how, what techniques and tools maybe do you use for monitoring and controlling the process and trying to keep on top of everything.

Rob: Yeah, I mean, there are lots of tools out there, obviously, lots of funky web-based ones, um, there is no substitute for talking to you team. Um, trying to (unintelligible) email or basecamp or something is impossibly without talking to you team. So, communicate. It’s a big part of what we do. You have to talk to the people doing the work, you have to talk to the clients, um you have to keep the lines of communication open. Um, but as far as actually keeping track of what’s going on, we do use basecamp, um which is great for managing lists, basically, you manage lists. So from our gantt shell, we’ll break it up into a series of tasks if you like, wide areas, um, and then, (unintelligible) ask people to add comments to them and take them off and then we’ve got kind of an overview of where our project is. Um, and hopefully from there, and when we’ve got the gant shell, we’ve got some dates, some milestones and reminders like you should have done this by then, um and so, you use that to kind of keep track of where you are.

Paul: Cool. What about, so that’s kind of dealing with the internal side of things. What about when it comes to the client, I mean, you talked about, you said earlier, a happy client makes everybody happy kind of thing. So what makes a client happy? What are the things that really, or perhaps turn it around the other way, what are the things that really piss of a client and where can it really go wrong?

Rob: This is really where the people side of it really comes in because every client is different. Some clients want you to talk to them for five hours a day, hold their hand, you know, spoon feed them, and some clients just want to know when it’s finished. So initially, when you’re kind of trying to assess your project team, if you like, your resources and what you’ve got, assessing the personality of your client early on, will really put you in a good place. Um, but, I guess, general principles, if you’re honest, it helps. Um, so, be realistic about what you’re telling your client is going to happen. Don’t promise the Earth by yesterday. Because then you won’t deliver and then they’ll get upset. If there’s going to be a problem, if things have slipped for some unknown reason, then tell them as soon as you know. Tell them as quickly as you possibly can. Um, manage their expectations is kind of the phrase that we use a lot. You gotta manage you clients expectations so that they’re not expecting something that you can’t deliver. And um, and then that limits the amount of upsetness that they get.

Paul: Slippage is a big one, isn’t it? This kinda whole area of things like, you know problems you kinda face, things, like slippage, scope creep, non-delivery, I mean, how do you have any kind of broad techniques for dealing with these kinds of things, or is it just kinda communications thing again.

Rob: It’s mainly I think a communication thing again. Um, part of the planning stage is trying to asses these risks and so you try and build in contingency to cope with those, and if you’re building enough contingency, you deliver the project early and that makes everyone really happy, even if its a long project, you deliver it early, you’ve exceeded their expectation also. Um, so I think, if somethings going to slip, I think you should say you’ve got to be honest. Sometimes things are just out of your control, so you’re two weeks before the end of a project, you in the middle of snagging, your lead developer goes down with appendicitis. There’s nothing you can do about that, and so you just need to communicate with the client and hope they take it well.

Paul: So wishing everything works out, I’m loving that approach. Ok, so, um, let’s finish of with a piece of generic advice. Either people starting out in project management or those that have had project management foisted upon them. You know, whats the kind of one piece of advice that you would leave for people?

Rob: Get to know your team. I think that’s the main thing I would say. Um, its kind of like, when you drive you car, you’re environment is a very organic, dynamic thing, you know what it really what’s going to happen and the only thing you’ve got to get you through it is that you understand you car. You know almost instinctively how it works, how to drive it it, if you get to that situation with your team, then whatever the project throws at you, you kind of, you can deal with it. If you understand how you client is going to react to a certain situtation, you can intincfully deal with it. And it keeps the stress levels low. You need to find ways of managing your stress levels.

Paul: There you go, that’s great advice. Thank you vert much for that, it was wonderful. I really appreciate you coming on the show.

Rob: My pleasure.

Thanks goes to Meredith Marsh for transcibing this interview.

Back to top

Feature: Home Working

I was recently contacted by a friend of mine Marieke Guy about writing a guest post for her blog on remote working.

I have been working at home for over 7 years now and am a great believer in the benefits. However when I actually sat down to write the post, I realised just how long it has taken me to find the right way of working.

As a large number of people who listen to this podcast work from home, I thought I would share my experiences to date and my hopes of where remote working will take me in the future.

The reality of home working

Back to top

What's with the attitude?

We face many challenges as designers and developers – IE6, the fast pace or change, meeting the needs of disabled users. However, I am coming to believe that our biggest challenge is our own attitude.

This post started off as a bit of fun. It was going to be another spoof, this time in the form of a top 10 list of harsh truths. However, as I began writing I found myself actually believing many of the points. In the end I was forced to scrap that draft and start from scratch.

I am worried about how people see us as web designers. More than that, I am worried how we behave as web designers, both with our clients and towards one another.

Let me explain what I mean, starting with the more obvious and damaging area – our attitude towards clients.

Our attitude towards clients

I speak to a lot of web designers and in all of those conversations I rarely hear a positive word said about the people who keep us employed.

The overwhelming attitude towards clients is one of disdain. Oh, we hide our feelings reasonably well when dealing with them face to face. However, behind their backs we are often critical and derisive.

We see clients as stupid, awkward, or intent on derailing the project. In short we see them as the enemy.

We have to change this attitude. Not only is it damaging to the relationship, it is also untrue. Just because somebody doesn’t understand the web, does not make them an idiot. Without a doubt they will be far more knowledgeable than you in many, many areas.

You cannot have it both ways. On one hand we set ourselves up as experts who should be listened to. On the other, we are surprised that the client doesn’t instinctively know, understand and except everything we suggest. If they could, we would not be the expert!

We need to recognise the critical role the client brings to the web design process and stop trying to exclude them for fear they might bring something different to the table we might not like.

Stop treating your clients like children and start treating them as peers. That means listening to their contributions even when it does not sit comfortably with your own views. This involves us losing our sense of moral superiority.

You do not have the moral high ground

I do not hide the fact that I am an evangelical christian. That means associating myself with some people who have an enormous sense of smug satisfaction and moral superiority. Some of these people really think they are ‘Gods gift,’ literally! However, they pale in comparison to the moral and intellectual snobbery I encounter in the web design community.

I am fed up with web designers who judge others (and their own clients) with such passion and vigour it borders on the fanatical.

We are not poets, artists or preachers. We do not have the luxury of free thinking theory. We should be pragmatists that work in the real world and solve real world problems.

The problem is that most of our high minded ideals are nothing more than ego. It is about exalting ourselves at the expense of others. Let me give you a few examples of what I mean…

Why doesn’t your site validate?

I can’t believe they code in .net

He is always asking people to retweet his posts.

Oh, they are just link baiting

Comments like that are just about pulling others down. Validation isn’t everything and how can you judge somebody’s decision to code in a certain language without any background information? Hell, what does it matter to you anyway? As for link baiting and retweeting – what is wrong with wanting to drive traffic? There seems to be an attitude that desiring your site to be popular and working towards that end, is in someway wrong! Admittedly new traffic is not the whole story but it is a part of it.

Promoting your sites or services is not desperate or needy. It is good business. If all you offer clients is moral superiority and a well built site, then you are only offering them half a service.

I am not saying there are no lines. I do not condone black hat SEO techniques and I hate SPAM as much as the next person. However, I think we need to drop the attitude and consider the broader picture. We need to consider the business behind the site.

Stop trying to be intellectually superior

Unfortunately we do not just like to feel morally superior, we also like to feel intellectually superior.

We dress our profession up in impenetrable jargon and give ourselves fancy job titles. In many ways we are like teenagers trying to appear more grown up by smoking and drinking.

I guess this is not surprising. Our industry is barely in its teens. We are trying to find our identity and justify our existence. However, in the process we are in danger of becoming elitist and inaccessible to outsiders.

Take for example the recent rash of Top 10 posts. It is something I have started doing myself and have received a massive amount of criticism for it. I have been accused of dumbing down, catering for the lowest common denominator and being desperate for traffic.

Indeed top 10 posts do drive more traffic. That is because people like them. They like them because they are accessible. They are easy to scan and easy to assimilate. In what way is that bad?

Those who criticise do so because they feel that in some way these posts cheapen the industry or devalue what we do. I get the same criticism about my podcast. We joke on the show and have fun. We make the information accessible. Therefore we must be devaluing it.

In my opinion this is a view driven by insecurity. By wrapping up what you say in long words and impenetrable jargon you can hide the truth. You can sound better than you really are.

Unfortunately this just isn’t true. By making it impenetrable you are actually hiding its worth. By explaining what you know in a clear and accessible way you demonstrate its real value.

The desire for exclusivity

All of this is driven by a desire to the ‘cool kid’. Perhaps it is a hang over from our school days when geeks were far from popular. We try to impress and dominate, when we should be empathising and working together.

Another manifestation of this cool kid mentality is our rejection of anything mainstream. As soon as something becomes popular we drop it like a stone. Now our clients are talking about twitter, we accuse them of ruining it and start looking for the next thing. We want to be exclusive, special, different.

The trouble is the mainstream pays the bills. We need to break out of our exclusive little bubble and try to associate more closely with that mainstream. We need to understand what the general populace are embracing and go with that, even if it means still supporting IE6.

Conclusion

This post is aimed as much at myself as anybody else. I catch myself doing many of the things I have written about here.

In many ways the web design community is awesome. There are not many industries where direct competitors talk to one another so openly and freely. However in doing so we have become somewhat insular and very intense. I think sometimes we are under the impression that we are shaping the future and that every choice we make is of crucial importance.

At the end of the day we are just building websites. We need to get some perspective.

Thus ends the rant :p

Headscape is hiring

Are you a developer living in the south of england? Headscape is looking for a talented, enthusiastic developer to join their team.

Not only are we looking for somebody interested in renting office space at the Barn, we are also looking to hire a new developer. We are looking for somebody with a computer science background, who is passionate about the web and can work out of our Hampshire offices.

Who we are looking for

We are looking for a server side developer who is absolutely passionate about the web and keen to develop new skills and experiences.

We are looking for somebody that loves finding innovative solutions to problems, enjoys working as part of a creative team and excels under pressure.

We need somebody with a computer science background preferably with a first or upper second degree.

Although Headscape is almost exclusively a .net development house, we do not require you to have specific experience in this language. As long as you can write great code, we will teach you the rest. (Anti-Microsoft Bigots need not apply!)

What we can offer

Headscape has a lot to offer employees. Just some of the benefits include…

  • A great working environment (watch our recent tour below)
  • The chance to attend industry conferences (two of our developers are off to SXSW soon)
  • All the training and careers development you need
  • The opportunity to work with an amazingly talented team
  • Loads of challenging and complex work that will stretch your skills
  • Some great client work to add to your CV
  • A decent office chair! :)

As for salary – Headscape always try to pay well and also pass on our success in the form of bonuses when things go well.

Where you would work

One of the best things about working for Headscape is our offices. Check out the video tour below. This was originally recorded to show people the room we have for rent. However, it also gives you a nice idea of where you would work.

The office is based in Lockerley, Hampshire. This makes it well placed for those living in Bournemouth, Winchester, Southampton, Romsey, Basingstoke and Portsmouth. However, its such a damn nice place that it is worth relocating for!

Interested?

So are you interested? If so (and you are not a recruitment agency) then email your CV to [email protected] or call him on 01722 320596.

7 Harsh Truths about running online communities

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

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

A well run community can…

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

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

1. Technology does not create community

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

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

Vanilla Website

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

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

2. Show some commitment

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

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

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

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

3. Learn how to lead

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

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

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

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

Photograph of Barak Obama

4. An antisocial community is your fault

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

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

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

Diggnation Homepage

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

5. You need to swallow your pride

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

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

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

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

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

flickr blog post - Sometimes we suck

6. Stop trying to control the message

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

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

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

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

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

Adobe complaints on Get Satisfaction

7. Nobody likes to be alone

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

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

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

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

Conclusions

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

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

152. War?

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

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

146. Obsessive

On this week’s show, Paul interviews Nicholas Felton about designing with data, we celebrate the return of 24Ways, and explain how community can keep users coming back for more.

Play

Download this show.

Launch our podcast player

Housekeeping

Two pieces of housekeeping before we begin:

  • First, Jaysone wrote in asking about the chat room we mention on the show. He wanted to know what it was and whether anybody could join. The chat room is associated with the shows we occasionally stream live. You can watch these shows at http://boagworld.com/live and interact with us as we record via the chat room. Anyone is welcome although you will probably need to follow me on Twitter to see when the shows are being recorded.
  • Talking of streaming shows, the next live show will be our 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

24 Ways is back

This week sees the return of 24 Ways. 24 ways is the advent calendar for web geeks. Each day throughout December they publish a daily dose of web design and development goodness to bring a little Christmas cheer.

I am not sure whether it is the quality of the posts or that 24 Ways appears just before Christmas, but I always get excited when they return.

This year it returns with a somewhat controversial new look (personally I think it is great they are experimenting) and a whole new set of posts. They still offer a complete archive of previous posts so be sure to look through that, as well as subscribe to their RSS feed.

There is something very special about 24 Ways. I think part of the reason I like it so much is because the writers are given a free hand. They can write on whatever they want and so inevitably write about their passions. This leads to a better quality of post.

As if that glowing recommendation is not enough, I should also point out that our very own Marcus Lillington has a post coming soon. Surely that will be enough to encourage you to subscribe!

iPhone designers kit

In the past I have been slightly rude to the guys over at Smashing Magazine about their endless lists of other people’s creativity (we love them really). However, this week they have released something that is genuinely useful.

The iPhone Starter Kit, is a set of button elements and various iPhone interface options, bundled in a Photoshop PSD. The pack is ideal for mobile developers and front-end designers who need a professional way to show mock-ups or try out ideas.

You can use the set for free and without restriction. This includes both private and commercial projects. The only thing they ask is that you do not resell it.

Admittedly you may not be doing work on the iPhone right now. However, I suspect it will only be a matter of time before we will all be working on a mobile application of some description.

The mobile sector is incredibly exciting at the moment and this is another useful little weapon in our arsenal.

5 Ways to Get Usability Testing on the Cheap

Our next post is from the sitepoint blog and is entitled ‘5 Ways to Get Usability Testing on the Cheap‘.

Usability testing is a good idea for any new web site. Increasing the usability of your web site is good because it will increase visitor satisfaction, which in turn increases sales and user loyalty. On the business savings side, usability testing can also save you money in development, maintenance, and support costs.

The problem is website owners often perceive it as expensive, failing to grasp the high return on investment. However, it doesn’t need to be and any project can incorporate some user testing, no matter what the budget.

The sitepoint post makes 5 suggestions of how you can keep the cost down…

  • Use a service like usertesting.com, which provides a video of users interacting with your site.
  • Get a written user response to your site from Feedback Army for as little as $7.
  • Use a DIY user testing tool like Silverback for the mac or Morae for Windows.
  • Ask friends and family to take a look at the site. Alternatively ask for some feedback on the boagworld forum.
  • Use services like Crazy Egg or Click Density to get heatmaps showing how users interact with your site.

Whatever approach you choose, always make sure you have at least some user testing in every project.

Site search options

One of the things I hate most about the Boagworld website is its search facility. The built in search mechanism that comes with my blogging software sucks! This is particularly embarrassing as I am always banging on to clients about how important search is. After all half your users will turn to the search box before even considering browsing the site. Search has to be right.

I have half heartedly looked around for something that would do the job. I remember looking at Atomz a while back and also there is the obvious Google integration route, but nothing inspired me.

This week however another post from Sitepoint caught my eye. It was talking about the new site search from Yahoo! Recently adopted by Techcrunch it has some fairly impressive features…

  • Real-time indexing of content – When new blog posts or comments are added to the site, the search index updates almost immediately.
  • Customised ranking – You can fine tune the algorithm to fit your audience and user experience.
  • Structured search – You can build your own refinement mechanisms. For example I could allow users to filter posts by category, number of comments, tag or any other criteria I set.
  • Blending Web with site results – Users can search both site and web content and see the results blended together in a single display.

If your site search sucks as much as mine, you might want to check this out.

Back to top

Interview: Nicholas Felton on ‘Designing Data’

Paul: So joining me to day is Nicholas Felton. Good to have you on the show Nicholas!

Nicholas: Thanks so much Paul, it’s a pleasure being here.

Paul: It’s the first time that I’ve really spoken to you. I only first saw you or heard about your work at Future of Web Design and I have to say you completely blew me away with a presentation that was very different from the majority of stuff that was being talked about because it wasn’t really fundamentally about Web design, I guess in a way.

Nicholas: No, I think in a way it’s about a weird hobby that’s kind of developed into a tiny Web phenomenon.

Paul: Well, from what I can gather it’s a fairly big Web phenomenon according to Keir from Carsonified who was raving about you afterwards. For those people that haven’t come across you before, tell us a bit about yourself. Who are you? What is it that you do? Where is it you work? A bit of background basically.

Nicholas: Sure, sure. Well again, my name is Nicholas Felton. I’m a graphic designer, predominantly print but I definitely dabble in the web and am there more and more frequently. I went to art school, I studied graphic design about ten years ago here in America at the Rhode Island School of Design and I’ve worked in graphic design firms and advertising doing identity and on the side I’ve started my personal website called Feltron where I’ve grown these annual reports that have become something that I’m sort of getting well known for.

Paul: So let’s talk about these annual reports, because this is what you were talking about at Future of Web Design. There’s a lot of people that might be listening to this thinking “Well, hang on a minute he’s just said that he’s primarily a print designer, this is a web design podcast. Why have we got him on the show?” Well just to kind of deal with that to start with, I mean obviously web design should be a lot broader, we should be looking outside of the web for inspiration and I’ve found these Felton Annual Reports incredibly inspiring. For those that don’t know, tell us a little bit about what they are.

Nicholas: Alright. Well, I really latched onto this name for them because I think it communicates pretty quickly what it’s about. Everyone understands what an annual report is. It’s the summation of a year. I’ve just attached my name, more precisely my sort of Web name, which is Feltron. My last name is Felton. But these started in 2004. I was just trying to get a grip on the year and wrap it up and I looked around at the websites I was looking at and the books I enjoyed and I put that all on my site but I snuck in a couple of little details, like the number of postcards that I sent and worked out the number of air miles that I traveled and those sort of, they hooked me. And so the next year I went back through my records and I put together a multi-page feature for my website where I looked at my travel in more detail, making pie charts of the countries that I went to. I split up my photography into all these different metrics that I could examine and between that I came up with about six pages I think of exploration of my eating and drinking habits and the culture that I enjoyed for the year and this is something I thought would only be appealing to people who knew me well, it would be a little bonus for them at the end of the year and it turned out to be a little viral and people started sending it to their friends and I started hearing from strangers that they thought it was fantastic and people saying, “I want to do this,” so I’ve tried to spend more and more time on it each year to stay in the forefront of this desire that I see building for people to encapsulate their year in this kind of report.

Paul: For me personally, when I heard you speak I immediately came away with a desire to do the same thing, just as you described.

Nicholas: That’s fantastic.

Paul: But the question that’s burning in me is, “Why?” Why do I feel the desire to do that? Why did you do it? Where did the idea come from? How did this all start?

Nicholas: I think it wasn’t that hard for me to do. The first one that I described, which was a multi-page document I actually didn’t do anything different than I’d been doing for previous years. I just had this natural habit that in my calendar I would write down where I went socially as well as what I did for work and I was able to look at that and between the names of the restaurants I knew this was a Thai restaurant so I could sort of make pie charts of what types of meals I was eating and I knew how many bars I had been to and I guess after that year I decided I was really going to formally examine this and decided to strictly track more things over the course of the year. I guess for me it’s driven by curiosity, I think I’m a pretty naturally curious person, maybe you are as well and it’s not about changing my behavior. I really don’t want the reports or this recording of my year to affect what I do over the year. I think I find a lot of solace in the numbers that come out of it. Just knowing how many beers I had or how many coffees I had or how many air miles I traveled is really comforting to me. It’s a way of tackling some of the unknown in our life.

Paul: It’s interesting because when you describe it, if someone hasn’t seen these reports you kind of think of an annual general report that’s published by a company, which are tediously dull documents but the things that you produce are graphically stunning as well. So I’m interested, is it primarily a kind of data collection exercise for you, or is it more a graphic design exercise? Is it about, I mean you kind of indicated that it’s about the data that you’re gathering rather than maybe the graphics, but the graphics are obviously what sells it to other people I guess. I don’t know.

Nicholas: Yeah, it’s hard for me to split it, but I have to say it’s absolutely about the finished product which is a piece of graphic design and the better the data is the better the story I have to tell so it’s a narrative of my year. It’s all encapsulated. It’s primarily a visual piece and I do put a lot of time and effort into making sure that it’s very visual and very easy to read quickly but that there are little details in it you can pull out if you want to spend more time with it.

Paul: Yeah. I mean that’s the immediate thing that you said there, it’s very time consuming.

Nicholas: Yes.

Paul: Not only from a design point of view, and I’m sure it must take you just an unbelievable number of hours to produce something that is so exquisitely designed but I mean tracking all this stuff, you must spend, I mean I’m surprised there isn’t a big part of one of your pie charts that’s just entitled “Tracking” you know where you spend hours just tracking all this information. What keeps you going? Why do you continue to do this?

Nicholas: Well first of all, it just doesn’t take that much time actually. I tend to sit down in the morning in front of my calendar and write down the meaningful things from the previous day but at most five to ten minutes a day. It’s definitely a background process that’s running in me all the time as, “Do I need to take note of this for my reporting?” And when I do leave my routine, when I travel, it’s a bit more complicated because then I’m doing new things and I want to make sure I get them right but it’s something I think you get into the habit of doing. For anyone who writes a diary or does these sort of recordings of the day I think after a while it’s not a burden at all. Last year I did find out, I decided out of this curiosity that I wanted to record every street that I’d walked down in New York City and that did become a little burdensome, but it was well worth it.

Paul: It’s interesting that you picked that one out because that was the one that I really looked at and went “Wow, that must have taken a long time.”

Nicholas: Yes. But it was well worth it. A year is a long time but it’s actually not that long of a time and I had a lot of hunches going into it about where I would go and where I didn’t go and it’s phenomenal to see how little of the city my routine is actually settled into.

Paul: Yeah, it’s a fascinating exercise. Just kind of give us a little bit of an idea, you know tell us you just mentioned walking down certain streets. Tell the listeners some of the other things that you collect, the other bits of information.

Nicholas: Well last year I was keeping track of every single alcoholic beverage that I had. For some reason I think drinking is really easy to keep track of because it is sort of a binary act, it’s like “one drink” versus a meal which can be more complicated but so alcoholic beverages I had 968 in 2007. I had 83,565 milligrams of caffeine through all my coffee beverages which by examining my weight and the caffeine content of each type I was able to deduce was approximately 6.8 lethal doses. I knew there’d be a couple lethal doses in there I just wasn’t sure how many and I worked it out.

Paul: That’s just horrifying. How do you decide what it is you’re going to track?

Nicholas: It usually just leads naturally out of the previous year. So like in June I will decide, “I wish I’d been tracking that this year,” and so next year I’ll make a point of doing that. So last year I started delving into the distances I’ve traveled, I worked out that I traveled about 1075 miles on the New York City subways. So this year I’ve taken a much closer look at the distances I’ve traveled. I’ve worn a pedometer all year so I could figure out how far I’ve walked and yeah.

Paul: What kind of other stuff are you tracking at the moment? You’re tracking how far you’ve walked, what other things?

Nicholas: Mostly the same things from previous years, but I’d like to look at it all through the lens of distance so it’ll be a different measure of the year rather than relating things to days or hours how does that relate to how far in terms of length I was through the year.

Paul: I mean you mentioned a pedometer there. What other kind of tools do you use for collecting data when you’re out there? When you’re out and about I feel like you need a really handy little iPhone app or something here that kind of records all this stuff for you but what tools are you using?

Nicholas: Well yes the iPhone is great I’ve tried to have some sort of smart phone where I can take notes at all times through this project but often times it’s just as simple as sending an email to myself so I have this little note that gets collected and goes into a folder and I make sure that I enter that into my calendar. It mostly all goes into iCal. I also use Backpack by the 37signals guys to keep running lists of the clothes that I purchase through the year or the movies that I saw and then when it all comes together it’s Excel. Everything needs to get into a spreadsheet so that all the math can get done and that’s probably half of the time it takes to design is just collating all the numbers.

Paul: Yeah, I’ll bet. Wow. This is absolutely fascinating. It’s something very addictive about the whole idea. I mean OK, for somebody like me, let’s say I wanted to go for this and I wanted to try it. What kind of advice would you give me starting out?

Nicholas: Well probably the best advice is to pick something that you’re going to be able to track, that you’re not just picking “What websites do I visit?” because it’s going to be overwhelming and you’re just going to pass on it after a week or two so pick something that’s easy that you do, not too infrequently that it’s not interesting but frequently enough that you’re going to get a good data set out of it. And so like if you see a lot of concerts I think concerts attended is great and then what aspects of that that are interesting? Who did you see and where was it or how long was it? So I think definitely in this website I’ve been developing to help other people create their own annual reports or just personal reporting in a way you can just have one really rich data set and by slicing it in different ways I think you can get a lot of interesting presentations out of it.

Paul: You mentioned a site there that you’re developing. Tell us a bit about that.

Nicholas: OK, it’s called daytum.com. It’s D-A-Y-T-U-M and it’s just a place where I’ve tried to remove a lot of the boundaries for creating a document like this. So there are two parts of it, there’s the recording element that can get complicated so we want to make a way that’s really easy for you to count things and then the display part of it which is practically inaccessible to a lot of people so there are a lot of built-in pie charts and stack line graphs and counting methods that are all built in, in a sort of clean design and you can just make this page that fills up with graphs and numeric intricacies of your life.

Paul: I must admit I’ve had a quick look at it and I haven’t signed up for it yet and you know it has that same clean look that your reports have and you know it’s obviously beautifully designed as well I mean we’ve spent a long time haven’t we talking about the collecting of the data I think that’s probably the most fascinating bit but as this is a web design podcast I feel like we should be talking about the design a little bit as well.

Nicholas: Absolutely.

Paul: You know I think the kind of key thing that really struck me is that you’re presenting, you know, fairly dry data and don’t get me wrong, I’m not implying that your life is boring but at the end of the day it’s data that you’re presenting and you’re doing that in a kind of visually stunning way. Tell us a bit about how the design comes together, you know. What’s your design process?

Nicholas: Well I have the benefit of being in control of all the data so if something isn’t looking right one way I can explore it a different way or I can rewrite a headline which is one of the greatest advantages that any designer can have rather than working for someone else. And then I sort of have an infographics approach where I really eschew using keys or trying to make your eye go in too many places to understand something so whenever possible I try and keep everything really focused so you can look in one spot and hopefully understand what’s going on there immediately rather than having to look at color codes or translate symbols unnaturally.

Paul: I mean is it, a lot of graphic designers out there that kind of find working with data and, you know, things like that incredibly dull. How do you keep inspired? How do you get something out of it? Because you’re not working with gorgeous imagery or anything like that, you know it’s quite dry, what inspires you about doing this kind of stuff?

Nicholas: Well I guess they’re kind of like puzzles for me. Um, I will see the establishing of infographics sort of like the data’s there and it wants to look interesting so how can I make a system that’s going to present it in the most instructional way? So I’ll play with that system so that it will line up in a dramatic way rather than just sitting in a static predictable line graph or bar chart or something like that.

Paul: I mean also you seem to use typography very heavily so I’m guessing that’s something you’re particularly passionate about.

Nicholas: Yeah I guess it’s my two natural loves in one place: the numbers and type.

Paul: Oh dear. So what advice would you give for us Web designers that are kind of, you know we do work with data a fair amount, you know from surveys through to content management systems that provide reporting and things like that. What do you think the key is to presenting data in an understandable and approachable format?

Nicholas: I think that one of the key things is just getting away from the default options that you’re given like I’ve found it’s really impossible to get a nice looking graph out of Excel or out of Apple’s Numbers and the same is kind of true for the Google Chart API which is what we use for daytum.com which is basically a way to send a URL to Google and they return a pie chart or a line graph but they can get really overly complicated and ugly very quickly so it’s a matter of stripping it down and making sure that this is something that’s going to be dramatic and simple to understand.

Paul: It’s that simplicity thing again that, you know, have taken something complex and as you say stripping it down and keeping it simple.

Nicholas: Absolutely, and even if you have the benefit being able to edit your material so that I’m looking at a pie chart that has four or five slices rather than seventeen I think it’s going to benefit your readers enormously.

Paul: So Daytum, that you are in the process, is that actually live now or is that still in the process of being developed? I can’t remember whether it was generally accessible or whether it was in a closed beta.

Nicholas: It’s in a beta but the wait list is down to less than a week now so it’s just a queue basically to protect out severs. But yeah, we’re adding new features all the time. We’re about to add averages there so you can examine your average cup of coffee or your average commute time and we just plan on trying to preserve the user experience by making sure we don’t get too swamped and growing it over time.

Paul: So how did this come about? You keep saying “we” so who’s the team that’s behind that?

Nicholas: Yes it’s my partner Ryan Case who is more on the development side but is also a fantastic user interface designer and he came to me in January or February of this year and like many people had said we should figure out a way to do this year reports on the web so that other people can do it but he had the technical chops and motivation to really get the ball rolling and he’s become actually a great data tracker himself and has been keeping track of all his beers religiously and all the trains he’s been taking, which I didn’t know he had in him. So I think it goes to show anybody with the proper motivation could get started.

Paul: So is this your full-time job now or is it a part-time project?

Nicholas: It’s about half-time at this point. I still have my editorial clients and web clients and identity clients that I work for but this definitely occupies as much free time as I can give to it.

Paul: Well I found the whole thing incredibly inspiring.

Nicholas: Thank you so much.

Paul: It made me look from a completely different perspective at graphic design and also at life in general I guess and we have so many people who come on the show that are talking about the stock and trade of web design and thought it’d be really good to get you on just to give a different perspective and make us look outside of our little boxes. Thank you so much for coming on and I wish you all the best in your various projects.

Nicholas: Thank you Paul. Thank you.

Paul: Good to talk to you.

Nicholas: OK, take care. Bye bye.

Thanks goes to Todd Dietrich for transcribing this interview.

Back to top

Listeners feedback:

This week’s listener contribution is a question from Dave. He writes:

I am having real problem maintaining users. They visit the site once and then I never seen them again. I have good content, the site is usable and so I am at a loss as to what I should do.

Should I be worried? Are repeat users really important? What can I do to keep them coming back which doesn’t cost a fortunate?

It is such a good question that it spawned an entire post on using community as a retention tool.

Back to top

The stickiness of community

For many, the Holy Grail of a successful website is ‘stickiness’. How do I keep users coming back for more?

Dave from somerset wrote: I am having real problem maintaining users. They visit the site once and then I never seen them again. I have good content, the site is usable and so I am at a loss as to what I should do.

Should I be worried? Are repeat users really important? What can I do to keep them coming back which doesn’t cost a fortunate?

I have written about the importance of repeat users before. These are the people who develop brand loyalty, complete calls to action and regularly purchase. For example, according to data from WebSideStory Inc. repeat users are eight times more likely to make a purchase on an ecommerce site. Repeat users are the lifeblood of most website.

One of the best ways to keep users coming back is to foster a community. However, a thriving community provides a lot more benefits than repeat traffic. An online community can also:

  • Improve your offering
  • Change brand perception
  • Promotes your site
  • Reduce your costs

We have covered the benefits of community on the podcast before. However, that was back in 2006 so my thinking has moved on since then. I therefore hope you will forgive me if I clarify what I mean when I say ‘community can help your business’.

Improving your offering

A good community is not just about users speaking to one another through a forum or chat room. It is also a two way dialogue between you and your users. It is an opportunity for you to hear from your users and discover what they want from your website.

In an attempt refine their products or hone their marketing message, many organisations spend substantial figures on focus groups and customer survey. However a healthy community is constantly providing feedback on your offering. This gives a superior insight into how your product or service should develop at little or no cost.

However, listening to your users does not just improve your offering. It also improves their perception of you.

Changing brand perception

People like to be heard. They like to feel their opinion matters. Engaging with your users and really listening to what they have to say about your products and services is incredibly powerful. It is even more powerful when they see their suggestions acted upon.

Both Dell and Microsoft have significantly improved the way their brands are perceived by talking to customers and engaging the community around their products.

Often this involves nothing more than a speedy response and apologetic tone. However, openness and transparency with a community can also go a long way.

It is possible not only to undo a negative brand perception but also nurture a positive one. And once users feel positive about your brand they start to recommend it to others.

Promoting your site

An community that is enthusiastic about your site or products can be one of the most powerful promotion tools available. Sites like Digg.com have become popular largely because of their passionate community. Equally, Apple’s success is at least partly reliant on their obsessional ‘fans’ who constantly push and promote their products. Nothing is as valuable as personal recommendation.

If you include your users in the process of developing your site they feel invested in it. They feel the site is as much theirs as yours and so will promote it as their own.

A successful community will always be seeking to draw others in, so growing and promoting your site. This ‘evangelistic’ tendency in a community can also lead to substantial cost savings.

Reducing your costs

As I have already said, a passionate community can provide free advertising and save money in focus groups and product development.

However they can also save money in customer support. This is particularly true if your site provides customer support. Rather than users sending queries directly to you, they can post them in support forums and allow others in the community to answer their questions. These forums also become a repository of knowledge others can draw upon. This reduces the support burden (and therefore cost) on your organisation.

Finally, communities have a lower cost of sale. Because they are already enthusiastic contributors to your community, they are easier to reach. This is especially true for repeat ordering.

Hopefully that has convinced you of the benefits found in community and given you some ideas of how to keep users coming back for more.

144. Scale

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

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

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

139. Brand

On this week’s show we’re joined by Ryan Carson to discuss building an online brand. We look at promoting your site with minimal budget and Marcus shares his views on working in an office.

Play

Download this show.

Launch our podcast player

News and events

Understanding progressive enhancement

Its funny how we spend our whole lives telling clients to avoid jargon and yet web design has more jargon than most. Every few months we seem to make up some new term that is thrown around like everybody knows it.

In reality some we have never heard certain terms, while others seems so similar to one another that the difference escapes us. Take for example ‘graceful degradation’ and ‘progressive enhancement’. Have you heard of them? Could you tell me the difference?

I have to be honest, I couldn’t. In fact in a few weeks you will hear an interview I recorded with Paul Annett from clear:left where I make a comment about graceful degradation and he said ‘no its more like progressive enhancement’. I had no clue why one was right and the other was wrong and I am supposedly a web design expert. Does that make me thick? Possibly. However, more likely I just missed the memo on that one.

The trouble is we are all too busy looking intelligent to clearly communicate with one another.

I have to some extent criticised A List Apart (among others) in the past for perpetuating this kind of ‘in the know mentality’. However, I am now being forced to eat my words (gratefully so) as they published an excellent article on Progressive Enhancement and why you should care about it.

Now if only somebody could explain what Web 2.0. really is.

A free conference (kind of)

I realise that some of the advice I give on this show is unrealistic for some. For example, I talk about the importance of attending conferences. However, when a conference can cost hundreds of pounds it is not always possible.

One alternative is to listen to the podcasts that most conferences published. Unfortunately, they are slow to appear and are hard to follow without being able to see the slides.

Fortunately, the FOWA in London has significantly raised the bar and other conferences will be forced to follow suit.

FOWA has released video of most talks. These appeared within hours of the speaker taking the stage, and are beautifully done including both speaker and screen.

There are also ‘highlights reels’ for most talks. These are a cut down version of the presentation, ideal if you are too busy to watch the whole thing.

With some of the most influential people in web design taking the stage, this is an invaluable resource and Carsonified should be congratulated for making it freely available.

Design Float

Talking of useful resources check out Design Float. Design Float is basically a Digg clone. However it is a clone aimed at designers.

I have to say I don’t like sites that rip off Digg. I have huge respect for what people like Daniel Burka and Joe Stump are doing at Digg. I hate to see people directly ripping off their work (normally badly).

However, Digg does have one flaw. It doesn’t serve the niche very well. Even Kevin Rose recently said: "We don’t really do a good job of servicing the long tail of content." And he is right.

As a web designer, categories such as technology or design are just too broad for me to bother following Digg regularly. Until this problem is resolved, Design Float is an alternative.

Design Float allows me to only see stories relating to web design and although the smaller community means that stories are posted less regularly, what is posted is pretty good.

I recommend checking it out. However, if you are a designer don’t just limit yourself to web design posts. Also look at the other design posts. There is some pretty inspiring stuff there.

Can we stop supporting text scaling?

Finally today, a post by Dave Shea in which he discusses page zooming.

Most modern browsers now support page zooming. The only exception is Safari and that will soon change. This allows users to zoom an entire page, not just the text. Obviously this is beneficial to those with visual impairments. However, is also exciting for web site owners and designers.

Traditionally websites have been forced to support text resizing. This significantly increased development time as well as making design integrity challenging. As text scales, designs often breakdown especially when fixed sized images are involved.

With page zooming these problems go away. It provides the designer with more control and reduces the costs of development. A cost normally passed on to the website owner.

Dave asks whether it is time to support page zoom rather than text resizing. As can be seem from the comments, there is no wrong or right answer. Nevertheless it is an interesting question and one you might want to start considering for your own site.

Back to top

Interview: Ryan Carson on Building an Online Brand

Paul: So I’m really excited to have joining me today Ryan Carson from Carsonified. Good to speak to you Ryan.

Ryan: Thanks for having me Paul. Good to be here.

Paul: It seems that we are crossing paths more and more often with me doing various things with Future Of conferences and you guys kindly giving discounts to my listeners, so it’s good to finally actually have you on the show.

Ryan: Thanks. It’s great to be here.

Paul: So the reason I have asked Ryan on to the show today is to talk a little bit about building an online brand. Carsonified have got lots of different brand identities going on with obviously Carsonified itself and then Future Of and ThinkVitamin and various other things. Ryan’s a bit of an expert really, or he comes across like that anyway, at building an online brand and I wanted to talk to him about how he’s gone about doing that. But before we get into that, Ryan, tell us a little bit about the background of Carsonified. How did it come into being, so to speak? How did it end up being what it is today?

Ryan: Well, it was kind of born four years ago. It started off basically as just me in our top bedroom. I used to be a developer in a web design studio and when Jill and I, my wife and I, got married four years ago we just decided to start our own company. At that point it was just me and I was trying to build web apps and attempting to make money and didn’t really do a great job of it. Then I kind of slowly moved into doing sort of more workshops and things and then we built our first proper web app, which was DropSend, and then we just kept growing and growing and doing more web apps and more websites, for ourself not for clients, and then we launched a couple big conferences, Future Of Web Apps and Future Of Web Design, and all of a sudden now we’re about eleven people. Located in Bath and just love what we do and are really excited to be part of the web industry. So that’s us kind of in a nutshell.

Paul: It’s quite interesting, the approach that you’ve taken. You’ve come from the same background as the vast majority of us yet your business has gone in a completely different direction. You haven’t gone down the road of delivering solutions to clients but you’ve done this quite eclectic thing of a bit of web apps here, conferences here. Was that an intentional thing or has it just kind of naturally evolved that way?

Ryan: It kind of naturally evolved but my mother, and your mom always knows you best, she always said there’s a vein that’s been running through my life for a long time, which is just connecting people. I don’t know, for whatever reason I just get a lot of joy out of connecting people and physical events are just a great way to do that. I’m passionate about the web and therefore it’s kind of like, well, connecting people in the web industry, in the technology sector is just kind of made sense. It did start off with this thing called BD4D which you probably don’t remember, By Designers For Designers. A friend and I did that and it was bd4d.com which is now gone but the idea was we got together designers for free just at a bar and people showed their work. It was in London originally and it kind of took off and I think then it was always just a for fun thing. We called it the Creative Fight Club. I think that was kind of the genesis of our events career. We don’t really see ourself as an events company we see ourselves very much as lovers of the web and technology and we just kind of happen to connect people at events so, it just kind of worked that way. I’m also not a big fan of working for clients because it’s just so hard. I really respect what you guys at Headscape and any web designer web developer because constantly doing work for clients is really hard work and it’s fun but it’s hard and because we run our own conferences and build our own web apps thankfully we’re our own client which gives us a bit more freedom. So that’s kind of how we ended up there.

Paul: It depends on how you look at it Ryan because from my point of view you’ve got thousands of clients while I only have one at a time because you have all those users of your apps and the people who come to your conferences. You’ve got far more trouble in my opinion.

Ryan: I guess you could look at it like that but they tend to be less demanding. They’re not paying us thousands of pounds each so it kind of. But you could look at it like that. We try to treat all of you who come to our show with the same respect as clients, it’s just a shorter term, lower economic value relationship.

Paul: OK, so let’s talk about brand a little bit and profile and stuff like that. Carsonified has kind of built quite a significant online profile and I’m just quite interested in some of the techniques that you’ve used to achieve that. You know, how have you made that happen?

Ryan: OK, well I think underlying everything we do is genuineness. I think that we care very much about honesty and being genuine and being kind and friendly and that sounds a bit fuzzy and happy but that’s just kind of, I don’t know, the way we are. And I think that’s been the key to our success, that when we do things people know that we’re not trying to pull the wool over their eyes or secretly sell them something. We have a genuine interest in the web and the tech industry and so when we do things people kind of know there’s real people that are behind this, we’re not some company. And I think we’ve always been very personal and very human and very transparent and I think that at least set the stage for being successful, but obviously we just follow through with pumping out tons of hopefully valuable content. We see building a brand as basically building friends and I think that on our blogs and through our tweets and at our events and through our communications we try to treat everybody as friends and that’s kind of, I think, a little bit of the key to our success.

Paul: I like that idea of talking about treating people as friends. I think that’s a good way. Too many people treat people as potential customers in preference to actually having any real interest in them as human beings I guess. So it’s good.

Ryan: Well yeah. I just kind of think about who do you like being around? I mean, It’s your friends and there’s a reason for that. I think why does business have to be different? Of course there’s an element of professionality but when you go to the pub and you relax it’s because you feel comfortable with people and I think that whole idea should permeate business. You know with your friends you just buy them a beer, but with your customers there’s significant money being exchanged I think that should involve even more trust than friendship. Hopefully our customers, our attendees and our sponsors really believe that we’re doing the right thing for them. You guys probably do something very similar when you work with your clients. You want them to know that you care about them. That this isn’t just about money that you actually are trying to build something beautiful and worthwhile for them.

Paul: Yeah. I mean it’s interesting. You talking about friends reminds me a little bit of the Innocent smoothie guys that I heard talking at Fuel, which is obviously one of your conferences, where they were talking about how they refer to their customers as family, don’t they? And I always thought was quite a. It sounds naff when you say out loud, referring to your customers as family but if you kind of treat them with that kind of respect, I don’t know, it’s good but it depends on how you get on with your family I guess.

Ryan: Yeah. It could be good or bad but the problem is that would never work if you didn’t actually think Innocent cared about you. If you looked on their bottle and there was E numbers and preservatives and stuff you’d think, “Well, they talk this stuff, but they don’t really seem that committed to doing this.” So I think it really needs to be backed up with a sincere and real effort to support. I mean, we’ve been talking about accessibility, this is a good example, at Carsonified for years. You know, “Yeah we care about accessibility and it’s a great thing,” but we don’t actually know what we’re doing and so we just met with AbilityNet yesterday with Robin and we said we want to get serious about this. I know that you guys are really good at accessibility and sort of putting our money where our mouth is. We want people with disabilities to be able to attend our shows and to use our websites. Let’s actually spend some money on that and get serious about it so at the bottom of each page we’re going to put a little thumbs up symbol that will go to a site that explains why accessibility is important to us and what we’ve done to move towards that with also sort of some tips and hints for people who are disabled like how can you use this site better and get more out of it so trying to put our money where our mouth is really.

Paul: Yeah. I tell you one of my favorite moments I ever had at one of your conferences was, I can’t even remember who the speaker was but the question that came out for the panel was about promoting your business and can you do that outside of San Francisco and California and this guy said you had to be in California you had to be at San Francisco if you wanted to launch a web app and you stood up afterwards and you completely laid into this guy and you said, “No no no, that’s not the case, blah blah blah.” But it does strike me, you know, you’re a Bath-based company and Bath isn’t exactly the beating heart of the web design world and I’m quite interested as to whether you feel that that’s been a barrier to you in any way, being based where you are.

Ryan: That’s a great question. It makes it harder, for sure. You know, we have to go to London to have meetings to go to drink, parties, to network, blah blah blah, but the way we make up for that, and I think a lot of your listeners won’t be in London necessarily or New York or Silicon Valley so this is applicable to all of you out there. It’s all about being visible on the web. And you guys do a good job of this as well. You just have to get yourself out there. So we blog as much as we can, we tweet as much as we can. We try to gather a community around us and that’s the way we make up for the fact that we’re not in London or Silicon Valley. I was going to say another important thing about building a brand, and this fits into that, you need to have an opinion in order to be heard, and that means that you have to be comfortable with the fact that people will completely disagree with you sometimes. You know I think in a way I’ve been successful at building a brand because I’m willing to say something that pisses people off really. You know and I think it’s only interesting to hear from someone who has an opinion. When Paul Graham said that “You know you need to be in the startup hub,” it just really made me angry, because he was basically saying to every one of us, well, you know you’re just kind of screwed, and I just thought, “You know what? That’s just not true, and it makes mad and I’m gonna sort of put my reputation on the line by going on stage and disagreeing with you, a well known entrepreneur.” And if I kind of was afraid to do that you know, not so many people know about et cetera. So yeah, get out there, blog, be as controversial as you can, you know as long as you’re being genuine and be ready for people to say mean things about you really.

Paul: Talking about mean things and people say mean things about you. You’ve come under some criticism for being somewhat pushy in your self-promotion. Do you think that’s kind of justified in any way? Do you think maybe there’s a cultural difference there, the fact that you’re American and are us English more uncomfortable with marketing and promoting ourselves?

Ryan: Yes, I think there is a cultural difference. But I’m also kind of, I like to think I’m friendly but I am sort of a brash person. I’m not afraid to tell you my opinion and do what I think I need to do. While being kind, I don’t want to sort of hurt anybody, but I think there is a cultural difference and I do think that, I mean my wife is English so I’m obviously very familiar with English culture now and British culture and I think there is kind of a slight uncomfortableness with getting on stage and blowing your own horn. I think that in the UK we need to get over that. Not change our culture here but be willing to admit that in the UK if we don’t start to step up to the plate and start talking about ourselves, the rest of the world’s just gonna carry on in the tech space. Mike Harrington, he’s not going to shut up. You know and unless we really start to kind of compete with that and start talk about all of the great things that are going on in the UK and really kind of get out there I think unfortunately it means that the startups and the web designers and web developers that are British are going to start to fall behind in the world stage. For instance, I was trying to think, who are the rock star developers in the UK? Who can you name? I mean I can name a couple but who do you think?

Paul: It’s hard. It’s hard to say. I think there are more rock star designers than there are developers. You know you can think of people like Rachel Andrew, and Drew. Two that spring to mind. Jeremy Keith is kind of a developer but maybe not really.

Ryan: Matt Biddle. You know, there’s a few but it’s just. It’s not the plethora that are sort of being spoken about, in the US particularly, but I have no doubt there’s just as many talented people here. It’s just that, that hesitancy to say, “I’m going to do my own startup. I’ve got a good idea. I’ve got what it takes. I’m gonna start talking about it.” It’s just less common over here. I’m not saying that’s a bad thing and that everyone here should change but I think if you want to build a brand in the web space you just need to admit that I’ve got to get out there. You know I had an interesting conversation with Alex Hunter who is sort of really big in Virgin, The Virgin Group, he’s high up and he’s met Richard Branson a bunch of times. And you know what was crazy? He said that Richard was really shy. And I was like, “Really?” That’s a great example I think of a guy, he’s obviously driven and I don’t think everyone should be like Richard Branson but he’s obviously driven and he understands that in order to get Virgin talked about, to build a brand he’s got to be kind of crazy and get out there. He’s always hanging from helicopters or you know flying spaceships and you know, that’s why people talk about him.

Paul: I think there’s also a little bit within the web design community here in the UK of kind of almost false modesty and a little bit of trying to persuade the world that we’re being very altruistic in what we’re doing and not being up front. I receive criticism for the fact that I’m very open about the fact that Boagworld is a marketing tool and that we make money out of it.

Ryan: But it’s the truth.

Paul: Yeah, exactly. So I think I prefer to be up front about those things, than kind of hide them behind a façade of false modesty to be honest.

Ryan: Well yeah and that kind of goes back to my thing I said earlier about being genuine. I think you’ll always be better off if you’re genuine. And of course we’re sort of painting with broad brushstrokes here, but there’s some very talented people here and I just think, let’s get on our soap boxes and sort of shouting back at the Americans really. And people are doing it, I just think there should be more of it.

Paul: Talking about effective marketing tools, ThinkVitamin, let’s talk about that for a little bit. ThinkVitamin is a website that you run which is basically web design related and web app related kind of articles and stuff like that. I’m guessing that was set up as a marketing tool. Tell me a little bit about why it exists and how you came about setting it up and what its aim is for you.

Ryan: Yes. So thinkvitamin.com has two purposes. It’s to build good will and to give back to the community but it’s also a marketing tool and those things are actually very related. If we pump out great content we give away for free it will be valuable, but those of you who read thinkvitamin.com will also probably come to our shows. It’s a symbiotic relationship. We’re very happy to do that. There is a little bit of altruism there, we do actually want to provide good content and give it away for free but we also realize we needed a platform to talk about our shows. We kind of kept calling in favors like, “Do you mind blogging about Future Of Web Apps?” and “Can you mention it?” We just thought we need to build a big site that people go to so we can tell them about that and we’re fortunate to have great connections. We know people like you and Molly Holzschlag and Kevin Rose and just big Internet people and they all agreed to be on the advisory board and really that’s just a group of people that we trust that occasionally write for us but we’re actually taking ThinkVitamin in a new direction where we want it to pretty much become it’s own little business. So we’ve hired a full time Editor named Simon Mackie and he was really high up at SitePoint actually. And he’s come over and he’s taken the reigns and we’re gonna, yeah we’re gonna basically grow that team and expand that out into its own little business.

Paul: That’s interesting.

Ryan: It’ll be better for the readers. It kind of was dying. The publishing schedule was going down and I think we realized, “Man this is so valuable we have over 50,000 RSS subscribers, closer to 70 if you count the news feed,” and we thought, “This is great, we should grow it.”

Paul: Yeah. I mean it’s interesting in some ways you’ve kind of taken the same approach that we have at Headscape using ThinkVitamin that you could have created a blog on the Futures Of website and you could have put this content there. There’s actually a value in separating it out and making it a standalone thing. It feels less salesy I guess. The same way as I could have posted my Boagworld stuff on the Headscape site. You know it could be the Headscape podcast instead of the Boagworld one. All the rest of it. It just comes on a bit too strong if you do that I guess.

Ryan: I totally agree. And it’s interesting because I had a good conversation with Mike at FreshBooks, and freshbooks.com for those of you who don’t know is an app that helps you send out invoices. He had this blog and he was really slogging his guts out on it and at freshbooks.com/blog or something and he said, “I don’t get it. No one’s really reading it,” and to me it was obvious for that reason you just said. Well it’s clear that this is just a marketing tool. Why would you put a blog on your company’s site, on your product’s site? It’s just kind of obvious and that’s exactly why we haven’t done it for our events, you know we put occasional updates there but it’s hard. As much as I like Web 2.0 Expo or something I would never read a blog from Web 2.0 Expo. It’s just too blech, you know what I mean?

Paul: Yeah totally. It’s interesting that the other thing that you’ve done, which again is something that I do, which is that you haven’t just relied on people coming into your sites, whether it be ThinkVitamin or the Futures Of sites or even the Carsonified site. You’ve made a big deal of kind of going out there and using tools like Twitter and Qik and YouTube. I’m just interested as how effective you’ve found those things.

Ryan: I find Qik to be really effective, or Qik, however the heck you say it qik.com and I was really shocked as soon as I started broadcasting was that just tons of people were interacting and I almost couldn’t wait to do the next one. Annoyingly 3G is kind of spotty in Bath so it makes the quality a little bit bad but I’d highly recommend Qik or any other comparable service. It’s so fun you just take your phone with you, I had to get a kind of crappy Nokia phone or something, because I use my iPhone for normal business but just grabbed it from the 3 store, got a plan I think it’s 20 pounds a month that gives you unlimited data which you’ll need if you’re streaming live video from a phone, and whenever I’d walk to Starbucks or something I’d just turn it on and start talking and people would show up because the way Qik works for people who don’t know is you actually see comments live on the phone screen.

Paul: That’s very cool.

Ryan: Yeah, it’s great for interaction and any tool you can use to interact with your fans will increase your connection and that friendship. It will show you want to be real and you want to connect with people and I think hopefully we’ve achieved that where people think, “Gosh you know Carsonified we know who’s there we know it’s not a company it’s really these people that are there and they’re interested in hearing from me and talking to me,” so that’s been good. YouTube has been amazing, I mean I hate YouTube, it’s ugly, it’s a bit crude you know but man there’s just a lot of people on it. I used this cruddy little video camera, filmed myself giving some tips about business, threw it in iMovie, put some music to it and popped it on YouTube and I think I can’t remember the figures it’s up to, it’s up to like 10 or 15,000 views in literally like two hours work.

Paul: Yeah, I keep meaning to get around to that myself and I’ve never quite managed it.

Ryan: Now you can use a Flip camera. Flip is just a type of camera, you just record and then it’s got a USB dongle built right into it. You pop it in and it actually automatically uploads it to YouTube.

Paul: That’s nice.

Ryan: There’s a couple tools you can use to make it easier. And then Facebook, I’ve been using Facebook a lot just to connect with people and remember people’s birthdays and say hello and just be a friend to them. The more connections you can have to people the better, which builds your brand and I feel that, like a mercenary when I say that, and I don’t like it, like I do believe it’s just a better way to live to connect with people and it happens to build your brand which is great and I like that as well, but I think it’s important that you need to be genuine and actually care about people for this to connect.

Paul: What about Twitter? How have you got on with that? Have you found that a useful tool?

Ryan: I love Twitter. And it’s been probably the best way I think for me to communicate I’ve got I think around 4,200 followers now and I don’t know why people follow me. I don’t think I’m particularly interesting but I do whenever I tweet I try to imagine if I was somebody else and I was reading it if I would find it interesting. I think with Twitter don’t tweet too much, maybe a couple times a day max. If you tweet too much people unsubscribe.

Paul: That will explain my problem then, I tweet too much.

Ryan: I still follow you so it’s not too bad. But you know Evan Williams had a good tip he said you should tweet things every so often that you’re not quite sure if you should tweet because they’re a bit too personal or a bit too blech, because that’s the type of stuff that’s actually fun and interesting to read. Initially we had a twitter account for Carsonified and we deleted it. I think we decided that that was kind of exactly what not to do. People don’t really want to hear from a company, they want to hear from you.

Paul: That’s almost the same as having a blog on your own corporate website isn’t it? Having a kind of corporate Twitter account. After saying that we have set one up for GetSignoff but more as a for announcements. If something goes down with the service or if we’ve done some bug fixes or stuff like that. By far the majority I do via the Boagworld Twitter account which is just me talking about my life. I agree with what you’re saying about putting personal stuff there as well that people seem to like to know what’s going on with each other’s lives. I like to know how Jackson’s doing. People like to know, I don’t know. Making it personal, it’s about that personal connection again isn’t it really?

Ryan: Definitely. And I think that that’s the future, you know just in general. Humankind you know it’s just kind of being personal and not hiding anymore behind companies or brands or policies or terms and conditions. It’s about, “Hey, how can I help you and how can I take care of you?” and that’s just a better way to live and it will massively benefit your company which is great. What’s interesting though is that everybody, including us, continues to look at the Signal vs. Noise blog from 37signals and kind of scratch our heads it’s like, it’s the one blog where it is a company blog, I mean yes it’s called Signal vs. Noise, but it’s on their domain, and yet they have over 90,000 subscribers. It’s funny because I think everyone is kind of, “How do you do that? I want to replicate that.” In the end I think you know, they were kind of first. You can’t have that many of those type of blogs and I think most of us are gonna have to be happy with just doing a good blog that is real and personal whether, and I mean ours is carsonified.com and it seems to work and we have about 4,000 subscribers and for us that’s a pretty good number. We should post more but that’s something I haven’t quite figured out yet and I’d be interested to hear from your listeners what they think about that. Is it possible to have a company blog that people care about or is it just not possible? I don’t know.

Paul: I think what you said there about being first is quite significant. I think originality goes a long way. I mean even with the Boagworld podcast. Simply the fact that I was the first web design podcast it seems to give it a momentum that keeps things going, you know because you keep delivering the goods so to speak which obviously the guys at 37signals really have done. I think there is a momentum in being first in something.

Ryan: Yes and that’s probably the secret sauce.

Paul: OK, So let’s wrap this up with kind of a last question which is: What advice would you give to budding entrepreneurs seeking to increase their profile? Let’s have some kind of top tips if you’ve got some.

Ryan: OK. The first tip I give is to start connecting with people that you feel are influential. You know, spend some time and try to get out and physically meet these people, get to know them and to not be creepy about it, but to get out there, to get in front of them and to get to know them. See if you can do something to help them out, to get on their radar, and I think building sort of a group of friends that trusts you but is also influential is just instantly valuable. So I’d do that and you can use all the tools we talked about for that: Facebook, Twitter, etc. etc. but physical meeting is always the best. I mean you want to have a beer with people.

Paul: And you say you do that by trying to help them out in some way? Because that’s always the difficult thing. It’s all well and good to say, “Get to know influential people,” but how you do that’s the tricky part isn’t it?

Ryan: Well my dad always did something that worked. If it was someone he really respected or cared about and wanted to get on their radar he would find an article about them in a magazine and he’d actually go to a framer and have it framed and then write them a personal note and just kind of say and send it to them and say, “You know, I bet you haven’t had time to actually frame a picture of your article so I thought you might want this for your wall.”

Paul: What a genius idea. I love it.

Ryan: And it’s genuine. I’m not trying to get anything out of you but I respect you and here you go. It’s very subtle. You have to be very careful to not try to sort of bribe people. If you come across that way it’s exactly what you don’t want to do. If you feel, and kind of think deep down, “Do I actually want to be friends with this person or am I trying to use them?” I think you should steer very clear of a person if you just think actually I don’t really like this person I’m just trying to get something out of them. But if you think there’s some synergy there, that’s a great way to do it. Remember people’s birthdays, it’s just a nice thing to do. Stuff like that is a great way. Most people’s friends don’t even do that for them. I’ve had people send me stuff and you know it just makes me smile and I’ll always take their call or answer their email now. So I think that’s a good idea.

Paul: Any others?

Ryan: Um, other tips. Um, probably put a real emphasis on customer service and build a real base of caring in your company. Not just for your customers but for your own team. I think that your team will never be able to treat your customers well if they don’t think that they’re treated well. So I think as entrepreneurs grow and they start to hire people I think it’s important to remember to take care of your staff first and then your customers second. And a really great resource for that is what zappos.com does. Zappos.com has an amazing company culture. They have this book called the Culture Book and every year it comes out and you can buy it and it’s basically a bunch of testimonials, thousands of them from the Zappos employees about why they love their job. And it’s just packed full of ideas of how to take care of your team and it’s a great inspirational resource. I think you can either get it on eBay or Amazon or you can buy it straight from Zappos. A couple hopefully useful tips?

Paul: Yeah that’s excellent. Ryan thank you so much for coming on the show, it’s been really good to get you on and I think there’s some really good useful advice there for anybody looking to kind of build an online brand so thank you very much and no doubt we will have you back again soon.

Ryan: Thank you, it’s an honor.

Thanks goes to Todd Dietrich for transcribing this interview.

Back to top

Listeners feedback:

Site promotion with minimal budget

Our first question is from Adam in the boagworld forum:

I have got a site that needs an awful lot of promotion to work, and have got very little budget to do it with. I could probably spend a little bit on Google AdWords but on nothing else. So, how can I promote my site for little money?

Adam went on to tell me it was a charity website. This makes it challenging. As Adam said…

There are thousands of Charity sites, and many better funded, and just altogether bigger.

In this situation search engine optimisation or Adwords is going to be tough. The competition is fierce and so it will be expensive to be highly ranked.

The other problem with a charity site is that unless it is niche (e.g. bird protection) the potential audience is open ended. However, with limited resources there is little point in targeting ‘the general public’. You will have no impact on such a broad audience.

Target a specific group as it will be easier to gain momentum within a smaller audience. For example, there are Christian charities who do general humanitarian aid. Even though anybody could be a potential supporter, they instead target other christians. Therefore they are well known in that circle. Better to have a lot of support from a niche audience than a small amount of support across the general populous.

Once you have picked the audience use three techniques to reach them:

  • Offline promotion – Engage with your audience offline as well as on. Attend conferences, produce offline promotional material and target magazines your audience reads. As web designers we often forget to power of offline marketing.
  • Social marketing – Identify the social sites your audience You should be wherever your audience is interacting. Finally, seek out key figures who your audience admire and respect. See if you can get them on board and encourage them to promote your site.
  • Editorial promotion - Find out if your audience reads online blogs or magazines. Offer to write articles for these sites. Do not overtly promote your charity but instead write content which will be of interest to the audience. Failing that make use of comments to join in the discussions and increase your sites profile among that audience.

However, be careful. In your haste to promote your site do not spam. The key is to offer something of value. You must earn the right to promote your site.

Sitepoint has an excellent article entitled ‘10 rules for driving traffic using forums‘. Although it is focused on forums, its advice is applicable to most forms of online promotion.

Office Or Not

This from Brad:

A question from Canada! I’m a long-time listener of the show, and I thank you both for your entertainment and inspiration.

A little bit of background first… Two years ago I co-founded a small web development company, and to date we have not yet invested in office space. As we slowly move on to ‘higher profile’ clients, we find it increasingly important to have someone in-house, to answered the phones, do the books, etc, etc, so we can focus on growing the business.

That said, I’m obviously touching on a huge spectrum of possible questions, so I’ll try to narrow it down. I don’t think this is something you have covered specifically on the show before…

Is office space really important for a creative business? If so, what steps would you recommend. And if not, are there better areas to spend $2000 / month?

If I had been asked this question only two years or so ago I would have said that office working for a web team is not important at all. If anything, I would have said that home working was better. The following extract from Paul’s blog, written in 2005, underlines this:

The benefits of a virtual company

By virtual company, I mean we do not have a central office. Each member of staff works from home and we communicate and file share with tools such as Skype, CVS and Groove.

People are often curious about an entire company home working and ask how well it works in reality. My answer is usually that it is brilliant. From the employee perspective, you do not have to commute and you can see a lot more of your family. For example, if I were still working for IBM when I used to commute an hour and a half everyday, I would only see my 2-year-old son at weekends. As an employer, I love it because my staff tend to work the hours they would commute and generally home working is seen as a big bonus that keeps people at the company longer. Not to mention the savings made on premises.

Communication really is not a big problem. There are so many tools out there these days that help, and broadband means that even telephone conversations are now free.

Paul goes on to say that the only drawback of home working is that it lacks the social aspects of working in an office.

Not true I’m afraid. Though of course home working does give you an environment to ‘get your head down’ without interruption, what it really lacks, that phone/email/IM cannot replace, is creative collaboration. People simply do not bounce ideas around like they do if they work together.

Our current office is open plan and there’s nowhere to hide yourself away. This has meant that I haven’t really frequented it that often – I need ‘calm’ to write. However, watching particularly our development team grow and work really effectively together underlined to all of us the value of working together.

So much so that we are about to move into our ‘dream’ offices where there will be a mixture of open plan spaces and areas where we can work quietly.

So (finally!), in answer to Brad’s question, I think that office working is better for the business in the long run and I would say warrants the additional associated cost (though beware the costs, they can mount up – another podcast topic I think). That said, we have managed for nearly seven years before doing it properly (i.e. pretty much all of us will be in together most of the time) so it won’t necessarily damage you if you leave it awhile.

Back to top

136. Stagnation

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