Openbox, ein Werkzeug
Kritik an Entwicklungen im Design von Distributionen und von Programmen (Anwendungen) insbesondere unter Linux.
Über das Video:
Taskleisten (Panels), Button, Symbole, Icons sowie Tooltips einschließlich Hover-Effekte sind Optionen:
Tooltips sind gar als Notlösungen zu sehen.
Das geschriebene Wort, die Erklärung einer Programm-Funktion via Sprache indessen sind Pflicht … notfalls via „Tooltip“ …
Zeige Beispiele des Designs anhand meiner Programmfenster und anhand der „Einstellungen“ des Programms Drawing im Gnome-Design.
[Textfassung:]
Design und Nutzer
Kurzfassung: Leisten, Button, Symbole, Icons sowie Tooltips als Optionen.
Funktionale Gestaltung von Programmen und Distributionen – Design als Wahlmöglichkeit …
Programm-Symbole oder Button, deren Aufgabe es sein soll, Funktionen von Programmen zu verbildlichen, brauchen Text, mindestens in der Form eines Tooltips, um den fragenden Nutzern Programm und Funktionen erklären zu können.
Icons und Programm-Symbole sind kein Ersatz für Schrift.
Ein Symbol-Button als „Dekoration“ bliebe ja unberührt, wenn das Symbol neben einem Wort stünde, einem Wort, das die Funktionen des Programms benennt.
Schrift versteht der Mensch … Symbole, Icons, Button übersetzt der Mensch in Schrift, damit er sie versteht.
Gestaltung orientiert sich am Menschen?
Schreiben wir mutig: Design stützt Inhalte und Funktionen – zum Beispiel beim Nutzen von Programmen eines Betriebssystems.
Design stützt das geschriebene Wort.
Ein gelungenes Design hilft den Nutzern, ein Programm am Computer besser zu verstehen, um es für die zugedachte Aufgabe gut nutzen zu können.
Behaupten wir einmal: Ein Icon anstelle von Text hilft nicht – es spart bestenfalls Platz und mag im „Handy-Zeitalter“ sogar irgendwie „normal“ erscheinen. Dennoch:
Selbst der Gnome-Desktop, der irgendwie als überdimensioniertes Handy erscheint, nutzt für die mit offenbar Leidenschaft gestalteten Symbole das gesprochene respektive geschriebene Wort: unter dem Symbol stehend, mitunter gekürzt, geradewegs abgebrochen in der zugedachten Breite des Symbols bis zerstückelt erscheinend – und / oder es erscheint das Symbol, dessen Erklärung via Tooltip bemüht erfolgt.
Text aber erscheint in diesen Formen selbst auf dem Gnome-Desktop noch unersetzbar beim Symbol, beim Icon, beim Button – damit die Nutzer die Bedeutung verstehen können.
Symbole, Button benötigen insbesondere Text, wenn Symbole, Button, Icons eine Funktion inne haben: Öffnen eines Programms, Kopieren, Druck aktivieren, verschieben, minimieren, maximieren … löschen.
Bei Dutzenden von Programmen und deren Programm-Symbolen machen diese Bemühungen rund um eine „textuelle Erklärung“ des jeweiligen Symbols nicht nur Sinn, sie sind notwendig: Kein Mensch kann sich die mittlerweile unzähligen verschiedenen Symbole und deren zugedachten Bedeutungen merken.
Und kein Nutzer will ernsthaft „experimentell“ Button, Symbole bedienen …
Text und Symbol – Symbol ohne Text – Text ohne Symbol
Button, Symbole ohne textuelle Infos sind bestenfalls Schmuck – und könnten folglich auch weg …
Das geschriebene Wort ist und bleibt der Anker für den Nutzer beim Öffnen von Programmen, beim Aufrufen von Funktionen.
Tooltips indessen und Icons, Symbole und designte Button gehören in die Kategorie „optional“. Denn die Sprache kommt prima ohne Hover-Fensterschen und bunten Bildchen aus – nur gewendet geht es nicht … Button ohne Sprache sind eine Zumutung.
Leider wurde die Entwicklung dieses Fenstermanagers zu früh eingestellt.
Dennoch: Er bleibt bis dato nutzbar.
„Bis dato“ als Einschränkung, weil die Tendenzen im Design heute von Betriebssystemen unter Linux zeitigen, dass Button und Symbole vor Text und sogar anstelle von Text den Nutzern vorgesetzt werden.
Dies betrifft u.a. aber insbesondere den Gnome-Desktop.
Der Fenstermanager Openbox erlaubt es also bis dato, Icons, Button, Symbole zu entfernen.
Für mich ein Segen! Auf meinem System – ich nutze u.a. Linux-Mint, Version derzeit „Vanessa“ – sind keine Icons zu sehen, weder im Menü des Betriebsystems, nicht im Menü der Programme, weder auf irgendeiner Titelleiste, noch im Submenüs von Programm-Fenstern.
Taskleisten – und andere Parkplätze für „Icons“
Die Ablage von Symbolen auf sogenannten Leisten oder Taskleisten erübrigt sich, wenn Leisten nicht genutzt werden, wie es das Grundprogramm von Openbox anbietet:
Leisten, Button, Symbole, Icons sowie Tooltips sind unter Openbox Optionen: Man kann derlei nutzen, wenn der Nutzer derlei braucht oder mag – oder weglassen, wenn derlei stört, nervt, den Arbeits- bis Spiele-Fluss am Computer erschwert …
Openbox macht jedes Icon und jeden Tooltip … und diese jenseits vom Handy nicht sterben wollende Hover-Effekte … zu einer Option – quasi überflüssig.
Da kann der Symbol- und Effekte-Designer gestalten, was immer er will …
Das Icon in der Titelleiste eines Programms, wie die Icons innerhalb der Menüs und Menübars von Programmen, die vorgeschlagenen respektive vorgegebenen Icons des Betriebssystems, sie alle sind Optionen und mit Hilfe u.a. von Openbox entfernbar. Wunderbar!
Steht ein erklärendes Wort neben einem Icon, bleibt die Funktion erhalten, wenn man das Icon entfernt. Symbolisiert das Icon alleine eine Funktion, wird es eng für den Nutzer …
Die Design-Kapriolen trauen sich noch nicht, die Funktion „Alles unwiederbringlich löschen“ als reinen Symbol-Button anzubieten – ohne auch nur eine zweite Nachfrage in Textform.
Warum nicht?
Die Entwicklungen im Design – schreiben wir einschränkend – unter Linux respektive von Seiten einiger Betriebssysteme sind zu hinterfragen.
Gthumb unter Gnome ist Pix unter Linux-Mint?
Ein Beispiel ist Gthumb unter Gnome, kompiliert von Linux-Mint bis Version „Victoria“ zu Pix:
Gthumb unter Gnome arbeitet neuerdings fast ausschließlich via Icons, die via Tooltips erklärt werden und aufgrund der Vielzahl dieser Icons den Nutzern auch erklärt werden müssen, will man nicht „experimentel“ seine Fotos bearbeiten, indem der Mensch diese Icons „probeweise“ durchklickt im Bemühen, sich die Bedeutung dieser Symbole dann für die nächste Runde zu merken.
Diese Button-Symbole haben Text nur noch als Tooltip – und beide können nicht entfernt werden zugunsten des geschriebenen Wortes.
Statt aussagekräftige Menübar und Menüs: bunte, designte Bildchen fürs „Hovern“, um bunte, designte „Tooltips“ zu sehen – die den Text liefern.
Diese Art der „Modernisierung“ lässt mich an kleine Kinder denken, die noch nicht schreiben können, Bilder aber können sie malen …
Pix indessen war und ist Gthumb – aber in der Menüführung mit Text, wenigstens bis Version „Victoria“.
Gthumb kompiliert von Linux-Mint zu Pix.
Ab Version „Victoria“ wird das textuelle Pix zu einer vom Gnome-Designern festgezurrten Ansammlung von Symbol-Buttons und deren Tooltips.
Diese Entwicklung(en) des Gnome-Designs schluckt auch die von Openbox beeinflussbare Titelleiste der Programme: Die Titelleiste existiert bei Gnome de facto nicht mehr. Programmfenster können nicht mehr eingerollt, sondern alleine noch minimiert werden, textuelle Informationen auf der Titelleiste sind reduziert, de facto entfernt.
Da Debian Grundlage für zahlreiche weitere Distributionen ist, sind die Einflüsse des Gnome-Design auf solche sogenannten Forks erheblich: Programme werden „für Gnome“ geschrieben und entwickelt.
Ein Programm duckt sich unter dem Vorgabe-Design einer der wichtigen Distribution unter Linux – und verändert nicht nur Gnome.
Text, der zweckmäßig einst auch in Gthumb neben Icons und Symbolen stand und Optionen der Nutzer-seitigen Gestaltung der Titelleiste nicht einschränkte oder gar verhinderte, übernimmt und bedient dieses „sprachlose“ Gnome-Design.
Ab Version „Victoria“ übernimmt auch (ausgerechnet) Linux-Mint dieses Gthumb-Design: Design-Vorgaben im Namen von Gnome.
Beispiel eines zweckmäßigen Menüs unter Pix vor der Version „Victoria“ bei Linux-Mint:
In dieser Ausführung von Gthumb respektive Pix entfällt dieses Hovern über irgendwelche Symbole zwecks Abfrage erklärender, textueller Tooltips – Hovern ist und bleibt eine Option, eine Notlösung, zumal im Zeitalter des Handys und Co., wo Hovern und Tooltips unbekannt, ja nutzlos sind …
Abkürzungen, Akronyme und derlei gehören (mindestens ein Mal) ausgeschrieben, also via Text erklärt: „Symbole“, „Hovern“ und „Tooltips“ helfen hier nicht.
Wenn Handyformate als Designvorlage herhalten sollen, dann in solchen Hinsichten: Schreibt Text, Designer dieser Welt.
Funktionen und Bedeutungen müssen in Textform verfügbar sein – darüber täusche mal auch nicht der Einsatz des „Hamburger Menüs“, das so langsam den Desktop erobern will, um vermeintlich all überall „Standard“ zu werden.
„Gnome-Design“ ist bald ein Synonym für inkonsistentes Design … obgleich das Gegenteilige behauptet wird.
Titelleisten-Menü und Symbol-Button
Titelleisten-Menü ohne Symbol-Button
Unter meinen Einstellungen unter Openbox sehe ich überall Text, keine Button-Symbole, ich vermisse diese Bildchen nicht.
Gewendet indessen würde ich den Text arg vermissen, sähe ich nur noch Symbole …
Button-Symbole sind wie Icons pure Dekoration … bestenfalls eine augenfällige Orientierungshilfe … für den Nutzer aber entbehrlich. Allesamt. Wenigstens entbehrlich, soweit es die Bedienung von Betriebssystem und Programmen betrifft.
Das via Rechtsklick der Maus (oder in Variante via der Tastatur) derzeit noch aufrufbare Titelleisten-Menü ist auch dann verfügbar, wenn irgendwelche Buttons auf der Titelleiste herumgeistern, deren Funktionen via schon erwähnten, nicht müde werdenden „Tooltip“ ihre Erklärung finden.
Dieses Titelleistenmenü zeigte bis dato stets dieselben Funktionen – bis Gnome es anders entschied, Funktionen ersatzlos strich: das Auf/Abrollen, das Verschieben von Programmen auf Arbeitsflächen.
Dieses Titelleisten-Menü ist in der Regel im Funktionsumfang umfangreicher, universell für alle Programmfenster, effizienter als es jede Button-Sammlung je sein wird.
Titelleistenmenüs sind stets ausreichend gut beschriftet, leichter zu bedienen – und selbst im Seitenbereich der Programmfenster aufrufbar, wenn das „Padding“ denn stimmt – was unter Openbox problemlos von Seiten der Nutzer anpassbar ist.
Der universelle Charakter des Titelleistenmenüs gibt Struktur und Orientierung – was Gnome da anbietet, macht diese Funktionen oder Eigenschaften des Titelleistenmenüs nicht besser, sondern zeitigt einen Rückschritt.
Was schlechter ist, sollte das Gute nicht ersetzen.
Auch jene Anpassbarkeit der funktional zu denkenden Rahmenbreite ist eine Eigenschaft der Programmfenster, die unabhängig vom Betriebssystem und Design zu bewahren ist.
Button auf Titelleisten samt Hover-Tooltip indessen sind optional, auch wenn daraus gern ein Fetisch gemacht wird und sich die Design-Kapriolen rund um Buttons und Icons gegenseitig überschlagen …
Anstatt zu bewahren, was gut ist und daran anzuknüpfen, „Modernisierungen“ in irgendeine Richtung, wie etwa das Streichen von Text zugunsten eines „Hamburger Menüs“, einer Menüführung des Handy-(Web-)Designs, welches zunehmend die Desktops erobert … und am Ende alles „sprachlos“ zurücklässt.
Ich warte schon auf die erste E-Mail, die ihren Inhalt hinter drei waagerechten Strichen verbirgt … und im Button-Style endet: VG … LG … MfG …
Symbol-Button versus Titelleisten-Menü
Charakteristika Button:
- Symbol „symbolisiert“ Funktion
- ohne Symbol nicht nutzbar
- kleiner Funktionsumfang
- an festen „Punkten“ aufzurufen (nicht flexibel)
- Hovern für Abfrage von Funktion via textuellen Tooltip
- wenig Platz für Titel-Bezeichnung (schmales Fenster)
Charakteristika Titelleisten-Menü:
- Text benennt Funktion
- mit oder ohne Symbole nutzbar
- großer Funktionsumfang
- an Fensterrahmen flexibel aufrufbar
- Hovern für Abfrage von Funktion nicht erforderlich
- viel Platz für Titel-Bezeichnung
Scroll-Leisten – Animationen von Werkzeugen
Dass so mancher Designer-Wille nur noch Kapriolen schlägt, zeigt auch die Entwicklung der Scroll-Leisten:
Deren „modernes“, sprich animiertes, penetrantes Erscheinen und Ausblenden, sobald die Maus im Arbeitsbereich unterwegs ist (und etwa bemüht einen Text verfassen oder lesen will) ist wie ein Hammer in der Werkstatt, den der Mensch just NICHT braucht, weil er mit der Säge arbeitet. Ein Hammer aber, der sich unbeirrt ständig via Blinken und Rufen anbiedert, sobald der Mensch die Säge, die Feile … bewegt, also am Werkstück (sprich Text oder Bild) arbeitet.
Wenn dieser Hammer dann auch noch seine Farbe ändert, sobald man ihn dann doch nutzt, es ist so überflüssig, wie es bei der Scroll-Leiste und dem Slider überflüssig ist – und nach Dutzenden Anwendungen verkommt dieses „dolle Design“ auch nur noch zu einem nervenden, jegliche Arbeit störendem Geblinke und Gezappel.
Warum wird es dem Menschen mit solcherart „Über-Design“ zunehmend schwer gemacht, sich konzentriert auf seine Arbeitsumgebung bewegen zu können?
Auch diese fummelige „Breite“ des Slider – wohl gedacht für den jugendlichen Feinmotoriker? – dient nicht seiner Grundfunktion: Dem Nutzer es zu ermöglichen, sich rasch Inhalte zu erschließen …
Wenn Design Arbeitsumgebungen beschwert
Pix ist leider ab der Linux-Mint-Version „Victoria“ wie Gthumb unter Gnome:
Die Orientierung und Struktur gebende Titelleiste des Programmfensters wurde umfunktioniert zu einer von vielen Bedienflächen eines Programms, wohl entstanden an irgendeiner nackten Konsole irgendeines Nerds, der den Rest der Menschheit via seinen Design-Spielereien mit dem quälen will, was er selbst im „produktiven System“ nicht nutzt.
Button und Symbole des Programms „Pix“ sind bei Linux-Mint wieder ohne Text, wie dieses aktuelle „Gthumb“ unter Gnome.
Was für ein Rückschritt in der Design-Entwicklung …
Tooltip-Text wird dann obligatorisch in dieser Button-Wüste, somit wird auch der Linux-Mint-Nutzer gegängelt, „Herum-Hovern“ zu müssen.
Gestaltungsoptionen werden verhindert: bald chancenlos für den Nutzer, es für sich gut anzupassen, etwa via Openbox oder einer eigenen CSS-Datei, was bei Pix zuvor problemlos möglich war.
Und obgleich sich Linux-Mint nicht zuletzt wegen diversen, hier nicht zu wiederholenden Design-Streitigkeiten von Debian verabschiedete, springt Linux-Mint ab Version „Victoria“ nun via Anpassung von Pix an Gthumb-Gnome genau dort wieder zurück: Festgezurrtes, hochmütiges, ja geradezu dümmliches Programm-Design, das sich vermeintlich „intuitiv“ (Zitat Mint) via Button-Häufungen samt Tooltips allen Nutzern wohl noch irgendwie erschließen wird.
Keine Verbesserung der Nutzbarkeit also, sondern Design-Klötze, die den Nutzer vor die Nase gesetzt werden … Microsoft und Apple lassen grüßen.
Solche Design-Entwicklungen indessen sind wider diesem Geist von Linux.
Sie sind wider dem Geist jeglichen Designs.
Das Menüs und Menübars aus Programmen wie Pix (Taschenrechner-Gnome, ja sogar von Firefox) verschwinden und stattdessen schier unveränderliche „Symbol-Leisten“ angeboten werden, ist eine mehr als ärgerliche Entwicklung im Computer-Design unter Linux.
Ein zweckmäßiges, hilfreiches, verstehbares, bedienbares Menü:
Was da reitet in den neusten Design-Entwicklungen unter Linux, es hat nichts mit irgendeinem „Windows (Nutzer)” zu tun, dem man sich anbiedern will, vielmehr erscheint es als Kind eines mangelhaften Nachdenkens und Umsetzens von Grundsätzen des Designs, das Funktionen und den Menschen als Orientierung haben sollte.
Dabei könnte Linux am Desktop hier Vorreiter werden! Und den beiden Protagonisten „Microsoft und Apple“ zeigen, wo der Hammer (samt Säge) in der Designer-Welt hängt!
Denn derzeit hat Openbox noch relative Kraft genug, dummes Zeugs von Designern wegzuwischen und Betriebssystem samt Programme nutzbar zu halten oder wieder nutzbar zu machen …
Aussichten …
Wäre ich kein Rosenbauer, sondern Entwickler mit ausreichend Kenntnissen in diversen Programmiersprachen, es wäre für mich die denkbar reizvollste Aufgabe, ein solches universell einsetzbares „Design-Programm“ zu entwickeln, wie es Openbox in seinen Anfängen zeitigte … es würde mir Spaß bereiten, im Dienst der Nutzer von Betriebssystemen und Programmen weltweit unterwegs zu sein … soweit es mindestens „Linux“ betrifft. Es wäre mir ein Genuss, mir diesen Brocken aufzuhalsen, ein Programm anzubieten, das etwa alle Gnome-Designer-Träume von der eigenen Arbeitsumgebung gnadenlos wegwischt …
Es bleibt mir leider nur der Appell solcher Texte … mein bemühtes Erlernen von Programmiersprachen … und die Hoffnung in die Zukunft eines Nutzer von „Linux“, nicht in den Design-Vorgaben irgendwelcher „Standard-Nerds” zu enden, Nerds, die auf ihren Konsolen mit der Gestaltung von Werkzeugen und Arbeitsumgebungen herumspielen im Glauben, den Nutzern zu dienen …
Weiterführend, ergänzend:
Openbox, Installations- und Nutzungs-Varianten – Besonderheiten.
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.