Andy Budd on Usability, Design, and the Death of CSS

SP: The marketing of this application was interesting, wasn't it? You put up a sign-up page, and you told me earlier that you didn't plan on promoting it, but it seems to me like the perfect viral campaign.

I guess so, yeah. It really was accidental marketing though. What happened was we bought the domain, (link: silverbackapp.com) and it was just resolving to a domain name company, and we thought people might start hearing about it -- our friends or whatever. So I asked Paul, our designer, to stick up a holding page, and we had the nice gorilla design from Jon Hicks. And Paul, who's an awesome designer, created this nice little Parallax effect that he'd been playing with.

I went to London for the afternoon, not expecting much to happen, I was off to see a client. And he'd just twittered it -- he'd just posted "Guys, I've put this holding page up." And all of a sudden we got inundated with all these twitter messages and emails saying "Wow, that's so cool, what's Silverback?"

So people were getting excited because of the logo, people were loving the holding page, and people were really interested and curious about what the application was. And it was just a holding page -- we didn't want to give too much information away. It just said "Silverback. Coming soon." And that seemed to just generate so much buzz, and within the first day we had about 2,000 people sign up on our announcement list. And by the end of the week we had 5,000 people sign up, and I've got no idea how many people have signed up now.

So for a small little company doing a small little desktop app, that's pretty awesome. But now one of our fears is, because we've been a little bit mysterious about the application, and there are reasons why which I'll come to in a second, people have been imagining the best kind of thing that could possibly happen. I guess, because we're Clearleft and we're fairly well known, and I work with Jeremy and Rich and we've got so many smart people who work with us, suddenly people are starting to think that this is some sort of application that will solve world hunger and will, you know, make the world a peaceful place.

In fact, it's a really simple application that came out of realising that we've got a portable usability lab in our hands these days -- whether it's an iMac or a MacBook Pro or whatever. If it has a screen, it has a microphone, it has an in-built camera, then you don't need these big listening labs. You don't need to set up a tripod pointed at the screen. You can do it all in the one device.

And there used to actually be these portable usability labs -- you can still get them, in fact. They're these boxes with camera equipment and so on. You don't need that -- you've got it all in front of you. But the idea was so simple -- screen capture, audio capture, and video capture -- we were scared that if we gave too much information away, somebody who already had a screencasting app or was doing something similar could add feature in quickly and easily. So we didn't want to start shouting about it until we'd developed it.

Also, we'd never really developed a desktop app before, and we didn't know how long it would take -- and it has taken longer than we thought. It has taken probably a couple months longer than we ideally would have hoped. Getting bugs fixed and tweaked, and tweaking the UI. Plus if you develop an application, you end up obsessing over it, and we obsess about most of our clients' web sites as well. But if it's your baby, you want to make sure it's 100% right. So the fact that we didn't talk about it or saw what it was fueled the speculation even more. And that was part of the mystique -- everyone started chatting about "Oh, what is this Silverback?" People started writing blog posts, and I'd meet people at conferences, who'd say "Can you just tell me?"

So yeah, this kind of mystique did make it quite a popular thing, so it did help us. And I wouldn't say it was purely accidental, because as you saw today we do like building these little things into our applications, and we do have a good network of friends, so if we twitter something, people will find out. But it certainly wasn't a conscious thing to keep it secret so that it would fuel desire... it just kind of happened like that.

SP: What's your opinion of CSS Frameworks, and how do they fit into the approach you guys take in developing a solution for a client?

We have an internal framework that we use for our wireframes -- our prototypes. Wireframes are not things that live by themselves, so it doesn't really matter how semantic or pure they are.

This library, or "framework" if you want to be down with the hip kids, is a mixture of HTML and CSS and JavaScript, which we use time and time again for our wireframing. It makes use of jQuery, and a company we work with called New Bamboo have helped us to develop a jQuery plugin called polyPage, which allows multiple state changing within a wireframe, which is really cool.

So I think these libraries -- frankly, I think "framework" is a bit of a grandiose term for something like Blueprint, for example. Essentially it's three or four CSS files and a page worth of HTML. It's not a framework -- a framework, I think, is a much bigger thing. And there's a certain element of trumpet-blowing going on there. By calling it a framework, it makes it sound like it's this big, important thing like Ruby on Rails. Everyone knows Ruby on Rails is hot, everyone knows Django is hot -- let's call it a CSS framework, and it will be big.

I think what you need to do is develop your own framework. You need to develop a series of tools, a library of elements that work for your team, that work for the types of sites you build, that work for the internal belief system structure and knowledge that your team has.

I think generic libraries like Blueprint box you in to certain solutions. They have a certain amount of flexibility, sure. You can choose between one of any number of columns -- I think it's 16 or 24 -- and you can span columns and stuff. But it's still limited to this column behaviour. And you're limited to the size of the gutters and the width of the window, and if that doesn't necessarily fit with your designs, what do you do? Do you spend hours hacking your library to fit with your designs?

Probably not. What I imagine many people do is fit their designs around the library, and you end up getting this templated approach to web design, in the same way that people who are really focussed on a particular CMS -- all of their web sites are designed around the capabilities of that CMS, rather that creating a user experience that is right for that solution.

Ironically I've spoken to some of the people behind some of these libraries.And they have been in real-world situations where they've used a library initially, and it just didn't work and they've had to stop using it and rebuild things from scratch. So libraries aren't always the quickest thing to use, because you may be using the wrong tool for the job.

Jeremy has a saying, which I think is a pretty wise saying. He says, "If you have a hammer, everything looks like a nail." And I think that is the problem with the pre-built tools. If you have a design in place, you try and put everything into that library.

And I actually think Blueprint has some fundamental issues that, as a company, we don't particularly like. One of those is the fact that it is not very semantic at its core. It has presentational elements -- for example, it has classes called "span-1", "span-2", "span-3" ... and what it has essentially recreated is a table-based layout. My feeling is, why add 200 lines of CSS code to recreate a table-based layout, when you can just use a table? If you're not that bothered about semantic markup, and you're willing to use libraries that pollute the semantic nature of your HTML, why not use a table? Because it's already built, and all that code is already there. Why try and reinvent the wheel?

Now, personally I think that tables for layout are bad, but I also think that non-semantic markup is bad.

Then again, people would argue that it isn't really non-semantic. I think that clearly when you've got class names in your HTML structure that are called "span-1", "span-2", "left", "right", whatever, that it's a little bit backwards.