1. Introduction
Recently, the Funpidgin fork of the Pidgin instant messaging client project began based on disputes related to input field resizing issues. Apprently, two groups saw two sides of the same coin and felt that this would be worth forking the project over. Funpidgin, working according to a “we work for you” idiom, felt that the user should have the choice of behavior for the client, which the Pidgin project did not agree with.
No statement is being made about the stubbornness of the Pidgin loyalists. They went through painstaking trouble to make sure that the behavior of the client is intuitive and simple. Blogs, such as obso1337.org, did get a little up-in-arms about this attitude, claiming that users are not designers, and that they don’t think that the uninitiated masses should have a say in the development of a large-scale project.
This attitude [that users are designers] 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). [Author's emphasis] [1]
2. Leadership
The underlying principle behind this message is fair: users that make up the minority or the unintended demographic might not be the best candidates for directing the design and development a project. That is understandable, since the project should have direction of its own. That does not mean, however, that they should have no say.
It is the idea that users are going to inherently work in their own best interest, forgoing the betterment of the overall project, that is irksome. Allowing users with different interests to have say in development can only make the outcome more diverse; nothing dictates that the “too many chefs” metaphor will produce a proverbial Rube Goldberg machine.
3. Rules, or a Reasonable Facsimile
Being an immature field, “computer science”, by and large, does not have the easiest time prescribing or adhering to a set of rules by which to operate. Organizations such as the ACM and IEEE do have codes of ethics by which they attempt to regulate their actions.
Taking the ACM, for instance, we find the following:
3.4 Ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements.
Current system users, potential users and other persons whose lives may be affected by a system must have their needs assessed and incorporated in the statement of requirements. System validation should ensure compliance with those requirements. [2]
Note that no mention is made about the majority or minority, the target audience or the outliers. Simply put, all current and potential users should have their needs met. This means that, in essence, all users are developers, because it is the job of developers to listen to and satisfy the needs of those who will be using a given system.
This is the servitude into which developers enter. Needs of users outweigh the vision of the leader, outweigh that which is easy, outweigh petty bickering about text input fields, and outweigh the ridiculous notion that users are incompetent. Designers and developers must understand that they are the minority in their own project, and that the users are the ones who will crucify those who ignore their concerns.
4. Resources
- Paul, Celeste L. May 2008. Four Words for Funpidgin. http://weblog.obso1337.org/2008/four-words-for-funpidgin.
- ACM. Code of Ethics. http://www.acm.org/about/code-of-ethics.
