[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: optionitis
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-02-18 5:06:39
[Download RAW message or body]

hi...

> 1) There is an option to control something that should just "do the right
> thing".

who gets to define "the right thing"? and what do we do while we wait for 
everyone to have the same computer, the same network connection, and the same 
personal quirks, er, preferences.

> 2) The number of options gets confusing to the user.

this is a valid point. the problem, however, is not that things are too 
configurable, it is that the configuration options are presented in firehose 
fashion: all at one in the same place with no way of toning it down.

> 3) Options talk about internal system behaviour, rather than user-visible
> results

define "user visible". resource usage, for instance, is very user visible 
even though you often can't see it with your eyes. you feel it in 
responsiveness.

and let's not even talk about power users and their picky behaviours.

> You may disagree.

ok ... ;-)

> * The panel config dialog lets you set the size of hide buttons. Diagnosis
> (1). If the buttons are a sensible size, why would anyone need to customize
> them?

because different people have different ideas of sensible. depending on 
screen resolution, eyesight quality, aethetic opinion, etc...

> * There is an option to show or hide the side image in the K Menu. (1)
> again. If the side image is useful have it, if not, don't.

some want it, some don't. instead of making a call that upsets a large number 
of people either way, it is made configurable at run time to have it or don't.

> *KMail "Miscellaneous" configuration. "Loop in the current folder when
> trying to find unread mail". (3). Even with the very helpful context help

read the threads on kmail devel regarding this one if you have a few hours to 
burn ;-)

> * Konqueror "file manager", "Previews" tab. This lists different protocols
> so you can select which ones should use previews. (3) again. I can see the
> rationale. It is annoying for Konqueror to try to load previews over a slow
> ftp connection. But many users won't know what protocols are. It would be
> preferable to automate this decision, so that previews were not generated
> if the connection was slow.

how slow is slow? what about those who are concerned about bandwidth 
conservation beyond the width of their own pipe (vs those who aren't)?

and they do have default values. they are simply modifiable.

> * Screensave "Limit pixmap cache" option. (3). Again, users don't want to
> "limit the pixmap cache": they want their KDE box to be reasonably fast.
> The system should be capable of making this choice itself, based on amount
> of memory.

this is not so easy to do on a multiuser system. and where do you draw the 
line exactly? people on the arbitrary border may not appreciate it.

> * A new way to do things is introduced, but some users prefer the old
> system. An option is introduced to shut them up.

s/shut them up/ensure existing users continue to enjoy KDE/

> * Developers can't agree about the best way to do things: so they put in an
> option as a compromise.

s/compromise/realization that there isn't a single best way/

> * Options should make sense in user terms. ("Limit pixmap cache" - no; "Use
> less memory" - yes.) Even if you can explain a confusing option with
> context help, the fact that it is confusing should alert you to the
> question "Is this choice relevant to the end user"?
> * Advanced options should be separated from simple options if possible,
> e.g. on a separate tab.

now this is IMO more to the actual problem. how the options are presented is 
the issue, not that the options actually exist. the idea of "user levels" has 
been offered before, but there are deep problems with that idea. i agree that 
the control dialogs need to be combed and better organized and structured so 
as to avoid 'option overload' while not getting in the way of the power 
user's great thirst for and ability to digest options.

kicker's option dialog is a great example of something that could use a HUGE 
massage IMO.

btw, there are severa options that are largely undocumented. there are little 
things you can turn on by editing config files that don't appear in config 
dialogs. sometimes these things eventually go away, sometimes they are always 
there but seen as "too fringe|detailed|advanced" and option to warrant making 
it "public". so, things could be worse and there is some thought put to 
whether to document an option or not.

> * Don't put an option in just because you're not sure what the best way to
> work is. Only put an option in if you are sure that different users need
> things to work differently.

this seems to rarely happen.

-- 
Aaron Seigo
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]