08 June 2008

Arguing with users over what they want

I wrote a whole bunch of this a long time ago when I stumbled across the debate that resulted in the FunPidgin (apparently now Carrier) fork of Pidgin. As their website puts it, "Unlike the Pidgin developers, we believe the user should have the final say in what goes into the program."

If you've missed this whole debate (likely even if you use Pidgin), it started with this bug report for Pidgin. The problem was stunningly simple: in the new version of Pidgin, the input text area automatically resizes itself. This is fancy and neat, but it also can't be sized larger than about 4 lines of text, which makes a lot of people sad, and some people find the auto-resizing jarring and unpleasant. This massive support ticket is basically a huge argument between the users and the developers about whether users want this feature or not. Seriously, a whole group of users telling the developers they want something, and the developers telling them they're in some way addled and don't really want it at all.

If your users want a feature, unless it's too difficult or time-consuming to write, you should add it. Your users shouldn't have to defend or justify why they need something, that's ridiculous; if they say they need it, they need it, and developers saying "no, you really don't want that" is absurd. Users have better things to do than sit on your bug tracker begging for you to implement something you've already written; obviously they want this feature.

I've always been of the opinion that if users want two competing ways of doing something it should be an option, which I know isn't a universally accepted view -- I might go so far as to say it's the minority view. I like the ability to customize how my programs work, since usually I don't like the defaults. Trillian was spectacular at this, and it's still my favorite IM client of all the ones I've tried; every single time I disliked something there was a preference to change exactly that. The pidgin developers do not believe this; they state repeatedly that they want a "better" (they frequently put the quotes around it too, like they're mocking themselves) solution than adding a preference. That's great and all, but either find one or give us the choice back. There might be a better solution than adding a preference, but adding a preference is still a better solution than telling a section of your userbase to go fuck themselves. The developers even mock the users in some of the posts, asking why they're not clever enough to write a plugin to do this. Is this supposed to be some sort of battle between developers and users, where developers change something and then taunt the users to try and change it back? I know lots of users don't like preferences; personally, I don't know why they can't just ignore them them, but apparently the mere fact that options exist bothers them in some way. Nonetheless, the users saying that they want an option and the developers telling the users that the users don't want an option is so obviously ridiculous that I can't believe this is still going on.

This quote was particularly amusing; it makes me think maybe the developers are missing the point completely: "it proved to be impossible to get both manual sizing and automatic resizing to work at the same time". Really? That's like saying "well, we tried to let the user set the size manually, but that damn automatic sizing kept automatically sizing". Obviously they can't work together, it has to be one or the other. Almost like it should be the user's choice. Like some sort of "preference" or something. They should have a dialog for those. I loved this solution: "What if manual sizing is disabled when automatic sizing is enabled?" Maybe it's just that this seems way more obvious to me than it apparently is to other people if this was actually considered ground-breaking enough to post, so I'll lay out my fairly brilliant solution to this problem in hopes of merging: Have an "automatic input resizing" checkbox. When it's checked, the input box auto-resizes. Manual resizing does not work. When it's unchecked, the box can be manually resized. Auto-resizing does not work. If anyone needs further clarification, I will send them a truth table

I dislike the notion that developers need to protect the silly users from themselves and not give them an option that deep down the developers are confident users really don't want. This is very much a Windows point of view.

19 comments:

Jonathan Feinberg said...

"If your users want a feature, unless it's too difficult or time-consuming to write, you should add it."

Unless, of course, you want to have a well-designed, usable system.

You can't add a feature except at the expense of any number of things such as simplicity, reliability, consistency, a user's ability to understand the data model, etc.

I agree with you that to say "you don't really want it" is bogus; I think "I don't want to compromise the design" is a much better answer.

Michael Mrozek said...

Good point, that sentence overgeneralized the design process, but I tend to feel developers focus too much on simplicity at the expense of adding things users want. And in this case, hating the Pidgin developers is still an option because we know this doesn't compromise the design: it was an existing design element they broke with a new feature

not a real blog said...

Hmmm. Sometimes users ask for something when they really don't know the root problem. For example, my beta testers asked for an Undo for a game I was making. Upon studying them, I realized the root problem was it was too easy to make mistakes. I fixed that, and the requests for Undo went away.

Here's a more detailed case:

http://blog.hanfordlemoore.com/2007/04/16/dont-do-what-your-users-say

JDB said...

There is a bit of fallacy in taking the people submitting this particular bug report as the user base. Logically we would expect that only users who found it to be a problem would end up in that discussion thread; thus we can not expect that to be an unbiased 'vote'.

Anonymous said...

Simply adding a feature because your users asked for it is a really bad idea. You must understand *why* they need it to fully understand what they really want. Your users may say "I need a way to turn X off". OK. But *why* do they want to do that? It's not rude to ask and dig in. Really understanding the crux of your user's problem will help you develop a better product. Just literally doing what your users ask for all the time will lead to a product with little cohesion and lots of confused users.

Don't fight with your users, but really dig in and figure out what they want and why they want to do it. The "why" part is by far the most important.

Anonymous said...

You say that you should give users what they want - then when some users say "I want it to work without me having to interpret pages and pages of options" you say that you don't understand why they're not happy.

Basically, you can not win this - no matter which users you make happy, someone else won't be happy.

And the reason why they hate options is that soon you end up with two dozen tab sheets with 50 options each, and noone can use the application until they learn what each option does and what effect it has on all the other options.

The ultimate option dialog is a blank document and a compiler - anything less than that and you have to make some decisions.

This particular case may have something to be said for user configuration, for all I know, but if your first resort is "don't decide, make the user decide" then you're doing something wrong. That should be the last resort, and only if making the user think about it is a greater benefit than making the decision yourself.

Anonymous said...

Throwing in a feature just because your users want it assumes the users know what they want.

As stated above by someone else, it usually a good idea to find out WHY people want something. That's called identifying the PROBLEM. Next, it's up to you to decide on a SOLUTION, given the parameters of your project and reality.

Like Mr Ford said: "If I'd asked my customer's want they wanted, they would have said a faster horse." Ford should also have been asking deeper questions about the PROBLEMS they wanted to solve, but it illustrates my first point, and heck, he came up with a pretty good (game-changing) solution.

Anonymous said...

The decisions about what a program does HAVE TO BE MADE. The only questions is WHO MAKES THEM. In this case it's resizable, or it isn't. Either the user does with preferences, or the developer does with the options hard coded in the source. Even if the option to manually size it is removed from the code, the removal represents a hard-coded decision. The developers want to retain control of the decisions on how the software behaves and the users believe it should be up to them. We know who will win the battle. It's like expecting wealthy Senators to vote to increase their own taxes so they can decrease yours. Ya, right.

Bryan said...

'Users' is a self selecting group. Simply from the fact they were using the software you can assume a bias towards how things were over what they have changed to be. It's not just the current users who need to be considered though, but all potential future users.

Anonymous said...

"it usually a good idea to find out WHY people want something."

How about, because I want to be able to look at what I wrote all at once before I send it? When sending code samples, PGP messages, etc., it's helpful to me to be able to see the monolithic text to make sure the formatting and everything looks right. Scrolling through all the lines isn't very useful to me.

Anonymous said...

"Simply from the fact they were using the software you can assume a bias towards how things were over what they have changed to be."

No you cannot assume that at all. Think about that for one minute. By your reasoning, you can assume that current users of Pigin prefer its new behavior. A patently absurd position to hold. By your definition, you can assume that users prefer never to see improvement in software. Heh. Users cry out for change in their software every day. Developers just don't always like the changes that are requested.

What users do resist, and strongly, is removal of features or control. If something was possible that isn't possible any longer, that's bad. Taking away an application's flexibility isn't a "feature", it's a design flaw.

Anonymous said...

The Pidgin developers are the biggest douches I have ever encountered, and I have traveled the entire world and have experienced a whole panoply of massive douches.

-Ibod Catooga

Anonymous said...

Taking away an application's flexibility isn't a "feature", it's a design flaw.

This is why Seamonkey is so much more popular than Firefox.

The Pidgin developers are the biggest douches I have ever encountered...

So you've never used anything from JBoss?

shevy said...

I totally disagree. No matter how idiotic an user is, a genuine user opinion is always right in regards to usability for something.

To this day I want Gimp to use just one window and not spawn many windows.

I do not get an easy way to do this, so the developers imposed their point of view upon me. This arrogance in general makes me sad.

If things retain customizable and flexible there is no problem. If developers whine that this creates maintainence problems I can only laugh and stick to developers that remain flexible.

Kevin Gamble said...

That's the key, "genuine user". In my experience it's almost always a non-user who is insisting that the users needs some new feature.

Anonymous said...

There are some very good User Experience Processes available now to help us make more informed choices.

We can identify user types and document them with Personas. We can model user mindsets (Mental Models), typical interaction patterns (User Journeys), skill levels, and motivations when using a UI (Affordances come into play here). This information can be derived and understood using engineering principles similar to SSADM. Combined with analytics from Usability tests and 'live' users we can assess which features suit their needs without having to rely on direct requests from users, personal opinion, developer intuition or arbitrary requests from senior management.

Anonymous said...

I strongly disagree with the following statement: "
If your users want a feature, unless it's too difficult or time-consuming to write, you should add it."
.

This is the golden road to the most inept bloatware ever built. Does "Nero Burning ROM" ring a bell here ?

You should not ask users what they want or at least you should regard that feedback with a healthy dose of skepticism. You'd rather look at what your users do.

Anonymous said...

This blog entry is a nice counter-point to your entry (and summarizes some of the above comments as well).

Anonymous said...

One way to solve this would be to create an auto-resize functionality which actually works nicely. Off the top of my head, I'd consider:
- Wide margins on the top and the bottom. It's easier on the eyes.
- Fluid movement when resizing. Ditto.
- Some default minimum height other than 1 line. Avoids resizing until the user has actually written quite a bit.
- Scroll bar by default or popping up outside the text field. Don't you hate it when the text is restructured because the scroll bar pops up and takes away some of the horizontal space? This is probably a general usability criterion: Make sure input stays still as long as the user is editing it.
- Resize increments other than 1 line. I'd probably go for something like doubling the line count every time a scroll bar would normally appear, but limited so that borders never reach outside the screen, and the text field never moves.
- With regards to the last point, resize the input field vertically when moving the window, as long as there is more input than can fit on the screen.

I think it's time to check the Pidgin enhancement requests...