GUI gegen TUI: cut&waste
Wenn man System B genauso konfiguriert haben will wie System A, transferiert man einfach die entsprechenden Teile der Textkonfiguration von B nach A. Das kann über Dateitransfer geschehen, oder im einfacheren Fall einfach per Text-cut-and-Paste vom einen Fenster des Admins auf das andere.
Zum Vergleich das GUI: Hier muss man entweder den Umweg über Word- oder HTML-Dokumente mit Screenshots gehen, auf denen oft genau das wichtige Unterfenster der dritten Subebene fehlt, in dem die magische "mach-dass-es-funktioniert"-Option eingestellt werden kann, oder man hat zwei (auf dem Bildschirm wertvollen Platz belegende) grafische Oberflächen und man überträgt die Konfiguration manuell vom einen Fenster ins andere, ohne das Clipboard als Hilfe benutzen zu können.
Bestenfalls erzeugt das GUI letztendlich doch wieder eine Textkonfiguration, oder man darf schlecht oder gar nicht dokumentierte Registrybäume oder Datenbankdumps von einem System aufs andere schieben.
Plus fürs TUI.
Comments
Display comments as Linear | Threaded
Django on :
Für das GUI: + alle Optionen sichtbar, muss man nicht nachschlagen + feine Rechtevergabe möglich (Admin darf alles ändern, User X nur einen Teil, User Y einen anderen) + nur Sachen, die man ändern darf, werden angezeigt + kontextsensitive Hilfe + am Telefon besser erklärbar, kann auch mal vorgelesen werden + wenn man die Felder kennt, kann man auch eine japanische GUI bedienen
Gegen TUI: - jede hat eigenes Format, immer neu lernen und gleich wieder vergessen - subtile Gemeinheiten von Tab, Leerzeichen und Zeilenumbruch - welche Zeilenenden werden verwendet - welcher Zeichensatz/Umlaute - kompromittierbar durch fehlerhafte Einträge in der
Konfiguraionsdatei, falls andere im System sie schreiben können
Björn Schließmann on :
Nicht zwingend. GUIs sind teilweise gepaart mit versteckten Einstellungen in Registry-artigen Datenbanken, oder seltsamen Klick-Kunstgriffen.
Auch bei TUIs möglich, wenn auch nicht ganz so komfortabel. Doku und gute Architektur ist zwingend.
Klickanleitungen am Telefon verabscheue ich persönlich. Lieber eine Konfigurationsdatei per E-Mail schicken. Ist beides nicht grad DAU-kompatibel.
Das stimmt nur bedingt. Viele Konfigurationsdateien haben ähnliche Formate (Shellvariablen, "Windows-INI"). Exoten wie procmail gibt es natürlich (die gibt es aber auch bei GUIs).
Gibt es meiner Erfahrung nur vereinzelt.
Sollte für ein gutes Programm kein Problem sein. Ist das ein Problem in reinen *nix-Umgebungen?
GUIs sind bei Rechteproblemen nicht ebenso kompromittierbar? Die speichern ihre Daten auch irgendwo.
Björn Schließmann on :
Ich würde GUIs nicht generell bevorzugen, nur in manchen Einsatzbereichen benutze ich sie tatsächlich lieber. Beispiele aus jüngster Vergangenheit:
QEMU (TUI und GUI) Da habe ich die Wahl zwischen (lückenhafte) manpage auswendig kennen und ca. 300 Zeichen lange Befehlszeile im Skript als "Konfigurationsdatei" zu benutzen, oder qemu-launcher als halbwegs übersichtliches GUI zu benutzen. Ich bevorzuge letzteres.
Dosbox (nur TUI) Hat nur TUI. Einfach furchtbar. Konfigurationsdatei ist zwar kommentiert, nur unvollständig. Es wird öfters auf die README-Datei verwiesen, in der aber auch nichts näheres zu speziellen Themen (hier: ALSA-Sound) steht. Im Internet gibt es an offizieller Doku nur ein halb eingerichtetes MediaWiki mit einem "hier-Klicken"-Tutorial für Windows.
LTSP 5 * (nur TUI (zumindest habe ich nur TUI benutzt)) Konfigurationsdatei muss man sich selber schreiben. Die Doku, was drinstehen kann, ist extrem lückenhaft. Zum Glück kann man sich das Wichtigste aus den Shellskripten rausorakeln. Sonst auch wenig Doku zu Architektur oder Zusammenhängen.
TUIs kann ich nicht ausstehen, wenn es keine Beispiel-Konfigurationsdatei(en) oder gute Doku gibt. Diese Kombination treffe ich leider des öfteren an. Das spricht nicht prinzipiell gegen TUI; nur habe ich subjektiv gesehen mehr schlechtere TUIs als GUIs erlebt. Wenn man mit einem schlechten GUI zurechtkommen muss, kann man sich oft grob an den Fensterchen orientieren. Bei schlechten TUIs muss man sich aus lückenhafter Doku die Konfigurationsdatei (idealer: mehrere) selber schreiben, samt Skripten zum Einbinden ins System.