It’s nice to support this foundation and it’s projects, you should do too!

David Heinemeier Hansson is one of the most influential voices on the Internet. He is the author of the immensely popular Ruby on Rails programming framework, is a noted blogger and media figure, and is elegantly opinionated when it comes to the best ways to make great software. People follow David’s lead in droves, and for good reason: as a partner in the multi-million dollar company 37signals, David is one of the most successful young entrepreneurs in today’s Web economy.

Creators of Basecamp, Campfire, Highrise, and Backpack, and authors of the widely read Signal vs. Noise blog, 37signals is an advocate for all things simple and beautiful. We are delighted to share this interview with David about a range of topics—from software development to the productivity gains associated with making people happy.

Audio clips of the interview are included throughout the interview transcript.

Umbaugh: David, thanks for calling in today. It’s wonderful to have you with us.

DHH: Happy to be here.

Umbaugh: Your company 37signals is really successful, you have got an enormously popular blog and you’ve written several books. You built a great open source programming framework that people just love, and you’re actually making money selling software on the Web. Why are your ventures so successful?

DHH: Well, I think the biggest reason is because we don’t identify ourselves too much with the whole notion of the Web world. We identify ourselves more with the notion of a small business operating under proven approaches—like the crazy idea of charging money for products, which seems like a lost art for a lot of Web startups out there.

The best example of how we try to be just like a regular business is that we try to maximize our profits and minimize our expenses. No news there. The wonderful thing about working with the Web is that it’s in some ways easy to do both things. It’s much easier for us as a 10-person company to reach a huge audience than it is in the traditional world where small companies have a hard time getting heard. With our blog and our book, the Web really gives us a platform to present our products.

In many ways, it’s very productive, easy and cheap to build new applications if you have a good idea and an eye for what you want that you can actually accomplish with a small team. Our whole approach is to stay as small as we possibly can and have an influence through other means than just throwing a ton of software out there.

Umbaugh: 37signals had several successful products on the market. Were you ever tempted to give products away for free and use advertising to generate revenue?

DHH: No, never. I don’t think that that’s an attractive business model at all. There are a lot of people who focus on creating an audience and just get users for the sake of getting users. To me, that just isn’t interesting.

For me, it’s interesting to get users who like your stuff so much that they’re actually seeing real value from it, and thus are willing to pay for it. That’s much more of an affirmation that you’re doing something worthwhile rather than just getting a lot of users who want to use your stuff for free.

Most of the people at 37signals have been involved with other businesses and have seen what happens when companies don’t charge for their products or services. If you don’t start out charging money for your products, then you have to do something else. That usually means taking venture capital money or taking some sort of investment to fund your growth. That typically doesn’t lead to a healthy happy work environment. I mean it certainly can. There definitely are companies out there who made it work, but I’d say the majority of the VC-funded companies I’ve talked to—their practices, their lives in the workplace—are pretty far removed from what I would call an ideal situation.

Companies too often merely try to please users and get them to pay for stuff just to satisfy investors, satisfy the three to five-year exit window, and satisfy other external demands. Those are just distractions. For us at 37signals, we’ve managed to create a good situation in large part because we’ve been able to cut out distractions.

Umbaugh: Your book, Getting Real, outlines your software development process and your business philosophy in general. What are some of the core values you put forth in Getting Real, and how do you think software developed using that philosophy ends up benefiting the end user?

DHH: One of the big themes in Getting Real is the notion of less software. I think way too many companies and teams try to overachieve by building a ton of software, by building tons of flexibility into their software, including tons of features and by imagining all the things that somebody out there might need in some way, some day. I think that’s a really hard way to develop software because it’s so much fumbling in the dark.

What we try to do and what we advocate in Getting Real is focus more on needs that are closer to you, things that you can directly relate to, things that will directly determine the quality of something. For us, on both the business side and the software side, our approach is simplicity. Simple alone is a huge feature that’s often vastly overlooked. When people compare software products, they often compare checklists of features. In other words, the product that has the longest checklist appears to be the best.

Well we try to do exactly the opposite. We try to ‘under-do’ our competition by doing less than they do, by having the shortest feature list. That is, in essence, our biggest feature.

When we do customer surveys every few months, the number one thing that everybody says that they like the most about our products is the fact that they’re simple. Simple sounds in some ways, like a cliché. Nobody would say, ‘I want to make complex software.’ But they do say things that amount to the same thing. ‘I want my software to have tons of features. I want my software to have endless flexibility.’ Well, all these things are in essence saying, ‘I want complex software.’ We’re willing to take a stand for simplicity in software. We’re willing to say, ‘You aren’t going to get all the features you think you might need some day, you’re just going to have the basics executed beautifully. You’re not going to get all the flexibility you might imagine that you could need, but we’ll give you some.’ We’re going to have opinions and we’re going to instill defaults and we’re going to package it up.

We keep comparing ourselves to the notion of chefs. When you walk into a high-end restaurant, you really don’t get a whole lot of choice. Usually, the hallmark of a high-end restaurant is the chef’s menu. The chef prepared courses of a dinner in advance where he made all the choices. You eat there because you trust the chef’s judgment and want his taste. Well, we try to do the same thing. Instead of just giving you a super-long menu, we’ll just give you this set course of plates and you’ll have to trust our judgment on it, and I think you’ll end up with a much tastier meal in the end.

That’s one way we describe how we’re trying to be different from people out there, and we’re trying to convince others that they can do the same thing. There’s so much software out there that’s just endlessly complex, that has too many features, that has too much flexibility, and it ends up not being used because users can’t relate to it; they can’t get into it. It feels too complex. It feels intimidating when what they really need is just a small subset of what they’re given.

But most companies out there are afraid to give them just that small subset because everybody we’re talking to is saying, ‘We want more features; request this, that and the other thing.’ It’s actually funny—in our customer surveys, everybody says the number one feature they like about our products, our approach and our company is that we keep things simple. Then in the very same breath, they say, ‘Oh, I love all this simple stuff. By the way, please add A, B and C.’

It’s incredibly hard to help people realize that if we added their A, B and C, and everyone else’s D, E and F, they wouldn’t like the software anymore. It wouldn’t be simple any more. In some ways, we are in constant conflict and we just have to be willing to embrace that conflict. On one hand, you get to please users by doing something that’s simple and that doesn’t have a lot of features. On the other hand, we have to constantly push back against the very same people saying, ‘I want this, I want that, and I want the other thing.’

That’s a rough outline of the approach that we’re preaching in Getting Real on pretty much all levels. It’s not just about the software. It’s also about your policies, your pricing—this whole notion of keeping things simple so that you can have a simple team, so you can execute simply, so you don’t need a lot of money upfront, so you need fewer software developers, so you can do it with less marketing. In many ways it feel likes we’re stating the obvious, but I don’t think it’s so obvious after all, because most companies are not doing it this way.

Umbaugh: Software developers add features under the assumption that customers choose software based on its feature set. How would you convince developers that less software is a competitive advantage?

DHH: Exactly as you’re saying, everybody out there is doing the opposite of what we’re doing. Thus, if you’re doing the opposite of what everybody else is doing, you’re actually unique.

When you talk to anybody who’s used a computer for any period of time, the number one thing they typically say is how much they hate it because it’s too complex; it’s too hard to use. They can’t get their stuff done. So it’s not like users aren’t already predisposed to wanting something simple. I think this is true all over the place and people are selecting the simple stuff whenever they can.

I can think of two other examples not necessarily in the software world, but look at the iPod. There have been so many other MP3 players out there—a lot of them had FM tuners, they had voice recorders, they have laundry lists of features—but the iPod just successfully executed on a few basics really well and it’s overwhelmingly won the market.

Another more recent example, which I really like, is the iFlip portable video recorder. It has pretty much one feature—a big red button that says, ‘record.’ When you push that, it records video in not especially good quality, but it’s just incredibly simple to use and they’re selling these by the boatload.

Audio clip: Don’t underestimate simplicity – 2:25 min

So I think that oftentimes companies underestimate their customers. They underestimate how willing their customers are to sacrifice features in return for getting something that’s actually usable. Well of course the hard thing is to communicate this because everybody’s saying they’re simple even when they’re very much not. So in some ways this is just a slow steady build. But that’s pretty much how all business building is—very, very few businesses out there go from zero to multimillion in short order. Pretty much all businesses out there are grown slowly but surely, and I think that that’s what we’ve done as well. Basecamp wasn’t this blasting success on the second week of operation. It actually took a full year for Basecamp to be able to pay all the bills at 37signals.

Today of course it’s a fantastic business. It’s a multimillion-dollar business. We’ve bee doubling our revenues for the past many years and it’s doing very well, but it’s built into that. The reason it built into that is that this simplicity really works best as a word of mouth thing. You have somebody using Basecamp or another product of ours, it’s simple and they can actually get something done and they’ll tell their friends and so on and so forth. The checklist-driven or the feature list-driven approach is much more a shove it down their throats approach because people will perhaps get initially impressed by this long list of features. But when they actually start using it they probably won’t like it that much, thus their word of mouth will not be very good, thus you need to keep shoving it down new people’s throats who haven’t heard about your product from somebody else. That’s, in my mind, generally not a very viable long-term strategy. It’s very expensive, and it’s just not very satisfying. So in my mind, I think companies in general are underestimating their customers. They’re underestimating the importance and the success that simple has in the marketplace and could have for them and they’re kind of expecting that they’ll be success overnight, which is not going to happen in any case so…

Umbaugh: I think simplicity sometimes is easier in theory than it is in practice. If a team commits to writing a piece of really simple software, how do they go about deciding what features to include and which features to cut out? Do they perform user testing, or do they just decide on their own? What approach does 37signals take and how would you extrapolate that outward?

DHH: Sure. So the first thing you do is you don’t talk about it that much. You don’t try to write it down into functional specs. You don’t try to envision your entire product upfront because we simply cannot hold all these things in our head. If you try to write it all down on paper, the easiest thing to do is to add one more feature. One more feature when you’re writing it down on a piece of paper is just a single line. It’s a bullet point. How long does it take to write a bullet point? Not very long at all. So every single idea whether good or bad, has a tendency to make it into the declaration of what this product should be. In our minds, the only way, for us at least, to arrive at usable software is to build it and use it at the same time.

I’ll tell you about how we built Basecamp. We started building Basecamp by building one feature. What is the one thing that Basecamp must do for it to have any value at all? For us, that was the Messages section. If we don’t have the Messages section in Basecamp, we don’t have Basecamp. So we start building the Messages section and we started using it very shortly thereafter. Once you get rolling with that ball, it becomes almost self-evident what you should be working on next because when you’re using your software, there’s just one or two features that’ll keep popping up as next most important thing to work on.

For us, I believe that was Milestones. So after we got going with communications in Basecamp, the next thing we wanted was this impromptu or really easy planning tool in the Milestones. Once we had that, we went on to do the Files section, and the To-do list and so on.

But the great thing about building software one feature at the time is that:

1. You can pretty much stop at anytime. If we had stopped Basecamp just after we built the Messages section, we would still have a usable piece of software. We would have had the Messages section, which is usable piece of software in itself. It definitely would not have been as useful as Basecamp is today, but it still would be a useful piece of software.
2. Project participants build an immense amount of confidence to see running software that does something useful. People typically approach building software where you write it all down in a functional spec, then a team of programmers goes away for nine months (or year and a half) and they come back with software you don’t want anymore. This is that constant struggle of change requests of saying, ‘Well, this is not what I want,’ says the customer; and the developer says, ‘Well, this is what you asked for.’
3. There’s just no way of successfully describing software in the abstract on any sizeable project. The only way for us, and I believe for pretty much anyone, to arrive at a workable usable good software is to build it and plan it at the same time.

Audio clip: Functional specs are relics – 3:46 min

Umbaugh: Okay, so functional specs, they’re everywhere. So I think a lot of people think of a functional spec as something that keeps a piece of software organized during the development phase. You just don’t agree with that notion?

DHH: I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don’t think that functional specs is a technique that’s any longer relevant. To me functional spec is a dead document. It’s an illusion of agreement. It’s very, very easy for people to sit around a table and just try to hash out what the program should do on a piece of paper.

As we were talking about before, the cost of adding another feature when you’re working with a functional spec is the price of a bullet point in Word, which means incredibly inexpensive. It’s also a point where you really don’t want that much contention. It’s hard to make decisions because when it’s so easy to add something else in, why wouldn’t you just do that? Would you really want that big debate at the table right now, or are you just trying to please everybody who sits around the table? Usually you try to please everybody who sits around the table, and that’s really bad way of building good software because you can’t please all the people all the time. You’re going to end up with something that pleases nobody at any time.

I think this illusion of agreement is especially dangerous in the sense that we can both agree on what a paragraph of text says. Customers and developers do this all the time. Yes, the system will have a Milestone section, and everybody nods their heads and agrees. The developer goes off and builds that Milestone section, takes it back to the customer, and the customer says, ‘This is not at all what I wanted,’ because this illusion of agreement when you’re working with abstracts (such as paragraphs and words and bullet points) are just so far removed from software that is almost useless, if not outright dangerous. So I think functional specs are a really bad way of developing software because they have all the illusions of agreement.

They try to plan a piece of software into a most unique detail at the point in time where you know absolutely the least about what that piece of software should do. On day one when you’re planning some software, you have no idea on how it’s all going to fit together. Nobody can hold a complete piece of software in their head and imagine something good. Instead just planning piece-by-piece or inadvertently working small chunks to try to finish something, you get the benefit of doing planning for stuff that’s very immediate. You’re planning for next week or two weeks from now. It’s so much harder to try to plan what you’re going to do six months from now to the point where it’s at it’s downright useless, in my mind. People and programmers and designers are just not good enough to do that. The only way you can do successful job, in my mind—the only way you can create useful good features that people will actually appreciate—is by designing them in very unique detail as you’re going along as they’re needed right now. So these things kind of have to go hand-in-hand and I see the functional spec is just a really poor way of doing this.

Umbaugh: So what do you instead? If you don’t have functional specs, doesn’t the process turn into chaos?

DHH: No, I don’t think so. What we do is we do the user interface first. So when we’re starting a project like Basecamp, we’ll have a rough idea of what we want—project collaboration—and that will be the banner for this piece of software, and we’ll start with the most important feature.

Where do we go from there? We start designing the screens. Instead of trying to write and own a paragraph and imagine what the software should do, we go straight to the elements. We go directly to the core and we start working in it, start cutting in the materials until we find something that looks like what we want. That’s exactly the point in time when we can have a real meaningful discussion about how the software should work.

Developers know this instinctively. When they go to their customer and show them that piece of software that the customer told them to make, well, first of all the software’s not going to be what the customers want. But when the developers show customers that piece of software, the customer all of a sudden has a very, very specific explanation for exactly what they want because you’re working with something concrete now. They can say, ‘Well, we don’t want this screen here or this is actually not how it’s supposed to be. If you move these things around, you understood it wrong and so on.’ Once you arrive at that point, everything becomes so much easier.

So we try to do the user interface screens upfront. We then move from the user interface screen to the implementation part, which is always a back and forth process when the developers push back: ‘If you move this piece of the UI a little bit down…if we use a checklist instead of radio buttons…or if we did this, that and the other thing, it would makes more sense.’ You hash it out as you go. Then when you’re done with, say, the Messages section, you try to use it and you tweak it and then you go on to the next thing.

When you have a functional spec, you have the blueprints upfront, which is really an illusion that you have all the answers right away. But we can never design software like that, even on a feature we’re working on right now—we’ll change it many times over. We would end up with really terrible software if we only got one shot at it. Nobody can make perfect decisions off the top of their head in abstract terms laid out in paragraphs and bullet points. Everybody needs something concrete. Everybody needs something tangible for the mind work at its best.

Umbaugh: When your follow this iterative method of software development, how do you conform to schedules and budgets?

DHH: So two things. First of all, how many of your customers actually receive what they asked for? How often have you done the functional specs, got a budget in on time, delivered the software on time and—most importantly—delivered a piece of software that you actually liked that actually solved your problems to the fullest of its ability? Most people will say pretty much never, because the fact is that the process doesn’t seem to work very often.

The software world is ridden with this stigma that we can never deliver anything on time. We can never deliver what the users want, and tons of projects end up canceled. So I say the predominant development process has shown itself to be broken. Once something is truly broken, it’s a lot easier to face facts and try something else.

Second thing: There are a lot of techniques you can use to control your costs at the same time you control what the software is going to be like. I’d actually say that the iterative approach is a much safer bet, a much easier way to control costs. When you build something from a functional spec, there’s no real sense of priority in the sense of how this software is going to be implemented. When greeted by a functional spec, very rarely do developers start with the feature most important to the business right away. They’ll start with the features that they like best, implement that feature to 90 percent, and they will move on to something else. At the end of the cycle, they’ll be 90 percent done and they’ll have 90 percent left. That’s usually how these things go.

Instead, when you work in short bursts time—the boxed development approach, one or two or three weeks at a time—you can sprint during those weeks to develop some features. After three weeks, you’re going to have a piece of software that does something. So it’s much safer. You can see after three weeks if you don’t like the direction this is going, you can now cancel the project. You only spent three weeks of development learning that, well, this is just not the right thing, let’s cancel it, instead of waiting the nine or the 18 months for somebody to come back with a complete implementation of your functional spec and have the customer tell you it’s not what they wanted anyway.

Now you’ve blown that entire period of time. But after the three weeks working in the iterative style, you’ll have a pretty good idea of where your project is going. I think you can say, ‘I don’t like it. Let’s cancel the project.’ You’ve only wasted three weeks’ worth of money. More likely, you can say, ‘I like where this is going, and seeing this piece of software I have, let’s do another three weeks.’ It’s much more piecemeal. It’s much more controlled. It’s a lot less scary for customers to work this way because they get constant feedback, so there is less uncertainty on how it’s all going to end up.

Audio clip: Controlling costs in time boxes – 2:20 min

There’s going to be a lot more trust built up between developers and the customer. And developers are going to be a lot happier for it too, because they get to deliver real workable software very early in the process and they get to get real valuable feedback such that they can change their course before they’ve implemented everything wrong. So the techniques are to use a time box approach—a week, two week, three weeks, whatever you decide on, just schedule for that time box—one time box at a time and you can also just set a budget. So the most this project can cost me is $50,000. Well, divide that by the hours you can buy at a given rate from the developer and you’ll end up: Okay, we have six boxes of three weeks each, so I have to arrive at some usable software within the scope of six times three weeks. Well, that’s pretty cool because you can now see after you’ve spent one of these time boxes, am I getting the right way, am I liking where this is going, do I need to change the course, and you can constantly alter and adjust where the project is going. And if you’re happy after four weeks, if you like the software that you have then, fine, you just stop. If after six weeks, you realize that the original budget is spent but this software is so valuable, you’re getting so much good stuff out of it that it’s going to be worth another $50,000, you just keep on going.

It’s just to my mind it’s a lot safer way of developing software. It’s a lot more likely you’ll end up with software that you’ll actually want to use and is developing some value. But I understand that it’s scary because it’s not how most people do things and they kind of have a tendency to want to know exactly upfront what something is going to cost. That’s completely natural. The only problem is it just doesn’t work. There’s no way that you can ever pinpoint exactly what something is going to cost when you don’t know what that something is. That’s how you get into the whole functional spec thing where you get into the illusion of trying to figure out what the something is actually going to be, but it just doesn’t work.

Umbaugh: Is facilitating iterative development environment part of the reason you chose to create Ruby on Rails?

DHH: Oh, definitely. A big part of why this shift is happening now versus, say 15 years ago, is that the cost of software development has dropped radically. Tools have become much more productive, making it much easier to implement something of value. It’s become feasible to talk about delivering real business value within the scope of one week, or two, three weeks, or whatever your time box is.

For us, our constraints were even more extreme. When we started working on Basecamp, I was still in school. The other guys were working on client gigs. I had 10 hours per week—not per day, per week—to work on Basecamp. So I needed something that was productive enough that 10 hours of programming time would yield concrete benefits. Frankly, the other environments that I’d been working in—PHP and Java—were not giving me a good value for of my ten hours of investment.

It was really just a great realization to discover Ruby and use tools that fit my working style and could help me deliver something useful, meaningful within the scope of just 10 hours. That’s what Ruby is optimized for: extreme productivity under pretty harsh constraints, like having teams with a single programmer who has limited time.

Those constraints led to interesting choices in the design of that framework that just wouldn’t have arrived otherwise. I think it’s very apparent when you look at mainstream tools such as C and Java—how they’re just not designed for resource-constrained operations, especially when the resource is a human resource. They’re designed for big teams, million-dollar budgets and year-long implementation. On the other hand, Ruby on Rails is designed for something more like this: ‘Hey, we want an application done in three man-months. Let’s use something that will allow us to get that done.’

Umbaugh: You’ve been outspoken about how Ruby on Rails was designed to make programmers happy. Why do you think that’s an important value for a programming framework?

DHH: The interesting part of Ruby on Rails was getting really high productivity. I asked myself when I am working most productively. When do I just knock out features and just get a ton of stuff done? I get a ton of stuff done when I’m really pleased with the implementation of what I’m doing, when I’m really pleased with the coherency and in some ways the beauty of the software that I’m creating. When I’m writing beautiful software, it just seems to fly off my fingers and I get a ton of stuff done.

Audio clip: Love the code you’re with – 2:40 min

I was really having a hard time writing beautiful software in Java and PHP because those languages and platforms just weren’t, let’s say, making themselves readily available for beautiful implementation—at least in the way I use them. So when I finally discovered Ruby, I discovered a programmer language that allowed me to write these beautiful programs. And I realized that that was the number one thing that would shoot up my productivity: being motivated by beautiful software. By writing software that you like just makes you so much more productive as a programmer. Up until Ruby on Rails really made that a theme, it was somewhat neglected that the programming environments should really cater to the programmer, not the other way around. Programmers shouldn’t try to bend themselves in those ways to programs, and I think that most other programming environments are just not optimized to the programmer first.

Ruby had it straight in its almost mission statement. Matz, the creator from Japan, when he wrote about why he created Ruby, he wrote that he wanted a programming language that makes the programmer happy, and that was his prime motivating goal. Well, I took exactly the same mission and applied it to just a slightly more specific field—that of Web programming—and I tried to build a framework that would make programmers really happy about the actual code, the actual work that they’re performing. For all the feedback I get when I go to conferences, when people write emails, and so on, that’s the one I’m most proud about. People coming up to me saying, ‘I used to not like my job very much. I used to consider whether programming was something I wanted to do just because I wasn’t writing programs that were making me happy. I wasn’t writing implementations that were beautiful and satisfying, and now I am. I’m loving it now. I’m loving writing beautiful programs. I’m loving be a programmer,’ and so forth, because that’s exactly the experience I had. I didn’t use to like programming that much. I used to like programs; I used to like having the results of what I did come to life, but I didn’t use to like the actual process that much. After I switched to Ruby, started working on Rails, I never enjoyed programming so much in my life, thus never been so productive doing programming as I’ve been since I switched.

Umbaugh: So, are there business advantages to developing software that makes customers and employees happy?

DHH: Oh totally. I think that making people happy is pretty much why we’re all here and why we’re all working in software or working anywhere, for that matter. Most people aren’t working in places where making their customers happy is an important factor. To me it’s very hard to make your customers happy if you’re not happy yourself. That has to start from within. You have to be happy with the work you’re doing, happy with the products that you’re producing in order to really truly make your customers happy. It’s very much a positive feedback cycle. When you like what you do, you’re going to create something that’s better than if you don’t like what you do. All things being equal, your customers are going to like you and your product a lot more. I don’t think you can separate the two, really. It’s going to be very hard for a company that doesn’t focus on having happy employees to have happy customers, and I don’t think the companies are going to do very well at all.

Umbaugh: David, we have two other developers from EffectiveUI on the call, Tony Hillerson and RJ Owen. I’m going to let them ask a few questions, okay?

DHH: It’s my pleasure.

Tony Hillerson: Hi David, great listening in today. My question is about giving users choices. Do you think offering users more choice or less is preferable?

DHH: Less choice by a very wide margin. There’s a lot of interesting research going on in this right now, actually. There’s a book called The Paradox of Choice: Why More is Less by Barry Schwartz that discusses a number of scientific studies done in grocery stores. A typical grocery store has about 41 varieties of jams and marmalade available. The study measured how many people would go over to the wall, look at a few different types of marmalade and jam, and then actually choose to buy something and go home. Then they contrasted that to a wall with only three different kinds you could pick. I think the sales on the wall with three choices were something like 40 percent higher.

Then they analyzed all the qualitative feedback that stemmed from that interaction. People faced with a ton of choice very easily became insecure. Am I picking the right one? Is there something else that’s actually going to taste better? They highly doubted their choices and ended up not buying anything at all, afraid of being disappointed.

That research can apply directly to software, at both the infrastructure level of software like Ruby on Rails that appeals to programmers, as well as for end users. Most people just want to get stuff done. They don’t want to sit and tinker. They don’t want to spend time setting stuff up. They just want really good defaults. Again, going back to the chef metaphor, you want your dish coming out of the kitchen ready to eat.

Audio clip: Forget about preferences – 1:48 min

Actually this is one of my bits I always play out when I came here from Denmark about three years ago: one of the things I absolutely hated was the notion of the construction kit meal, which is this notion that in certain bars you’d get a burger and it comes disassembled. There’d be certain amount of lettuce, there will be some tomatoes, some onions, and so on. It was up to you to put it back together. Well screw that; I just want a meal. I want what the chef thinks is going to be a good meal, and I really don’t want to put it all back together myself. That’s I believe why I’m paying this guy to prepare food for me.

In the same sense, this is why users are paying software developers money to use their products because the software developer hopefully put some thought into how the stuff should work. So we’re really not big into having a whole lot of options. Actually one of our prime motivated design directives is to avoid preferences. Whenever we have to put in or feel that we have to put in a preference in our software, we pretty much consider that a defeat. We were not good enough. We were not good enough at coming up with a reasonable choice that most people would like most of the time. I take the same approach to designing Ruby on Rails. I really don’t want there to be a whole lot of choice when the choice itself doesn’t matter or when we think that there is a best practice that we could just follow out the gate. Why do we have to leave all these choices up to the user, again programmer, if we could just once for all make a good choice for everybody? I think it’s just such a waste of work productivity when you force everybody to go over the same considerations time and time again to make essentially the same choices.

For example, in Basecamp, the Dashboard will contain five projects and the five latest things from each project. That’s a good default. You can’t change it to seven projects. You can’t change it to three projects. It’s just five, and it actually does matter. It matters in the sense that it’s a good default and it’s just something you just don’t have to worry about. If you have all these options of how many things you can see in the Dashboard, that’s just another obstacle for you to actually get to the thing that you’re trying to do, which is to use Basecamp to organize your project. You’re not using Basecamp for Basecamp’s own sake.

That’s what I was talking about earlier. Too many programmers are using programs for their own sake. They like tinkering with programs, not necessarily using the programs to solve actual problems, but just because they like software. So it’s very natural for programmers to like to have their software as tunable and tweakable as possible. That’s just not true for the general population, and I also think it’s not really true for programmers, either. Ruby on Rails is probably the least configurable framework out there and at the same time it’s still one of the very most popular frameworks out there.

Hillerson: On a slightly different topic, how did you reach the decision to release the secret sauce behind 37signals—Ruby on Rails—to the open source community?

DHH: Why did we choose to do that? First of all, we don’t do infrastructure software. That’s not the business we’re in, so the secret sauce is actually not Ruby on Rails. We could be using anything else out there and we could probably still arrive at our products. Not as easily and probably not as cheaply, but the secret sauce is really the design of our products, not what we use to implement them in.

We’re not going to gain anything by keeping Ruby on Rails to ourselves. We’re also not going to gain anything or win anything by trying to sell it. There’s nobody out there short of Microsoft or IBM who can make money anymore selling general-purpose infrastructure-level software in my mind. And it’s also not the business we’re in.

We decided that if we open-sourced this framework, a lot of people would use it and hopefully implement a bunch of features that we’re probably going to need anyway, so we won’t have to implement those features ourselves. They’re probably going to find and fix many bugs that we would otherwise hit and have to fix ourselves, so we don’t have to do that. So that made good business sense for us.

Second of all, I mean for us our marketing secret is something we stole from Kathy Sierra. She writes a wonderful blog called Creating Passionate Users and a wonderful book series called Head First. The theory is: you can either out-spend your competition or you can out-teach your competition. Well, 37signals is not going to out-spend anybody. We are 10 people. We don’t have venture funding. There are a lot of people out there who can blow more money than we can on any number of things.

But what we can do—or at least try to do—is we can out-teach the competition. We can out-share the competition. Again, I keep coming back to this cooking world, who are the famous chefs out there? They are the ones who gave away their recipes. They are the people who wrote cookbooks, wrote recipe books, went on TV, showed how they did the things that they do.

We used exactly the same strategy for our own purposes. We gave away our recipe book in the form of Ruby on Rails. We gave away most of ideas in the form of Getting Real and we continue to give away these internal discussions and so on through our blog Signal vs. Noise. In return, we get a lot of passionate users who learn more about the company, who get inspired to do their own thing, and hopefully choose to use our software along the way.

People overestimate secret sauce in general. There’s very little secret sauce out there in terms of software that’s just so brilliant that you have to keep it for yourself. In general, I think that there’s way more value to be had by sharing the software that’s not your core business. So we’re not going to share the source code to Basecamp. That wouldn’t make any sense; that is what we do. But the database driver that Basecamp uses to connect to the 37signals‘ database, that’s not specific in any way to what we do, thus makes a perfect target for something we can share.

RJ Owen: David, do you cook?

DHH: I actually don’t, but I love eating at restaurants where I can just say, ‘Give me what the chef thinks is a good thing tonight.’ I hate long menu boards and I hate construction kit food. I love giving somebody who I think I can trust free rein to do the best they can do.

Hillerson: On a final note, tell our readers what you think makes a good user interface design.

DHH: For me a good user interface is a simple user interface. It’s a user interface that doesn’t try to expose or reveal too many features or preferences. That’s pretty much the extent of the general-purpose ideas.

Also, a good interface should focus on context over consistency. We have a lot of interfaces that are subtly different because they have a slightly different purpose even though they could have been shoved into the same template. I think a lot of Web development shops have a tendency to just create the overall skeleton of the site once and for all, and then just plug stuff into it from there on out. We think that’s exactly the opposite way of how you should be doing it.

When we start to design something, we don’t start with the frame, or navigation, or the search tab, or any of that stuff. We try to practice something what our people have labeled ‘epicenter design.’ Try to start with thing itself, not the frame, but the picture. In the Messages section of Basecamp, we looked at an individual message: What should the headline look like? How should the date be formatted? How many paragraphs of text should you show before you have a ‘more’ link? Those are the important decisions to make, whereas the ‘what color should the sidebar be, or how large it should be’ is like window dressing.

We have a slightly different perception of what designers are at 37signals. It is not so much about making things pretty as it is about figuring out what things should be and how they should work. That requires looking at the things themselves and not at the frame, or other elements that will fall into place naturally later. Once you have a really good message design, creating the rest in some ways is trivial.

Umbaugh: It was a privilege to do this interview with you. You’ve been inspirational to my career, and to others who are reading this.

DHH: Sure, it’s always fun for me to talk about these things, so entirely my pleasure.

This article was originally published on the User Interface Resource Center (UIRC). For more info, please see http://uxmag.com/uirc

“

(Via UX Magazine Articles.)

HOMETUTORIALSARTICLESFREEBIESVIDEOSABOUTSUBSCRIBE BY RSS | EMAIL | OTHER
HOME  \  ARTICLES  \  INSPIRATION  \  40 FREE TUTORIALS ON ADVANCED…
CATEGORIES
CONTESTS
INSPIRATION
INTERVIEWS
NEWS
TECHNIQUES
WEB ROUNDUPS

40 Free Tutorials on Advanced Drawing Techniques
Feb 19th in Inspiration by Chris Spooner
The traditional form of drawing and sketching is a highly sought after skill. Develop your personal drawing abilities by following this collection of 40 great tutorials on advanced drawing techniques, including general theory, useful tips, comic inspired art and some methods for transforming your creations into digital format.

Author: Chris Spooner
Chris is a web designer, logo designer and vector illustrator. Find Chris’s portfolio and blog at SpoonGraphics.

1. How to Draw a Car

Use a range of pencil drawing techniques to create an American classic, the Corvette. This tutorial from DueysDrawings.com covers the process from roughing out the initial outline through to shading”

(Via .)

Mid-’80s presentation from Alan Kay showing off Sketchpad, a simply incredible vector drawing application written by Ivan Sutherland in 1963. 1963! This is astonishing. (Via Swiss Miss.)

“

(Via Daring Fireball.)

It’s no great mystery that truly great user interfaces are the ones that are engineered to stay out of the way.

‘Staying out of the way’ means not distracting your users. Rather, good UIs let your users complete goals. The result? A reduction in training and support costs, and happier, satisfied and highly engaged users.

When getting started on a new interface, make sure to remember these fundamentals …

Editor’s Note: Kyle will be talking about User Interface Design at The Future of Web Design NYC.

1. Know your user

‘Obsess over customers: when given the choice between obsessing over competitors or customers, always obsess over customers. Start with customers and work backward.’ – Jeff Bezos

Your user’s goals are your goals, so learn them. Restate them, repeat them. Then, learn about your user’s skills and experience, and what they need. Find out what interfaces they like and sit down and watch how they use them. Do not get carried away trying to keep up with the competition by mimicking trendy design styles or adding new features. By focusing on your user first, you will be able to create an interface that lets them achieve their goals.

2. Pay attention to patterns

Users spend the majority of their time on interfaces other than your own (Facebook, MySpace, Blogger, Bank of America, school/university, news websites, etc). There is no need to reinvent the wheel. Those interfaces may solve some of the same problems that users perceive within the one you are creating. By using familiar UI patterns, you will help your users feel at home.

CoTweet uses a familiar UI pattern found in email applications.

3. Stay consistent

‘The more users’ expectations prove right, the more they will feel in control of the system and the more they will like it.’ – Jakob Nielson

Your users need consistency. They need to know that once they learn to do something, they will be able to do it again. Language, layout, and design are just a few interface elements that need consistency. A consistent interface enables your users to have a better understanding of how things will work, increasing their efficiency.

4. Use visual hierarchy

‘Designers can create normalcy out of chaos; they can clearly communicate ideas through the organizing and manipulating of words and pictures.’ – Jeffery Veen, The Art and Science of Web Design

Design your interface in a way that allows the user to focus on what is most important. The size, color, and placement of each element work together, creating a clear path to understanding your interface. A clear hierarchy will go great lengths in reducing the appearance of complexity (even when the actions themselves are complex).

5. Provide feedback

Your interface should at all times speak to your user, when his/her actions are both right and wrong or misunderstood. Always inform your users of actions, changes in state and errors, or exceptions that occur. Visual cues or simple messaging can show the user whether his or her actions have led to the expected result.

BantamLive provides inline loading indicators for most actions within their interface.

6. Be forgiving

No matter how clear your design is, people will make mistakes. Your UI should allow for and tolerate user error. Design ways for users to undo actions, and be forgiving with varied inputs (no one likes to start over because he/she put in the wrong birth date format). Also, if the user does cause an error, use your messaging as a teachable situation by showing what action was wrong, and ensure that she/he knows how to prevent the error from occurring again.

A great example can be seen in How to increase signups with easier captchas.

7. Empower your user

Once a user has become experienced with your interface, reward him/her and take off the training wheels. The breakdown of complex tasks into simple steps will become cumbersome and distracting. Providing more abstract ways, like keyboard shortcuts, to accomplish tasks will allow your design to get out of the way.

8. Speak their language

‘If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. ’ – Getting Real

All interfaces require some level of copywriting. Keep things conversational, not sensational. Provide clear and concise labels for actions and keep your messaging simple. Your users will appreciate it, because they won’t hear you – they will hear themselves and/or their peers.

9. Keep it simple

‘A modern paradox is that it’s simpler to create complex interfaces because it’s so complex to simplify them.’ – Pär Almqvist

The best interface designs are invisible. They do not contain UI-bling or unnecessary elements. Instead, the necessary elements are succinct and make sense. Whenever you are thinking about adding a new feature or element to your interface, ask the question, ‘Does the user really need this?’ or ‘Why does the user want this very clever animated gif?’ Are you adding things because you like or want them? Never let your UI ego steal the show.

10. Keep moving forward

Grandpa Bud: If I gave up every time I failed, I would never have invented my fireproof pants!
[Pants burn up, revealing his underwear]
Grandpa Bud: Still working the kinks out a bit.

from Meet the Robinsons

Meet the Robinsons is one of my all time favorite movies. Throughout the movie Lewis, the protagonist, is challenged to ‘keep moving forward.’ This is a key principle in UI design.

It is often said when developing interfaces that you need to fail fast, and iterate often. When creating a UI, you will make mistakes. Just keep moving forward, and remember to keep your UI out of the way.

Editor’s Note: Come hear Kyle speak about User Interface Design at The Future of Web Design NYC.

Photo credit: flickr.com/photos/lostamerica

“

(Via Vitamin Master Feed.)

CSS is one of the most powerful tools that is available to web designers (if not the most powerful). With it we can completely transform the look of a website in just a couple of minutes, and without even having to touch the markup. But despite the fact that we are all well aware of its usefulness, CSS selectors are still not used to their full potential and we sometimes have the tendency to litter our HTML with excessive and unnecessary classes and ids, divs and spans.

The best way to avoid these plagues spreading in your markup and keep it clean and semantic, is by using more complex CSS selectors, ones that can target specific elements without the need of a class or an id, and by doing that keep our code and our stylesheets flexible.

CSS Specificity

Before delving into the realms of advanced CSS selectors, it’s important to understand how CSS specificity works, so that we know how to properly use our selectors and to avoid us spending hours debugging for a CSS issue that could be easily fixed if we had only payed attention to the specificity.

When we are writing our CSS we have to keep in mind that some selectors will rank higher than others in the cascade, the latest selector that we wrote will not always override the previous ones that we wrote for the same elements.

So how do you calculate the specificity of a particular selector? It’s fairly straightforward if you take into account that specificity will be represented as four numbers separated by commas, like: 1, 1, 1, 1 or 0, 2, 0, 1

1. The first digit (a) is always zero, unless there is a style attribute applied to that element within the markup itself
2. The second digit (b) is the sum of the number of IDs in that selector
3. The third digit (c) is the sum of other attribute selectors and pseudo-classes in that selector. Classes (.example) and attribute selectors (eg. li[id=red]) are included here.
4. The fourth digit (d) counts the elements (like table, p, div, etc.) and pseudo-elements (like :first-line)
5. The universal selector (*) has a specificity of zero
6. If two selectors have the same specificity, the one that comes last on the stylesheet will be applied

Let’s take a look at a few examples, to make it easier to understand:

• #sidebar h2 — 0, 1, 0, 1
• h2.title — 0, 0, 1, 1
• h2 + p — 0, 0, 0, 2
• #sidebar p:first-line — 0, 1, 0, 2

From the following selectors, the first one is the one who will be applied to the element, because it has the higher specificity:

• #sidebar p#first { color: red; } — 0, 2, 0, 1
• #sidebar p:first-line { color: blue; } — 0, 1, 0, 2

It’s important to have at least a basic understanding of how specificity works, but tools like Firebug are useful to let us know which selector is being applied to a particular element by listing all the CSS selectors in order of their specificity when you are inspecting an element.

Firebug lets you easily see which selector is being applied to an element.

Useful links:

• CSS Specificity: Things You Should Know
• Link Specificity¯MeyerWeb
• CSS: Specificity Wars
• Assigning property values, Cascading, and Inheritance—W3C

1. Attribute selectors

Attribute selectors let you target an element based on its attributes. You can specify the element’s attribute only, so all the elements that have that attribute — whatever the value — within the HTML will be targeted, or be more specific and target elements that have particular values on their attributes — and this is where attribute selectors show their power.

There are 6 different types of attribute selectors:

• [att=value]
  The attribute has to have the exact value specified.
• [att~=value]
  The attribute’s value needs to be a whitespace separated list of words (for example, class=’title featured home’), and one of the words is exactly the specified value.
• [att|=value]
  The attribute’s value is exactly ‘value’ or starts with the word ‘value’ and is immediately followed by ‘-’, so it would be ‘value-’.
• [att^=value]
  The attribute’s value starts with the specified value.
• [att$=value]
  The attribute’s value contains the specified value.
• [att*=value]
  The attribute’s value ends with the specified value.

For example, if you want to change the background color of all the div elements that are posts on your blog, you can use the an attribute selector that targets every div whose class attribute starts with ‘post-’:

div[class$='post'] {
	background-color: #333;
	}

This will match all the div elements whose class attribute contains the words ‘posts’, in any position.

Another useful usage of attribute selectors is to target different types of input elements. For example, if you want your text inputs to have a different width from the others, you can use a simple attribute selector:

input[type='text'] {
	width: 200px;
	}

This will target all the input elements whose type attribute is exactly ‘text’.

Now let’s say you want to add a different icon next to each different type of file your website is linking to, so your website’s visitors know when they’ll get an image, a PDF file, a Word document, etc. This can be done by using an attribute selector:

a[href*='.jpg'] {
	background: url(jpeg.gif) no-repeat left 50%;
	padding: 2px 0 2px 20px;
	}

a[href*='.pdf'] {
	background: url(pdf.gif) no-repeat left 50%;
	padding: 2px 0 2px 20px;
	}

a[href*='.doc'] {
	background: url(word.gif) no-repeat left 50%;
	padding: 2px 0 2px 20px;
	}

In this example, we’ve used an attribute selector that will target all the links (a) whose href attribute ends (*) with .jpg, .pdf or .doc.

Notes on browser support
Apart from Internet Explorer 6, all major browsers support attribute selectors. This means that when you are using attribute selectors on your stylesheets, you should make sure that IE6 users will still be provided with a usable site. Take our third example: adding an icon to your links adds another level of usability to your site, but the site will still be usable if the links don’t show any icons.

2. Child selector

The child selector is represented by the sign ‘>’. It allows you to target elements that are direct children of a particular element.

For example, if you want to match all the h2 elements that are a direct child of your sidebar div, but not the h2 elements that may be also within the div, but that are grandchildren (or later descendants) of your element, you can use this selector:

div#sidebar > h2 {
	font-size: 20px;
	}

You can also use both child and descendant selectors combined. For example, if you want to target only the blockquote elements that are within divs that are direct grandchildren of the body element (you may want to match blockquotes inside the main content div, but not if they are outside it):

body > div > div blockquote {
	margin-left: 30px;
	}

Notes on browser support
Like the attribute selectors, the child selector is not supported by Internet Explorer 6. If the effect you are trying to achieve by using it is crucial for the website’s usability or overall aesthetics, you can consider using a class selector with it, or on a IE-only stylesheet, but that would detract from the purpose of using child selectors.

3. Sibling combinators

There are two types of sibling combinators: adjancent sibling combinators and general sibling combinators.

Adjacent sibling combinator

This selector uses the plus sign, ‘+’, to combine two sequences of simple selectors. The elements in the selector have the same parent, and the second one must come immediately after the first.

The adjacent sibling combinator can be very useful, for example, when dealing with text. Lets say you want to add a top margin to all the h2 tags that follow a paragraph (you don’t need to add a top margin if the heading comes after an h1 tag or if it’s the first element on that page):

p + h2 {
	margin-top: 10px;
	}

You can be even more specific and say that you only want this rule applied if the elements are within a particular div:

div.post p + h2 {
	margin-top: 10px;
	}

Or you can add another level of complexity: say you want the first line of the paragraphs of every page to be in small caps.

.post h1 + p:first-line {
	font-variant: small-caps;
	}

Because you know that the first paragraph of every post immediately follows an h1 tag, you can refer to the h1 on your selector.

General sibling combinator

The general sibling combinator works pretty much the same as the adjacent sibling combinator, but with the difference that the second selector doesn’t have to immediately follow the first one.

So if you need to target all the p tags that are within a particular div and that follow the h1 tag (you may want those p tags to be larger than the ones that come before the title of your post), you can use this selector:

.post h1 ~ p {
	font-size: 13px;
	}

Notes on browser support
Internet Explorer 6 doesn’t understand sibling combinators, but, as for the other cases, if your audience includes a small percentage of IE6 users, and if the website’s layout isn’t broken or severely affected by its lack of support, this is a much easier way of achieving lots of cool effects without the need of cluttering your HTML with useless classes and ids.

4. Pseudo-classes

Dynamic pseudo-classes

These are called dynamic pseudo-classes because they actually do not exist within the HTML: they are only present when the user is or has interacted with the website.

There are two types of dynamic pseudo-classes: link and user action ones. The link are :link and :visited, while the user action ones are :hover, :active and :focus.

From all the CSS selectors mentioned in this post, these will probably be the ones that are most commonly used.

The :link pseudo-class applies to links that haven’t been visited by the user, while the :visited pseudo-class applies to links that have been visited, so they are mutually exclusive.

The :hover pseudo-class applies when the user moves the cursor over the element, without having to activate or click on it. The :active pseudo-class applies when the user actually clicks on the element. And finally the :focus pseudo-class applies when that element is on focus — the most common application is on form elements.

You can use more than one user action dynamic pseudo-class in your stylesheets, so you can have, for example, a different background color for an input field depending on whether the user’s cursor is only hovering over it or hovering over it while in focus:

input:focus {
	background: #D2D2D2;
	border: 1px solid #5E5E5E;
	}

input:focus:hover {
	background: #C7C7C7;
	}

Notes on browser support

The dynamic pseudo-classes are supported by all modern browsers, even IE6. But bear in mind that IE6 only allows the :hover pseudo-class to be applied to link elements (a) and only IE8 accepts the :active state on elements other than links.

:first-child

The :first-child pseudo-class allows you to target an element that is the first child of another element. For example, if you want to add a top margin to the first li element of your unordered lists, you can have this:

ul > li:first-child {
	margin-top: 10px;
	}

Let’s take another example: you want all your h2 tags in your sidebar to have a top margin, to separate them from whatever comes before them, but the first one doesn’t need a margin. You can use the following code:

#sidebar > h2 {
	margin-top: 10px;
	}

#sidebar > h2:first-child {
	margin-top: 0;
	}

Notes on browser support

IE6 doesn’t support the :first-child pseudo-class. Depending on the design that the pseudo-class is being applied to, it may not be a major cause for concern. For example, if you are using the :first-child selector to remove top or bottom margins from headings or paragraphs, your layout will probably not break in IE6, it will only look sightly different. But if you are using the :first-child selector to remove left and right margins from, for example, a floated sequence of divs, that may cause more disruption to your designs.

The language pseudo-class

The language pseudo-class, :lang(), allows you to match an element based on its language.

For example, lets say you want a specific link on your site to have a different background color, depending on that page’s language:

:lang(en) > a#flag {
	background-image: url(english.gif);
	}

:lang(fr) > a#flag {
	background-image: url(french.gif);
	}

The selectors will match that particular link if the page’s language is either equal to ‘en’ or ‘fr’ or if it starts with ‘en’ or ‘fr’ and is immediately followed by an ‘-’.

Notes on browser support

Not surprisingly, the only version of Internet Explorer that supports this selector is 8. All other major browsers support the language pseudo-selector.

5. CSS 3 Pseudo-classes

:target

When you’re using links with fragment identifiers (for example, http://www.smashingmagazine.com/2009/08/02/bauhaus-ninety-years-of-inspiration/#comments, where ‘#comments’ is the fragment identifier), you can style the target by using the :target pseudo-class.

For example, lets imagine you have a long page with lots of text and h2 headings, and there is an index of those headings at the top of the page. It will be much easier for the user if, when clicking on a particular link within the index, that heading would become highlighted in some way, when the page scrolls down. Easy:

h2:target {
	background: #F2EBD6;
	}

Notes on browser support

This time, Internet Explorer is really annoying and has no support at all for the :target pseudo-class. Another glitch is that Opera doesn’t support this selector when using the back and forward buttons. Other than that, it has support from the other major browsers.

The UI element states pseudo-classes

Some HTML elements have an enable or disabled state (for example, input fields) and checked or unchecked states (radio buttons and checkboxes). These states can be targeted by the :enabled, :disabled or :checked pseudo-classes, respectively.

So you can say that any input that is disabled should have a light grey background and dotted border:

input:disabled {
	border:1px dotted #999;
	background:#F2F2F2;
	}

You can also say that all checkboxes that are checked should have a left margin (to be easily seen within a long list of checkboxes):

input[type=’checkbox’]:checked {
	margin-left: 15px;
	}

Notes on browser support

All major browsers, except our usual suspect, Internet Explorer, support the UI element states pseudo-classes. If you consider that you are only adding an extra level of detail and improved usability to your visitors, this can still be an option.

6. CSS 3 structural pseudo-classes

:nth-child

The :nth-child() pseudo-class allows you to target one or more specific children of a parent element.

You can target a single child, by defining its value as an integer:

ul li:nth-child(3) {
	color: red;
	}

This will turn the text on the third li item within the ul element red. Bear in mind that if a different element is inside the ul (not a li), it will also be counted as its child.

You can target a parent’s children using expressions. For example, the following expression will match every third li element starting from the fourth:

ul li:nth-child(3n+4) {
	color: yellow;
	}

In the previous case, the first yellow li element will be the fourth. If you just want to start counting from the first li element, you can use a simpler expression:

ul li:nth-child(3n) {
	color: yellow;
	}

In this case, the first yellow li element will be the third, and every other third after it. Now imagine you want to target only the first four li elements within the list:

ul li:nth-child(-n+4) {
	color: green;
	}

The value of :nth-child can also be defined as ‘even’ or ‘odd’, which are the same as using ‘2n’ (every second child) or ‘2n+1’ (every second child starting from the first), respectively.

:nth-last-child

The :nth-last-child pseudo-class works basically as the :nth-child pseudo-class, but it starts counting the elements from the last one.

Using one of the examples above:

ul li:nth-child(-n+4) {
	color: green;
	}

Instead of matching the first four li elements in the list, this selector will match the last four elements.

You can also use the values ‘even’ or ‘odd’, with the difference that in this case they will count the children starting from the last one:

ul li:nth-last-child(odd) {
	color: grey;
	}

:nth-of-type

The :nth-of-type pseudo-class works just like the :nth-child, with the difference that it only counts children that match the element in the selector.

This can be very useful if we want to target elements that may contain different elements within them. For example, let’s imagine we want to turn every second paragraph in a block of text blue, but we want to ignore other elements such as images or quotations:

p:nth-of-type(even) {
	color: blue;
	}

You can use the same values as you would use for the :nth-child pseudo-class.

:nth-last-of-type

You guessed it! The :nth-last-of-type pseudo-class can be used exactly like the aforementioned :nth-last-child, but this time, it will only target the elements that match our selector:

ul li:nth-last-of-type(-n+4) {
	color: green;
	}

We can be even more clever, and combine more than one of these pseudo-classes together on a massive selector. Let’s say all images within a post div to be floated left, except for the first and last one (let’s image these would full width, so they shouldn’t be floated):

.post img:nth-of-type(n+2):nth-last-of-type(n+2) {
	float: left;
	}

So in the first part of this selector, we are targeting every image starting from the second one. In the second part, we are targeting every image except for the last one. Because the selectors aren’t mutually exclusive, we can use them both on one selector thus excluding both the first and last element at once!

:last-child

The :last-child pseudo-class works just as the :first-child pseudo-class, but instead targets the last child of a parent element.

Let’s image you don’t want the last paragraph within your post div to have a bottom margin:

.post > p:last-child {
	margin-bottom: 0;
	}

This selector will target the last paragraph that is a direct and the last child of an element with the class of ‘post’.

:first-of-type and :last-of-type

The :first-of-type pseudo-class is used to target an element that is the first of its type within its parent.

For example, you can target the first paragraph that is a direct child of a particular div, and capitalize its first line:

.post > p:first-of-type:first-line {
	font-variant: small-caps;
	}

With this selector you make sure that you are targeting only paragraphs that are direct children of the ‘post’ div, and that are the first to match our p element.

The :last-of-type pseudo-class works exactly the same, but targets the last child of its type instead.

nly-child

The nly-child pseudo-class represents an element that is the only child of its parent.

Let’s say you have several boxes (‘news’) with paragraphs of text inside them. When you have more than one paragraph, you want the text to be smaller than when you have only one:

div.news > p {
	font-size: 1.2em;
	}

div.news > p:only-child {
	font-size: 1.5em;
	}

In the first selector, we are defining the overall size of the p elements that are direct children of a ‘news’ div. On the second one, we are overriding the previous font-size by saying, if the p element is the only child of the ‘news’ div, its font size should be bigger.

nly-of-type

The nly-of-type pseudo-class represents an element that is the only child of its parent with the same element.

How can this be useful? Image you have a sequence of posts, each one represented by a div with the class of ‘post’. Some of them have more than one image, but others have only one image. You want the image within the later ones to be aligned to the center, while the images on posts with more than one image to be floated. That would be quite easy to accomplish with this selector:

.post > img {
	float: left;
	}

.post > img:only-of-type {
	float: none;
	margin: auto;
	}

:empty

The :empty pseudo-class represents an element that has no content within it.

It can be useful in a number of ways. For example, if you have multiple boxes in your ‘sidebar’ div, but don’t want the empty ones to appear on the page:

#sidebar .box:empty {
	display: none;
	}

Beware that even if there is a single space in the ‘box’ div, it will not be treated as empty by the CSS, and therefore will not match the selector.

Notes on browser support
Internet Explorer (up until version has no support for structural pseudo-classes. Firefox, Safari and Opera support these pseudo-classes on their latest releases. This means that if what it’s being accomplished with these selectors is fundamental for the website’s usability and accessibility, or if the larger part of the website’s audience is using IE and you don’t want to deprive them of some design details, it’s be wise to keep using regular classes and simpler selectors to cater for those browsers. If not, you can just go crazy!

7. The negation pseudo-class

The negation pseudo-class, :not(), lets you target elements that do not match the selector that is represented by its argument.

For example, this can be useful if you need to style all the input elements within a form, but you don’t want your input elements with the type submit to be styled — you want them to be styled in a different way —, to look more like buttons:

input:not([type='submit']) {
	width: 200px;
	padding: 3px;
	border: 1px solid #000000;
	}

Another example: you want all the paragraphs within your post div to have a larger font-size, except for the one that indicates the time and date:

.post p:not(.date) {
	font-size: 13px;
	}

Can you image the number of possibilities this selector brings with it, and the amount of useless selectors you could strip out off your CSS files were it widely supported?

Notes on browser support
Internet Explorer is our usual party pooper here: no support at all, not even on IE8. This probably means that this selector will still have to wait a while before some developers lose the fear of adding them to their stylesheets.

8. Pseudo-elements

Pseudo-elements allow you to access elements that don’t actually exist in the HTML, like the first line of a text block or its first letter.

Pseudo-elements exist in CSS 2.1, but the CSS 3 specifications state that they should be used with the double colon ‘::’, to distinguish them from pseudo-classes. In CSS 2.1, they are used with only one colon, ‘:’. Browsers should be able accept both formats, except in the case of pseudo-elements that may be introduced only in CSS 3.

::first-line

The ::first-line pseudo-element will match the first line of a block, inline-block, table-caption or table-cell level element.

This is particularly useful to add subtle typographical details to your text blocks, like, for example, transforming the first line of an article into small caps:

h1 + p::first-line {
	font-variant: small-caps;
	}

If you’ve been paying attention, you’ll know that this means the paragraph that comes immediately after an h1 tag (‘+’) should have its first line in small caps.

You could also refer to the first line of a particular div, without having to refer to the actual paragraph tag:

div.post p::first-line { font-variant: small-caps; }

Or go one step farther and target specifically the first paragraph within a particular div:

div.post > p:first-child::first-line {
	font-variant: small-caps;
	}

Here, the ‘>’ symbol indicates that you are targeting a direct child the post div, so if the paragraph were to be inside a second div, it wouldn’t match this selector.

::first-letter

The ::first-letter pseudo-element will match the first letter of a block, unless it’s preceded by some other content, like an image, on the same line.

Like the ::first-line pseudo-element, ::first-letter is commonly used to add typographical details to text elements, like drop caps or initials.

Here is how you could use the ::first-letter pseudo-element to create a drop cap:

p {
	font-size: 12px;
	}

p::first-letter {
	font-size: 24px;
	float: left;
	}

Bear in mind that if you use both ::first-line and ::first-letter in the same element, the ::first-letter properties will override the same properties inherited from ::first-line.

This element can sometimes produce unexpected results, if you’re not aware of the W3C specs: it’s actually the CSS selector with the longest spec! So it’s a good idea to read them carefully if you’re planning on using it (as it is for all the other selectors).

::before and ::after

The ::before and ::after pseudo-elements are used to insert content before or after an element’s content, purely via CSS.

These elements will inherit many of the properties of the elements that they are being attached to.

Image you want to the words ‘Graphic number x:’ before the descriptions of graphs and charts on your page. You could achieve this without having to write the words ‘Graphic number’, or the number itself yourself:

.post {
	counter-reset: image;
	}

p.description::before {
	content: 'Figure number ' counter(image) ': ';
	counter-increment: image;
	}

What just happened here?

First, we tell the HTML to create the ‘image’ counter. We could have added this property to the body of the page, for example. Also, we can call this counter whatever name we want to, as long as we always reference it by the same name: try it for yourself!

Then we say that we want to add, before every paragraph with the class ‘description’, this piece of content: ‘Figure number ’ — notice that only what we wrote between quotes will be created on the page, so we need to add the spaces as well!

After that, we have counter(image): this will pick up the property we’ve already defined in the .post selector. It will by default start with the number one (1).

The next property is there so that the counter knows that for each p.description, it needs to increment the image counter by 1 (counter-increment: image).

It’s not as complicated as it looks, and it can be quite useful.

The ::before and ::after pseudo-elements are often only used with the content property, to add small sentences or typographical elements, but here it’s shown how we can use it in a more powerful way in conjunction with the counter-reset and counter-increment properties.

Fun fact: the ::first-line and ::first-letter pseudo-elements will match the content added by the ::before pseudo-element, if present.

Notes on browser support
These pseudo-elements are supported by IE8 (not IE7 or 6), if the single colon format is used (for example, :first-letter, not ::first-letter). All the other major browsers support these selectors.

Conclusion

Enough with the boring talk, now it’s time for you to grab the information on this post and go try it for yourself: start by creating an experimental page and test all of these selectors, come back here when in doubt and make sure to always refer to the W3C specs, but don’t just sit there thinking that because these selectors aren’t yet widely supported you might as well ignore them.

If you’re a bit more adventurous, or if you’re not afraid of letting go of the past filled with useless and non-semantic classes and ids, why not sneak one or two of these powerful CSS selectors into your next project? We promise you’ll never look back.

References

• CSS 2 Selectors — W3C
• CSS 3 Selectors Level 3 — W3C
• Comparison of layout engines (Cascading Style Sheets) — Wikipedia
• Generated content, automatic numbering, and lists — W3C

Further Resources

• Keeping Your Elements’ Kids in Line with Offspring — A List Apart
• Selectutorial – CSS selectors
• A Look at Some of the New Selectors Introduced in CSS3
• CSS 2.1 selectors, Part 1 and Part 2
• CSS 3 selectors explained
• CSS selectors and pseudo selectors browser compatibility
• 10 Useful CSS Properties Not Supported By Internet Explorer
• Styling a Poem with Advanced CSS Selectors

Related posts

You may also be interested in the following articles:

• The Definitive Guide to Using Negative Margins
• 10 Useful CSS/JS-Coding Solutions For Web-Developers
• Take Your Design To The Next Level With CSS3
• Adaptive CSS-Layouts: New Era In Fluid Layouts?

About the author

Inayaili de León is a Portuguese webdesigner. She has a true passion for webdesign and front-end coding, and loves beautiful and clean sites. She lives in London (and blogs about it), and enjoys pizza and ‘skyping’ her cats. You can see more of her articles at Web Designer Notebook and follow her daily ramblings on Twitter.

© Inayaili de Leon for Smashing Magazine, 2009. |
Permalink |
2 comments |
Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine

Post tags: CSS, selectors

“

(Via Smashing Magazine.)