See: http://blogs.testbit.eu/timj/2005/12/14/14122005-never-reject-a-feature/ (page moved)
I didn’t mean to engage in the flamage about the printer dialog or usability design issues with Gtk+’s new file chooser, but i do feel that a few things should be pointed out in this context nonetheless. In particular, I’d like to respond to Dave Neary (bolsh), quote: “Linus is irrelevant”. There’s an important thing to note here: Linus opinion on GNOME is relevant!
For a single very important reason: Linus is a GNOME user.
Every GNOME user counts. Without exception. Yes, i mean it.
This is the reason we care about accessibility even though it focusses on a user group that can be regarded a minority by sheer usage figures. If you start to make decision only for an assumed “majority of users”, you are going the wrong path with a probability so high you may as well call it a guarantee.
Firstly, programmers are notoriously bad at assuming what the “majority of users” want, and often even what that “majority” is. As Linus put it: “the _vast_ majority of people are part of a specific minority when it comes to something”. As a result, it’s often very hard to tell what your users want or even who they are. The only cure from that is listening to your users, their requests and – if required – poll feedback. If you think these are exclusive programmer problems, think again. Without a specific case study at hand, guesses by usability experts usually aren’t any better. And marketing experts face the same problems, they also need to figure who their (possible) users (customers) are and what they could (possibly) want. The main difference between marketing people, usability experts and programmers is that the former two groups actually make evaluations and studies, they test or ask users and try to find out about their needs and expectations. They do the “feedback polling” just mentioned. (If your project allows for feedback polling to be carried out as a proper usability study, that is always better than just asking the user what he thinks he might need.)
Secondly, disregarding any group of users by marking them as irrelevant is a guarantee for bad perception. There is no way around this, you have – by definition – just made sure that some users are going to be dissatisfied and feel mistreated. Now think about your own reaction when you feel that way. Do you shut up? Do you engage in improving the particular project? Do you try to work out a consensus with someone attempting hard at ignoring you?
Thirdly, disregarding any user needs is not the logical thing to do from an impetus perspective. For that, think of the user request as a force towards a specific direction. Arguing against the request can be viewed as a resistance to the force. As a programmer or project leader, you’re in control of that resistor. If you’re clever, you try to direct that force to work for you, e.g. “We could integrate feature XXX if we had a patch that integrated it according to specification XXX-spec.” The force may be not big enough to be utilized, i.e. the user walks away; fine, without knowing a person really well, you couldn’t have told its strength in advance anyway. Or it might be big enough, you get your patch (maybe from the user directly or maybe by him hiring someone to do the work, etc), you work out the details and you can integrate it into the project. In the end, everyone wins that way (I’ll get to why this doesn’t need to worsen usability).
Alternatively, you can be ***not-so-clever***: You could argue that the feature will never be integrated, for whatever reason, and stand by that point. That is effectively putting the resistor antipodal to the force. Be assured, it’ll hurt both sides no matter how polite you are since this situation strives for conflict maximization.
To be fair, this is a simplification to some extend, sometimes the user simply needs to be told the proper way to achieve something or be kindly reminded of the manual. I have faith in the ambitious reader to tell this difference though ;)
As an interesting side note, let me tell you that the not-so-clever branch of the impetus view can explain forking amongst other things. Consider a force (the user(s)) significantly stronger than the resistor (the blocking developer). There are basically three possible outcomes of this:
1. Argumentation goes on until the developer gives up. Depending on the project structure, various things can happen, the developer might resign, or a patch gets past him by approval of other project developers. The user may (longer term) even become a more active contributor.
2. If the developer is in full control of the project and doesn’t give up, the user can re-aim his energy. He may provide significant contributions to a competing project (maybe a proprietary one), or he may direct his energy against the project by generating bad PR and spreading FUD. Now remember that we assumed above that this force was significant, measured in relation to the developers energy. Significant bashing, hindering the project in various ways, will be the result and can be observed for quite some project/user combination.
3. Let’s say our user who has a significant urge to see his problem XXX solved is technically skilled. He might start his own program/project which solves XXX. However if the project is large enough, a fork will often provide the only viable alternative. So if you ignore enough users especially over topics they deem important enough (they don’t need to appear important to you), you increase likeliness of a project fork, or maintenance of a customization patch set for your project or similar variants thereof.
Now i do realize that not everyone in the GNOME camp wants to ignore and upset the majority of users or user minorities (be warned that “user minorities” may still represent a strong force ;)
So let me plead that we attempt to reduce this where it comes up nevertheless. As things stand, we have too many dissatisfied users currently and can observe the various outcomes described above. To address this, we simply need to strive for fulfilling more user requests, e.g. by accepting more patches that have been rejected as “featurism”, and by re-enabling or exposing existing features (gconf-editor gives you a hint on what could be done already if we allowed more configurability).
And let me side-line with Linus on trading features for usability. Basically, this can’t be done, because usability can only be a second grade concern. If you don’t have features or leave them out, you’ve ruined your usability right away, not improved it. If you have usability problems because of many features, yes that is a serious concern but still second grade. There are various ways at dealing with this, for instance by improving the structure of your preferences or by introducing user levels (e.g. early versions of Nautilus did this) or “Advanced” features (take the mozilla tab extension preferences as an example) or a number of other measurements. The reason there is not “The Definitive Answer” to this currently, is that usability in various aspects is still a very active research topic (let’s talk about this again 100 or 200 years from now). Taking features out is not amongst the set of these usability measurements, because it’s essentially a first grade decision about the program scope and solution space constituted by user desires, so it will definitely get you into the problem chain presented under “Thirdly,” above.
In essence:
In order to avoid various kinds of problems for your users and project, NEVER REJECT A FEATURE but either implement what’s requested or ask for an implementation (nothing simpler than just saying: “We accept patches.”)
Update: PBor replied in his blog and suggested a title change for this post to “Never reject a feature request!“, which I much agree with in retrospect.