KScreen: Vorschlag für eine neue Oberfläche

Basierend auf Ergebnissen der Umfrage zu Anforderungen für Bildschirmkonfiguration stellen wir ein neues Konzept für eine Bedienoberfläche von KScreen vor.

Wie in KScreen: Ergebnisse der Umfrage berichtet, werden alle Funktionen zur Konfiguration von Bildschirmen benötigt, manche jedoch häufiger als andere. Dies betrifft insbesondere die Aktivierung von Displays und die flexible Positionierung der Ansichten. Häufig wird dann ein Tool gebraucht, wenn Bugs auftreten. Daher ist der Ansatz von KScreen sinnvoll, sich selbst weitestgehend unsichtbar zu machen und im Hintergrund zu arbeiten.

Anforderungen

Auf Grund der Ergebnisse der Umfrage und Diskussionen mit Anwendern würden wir die folgenden Anforderungen ableiten:

Funktionale Anforderungen (nach Relevanz sortiert):

  • Aktivieren bzw. Deaktivieren von sekundären Bildschirmen
  • präzise und freie Positionierung der Ansichten
  • Einstellung der Auflösung
  • Auswahl des primären Bildschirms
  • Änderung der Ausrichtung
  • Einstellung der Bildwiederholrate
  • Identifizierung der Bildschildschirme

Nicht-funktionale Anforderungen

  • Persistenz: Speichern der Einstellungen und automatische Wiederherstellung
  • Flexibilität: die individuelle Anpassung aller Optionen ist möglich
  • Einfachheit: die Konfiguration von Bildschirmen wird selten vorgenommen

KScreen macht in der gegenwärtigen Version 1.0 intensiven Gebrauch von selbst gestalteten Steuerelementen (custom controls). Die meisten Interaktionen sind versteckt und über Popup-Elemente erreichbar. Dies hat den großen Vorteil eines klaren UIs, allerdings mit dem Nachteil, dass Accessibility und Transparenz leidet. Zum Beispiel muss zum Rotieren im Uhrzeigersinn das Icon mit dem Pfeil in entgegengesetzter Richtung rechts geklickt werden. Außerdem ist die Platzierung von Steuerelementen auf den Panels problematisch. Es besteht die Gefahr, dass Anzeigen verdeckt werden. Zugriff auf die Steuerelemente ist nur durch Verschieben der überlagernden Panels möglich, was zugegebenermaßen sehr einfach ist.

Das bisherige Kontrollmodul „krandr“ (das entsprechende Modul in den KDE-Systemeinstellungen) stellt alle Funktionen per Standard-Steuerelement zur Verfügung, lässt aber trotzdem eine Übersichtlichkeit vermissen. Der rechte Bereich hat keine Funktion außer der Anzeige der gerade eingestellten Parameter. Die Positionierung der Ansichten wird nicht besonders gut unterstützt und viele Funktionen sind eher eigenartig. Andererseits ist dieses Interface bekannt und entspricht den Anforderungen von Laien wegen der Nutzung von standardisierten Steuerelementen. KRandTray KScreen Abbildung 1: Vergleich der aktuellen UIs: das überholte krandr links und kscreen rechts.

Wir empfehlen daher, das konventionelle Layout mit einem Editierbereich auf der linken Seite und einer graphischen Repräsentation rechts beizubehalten. Das neu eingeführte Feature der freien Positionierung von Ansichten wird von den Anwendern sehr geschätzt und sollte mit den Standardeingaben kombiniert werden.

UI-Vorschlag

Wir stellen unseren Vorschlag in Abbildung 2 zur Diskussion. Auf der rechten Seite werden so viele Panels angezeigt, wie Ansichten am Computer aktiviert sind. Die Größe der Panels richtet sich nach der gewählten Auflösung und Ausrichtung des Displays, die Beschriftung entspricht dem Namen des Monitors.

Die Anwender können die Panels frei bewegen (inklusive der Snap-Funktion), wobei jederzeit eine redundante Konfiguration über die Standardsteuerelemente möglich ist. Zusammen mit den anderen Optionen (d.h. Auflösung, Bildwiederholrate, Ausrichtung, Auswahl des Primärbildschirm, Aktivieren des Displays) ist diese Funktion linkerhand verfügbar.

Die Sequenz der Steuerelemente folgt dabei aus zwei Gründen nicht nur der Relevanz: die Wahrnehmung wird unterstützt, wenn die gleichförmige Darstellung aufgebrochen wird. Würden alle Drop-down Elemente direkt untereinander platziert werden, würde das Auffinden des richtigen erschwert werden. Der zweite Gedanke bezieht sich auf den sogenannten Primacy/Latency-Effekt. Das erste und das letzte Element werden im Gedächtnis höher priorisiert.

Abbildung 2: Mockup für den UI-Vorschlag.

Abbildung 2: Mockup für den UI-Vorschlag.

Rationale für die Steuerelemente

  • Bei der Auflösung kann aus einer begrenzten Anzahl fest vorgegebener Werte einer ausgewählt werden (wenn keine beliebigen Werte möglich sind). Üblicherweise wird dabei der Maximalwert ausgewählt. Dies ist eine prototypische Anwendung für Slider. Alle verfügbaren Größen innerhalb des kleinsten und des größten Wertes sollten als Teilstriche angezeigt werden, die Beschriftung zeigt den gewählten Wert. Eine Änderung der Auflösung bewirkt eine unmittelbare Anpassung der jeweiligen Panelgröße im rechten Bereich.
  • Die Bildwiederholrate eines Displays kann aus einer sehr kleinen Menge ausgewählt werden und wird nur sehr selten verändert. Deshalb bietet sich ein einfaches Drop-down an, das den gewählten Wert anzeigt.
  • Der Hauptbildschirm stellt eine exklusive Auswahl eines Items aus einer kleinen Menge dar. Dies wird am besten durch Radio button umgesetzt bzw. eine Gruppe von Radiobutton, die über die Displays miteinander verbunden sind. Wenn nur eine Anzeige aktiv ist, sollte diese ausgewählt und deaktiviert sein.
  • Die Position der Ansichten kann im rechten Bereich frei angepasst werden, aber auch eine redundantes Setup über Standardsteuerelemente soll möglich sein. Zur Vereinfachung dient eine grundlegende Auswahl des Setups, bei der eine freie, absolute Positionierung, eine relative Positionierung oder ein Klonmodus ausgewählt werden kann – entsprechend der gegenwärtigen Implementierung. Die absolute Positionierung ist mit Spin edits verbunden, in denen Werte für die Verschiebung auf der x- und y-Achse eingegeben werden können. Sowohl eine Änderung dieser Werte als auch ein Verschieben der Panels auf der rechten Seite bewirkt eine Aktualisierung der jeweils anderen Elemente.
  • Bei der Ausrichtung kann einer aus vier möglichen Werten ausgewählt werden. Dies wird am besten durch ein Drop-down realisiert. Da viele Menschen mit links/rechts Probleme haben, empfiehlt sich eine Darstellung der resultierenden Ausrichtung über Icons.
  • Die am häufigsten genutzte Option ist das Aktivieren eines Displays. Nur eine check box ist hierfür sinnvoll (deren Zustand die assoziierten Steuerelemente ebenfalls aktiviert bzw. deaktiviert).

Plasmoid

Das KScreen Projekt beinhaltet auch eine kleine Anwendung für den Schnellzugriff. Jedes Symbol in der Taskleiste (tray icon) sollte auf einen Linksklick die zugehörige Anwendung öffnen und auf einen Rechtsklick ein Kontextmenü mit den wichtigsten Funktionen aufklappen. Hinsichtlich der Bildschirmeinstellungen ist dies die Aktivierung von Displays. Das Menü von KScreen sollte dementsprechend ‚KScreen starten‘ enthalten (das erste Menüitem sollte zur Redundanz immer die Standardaktion zur Verfügung stellen) und eine Checkliste mit allen angeschlossenen Displays beinhalten.

KCM-KScreenTray

Abbildung 3: Beispiel für ein Schnellzugriff-Plasmoid.

Wird eines der Items ausgewählt, wird das Display sofort an- bzw. ausgeschaltet und, wenn verfügbar, die letzten Einstellungen wiederhergestellt. Es sollte jedoch beachtet werden, dass nicht alle Displays aus Versehen deaktiviert werden können.

Zusammenfassung

Der wichtigste Aspekt von KScreen findet unter Haube statt: eine halbautomatische Konfiguration, die zuverlässig wiederhergestellt wird, wenn bekannte Displays angeschlossen werden und die auch eine gute Vorgabe bei neuen Geräten liefert. Anwender wollen so wenig im Konfigurationsdialog arbeiten müssen wie möglich, jedoch auch in der Lage sein, die Standardeinstellungen entsprechend ihrer persönlichen Bedürfnisse und Vorlieben zu überschreiben. Der Dialog wird daher eher selten genutzt und muss seine Funktionalität transparent präsentieren, damit auch ohne Einarbeitung eine Bedienung möglich ist.

Der Vorteil von Standard-Steuerelementen (und dadurch auch einem eher konventionellen Layout) ist, dass die Interaktionen vertraut sind. Zum Beispiel hat ein Button nicht nur ein Klick-Ereignis, es zeigt auch spezifische Informationen beim Bewegen der Maus über den Button (hovering) und beim Fokusieren an, liefert eine klare Rückmeldung, wenn er deaktiviert ist, und entspricht individuellen Einstellungen bzw. Vorlieben per Themes. Anwender wissen, wie man einen Dialog bedient, auch wenn sie noch nie damit zu tun hatten. Durch Standardelemente kann der Dialog auch von behinderten Menschen bedient werden und benötigt keine erweiterte Einleitung für Anfänger.

Als zukünftige Erweiterung von KScreen wäre es auch wünschenswert, dass der Anwender allgemein definieren kann, wie mit neuen und unbekannten Displays umgegangen werden soll. Dadurch würde KScreen vom Anwender noch seltener gebraucht werden, seine Arbeit jedoch im Hintergrund verrichten und damit gleichzeitig mehr Relevanz für einen angenehmen Umgang mit dem System haben. Wir sind immer an Kommentaren interessiert. Also nehmt an der Diskussion teil… (auf Englisch bitte).

PS: KScreen_Mockup made with Balsamiq.