KDE System Settings: About the general navigation

KDE system settings are subject of ongoing discussions. In this article we present two alternative interactive prototypes for a possible future of the design. Please vote for the approach you like most.


Recently, we ran a study on the reorganization of the KDE system settings (Re-sort KDE control modules and Results of Card Sorting the KDE System Settings). Both the number of participants as well as the discussion in the forum proved the huge interest in this topic.

Based on these information some design proposals have been developed. Their impact on navigation needs to be carefully considered. Following we introduce two possible alternatives how the system settings could look like in the future as (partly) interactive mockups and ask you to vote for your favorite option.


Primary goal of the project is to get a clear organization of the different modules. The system settings should work with the minimum screen resolution of 1024 x 768px (mockups have exactly this size). To facilitate usability both alternatives got rid of hidden features and avoid using tabs, for instance. Furthermore, we want to provide options for a simple access to frequently needed system settings while keeping the full range of KDE’s configurability for advanced users. Modules should get cross-linked to provide fast access to related information. The idea is to have a flexible framework that allows future enhancements, e.g. a new module for motion sensing devices. Furthermore, the modules should have options for extension with predefined add-ons (eye candy, get hot new stuff, desktop exchange service). The mockups are geared to the visual design group (VDG) styleguide, though not using the recommended inkscape mockups.

Idea 1: Scrollarea

The first idea was made by anditosan and published in the forums. Albeit the draft focuses on KCM design it introduces a complete new top level navigation: Top-level categories are shown in a sidebar. On click, a subordinate sidebar opens with all sections that belong to this category. Every other content is shown at once in a scrollarea, but not unless it gets expanded explicitly. The modules arrange information in columns, sections are broke down by horizontal rules.


  • Easy to use (the idea is known from web design and usage is self-evident)


  • Placement of description (this first draft has no room left to show a description on the module level)
  • Limited length of labels (the design takes some space and needs at least an elaborated auto-alignment)

Some enhancements have already been proposed in the forum: the subordinate sidebar overlays the labels (implemented in the mockups) and every section gets an expander (not implemented because it doesn’t solve the use case simple vs. advanced).

Idea 2: Drill-down

The second idea brought up by Björn Balazs is to use a drill-down navigation. The sidebar offers access to other modules or sections on the same level. To dive into subordinate information, links are offered on the content page. The breadcrumb on the top makes it easy to go back to upper levels. If an option for a simple configuration is available, it is included directly alongside further navigation options on the content page. That makes it an integral part of the navigation.


  • Known (and yet reusable) sidebars are possible (list view with icons)
  • Very flexible (the navigation can be as deep as needed)
  • Efficient use of screen real estate for modules (even in case of smaller dialogs) with the option for descriptions


  • Unusual navigation for desktop software (however, drill-down navigation is a standard in web design)
  • More clicks are necessary to reach a certain module

The draft could be improved by better feedback by means on mouse over effect for icons (which are a matter of improvement too).


The advantage of one alternative is the drawback of the other. Either the navigation is flat with only two levels or you have to do more clicks. The one uses much space the other is more flexible. So please try it yourself. Open the mockups by clicking the pictures below and start exploring. Interactivity is available when the cursor becomes a ‘hand pointer’ (that is the symbol when you move the mouse over a link). Click it and see what happens. When you reach a decision please vote below for your favorite alternative.

Prototype ‘Scrollarea’

KDE system settings, alternative 'Scrollarea'

KDE system settings, alternative ‘Scrollarea’

 Prototype “Drill-down”

KDE system settings, alternative 'Breadcrumb'

KDE system settings, alternative ‘Drill-down’


Which type of navigation do you prefer?

View Results

Loading ... Loading ...

Next steps

Although the mockups look near to final there are still a lot of open questions:

  • Implement final organization of KCMs
    So far the categories and sections should be understood as a first draft. It was criticized, for instance, that ‘software’ is a rather unspecific category name.
  • Consider activities
    Plasma provides the awesome feature of activities which should be pushed a little more, however. The idea is to allow activity specific configuration for all (at least when it’s possible) modules included.
  • See-as-well links
    The idea to cross-link modules received some support in the ongoing discussions.
  • Bottom-bar button (Defaults, Undo, Apply, Cancel)
    Another issue is the bottom bar. Right now it depends on how the module was started – stand-alone or from the shell. This is not an example of good usability.
  • Design of control modules (e.g. clickable preview of color options)
    The shown mockups are only a small sample from the wide range of configuration options.

However, most important for the next steps is to discuss the project with developers in order to balance coding effort and benefit for UX. A first proof of concept has been made by Sebastian Kügler, which looks very promising.

0) { foreach ($sd_categories as $category) { array_push ($sd_result,$category->term_id);//<-- gendert von name zu term_id anpassungen ntig!! } } ?>