Sprung (zurück) zu: Gestaltung (Übersicht)

Openbox – Nutzer-seitige Steuerung von Programmfenstern, Arbeitsplatzgestaltung am Computer

Der Nutzen von Titelleisten, des Titelleistenmenüs. Kritik an Client-side decoration, Kritik an Gnome, Kritik an Wayland. Beispiele für ein am Nutzer und an Funktionen orientiertes Computer-Design unter Wayland.

Bedienung der Programmfenster via Tastatur: CSD erfordert stets Durchlauf via Tab-Taste.
„Traditionelle“ textuelle Menüführung indessen zeigt kurze Wege:
Alt-Taste + (markierten) Buchstaben der Rubrik in der Menüleiste drücken,
Menü der jeweiligen Rubrik öffnet sich,
sodann (markierten) Buchstaben innerhalb des geöffneten Menüs drücken.

CSD raubt „Platz“ für den „eigentlichen Inhalt“.

CSD raubt Funktionen für die Steuerung der Programmfenster.

CSD raubt Gestaltungsraum der Nutzer.

Über diesen Raubzug sollten diejenigen, die einen Computer mit einem Betriebssystem samt Programmen nutzen, besser heute schon nachdenken …

Die bemühten CSD-Argumente, Programmfenster unter Ausschaltung Nutzer-seitiger Fenstermanager frei von „Schlieren, Artefakte“ darzustellen und „mehr Raum für den eigentlichen Inhalt“ zu ermöglichen, sind unhaltbar.
Das erste Argument ist ein technisches Problem, das nicht zum Nachteil der Nutzer gelöst gehört.
Das zweite Argument ist schlicht falsch, das Gegenteilige ist der Fall.

Streifzüge ins Computerdesign

Doppelklick für ein Maximieren wird durch CSD erschwert, da diese Funktion der Fenstersteuerung auf der CSD-Kopfleiste vermengt wird mit der Menüführung der Programme.

Das Schlimmste an diesen CSD-Dingern ist und bleibt, dass massiv Funktionen der Fenstersteuerung entfernt werden, dass die Nutzer nicht mehr selbst über die Steuerung der Programmfenster sowie nicht mehr selbst die Gestaltung ihrer Arbeitsumgebung bestimmen können.

Das erstarrte CSD ist dysfunktional und hässlich – diese erstarrten, uniformen Rahmen und Farben in einer bemühten „Geschmacksneutralität", sie sind unveränderbar und bleiben für alle Zeiten abgrundtief hässlich. Jedes dumme, sich in Hybris übende Diktat, dem der Mensch sich gut begründet nun nicht beugen will, wird für alle Zeiten dumm, hochmütig sowie hässlich bleiben …

„Client-seitig“ wäre es Pflicht, den Nutzern freie Gestaltung über Rahmen, Farben, Schriften, Rahmen-Padding (…) anzubieten – Optionen der Gestaltung, meinetwegen „out-of-the-box“ – als eine Art „Client-seitigen Fenstermanager“ …
Obgleich es kein gutes Gefühl macht, die Gestaltung der Arbeitsplatzumgebung in fremde, „Client-seitige“ Abhängigkeiten zu wissen.

Die Erfindung von Fenstermanagern ist eine der besten Erfindungen innerhalb des Computerdesigns.

Die Nutzer-seitige Einrichtung der eigenen Arbeitsumgebung sollte gefördert, unterstützt werden.

Die Lösungen technischer Probleme durch Entfernen von Funktionen und von Gestaltungsräumen zum Nachteil der Nutzer sind keine Lösungen.

Video (3:23 Minuten:Sekunden)

Denkbare Alternativen

Beispiele für ein am Nutzer und an Funktionen orientiertes Computer-Design unter Wayland.

Nutzer entscheidet

Der Nutzer entscheidet, ob links oder rechts auf der Titelleiste ein Button mit der Aufschrift „Menü“ steht; oder, wenn der Nutzer es für besser befindet, stattdessen dieses „Hamburger-Menü“-Symbol steht.

Dieses Menü sei dann nicht weiter fest horizontal ausgerichtet (wie bei der „traditionellen“ Menüführung), sondern nach Größe des Programmfensters flexibel vertikal ausgerichtet – dies funktioniert optisch konsistent auf Desktop als auch unter Handyformaten, unabhängig von der Anzahl der Rubriken (vergleiche Rubriken bei exemplarisch Lxterminal mit LibreOffice).
Beispiele, Schema:

Auf/abrollen:

Menü Titel optional Button

Menü Titel optional Button

Titel-Menüleiste ein/ausblenden:

Inhalt

Vergleiche „Vollbild“ deaktivieren unter Bluefish: Tastatur / Rechtsklick Maus öffnet Kontextmenü: „Vollbild beenden“.
In diesem Kontextmenü stünde also: „Titel-Menüleiste ein/ausblenden“. Dies ist jetzt schon Programme übergreifend möglich:

  1. Titelleiste ausblenden,
  2. Menüleiste ausblenden,
  3. Statusleiste ausblenden,
  4. Werkzeugleisten ausblenden.

Je nach Bedarf …

Unter CSD indessen lässt sich nichts mehr ein/ausblenden.
CSD raubt Funktionen – und Platz.

Programm-Menü aufrufen, vertikal
(funktioniert so auch bei Handyformaten):

Menü Titel

Programm-Untermenü,
Beispiel Rubrik „Ansicht“:

Titel

Warum nicht: Bei großem Monitor / großen Programmfenstern die Option oder die Default-Einstellung, Menüleiste horizontal anzuzeigen und optional eingeblendet zu lassen:

Menü Titel

… mit entsprechend zu öffnenden Untermenüs.

Alternativ: „Titel-Menü-Leiste“ ausblenden, Menüleiste bei Bedarf ein/ausblenden sowie optional eingeblendet lassen; zweckmäßig etwa bei kleinen Monitoren, bei maximierten Fenstern sowie bei Tiling:

Die Programmfenster „springen“ dann nicht, weil die Fenster bei „Menüleiste ein/ausblenden“ nicht mehr respektive nicht weniger Raum einnehmen.

Mit Nutzer-seitig eingestelltem Padding am linken, rechten Fensterrand, so dass Größenänderungen des Programmfensters bequem und das Aufrufen des Programmfenster-Menüs (Titelleistenmenüs) flexibel möglich ist (bei Tiling bei Wunsch halt ohne Padding):

Menü Titel

Rahmen des Programmfensters sind optional Nutzer-seitig farblich anzugleichen oder zu entfernen, Fenster-Padding in der Breite und Farbe einstellbar – Rahmen, Farben, Bedienflächen in den Händen der Nutzer (unabhängig vom Default-Design).

Struktur anstelle von Beliebigkeit – in einem Detail-Tag – [bitte öffnen]

Klare Strukturen

Client-seitig bleiben klare Strukturen, wo die Funktionen des Programms einzuordnen sind – Nutzer-seitig bleiben klare, textuelle Strukturen für die Bedienung des Programms.
Client-seitig und Nutzer-seitig bleibt die Trennung zwischen „Inhalt und Design“, also zwischen Funktionen des Programms zu den Funktionen der Fenstersteuerung und Gestaltung.[1]

1. Bei Webseiten ist diese Trennung zwischen Inhalt und Design nun gepflegter Standard, um aus zahlreichen Gründen dem Missbrauch der Auszeichnungssprache HTML ein Ende zu bereiten.

Die Notlösung „Tooltips“ könnte weitergehend reduziert werden; nicht nur in Anbetracht der Bedeutung von Handyformaten eine für die Bedienbarkeit zweckmäßige Reduktion dieser ansonsten ungefragt erscheinenden (nicht selten tautologischen) „Zettel“.

Der Nutzer entscheidet, ob die Untermenüs bei Hover schon aufgehen, oder erst bei gezielter eigener Auswahl, also via „Klick“;
der Nutzer entscheidet, ob mit oder ohne Hover-Effekt; ob mit oder ohne zugeordneten Symbolen; ob mit oder ohne Angabe der Tastaturkombinationen (bei den Untermenüs).

Symbole, Icons sind als Stellvertreter für eine textuelle Benennung immer optional: Wer Symbole gerne nutzt oder für wen sie hilfreich seien, sollte die Möglichkeit deren Darstellung bekommen … wie diejenigen, die diese Bilder nicht benötigen oder eher als störend wahrnehmen die Möglichkeit bekommen sollten, sie zu entfernen.[2]

2. Aus sprachlosen Symbolen und Icons ist kein Fetisch zu machen, zumal nicht in deren Paarung mit Hover-Tooltips, vielmehr sei deren Meidung anzustreben, wo immer es zugunsten von Sprache möglich ist. Hier ist die „traditionelle“ Menüführung schon sehr gut aufgestellt. Es ist unsinnig, den zunehmenden Einsatz von irgendwelchen Symbolen als „modern“ verkaufen zu wollen.

„Titel-Menüleiste“

Auf dieser „Titel-Menüleiste“ steht neben diesem Menü-Button ein aussagekräftiger, informativer Titel:

Datei/Ordnername – Pfad (sofern verfügbar) – Programmname.

Titel ohne Verwendung von Fettschrift, ohne Tooltip.
Es ist zweckdienlich, wenn Titel in Schrift, Schriftstärke und Farbe Nutzer-seitig bestimmt werden.

Optional: Button für die Fenstersteuerung; Nutzer-seitig bestimmt, ob Programmfenster via textuellen Menü (Rechtsklick Maus) oder via diesen Button gesteuert werden; bei Button: freie Auswahl derjenigen Funktionen, die der Mensch anstelle des Titelleistenmenüs halt als Button bedienen will:

Diese Titelleiste respektive „Titel-Menü-Leiste“ samt Fenstersteuerung könnte weiterhin die Funktionen erfüllen:

Zuzüglich natürlich: „Titel-Menüleiste“ ein/aus, Maximieren, Minimieren, Schließen; Wiederherstellen.

Keine sachlich begründbare oder erforderliche Reduktion von Funktionen der Fenstersteuerung.

Wenn diese Funktionen nicht ins Gnome-Design passen, dann kann Gnome ja machen, was immer Gnome innerhalb Gnomes seinen Nutzern anbieten will …

Das einstellbare Rahmen-Padding erlaubt weiterhin das Aufrufen des Titelleisten-Menüs ebenda und bietet eine gute, personalisierbare Bedienfläche für Größenänderungen der Fenster via Maus,
nicht zuletzt für motorisch und in der Sehkraft eingeschränkte Menschen – oder schlicht für alle Nutzer gedacht, die die Dinge schlicht bequem, komfortabel bedienen wollen.

„Friss oder stirb!“

Der Nutzer entscheidet selbst, welche dieser Funktionen der Menüführung, Fenstersteuerung sowie Fenstergestaltung er nutzen will.

Desktop-Umgebungen können ja ihre eigenen Bedienkonzepte anbieten, wie sie es wollen – ihre Nutzer finden … oder eben nicht.

Debian-Gnome habe ich nicht installiert. Sondern Linux Mint Cinnamon, sodann Openbox: Ich nutze Linux Mint unter Openbox.
Ebenso Debian-netinst + Openbox, also ohne eine Desktopumgebung.
CSD verhindert Nutzer-seitig bestimmte Bedienkonzepte.
Das Konzept von CSD ist: „Friss oder stirb …“

Leitfäden

Bestehende Optionen einer Nutzer-seitigen Gestaltung der eigenen Arbeitsumgebung gilt es zu bewahren, zu fördern, zu verbessern, wo es möglich erscheint.

Hand in Hand mit den Nutzern, für eine „Modernisierung“ des Computer-Designs.

Der Leitfaden für Fragen des Designs laute, es seien keine Nutzer zu behindern, auszuschließen.

Funktionen zu entfernen, unveränderliche Bedienkonzepte durchzusetzen, sogar durchsetzen zu wollen, dies ist kein brauchbarer Leitfaden für irgendeine „Modernisierung“ … nicht einmal innerhalb einer noch so gut meinenden Desktop-Umgebung, geschweige denn übergreifend, wie es bei CSD der Fall ist.

Diktate anstelle von Optionen durchzuboxen, Nutzer de facto zu entmündigen, dies zeitigt – grundsätzlich zu denken – keine nachhaltige Entwicklung des Computer-Designs – zumal nicht innerhalb von „Linux“.

Anstelle des vorhandenen, notfalls historisch zu begründenden Raumes für Anpassungen von Seiten der Nutzer zu stärken und diesen Raum offen, zugänglich zu lassen, den Nutzern also zu helfen, diesen Raum betreten und selbst gut ausfüllen zu können – und dies als Kern-Aufgabe des Designs zu begreifen – zeigen sich mehr als nur unappetitliche Tendenzen, genau das Gegenteilige durchsetzen zu wollen.

Wenn der Designer die Nutzer als Ziel und Quelle entfernt, sollte der Designer zum Gedanken finden, sich besser selbst zu entfernen …

Wenn Lösungen eines technischen Problems zum Nachteil der Nutzer geraten, sollte der Techniker zum Gedanken finden, noch keine Lösung gefunden zu haben …

Die Videos zu den Openbox-Dateien – inklusive der Datei gtk.css.

Weiterführend:

Openbox, Installations- und Nutzungs-Varianten – Besonderheiten

Openbox – hilfreiche Links.

Ein Experiment – mit Kritik an Entwicklungen im Design (Video und Text)

Openbox, ein Werkzeug, für Distributionen und Programme – Video: Button versus Titelleisten-Menü … und die Frage nach Icons (Video und Text).
Seite 2: Openbox versus Gnome (Video und Text).
Seite 3: Openbox – Symbole und Sprache – Über die Funktionen von Programmfenstern und von Programmen (Anwendungen). Beispiele.

Client-side decoration … und Gnome-Zentrismus

Openbox – die Suche nach Titelleisten. Wege des Designs unter „Linux“.

Openbox versus Gnome – Symbole im Design versus textueller Menüführung; Beispiel Vollbildmodus. Wege des Designs unter „Linux“.

Openbox versus Gnome – Beispiele Funktionen Auf/Abrollen, Verschieben, Größe ändern. Wege des Designs unter „Linux“.

Openbox versus Awesome – Vergleich zweier Fenstermanager, Floating versus Tiling.

Openbox – hilfreiche Funktion „gmrun“ (Run-Funktion) – und selbst entscheiden: Titelleiste sowie Menübar ein/aus.

Openbox – Vergleich Floating / Tiling, Maus / Tastatur

Openbox – Layer: Immer im Hintergrund

Openbox – Nutzer-seitige Steuerung von Programmfenstern, Arbeitsplatzgestaltung am Computer.

Openbox – Nutzer versus Client-side decoration (CSD)