Boagworld web design podcast

138. Freeform

Wed, 08 Oct 2008 12:20:00 +0000

In this week's show the entire boagworld production team answer listener questions.

Download this show.

Launch our podcast player

Watch the behind the scenes video

We were really excited to have all of the boagworld production team in one place. This included...

Anna Debenham (the show's technician)
Ryan Taylor (our producer)
Paul Stanton (the master of our news feed)

They came to visit myself and Marcus at the Headscape office, so we thought we should record a show at the same time.

Obviously, the normal format was not going to work with 5 people, so we decided to do something different. This week's show is a panel based question and answer session. All the questions were submitted by listeners and thanks so much to those of you who took the time to send them in. Sorry we didn't manage to do them all.

The show was recorded live and so is a little rough around the edges. I apologise if the audio is not up to our normal standard.

Also, because of the somewhat chaotic nature of this week's show there are no show notes. Apologies to those of you who follow the show in written format. Normal service will resume next week.

Head Conference

For those of you waiting for the boagworld discount to the Head conference, your wait is over (almost!). On Friday 10th October for one day only the price is going to be slashed by 20%. You don't need a discount code. Just visit the site on that day and buy a ticket.

137. Adobe

Wed, 01 Oct 2008 15:00:00 +0000

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

Download this show.

Launch our podcast player

News and events

Adobe CS4 is released

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

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

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

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

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

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

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

For more on the new features in Adobe CS4 listen to our interview with Aral later in the show. Also check out Adobe TV for video demonstrations of all the new features across the entire range.

Fire Vox

Next up is a Firefox extension that allows you to transform Firefox into a screen reader.

We all know accessibility is important. We all know we should develop with screen readers in mind. However, many of us fail to test in screen readers because they are expensive and time consuming.

Well, now you have no excuse. Fire Vox is an open source, freely available talking browser extension for the Firefox web browser. Think of it as a screen reader that is designed especially for Firefox.

In addition to the basic features that are expected of screen readers, such as being able to identify headings, links, images, etc. and providing navigational assistance, Fire Vox provides support for CSS speech module properties. It also works on Windows, Macintosh, and Linux.

Installation is slightly more fiddly than your average extension but if you follow the instructions it is easy enough to get up and running.

Once installed, it is probably one of the easiest screen readers I have used. They also provide some excellent tutorials on their site to get you up and running.

I highly recommend it.

Irresponsible content publication

According to Gerry McGovern, on the 8th September, a story about the bankruptcy of United Airlines parent company began circulating on the Web. Within hours of the story's being released, their shares had dropped by 76 percent.

What has this got to do with web design I hear you ask? The answer; the story was 6 years old. Somehow it had been picked up by Google News and quickly caused panic among share holders.

Gerry uses this as an example of the dangers associated with out of date content. He goes on to talk about how our 'content management system mentality' has led to an online environment without editorial control.

The production of content for our sites has become so distributed and unregulated that nobody is responsible for reviewing or removing content. We put content online without considering if it is needed or whether it has an expiry date.

The content of our websites has been largely neglected and I believe the time has come for website owners to put the same investment into content as they do into the build of a site.

For those of you who are web designers, I would encourage you to start talking to your clients about how they plan to manage the content on their sites. Who will be responsible for the relevancy of what they place online?

Code CSS the clear:left way

It is always interesting to see how others build websites particularly when it is a high profile company you respect. One such company is Clearleft who are known for the quality of their CSS and Javascript.

One of the developers at Clearleft is Natalie Downe. She recently spoke at Barcamp London about the methodology Clearleft use when coding in CSS.

Although I didn't get to hear her speak she has put her slides and notes (PDF 64.2mb) online. Fortunately, her notes are extremely comprehensive and it gives a real insight into her approach.

Obviously, there is not a single approach to building websites. However, Natalie shares some interesting ideas about ensuring your CSS remains maintainable and can be easily handed to other developers.

Interestingly we follow a similar approach at Headscape although we do differ in a few key ways. Nevertheless it is fascinating to see how others do it and there is a lot to learn from what Natalie shares.

Interview: Aral Balkan on the new Adobe Products

Paul: Ok, so joining me today is Aral Balkan, good to have you on the show.

Aral: Oh, thank you Paul, it’s always great to be here.

Paul: It’s been a little while, but it’s good to have you back, and we’ve got Aral on the show today, really to talk about a couple of random things really...

Aral: The story of my life!

Paul: ...yeah, the story of your life, yeah, um, one of which is the new Adobe suite of products that are coming out, but before we get onto that, let’s talk about <head>, previously Singularity, what's all that about for a start, what happened there?

Aral: Uh, with the name change?

Paul: Yeah.

Aral: It was quite unfortunate, about 2 weeks ago or so, I got a letter from a company called Singularity Ltd, and they'd apparently trademarked "Singularity" the word, and you know how trademark law works, it's got different categories apparently, and these categories are really wide, so a single category could include things like training and conferences, so this company was not actually doing a conference called Singularity, but they trademarked it under the same class, and so they weren't too happy that we were using the name, and we had a talk as well, I called them up because I was like, oh crap, might as well just talk it out, and it just seemed like they wanted to have a legal conversation through the lawyers and stuff, you know, I'm not really into that, we only had 2 months to go and, you know, we're a first year conference so I didn't have the budget or the time really to get into that sort of a conversation and so I was like, yeah, you know what, this is going to hurt but let's re brand, so I took a weekend out, redesigned the site, redesigned everything, and then we decided to go with the new name. I actually really like the new name...

Paul: Yeah, it's a good name.

Aral: ...it's kind of edgy, it's short, it's memorable, and you know, given everything else, I probably wouldn't have changed the name 2 months ago if I'd had a choice, but still, I like it.

Paul: These things happen don't they.

Aral: These things do happen apparently, yeah.

Paul: So tell us a little bit about <head>, what is it? You know, it's obviously a conference but tell us a bit more about it.

Aral: Well, it's this conference and we have this amazing guy; Paul Boag speaking at it.

Paul: Well, obviously, yeah!

Aral: And that's really all I need to say! How do you like that one?

Paul: That's perfect. Keep going, you're doing well.

Aral: It's a virtual conference, so all of the sessions are streamed live over the Internet, and they're interactive so you can ask questions as you're viewing them, and the speaker can answer those questions. We're using Adobe Connect Pro in order to do that, so it's a tried and true system that's been around for quite a few years actually, surprisingly. Also we have a couple hubs in London, in Manchester, we're going to have one here in Brighton, one in Belgium, and there are a few more that still haven't been finalised, but we may have 1 or 2 more hubs, and the one in London for example is taking place at the Magic Circle which I'm very excited about, it's a lovely venue. Have you been there?

Paul: I've heard of it, but I haven't actually been there, I've heard of other people talk about it.

Aral: It's awesome, I was there last week, and it's basically like the magician's society in the UK, so it's been around for about 100 years, and it's got a museum where you can see actual items from Houdini and other people. Did you know that Prince Charles apparently is a member of the Magic Circle?

Paul: Oh, that doesn't surprise me.

Aral: And he apparently had to do a little trick to get in with these cups and this ball, and he got accepted into the highest order of the magic circle, just kind of crazy!

Paul: There you go! So when is this conference?

Aral: The conference takes place October 24th to the 26th, and it's everywhere, so you sign up to attend, and you can watch it from home, or if you're in one of the cities where we have a hub, you can go from there.

Paul: I mean, why virtual? Why did you decide to have a virtual conference rather than the traditional get-together kind of thing?

Aral: Personal reasons Paul! No, um, actually seriously I do a lot of talks at conferences, so I fly around a lot, and the flying around bit and staying in strange hotels, sometimes it's a great experience but depending on the hotel that you're in, that's not the bit that I really enjoy. You know, you go to a hotel, you don't have wi-fi, the wi-fi costs 3 billion dollars or something, and I got to thinking whether that was actually part of the conference experience, the positive part of it for me, and I thought maybe not, and we do stuff on the web, that's what we do, that's the line of business that we're in. So I thought why not try and see if we can create a conference that's virtual, but yet try to keep some of the aspects of conferences that we like the most, like the social interactions, and that's where the idea of the hubs came from, and that's why it's interactive and people can ask questions and communicate during the conference. And it's an experiment, you know, it's a first time conference so we're trying it out, we're going to see what works, see what doesn't, and then we're going to evolve it next year.

Paul: I mean what I find incredible about it is, I guess because people don't need to travel, you've got an absolutely incredible line-up of speakers.

Aral: We do have some great speakers!

Paul: And you've got so many of them as well, there's, what is there? Over 70 odd speakers?

Aral: Yeah, yeah, we've got 70 plus speakers, we've got amazing people; Tim O'Reilly for example is speaking, he's doing a keynote in the London hub in person, we've got Jason Fried, and we've got yourself of course...

Paul: I don't think you could put me in the same category as those 2, but keep going. I like the sound of it, that's good.

Aral: Course we can! Dude, I've seen you in so many conferences, you rock! Um, and we've got Molly, Jeremy Keith, we've got so many people, I mean Rafi Haladjian, he's the father of the Nabaztag bunny... I have one here! Yeah you saw it, when I came over with you guys.

Paul: Yes, I know how obsessional you are.

Aral: So, I mean, we've got amazing people. Gary Vaynerchuk, Wine Library TV, he's awesome, I'm going to see if we can try and get a live video hook-up during the London hub with him, he's just awesome, and just a whole bunch of people, I'm forgetting half of them, Richard Moross from moo.com, another one of my favourite companies.

Paul: It's just a stella list, absolutely unbelievable. Do you think people are going to miss out from the fact that they're not going to have that face-to-face experience?

Aral: I sure hope not, you know, we're trying to build things that compensate for that, and next year especially I'm going to concentrate much more on the hubs. You know, I'm thinking of scaling it down next year because we've kind of gone for everything this year, which is exhilarating, but at the same time for a first year conference it's a lot to do. Next year I'm thinking of maybe scaling it down a little bit, concentrating on 1 or 2 hubs, and try to build new interactions for connecting those hubs. I've got some really cool plans for it.

Paul: I mean, one of the kind of interesting things about this as well is the kind of underlying technology of all of this. I mean, how is it working, how are you going to connect all of these people? I mean, you're talking about thousands of people, 70 speakers, you know, here I am sitting in the middle of Dorset in the back and beyond, you know, and how are all these people going to see my presentation?

Aral: Well, we're using Adobe Connect Pro, so that does have a limit currently of 2,000 people in a room, so that's where we're limiting our attendance, we're definitely not having more than 2,000, and I don't think that's going to be a problem. But Connect has a lot of features for basically connecting people. You can see the streamed audio and video of a presentation, but you can also interact both by typing, or you can send your own video feed. We're probably not going to use that because of bandwidth concerns, but people can interact with other people who are in the session, they can chat with them and with the speaker, and so at the end of every session we're going to have a question and answer, and the speaker will go through all of the written questions that they've received during the talk and answer them, and that format has really worked in the past as well for meetings that we've done.

Paul: So, this is not a technology I've come across before, this is something that's kind of publicly available from Adobe is it?

Aral: Oh yeah, totally, Adobe Connect Pro has been available for several years. I think the full name, and it's got one of those really long names, is Adobe Acrobat Connect Pro.

Paul: Right.

Aral: I know, I don't know where they come up with them. But it's a really cool piece of software for doing meetings and these sorts of virtual presentations. It used to be called Breeze.

Paul: Ahhh, that's the name I recognize.

Aral: Yeah, there you go. It's been around for years and years, so it's really really stable, and Adobe actually has a new version of it, I don't know what they're calling it, I remember it's beta name I think, but they have a free version for up to 3 or 4 people, so if you Google for that, or like in the transcript or something you guys can find it and link it, that's really cool because you can just start playing with that. It used to be called Brio. I don't know what they're calling it now it's been released.

Paul: The other thing that I noticed from Twitter was that you mentioned that you built the website using Google's App Engine.

Aral: Yes.

Paul: Tell us bit about that.

Aral: Wow, it's been a fun ride!

Paul: You sounded somewhat stressed at certain points through the period.

Aral: It has been really great.

Paul: What is it first of all? Explain to people what it is.

Aral: So Google App Engine is Google's foray into providing access to the cloud; to its infrastructure. So basically Google has this massively scaleable infrastructure that hosts, it's search and on it's various applications on. So Google's App Engine is Google's way of saying "ok, here's the technology that we have for building these infinitely scaleable applications, and we're going to make it available to you in a very simple manner so you can build your applications on it and host them on it". And it's really cool, the idea is awesome, and you're going to be hearing so much more about it as they add more features to it. It's currently in pre-release, so of course it was quite a gamble to base the website on a pre-release technology, but I'm still convinced that that gamble is going to pay off because basically the way I see it, there are the most intelligent developers in the world working at Google basically working for my application. Every feature they add basically adds a feature to my app in a way that I can use. So once they integrate things like the Google APIs, once they integrate other features, not that I have any insider information, but it just makes sense that they would do that, I think it's just going to become a more and more powerful platform.

Paul: But you found it a little bit painful at times.

Aral: Well of course. It's pre-release, right? And pre-release technologies have issues, so they're figuring things out. It's not something that, again, has been done before, Amazon has a really cool platform with simple DB, S3, S32 and those technologies which provide the same thing, but in some ways, Amazon's platform is much more tested, much more tried, but it's also more difficult to develop on, I mean, you need a lot of skills, you need to be a system administrator in order to build on EC2, or at least have some knowledge in that area. You need many more skills. With Google App Engine, if you know Python, you just download this SDK onto your machine, you install it and you have a local version of their environment on your machine and you can write a few lines of Python and start running your application on your local machine, and then you just enter one command and suddenly it's on Google's servers, and the theory is that a million people can hit it immediately and it's not going to go down.

Paul: Yeah, which for a conference like this where a large number of people are all going to be using a site at the same time, it's vital.

Aral: Yeah, and I mean we're not going to stress it at all with our numbers, but you know, if you think of the next Flickr or the next Twitter, although you can't currently build a messaging app on it, but apps that will get those numbers, that might get those numbers, they won't have to go through the standard stages of development. Because these days, today, what happens is you build an application, you build it using some sort of rapid framework like Rails or Django or whatever, you build it, you put it up there, and if it gets really popular, then you basically have to go in, you have to re-architect a lot of things. You know, for some apps like Twitter, they've basically had to rebuild the application as it's running. And that's a lot of work. Google App Engine turns this on its head. You have hurdles to get by when you're building the application, but you can test it, just with yourself, and if your application runs correctly for you, if you can get it to that point, then it will run that way for everyone that hits it. Or at least, that's the idea, that's where they're heading for.

Paul: That sounds really exciting, I look forward to seeing that develop.

Aral: It is.

Paul: You're very brave taking it on so early.

Aral: Well you know what, that's the thing. A few people have told me when I was bitching and moaning when we had a few issues, and let me tell you, Google have been amazing, I have direct contact with a couple of engineers on their team, and they have been amazing in helping me out and working with me, and I'm working with them to try to improve it. But a few people when I was bitching about it were like "well, you know, you just got what you deserve for using pre-release technology". But the thing is, someone has to, right?

Paul: Exactly, yeah.

Aral: Someone has to, so the next time somebody tries a beta piece of software, tries to build it and provides feedback, instead of going "ha ha, I told you so!" kind of think, well you know, I'm probably going to end up using this in a few years time and I'm going to benefit from the lessons you've learnt. So some people have to be early adopters, and yeah, getting burned with certain things is part of it. But it's just how it goes. But what interests me the most, Paul, about Google App Engine, and about like, EC2 et cetera, is that we're kind of entering the age of the commodity web, where the web, where building scalable applications on the web becomes a commodity just like electricity or water. You know, so we won't have to worry about things like hosting and this and that, it will just be like another meter reading, you know,um, I've made my app, here it is on the web, and I get charged for it by CPU cycles, by the amount of resources that I'm using, just like electricity.

Paul: I mean, that will be awesome. If we can reach that point where we don't have to worry about scaleability and things like that, that would just be incredible.

Aral: Yeah, I think we're nearly there.

Paul: That's superb.

Aral: Yep.

Paul: Talking of you working with people, you said you were working closely with Google over this, I know you've got an excellent relationship with the guys over at Adobe, and no doubt you've been playing with CS4, tell us a little bit about it. You were over at the launch of it were you not?

Aral: Yes I was, I wasn't actually speaking about CS4, but I was at the launch and I got to see some of the demos there. It's a huge suite, you know, I didn't have the chance to play with everything, so seeing some of their demos, it's really cool, it looks like they're really concentrating on integration between the products, they've been doing this for a couple of releases now, but it's really starting to pay off. When Adobe bought Macromedia, everyone was like, well you know, how are they going to integrate things, and people were fearing it was going to be an instant process and some of the tools would be ruined. That hasn't happened. But they have been integrating the products over the years with these release cycles. So, one of the demonstrations that I saw that was really cool for example was in In Design, which is a desktop publishing tool that they have, you can build a magazine, and then you can click a button, and then have that be an interactive magazine in Flash that you can put on the web with like a page turn effect and stuff like that.

Paul: Wow.

Aral: And that's actually quite awesome.

Paul: Yeah.

Aral: I spent a bit of time a couple of years ago to build an app that did that from PDFs, and that software is still going strong and being used on the web, but now you can just do that with In Design and Flash. And things like that, it really worked on the workflow between various tools, and it makes a lot of sense because web video is such a big thing now, and being able to take things from After Effects and Premier into Flash and back and into DreamWeaver and put it up on your site, they're really working on these workflows so they're not joined to tools. I think that's really for me the most exciting thing, apart from some of the cool stuff in Flash.

Paul: What have they done in Flash then that's so cool?

Aral: Some of the cool stuff in Flash? Well, we have bone support now, IK support. You can draw like a stick man for example and then you can take this bone tool and trace over its various limbs, and then have this puppet that you can play with, and the cool thing is, you can publish this and this puppet is interactive once you've published your movie as well, it's not just an authoring. So you're going to see some amazing advances in like online games that use this, and in animation. For animators, it's just going to make their lives so much easier. And that's just like one of the new things they have.

Paul: Did you get a look at Photoshop and whether there have been any major changes in that?

Aral: Yeah! Well they're really concentrating on the 3D stuff in Photoshop from what I can see. There's a lot of 3D tools, you can bring in 3D models into it, you can paint into them, they stay 3D as you're painting into them and outside of them. There was this one demo which I thought was really cool where they took an old-fashioned car and it was like a 3D model, and they just rubbed off the roof, and then it became like this convertable, but it's still 3D, and they started painting the seats, which is kind of cool. I think that's going to, again, it's an integration with your other tools, with your 3D tools. It does look really cool, I can't wait to play more with it.

Paul: I guess the only other one that's directly relevant to web design would be DreamWeaver. Did you get a chance to look at that?

Aral: Yes. Yeah, I did, and it seems to have gotten a whole bunch of new features as well especially with the CSS and their live preview of CSS. But to tell you the truth, I don't really use DreamWeaver. I started out with, well no, ok, I started out with Front Page many many years ago.

Paul: You should be ashamed to even admit that.

Aral: Forgive me, I know, but I switched to DreamWeaver right away! But recently, you know, I just do a lot of my stuff in Text Mate, and I don't know why that is, but I just find some of these tools to be way too heavy, especially for HTML, and I really like to have control over what I do. And Text Mate is light, I've begun to favour lightweight tools a lot.

Paul: Yeah, I must admit, I use DreamWeaver for a very long time as a text coding tool, not as a WYSIWIG, but in the end, it was just so slow to open up compared to other stuff and it just seemed to be chunky.

Aral: Yeah, I kind of went through the same thing, and I really, like I say, I really enjoy Text Mate. It is such a simple simple editor and it just works.

Paul: Ok, so that's really great Aral. Going back to the conference just very briefly, by the time this comes out, people are going to have missed unfortunately the early bird discount, so how much are they looking at for this conference?

Aral: Well the main tickets are $149, but who knows, maybe we can do something special for listeners of your podcast.

Paul: Oooooh!

Aral: If they are going to miss it.

Paul: Ok, well you let me know that, and we'll tag that on after this interview, I can do that easily enough.

Aral: Ok, cool.

Paul: You can find out about the conference over at headconference.com and I've got to say, this does look absolutely incredible. Am I right in saying that also people that have attended the conference, there's no way you're going to be able to listen to all 70 speakers over those couple of days. So they can go in and watch the videos after the event? Is that right?

Aral: Yep, all of the videos are going to be recorded and you'll be able to watch them at any time.

Paul: So I mean, absolutely superb for a $149 or whatever it is, that's an incredible deal and you will never come across a conference that's got quite this line-up of speakers, and certainly of course, you don't have to pay for hotel bills, you don't have to pay for travelling, and you don't even have to pay for time out of work.

Aral: Exactly, yep.

Paul: Sounds pretty good. Aral, thank you for coming on the show and we'll get you back again in the future.

Aral: Thank you Paul, oh it will be great, I love being here.

Paul: Ok, good to talk to you.

Aral: Take care, Paul.

Listeners feedback:

Review of Stackoverflow by Teifion

I'm a developer not a designer so if you understand my incoherent babbling please keep in mind that this review probably won’t be as useful for designers but please, fall asleep after I stop talking.

About a month ago I joined a site called Stackoverflow. Essentially it is a cross between a Forum, Digg/Reddit, Wikipedia and a Blog; you ask questions and answer questions, you also get answers to your questions and you generally get them very fast. It is now in public beta.

It's a simple idea that could be great and could also be completely useless. Jeff Atwood and Joel Spolsky have managed to make it very useful.

Now it's time to add some actual content to the review or Paul will call me silly names again. Questions in Stackoverflow are allowed to be on any language or topic related to programming and here’s where the designers might be interested, this includes source control, HTML, CSS and even things such as keyboard layouts.

The question that you should ask yourself right after "why am I listening to Teifion" is "Why is this better than google?". The answer is a simple one, Google cannot look at your site and tell you why a div is wider than you want it to be while a site with 8000+ members probably can. I am given answers to my questions within 5 minutes bar I think 2 obscure questions.

Don't feel that you are too new for the site either, you can ask anything from very simple to very complex questions, anything from "what is a class?" to "how do I benchmark a PHP or Python script via the Unix terminal and not from within the script itself?".

I strongly recommend that everybody check it out.

Don't Get Blacklisted By Google

Jason from Toronto recently wrote to me with a questions about search engine optimisation:

I am desperate to improve the search engine ranking of my company website but I am confused by the contradictory advice online. We have even considered hiring an SEO company, but aren't sure who is reputable. The last thing we want is to be blacklisted. Do you have any advice which might help?

It is true that Google comes down hard on sites who disregard their webmaster guidelines. Probably the highest profile example of this was when they effectively removed car manufacturer BMW from their search results for using doorway pages.

Don't get blacklisted by Google

Thu, 25 Sep 2008 17:26:03 +0000

There are so many SEO companies and so much advice about how to get ranked highly on Google. How can you tell the good from the bad?

Jason from Toronto recently wrote to me with a questions about search engine optimisation:

I am desperate to improve the search engine ranking of my company website but I am confused by the contradictory advice online. We have even considered hiring an SEO company, but aren't sure who is reputable. The last thing we want is to be blacklisted. Do you have any advice which might help?

With many search engine optimisation companies still using these 'black hat' techniques, it is important to be able to tell the good from the bad.

Later we will look at some of the SEO techniques that can get you blacklisted but first lets examine ways to identify a less than reputable SEO company.

Spotting the black hat operators

Always be sceptical of any company that contacts you out of the blue. If you are going to hire an SEO company, ideally you should use a personal recommendation.

Definitely beware of companies who guarantee a particular ranking. If a company promises that you will be ranked number one on Google, ask for more information. It is relatively easy to get a website ranked number one on Google for an obscure term. However it is much harder to get ranked for something that is useful from a marketing perspective.

Also ask what happens if a company fails to live up to its guarantee? Is there any real value in their promise? The answer is probably not.

Finally ask the SEO company to clearly explain the techniques they are intending to use. If they are evasive with their answers they should be avoided.

If you do discover the techniques they are intending to implement, this will enable you to judge whether you are in danger of being blacklisted.

Know their techniques

Most search engines provided guidelines about unacceptable SEO techniques. Google in particular provide excellent documentation for website owners looking to improve their rankings. They provide advice on selecting an SEO provider and layout what it considers unacceptable techniques. These include:

Hidden text and links - Some SEO companies use hidden keywords and links that provide no value to the user, but are designed to increase search engine rankings. Techniques include adding text that is the same colour as the background, hiding content with CSS, setting the font size to zero or hiding text behind images.
Search engine only content - Using techniques such as redirects and cloaking it is possible to show different content to a search engine than to a real user. This approach is often adopted on sites built using Adobe Flash. However, this breaks Google's terms of service and could led to you being removed.
Sending automated submissions to Google - Many website owners and SEO companies use software packages such as Web Position Gold to automatically submit their websites to multiple search engines. Again, this breaks Google's terms of service and could led to you being removed.
Duplicating content - Although Google recognises that some content is duplicated for legitimate reasons (e.g. a separate print version of your site), it frowns on websites that deliberately duplicated in an attempt to manipulate search engine rankings.
Doorway pages - These are pages that are created with the sole purpose of ranking well for certain keywords. They often have poor content and exist solely to funnel users into the main site.
Keyword stuffing - This refers to the practice of loading a webpage with keywords in an attempt to manipulate a site's ranking. This can results in a negative user experience, and could harm your site's ranking.
Participating in link schemes - Although your site ranking is partially based on who links to you, link exchange programs are still a bad idea. Exchanging links indiscriminately without considering their relevancy will damage rather than help your ranking.

Will implementing the above techniques get you removed entirely from Google? Probably not. However, they could damage your ranking over the long term and will almost certainly be a waste of money implementing.

Should you therefore avoid hiring SEO companies? Not necessarily. There are many reputable companies offering superb advice on how to improve your rankings. It just depends who you go with.

136. Stagnation

Wed, 24 Sep 2008 10:15:00 +0000

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.

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.

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.

Overcoming stagnation

Fri, 19 Sep 2008 09:27:44 +0000

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...

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

Wed, 17 Sep 2008 14:50:00 +0000

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?

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...

Accessibility is good for Search Engine Optimization (SEO)
Accessibility enhances usability for everyone. An April 2004 formal investigation into UK web accessibility (PDF) reported "all users, not just disabled people, would benefit greatly from the measures required to make sites accessible and usable by blind people".
Accessibility has many quantifiable business benefits (PDF). Legal and General, a British financial services company, redesigned its site with accessibility in mind and found:
- 40% traffic increase
- Doubled conversion rates
- Doubled online revenue
- 100% ROI in 5 months

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.

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 than 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.

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.

Quality or quickly?

Mon, 15 Sep 2008 12:38:39 +0000

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.

The advantage of launching early

The prevailing wisdom is to launch early. The logic goes that by launching quickly you can be first to market and then refine the offering based on user feedback.

There is certainly something to be said for being first to market, especially online. It is easier to build some buzz around your product if it is an original idea. You can also establish a customer basis more easily when there is little choice available. However it is not without its drawbacks.

The disadvantages of launching early

You only get one chance to make a first impression. If a user does not like your product they are unlikely to return. They will therefore never see improvements you make later. The customer is lost.

Also, by launching early your competition has the chance to adapt before they launch. Few ideas are truly original and somebody somewhere will already be developing something similar. If you launch too early they have the opportunity to adapt their offering to undermine you.

Of course, the danger of delaying launch is procrastination. That has certainly been my experience. The idea for GetSignOff was formed over a year and a half ago and we wasted far too much time. Be careful you do not make the same mistake and spend too long obsessing over details.

How to make a decision

When to release is dependant on two factors, what you are releasing and who it is aimed at.

If you are releasing a traditional website it is important that the quality is high. There is no option to slap on a beta label, and users are less tolerant of problems.

If the product is a web application the decision is dependant on the nature of that application. If it is business critical, the users will have a lower tolerance for problems. However, if it is something like twitter then downtime and problems are more easily accepted. After all, the inability to twitter is not the end of the world (not that you would guess that from some peoples reaction).

The second factor that determines when you launch is audience. For example the audience for GetSignOff are other web designers. Although you couldn't find a more critical audience, they do understand that a new product will have bugs. They are also experienced enough to work around usability problems and muddle through. However, if your audience is not so computer literate they are more likely to give up and try another site.

Fearing competition

There seems to be a fear of competition among web developers. They have this desire to be completely original, and so rush the launch of their application.

However, competition is to be expected and choice is good. I have received numerous apologetic emails and twitters from people pointing out the competition to GetSignOff. Their tone indicates that this is the end of the world. In reality it is to be expected. Even if GetSignOff was identical to its competition it would not be a problem. There are enough customers to go around. The web is a big place.

Take baked beans for example. There are a lot of varieties of backed beans and they are all basically the same. They do not even taste different. However, all of these varieties can exist side by side in the marketplace quite happily. There is enough demand.

In conclusion, there is no need to rush to market. Take your time and get your product right. However, be careful not to procrastinate and remember that you will need to tweak your application long after launch. No matter how careful the planning, you will not get it right first time.