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

List:       kde-usability
Subject:    Re: optionitis
From:       Rene Horn <ndogg () geekhead ! org>
Date:       2002-02-19 2:00:50
[Download RAW message or body]

> > * 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"?
>
> We already have such things.  If you don't understand an option, use the
> What's This help.  The option is there to explain what it actually does;
> What's This is context-specific help to explain what it means.
Sorry to nitpick, but I have to agree with David here.  I think that the 
context-specific help should give the inner details while the label should be 
relatively intuitive.  I think most people would understand the latter label 
than the former.

The less people have to rely on context-specific help, the more productive 
they are.  Context-specific help is there if the functionality of a button or 
other widget has a functionality that cannot be explained fully by just a 
label.

If a user doesn't know what a "pixmap cache" is, but does what memory is, 
should we force him/her to wait to find out what a "pixmap cache" is?

Here's an idea, why don't we ask the user in their first login how familiar 
they are with KDE?  This would set an option that an application could check, 
and the more advanced the user is, the more options that would be available 
to him/her.  We would need to make sure that option is pretty visible though. 
 This way we could satisfy both power users and novices.
-- 
Alternate email addresses: hornr18@uwosh.edu, hawkdogg@whoever.com
_______________________________________________
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]