Name: KUA11 KControl's Categories Description: Explains the rationalis behind KControl's categories. Observe, the content, does not reflect the current state, but the plans for KDE 4. KControl uses a traditional way of organising functionality; instead of showing a long list of all available functionality, it is grouped into categories. Instead of having the user iterate through a single list for finding the requested functionality, the navigation is performed by first selecting a category. As a result, the selection and phrasing of categories, and the organisation of the modules, affects the navigation substantially and must thus be done with great care. Since all users, regardless of what they are looking for, must intercept and interpret the categories, it is of interest keeping the categories fast to read, as well as having as low amount as possible. Obviously, not to the extent their content becomes crowded. To the contrary of older versions of KControl, only one level of categories is allowed. The existence, and need of multiple levels, is a sign of how absurd the amount of configuration options was, and its usability inefficiency. Eventually, at some point in the future, no categories will exist at all. KControl is not a dumping place for configuration options in general, it provides configuration functionality which affects the computer on a global, central level. Thus, a module can not represent an individual programs's settings. Of course, from an implementation perspective the module may well affect an individual component's or program's settings, but the implementation details are irrelevant since it is not the user's, but the developer's, view. KControl have, except for regular configuration modules, administrator modules, which allows more intrusive changes when the user have entered the administrator password. Under what categories administration modules are placed have absolutely nothing to do with their technical nature. If a module need administrator privileges is a technical, system dependent, aspect the user does not know about, and does not want to know about. Organising KControl on whether modules need system administration or not, will make the user's navigation fail, since it does not correspond to the user's knowledge and expectations. Thus, it is not obvious an administration module should be placed under "System". Do not add any KControl modules without consulting the KDE developer community first. Remember, new modules affect the whole of KControl, not only the module itself, and must thus be coordinated with the rest of KControl's development. Having a module peer reviewed will also ensure a good selection of name and category - aspects not always obvious. Entries in the former "Peripherals" and "Power Control" have either been removed or transfered to the new "Hardware". Because: * The word "Hardware" is broader and cover more devices than peripherals. Thus, multiple hardware categories is not necessary. Furthermore, "Hardware" is more common, and not as technical and clinical as "Peripherals". * With the new conditional-module-loading code in KDE 3.3, and later restructurings, the amount of modules for the mentioned categories was reduced, and thus two categories unnecessary. "Web Browsing" in "Internet & Security" and "Spell Checker" in "KDE Components" was removed since: * Their content is not percepted as being global but program specific. For example, the user is unaware of KHtml is a generic component and associates its behavior with Konqueror or whatever program it is used in. When, as a developer, being aware of KDE's high integration, it is easy believed the user shares the insight. * They were duplicated by being available where they were used. For example, all programs which have spell checking have the configuration available in one of their menus. * The need for accessing their content(to configure) araises in the respective programs the components are used. When it is possible to place functionality close to the user, it should of course be done. Applications using the components, which configuration modules not any longer available in KControl, should load the needed modules in their configuration dialog. Former "KDE Components" was removed because it assumes the user distinguishes between KDE and other system components, an idea far from the actual circumstances. Its content was either removed or moved to "System". "System Administration" was renamed to "System". No need to state the obvious, as well as increased interpretation speed. * Hardware Contains elements the user percepts as engaging directly with the hardware. For example, "Monitor" could be placed under "System" since it actually means configuring the X Windows system, but the user associates a monitor with hardware, and percept the configuration of the monitor as affecting the actual monitor, not the underlying system component(which the user does not know anything about). * System Contains elements the user associates to directly concern the actual computer - the system.