From kde-usability Mon Feb 18 05:06:39 2002 From: "Aaron J. Seigo" Date: Mon, 18 Feb 2002 05:06:39 +0000 To: kde-usability Subject: Re: optionitis X-MARC-Message: https://marc.info/?l=kde-usability&m=101405447412283 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