Saying No in Software Design
A post on macSB made me stumble across a couple of nice articles on usability in open source software. They're not only relevant to open source, but also to any other software design. Often users ask for a particular feature, and then a programmer just has to know when to say 'no' and when to say 'yes, but...'
A programmer can't just add every requested feature, and a programmer can't just leave design up to the users. Designing software is the programmer's job. Generally, users are exceedingly smart people, with lots of qualifications any of us can only dream of, but few of them are software engineers or user interaction designers. They needn't be. The programmer has to accept user feedback and do some more work on it to turn it into a design that is not only possible to implement, but that also accounts for other factors the user may not have been aware of when he made the request.
But just like a typical user is not a programmer, a programmer is rarely a typical user. Some of the articles below elaborate on both of these aspects. The former is generally characterized as needing the ability (or the hierarchy, or the infrastructure) to say 'No', and the latter is in one of these characterized as "Designing for Aunt Tilly". I'll link to each article, then make a few comments. They open in a new window, so feel free to read them and then come back.
10 Ways to make OSS more humane
While this article is a nice, short introduction with some good examples and 5 DO's and 5 DON'T's, it suffers from being a little imprecise and simplifying the problem somewhat. For example, a coherent design is needed, yes, and committees sometimes have to make compromises that end up making nobody happy, true, but still I wouldn't make a rule like "Get a benevolent dictator".
You don't want someone who bosses people around, even with the best intentions. Instead, you want a professional servant of the people who is so well-respected that people will just listen. You want a person with qualifications. Be it just that this person has shown before that they can design an application, be it that this person has professional credentials as a lead programmer, interaction designer, executive producer or whatever else the project might ask for at a particular time.
You need someone that people trust. But of course you also want someone who is worthy of that trust, who is willing to stand back and listen to users or contributors, and is able to see and accept what good they bring to the project, but who will then be able to make the unpopular decisions, too, and make sure they're followed through.
My guess is that Jono DiCarlo would agree with that, and that this is what he meant by "benevolent dictator". After all, someone may be needed as a tie-breaker, because even an arbitrary decision from a dictator (or better, arbiter or ombudsman) is better than everything stopping in its tracks because the team can't come to a decision. But I've seen a project fail because its benevolent dictator decided things with the best of intentions, but just didn't have the trust and respect needed.
As I mentioned above, most users have other qualifications than being programmers, or system administrators or whatever. They are trying to get actual work done, and our software is just a tool to do that. They don't have fun installing it, or configuring it, or activating it on every install, or writing scripts to schedule a recording of a TV show.
They want to see a great 5-year story arc, or write a great novel, create a funny movie about comic book characters. Hence, our programs should respect and support the user, and get out of the way otherwise. The user should be free not to have to learn about network interfaces and determining the computer's IP address just to watch a movie on their iPhone. Or, as ESR so aptly put it, the user should have the luxury of ignorance of all the hard work your program is doing behind the scenes.
Eric S. Raymond's article has its own flaws, but John Gruber summarized them much better than I could do. Because ESR's article proves itself: ESR is the one-eyed among the blind, just like we are as programmers: The task he's doing, and where he demands that it be made to suit Aunt Tilly, is a task Aunt Tilly would never try to do. That doesn't mean Eric's point is wrong, but it shows us that we can't rely on ourselves to assess usability for typical users. We'll just have to remember test our designs on actual users occasionally.
Rise of Interface Elegance in Software
Steven Garrity does a nice summary of the important points again, and adds that designing for real users is different from designing for the stereotypical "power user" or doing dumbed-down versions for some imaginary "average user". If we design for discoverability, ease of use and ease of learning, we don't need various "user levels" or "Advanced" areas that can be uncollapsed.
If we provide smart and sensible defaults, and keep unnecessary or conflicting options out of the UI, we can create applications that do the right thing for users just beginning to learn our programs, while once they become more comfortable with our programs, they will start looking for and discover additional options. And at this time, they will be able to also understand these options. We don't have to design for several users at the same time, we essentially design for one user progressing through time, we design for the fourth dimension.
But this isn't done by hiding buttons or shortening menus, this is done by hiding things in plain view, just at a little distance. The most-used, most important things are in the main window, in plain view. Some bigger, some smaller, all in an order that fits with the user's reading order as well as with the order in which the user will probably need them (without enforcing this order, of course).
Secondary things go in popups and other menus, and things that are used rarely or not by everyone can be put in secondary windows that have to be explicitly shown, but which are obvious to a person looking for this feature (like the Apple DVD Player's "zoom" feature, which sits in a small floating palette, and which lets you see more of your image, bigger on the screen, but with the black bars cut off).
ESR follows up along similar lines in his follow-up to Luxury of Ignorance.