posted by Eugenia Loli on Mon 10th Mar 2003 21:25 UTC
IconThis article we host here today is a must read for all Gnome and KDE users. We are happy to feature an exclusive interview with Waldo Bastian and Aaron J. Seigo from the KDE project and Havoc Pennington from the Gnome project. Waldo and Havoc are developers working on many "under the hood" places of their respective DEs, but they are also "sensitive" at UI and usability issues, so we could also call them "usability engineers". Aaron is the head of usability in the KDE project. All three of them were... brave enough to answer twelve hard questions about interoperability, standards, UI etc. between the two leading Unix DEs. Note that this is not a Gnome Vs KDE article, it is in fact exactly the opposite: 'KDE for Gnome' and 'Gnome for KDE'. The begining of a deeper collaboration and sharing that will bring the Unix desktop into a new era.

Note: We asked Seth Nickell, the leader of Usability for the Gnome project, to participate in this interview, but Seth is busy lately with other things (after postponing the publication of this article three times we still haven't got his full response back). If and when Seth finds some time to answer all the questions, we will be posting them too.

Aaron, Havoc and Waldo

1. Some users want infinite number of options and preferences, while others prefer a non-bloated interface where the best options for them is already decided by the system. Now, we all know that there is no such thing as the "Perfect UI", but would it be acceptable to sacrifice certain configurability and... bloat --with the possible outcome of losing some users-- in order to provide a cleaner interface? Do you think such a move would simplify things for the user or do little but rob power from those who know enough to use it?

Aaron J. Seigo: Addressing the overall usability of an application or environment in terms of "number of configuration options" is rather naive. Most people use whatever the default settings are and only interact with the configuration systems when the default settings are not what they need or want.

The sad irony is that the people who lose out the most when configuration is limited in an ad-hoc fashion are those who care about configuring their software in the first place. Those who don't are rarely affected one way or the other. Default configurations are therefore a much more interesting and useful discussion as they effect everyone.

In that vein, it is our challenge as technology creators to deliver what our users need and want in a way that actually works; we can't shoehorn people into the mold of our personal comfort zones. In the world of open source development, our usability lab is much closer to our development offices than is generally typical. In such a cooperative and open environment the question to the answer of "how much is enough" manifests itself naturally if you let it. This does not mean effort is unnecessary on the part of developers, but rather that oligarchical scheming and Grand Unified Opinions are.

It disheartens me when I see a "developer-knows-best" attitude as it almost always lead to "too many", "to few" or just "the wrong" options for the users of the software. Listening to and watching our users in action, I observe three types of requests:

* Options, options and more options, please!
* Make it easy to use these options!
* Make the defaults sensible!

I almost never hear from actual users, "Hey, can you remove a bunch of these options?" So that is our mandate: to make it easy to access featureful software. This may not be the easiest path available, but it is the most rewarding. Anyone clammering for across-the-board removal of options is simply not in touch with our user base.

Of course, this does not mean that we should add every single option imaginable or that we should make everything infinitely configurable. Not all options are created equal, and you can oversaturate a system with microconfigurations to the point that it becomes unmanageable. Some options are the result of developer indecision, some are band-aids over bugs that should be fixed, while others are clearly at odds with the overall design of the software. But the majority of options are worthwhile and there because they were wanted or even needed by actual users.

Havoc Pennington: My opinion on this is pretty well known.

It's all about balance, as I say in that article. The question is not whether configuration is good or bad (some people reduce the argument to this), but about which configuration you have, and how you decide. Claiming "all configuration is good" ignores real tradeoffs - not just with simplicity, but also with stability and speed of development.

People miss that GNOME is still more configurable than OS X or Windows, even though I talk about how it's moved the configurability tradeoff back into the realm of sanity. You have to keep things in perspective.

Waldo Bastian: Configuration options have a cost, they make the software more complex and complexity leads to bugs. More configuration options also makes it increasingly difficult to write good user interfaces for them. On the other hand configuration options can help to make the software perform it's task better for specific users. As a developer you have to balance these two conflicting demands, for each extra configuration option you have to ask yourself, is it really needed, does it really improve the overall quality of my application?

If a configuration option adds very little extra value to the application but stands in the way of a usable interface then I think it can be justified to remove it. But that should be a last resort, the first goal of improving a user interface should be to optimize usability while preserving all features. Presenting the available options in a way so that they aren't overwhelming and form a logical and coherent whole.

Table of contents
  1. "Usability Interview, Part 1"
  2. "Usability Interview, Part 2"
  3. "Usability Interview, Part 3"
  4. "Usability Interview, Part 4"
  5. "Usability Interview, Part 5"
e p (0)    113 Comment(s)

Technology White Papers

See More