Skip to content

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.

Trackbacks

A view from the hill on : User interface modals, configurations etc.

Show preview
Zugschlus bloggt in einer Serie über Text-UIs and GUIs. Da ich kein Cookie-Freund bin, hier eine Nachfrage/Gegenargument. Ich blicke seine grundsätzliches Thema gar nicht. Die Frage des UI ist sehr auf die Frage der Konfiguration der Applikation konzentri

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 :

Für das GUI: + alle Optionen sichtbar, muss man nicht nachschlagen

Nicht zwingend. GUIs sind teilweise gepaart mit versteckten Einstellungen in Registry-artigen Datenbanken, oder seltsamen Klick-Kunstgriffen.

  • feine Rechtevergabe möglich (Admin darf alles ändern, User X nur einen Teil, User Y einen anderen)

Auch bei TUIs möglich, wenn auch nicht ganz so komfortabel. Doku und gute Architektur ist zwingend.

  • am Telefon besser erklärbar, kann auch mal vorgelesen werden

Klickanleitungen am Telefon verabscheue ich persönlich. Lieber eine Konfigurationsdatei per E-Mail schicken. Ist beides nicht grad DAU-kompatibel.

Gegen TUI: - jede hat eigenes Format, immer neu lernen und gleich wieder vergessen

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).

  • subtile Gemeinheiten von Tab, Leerzeichen und Zeilenumbruch

Gibt es meiner Erfahrung nur vereinzelt.

  • welche Zeilenenden werden verwendet

Sollte für ein gutes Programm kein Problem sein. Ist das ein Problem in reinen *nix-Umgebungen?

  • kompromittierbar durch fehlerhafte Einträge in der Konfiguraionsdatei, falls andere im System sie schreiben können

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.

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options