[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