Four Words for Funpidgin (Updated w/ comments)
I’ve been meaning to comment about this, and was reminded by today’s Coding Horror.
Funpidgin, a fork of the popular Pidgin Instant Message client, was created when Pidgin developers had diverging opinions on how the input box of the chat window should resize by default. According to the Funpidgin website, What makes us different from the official client, is that we work for you. Unlike the Pidgin developers, we believe the user should have the final say in what goes into the program.
Four words I have to say to Funpidgin: Users Are Not Designers.
This attitude takes participatory design to all-new (and very dangerous) level. You go from user-centered design: keeping users in mind while designing a product, to user-directed design: catering to every users’ whim without consideration of the consequences (at least, users who know how to use mailing lists and bug trackers, who are not representative of a broad user audience for an instant messenger client).
What you end up getting is this:
Good luck guys.
– Updated 2008-05-17 00:30 –
Besides all the things I obviously never said nor remotely hint to, between the lines or not, it seems like pantsgolem is the only one who Got It. This isn’t about the [Fun]Pidgin product or the decision to fork, or the design decisions the projects made concerning the text widget. It is about the fundamentally flawed development process Funpidgin has adopted in the name of usability and design and their ignorance (or ignore-ance if they just choose to ignore it) of this decisions implication to the project.
When a project declares that users will have the final say in functional requirements, it is on its way down a slippery slope. Sure, there may be some good examples where a problem was easily solved and a user had a good idea, but what about all the ideas that are obviously a bad design decision? What happens when you have users who have conflicting opinions? Or users who have no knowledge of other users, cases, and scenarios beyond themselves? This is why users are not designers. Even if the real designers are users of a product, they are trained to be objective. They don’t replace the user with themself, but they are empathetic towards the user.
Also, what about the developers? Don’t they want retain the right to create and preserve a certain kind of experience? What if the project wants to focus on a specific user type, but a minor user type requests a feature that will disrupt that group? What happens when developers start to ignore certain ideas and only take the ones they like? Aren’t they acting as the designer and preventing the user from playing designer?
By adopting this mission statement, Funpidgin has set itself up to make some possibly fundamentally poor design decisions. I don’t care about the project itself or the design decisions they’ve made. What I do care about is that the rest of the open source community learn something from it so we don’t repeat these mistakes.
Of course I want to see users participating in open source projects and providing their feedback, that is the basic principle of participatory design. Of course I want to see developers thinking of users besides themselves, that is the basic principle of user-centered design. What I don’t want to see is development driven by users who don’t understand the problem they are experiencing or know who else they will be effecting with their change. We don’t have developers who fully understand how different users of their software might effect each other, and yet we expect users think beyond themselves and do this?
User feedback is important. Open source celebrates the fact that users can take an active part in the community by reporting bugs and driving the development of features through requests. But users are just an indicator of how well we are doing. We want their feedback, but we also want to do what’s best for them.
seele :: May.17.2008 :: Design, General, Open Source :: 42 Comments »
