[linux-elitists] GNOME report.
Karsten M. Self
Mon Jan 19 01:55:43 PST 2004
on Mon, Jan 19, 2004 at 07:03:44PM +1100, Martin Pool (email@example.com) wrote:
> On 18 Jan 2004, "Karsten M. Self" <firstname.lastname@example.org> wrote:
> > on Fri, Jan 09, 2004 at 08:32:28AM +1100, Martin Pool (email@example.com) wrote:
> > > On Thu, 8 Jan 2004 13:36:20 +0200
> > > Shlomi Fish <firstname.lastname@example.org> 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:
Commentary, some agreement, some suggestions, some differing.
> - 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.)
Here's where an appropriate test frame / debug tool / reporting system
would help. Mozilla had one (name escapes me), and I think Microsoft's
Dr. Watson was nominally something like this (though not of much use).
One solution is to keep your internal state sufficiently well
represented that it can be reported (or determined) from dumps or
Sometimes you get bonuses, like Galeon's crash recovery. Sometimes what
_that_ told me was that one of the pages I was on was crashing Galeon.
Pretty hard to get _that_ detail without crash state.
> - 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.
Yes. We've been there, haven't we...
One the one hand, the bar's pretty low. Legacy MS Windows docs are full
of completely content-free documentation. What I've seen of a lot of
recent-generation 'Nix apps is that the manuals (say, either GNOME or
KDE) tend to be far better.
> - 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
Just to note that this is part of the problem being encountered now.
There were apps/systems which behaved one way. Now they either behave
another, or don't have the functionality at all. Galeon (equal
opportunity kvetching) is a particualarly sore point here.
> - 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.
Often providing a function for something is a broken mode. Especially
stuff that the system should determine automatically. Sometimes,
though, the user, or some users, really want or need the choice.
Earlier choke/clutch discussion.
> - Users will set options in wierd and broken ways.
...and learn to love them.
> (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
Again, for system-level stuff, automated configurators are a good way to
fly. Knoppix sets a bar: it may not configure itself _optimally_ for
_all_ hardware and networking situations, but it configures itself
_functionally_ for a _much_, if not most. A tool which works out sane
settings and goes forward is useful. Autoconf is another. Hairy piece
of shite, but damned if it didn't work for a wide range of situations.
Point being: you get the user back on even footing. Have them get back
to you if they still have a bug. Sort of the equivalent of the help
desk asking if you're plugged in to wall circuit (no joke: about half
my support issues at one job involved stuff no connected, connected
incorrectly, or with broken connectors).
> 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...)
Here's where I've got a *major* difference of opininion.
You make the configuration portable.
Rather than forcing all your square pegs into round holes, jackbooting
users, or resetting time-tested and habituated configurations on moves
and upgrades, *you port the configuration with the user*. This is one
place where GNU/Linux wins *SO* overwhelmingly over legacy MS Windows
that it's not even funny. At all levels. I can port a system to a new
box (or new architecture), including all 1479 installed packages, and
configs, in a matter of hours (faster for fully automated transfers).
For user-level setup, seconds or minutes. See Joey Hess's $HOME under
CVS (now either arch or svn, IIRC) articles. The thought of hoofing to
a job where I can't determine my computing environment frankly bugs the
bejesus out of me. And if you think this is just a techie issue -- the
secretaries and salesfolk bitch about this as much as anyone, the moreso
because they're frequently intimidated by the technology.
> - Sometimes there is a single setting that is adequate for everybody.
I hear that a lot from you folks (Waugh, yourself, in particular). I'm
decidedly unconvinced it's as common as I've heard claimed.
> 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.
A lot of what I'm hearing is that many problems can be avoided by
eliminating the user. Which begs the question of who's being served.
Karsten M. Self <email@example.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Geek for hire: http://kmself.home.netcom.com/resume.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040119/1cebf7ff/attachment.pgp
More information about the linux-elitists