Symbol versus Sprache, Icon versus Text?
Über die Funktionen von Programmfenstern und von Programmen (Anwendungen). Eine Kritik an Entwicklungen im Design unter Gnome.
Beispiele des Designs anhand der Programme Blusfish (Editor, IDE) und Pix (Bildbearbeitung), was gut erscheint, welche Probleme bestehen – und wie es möglicherweise besser gestaltet werden könnte.
Video:
Text der Originalfassung des Videos, etwas angepasst
[Textfassung 20. Dezember 2023 erweitert um:
Werkzeugleisten im Design.]
========== Design und Funktion von Programmen (Anwendungen)
Beispiel: Bluefish (IDE) – für u.a. Websites …
Symbole respektive Button:
- deren Funktion ist nicht immer eindeutig
- deswegen werden „Tooltips“ verwendet, die textuell die Funktion benennen
- die Symbole erklären sich halt NICHT von selbst; hierfür einige Beispiele …
- fehlt die Info, etwa via Tooltip, kann der Mensch nur raten,
welche Funktion hinter dem Symbol steht …
- diese Unklarheit passiert bei der Verwendung von Sprache eher selten …
- alle Funktionen, die durch Symbole angeboten werden,
findet der Nutzer leichter im „klassischen“ MENÜ / MENÜBARS
- diese Menüs sind in Text verfasst: die Funktion erklärt sich quasi selbst …
ein zugeordnetes Icon / Symbol ist optional … bestenfalls Dekoration …
vielleicht hier und da eine Erinnerungsstütze …
Beispiele von meiner Arbeitsumgebung, Menü und Menübar beim Programm Pix
(da sind keine Icons zu sehen, die erkennbaren Icons Firefox und Bluefish,
es sind Fotos für diese Website):
Anders bei Bluefish in einer der Seitenfenstern – regelrechte Symbol-Wüsten
unter der jeweiligen Rubrik (hier Rubrik „Standard“):
- die Anhäufung der Symbole in der Spalte allein zur Rubrik „Standard“:
Wissen Sie diese Symbole in deren Funktion zu benennen?
Sagen Sie sich selbst die Funktionen der gezeigten Symbole auf …
Warum nicht so:
Beispiel Pix, Bildbearbeitungsprogramm unter Linux-Mint – ZEIGE
Solche Symbole haben eigentlich KEINE Funktion mehr, sobald sie via Text erklärt SIND
– sie sind dann bestenfalls Dekoration (oder: sie könnten auch weg …)
Bei Bluefish:
Warum stehen hier die Funktionen der Symbole nicht in Textform daneben, wie bei Pix?
Platz genug wäre ja! ZEIGE
[Nebenbei:
dieses Verschieben der Fenster zueinander innerhalb eines Programms
sollte als Funktion den Nutzern deutlicher gemacht werden,
etwa durch eine mehr oder weniger dezente Handleiste
wie es im alten GTK, etwa bei PCmanFM, Gimp, Recoll noch verfügbar war]
„Alternativer“ Aufbau einer Programm-Funktion:
Es könnte sogar so sein, dass
links das Symbol steht,
recht die Textfassung
und Tooltips (wenn sie denn eingesetzt werden)
ZUSÄTZLICHE Erläuterungen zur Funktion geben.
Nichts ist dümmer als ein Tooltip, der nur wiederholt, was als Text da schon steht …
Besser aber als jeder Tooltip ist allerdings das sogenannte Detail-Tag,
das im Webdesign eingesetzt wird … (ZEIGE ICH NOCH)
Tooltips werden via Hovern aufgerufen – dies aber geht auf Handy und Co. nicht …
Detail-Tags indessen lassen sich anklicken – dies kann auch auf dem Handy bedient werden
(wie diverse Menüs ja auch).
Denkbar wäre für die Symbolanhäufung
auf der linken Seite hier bei Bluefish (siehe oben) folgender Aufbau:
Links das Symbol,
sodann die Textfassung,
sodann ein kleiner Button [Pfeil + „Info“] – oder so ähnlich:
Klickt der Mensch auf das Symbol und / oder auf den Text,
aktiviert er die zugedachte FUNKTION.
Versteht er aber weder das Symbol noch die kurze Textfassung:
dann klickt er auf den Button [Pfeil / „Info“]
– und bekommt (ähnlich wie bei einem Tooltip) weitergehende Informationen …
dies funktioniert dann auch auf dem Handy und Co. …
Folgendes Beispiel:
Auf „[Info]“ klicken – Detail-Tag geht auf:
(Klick auf „Bluefish“ öffnet natürlich hier kein Programm,
aktiviert auch keine Funktion,
es führt Sie zu meiner Startseite – auch gut)
Müsste man alles noch etwas feiner machen … aber das Prinzip steht …
Denkbar wäre anstelle von „Pfeil + Info“ nur ein Pfeil,
der signalisiere, dass es da etwas zu „klicken“ gibt …
dies wäre denkbar, wenn diese reduzierte Darstellung
„Konvention“ würde … und „jeder“ weiß,
was es mit dem kleinen Pfeil auf sich hat.
Der Vorteil dieser Detail-Tags:
braucht man die zusätzliche Information zu Symbol und Text nicht,
weil die Funktion bekannt ist, erscheint auch nichts ungefragt
– wie es leider beim Tooltip häufig der Fall ist.
„Tooltips“, die einem endlos und immer wieder
„Schließen-Button“ erklären …
oder das Firefox „Zugang ins Internet“ als Funktion hat …
Auch bei umfangreichen WERKZEUGLEISTEN
– etwa bei den Programmen Gimp oder LibreOffice –
könnte der Aufbau sein:
SYMBOL (wenn es denn sein soll) + TEXT = Funktion (aktivieren)
+ „Pfeil-Info“ = („Mach mich schlauer“-Funktion)
Die Anordnung solcher „Werkzeugleisten“
innerhalb des Programmfensters müssten gewiss neu gedacht werden:
etwa links oder rechts vom Inhalts-Fenster als Liste
– wie es ja auch von diversen Programmen schon angeboten wird …
und in Dateimanagern als Verzeichnisbaum bekannt ist …
In solch einem Detail-Tag muss keine „Betriebsanleitung“ stehen,
also kein ellenlanger Text.
Eine kurze, hilfreiche Ergänzung zur textuellen Fassung des Funktionsbutton genüge …
Diese Detail-Tags würden dann ähnlich funktionieren wie im „Hamburger Menü“,
etwa wie bei Pix , der kleine Pfeil neben dem „Hamburger Menü“ genügt ja vielleicht …
Anstelle des „Hamburger Menü“-Symbols dann halt die Funktion als Text
[„Alles unwiederbringlich löschen“]
Also:
Symbol + Text (Wort, das die Funktion benennt) + kleiner ↓ (passend zum Design halt)
„Hamburger Menü“ = die waagerechten Striche oben links,
hier mit einem kleinen nach unten weisenden Pfeil …
GRUNDSATZ (vielleicht):
Solange eine textuelle Erklärung der Funktion erforderlich ist,
solange braucht es KEINE Symbole für die Darstellung der Funktion …
Wem es gefällt, hat oder lässt diese Dinger – andere Nutzer machen sie dann weg …
Die Krux:
Symbole BRAUCHEN Text – und sei es als Tooltip …
Text indessen braucht kein Symbol …
NIEMAND kann sich all diese kursierenden Symbole
und die dahinter liegenden Funktionen merken:
Sprache indessen versteht und merkt sich schon besser …
Die gezeigten Symbole sind auch nur ein Ausschnitt dessen, was
die Nutzer von sich aus innerhalb etwa des Programms Bluefish
diesen oder allgemein solchen Spalten hinzugeben könnten!
In Textform indessen ist dies alles viel einfacher anzusehen und zu verstehen,
um sich die Funktionen eines Programms, einer Anwendung zu erschließen
– wie auch beim gezeigten Beispiel eines Detail-Tags:
UNIVERSELL mag etwa das Symbol für eine Toilette sein (obgleich ich auch das bezweifel)
DIE SPRACHE indessen ist universell:
bei Debian dieselbe wie bei Mint, wie bei Apple,
wie bei ……… (trotz aller potentieller Missverständnisse …)
Die Symbole indessen in diesen Betriebssystem-Welten sind kaum universell,
man gewöhnt sich an diesen oder jenen Bildchen …
sie aber unterscheiden sich schon oftmals innerhalb eines Betriebssystems …
Und es kommen immer weitere Symbole, Icons hinzu,
ganze Familien von Symbolen und Icons, die auf dem Markt angeboten werden …
– zum „downloaden …“, wenn der vorhandene Icon-Satz nicht gefällt …
Na bitte …
Eine AUFGABE AN DAS COMPUTER-DESIGN könnte möglicherweise sein:
Wo könnten Tooltips zugunsten von Text weg …
ZWEITENS:
Bluefish und Pix machen es vorbildlich:
In der TITELLEISTE steht
die Datei / der Order,
sodann der Pfad,
sodann der Name des Programms
(mitunter + Versionsnummer): ZEIGE
Dies schafft Orientierung. (Auf allen Fenstern …)
Insbesondere bei verkleinerten Fenstern
– seien sie eingerollt oder auf irgendeine Leiste geparkt –
es schafft Orientierung.
Wer will, setze halt ein Symbol, ein Icon an den Anfang …
… oder eben NICHT …
mit Icons und ohne (wie ich es gerne nutze):
Diese Einstellung ist unter Openbox
mit dem Eintrag eines Buchstabens in der rc.xml-Datei bestimmbar:
NEBENBEI (respektive deutlich gesagt):
Diese Funktionen der Titelleiste
sind beim Gnome-Design von Debian
de facto entfernt worden:
- Das Einrollen der Fenster wurde kurzerhand gestrichen
- das Aufrufen des umfangreichen Titelleisten-Menüs ist unter Gnome „kastriert“ …
- Angaben wie „Dateiname + Pfad der Datei + Programmname“
existieren unter Gnome nicht mehr … kein Padding einstellbar und vieles mehr …
Dabei sind:
- Titelleiste
- Angaben auf der Titelleiste
- Nutzung des vollständigen Menüs
- sowie die Funktion des Einrollens von Fenstern … und vieles mehr!
geradezu PFLICHT
ZEIGE das Einrollen … das Minimieren (ohne Leiste!) (im Video)
Anhand dieser Beispiele kann auch deutlich gemacht werden,
dass zwischen den
FUNKTIONEN DER PROGRAMM-FENSTER
(bei Openbox in den Dateien rc.xml, .thermerc umfangreich einstellbar)
und den
FUNKTIONEN DER PROGRAMME
zu unterscheiden ist:
DIESE UNTERSCHEIDUNG SOLLTE BEWAHRT BLEIBEN.
GNOME von Debian missachtet diese Unterscheidung
einfach mal so
aus dem Designer-Bauch heraus …
Braucht kein Mensch!
Solche Praktiken
machen es den Nutzern
nur schwer(er), obgleich
das Gegenteilige bei Debian-Gnome
behauptet wird …
===== Ende
===== und Fazit
Wer ein Betriebssystem samt Design „out of the box“ nutzen kann und will: Fein.
Design orientiere sich am Menschen.
Offenbar hat der Designer es für diesen Menschen gut gemacht.
Und für den Nachbarn?
Und ja, man kann es diesem Nachbarn auch recht machen.
Und ja, man kann es sogar allen recht machen!
Ist das Design für den Nachbarn nicht „out of the box“ fein, sei der Designer nicht traurig … oder gar böse.
Wenn er seine Aufgabe verstehe, den Nutzern des Betriebssystems, des Programms zu dienen – einen Nutzen mit seiner Arbeit zu bieten – dann erkennt er, dass der Nachbar auch ein Mensch ist, auch ein Nutzer, der Optionen braucht, es sich gegebenenfalls selbst gut einzurichten.
Dies ist eine sehr reizvolle Aufgabe für jeden Designer, solches Handwerkzeugs zu entwickeln und allen Nutzern zu reichen.
Zufriedene Nutzer, zufriedener Designer.
Bestehende und bewährte Funktionen zu streichen, gute und genutzte Werkzeuge durch weniger gute und weniger brauchbare Funktionen und Werkzeuge zu ersetzen, es sind Wege, die jeder Designer meide, wenn er es denn ernst meint, dass Gestaltung dem Menschen diene.
Insbesondere sollte er nicht einfach etwas entfernen, was Menschen gut und lange schon im Gebrauch haben, also glücklich nutzen, was er selbst auch nicht entwickelt und auch nicht in die Welt gesetzt hat.
Wenn er meint, etwas noch besseres anbieten zu können … fein. Aber er streiche nicht das Bewährte …
Mit welchem Recht auch sollte er dies tun? Was einem nicht gehört, hat der Mensch anderen nicht zu nehmen.
Das beste und schönste Design ist es, es mutig den Nutzern in die Hände zu geben, was man selbst als gelungen ansieht, und den Nutzer entscheiden zu lassen, ob er es denn auch so nutzt, nutzen kann … oder lieber etwas oder etwas mehr hier und da geändert haben möchte.
Die Frage bliebe, welche Werkzeuge für diese Wege vom Designer ausgehend den Nutzer gereicht werden können.
Keine gute Idee ist es, bestehende Werkzeuge, die der Designer selbst nicht geboren hat, aus den Händen der Nutzer zu nehmen, um sie zu begraben. Werkzeuge, welche der Mensch gerne nutzt, möglicherweise gar nutzen muss. Diese Werkzeuge quasi ungefragt zu entwenden – ist es nicht eine Art der Hybris? So will ja doch kein Mensch ernsthaft sein: „hochmütig“.
Eine gute und bewährte Gangart in der Welt von „Linux“: den Nutzern zu dienen … weil nicht zuletzt jeder Designer selbst ein Nutzer ist. Gutes Design bedient sich selbst …
Es wäre doch schade, bedauerlich und nicht gut, wenn Nutzer gewendet den Designer gängeln, quälen, bestehlen und entmündigen … und ihrerseits mangelnde Bescheidenheit zeitigen …
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.
Anders bei Bluefish in einer der Seitenfenstern – regelrechte Symbol-Wüsten unter der jeweiligen Rubrik (hier Rubrik „Standard“):
- die Anhäufung der Symbole in der Spalte allein zur Rubrik „Standard“: Wissen Sie diese Symbole in deren Funktion zu benennen? Sagen Sie sich selbst die Funktionen der gezeigten Symbole auf … Warum nicht so: Beispiel Pix, Bildbearbeitungsprogramm unter Linux-Mint – ZEIGE
Solche Symbole haben eigentlich KEINE Funktion mehr, sobald sie via Text erklärt SIND – sie sind dann bestenfalls Dekoration (oder: sie könnten auch weg …) Bei Bluefish: Warum stehen hier die Funktionen der Symbole nicht in Textform daneben, wie bei Pix? Platz genug wäre ja! ZEIGE
[Nebenbei: dieses Verschieben der Fenster zueinander innerhalb eines Programms sollte als Funktion den Nutzern deutlicher gemacht werden, etwa durch eine mehr oder weniger dezente Handleiste wie es im alten GTK, etwa bei PCmanFM, Gimp, Recoll noch verfügbar war] „Alternativer“ Aufbau einer Programm-Funktion: Es könnte sogar so sein, dass links das Symbol steht, recht die Textfassung und Tooltips (wenn sie denn eingesetzt werden) ZUSÄTZLICHE Erläuterungen zur Funktion geben. Nichts ist dümmer als ein Tooltip, der nur wiederholt, was als Text da schon steht … Besser aber als jeder Tooltip ist allerdings das sogenannte Detail-Tag, das im Webdesign eingesetzt wird … (ZEIGE ICH NOCH) Tooltips werden via Hovern aufgerufen – dies aber geht auf Handy und Co. nicht … Detail-Tags indessen lassen sich anklicken – dies kann auch auf dem Handy bedient werden (wie diverse Menüs ja auch). Denkbar wäre für die Symbolanhäufung auf der linken Seite hier bei Bluefish (siehe oben) folgender Aufbau: Links das Symbol, sodann die Textfassung, sodann ein kleiner Button [Pfeil + „Info“] – oder so ähnlich: Klickt der Mensch auf das Symbol und / oder auf den Text, aktiviert er die zugedachte FUNKTION. Versteht er aber weder das Symbol noch die kurze Textfassung: dann klickt er auf den Button [Pfeil / „Info“] – und bekommt (ähnlich wie bei einem Tooltip) weitergehende Informationen … dies funktioniert dann auch auf dem Handy und Co. … Folgendes Beispiel: Auf „[Info]“ klicken – Detail-Tag geht auf: (Klick auf „Bluefish“ öffnet natürlich hier kein Programm, aktiviert auch keine Funktion, es führt Sie zu meiner Startseite – auch gut)
Bluefish„Hamburger Menü“ = die waagerechten Striche oben links, hier mit einem kleinen nach unten weisenden Pfeil … GRUNDSATZ (vielleicht): Solange eine textuelle Erklärung der Funktion erforderlich ist, solange braucht es KEINE Symbole für die Darstellung der Funktion … Wem es gefällt, hat oder lässt diese Dinger – andere Nutzer machen sie dann weg … Die Krux: Symbole BRAUCHEN Text – und sei es als Tooltip … Text indessen braucht kein Symbol … NIEMAND kann sich all diese kursierenden Symbole und die dahinter liegenden Funktionen merken: Sprache indessen versteht und merkt sich schon besser … Die gezeigten Symbole sind auch nur ein Ausschnitt dessen, was die Nutzer von sich aus innerhalb etwa des Programms Bluefish diesen oder allgemein solchen Spalten hinzugeben könnten! In Textform indessen ist dies alles viel einfacher anzusehen und zu verstehen, um sich die Funktionen eines Programms, einer Anwendung zu erschließen – wie auch beim gezeigten Beispiel eines Detail-Tags:
UNIVERSELL mag etwa das Symbol für eine Toilette sein (obgleich ich auch das bezweifel) DIE SPRACHE indessen ist universell: bei Debian dieselbe wie bei Mint, wie bei Apple, wie bei ……… (trotz aller potentieller Missverständnisse …) Die Symbole indessen in diesen Betriebssystem-Welten sind kaum universell, man gewöhnt sich an diesen oder jenen Bildchen … sie aber unterscheiden sich schon oftmals innerhalb eines Betriebssystems … Und es kommen immer weitere Symbole, Icons hinzu, ganze Familien von Symbolen und Icons, die auf dem Markt angeboten werden … – zum „downloaden …“, wenn der vorhandene Icon-Satz nicht gefällt … Na bitte … Eine AUFGABE AN DAS COMPUTER-DESIGN könnte möglicherweise sein: Wo könnten Tooltips zugunsten von Text weg … ZWEITENS: Bluefish und Pix machen es vorbildlich: In der TITELLEISTE steht die Datei / der Order, sodann der Pfad, sodann der Name des Programms (mitunter + Versionsnummer): ZEIGE
Dies schafft Orientierung. (Auf allen Fenstern …) Insbesondere bei verkleinerten Fenstern – seien sie eingerollt oder auf irgendeine Leiste geparkt – es schafft Orientierung. Wer will, setze halt ein Symbol, ein Icon an den Anfang … … oder eben NICHT … mit Icons und ohne (wie ich es gerne nutze):
Diese Einstellung ist unter Openbox mit dem Eintrag eines Buchstabens in der rc.xml-Datei bestimmbar:
NEBENBEI (respektive deutlich gesagt): Diese Funktionen der Titelleiste sind beim Gnome-Design von Debian de facto entfernt worden: - Das Einrollen der Fenster wurde kurzerhand gestrichen - das Aufrufen des umfangreichen Titelleisten-Menüs ist unter Gnome „kastriert“ … - Angaben wie „Dateiname + Pfad der Datei + Programmname“ existieren unter Gnome nicht mehr … kein Padding einstellbar und vieles mehr … Dabei sind: - Titelleiste - Angaben auf der Titelleiste - Nutzung des vollständigen Menüs - sowie die Funktion des Einrollens von Fenstern … und vieles mehr! geradezu PFLICHT ZEIGE das Einrollen … das Minimieren (ohne Leiste!) (im Video) Anhand dieser Beispiele kann auch deutlich gemacht werden, dass zwischen den FUNKTIONEN DER PROGRAMM-FENSTER (bei Openbox in den Dateien rc.xml, .thermerc umfangreich einstellbar) und den FUNKTIONEN DER PROGRAMME zu unterscheiden ist: DIESE UNTERSCHEIDUNG SOLLTE BEWAHRT BLEIBEN. GNOME von Debian missachtet diese Unterscheidung einfach mal so aus dem Designer-Bauch heraus … Braucht kein Mensch! Solche Praktiken machen es den Nutzern nur schwer(er), obgleich das Gegenteilige bei Debian-Gnome behauptet wird … ===== Ende