KScreen: Proposal for the user interface

We present our first suggestion for the future KScreen UI based on the results of the survey about requirements.

As reported in the summary of our screen management study, all features of screen management are needed, but some are used more frequently than others. Especially activation of monitors and flexible positioning of views are important for users. Often, however, the use of a screen management tool is purely required due to bugs. The overall approach of KScreen to make screen management more or less invisible seems to be worthwhile.


Based on the survey and discussion with users we would derive the following requirements:

Functional requirements (sorted by relevance):

  • enable /disable secondary display(s)
  • precise and flexible positioning of views
  • adjustment of resolution
  • selection of primary display
  • change of orientation
  • setup of refresh rate
  • identification of displays

Non-functional requirements

  • persistence: saving of settings and automatic restoration
  • flexibility: users should be able to adjust all features freely
  • simplicity: configuration of screens is a seldom used function

The current version of KScreen makes extensive use of custom controls. Most interaction is hidden from the user by pop-up controls. This has the big advantage of a clear UI. The trade-off, however, is a lack on accessibility and transparency. For instance, to rotate a view clockwise the user has to right click the icon with the anticlockwise open circle, which is close to non-discoverable. Additionally, when using two panels one can overlap and cover the other. The user has to move the top panel first – and hence change its position – to be able to alter settings in the panel below. This is not unusable, but cumbersome and can lead to confusion, when the user cannot find the second connected panel in the interface.

The legacy (standard before 4.11) module ‘krandr’ on the other hand provides all features via standard controls but lacks on lucidity. The right pane does not provide any functionality except the preview of the configured layout. The positioning of views is not supported well and many functions are rather weird. But on the other hand the layout is well known and suits novice’ needs better due the use of standard controls (cf. figure 1). KRandTray_en KScreen_en

Figure 1: Comparison of current UIs: krandr (the legacy KCM) on the left and kscreen on right hand side.

Therefore, we recommend to keep the conventional layout with an editing area left hand and a graphical representation on the right. The enhancement of free floating panels introduced by KScreen is highly appreciated by the users – so it makes sense to combine the best of both tools.


You can find the proposal we would like to discuss with you in figure 2. There are as many panels shown on the right hand side as there are displays connected to the computer. The panel’s dimension match the actual resolution and orientation, and are labeled according to the respective monitor.

Users can adjust views’ position by moving panels freely within this area (including the snapping feature), but a redundant configuration per standard control is possible as well. Together with all other options (i.e. resolution, refresh-rate, position, orientation, to select the primary screen, and to active the view) this function is located in the left-hand panel.

Figure 2: Mockup with the proposal for a new UI.

Figure 2: Mockup of proposal for a new UI.

The order of controls obviously does not follow their relevance for the user. Two considerations have lead to this decision: Perception in general is facilitated when the uniformity of the presentation is broken up. If all drop-down controls are placed below each other it is hard to spot the right one. Secondly, we have to consider the so called primacy / recency effect, which (roughly) states that the first and the last item of a list are prioritized in memory.

Rationale for choosing the interface elements

  • The resolution consists of a limited set of options with fixed steps (unless arbitrary values are possible). Usually, the maximum value is chosen. This is a typical application for a slider. Provide steps for all possible values between the lowest and the highest resolution, and show a caption with the selected option. When users change the resolution the respective right-hand panel should be adjusted immediately.
  • The refresh-rate of a view can be chosen from only a few options and is very rarely changed. Therefore, a simple drop-down would be a good choice to show that configured value.
  • The primary view is a mutually exclusive choice of one item out of a few options. It is best represented by a radio button, or rather a group of radio buttons associated over views. If only one view is activated the option should be checked and disabled.
  • The orientation of a view can be chosen from only four options. The best way to provide this feature is a drop-down list. Since many people struggle with left/right it is recommendable to identify the resulting orientation by icons.
  • The position of views can be adjusted freely be shifting the right-hand panels, but as well a redundant setup via standard controls should be possible. As a convenience feature the basic setup can be chosen from absolute position, clone of, and any type of anchoring in respect to another view – just as in the current KCM implementation. The absolute positioning is associated with spin edits to enter a certain value for moving a view on the x or y axis. Both, moving the right-hand panels as well as changing the absolute values are linked together and updated immediately.
  • The most used action is to switch a view active. Only a check box makes sense (whose state enables or disables all other items) to toggle an option on or off.


The KScreen project includes a small application for fast access. Any tray icon should open the application on left click and pop-up a menu with the most important functions on right click. In respect to display settings the most used function is to toggle a view on or off. Therefore the menu of kscreen’s tray plasmoid consists of ‘Start KScreen’ (the first menu item should always provide the default action for redundancy) and a check box list with all connected displays.


Figure 3: Example for fast access plasmoid.

Checking an option toggles the display immediately on or off, and restores the last setting including position of views. It should not be possible to switch all displays off, however.


The most important aspect of KScreen is under the hood: semiautomatic setup that is reliably restored on the connection of known devices, together with a good guessing of how a new screen should be configured. Users do not want to get bothered with configuration dialogs but want to be able to override defaults to their individual needs. The dialog is used on rare occasions only and should present its functionality clearly to allow handling without practice.

The advantage of using standard controls (and thereby a more conventional layout) is the familiarity with the interactions. For instance, a button does not only have a simple mouse click event but it shows as well information on hovering and on focusing, it provides clear feedback when disabled, and it fits user preferences with themes. Users know how to operate such a dialog even if they never used it before. It is accessibly even for people with handicaps and does not need much introduction for novices.

As an outlook for the future of KScreen: It would be beneficial to introduce a way for users to define how a newly connected, but unknown screen should be configured. This way using KScreen will be even less necessary for many users – and as we all know, the best interface is the one the user never needs. We are always interested in your comments. So join the discussion… PS: KScreen_Mockup made with Balsamiq.

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