Re: Draining the Swamp: A Technical User's Experience

[Maciej Stachowiak <mjs noisehavoc org>]

On 06May2002 12:24AM (-0600), Richard Stallman wrote:
> 
> Assuming the monitor could indeed handle both scan rates, this is a
> user preference choice.  It could not be decided automatically, even
> in theory.  If the system supports two scan rates, it cannot decide
> automatically which one is right.  So it system needs to provide a way
> for the user to choose.  In the GNU system, the part where this would
> naturally be done is GNOME.  Thus, GNOME ought to provide a full
> spectrum of configuration facilities.

Here you seem to argue for providing convenient graphical preferences
for anything a user may wish to configure. Elsewhere you have stated
that you would like GNOME to strive to have as good a user interface
as the Macintosh. Unfortunately, those two goals are in conflict.

Many preferences could be added to the user interface because they
have a benefit for some users. However, every preference that is added
to the user interface has a cost for all users - it makes other
preferences that much more difficult to find, and it makes it that
much more likely that the common case will not simply work
autmatically.


I think it is important here to distinguish three ways in which
software may be customizable to the needs of the user:

1) Convenient access to a particular preference or setting[1] through
the normal user interface of the program.

2) The ability to change a particular behavior through less convenient
back-door channels, such as using command-line tools or by editing
configuration files directly.

3) The ability to change program behavior by modifying the source code
to meet your needs, or arranging for someone else to do so on your
behalf.

I believe only #3 is required to comply with the principles of
software freedom, and GNOME's largely GPL and LGPL licensing already
ensure it.

Methods 1 and 2 above do not add any additional freedom - they merely
add convenience for some users. At the same time, they take away
convenience from other users, by making it harder for them to find the
preferences they truly care about. User testing under controlled
conditions bears this out.

Therefore, the right approach to methods 1 and 2 of customizing
program behavior is not to maximize the number of ways a program can
be customized, but rather, for each preference, to balance it's
benefits against it's costs. This is done by considering how many
users may want to change program behavior in that particular way, and
how much it would harm their use of the program to be unable to make
that change.

For example, changing the background picture is a matter of taste and
something a failry large number of users want to do, so it is provided
for conveniently in the UI. Accessibility preferences are only useful
to a fairly small subset of users - but without these preferences,
those users would probably be unable to use GNOME at all. So they are
also provided. On the other hand, having the titlebar on the bottom of
the window rather than on top is something that very few people want
*and* which has no practical utility. So this preference is not
exposed in the UI, even though the underlying system makes it
technically possible.

Obviously not all decisions about what preferences to include are so
clear-cut. In reality most such choices are tradeoffs rather than
black and white decisions. But we must realize that these are
tradeoffs among benefit and harm to different users, not between
freedom and simplicity.

So long as you have the source code and the ability to change it, you
cannot claim your freedom is impinged by the application of editorial
taste to preferences.


Regards,

Maciej


[1] We refer to choices which reflect the user's desires and cannot
possibly be "wrong" (such as choice of font) as preferences, and to
choices which must be made in a particular way for correct functioning
of the system (such as configuring the IP address) as "settings". As a
general rule, the kinds of choices that are controlled by "settings"
should be made automatically whenever possible, rather than being
thrust upon the user, or replaced with choices that cannot be gotten
wrong. In the case of IP address, this is not yet always possible, but
with IPv6 there should be very little need for users ever to manually
configure IP addresses.