KDE Usability Topics and Viewpoints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ General Usability Discussions ----------------------------- 1. User Levels DESCRIPTION: KDE should have user levels to allow new users to be better integrated into the environment. User levels will hide the advanced features so any one with a certain level of expertise will not feel overwhelmed by the number of options. COMMENTS: A. Seigo (2002-05-20): the goal should not be to remove things that people aren't familiar with (otherwise we may as well remove computers altogether; no one is familiar w/computing until they use them for an extended time). rather the goal should be to limit those things which are beyond the grasp of the average person. K. Koehntopp (2002-05-22): Looking at the kcontrolcenter, I am overwhelmed. There are far to many switches and dials, and most of them are essentially unused. Most of them really should not be there, but go away into some panel which is normally invisible, and only available by clicking at some button labelled "advanced". T. Zander (2002-05-20): The complexity you point at has little to do with the amount of features being turned on at the same time.  As long as they have a good default the user will never even try to change the features. CONCLUSION: User levels do not achieve the intended purpose because users first have to figure out their expertise. They never get the opportunity to learn more advanced features. In addition, users of different classes will end up dealing with "different" user interfaces which leads to confusion from support lists. 2. Application Plugins General "Computer" Applications ------------------------------- 1. The Apply Button DESCRIPTION: The behaviour of the "Apply" button. S. Edwards (2002-04-16): Hi all, A quick question I guess. Consider this: 1. User starts a program (a Firewall program for example). 2. User changes settings. 3. User presses 'Apply' and the settings immediately take effect on the system. 4. User presses 'Cancel'. The program exits. What state is the system's setting in now? a) Same as before point 1. b) Same as just before point 4. c) none of the above. What do people expect here? I. Kwan (2002-04-16): I think that as soon as you hit 'Apply', you should grey out the 'Cancel' button.  Notice an application like KControl does NOT have cancel buttons, probably precisely this reason. In this instance, I would put the program in the 'Applied' state with the new user settings that were chosen when you selected 'Apply'. (Same as before Point 4). C. January (2002-04-16): 1. Cancel should be called Exit if it exits the whole program. 2. Apply buttons are a horrible addition to dialogs. First of all, most Apply buttons appear next to Ok and Cancel buttons which close the dialog...except Apply doesn't actually close the dialog. Secondly, with most implementations once you press Apply your changes are fixed; pressing the Cancel button does not, usually, undo your changes. Preview is probably a better choice for environments where this actually matters (e.g. look and feel settings). The rest of the time (e.g. with firewall settings), an Apply button makes little sense anyway. A. Seigo (2002-04-16): if anything, i could see the term "Ok" being changed to something more in line with "Apply" and "Cancel" as it is ambiguous until one learns what "Ok" actually means. perhaps something like "Apply and Close", although that is long, would require people used to "Ok" to relearn the interface, etc... C. January (2002-04-16): When I said Preview I actually meant that the button would really preview the settings rather than change them there and then like the usual behaviour of Apply. A. Seigo (2002-04-16): how do you preview a user agent change in konqueror? or, to fall back to our original saw: how do you preview a firewall rule change? because "Preview" doesn't apply to all types of settings having "Preview" there sometimes and "Apply" there others would suck. additionally, previews (if at all possible) should be in the dialog itself. cf: kde3's style and color kcms I. Kwan (2002-05-26): I noticed that when watching people use a dialog with "OK", "Apply" and "Cancel", they usually hit Apply before using "OK" to close the window. This suggests that there is confusion because people are using apply to "be sure" that their application's settings are saved. POSSIBLE SOLUTIONS: * Rename "OK" to "Apply and Close". * "Preview" to see changes without saving them, OK, and Cancel * Status quo: OK = "Apply changes and close window", Cancel = "Cancel all changes and close window", Apply = "Apply changes and leave window open". 3. Static Window Placement Policies DESCRIPTION: There should be a window placement policy that places a window in a pre-set location on your desktop. SUMMARY OF DISCUSSIONS: -Current window placement policies place windows dynamically on the screen so that a user does not know where to find them. -Static window placement policies will allow a user to predict exactly where the window will be placed so he/she can move it to the desired location. -Static window placement policies will end up "stacking" windows, which means it is more difficult to find them under a number of windows. -"Paper on a Desk Analogy". How you arrange the paper on your desk; a new window is equivalent to a co-worker placing a new sheet of paper on your desk. POSSIBLE SOLUTIONS: * Add an option for placement of new windows in "Center" * Add an option for placement of new windows in "Upper-left Corner" * Status quo (do nothing) Specific KDE Applications ------------------------- 1. kicker kcmshell -Action was taken on this item. General Comments when redesigning other kcmshells(I. Kwan, 2002-05-26): -From a quick heuristic analysis, it is MUCH nicer to have everything laid out vertically as opposed to horizontally. For example the "tile" buttons on the Panel (kicker kcmshell Look and Feel tab) were changed from being a 2x3 grid to a 1x6 grid, for a much nicer effect. -The verb "Enable" was removed from the kicker kcmshell. Instead of "Enable automatic hide animation", we have "Animate panel hiding". -Removal of redundant sliders in favour of a number-counter widget (find name) -Use of checkboxes for "On-Off" rather than two panels indicating "Available items" and "Visible items". **NOTE: Configure Toolbars could take a lesson from this. 3. KMail 4. Konqueror (File Manager) 4.1: Button submenus: -Action was taken on this problem. 5. Konqueror (Web Browser)