obso1337.org

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 :: 44 Comments »

I hadn’t heard or seen anything from the Kopete devs yet, but I did ping Matt earlier this week to help spread the word to the rest of the project. Remember, this is an activity for you the developers, not me. I make myself available to answer questions and facilitate discussion, but the purpose of the user research profiles is to get developers more aware about their users. I will be at UDS next week and will be checking up on the Kopete User Research Profile once I get back.

seele :: May.15.2008 :: Asides, KDE/Kubuntu, Usability :: Comments Off

They call it a feature, but it’s really just a pain in the ass.

seele :: May.14.2008 :: Asides, Design, Humor :: Comments Off

Updates on current KDE User Research Profiles:

Plasma User Research Profile: A lot of good stuff came out of the Plasma Interviews and the work from Tokamak. I’d like to see more of this written up and discussed in public.

Both the Okular User Research Profile and Gwenview User Research Profile have some good stuff in their profiles. Remember that these profiles grow with the project, and as you expand your scope or add/change functionality, the profiles must be updated to remain useful.

This week, I would like to call on Kopete to begin working on their User Research Profile.

Instant messaging is an activity that nearly every type of user participates in and Kopete is one of the best instant messenger applications out there. But because Kopete has such a broad audience, it makes it that much more important to get all of the user types and use cases/scenarios documented. As always, ping me if you need help getting started.

seele :: May.07.2008 :: Design, General, KDE/Kubuntu :: 13 Comments »

Some of the most common questions I have received in relation to the KDE User Research Profiles have been what are use scenarios, how are they different from use cases, and why do I need them. Hopefully some of this information will clarify the difference between use cases and scenarios and why use scenarios are so important.

What is a Use Case?

A use case is a description of how a user might use an application to complete a specific task. Use cases are commonly used in software engineering to help document functionality and how it is used. They can range in the amount of system-specific information from only describing the task to detailed implementation and avenues for completion. This examples describe similar use cases for the print function in Okular, including implementation details and two avenues for completion.

Okular example: Print a PDF document

• John prints a PDF document from the hard drive by opening the file in Okular, and then selecting File -> Print.
• Sara prints a PDF document from the web by opening the file in Okular, and presses Ctrl+P.

What is a Use Scenario?

A use scenario describes the context of a use case — the conditions, motivation, and environment of the task for a particular user. It is important to understand why a user might complete a specific task and how they will complete it in order to create an interface design. Use scenarios are commonly used by designers as a way to understand users’ motivation and tasks in an interface, but good engineering use cases include these extra elements of use scenarios. This example describes different use scenarios for a similar use case (printing) in Okular.

Okular example: Print a PDF document

• John is using a friend’s computer to print a paper he needs for class. He finds the paper on the hard drive and clicks on the icon to open it in Okular, the default PDF document viewer. He has never used Okular before and doesn’t find the Print button on the toolbar. John is not sure if Okular shares the same keyboard shortcuts as other applications, so to be safe, he goes to the File menu and finds the Print option and clicks it to print the document.
• Sara wants a PDF document which is stored on the web. When she clicks on the link, instead of opening in her browser, she is prompted with a dialog to save or open the document. She selects the open document option and specifies Okular as the application to open the PDF document. Sara usually only reads PDF files on the web, and this is the first time a PDF did not open in her web browser, and this is the first time she has ever used Okular. She does not see a Print button on the Okular toolbar and so decides to try Ctrl+P, which is a shortcut she is familiar with using in her web browser’s PDF plugin.

Why do we need both Use Cases and Use Scenarios?

Use cases and scenarios complement each other. They get interesting when you have similar use cases driven from different use scenarios or different use scenarios leading to similar use cases. You want to try and develop use cases and scenarios for as many functions or features and user types as possible. The goal is to make sure the different ways different users try to complete the same tasks do not conflict with each other.

These example use cases and scenarios describe how different users under different conditions might try to print a document in Okular. In particular, notice how the decision to remove the Print button from the toolbar to make the interface more simple and pleasing effects how these sample users might complete their tasks. What might happened if Okular has a number of users who rely on toolbar buttons to assist in completing tasks? Are these types of users familiar with looking through menu items or keyboard shortcuts? At the same time, consider how inexperienced a user must be to not consider looking through an application menu when all else fails. These users are not really a target user type for KDE or Okular, and so changing the design to accommodate them might not be reasonable.

Use cases and scenarios help provide developers with information to make these types of informed decisions. The next time Okular gets a bug report complaining about the Print button not available on the toolbar by default, the project has a reasoning they can cite. (BTW, users who are knowledgeable enough about using bugtracker can probably also figure out how to add the print button to their toolbar.) Also, I am in no way agreeing or disagreeing with Okular’s decision to remove the Print button from the toolbar by default. It was just a really good example.

seele :: May.06.2008 :: Design, General :: 6 Comments »