[linux-l] einfach zu bedienende programme fuer norman
Norm@nSteinbach
norm at nsteinbach.de
Do Apr 19 19:21:03 CEST 2007
Hi Peter,
Peter Ross wrote:
> Anyway, fuer interaktive Programme finde ich Menus und Hilfen schon
> praktisch, klar. pine z.B. hat es.
Das klingt gut!
> Auf getrennte Dokumentation moechte ich nicht verzichten. Ich kann Dir als
> Admin helfen, ohne das Programm selbst laufen zu haben, ich kann ein
> Programm studieren, bevor ich es installiere (ich finde es nervig, Pakete
> runterzuladen, auszupacken und dann festzustellen, dass es mein Problem
> nicht loest..)
Getrennte Doku: Klar, als zusätzliches "Addon" zu einer
selbsterklärenden Programmoberfläche ist das absolut unverzichtbar. Es
hapert ja auch an der selbsterklärenden Programmoberfläche, und nicht an
der Doku ;-)
Helfen ohne das Programm laufen zu haben konnte ich Leuten die mich was
gefragt haben bisher immer nur bei Programmen die ich selbst kannte,
weil ich sie schonmal benutzt hatte oder so. Ist aber alles eher
windows-lastig, unter linux kenne ich ja noch nicht soo viel ;)
Ein Programm anhand der Doku studieren ohne es zu installieren: Das geht
nur bei OSS-Programmen, denn kommerzielle Programme - zumindest unter
Windoofs war es so - waren nur anhand der Doku nicht verstehbar, man
benötigte auch das Bild des Programmes vor Augen (die wenigsten Dokus
enthielten Screenshots, außer für große&teure Programme).
Ein Paket runterladen, installieren und feststellen dass es das Problem
nicht löst ist natürlich nervig (und dagegen hilft tatsächlich eine
separate Doku), ist aber mir noch nicht so häufig wiederfahren. Es war
bisher immer eher so, dass ich ein Paket runtergeladen hatte, was ein
Problem zu lösen in der Lage gewesen wäre - und wenn das Problem dann
dadurch nicht gelöst wurde, lag es eher daran dass das Paket sich nicht
richtig installiert hatte oder noch irgendwelche Handarbeit vonnöten
war, um es auch wirklich so zum Laufen zu bekommen wie man es haben will.
Klar, alles nur persönliche Erfahrungsberichte die wenig oder garkeine
Aussagekraft darüber haben, was für Anwendungsszenarien im Geld-Alltag
den Leuten die IT für oder gegen Geld machen wiederfahren.
> Anyway, ich sehe schon, dass vieles "ehrenamtliche" Arbeit ist. Selbst auf
Definiere Arbeit - wenn man es ehrenamtlich macht, ist die
Arbeitsdefinition vom Geld losgelöst - aber, was ist dann Arbeit?
Letztlich ist dann alles arbeit, sogar "einkaufen" oder "autofahren"
(auch wenn man es gern macht: es gibt leute, die machen es als job),
undsoweiter. Da mir bisher noch niemand eine wirklich aussagekräftige
Definition von Arbeit geben konnte,
> Arbeit muss ich fortlaufend Kompromisse machen, zwischen Quantitaet der
> Arbeit, die zu schaffen ist, und der Qualitaet. Seit Monaten versuchen
> wir, pro Person im Operations Team einen Tag zu haben, an dem sie frei vom
> Tagewerk ist, um die Arbeit der Woche zu dokumentieren. In der Realitaet
> reicht es gerade bis jetzt gerade mal zu einer Mail in der Arbeitsgruppe
> "Programm xy geschrieben, und laeuft auf allen Rechnern als Cron, macht
> dieses.. Aufruf und Paramer siehe Kopf des Skripts, eingecheckt in svn"
Woran liegt das? Zu wenig Leute, die direkt mit den Entwicklern
zusammenarbeiten und sich aber nur ums "Human-Interface" bzw. die Doku
kümmern? Falsche Prioritätensetzung bei Entwicklungs- und
Dokumentationstätigkeiten?
Gut, ich weiß nicht wie Eure Software aussieht, vom "Human-Interface"
her meine ich jetzt, daher kann ich so nichts darüber sagen, aber
wannimmer ein Team von Entwicklern eine Software baut, die zwar perfekt
funktioniert, ohne Studium des Quellcodes oder dessen erster
Abstraktionsstufe (weiß nicht mehr wie das heißt, aber in der
"Grundlagen-der-Informatik"-Vorlesung habe ich sowas mal mitbekommen,
praktisch "sprachlicher" Quellcode, z.B. "wenn das dann mache dies" usw.
anstatt irgendeiner Programmiersprache) aber nahezu unbedienbar ist,
dann wurde in den meisten Fällen am Anwender vorbeientwickelt - außer
natürlich, es handelt sich um hochspezielle Anwendungen, die ohnehin nur
von entsprechend versierten Anwendern benutzt werden. Das ist dann aber
weder bei einem Mailprogramm, noch bei einem Editor oder einem
Schriftsatzsystem u.ä, der Fall, sondern vielleicht bei einer Steuerung
für eine CNC-Einheit. Alles was jedoch "für alle" (bzw. portentiell
jeden) veröffentlicht wird, sollte sich auch zu einem gewissen Maße
selbst erklären.
>> Hier sehe ich allerdings Handlungsbedarf, und zwar sollte jeder User
>> zumindest eine gewisse Grundausbildung in der Bedienung eines Computers
>> haben, so dass es eben kein Problem mehr ist, eine Systemdatei zu
>> editieren (meistens läuft so etwas nach Anleitung ab, und damit kann der
>> User so gut wie nichts falschmachen, wenn er sich daran hält).
> Jein.
> Ich habe Mitte der 90er mit Nextstep gearbeitet. Ich fand es ausgesprochen
Nextstep kenne ich leider überhaupt nicht. Was heißt leider, heute ist
es wohl auch (ebenso leider?) kaum mehr wichtig, es zu kennen...
> schoen, eine funktionale, konsistente Oberflaeche zu haben, in der ich
> annaehernd alles erledigen konnte, ohne das Terminal zu benutzen - und
> eine Shell zu haben, fuer "gehobene Ansprueche", die dem Heimanwender
> nicht wichtig sind - um es in einem heterogenen Netz einzufuegen (mit NIS
> und Suns zu "verheiraten" z.B., netzwerkweites Backup u.a.)
> Ich mache mir manchmal den "Spass", das mit Gnome zu versuchen. Der Erfolg
> haengt sehr von der Vorkonfiguration ab. Unter Fedora z.B. gibt es keinen
> Aufruf vom - installierten - gnome-screenshot auf der Oberflaeche, bei
> FreeBSD mag totem ohne Rechteaenderungen nicht..
Von dem, was Du hier geschrieben hast, habe ich vielleicht 10%
verstanden (ich weiß z.B. dass Du mit einem "screenshot" keine
Grafikdatei meinst, sondern ein Abbild des Systemes inkl. aller
laufender Programme usw) ;-)
> Es ist schon der Preis der Flexibilitaet von solchen Paketen, jede
> Distribution, jedes OS erfordert Anpassungen, im Prinzip muss man bei
> jedem neuen Paket zumindest ein zuseatzliches postinstall fuer Gnome
> und KDE haben, damit es sich einfuegt ..
Auch hier kapiere ich nicht so ganz was Du schreibst. Ich nehme an, mit
"postinstall" meinst Du eine Routine, die das Programm so in der
jeweiligen GUI "einbaut", dass es mit dieser zusammenarbeitet. Nur dass
ich dieses Problem/Bedürfnis noch nie hatte. Nagut, vielleicht verwende
ich zusehr auf triviale Bedienerschnittstellen ausgelegte Programme,
oder sonstwas - jedenfalls war es bei mir unter Linux bisher immer so:
Entweder, etwas funktioniert von vornherein, oder es funktioniert
garnicht ohne Handarbeit, dann weder in der Konsole noch unter GUI.
> bei Next (heute Apple) war's eben aus einem Guss.
Achso, Next ist das alte Apple-System? Naja, das habe ich auch immer nur
mal gesehen. Hätte zwar sicherlich inzwischen mehrfach die Chance haben
können, 10 Jahre alte PowerMacs geschenkt zu bekommen um mich damit
anzufreunden - aber dann: Wenn da noch kein OSX drauf läuft, erscheints
mir wenig sinnvoll, mich noch in so alte Technologien einzuarbeiten. Ich
weiß nur, dass ich, wannimmer ich versucht habe unter irgend einem alten
MacOS irgendwas zu konfigurieren oder einzurichten, kläglich daran
gescheitert bin, dass ich weder wusste wo die entsprechende
Konfiguration im System zu finden ist - zudem war es da ja
wahrscheinlich noch so, dass jede Konfiguration im System 2mal
abgebildet ist: Einmal als Konfigurationsdatei auf der Festplatte (nicht
unbedingt menschenlesbar), und einmal als grafischer Dialog versteckt in
einem der hundert milliarden Untermenüs von MacOS. Letztlich habe ich es
dann immer vor allem deshalb aufgegeben, weil man zu häufig die Maus
benutzen musste und zu wenig mit der Tastatur ging - da kotze ich heute
schon bei Windows bzw. X11-Programmen häftigst ab, wenn man gewisse
Dinge nur an*KLICKEN* kann, anstatt sie per Shortcut (oder meinetwegen
auch per Fokuswechsel via <Tab>) aufrufen zu können.
Viele Grüße,
Norm at n
Mehr Informationen über die Mailingliste linux-l