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.

167. Beyond Technology

On this week’s show: Paul shares his inspiration on blog writing and we talk to Mike Kus about our obsession with technology.

Play

Download this show.

Launch our podcast player

News

Good vs Great Design

Cameron Moll is one of the most intelligent and inspirational designers I know. Where some design on an instinctive level finding it hard to describe what makes their designs work, Cameron has carefully deconstructed his work and seems to have a firm grasp of what makes it tick. He understands design. He understands the processes behind design and the rules that make it as much a science as an art.

This deep understanding of design shines through in a free PDF download (Good vs. Great Design) available from his website. The PDF has been produced to accompany his talk at the HOW design conference in Austin Texas and is packed with little insights into good design practice.

The document is only 10 pages long and yet touches on subjects as diverse and grandiose as…

  • The nature of great design
  • The differences between influence and inspiration
  • The need to understand a problem before searching for a solution
  • The power of typography
  • Definitions of visual hierarchy
  • The need for a ‘creative pause’
Obviously, there is only so much Cameron can cover in 10 pages. However, the document is a great starting point for further reading on the subject. Cameron recommends 4 books in particular…
  • How Designers Think (Bryan Lawson) – A book devoted to the idea that design thinking is a skill, and as such it is something that can be improved.
  • The Elements of Typographic Style (Robert Bringhurst) – A complete study in typography, from the broadest concepts to the smallest details.
  • Universal Principles of Design (William Lidwell, Kritina Holden, Jill Butler) – A reference of vocabulary and examples from the disciplines of graphic design and user interface design.
  • The Design of Everyday Things (Donald A. Norman) – An extensive investigation of the interplay between design and living.

If you are looking to deepen your understanding of design, then this is a great place to start.

Eye tracking findings

I have mixed feelings about eye tracking exercises. This is probably partly because I am not particularly knowledgeable on the subject. Although, I am happy to acknowledge that they offer a valuable insight into users behavior and are a useful tool in our usability arsenal, I do have two concerns…

  • Running an eye tracking session is expensive. If this leads to a reduction in the number of rounds of traditional user testing or the number of users tested, then I would have serious concerns.
  • Although eye tracking provides an insight into where a user is looking, it does not reveal anything about intent or comprehension. For example, if a user only briefly glances at a key screen element this doesn’t necessarily mean they are ignoring it. It could mean that it is well designed and the user quickly processed the information it was attempting to convey.

Ultimately, I would be concerned to see too much weight put on their results. That said, it is interesting to see the results of eye tracking and Eyetrack have released some results from one such exercise that focused on the homepages of news site. Useful nuggets included…

  • Dominant headlines most often draw the eye first upon entering the page.
  • Smaller type encourages focused viewing behavior.
  • Navigation placed at the top of a homepage performed best.
  • Shorter paragraphs performed better.
  • We also learned that the bigger the image, the more time people took to look at it.
  • Our research also shows that clean, clear faces in images attract more eye fixations on homepages.

It’s a good read and although most of the points are common sense, it is nice to have evidence to backup those opinions.

Online reputation management

“Online reputation management” – Sounds ghastly doesn’t it? Sounds like the horrible love child of social media and marketing BS. That said, for better or worse, it is becoming increasingly important to manage how we are perceived online.

As I recently said in an interview at FOWD, our websites are no longer the only place where our brand is discussed. As a result we need to engage with users wherever they are talking about us. The question is, how do we do that successfully?

Whether we are responsible for our organizations brand or just want to know what is being said about us personally, there are various techniques and tools that can help.

This week Sitepoint have brought those tools and techniques together in 3 useful and informative posts…

Past disasters like Dell Hell are perfect examples of just how important this area is. It is time we all started to think carefully about how we are perceived.

7 Quick CSS Enhancements for Better User Experience

I haven’t seen much written about CSS over the last year or so. It has been as if everything that can be said about CSS, has been said. However, just recently we are beginning to see a few CSS focused blog posts appearing. One example is 7 Quick CSS Enhancements for Better User Experience by David Walsh.

What I love about this post is the ideas suggested can be applied on top of an existing site design. They are just little ‘touches’ that make the site visually more appealing and easier to use. The 7 suggestions are…

  • Change the text colour of selected links
  • Prevent Firefox scroll bars from jumping
  • Give form fields rounded corner
  • Control where page break occurs when printing
  • Show icons that identify the file type of link destinations
  • Change the cursor when it hovers over a submit button or label so it actually looks clickable
  • Increase the clickable area of a link  using display:block

Each suggestion comes with an explanation of its benefits and the code required to implement.

Admittedly not all browsers will understand these enhancements. However, because they are not crucial to the functionality that really does not matter. Its a nice example of graded browser support.

Back to top

Interview: Mike Kus on our obsession with technology

Paul: Okay, so joining me today is Mike Kus from Carsonified – good to have you on the show.

Mike: Good to be here.

Paul: It’s really nice. So, as the listeners will have gathered by now, we’re doing a whole series of little interviews off the back of ‘The Future of Web Design’ conference, where we can do all our interviews in one go, rather than spreading them out over time.

Marcus: Yay, we like this.

Paul: So Mike has just finished his presentation and there’s some excellent stuff in there, but you were quite kind of, what’s the word… You were quite harsh to the poor web design community and their obsession with details of technological stuff.

Mike: Yeah, maybe yeah.

Paul: You know, all of this “does it really matter whether your code validates”, not that you used that as an example, but I can’t remember what examples you did use, you did have a few didn’t you.

Mike: No, well I mean things like [a lot of debate to un-debate] which I come across and you see lots of times. You know, it’s a question that’s probably never going to get answered. I just come across it all the time still, and it’s like make up your own mind and move on.

Paul: I got the impression that you feel that perhaps as a community we’re a little bit petit, and overly concerned with minutia.

Mike: No, I mean, I love the web community *laughter*, no I do I love it and I love being part of it; it’s great. The funny thing is I started off two years ago doing web stuff, and I really do feel now two years on, that web design… I don’t see many differences to me between web and print now. It’s all the same thing to me, you’re just designing, you know. And I guess because I feel design is so important, I sort of maybe feel a bit left out *laughter* in conversations, because people don’t seem to talk about the design as much. And the reason that talk was called “Forgotten Web Standards”, I mean I know some guy heckled at the end saying about it not really…

Paul: “It’s not really a web standard.”

Mike: No, and I know that. It’s just a cool title I thought – it gets people thinking, and really the part that related to web standards was just because I feel like for a site, good layout and thinking about things from a graphic design point of view contributes to accessibility on a web site.

Paul: Yeah. And also to be honest, I mean what is web standards other than a set of guidelines and criteria. Equally there’s sets of guidelines and criteria about good design; use of colour, you know.

Mike: Well that’s it, yeah. To be honest it was really more just a good title, and I didn’t expect people to start analysing.

Paul: But they will!

Mike: Yeah I know, yeah; I should have known.

Paul: But I think you raised an interesting point, or a good point which is that we can get so hung up in the logistics of how web sites are built that we’re not always giving the attention to the design aspects of it. And even more specific than that, it’s the whole discussion about, you know, we spend a lot of time talking about usability and accessibility, but aesthetics do matter. We almost have this attitude in some ways that aesthetics are just skinning it afterwards.

Mike: Yeah, yeah I know, I agree. I think aesthetics do, well to me they matter. You know my opinion is just my opinion and other people have different opinions, and on a day like today you’re going to get people talking about the code side of things, and I just feel that I know what I know best, and it’s what I can bring to it, it’s what I can bring to the table, and people can take away from it what they like. Someone’s got to do it haven’t they.

Paul: It’s quite interesting, in your mind you don’t make a differentiation between the print stuff you do and the online stuff you do. Surely there are differences Mike.

Mike: Of course there are differences, yeah. But the processes I go through as a designer are the same.

Paul: Right.

Mike: I’ve noticed that much more; I guess of course there are differences. I mean for a start you’ve got to think about things differently in web design because you’ve got to make sure that people understand where you’ve got to go to click things; how you’re going to navigate your way through the site. But once you sort of know that, it’s sort of… Once you’ve built a load of sites and you know that, that’s just something that comes naturally to think about.That’s a different part, that part where you just get used to doing it, then ,he essence of the process is the same. Designing something for a web site, I find there are the same pitfalls and hurdles designing for print as for web. And the funny thing is, and I really feel now as well, that the coding side… I’m not the best coder in the world, and probably not the worst, but I’ve learnt loads in this past year, and I’m writing much cleaner code now than I was a year ago. I enjoy that too, and I know it’s important.

Paul: Yeah. But like you say there are lots of people discussing that, and not as many discussing the design side of things.

Mike: Yeah, and I totally read up on stuff about code; I know it’s important. I guess for me, sometimes I’d want to go in line and get involved in discussions about design, and I know you get Photoshop tips and tutorials don’t you, but that’s not really design.

Paul: Yeah. But a lot of that’s about using the tools of design rather than the principles of design.

Mike: Exactly, it’s all tools yeah. I’m interested in the principles and the ideas and imagination part, you know.

Paul: You talked in your presentation about design aiding the experience, you know; experience based design. I was just interested to hear you talk a little more around that, about how you feel that design can… In what ways can design affect the experience that a user has and what do you mean by the ‘the experience of a user’?

Mike: Well I guess I mean when I go to a web site, and for a start, at least if we’re just talking from an aesthetic point of view, if I return to, and again this is something that appeals to me, if I go to a web site and it gob smacks because it looks so beautiful, that in one foul swoop is my experience of it, you know? But I think there are other things more technical, and when I say technical I don’t mean in a code way, but in a technical graphic design way, you can enhance people’s experience just by… I like the idea of merging more, like you said, things I learnt at college about graphic design and where to make people look in a page, and how to highlight. Combining the technical bits of graphic design, what to highlight and what to push back, how to take people’s eyes in to the bits you want them to read, and then the slightly less important stuff, pushed back a bit, and combining that with an aesthetic. So if you’ve got a great aesthetic and you’ve really thought about where people are looking on your page, and how they’re going to follow through you’re site, to me those things combined is what I mean by designing for experience; a good experience. Because you could obviously design for a bad experience!

Paul: Well obviously, yeah, that’s easier! Another thing that interests me about your work in particular, and really people need to go and look at examples of stuff that you’ve done to grasp this, but you have a very distinct and obvious style; I think you do anyway. So I can look at the stuff you’ve done for Carsonified, and then even the stuff you’ve done here for Microsoft and there’s obviously a consistent theme to that. Do you think that having a very strong style creates problems sometimes when you’re trying to reach different audiences, and you’ve got to battle with your own style, do you find that a problem?

Mike: Well, this is something I find really interesting because growing up as a graphic designer and stuff, I was always someone who basically… For a start if you’re working for clients and you’re an agency, and you’re getting different jobs, you’ve obviously got to be able to create something completely different one day to the next, potentially. And the funny thing is I actually carried that through into my personal work, and I was like “I can’t do something like this because I’ve done something that looks a bit like that before.” But then you know how you can get famous illustrators who basically churn out the same stuff all the time and they get seriously famous, and one company gets them to do something, and another company…

Paul: They come to that person because of that style.

Mike: Exactly, and I think the only reason my stuff you’re seeing… if you looked at the Orchestrate site, that’s me turning my hand to something through a brief.

Paul: Yeah that’s true actually, yeah, because that has got a very different style.

Mike: I’m just answering the brief there, you know, so it is something I can do.

Paul: Sorry, I didn’t mean to imply you couldn’t, it’s a constant discussion isn’t it.

Mike: I don’t think you implied that *laughter* But it’s interesting, and the only reason I do bring my style into the projects you see that overlap each other is because I’ve had the freedom to do so.

Paul: Yeah, and I guess to some degree, the style that I’m exposed to is the style that’s aimed at people like me.

Mike: Yeah.

Paul: So the fact that you did the Microsoft stand here at ‘The Future of Web Design’, well actually it’s good that it’s got the same style as the other stuff that’s going on because it’s a style aimed at web designers and people like me.

Mike: Yeah, and another thing about doing stuff that’s similar, is you do get to get known for a certain thing, which in some ways I think “is that good or bad?” I don’t know, but I think I’m keen to make sure people know I can do different stuff. But at the same time I’m happy to be known for a certain style, because I think it’s sort of like an identity you get. And so I’d like to keep a balance there, but I definitely don’t mind being known for something that’s got a feel about it.

Paul: Yeah. I mean equally after saying that, which kind of brings me on to the next topic I want to talk about, is that the style that I typically associate you with is quite illustrative, you know, you’ve got this certain way of doing things. And then your set of slides for this week weren’t at all like that, they were very typographic, and you did talk a little bit about typography. We interviewed Mark Bolton on the subject of typography as well. I’m interested in your take on typography because you seem to use letter forms almost as design tools rather than necessarily as standard typography if that makes sense.

Mike: Yeah, well that’s interesting because when I did those slides, the reason they look like that is because I basically took a theme and I got interested with that, what’s his name… I can’t remember, a Swiss graphic designer, very famous I can’t remember his name now, it’s escaped from me, but it’s sort of Swiss modern graphic design, and I was looking at Swiss modern graphic design and some Russian constructivism stuff on Flickr, you know. And because when I was at college, that sort of graphic design, I was brought up on that; it was the first thing I was interested in, and because it was a graphic design themed talk, I used that as the style. And it just so happened that throughout it, the experiment with type and shapes and stuff was something that just happened in making those slides, and I suddenly realised I was getting something out of using type in a graphical way, it’s not just about the words, I mean a slide I like – my own stuff I love! *laughter* – that one that says (and I loved doing that slide and I think it looked great) was the one that said “buck trends and break conventions”, and conventions was all mashed up in different ways. There’s something beautiful about type though isn’t there, like huge letters, and I wish I could have seen those slides, because that screen was so big.

Paul: It looked spectacular, yeah.

Mike: There was a huge, massive letter N, you know. I guess now it excites me, type; I think it can be the basis for great design, not just in a traditional typography way, but actually great graphic design. I guess I think the whole type debate as in “where are we going to get all the fonts from”, or “what’s going to be the standard way of using them” – for some reason I don’t feel restricted by the web font thing.

Paul: No, it’s interesting. Mark was saying exactly the same thing as well.

Mike: It’s not something that bothers me, and I’m quite happy.

Paul: I mean a lot of the ways, certainly the ways you used them in the slides, we’re talking about using type as a graphic element in those cases, rather than necessarily to convey large amounts of copy; it’s a subtlety different thing going on there.

Mike: Yeah, yeah.

Paul: I was also quite interested when you talked in your presentation about a logo design that you did, and about how you were being stopped at every turn by the client effectively because they were saying “no, no, we don’t want to be associated with that etc.” So you then added in a strap line into that which you then built the logo around the strap line rather than the brand itself. Now, that was quite interesting because that gets into the realms of relationship between copy and design, and how the two things work together. And in that case, you came up with the strap line did you?

Mike: Yeah, I’m quite into… I mean, I don’t want to say it myself, but Ryan for example seems to think I’m quite good at copy – which is nice of him to say. It’s a way I work quite a lot, I’ve done loads and loads of logo / branding stuff in the past, and I did something, for example, for the Body Shop once. Basically I could do anything, and it was about raising money for a school in Kosovo to get it built, and they just wanted a poster. I just thought of a strap line anyway, because I could do anything I wanted. It was “building a future”, and that was all it was, and it had all these huge letters. Well it had “building a future” and the letters were all piled up and leaning against each other. I guess often the first thing I think of is copy whenever I’m designing something, especially if I’ve got a new site to design, I’m like well what are the words, what’s going on, what’s it about, is there a strap line, do you need one – you know – what’s written in the first paragraphs in the home page, is there something in there I can use to spark the idea for the design. I think copy in that respect has got a massive relationship to design. It’s rubbish trying to work with Latin text.

Paul: Yeah I know, lipsum, yeah.

Mike: It’s alright for that filling in a paragraph or something, but it’s nice to have that proper copy to hook your design on to it; it can be really helpful.

Paul: The thing that you intrigued me with is that you were going through things like layout, colour, typography, then you hit imagery, and you said there’s a whole presentation there. I want to know what the presentation is, I want to know what is it that you know, obviously there’s a lot of depth there that you couldn’t cover, and I’m just interested in that.

Mike: I think what it was, you’ve talked about my illustrative stuff already, so say you use that for the sake of argument right now because you could apply this to photography as well, I guess to me a site doesn’t have to be like you put it together; I don’t know, I’m going to put a picture here or an illustration there… It can evolve round an illustration from the very beginning. I know it’s a pretty one off site, but the Twiggy site for example, which is just a bit of fun, really quick, but that was just literally me, do what the hell I want, just have fun, and it wasn’t the most practical site design maybe, but you know that just literally was an image that built up and changed, and it was the basis for that site design. It wasn’t just in the site it was the site, and it had the huge letters in the background. I only had a short slot, and if I had more time I would have gone into why I felt it can be the basis for your site, not just something you add to it. Your site can grow from your photographs and illustrations rather than putting them into your site.

Paul: That’s a nice way of thinking about it, yeah. Because I do tend to start with the grid structure and the layout, and all that kind of thing, and then slot imagery in which I can see what you’re saying, you can miss a trick there if you’re not careful.

Mike: Yeah it’s funny I’m changing the way I work lately, and I was talking to Keir about this. I’m starting to think about stuff like you remember when Andy Clarke said he works from the inside out, and I’m starting to do that design wise.

Paul: Right, okay. You mean start with the detail or something?

Mike: Well start with something on the middle of the page. I just open a Photoshop document to start, and I know at one point in the page I’ll have like this… For example, I’m working on something at the moment, it’s got the planet Earth, and all I’ve got on the page is the Earth, I’ve got some bits coming off of it, and then I’m going to add this descriptive paragraph, and I haven’t got anything else on the page at this point, I’m just building it out.

Paul: Wow, that’s quite interesting.

Mike: Rather than thinking “ohhh”, and worrying about things like navigation afterwards, because it’s so easy to just go “no, nav-i-gat-ion”, and then I think no wait a minute what have I done, it’s literally just this autopilot.

Paul: Yeah, and to be honest that’s almost why, in the end, I moved on from design in my career, because I felt I was beginning to do exactly that, go on autopilot. So there is this need to find ways to refresh the way you’re working and stuff like that.

Mike: The funny thing is, it’s natural progression as well. It’s not a choice I’ve made, I just found myself doing this.

Paul: That’s good, that’s really good. You talk a lot about “I had a lot of freedom on this project; I could do what I wanted.” You said that several times in this interview. Do you like that, or do you like having constraints? Because a lot of people that are listening to this are going, “well it’s all well and good for him because he’s working on internal projects and he doesn’t have clients”, and that kind of thing, although you are doing client work now. So there we go, there’s a nice comparison between the client work you’re doing and the internal stuff. Where does your heart lie?

Mike: Yeah, I don’t know actually. Sometimes I hate having no restrictions. Sometimes, no restrictions is the worst thing in the whole world, I hate it. Sometimes it can be terrible, sometimes it’s great. Because if you’ve got no restrictions at all sometimes it’s so hard; that Microsoft thing, I was like “what the hell am I going to do, I haven’t got a clue”. For a start, I’ve never designed a stand before, let alone just an idea. I spent three days getting to that, just getting to the beginning of that idea. I literally produced nothing for three days. The fourth day I was like, “I think I’ve got something”, and that was hard because it had no restrictions because the whole point they came to us was because they wanted to do something different. So the pressure was on to think of something really different, and it’s hard when you can start anywhere. Sometimes it’s really nice to have restrictions, like that Orchestrate site was nice; I got back after Christmas, and John Hicks has put together roughly what had to look like.

Paul: Right. You had to carry on with his style.

Mike: Yeah sort of. I mean it did progress from that, but it had a logo and a colour scheme and a nice, tidy, neat… you know I just had to follow it through and it was nice, I enjoyed doing it. It was a nice break from “you can do anything”, which is actually harder I think.

Paul: Right, that’s interesting.

Mike: Much harder actually. I used to do music quite a lot, and in a way what was always helpful was restricting our instruments completely, and not having much to work with. Because it sort of sets you on a path at least, where as when you’re starting out and you can go any which way you want…

Paul: Yeah, it’s too open.

Marcus: It’s the starting part that’s the hard bit; it’s that initial creative spark. If somebody said “this is my idea, I want you to build me something,” then it’s like great I can do that. But, what’s better about when you’ve got, because I do a quite a lot of music as well (or did), it’s when you get something going and it’s good, that’s more satisfying than working on someone else’s work, but if it’s one of those days when it’s just not coming then, you know…

Paul: Which brings us on to what I wanted to wrap up with, which was you mentioned this slide about bucking trends and breaking trends and that kind of thing, and you advised against CSS galleries, you advised against Smashing Magazine’s trends for the last year, which people turn to for inspiration because they struggle to know where to begin. So if you’re advising against those things, which by the way I think is an excellent piece of advice, we asked Jim Coodle this as well, where does your inspiration come from? Where do you turn to if you don’t turn to that kind of thing?

Mike: I guess I do advise that, but I don’t like to sound like I’m telling people what to do *laughter*

Paul: Well if you stand on a stage…

Mike: I guess, yeah. But the funny thing is, I’ll be in a book shop… A year ago, for example, I was in a book shop and I picked up Jamie Oliver’s book, it was made of a nice sacky cover, don’t know if you’ve seen it, it’s got white and blue in it, it was beautiful. The graphic design and the layout was lovely, and I was like “oh I’ll buy that”, not for cooking, just because it looked nice, and I was like “I’m going to design a web site like that”. And someone on Twitter just said something about how they’d just discussed Mike Kus’s talk over lunch and how much of an idiot I am, and something about imagine your web site in print, which is what I said at the end.

Paul: Which I thought was brilliant, but he had problems with that did he?

Mike: Yeah, well he said it’s absolutely useless, different mediums, why would you do that.

Paul: It’s to take it out of context, and give yourself a chance to look at it from a completely different angle. It would be the same as projecting it huge on a wall or sketching it out in chalk, or whatever.

Mike: Well that’s it, exactly. It’s like what you said a minute ago about it’s so easy to go into autopilot with these things, and I think sometimes you need something to jolt your brain into looking at it a little bit differently. Because to me there are a lot of things on the web… Just imagine if you get a web site like your average one – it’s got the gradients all over it and everything, you put it on a magazine page; it would look weird. You have to ask yourself, why are you doing that. I know it’s a different medium, and I think we can all be clever enough to realise that, and there’s obviously bits I’m not going to say it’s got to be like a magazine, but I think it’s worth asking yourself those questions.

Paul: In the same way as in the talk, which I thought was really nice, was you had these amazing set of slides that had a very distinct look, and that was being projected massive on a wall, and yet you transposed that into a poster you gave away to people. So you were crossing those mediums and using inspiration from both which I thought was excellent; it was good. It went well didn’t it?

Mike: It was good, yeah I was pleased.

Paul: Excellent. Well thank you so much for your time Mike, that was really useful, and I think it will be very helpful for people. Especially freelancers that are stuck by themselves, and stuck in their own routine of working. It’s nice to hear how other people work, so thanks.

Mike: Cool. Cheers, thanks a lot.

Thanks goes to Gareth James for transcribing this interview.

Back to top

Listeners feedback:

APIs, source control and Ryan Carson

On show 164 Ryan Carson shared some more advice on running and building web applications as part of his ongoing series for Boagworld. Although Ryan’s advice is excellent, Boagworld listener Glen Bennett wanted to offer an alternative perspective over a couple of Ryan’s suggestions.

Hi Paul and Marcus, this is Glen Bennett from small business hosting. I was excited when you had Ryan Carson on the show talking about web application building, finally someone on the show who knew what they were talking about, however he cave out some information that was a bit misleading and I wanted to clear it up for your listeners, first of all he talked about spreedly.com and indicated that their fee is an alternative to the standard processing fees, in actuality it’s a fee that’s in addition to all the standard processing fees, there service sits in front of the processing gateway and therefore it’s an additional fee and there fee is not insignificant, in addition to that you would have to build an interface to their product. So there is some building cost at your end. I agree that building a processing engine is pretty substantial and something that you want to get help with if you possibly can there are packages out there anywhere from a few hundred dollars to a few thousand dollars that are actually pre-written source code that you put into you payment package, you have to do that pretty early in the process so that you can make sure that your user registration matches up with the processing system.

The second thing he talked about which is a source code repository, which is GIT hub, fantastic product and I recommend it highly, I think all developers should go and look at it, however the free service is primarily for a public repository so I don’t think he would have wanted to put DropSend source code into a public repository so their free service is not something that you’d probably want to use for your web application unless it’s an open source web application and there is a small fee for GIT hub but a lot of hosting packages come with SVN included for free so you might want to look into that, you can use GIT locally on your local system and then SVN them up to your free repository on the internet so you have a remote repository that’s free during development time. So there’s a couple of tips, a couple of corrections for web developers, I hope that helps and I want to thank Ryan Carson for the additional information that he had in his tips, I found it all very useful. Thank you very much.

Blog writing inspiration

Recently we received an email from Jon. He wrote:

I was wondering how do you find inspiration for your articles? How do you expand upon your initial idea and is there a process you go through when writing an article? How long do you spend writing an article? And lastly what do you think is the hallmark of a good article?

These are all good questions. The majority of blogs  have long since been abandoned by their authors. The owner either struggle to think of new content or finds running a blog more time consuming than anticipated.

I don’t claim to have all the answer when it comes to successful blogging. However I can share with you a few principles I work by…

  • Limit your time – I work best when I have a deadline. If I have too much time I over think things and pick at the details. This makes blogging  high maintenance and hard to keep up. Unless the content of a blog post is going to be used elsewhere (see Recycle below) I will never spend more than a couple of hours writing something. To me a blog is about sharing ideas, not writing a perfect piece of copy. I know I am not the best writer in the world and so make up for this by sharing ideas on a regular basis. In order to do that, I limit the time available for each post.
  • Keep an ideas list - Ideas for blog posts occur to me all the time and I have trained myself to constantly ask ‘would what I am doing make a good blog post?’ However, you can guarantee my mind will go blank the moment I sit down to write one. That is why it is important for me to keep a list of ideas. Whether you add them to a notebook or keep a list in WordPress, you need to make it as quick and easy to add ideas as possible. Also, when I add an idea, I try to flesh it out a little. Instead of just adding a title I also include a rough synopsis of what I want to cover.
  • Create an outline – Before I begin writing, I always create an outline of what I want to cover. I usually do this using Omni Outliner where I jot down random thoughts on the subject. I then sort those ideas into a logical structure. Once the structure is in place, writing the final post is much easier. This is because I know where I am going. It also ensures I lead the reader through a story, rather than throwing random thoughts at them.
  • Write first, edit later – Its easy to get caught up in spelling, grammar and structure to the detriment of flow. I tend to write posts in one go. I don’t re-read what I have written until the whole thing is finished. Stopping to check what I have written breaks my focus and leads to disjointed articles that take longer to write. Better to write the whole thing and then re-read the post afterward editing it then.
  • Write for your audience – Before I begin a blog post I always ask myself whether this will be of interest to my audience. Sometimes I indulge myself with personal posts, but most of the time I work hard to stay on topic and only write content that is focused on meeting my readers needs. This applies not just to the subjects chosen. It also to the style of writing and terminology used. For example, I try to avoid too much technical jargon because it may not be accessible to website owners. However, I don’t always succeed!
  • Write for scanability – There is a vocal minority in the blogging community who frown upon image heavy, list based, blog posts. However, I think there is a lot to be learnt from them. People who subscribe to my blog read a lot of other blogs too. With so much information to keep abreast of they rarely have time to read everything I write. I therefore write in a way that lets them get the ‘gist’ of a post without reading every word. Lists are one way to do this, as is the use of imagery. However, I also use headings and front loading too. Wherever possible make content easy to skim read. If you do not, users are likely to skip it entirely.
  • Ask for suggestions - I have found the best way to come up with ideas for my blog is to ask my readers. I actively encourage people to email me with questions, reviews or comments and these inspire ideas for posts. In fact the very question I am answering here would make a great blog post. Hmmm… perhaps I should stop before I waste the opportunity :-)
  • Ask your readers opinion – As well as asking for suggestions also ask for feedback. A good blog post does not have to be you sharing your words of wisdom with the world. It can also be asking a question and encouraging feedback. Some of the best content on blogs  can be found in the comments, rather than the actual posts. Try to write posts that encourage a dialogue rather than a monologue. Also if you do manage to spark a passionate discussion, followup with a second post that summarizes the views expressed.
  • Recycle – Finally, I am a great believer in recycling ideas. For example the answer to this question will appear on my blog, on the podcast and also will make a great Audioboo tip. Many of my best blog posts have either come out of a presentation I gave or a chapter from my book.

This is not a definitive set of guidelines and every blogger will work differently. However, this approach has helped me to continue blogging for over 4 years. I will leave it to you to judge whether the quality has remained high ;-)

Finally, if you are a regular blogger I would love to hear your thoughts on keeping your blog fresh. How do you come up with ideas and ensure the quality of your posts? Let us know by adding a comment below.

Back to top

10 ways to put your content in front of more people

What is more important – driving traffic to your site or encouraging as many people as possible to see your content? Believe it or not, they are not one in the same thing.

Too often as website owners we live and die by Google Analytics. We fret about bounce rates, unique visitors and dwell time. However, when we focus so heavily on the performance of our website we miss a fundamental point – the aim is to expose users to our content not our site. The website is tool a that can be used to showcase our content, but it does not have to be the only one.

Truly successful websites understand this principle. Take for example the following…

  • Amazon – Their primary objective is to sell stuff.
  • YouTube – Their aim is to use video content to carry advertisements
  • Twitter – They are about facilitating twittering (who knows what their business model is!)

In each case it is the content that matters not the site. That is why each company provides numerous ways of accessing their content beyond their websites. From Amazon’s affiliate scheme to YouTube’s embed feature, it is possible for these companies to reach audiences who may never go to their websites.

Twitter is probably the best example of all. What percentage of the time do you read tweets (or post them) via the twitter website? If you are like me, then the answer is very rarely.

Twitter website

The lesson here is obvious – as website owners we need to start thinking in terms of a broader web strategy and releasing our content from the shackles of our websites. How then do we do this? I would like to propose 10 possible opportunities that you may wish to consider integrating into your online approach.

1. Targeting the desktop

eBay recognised they had a need for a desktop application. Many people make their living from selling on eBay and these people needed desktop software that streamlined their business processes. They needed desktop notifications, faster more desktop like interaction and easier access to eBay features.

eBay Desktop

Using platforms like Adobe AIR it is easy to take web based content and functionality to the desktop. This is exactly what they did and it has proved very successful among their power users.

As a website owner you should be asking whether a desktop application is right for you. Do your users need desktop features, offline access or better integration with the operating system.

2. Going mobile

uStream iPhone Application

It won’t be long before more users access the web via a mobile device than do using a PC. In many countries this is already the case.

Traditional website often render poorly on mobile devices or are hard to use. They also do not take into account the context of being a mobile user. It is therefore necessary to approach the mobile web as a different channel to your traditional website.

Methods of delivering content to the mobile web include…

  • Producing mobile websites – Mobile sites take into account small screens, different input devices and the numerous other unique characteristics of the mobile web.
  • Using text messaging – Text messaging is ideal for notifications and updates. A perfect compliment to your website and a way of keeping users informed.
  • Building mobile applications - Mobile platforms like the iPhone and Android make it increasingly easy to build applications that run directly on the mobile device. This provides opportunities to make your content available even when the user is not connected or away from their PC.

Pushing your content to mobile devices is ideal if your target audience is often away from their computers or require access to your content while ‘in the field’.

3. Start twittering

Twitter is surrounded by so much hype at the moment. However, it does provide a unique opportunity to reach a larger audience with your message. The question is, how best to use it?

Some organisations use twitter as a broadcast tool. This is fundamentally an alternative to RSS. An example of this is BBC news who provide latest updates via the service.

However to use Twitter as a broadcast tool, fails to grasp its real power. Organisations who really ‘get’ twitter include Zappos and Omnifocus. They use Twitter as a way to engage with their followers and even provide customer support.

Use Twitter as a way to engage with your audience. If you have a number of people working on your site, encourage them all of them to twitter, rather than having a single ‘branded’ account.

4. Writing for others

Writing for other sites provides an excellent opportunity to demonstrate your expertise and spread your message to a larger audience than would otherwise be possible on your own website.

Do not limit your words of wisdom to your own website. Look for other editorial sites and blogs who are speaking to your audience and offer to write for them. After all your audience visits many sites other than your own. Why limit your writing skills to your own blog when you can reach new audiences by writing for others?

Of course, any article you write for others has to be more than shameless self promotion. The owners of those sites are going to want quality content that fits their site and is of interest to their audience. For example I recently wrote an article for a site whose audience was franchise owners. If I had simply written about how great Headscape was then I doubt it would have been published. Instead I shared a case study of our experience working with a franchise based business. The content was both relevant to the publication and useful to their audience. However, at the same time it raised our profile among a potential new customer base.

An example of the bio which appears when I write for others

What sites exist that reach your target market? Would they consider publishing some of your content? How could you rewrite your content to make it more appealing to them?

5. Embracing Facebook

Another option that allows you to expand your web strategy beyond the website is Facebook.

I am sure it is unnecessary for me to explain the importance and reach of Facebook. However, you maybe tempted to dismiss it because your target market is not the teenage audience normally associated with these kinds of social networking sites.

What may surprise you is that Facebook is no longer confined to the younger demographic. Over the last year the number of users between 35-54 has jumped by 276% to over 6 million.

So how do you reach your audience on Facebook? There are three good starting points…

  • Create a group – Groups have been around a long time and are ideal for building a dialogue with those already interested in your product or service. You can easily invite people to participate and those people in turn can invite others. This makes groups ideally suited for viral marketing
  • Create a fan page – Fan pages are basically public profiles for organisations rather than individuals. Unlike groups, pages are public facing. This means non-facebook users can see them and they are indexed by search engines. Fan pages are perfect for building long-term awareness and for reaching people both inside and outside of Facebook.
  • Create an application – Facebook allows third parties to build ‘applications’ that can be add to user profiles. These can range from games to RSS feeds. Unlike pages or groups, some technical skill is required to build an application. However, the possibility of users embedding your content into their profiles makes this an attractive proposition if you have appropriate content.

Carsonified Fan Page on Facebook

Of course Facebook is not the only site of this nature. However, it does have considerable reach and provides some the best tools for reaching their massive audience.

6. Developing widgets and APIs

The ultimate way of distributing content has to be by providing an API or widget.

An API gives other web developers access to your content allowing them to build applications and websites around it. Using an API, a developer could do anything from embed your content into their site, to build a desktop application that offers your functionality.

Twitter really gets APIs. When was the last time you viewed or posted tweets from their website? The chances are it was a long time ago. Because Twitter offers a powerful API, thousands of developers have built all kinds of applications allowing you to view and post tweets. Infact, what Twitter offers is very basic. However, because of their API it is possible to do everything from view Tweets on a google map to post photos, video and audio.

Screenshot of Tweetdeck

Unfortunately, APIs do have some drawbacks. They require a considerable level of technical expertise to implement. As a result they are only of use to developers. What about the rest of us? How do we add third party content to our sites? That is where widgets come in.

Widgets are typically a small piece of code that you can copy and paste into your website. There are literally thousands of widgets available. They allow website owners to utilise the content and functionality from other sites quickly and easily. Widgets are used to embed YouTube videos, show your Amazon wishlist or display your location on a map.

Widgets are powerful because they are easy to implement. This means anybody can add them, so distributing your content as far as possible.

Widgets are also easier to build than a full API. This makes them a good starting point for those wishing to put their content in front of more people.

7. Offering better feeds

Not all approaches to putting content in front of users has to be as time consuming or complex to develop as an API. There is one thing you could do to increase views within a few minutes.

Increasingly users are relying on RSS feeds as a way to consume content from websites. This is especially true for news, articles or blog posts. However, some website owners are so obsessed with driving traffic to their sites that they only provide a teaser of the post via RSS. To read the whole article, the user is forced to ‘click through’ to the website.

This approach to RSS is counter productive. When a user is browsing a large number of feeds, they are less likely to read your content if they have to leave their news reader to do so.

To maximise a users exposure to your content, ensure as much of it as possible is displayed within the RSS feed itself. Only require a user to click through when absolutely necessary.

Google Reader displaying a partial RSS feed

It is also important to note that when users are reading content from an RSS feed, they do not have the context of your website. It is therefore necessary to ensure content stands alone and that calls to action are incorporated in the copy of your posts.

8. Using multimedia

Of course, it is becoming increasingly unnecessary to limit your content to the written word. Creating audio or video content has become trivial with services like YouTube and applications like Audioboo making production and hosting easy.

Also, pioneers like Diggnation and Wine Library TV have shown that users care more about quality content than high production values. Both shows are essentially presenters talking to a single locked off camera. This kind of production value can be achieved with a consumer camera and basic editing software.

That said, creating popular content is harder than it first appears. Many organisations believe that simply uploading their latest product demonstration to YouTube will generate millions of views. This is simply not the case.

Good rich media content has to be engaging if you want people to watch, or more importantly recommend it to a friend. This can be done through a passionate presenter, great content, humour or shock value. With thousands of videos uploaded everyday it is important that your video stands out from the crowd.

Wine Library TV website

However, do not forget your content has to be appropriate to your target audience. Shock tactics may work well for a teenage audience, but it might not go down so well with a middle aged business executive!

9. Start streaming

The next wave of multimedia on the web is not going to be pre-recorded material. It is going to be live streaming.

Services such as ustream, qik, and Justin TV are all fighting to dominate this space. Each offers the opportunity to stream live content to the web at zero cost. This makes the barrier to entry extremely low.

The main benefit of this approach over pre-recorded material is interactivity. The live format allows viewers to engage with the presenter in real time via chat. This offers a host of opportunities including (but not limited to)…

  • Live product demonstrations – Live streaming allows you present your products and services while talking questions from the audience. This is considerably more powerful that pre-recorded promotional videos.
  • Community sessions – If you run an online community, live streaming gives you the chance to engage with that community on a much more personal level than the written word. Social news site digg.com have run a number of ‘Town Hall’ meetings where their user base engage directly with the CEO and founder.
  • Online training – Finally, live streaming is a perfect environment to provide remote training. Whether you are providing training on using your product or selling online workshops, live streaming provides the opportunity for users to both hear and see what you are doing.

Digg Town Hall

Live streaming is still relatively immature and few are taking advantage of this new opportunity. There is a real chance to differentiate yourself through its use.

10. Don’t forget email

Amongst all this talk of video, audio and APIs it is easy to forget the tools we have always had for reaching beyond the confines of our website.

Although not the ‘sexiest’ tool in our list, I could not end this post without mentioning email. Email should be a key component in keeping your content in front of users.

Obviously, email can be used for a lot more than syndicating content. However, for the purposes of this article you should use email as a way for users to subscribe to your content. If a user can subscribe to your content via RSS, they should also be able to do so via email.

Fortunately services like Feedburner makes this easy. If your RSS feed is managed by them, users can also subscribe via email when you adding a single link to your site.

I do however want to share a word of warning – If a user subscribes to your content via email, they are not giving you permission to spam them indiscriminately. If you fail to respect their email subscription, you are in danger of loosing that user and potentially having them post negative comment that could put off others.

Conclusion

There was a time when build a website was enough. However, increasingly your website should be just one small part of your website strategy. It is naive to expect users to come to you. Instead, you need to take your content to them, whether that is on a social network like Facebook or a mobile device like the iPhone.

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.

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

5 options when website budgets get slashed

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

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

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

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

1. Realign rather than redesign

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

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

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

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

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

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

My facebook profile

2. Simplify

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

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

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

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

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

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

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

Apple Homepage

3. Prioritise and phase development

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

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

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

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

Digg Technology Homepage

4. Reuse and recycle

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

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

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

opensourceCMS screenshot

5. Move beyond the website

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

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

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

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

Conclusions

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

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

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

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

Improving your site with user feedback

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

Whether you are a website owner or a web designer, listen to your users. Whether you are running a web application like GetSignOff or developing content driven websites, listen to your users.

We all know that user feedback can be invaluable for improving our sites. However, knowing something and putting it into practice are different things.

There are two problems with listening to users:

  • How to listen to them in the first place
  • How to decide what is valuable feedback and what is not

We will never pay more than lip service to the idea of users shaping our sites unless we overcome these obstacles.

Collecting user feedback

Everybody thinks they know their audience. However, in reality they probably do not. When was the last time you actually asked a user his opinion? You may think you know what they want but you can’t be sure unless you ask.

Fortunately there are a number of ways to collect feedback from users:

Face to face

From focus groups to usability sessions, meeting users in the flesh provides unparalleled feedback. Meeting users allow a level of interaction unavailable through other methods because they allow two way real-time interaction.

This creates a better empathy and connection with users. You can get inside their heads by watching their mannerisms, listening to their tone of voice and even observing the way they dress. All of these subtle elements help construct a picture of the type of person they are.

Admittedly face to face meetings can be difficult to arrange. However I would encourage you to settle for nothing less. You may not do it extensively, but make sure you do it at least once.

Web stats and search queries

In my post ‘use web stats for more‘ I explored what could be learnt from analysing web logs and search queries. I explained that web stats could be used to find and resolve problems with usability, accessibility and content. I also looked at how monitoring search queries reveal what users really want from your site and the mental model they use to find your content.

In short, web stats are an invaluable source for identifying trends in behaviour and expectations.

Questionnaires and surveys

Probably the most traditional and most favoured form of collecting user feedback is the ‘survey/questionairre’. One reason they are favoured is because they identify broad trends in much the same way as web stats.

Personally I am not a fan of this approach, especially when used in isolation. Tracking broad trends through statistical analysis does not encourage empathy with users. As is pointed out in the book Subject to change, empathy is an important aspect of successful web development. Without empathy you will not truly understand your users.

Also, in my experience there is a difference between what users say and what they actually want. Users often request features and functionality when in reality they value a simple user experience. Without a two way discussion with users it is hard to identify the underlying needs.

Finally, unless users feel strongly about a site they are unlikely to complete a survey. This polarises results suggesting extreme opinion where it does not exist.

I am not suggesting surveys are useless. The problem is how they are acted upon. Many treat survey results as absolute. In fact it is necessary to ignore some results and read between the lines of others.

Third party web applications

The final way of collecting user feedback is through a new generation of community tools. Sites like Get Satisfaction and User Voice allow two way interaction with users. Users can submit suggestions, questions and complaints online and you can respond in kind. This happens in an open forum allowing anybody to participate in the discussion.

This open format (when compared to the predefined questions of a survey) encourages a more personal discussion and provides opportunity for a deeper level of discussion.

As with surveys the people responding are likely to be more polarised in opinion. However, because of the interactive nature of these services it is possible to dig a little deeper and understand the underlying issues.

Personally, I have found these services an invaluable way of building a closer relationship with users and better understanding what they are looking for.

Of course, whatever method you use to collect feedback it must be assessed. You need to determine what must be acted upon and what can be safely ignored.

Assessing user feedback

Once you have engaged your users, you will be amazed at the quality and quantity of suggestions. The problem becomes deciding what to implement.

I have had this problem for some time with both Boagworld and more recently GetSignOff. I have established 4 criteria I use to judge whether I act on a suggestion or not. These are:

  • Level of feedback – How many people are making the suggestion? If it is a substantial number then you should seriously consider implementing the idea. However if it is just a vocal minority then you may wish to think twice.
  • Source of feedback – Who is making the suggestion? Are those people your core audience? It is easy to find yourself implementing functionality for a group of users who provide no value to your business or site.
  • Cost of implementation – Consider return on investment when deciding on whether to implement a suggestion or not. If it is time consuming to build and expensive to implement, then the benefit to your users and your business must be high.
  • Impact – Finally, consider the broader impact of adding new functionality or content. Will it introduce complexity into your site? Will it break another part of the site? Will it distract users from your call to action or undermine business objectives? Often implementing a suggestion can have surprising consequences.

There is no doubt that listening to users can be an invaluable way of improving your site. However, ask yourself how you intend to gather their feedback and respond to the results.

Don't panic!

According to Jason Calcanis and Michael Arrington the tech sector is in economic free fall. But, is the doom and gloom justified?

I am no financial expert. I have no idea how the economy works or how the actions of the stock market impact the rest of us. What I do have is my experience of the the dot com bust in 2001 and that tells me there is a lot of unnecessary panic flying around.

That said, I can understand why the likes of Jason Calcanis and Michael Arrington are twitchy.

I have said it before and I will say it again, any startup whose business plan is built solely on advertising revenue or venture capital has no business plan at all. When an economy gets into difficulties those are the first two areas of revenue to dry up. Companies do not advertise when they start tightening their belts. They certainly do not invest.

It is therefore unsurprising that there is a growing sense of unease in Silicon Valley. As with the last dot com boom there are a lot of companies with naive business plans. I am concerned for my friends who work in companies like that. I think they have worrying times ahead.

However, for the vast majority of web designers things are nowhere near as concerning. We are not supported by advertising or venture capital, but by delivering a service. Depending on our clients we probably have little to worry about.

There are of course exceptions. If your clients fall into the following categories, then I would look to alter that client base slightly:

  • Web 2.0. companies – If they are being squeezed then they will stop investing in their site,
  • Advertising agencies – As the wider economy tighten its belt they will stop spending with advertising agencies and this will trickle down.
  • Very small businesses – These people still see websites as a marketing spend rather than an intrinsic part of their business. If times get tough they will cut this expenditure.

However, if you clients do not fall into these categories, you probably have no need to panic. Things will slow down and you will see a trickle down affect, but if you can weather the storm there will be good times ahead. Recessions tend to clear the forest of dead wood and leave opportunities for growth later on.

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

    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?

    In a recent report that I wrote for one of our clients at Headscape I explained how most websites pass through a common product life cycle. This life cycle includes the following stages…

    • Exploration – Most organisations begin with a series of exploratory sites, where they discover the potential of the web. This often involves low investment and slow growth.
    • Growth – At some point during the exploration phases the ‘penny drops’ and the organisation realises how the web can benefit their business. More substantial investment is made, the site is dramatically improved, and rapid growth follows.
    • Stagnation – Following the initial rapid growth there is a period of stagnation. This is because the ‘quick win’ fixes have been made to the site. Obvious problems have been resolved and so the benefits of fixing these changes have passed.
    • Maturity – Once the challenges of overcoming stagnation have been met, a site enters a period of gradual but steady growth. This is characterised by continual incremental changes to the site, which consistently stimulate growth.

    It is easy to generate rapid growth on an early version of a website. There are so many obvious problems to fix. You can have a big impact with relatively little effort. However, what happens once that stage is over? How do you avoid sinking into stagnation?

    Overcoming stagnation

    Stagnation is not an entirely negative period. Although it consists of slower growth, it does not mean a decline. However it does generate fear…

    • A fear that growth will turn into decline
    • A fear of the competition catching up
    • A fear of losing customer loyalty

    This fear can lead to knee jerk reactions that are detrimental. This mentality manifests itself in two particular reactions. First, it leads to panic decision making. Something has to be done and it must be done now. Second, it leads to the creation of additional features. These two reactions often go hand in hand. As growth slows, organisations seek ways to maintain momentum. One source they turn to is user feedback. However, instead of considering the impact of suggestions on the overall usability, they instead grasp hold of it ‘as something we can do’ and implement immediately. This leads to feature creep and complexity. Before long all vision for the site is lost and the organisation has become reactive.

    This can be overcome in three ways…

    • Going back to basics – Step back occasionally and ask two questions. Why does your site exist and who is it aimed at? So much time can be spent troubleshooting, adding features and responding to requests, that focus is lost. It is easy to spend time placating the requests of the vocal minority, while damaging usability for the majority.
    • Pause and evaluate – Every website receives criticism. However, it is important to pause before responding to that criticism. Who is criticising? Are they an important segment of your audience, how many of the same comments are you receiving? How serious is the criticism? Is it a mild inconvenience or a serious issue? What are the ramifications of fixing the problem? Who else will it effect and in what way? The danger is that by rushing in to a fix a problem you create more.
    • Simplify – There is a belief that growth is maintained by giving the user more. However, often the opposite is true. Look to solve problems and increase growth by simplifying your site not by adding new features.

    It is the area of simplicity where I believe there is most to learn.

    The importance of simplicity

    There are two reasons why simplicity is important…

    • Simplicity sales
    • Users have limited attention

    What do I mean when I say simplicity sales?

    Simplicity sells

    One of the most successful products of our time is the iPod, and yet it is inferior to its competition in almost all ways. It is more expensive, has inferior technology and offers less features. The reason it has come to dominate the market is because it is simple and easy to use. This simplicity has become the trademark of Apple products and with it has come new-found growth for the company.

    There are examples online too. In the early years of the web Yahoo! dominated search listings. However, as the web grew their site struggled to adapt. It became complex and hard to use. It is therefore not surprising that the minimalist interface of Google came as a breath of fresh air and quickly supplanted Yahoo’s dominance.

    Google went on to apply this same simplistic approach to online advertising. They swept aside traditional banner advertising, replacing it with simpler text adverts accompanied by a ease to use administration system that allowed anybody to run an ad campaigns. The majority of users will select simplicity over functionality.

    Limited attention

    We forget that people have a limited capacity to process information. In fact we are only able to process 6-7 pieces of information simultaneously. That is why we find it so hard to learn to drive. It is not until we can process information on a sub conscious level that we feel relaxed driving.

    As we translate this principle to the web it becomes apparent why web pages can be so overwhelming. There is simply too much going on. One technique to reduce complexity is assigning user attention points to pages. For example, lets say you have 15 points of user attention to spend. Each item you add to the page costs 1 point of attention. If you want something to stand out it needs more points. This demonstrates that you need to reduce the number of screen elements or risk a lack of focus because points are too thinly spread. This problem is perfectly demonstrated by the difference between the Yahoo! and Google home pages…

    Google and Yahoo Homepages

    When compared to Google it is obvious that Yahoo! is demanding too much from its users and spreading their attention too thinly. By having so much content and not emphasising any particular element, the whole page lacks definition. It needs to prioritise and simplify its content.

    To move a website from stagnation to maturity we need to simplify. This involves making some difficult choices.

    Simplifying is hard for two reasons…

    • It is hard to remove functionality you have invested in.
    • It is hard to remove functionality people use.

    Nevertheless it is necessary.

    When it comes to the mental barrier of removing functionality you need to recognise that it is costing you money. Every time the complexity of that functionality undermines the user experience it is potentially driving users away and reducing profit.

    Just because some people use a piece of functionality does not mean you should keep it. Every piece of functionality on your website is probably used. The question is, how much are they used and how badly does it overcomplicate the user experience for everybody else?

    The above post is an extract from a report written for WFF by Headscape

    135. Libraries

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

    Play

    Download this show.

    Launch our podcast player

    News and events

    The complexity tax

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

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

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

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

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

    10 Rules for Driving Traffic Using Forums

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

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

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

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

    Accessibility in suit and tie

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

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

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

    UK Government Browser Guidelines

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

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

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

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

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

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

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

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

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

    Back to top

    Interview: John Resig on javaScript Libraries

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

    John:Well, thanks for having me.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    John:Thanks for having me, Thank you.

    Thanks to Todd Dietrich for transcribing this interview.

    Back to top

    Listeners feedback:

    Quality or Quickly?

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

    I received this question from Pete in South Africa…

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

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

    To read the rest of this blog click here.

    Back to top