By Björn Balazs
Based on the results of the user survey published in the last posting we introduce a new layout for the future KScreen UI.
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
- 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).
- 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.
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 …[more]
Source: FULL ARTICLE at Planet KDE