- About Us
As a participant in the KDE project (but expressing my own viewpoint here instead of speaking for KDE), the approach I have seen so far to our usability problems is... noise. Ideas are raised daily on the KDE usability email list, but they never seem to generate anything but endless discussions. Developers, users and reviewers all scream that something needs to be done, but apparently no one knows how.
Judging from blogs, email lists, and articles I see, these seem to be the most called-for solutions to our usability problems:
In other words, many developers seem to believe usability is such a complex matter that the open source community is unable to handle it; that we need outside Companies, Experts and Laboratories to manage this mystical matter.
Programming and "ordinary" engineering are areas in which the open source community has deep experience -- stretching over almost three decades -- but usability is a relatively new matter for us. How we react on usability issues, by seeing them as something mysterious we are unable to handle and someone else can and must master, is similar to how human beings historically reacted to phenomena we didn't understand. Lightning was explained by Thor's Hammer, the plague was a punishment from God, and so forth. In our case, we replace "God's will" with "Companies", "Reports" and "Experts." We don't understand usability, so we push responsibility for it onto someone else.
Too big an issue to rely on outsiders
Even if we decide to rely on outside experts to solve our usability problems, they are going to find it impossible to keep up with us. The KDE project alone has an average of 200 checkins to its code repository each day. There aren't enough outside usability specialists available to correct all the errors that are inevitable with this level of productivity.
One of the advantages of open source is its ability to put the consumer ahead of profit. Our goal is to produce great software while honoring the user's privacy, rights, and freedom. When usability, central to everything in today's software, is outsourced to companies, the open source community's independence and opportunity to achieve its noble goal is compromised. The open source community must be able to handle all its issues -- including usability -- by itself in order for our development approach to give maximum benefit to society and the user by constantly advancing our level of technical excellence.
"Usability Reports" sounds like a possible solution, but somehow, when usability issues are encountered, open source people seem to conclude with a deep sigh that they cannot be solved since we don't have the resources to study usability properly. But we don't need formal studies. We simply need to apply our own problem-solving skills.
Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.
All it takes is to think once about each little item like smbUmount. If the changes to this and other items that are obviously not user-friendly are made, most of our usability work will be done. We don't need usability reports. We need each developer to devote as little as one single thought to usability.
We need to teach -- and learn -- usability
If I want to learn programming in Python, device driver development for Linux, or object orientation, I can consult countless HOWTOs, online books, FAQs and email list archives. If these sources don't answer my questions, I can ask the community through an IRC channel or email list and almost always get a reply based on the community's decades of collective wisdom.
But If I want to learn how to write phrases understandable by users or what colors to use that still allow color-blind people to use my software or how to best name categories for efficient navigation, I can do nothing but listen to people's opinions in the matter. Where is the open source community's pool of facts and knowledge covering usability issues?
Discussions on our usability email lists are noisy, full of anecdotes and not so humble opinions. We cannot tell each other to RTFM (read the fine manual) because there isn't one. All we have are our style guidelines. Guidelines are "do's" and "don't's," but not rationales. Guidelines are a convenient way of steering usability development that work well in the areas they cover, but as soon as we get outside those areas, development drifts. Then we need knowledge to help us make wise decisions.
Our community has little experience in usability and designing graphical user interfaces, and the way we approach these matters today gives us no chance to teach ourselves. No wonder the result screams for improvement, our discussions are nothing but rants, and we leave the mysterious problem to the Almighty Gods of Usability: The Experts.
We need to build our own pool of knowledge in the usability field. We need online books about usability, published under open source licenses. We need HOWTOs, interviews with project managers, and articles discussing, questioning and driving usability. Then we will be able to work on our problems, since once we have the base knowledge, usability will be revealed as the engineering science it is. Then our usability discussions will no longer be long anecdotes and personal opinions, but will become problem-oriented, and will be discussed in terms of right and wrong.
Once we build a reservoir of open source usability knowledge that rivals our pool of programming knowledge, open source development will not only be the best way to achieve technically excellent software, but will also become the best way to produce usable software.