Version: (using KDE KDE 3.5.2) Installed from: SuSE RPMs (settings section) It is related to options mainly but also applies to the other functions of any program except those where someone has to handle mouse smoothly by definition -- like drawing programs. I think that HIG should state clearly that no option should require good reflex to set it on or off -- the settings dialog /or anything like it/ should not disappear all of the sudden, there should not be any time set for the user to make his/her mind up. User should choose options he/she likes in his/her own pace. Bad examples /programs violating such rule/: * kdevelop and its splash screen -- you have to click on the splash screen QUICK to turn it off * kmail and its fetching progress dialogs -- to show them you have to maneuver mouse to reach button ~20x20 pixels and click on it before it disappears
Is there a fetching progress dialog in kmail? Where? :-) I would have had uses for this for a while when I had email problems but no clue on what the problems were. kdevelop problem - is that really a problem? If it shows and disappears to fast for click on to close it, is that a problem? (since the only action when clicking on it is to close it)
Kmail -- bottom, right corner. KDevelop -- certainly, not a major one. However we are discussing not a wish/bug for given application (those are just _examples_) but the guidelines of all KDE apps. HIG purpose is how to design applications or redesign existing ones. Let's take a look from the other perspective -- do you really think that is is a good practice to design applications that require reflex to run them? Except for games, I have no doubt -- no!
You are correct for two reasons: 1) Computers/networks gets faster, unless the time window for doing an action is timed against real wall clock time. You will get shorter and shorter time to do the action. 2) Accessability for disabled. But you are also wrong... If your guideline suggestion were followed strictly there would be no option to cancel work once started. File transfer could not be stopped until all is transfered. (Same for web page rendering) Print could not be stopped before it is printed (easily until it is saved to a file, with printmgr until fully written to paper) BTW One think one application that clearly breaks this "rule" is kget (konqueror without kget?) The window you get for a single file transfer has an option to "do not close this window when done". Try to use that with a small file and/or fast network... So the rule needs to be reformulated...
> But you are also wrong... > If your guideline suggestion were followed strictly there would be no > option to cancel work once started. Ok, so except for programs that needs such skills by definitions (drawing tools, games, photo-edition) and all stopping the running process (copying files, compressing data, downloading pages, etc.). Another story is such dialog as you mentioned -- I think that by default all such windows should stay and show at the end message "printing/copying/downloading finished". The reason -- it is more appropriate for novice users, when the power users have no problem switching off such behavior (vice versa scenario is more unlikely).
Regardless of individual applications, I agree that this should be in the HIG. The exceptions would be time-dependent windows, such as the Cancel button on a file transfer. However, even that issue could be addressed with an option for the user to leave the dialog open even after it is complete, and Cancel would then undo whatever had been done (within reason, of course).
There isn't enough information in the report to determine if there is a problem, and if there is, how to fix it.
Celeste, what do you mean -- it is HIG part, not application report. HIG is for guidelines, not solution how to write applications (internally). HIG should state that it is incorrect to force user to work in "computer pace". That's it -- and HIG should not fix anything but give one or two positive and negative examples. Positive example is Kate overwrite dialog-warning, you can take an hour thinking what to do. Negative example are Kmail (see original report). Reopening.
The problem is that there is no KDE HIG guideline specifying that KDE applications should not require quick reflexes to operate. That seemed rather clear to me, but that could be because my own aging reflexes are not super quick. How to fix it? Add such a guideline. Would you like me to word it?