die alte GUI-Diskussion / Re: Hoffnung

Hi,

nochmal was altes, die Mail gammelt schon eine Weile halbfertig hier
herum ... ;-)

-- Oliver Fromme <olli(at)lurza.secnetix.de> wrote:

> > tja, und was machen Kommandozeilenanwender, die doof sind oder sich
> > doof anstellen?
>
> Die haben dieselben Probleme wir GUI-Anwender, die doof
> sind oder sich doof anstellen. Und von der Sorte kenne
> ich durchaus ein paar.

ja, klar -- davon gibt's viele ;-)

mal Vorweg: ich glaube, im Endeffekt liegen unsere Meinungen nicht
wirklich weit auseinander, ist halt nur immer die Frage aus welchem
Blickwinkel man etwas im entsprechenden Augenblick betrachtet.
Wenn ein Windows-Hansel daherkommen würde und behaupten würde, dass
damit ja alles viel toller und viel besser ist würde ich ihm
wahrscheinlich auch das ifconfig-Beispiel etc. um die Ohren hauen ;.)

> > Aber fast alles ist wenn der Nutzer es noch nicht erlernt hat
> > schwieriger, weil man schlicht mehr lernen muss.
>
> Das bestreite ich nicht. Aber der Zeitaufwand, den das
> Lernen kostet, bekommt man später doppelt und dreifach
> wieder zurück.

das ist in vielen Punkten wahr, ja.

Aber es ist immer die Frage, was man denn nun genau lernen will/muss/soll.

Im Zuge des Grep-Threads hattest Du ja auch was von awk etc. geschrieben.
Ich persönlich habe da keine sonderlich großen Ambitionen, awk etc. zu
lernen. Wenn ich entsprechende Probleme habe nehme ich Perl zur Hand --
das kann ich im Schlaf, vieles geht mit einem kleinen Einzeiler, und wenn
es sein muss ist es viel mächtiger und ich bin schneller am Ziel. Aber
das ist immer auch eine persönliche Frage.

Und im Zweifelsfall würde ich da eher nach einem CPAN-Modul suchen,
bevor ich mich in awk (oder anderes) einarbeite. :)

> Und wie gesagt: Für diverse Arten von Aufgaben ist es
> einfach nicht sinnvoll, zu versuchen, sie vollständig in
> ein GUI zu verpacken.

Das ist klar, dass es immer und überall Sachen gibt, die sich eher nicht
sinnvoll in einer der Varianten umsetzen lassen -- oder eben nur mit viel
Aufwand. Die spannende Frage ist natürlich, wo die Grenze zu ziehen ist,
aber auch das ist individuell!

So habe ich vor zwei Wochen einen Perl-Kurs für Entwickler aus dem
Entwicklunglsabor eines der (des?) weltweit größten IT-Unternehmes
gegeben. Viele nahmen im GUI der Entwicklungsumgebung die Maus zum
Speichern, indem sie auf das entsprechende Icon klickten.
Softwareentwickler, wohlgemerkt. Für mich ist das unvorstellbar, STRG-S
oder Apfel-S sind für mich eine der wichtigsten und normalsten
Tastenkombinationen. Aber ich verspüre keine große Lust, freiwillig von
x verschiedenen Programmen die Tastenkürzel zu lernen (immerhin kann ich
in der Zwischenzeit vi beenden und wenn es sein muss sogar was ändern
und die Datei speichern, bei meinem ersten Versuch vor Jahren musste ich
erst das Modem auflegen lassen, um da raus zu kommen!).

Und ein GUI muss ja nicht zwangsweise ein Klicki-Interface sein. Auch mit
curses etc. lassen sich Anwendungen basteln.
Ich komme ja aus der ATARI-Ecke, und da gab es ende der 80er/anfang der
90er einige Schweineprogramme, die kein echtes GEM-GUI hatten; zum
Beispiel GFA-Basic oder der TurboAss bzw. der dazugehörige Debugger
(Programmiersprachen brachten damals alle ihre "IDE" mit). Die
entsprechenden Funktionen wurden über die Funktionstasten und mittels
Kommandos ausgeführt, aber z.B. der Debugger vom TurboAss war deutlich
komfortabler und eingängiger als der normale
Perl-Kommandozeilen-Debugger oder der gdb, denn immerhin konnte man auf
dem Bildschirm direkt die wichtigsten Funktionen als Menüpunkte.

Oder: ich nutze für Kleinkram zum Beispiel lieber den ee als vi(m): die
Befehle stehen immer dran (auch wenn ich sie in der Zwischenzeit
auswendig kenne) und für Kleinigkeiten reicht der Funktionsumfang
meistens aus. Bei vi habe ich erstmal gar keine Information was ich da
überhaupt (!) machen kann. Siehe oben: Als ich vor Jahren damit das
erste mal in Berührung kam hatte ich massive Problem das Ding irgendwie
zu beenden ;-)

> > Das ist für uns alle hier kein Problem, die Grundlagen
> > haben wir nach jahrelangem Training erlernt.
>
> Das ist doch ziemlich übertrieben. Wie 'ne Shell grund-
> legend funktioniert, lernt man in fünf Minuten. Klar,
> die Feinheiten brauchen etwas länger (man muß ja nicht
> alles auf einmal lernen, sondern nach und nach das, was
> man gerade braucht), aber »jahrelanges Training« braucht
> man nicht.

Wie sie grundlegend funktioniert lernt man schnell, aber damit kann man
noch lange nicht wirklich viel anfangen. "jahrelanges Training" würde
ich schon sagen (solange man nicht einen entsprechenden Kurs macht). Um
sinnvoll arbeiten zu könenn braucht man schon ein paar Tools, muss
wissen dass man mit "man" Infos kriegt, sollte grep schon mal gesehen
haben usw.

> > Wer ließt schon gerne Handbücher?
>
> Wenn sie gut geschrieben sind, mache ich das gerne, wenn
> ich weiß, daß ich danach das betreffende Gerät oder Pro-
> gramm beherrsche.

gut Handbücher lese ich auch hin und wieder. Oder Teile davon. Aber die
meisten Leute lesen ja noch nicht mal das Handbuch ihres Videorekorders
und wundern sich, warum sie ihn nicht bedienen können. ;-)

Und viele wollen am Computer auch nix lernen und es soll einfach
funktionieren. Ich kenne da Leute, die weigern sich beharrlich statt der
MS Office Kopie lieber gleich OpenOffice zu nehmen (auch wenn alle
Kollegen damit arbeiten). Oder auch mal irgendwas anderes als Windows
auch nur anzuschauen. Das gilt dann für alle Applikationen: alles muss
exakt so sein wie man es mal gelernt hat -- und das ist nicht nur bei
älteren Leuten so!

 
> > Mit GUI muss man aber eben weniger lesen, wenn alle Optionen schon
> > dranstehen und nicht durch irgendwelche in der manpage aufgeführten
> > Switches zu erledigen sind.
>
> Das ist schlicht falsch.

nein, denn man hat quasi immer ein --help ;-)

> Wenn ein GUI eine bestimmte
> Funktionalität anbietet, dann muß man ebensoviel lesen
> wie bei einem textbasierten Tool, das dieselbe Funktio-
> nalität anbietet. Der Unterschied ist nur die Form der
> Dokumentation. Beim GUI ist sie typischerweise über
> Pop-up-Blasen und Online-Hilfetexte verfügbar (oder sie
> fehlt und erfordert vom Benutzer Ratespielchen), bei
> UNIX-Tools ist sie typischerweise in einer Manual-page
> vorhanden.

Wenn ich gruppierte Check- und Radiobuttons habe und die sauber
beschriftet sind, muss ich da deutlich weniger lesen und viele Optionen
sind dann klar. Die detaillierte Hilfe ist ja wieder was ganz anderes.

Das liegt nicht nur an der Textmenge sondern eben auch an der
Gruppierung. Bei Manpages muss ich zwar auch nur das Kapitel lesen dass
ich in dem entsprechenden Augenblick interessiert, aber trotzdem reichen
mir da weniger Informationen meist nicht aus. Und ich muss das Kapitel
erstmal finden ;-)

> Um das schonmal erwähnte find(1) nochmal zu bemühen:
> Würde man es in ein GUI gießen wollen (was meienr Meinung
> nach keinen Sinn ergibt), würde man vermutlich für die
> meisten Optionen einen Check- oder Radio-Button machen
> (womit man aber bereits nicht mehr die ganz Funktionali-
> tät von find(1) abbilden kann). Es gäbe dann also etwa
> Check-Buttons, die den find-Optionen "-inum" oder "-links"
> entsprechen (nur um mal ein paar beliebige der 52 Optionen
> herauszugreifen). Und dort würde im GUI exakt dasselbe
> stehen, was in der find-manpage steht -- entweder in einem
> Hilfe-Pop-up, oder direkt neben der Checkbox im Dialog.

nö, bei komplexeren Sachen würde man sowas ja zum Beispiel
ein/ausblendbar machen usw.

Ich möchte sogar behaupten, dass man die gesamte Funktionalität mit
entsprechedem Aufwand sauber in einem GUI implementieren könnte.
Eigentlich wollte ich hier eine kleine Wette vorschlagen, und zwar dass
ich die gesamte find-Funktionalität in ein GUI gepackt kriege -- aber in
der Zwischenzeit habe ich mir mal die neuen Suchfunktionen von OS X 10.4
genauer angeschaut:

Denn unter OS X Tiger gibt es etwas ähnliches mit GUI: und ich möchte
behaupten, dass die Suchfunktion deutlich mächtiger und komfortabler ist
als find.
In jedem Desktop-Fenster gibt es oben rechts -- wie man es von modernen
Webbrowsern gewohnt ist -- ein Eingabefeld zur Suche. Von dort aus oder
via Apfel-F kommt man zum Suchdialog.
Neben den üblichen Suchoptionen (Dateiname, letzte Änderung, letzter
Lesezugriff, Dateigröße, ...) kann man auch nach dem Inhalt suchen oder
nach Eigenschaften wie Bitrate bei MP3s, ID3-Tags von MP3s, Bildgröße
in Pixeln usw. Das ganze ist indexiert (via Spotlight), dadurch relativ
schnell und hat eine Vorschau während dem Tippen. Die Ergebnisse werden
nach Typ gruppiert, und zwar nicht stur nach der Dateiendung sondern wenn
ich nach "Test" suche kommen z.B. Ordner, Bilder, Programme, Quellcode,
PDF-Dokumente, ...

Das ist tatsächlich *deutlich* komfortabler als find, und es kann mehr;
es durchsucht auch Binärdateien wie PDFs und kann nach Metainformationen
filtern wie der Brennweite bei einem Foto. Sag mir mal, wie Du mit find
alle Fotos auf Deinem Rechner findest, die mit einem Blitz aufgenommen
wurden? ;-)

Und die Suche ist dafür durchaus rasend schnell.

Wiederkehrende Suchen kann ich speichern und als Ordner auf dem Desktop
(oder irgendwo anders) ablegen.

Apropos:
Apple versucht ja seit Jahrzenten immer wieder, eine Art
Desktopsuchmaschine zu implementieren; mit Spotlight scheint diesmal
endlich etwas brauchbares herausgekommen zu sein.
Aber das Grundproblem liegt wo ganz anders und ist die Ursache, dafür,
dass entsprechende Volltextsuchfunktionen vorhanden sind: Sehr viele User
finden ihre Dateien nicht mehr. Dies liegt meines Erachtens daran, dass
viele keinen blassen schimmer davon haben, wie ein hierarchisches
Dateisystem aufgebaut ist. Und der Zugang dazu wird ihnen extrem schwer
gemacht, da sie oft schon fast mit Gewalt davon abgehalten werden es zu
lernen.

Hinzu kommt, dass die Fileselector unter OS X und unter Windows völliger
Müll sind. Das liegt aber nicht daran, dass sie grafisch sind, sondern
das liegt daran wie sie implementiert wurden ...

[andere Mail]

> Anders liegt der Fall, wenn man daheim einen Rechner hat,
> den man selbst installiert und konfiguriert. Dort ist man
> Admin und Anwender zugleich, auch wenn es vielen Leuten
> lieb wäre, daß sich der Rechner von allein installieren
> würde und ohne Administration »im freien Fall« laufen
> würde. Dem ist aber nicht so, insbesondere bei den freien
> BSD-Derivaten.

na, bei Windows ist das auch nicht anders. Streng genommen ist das
nirgendwo anders (und kann auch gar nicht anders sein, wenn die
Funktionalität nicht grundlegend sehr stark auf einen Zweck beschänkt
ist).

Aber auch wenn ich mir als Admin in vielen Sachen das Leben durch Skripte
und Shell leichter machen kann und wenn es meistens viel schneller ist,
mal einen ein "portinstall bash" zu tippen, will ich nicht in jedem Fall
und für jede Aufgabe mich erstmal in die Syntax von irgendwelchen selten
benutzten Sachen einarbeiten.

Ciao
  Alvar

-- 
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/
 

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 01 Mar 2006 - 16:50:26 CET