[linux-elitists] GNOME report.
Mon Jan 19 00:03:44 PST 2004
On 18 Jan 2004, "Karsten M. Self" <email@example.com> wrote:
> on Fri, Jan 09, 2004 at 08:32:28AM +1100, Martin Pool (firstname.lastname@example.org) wrote:
> > On Thu, 8 Jan 2004 13:36:20 +0200
> > Shlomi Fish <email@example.com> wrote:
> > [for an elitist, you sure have trouble wrapping to 72 columns]
> > > In KDE configured Windows-like they also follow the same *cognitive*
> > > layout. And you should give your users a choice between
> > > Windows/KDE/GNOME 1.0 button-order and Mac OS button order.
> > I think this is a pretty good example of the kind of option that GNOME
> > has decided not to offer. As you say, people's choice of these
> > becomes subconcious, so changing the order between my desktop and
> > yours would confuse both of us.
> I think this is a pretty good example of the sort of thinking that
> bothers me about GNOME.
> I'm not configuring _my_ desktop for your convenience. I'm configuring
> it for mine. It's a collection of settings, hacks, stumblings, and yes,
> accomodations for broken behavior (most of which I've internalized
> fully), which make it useful for me.
> If you want to make pink flying flamingoes verbed left to right the
> default for all configuration dialogs, great. But if my preferences is
> for stacked koalas, and it's an option reasonably supported on other (or
> earlier) systems, _why deny the choice_?
Why deny the choice? Well, here are some reasons:
- More choices means more possible codepaths, which means a greater
testing burden. Adding an additional boolean roughly doubles the
test burden of code that is affected, even indirectly.
(Why does testing burden matter when we have millions of testers?
Because we don't really have millions of skilled and willing
testers. If there are paths which are hit for the first time by
users who are not in the mood, don't have time, or don't have the
knowledge to file a useful bug report then it's a potential loss
for the user and the developer.)
- It also increases the support and bug-reporting burden. The more
options there are, the more the reporter has to describe and the
more variables the programmer has to think about.
- Ditto documentation. Sometimes options are one of the hardest
parts to document.
- It can be hard to make options roll forward in a sensible way as
the behaviour of the program changes.
- Once you put them in, it's hard to pull them out. Therefore think
- Sometimes it is better for the developer to just fix the problem
rather than adding an option to kludge around it. Although it's
easy to just add another if-else, all of these things mean that
you'll pay for it later.
- Users will set options in wierd and broken ways.
(People love to break samba by setting options that sound
interesting, and then waste the developers' time asking about it.
Many of these options are things that only developers would want to
set when experimenting, therefore they are being removed or
I think all the above are true regardless of any subjective/personal
feelings about how UIs ought to work. In addition, there are some
less universal/objective arguments
- Excessive customization can make it hard to switch to someone
else's machine. (In the good old days, I often had to ask how to
drive a colleague's fvwm...)
- Sometimes there is a single setting that is adequate for everybody.
Sometimes you can just support both behaviours, or autodetect, or
Obviously not all options can or should be eliminated. But they do
have a cost that is not necessarily obvious either to the programmer
or the person requesting the feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040119/579da631/attachment.pgp
More information about the linux-elitists