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

List:       kde-usability
Subject:    Re: optionitis
From:       David Hugh-Jones <davidhj () mail ! com>(by way of David Hugh-Jones <david () zaygo ! com>
Date:       2002-02-18 23:02:18
[Download RAW message or body]

Hi Aaron

On Monday 18 February 2002 5:06 am, Aaron J. Seigo wrote:
> 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.

Obviously there are cases where options are essential. But I respectfully
submit that sometimes there is a Right Thing to do. For example, we don't
have an option to make the close button look like the maximize button.
Perhaps somebody might have an extreme desire for a large square close
button: if so, they can code it themselves!

I think the option to alter the size of kicker hide buttons is a good
example. If we have an option for this, why not also an option for, say,
"menu bar height"? Similarly, why are there separate speedbars for kicker's
automatic hide and manual hide? I can understand people playing with the hide
speed, but who would want to have separate speeds for these two things?

> > 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.

I do need to do this. What I mean by user visible, is that
1. the option should make sense to the user in his/her own terms.
2. the option should "be about" something of concern to the user. (does my
desktop look pretty? can I find unread email fast? is my computer fast
enough?)

Obviously these are open to interpretation. Power users have more detailed
concerns than new users.

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

Well... there is a balance. The thing is that power users are also those more
likely to report bugs, demand features etc. I know cos I do it myself.
Obviously KDE thrives on community involvement... but in the long run maybe
it will also need to think about "silent majorities".

> > * 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...

I don't buy it! It's such a specific option. I could understand a general
option to make buttons in general bigger or smaller. That would be great for
accessibility. But having it just for these two buttons is pretty odd. Note
that, for example, you can't change the width of the panel applet 'handles'
that open the relevant menu. If one, why not the other?

> > * 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.

Hmmm. Are you sure about that? I would be surprised if many end users cared
either way. Again, it is one thing for debate to get heated on development
lists; that is entirely right and proper, because  people care about getting
their stuff right. But that doesn't mean end users will be hugely bothered.

> > *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 ;-)

I'm trying to find them... do you know what the subject was?.

> 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)?

True enough. But how about:

[ ] do not view previews over remote computers

This loses fine-grained control. But it makes sense to my Mum. Whereas asking
users to parse audiocd:/, man:/, https:/ and so forth is quite a big demand.

Actually, I think mentioning your parents is to usability what mentioning the
Nazis is to politics. But that's another issue :-)

> > * 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.

Well, you don't have to have an on-off value. I think a really good example
of the right way to do this is the initial KDE configuration dialog, with a
bar where you can select speed vs. eye candy (and power users can choose
individual features if they want). That's a great way to aggregate different
features together. Perhaps the pixmap cache could be integrated with 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/

I know that it's important to pay attention to existing users. I'm not
suggesting that KDE shouldn't. But there is a cost to adding options.
Sometimes it might be better to resolve why old users are unhappy.

> > * 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/

Well, yes, sometimes I am sure. I ain't a KDE developer, so I can't comment
on the process. I am just guessing in the dark.

> > * 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.

Perhaps we should find out some examples of option "best practice". I
nominate the initial KDE config dialog. It's sweet. The "Mouse" kcontrol
module also seems good.  And I have always found KMail's config pretty easy
to use, although sometimes a bit overwhelming.

I can think of some baddies too; I think LookNFeel is organized strangely
(styles/themes/legacy themes/backgrounds etc. all seem to overlap), although
I wouldn't want to lose many options here cos people love making their
desktop look "just so".

--
David Hugh-Jones
_______________________________________________
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]