Author: Tom Chance
Over the past couple of years, usability work has gradually become part of the core KDE PIM (Personal Information Management) development processes. Spurred by the usability track at KDE’s conference last year, the suite of PIM applications has undergone an extensive usability review, with many changes introduced in the recent release of KDE 3.4, thanks to some radical changes to the way that the KDE PIM developers and usability engineers work together.
Before the changes, implementing usability wasn’t always pretty, according to Ellen Reitmayr (an expert from OpenUsability), Cornelius Schumacher (KDE PIM release manager and, for many years, KOrganizer maintainer), and Till Adam (one of KMail’s core developers). With only the kde-usability mailing list to focus usability discussions, the noise-to-signal ratio tended to be high, and any improvements were sporadic and generally technically oriented.
“The list was wildly ignored,” according to Adam. While individuals such as Aaron Seigo and Thomas Zander tried to push usability efforts forward, and a basic style guide provided a point of reference for discussions, there was never a sense that usability received as much productive attention as developing interesting new features or fixing bugs. Worse still, Reitmayr emphasised, “often when usability experts, especially from universities, contacted KDE, they didn’t know where to start”. So little outside advise penetrated the walls of the community.
Hurdles to a healthier relationship
When, at the KDE conference in 2003, some KDE developers began to work with OpenUsability, previous usability problems caused scepticism amongst many KDE hackers. Cultural differences didn’t help either. Often when Reitmayr and her colleagues first suggested changes they offended developers, because the ideas had already been discussed and were rejected. But as they grew accustomed to the KDE development processes and provided genuinely useful suggestions to developers, scepticism faded. According to Schumacher, by attending meetings, making personal contact with a lot of the developers, and taking part in discussions, the usability proponents bridged many of the differences in approach and knowledge. “By learning how different people work and what motivates them, both sides came to understand each other well enough to work together efficiently.”
The OpenUsability experts also had to overcome technical difficulties. To properly contribute to KDE user interfaces, you need to have a recent development version from the CVS repository. Being able to use tools like Qt Designer, the powerful GUI builder, also helps developers understand and quickly implement an interface suggestion. As Reitmayr pointed out, usability experts often have a background in psychology and other social sciences, so they’re unfamiliar with CVS and may be reluctant to use it. The full compilation process is an even greater hurdle. Qt Designer, on the other hand, is easy enough for them to pick up quickly.
The KDE developers are overcoming this problem with an ingenious new toolchain. First, the recent round of KDE PIM development (from KDE 3.3 to KDE 3.4) was done in such a way as to allow people to compile the development version using KDE 3.3 libraries. This meant that the OpenUsability experts could get away with only compiling the applications they wanted to test whilst using a stable version of KDE, saving considerable time and effort. The more impressive solution, which still needs some work to complete, will allow usability experts to test live nightly builds of development versions remotely using FreeNX. Whether they use GNU/Linux, a BSD derivative, Mac OS X, or Windows, they’ll be able to painlessly connect using NoMachine’s compressed X terminal session technology, NX.
Tracking issues was also problematic. Bugzilla, KDE’s tool for the task, is great for keeping track of crashes and feature suggestions. But according to Reitmayr, it isn’t suitable for usability, not least because bug reports can’t properly convey the context of the problem. She gave as an example a problem that a user might have configuring KMail:
“When trying to set up a mail account with an OpenPGP key in KMail, you have to make settings in three different configuration modules. Users have problems understanding that. This is not a technical issue, because once the user discovers how it works he can set everything up. But to make the developers understand that users might have a problem with the workflow, you have to explain the context of usage and the way common users think.”
The reports produced by OpenUsability are, according to Adam, “full of clear, concrete ideas that are well-reasoned, that have an overall vision, and that follow principles. They are also an appropriate length, without being too long or vague.”
Working in new pastures
OpenUsability is not just a team of experts; they are also working hard on a platform that will be a kind of usability Bugzilla, holding usability reports that can then be, as Reitmayr described them, “bases for discussion.” Their approach has been quite different to the usability status quo: that of experts feeding suggestions into the development community and, in some cases, watching the result come out of the black box. With KDE PIM, usability and code experts worked together throughout the process, equals in every aspect of the UI design.
“For developers,” Schumacher says, “the process changed in two ways. First, we had input that we felt was worth listening to, and that was more objective than our own opinions. Second, the input was continuous so we didn’t waste effort on bad design, and were able to react directly to feedback.” For Reitmayr and her colleagues, it was simply a more amiable environment than the flamefests they might have received on the kde-usability mailing list. Best of all, because they were deeply involved in the development process, and because they had the source files and tools at hand, they were able to work in a way that isn’t usually available to usability experts.
Usability issues still need interested hackers, admitted Schumacher; Adam added that controversial changes in KDE PIM “made some people yell.” But by providing constructive criticism such as “here are some use cases where it wouldn’t work, here’s how you might improve it” rather than “that idea is bad,” most hackers are being persuaded. If anything, they’ve gained a new insight into the problems that users face with their software. The hands-on sessions at the KDE conference last year were “scary” (Adam) and “eye-opening” (Schumacher). “If they take the initiative,” Schumacher says, “developers will find a lot of fun stuff to do”.
With 11 KDE projects now working with OpenUsability (recent converts include KPDF, KDEPrint, and Konversation) the future looks increasingly bright. Thanks to KDE’s architecture, many usability improvements can be made in the libraries, and with new usability guidelines being developed, every hacker should be able to meet the minimum usability requirements relatively easily. If more usability experts can be drawn into the KDE development process and be accepted as core participants, we should see two birds killed with the same stone: Developers will be spared the flamefests over everything from “pixel-pushing” to major changes, and users — not least the early adopters installing KDE for the first time — will find a more usable desktop on their screens.
