Lea: The Unity design process (and how you can play a part in it) [LWN.net]

Lea: The Unity design process (and how you can play a part in it)

Posted Feb 23, 2012 18:48 UTC (Thu) by sorpigal (subscriber, #36106)
In reply to: Lea: The Unity design process (and how you can play a part in it) by khim
Parent article: Lea: The Unity design process (and how you can play a part in it)

Except that Joel was not talking about the same thing. To quote from a just before your quote:

When politics demands that various nontechnical managers or customers "sign off" on a project, give them several versions of the graphic design to choose from.

We're not talking about getting a PHB to put his stamp of approval on something so you can start working on it, we're talking about feedback from users (who are often, remember, *programmers*, and non non-technical people!)

Want to keep quoting Joel? I know you'll like this bit:

If there's one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it's this: Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it.

Ahh, vindication! GNOME users don't know what they want so their complaints are irrelevant anyway. Joel continues:

Instead, assume that you're going to have to build something anyway, and the customer is going to have to like it, but they're going to be a little bit surprised. YOU have to do the research. YOU have to figure out a design that solves the problem that the customer has in a pleasing way.

Oh wait... did you figure out how to solve the user's problems in a pleasing way? Apparently not if, after the software is 'finished', they begin screaming at you that it's not solving their problems.

Joel's often an insightful fellow but using some out of context quotes of his is wrong, especially when they say almost the opposite of what you want them to say.

to post comments

Lea: The Unity design process (and how you can play a part in it)

Posted Feb 23, 2012 20:10 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

We're not talking about getting a PHB to put his stamp of approval on something so you can start working on it, we're talking about feedback from users (who are often, remember, *programmers*, and non non-technical people!)

It basically the same thing. Joel even says so directly in other place:

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

This doesn't mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy: it's great to give people choices: by all means, the more the merrier. And there's another category of choice that people like: the ability to change the visual look of things, without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.

Oh wait... did you figure out how to solve the user's problems in a pleasing way? Apparently not if, after the software is 'finished', they begin screaming at you that it's not solving their problems.

No objections from me. GNOME people completely blew up a lot of UI decisions (or at least their approach to the introduction of said UI decisions), but that's completely separate question from the question of the amount of configuration allowed.

Lea: The Unity design process (and how you can play a part in it)

Posted Feb 23, 2012 20:26 UTC (Thu) by dlang (guest, #313) [Link]

There's a big difference between forcing a user to make a decision and allowing the user to make a decision.

I agree that having a desktop environment that put the user through a long Q&A session to have them select the options for their desktop would be a disaster.

but removing the option for the user to change something that bugs them is just as bad.

People can easily ignore options. firefox about:config has hundreds, if not thousands of options (plus there are other things you can tweak in config files), most firefox users aren't even aware that about:config even exists, so those options don't hurt the user.

remember that every plugin/extension is an option, so by allowing them to exist you are creating a huge number of additional 'options' or 'decisions' for the user, probably far more options (and harder decisions) than if the features were included to begin with.

Provide the best defaults that you can, but provide the options to allow people to override the defaults.

Even better, if you can gather information about what defaults get overriden frequently, look into what is getting changed and why, and either make it easier to change that sort of thing, figure a way to guess the right setting for a user, or consider changing your default.

Lea: The Unity design process (and how you can play a part in it)

Posted Feb 28, 2012 15:06 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

I still cannot agree that Joel is saying what you think he's saying

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

Note my emphasis. In cases where the user has to make a decision, he's right. In cases where you ask the user to make a decision, he's right. Here we have a case where the user is asking to make a decision.

[snip]but that's completely separate question from the question of the amount of configuration allowed.

As GNOME3 fans will tell you, absolutely any configuration is allowed (via extensions). The question is what level of customization to support by the inclusion of knobs and how easy it is to find those knobs. I say more knobs is better, and put them somewhere a curious and determined user will be able to discover them. If they'd done that the UI decisions may not have been so hard to cope with.