From kde-usability Mon Feb 18 23:02:18 2002 From: David Hugh-Jones (by way of David Hugh-Jones Date: Mon, 18 Feb 2002 23:02:18 +0000 To: kde-usability Subject: Re: optionitis X-MARC-Message: https://marc.info/?l=kde-usability&m=101407353202198 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