Schreibstil der Doku

[Michael Springer]

Ich möchte mich eigentlich nicht einmischen und mein Thema passt auch nicht wirklich zu TeX. Aber da es mir persönlich wichtig ist, möchte ich nochmals darauf hinweisen.

Ich habe im Herbst 2012 die Datei http://www.zusi.de/zusi3/Kapitel_5_1.pdf" target="_blank gelesen und einige Anmerkungen aus meiner Sicht dazu per Email an Carsten gesandt. Ich persönlich finde, dass die Dokumentation von Zusi 3 einen nicht so guten Schreibstil hat und sehr einfach verbessert werden könnte.

In sehr vielen allen Sätzen sind Modalverben eingebaut (sollen/wollen/können/dürfen/müssen). Modalverben sollten aus drei Gründen nicht in Dokumentationen oder anleitenden Texten verwendet werden:
a) Modalverben sind nur Scheinpräzisierungen
b) Das eigentliche Verb dadurch wird geschwächt
c) Das Verb rückt immer an das Satzende. Der Satz ist somit schwerer zu verstehen.
Besser, klarer und kürzer ist es den Sachverhalt direkt zu schreiben.

Original
Funktional muß zwischen der Streckeninformation und der Landschaft unterschieden werden.

Besser
Funktional wird zwischen der Streckeninformation und der Landschaft unterschieden.
-oder noch direkter -
Zusi unterscheidet funktional zwischen Streckeninformationen und Landschaft.

Original
Grafiken sollten möglichst in einem Vektorformat (gut geeignet ist .wmf) erstellt werden. Dieses lässt sich z.B. mit OpenOffice-Draw erzeugen.

Besser
Grafiken im einem Vektorformat erstellen. Das Format .wmf ist gut geeignet. Verwenden Sie z. B. OpenOffice-Draw.
-oder-
Erstellen Sie Grafiken im Vektorformat. Gut eignet sich das Format .wmf. Verwenden Sie z. B. OpenOffice-Draw.


Oft sind Formulierungen vorhanden mit:
man
sich lassen
oder allgemein unpräzise Aussagen

Beispiel
Andererseits sollte man aber auch keine zu großen Module bauen, da sonst irgendwann der Arbeitsspeicher knapp wird.

Was sagt mir "irgendwann"? Morgen, Übermorgen? Wenn das Modul 2, 5, 10km erreicht hat?
Die Information "irgendwann" bringt mir hier garnichts. Lieber eine genaue Information mitliefern und wenn es nur ein Anhaltspunkt ist.

Bauen Sie keine zu großen Module. (Erklärung warum > Arbeitsspeicher knapp). Wir empfehlen (aus diesem Grund) eine Modulgröße von 5 x 5km nicht zu überschreiten.

Kürzer ist besser, aus mehreren Gründen.
1. Wenn die Anleitung gedruckt werden soll, spart man Seiten und somit Kohle.
2. Falls die Anleitung in andere Sprachen übersetzt werden soll, spart das auch wieder Ressourcen.

Wenns geht, pro Satz nur eine Information, usw.

Beispiel
Wenn das Element gerade so liegt, daß man von Punkt 1 zu Punkt 3 gegen den Uhrzeigersinn läuft, dann bedeutet das, daß das Dreieck von hinten betrachtet wird.

Habt ihr den Satz beim ersten Mal lesen verstanden? Seit mal ehrlich. Das geht sicherlich viel kürzer.
Das Dreieck wird von hinten betrachtet (und nicht gezeichnet), wenn ...

Oder 2. Beispiel
Der 3D-Editor bietet für das Zusi-eigene Format entsprechende Funktionen dafür, wo man jetzt lediglich die Außenscheiben ans Ende der Liste schieben muß, damit diese ganz am Ende (zumindest aber nach der Inneneinrichtung) gezeichnet werden.


Allgemein
Was aus meiner Sicht auch gar nicht geht ist Blocksatz. Bei der Zeilenbreite werden die Abstände zwischen den Worten teilweise so groß, dass der Text schwer zu lesen ist. Eine optimale Lesebreite sind 70-75 Zeichen pro Zeile. Der Zeilenabstand sollte ca. 20% sein. Also bei Schriftgröße 10 etwa 12 Punkte.

Ich möchte Euch nicht weiter zutexten...

Grüße Michael, der täglich mit technischen Dokumentationen und Anleitungen zu tun hat...

Just my 2ct

[Carsten Hölscher]

Wenn das ein Angebot zur Hilfe war, dann ist das sicher gerne gesehen (wäre nur zu klären, wie man es in den Ablauf einbaut). Es sind jetzt so um die 500 Seiten und das ist ja eigentlich nur eine Art "Nebentätigkeit" für mich. Da jetzt alle Sätze durchzuchecken wäre wohl nicht der sinnvollste Zeitvertreib.
Carsten

[Michael_Poschmann]

Um so wichtiger erscheint es aus meiner Sicht, mit den Formatierungsdingen zu einer tragfähigen Lösung zu kommen, ohne einen Anspruch auf die Weltformel zu entwickeln. Es reicht, wenn Zusi diesen in Sachen Fahrdynamik und Co besitzt.

Wie heißt's bei meiner Sportart so schön: "Der dritte Ball muss über's Netz!" Bei den Rasentretern ruft der Trainer oftmals: "Abschluß!", wenn er weitere Dribblings vermieden sehen möchte. Analog zu Deinem Ballsport der beim Fernsehen aufgeschnappte Kommentar: "Zeitspiel ist angezeigt!"

Michael

[Alwin Meschede]

Bauen Sie [...] Wir empfehlen [...]

Geht es nur mir so, oder empfinden auch andere Leute so einen Schreibstil, bei dem man gesiezt wird, als fürchterlich unpersönlich und irgendwie nicht Zusi-artig? Ich möchte von der Zusi-Doku irgendwie nicht gesiezt werden...

[Mr. X]

Bauen Sie [...] Wir empfehlen [...]

Geht es nur mir so, oder empfinden auch andere Leute so einen Schreibstil, bei dem man gesiezt wird, als fürchterlich unpersönlich und irgendwie nicht Zusi-artig? Ich möchte von der Zusi-Doku irgendwie nicht gesiezt werden...

Ich würde die Nutzer meiner Programme intuitiv eher siezen, sehe da kein Problem mit. Hängt aber auch von der Zielgruppe ab. Wenn ich Software für irgendwelche Nerds oder Hacker schreiben würde (und diese nicht englischsprachig wäre), würde ich die duzen. Die ZUpdater-Nutzer sieze ich, habs grad mal nachgeschaut. Das Zusi-Publikum ist halt im Schnitt doch als seriös eingeschätzt

Entscheidend dafür, ob ich etwas lesbar finde oder nicht ist für mich u.a., ob er mit Marketing-Sprechblasen vollgestopft ist. Dagegen bin ich allergisch. Ist bei Zusi-Texten aber eher nicht der Fall.

[Michael Springer]

Da ich nicht zum 3D-Häuser bauen tauge, würde ich mein Fachwissen dort gerne einbringen. Also die Anleitung ansehen und ein paar Verbesserungen vornehmen. Natürlich in Absprache mit Dir und den Original-Autoren. Ich weiß nur nicht, wie schnell das bei 500 Seiten geht. Vielleicht sollte man exemplarisch an einem kleinen Kapitel das mal versuchen und später die überarbeitete Version nochmals diskutieren.

Vor Beginn der Arbeiten wäre es hilfreich, wenn gewisse Standards definiert würden.
- Rechtschreibung alt oder neu (Bsp: daß oder dass, muß oder muss). Das Kapitel 5.1 ist durchgängig in daß/muß geschrieben, daher denke ich die Anleitung wird in "alter Rechtschreibung" geschrieben.
- Handlungsanweisungen werden normalerweise gekennzeichnet, dass der Leser sofort weiß, ok hier muss ich aktiv was tun.
Das geht entweder mit einen Symbol wie ► oder einer Nummerierung 1. 2. 3.
- Wie werden Handlungsanweisungen formuliert
persönlich/unpersönlich
1) Die Taste A drücken (unpersönlich, ohne direkte Ansprache des Nutzers)
2) Drücken Sie die Taste A (persönlicher, mit direkter Ansprache des Nutzers)

- Sätze mit Artikeln/ohne Artikel wenn möglich
* Drücken Sie die Taste A
* Drücken Sie Taste A (wäre wieder kürzer)

- Formatierungen von feststehenden Begriffen
Ich persönlich würde das nicht mit Anführungszeichen machen: Beim Import werden alle Meshes auf "Ohne Transparenz" gesetzt. Ich würde solche Begriffe/Menüpunkte/Verweise grundsätzlich Kursiv setzen. Der Leser sieht dann schneller, was er klicken soll: Wählen Sie den Menüpunkt Start der Simulation. Beim Import werden alle Meshes auf Ohne Transparenz gesetzt.
Wie gesagt, das ist eher subjektiv, was einem persönlich besser gefällt. Muss man nur 1x festlegen.

Und 1000 andere Dinge...

Mr. X und Alwin ... das mit dem Siezen oder eher der neutralen Ansprache, ist eher eine Festlegung wie das Dokument sein soll. Wir halten es bei uns so, dass unsere eigenen Leute ohne "Sie" angesprochen werden (Schalter A in Pos. 2 schalten), Endkunden aber mit "Sie" angesprochen werden (Stecken Sie den Netzstecker in die Dose).

[Johannes]

Das Geniale an dem nüchtern-technischen „man“-Schreibstil ist ja, dass der Nutzer überwiegend weder gesiezt noch geduzt wird. Im klassischen deutschen Softwarebereich üblich ist das Siezen, das macht Zusi auch, wenn es notwendig ist (siehe Demo-Sprachdateien).

Die Sie-Ansprache in Michaels Beispielen ist mir intuitiv zu direkt. „Bauen Sie keine großen Module!“ ist halt doch was anderes als „Man sollte keine zu großen Module bauen.“ Eine gewisse Schwurbeligkeit im Ausdruck kann man dem aktuellen Stil aber nicht absprechen. Das erste Beispiel von Michael finde ich daher gelungen.

Aber eigentlich hätte ich doch lieber Zusi 3 als eine sprachlich feingeschliffene Doku

Grüße
Johannes

P.S. Ich bin ja für eine Zusi-Doku in Leichter Sprache, damit’s auch ja für alle verständlich ist …

[Michael Springer]

Normalerweise modelliert man den durchschnittlichen Leser der Anleitung bei Projektbeginn:

Bei Zusi würde ich den durchschnittlichen Zusinutzer vermuten:
- 35 Jahre
- männlich
- Realschule
- Technischer Handwerksberuf

Und nach diesem Modell legt man dann die Parameter, wie Ansprache z.B., fest.

Nachtrag:
Egal wie schrecklich oder gut Anleitungen sind, der Leser gewöhnt sich an den Stil und das Layout. Und wenn alles konsistent schlecht ist, ist das immer noch besser, als mal so und so geschrieben. Das verwirrt die Leser noch mehr. Daher ist eine der wichtigsten Forderungen an eine Anleitung die Einheitlichkeit.

Nachtrag 2:
Zum Thema simple Sprache: Für die Luftfahrt gibt es auch eine einfache Sprache das simplified english.

[Michael Springer]

Bei Sätzen mit "man" ist oft das Problem, dass man ins Passiv kommt und nicht klar ist, wer was tun muss.

Beispiel:
Man kann Zusi beenden.

Muss ich das machen? Macht der PC das? Macht das meine Mutter, weil ich zulange spiele?

[Mr. X]

Sogar das "man" kann man vermeiden: Große Module sind zu vermeiden. xD

[Johannes]

Bei Sätzen mit "man" ist oft das Problem, dass man ins Passiv kommt und nicht klar ist, wer was tun muss.

Beispiel:
Man kann Zusi beenden.

Muss ich das machen? Macht der PC das? Macht das meine Mutter, weil ich zulange spiele?

Da würde ich ganz sprachspalterisch widersprechen, Passivsätze mit „man“ kann man gerade eben nicht bilden („Durch man wird Zusi beendet“ … nö).

Und für mich ist „man“ in der Zusi-Doku ziemlich eindeutig der (einzige) Nutzer, die von dir beschriebenen Mehrdeutigkeiten sehe ich nicht. Wieso sollte sich „man“ auf den PC beziehen?

Für mich kommt halt dieser Schreibstil fast lockerer rüber als eine direkte Ansprache mit „Sie“ oder „Du“. Ist natürlich alles Ansichtssache. Letzlich habe ich wahrscheinlich weniger Erfahrung mit deutschen Softwarehandbüchern als du

Grüße
Johannes

[AndiS]

Ich würde da einen Unterausschuß gründen, der für Zusi 3.0.5 eine Lösung erarbeitet, die dann vielleicht bei Zusi 3.1 fertig ist. Schnell geht da nämlich gar nichts.

Mir ist es beim Übersetzen der Featureliste auch aufgefallen, daß hier eine sehr trockene Ingenieurssprache gepflegt wird. Aber bei einem Text von Ingenieuren für technisch interessierte Menschen ist das doch nicht schlimm. Und bei einem 500-Seiten Opus schon gar nicht. Entweder man vertieft sich da hinein, oder eben nicht.

Ich bin der erste, der einfacher, mitreißender Sprache das Wort redet. Aber ich glaube, daß die in Tutorials gehört und nicht in ein Referenzwerk. Falls diese 500 Seiten tutorialartige Teile enthalten, dann kann man sich die zur Brust nehmen und für's Volk aufpeppen. Das können dann auch externe Autoren leicht übernehmen, jeder einen anderen Teil, parallel, ohne viel Koordinationsaufwand.

Das führt auch wieder zur TeX-Formatierung zurück. Vielleicht ist diese Diskussion um den Stil eine Motivation, die optimale Bilderplazierung zu hinterfragen. Vielleicht sollte das 500-Seiten Opus einfach Referenzwerk sein, in dem alle Information enthalten ist, das aber nicht den Anspruch stellt, jeden mitzureißen. Basierend darauf entstehen dann kurze Einführungen in verschiedene Teilgebiete. Die OpenOffice-Variante gibt es ja noch. Wenn man die den Tutorial-Schreibern als Ausgangsmaterial zur Verfügung stellt, dann kann jeder auf seinen 20-30 Seiten die Bilder herumschieben, wie es optimal erscheint.

Auf keinen Fall würde ich mir zu viel von formalen Änderungen erwarten. Viel wichtiger ist der Anteil der Beispiele, die Abgehobenheit oder Konkretheit der Sprache, und ähnliche Fragen. Das alles ist aber gar nicht einfach zu beantworten. Beispiel: "Andererseits sollte man aber auch keine zu großen Module bauen, da sonst irgendwann der Arbeitsspeicher knapp wird." Wenn das nicht volksnah formuliert ist! Natürlich ist es nicht so präzise wie "Module sollten nicht mehr als 10.000 Polygone enthalten, und 2 km, mit Genehmigung des ZPA auch bis zu 4 km lang sein." Wer will denn wirklich wissen, wieviele User welche Rechner haben? Das einzige, was hier hilft, sind Beispiele. Für die größten und die kleinsten Module listet man verschiedene Parameter (Länge, Fläche, Anzahl der Signale, Gebäude, Pflanzen, Gesamtlänge der Gleise). Dann kann man noch ein Histogramm für jedes dieser Parameter zeichnen, das die Verteilung der bisher geschaffenen Module zeigt. Die kann man aber eher erst nach der Release von 3.0 bringen. Und die machen aus den 500 Seiten auf jeden Fall 2000 oder 3000. Was gut ist. Aber vor der Release von 3.0 brauchen wir das wirklich nicht.

P.S.: Eine Lanze für "man"!
"Man kann Zusi beenden."
Das ist die ganze Wahrheit, so wie sie ist. Du kannst sehr wohl auch Mutti holen, um Zusi zu beenden. Du kannst es selber machen. Du kannst dich auch kränken, daß ich Du sage und nicht Sie. Irgendwer beendet Zusi oder es läuft weiter. So ist das. Mehr ist da nicht. Der Computer ist bei "man" nie gemeint.

[Carsten Hölscher]

Im Forum ist das Du üblich. Die Doku geht aber ggf. auch an Firmenkunden. Den Spagar meistert man am besten ohne Du/Sie, darum kommt es auch nicht vor. Ansonsten finde ich die Diskussion schon sinnvoll, aber nicht im Moment. Wir bauen die Doku gerade auf Tex um und da muss sie inhaltlich erstmal temporär eingefroren sein. Openoffice-Doku gibt'S leider nicht wirklich, da OO offenbar mit der Komplexität inzwischen überfordert ist und willkürlich immer wieder Seiten ausläßt im pdf-Export - darum ja der Wechsel zu TeX.

Um so wichtiger erscheint es aus meiner Sicht, mit den Formatierungsdingen zu einer tragfähigen Lösung zu kommen, ohne einen Anspruch auf die Weltformel zu entwickeln.

Das Thema Bilder soll je gerade gelöst werden, damit man möglichst schnell ans Ziel kommt und eben gerade nicht in nerviger Fleißarbeit manuell 500 Seiten durchformatieren muss.

Carsten

[Michael Springer]

Bauen Sie keine großen Module.

Ich hatte das absichtlich so hart formuliert. Der Satz klingt eher negativ. Anleitungen sollten immer positiv formuliert sein, wenn möglich. Es gibt aber auch Gründe wo harte Formulierungen besser sind, z. B. Sicherheitshinweise bei gefährlichen Maschinen oder bei Strom.

Vermeiden Sie große Module.

Ist in diesem Falle die viel bessere Wahl, da es positiv formuliert ist.


Da geplant ist, die Anleitung auch an Firmenkunden weiterzugeben, würde ich persönlich die "man"-Sätze entfernen. Aber wie gesagt, ob eine Dokumentation gut ist oder nicht, ist meistens ein Subjektives empfinden. Doku-Qualität in der Praxis valide zu messen ist sehr sehr schwierig. Die eine Hälfte bevorzugt das, die Andere das. Ich freue mich aber sehr, das eine gewisse Diskussion über das Thema Dokumentation zustande gekommen ist.

Am Ende muss Carsten festlegen wie er Dokumentation/Anleitungen für seine Firma sieht und er möchte das geschrieben/formuliert wird. Für zukünftige Projekte oder Erweiterungen empfehle ich einen Redaktionsleitsfaden zu erstellen, der die Autoren bei zukünftigen Erweiterungen unterstützt. Das spart viel Zeit und Nerven und jeder Autor ist froh, wenn er ein paar Regeln an die Hand bekommt. Ein Beispiel für einen Redaktionsleitfaden ist "Erstellen von wikipedia-Artikeln".

[Michael_Poschmann]

Hallo Michael,

danke für Deine Hilfestellung in Sachen "lesbarer" Dokumenation.

Ich möchte an dieser Stelle zu bedenken geben, daß die von Carsten angeführten rund 500 Seiten über mehrere Jahre gewachsenen Bestand darstellen. Würde man auf der grünen Wiese neu starten, ließen sich strukturelle Grundsätze vermutlich leichter berücksichtigen als zum jetzigen Zeitpunkt. Die komplette Überarbeitung des Mammutwerks würde nach meiner Abschätzung mindestens ein halbes Mannjahr an Aufwand erfordern, und dies zusätzlich zum derzeitigen, in meinen Augen grenzwertig detailverliebten Vorhaben, die Buchdruckkunst zu revolutionieren.

Nun gut, für etwa 100 Seiten Tutorium zeichne ich als Autor verantwortlich, hier wäre Carsten nicht gefordert. Allerdings sage ich hiermit klar aus, daß ich einen solchen Aufwand derzeit nicht leisten werde. Meine Freizeitressourcen setze ich lieber an anderer Stelle für Kernaufgaben der Simulation ein.

Da ich die Doku recht häufig nutze, behaupte ich, daß sie in der jetzigen Form als Nachschlagwerk nutzbar ist. Und das stellt für mich das Entscheidungskriterium dar. Vermutlich wird die Anzahl der Anwender, die Zusi aufgrund der Softwareeigenschaften erwerben wollen und die Dokumentation lediglich als Beiwerk betrachten, die Gruppe der Genuss-Leser bei weitem überwiegen.

Mit Blick auf völlig aus dem Lot geratende Projektzeitpläne müssen wir uns dringend von immer neuen Anforderungen an Carstens Werk auf Nebenkriegsschauplätzen lösen - sonst wird das Projekt niemals fertig! Und das will hier ja hoffentlich niemand...

Auf funktionalem Sektor ist noch genug zu tun, um das Jahr 2014 mit wirklich sinnvollen und auch notwendigen Aktivitäten auszulasten.

Gruß mit der abermaligen Bitte um Fokussierung auf das Kerngeschäft
Michael

[F. Schn.]

OT: Weil hier jetzt der erste Doku-Ausschnitt erwähnt wurde, und bevor sich was falsches einprägt: 5.1.2.2. Texturen => .png (Portable Network Graphics) Verlustfrei komprimiert Kein separater Alphakanal. Natürlich kann PNG einen Alphakanal besitzen (s. auch). Wird sogar in StellSi genutzt (bei den Icons).

F. Schn.

PS: völlig aus dem Lot geratende Projektzeitpläne ... Guter Spruch.

[Michael Springer]

Immer und immer wieder wird gebetsmühlenartig geschrieben, dass Leute aus der Zusi-Community gesucht sind, die Aufgaben übernehmen. Häuser bauen in 3D mit Blender. Hab ich versucht. Kann ich nicht. OK, soweit so gut. Also habe ich mir gedacht, ich versuche auf dem Gebiet zu helfen, wo ich mich auskenne. Anleitungen, anleitende Texte, usw.

Mir ist klar, dass die Anleitung in jahrelanger Kleinarbeit entstanden und damit auch gewachsen ist. Mir ist auch klar, dass man keine 500 Seiten in 2 Tagen überarbeitet. Mir ist auch klar, dass die komplette Formatierung des Dokuments auch nicht einfach über den Haufen geworfen weden kann. Ich habe auch nicht gefordert, dass ihr das selbst machen müsst. Ich habe angeboten diese Arbeiten zu übernehmen. Somit käme auch kein Mehraufwand auf Euch hinzu...

Nehmen wir mal an, dass nur durch andere Formulierungen der Text um 10-20% kürzer wird. Das heißt, die Anleitung wäre 50-100 Seiten kürzer. Bei 3D-Modellen wird stundenlang um jedes Dreieck gefeilscht, das man sparen kann. Aber hier ist es vollkommen egal.

Ach ja mal so nebenbei die Bedienungsanleitung ist Bestandteil des Produktes. Ist die Bedienungsanleitung nicht aussagekräftig oder nicht verständlich gilt das Produkt selbst als mangelhaft. Das heißt, der Hersteller muss den Mangel beheben, klappt das nicht kann das Produkt zurückgeben oder z.B. ein Rabatt von x % Nachlass aushandelt werden, aufgrund der schlechten Anleitung. Bei den Privat-Lizenzen für Zusi 3 im Bereich von 50€ - 100€ sicherlich eine relativ einfach Sache, aber bei Carstens Firmenkunden mit Projektsummen von sicherlich 100.000€ und mehr sind 10% eine Menge Holz.

Zwei Produkte, die sich in Ausstattung und Preis ähneln, eins mit China-Anleitung, eins mit guter Anleitung. Welches würdet ihr kaufen? Naja ist wie überall eben. Jeder schimpft nur über die schlechten Anleitungen, aber beschwerden tut sich niemand beim Hersteller. Somit wird sich auch nie was ändern...

Ich respektiere Eure Entscheidung, wenn ihr nichts ändern wollt. Ist ja nur ein Nebenkriegsschauplatz.

Schönes Wochenende

[Carsten Hölscher]

Vielleicht hast Du das falsch aufgenommen. Es geht im Moment orgamäßig schlecht, weil es gerade den Umbau auf TeX gibt und eine parallele Umarbeitung der Texte dadurch nicht möglich ist.
Wenn das stabil ist, nehme ich die Hilfe gerne an - wenn es mich nicht allzu viel Betreuungsaufwand kostet. Bei ein paar Deiner Vorschläge war ich z.B. nicht ganz sicher, ob der Sinn gewahrt blieb und wenn der Sinn nicht mehr paßt dann ging der Schuss natürlich nach hinten los. Es wird also vermutlich nicht ganz ohne fachliche Begleitung gehen.

Carsten

[Michael_Poschmann]

Hallo Michael,

in den Entscheidungsprozess bezüglich der Doku bin ich ebensowenig eingebunden wie die übrigen hier mitschreibenden Interessenten, das liegt letztlich in Carstens Hand. Daher halte ich mich hier raus.

Aber eine Frage habe ich dann doch. Du schreibst:

Das heißt, der Hersteller muss den Mangel beheben, klappt das nicht kann das Produkt zurückgeben oder z.B. ein Rabatt von x % Nachlass aushandelt werden, aufgrund der schlechten Anleitung.

(Hervorhebung durch mich)

Gibt es dazu eine belastbare Quelle? Der Hersteller (in diesem Fall von Software) steht für ein mangelfreies, d.h. spezifikationskonformes Softwareprodukt gerade. Soweit einverstanden. Wo gibt es eindeutige Regelungen zu den Anforderungen an die Dokumentation? Du bist ja vom Fach, daher hoffe ich, daß Du hier meine - auch über den Zusi-Tellerrand hinausgehende - Neugierde befriedigen kannst.

Gruß und Dank im voraus
Michael

[Johannes]

Naja ist wie überall eben. Jeder schimpft nur über die schlechten Anleitungen, aber beschwerden tut sich niemand beim Hersteller. Somit wird sich auch nie was ändern...

Mal ganz ehrlich, eine schlechte Anleitung sieht anders aus. So etwa .

Ich wuerde allerdings dazu raten, mit der Ueberarbeitung (sicherlich ein ehrenwertes Ansinnen) zu warten, bis das erste Release raus ist. Erstens kann sich dann niemand beschweren, die Arbeit haette das Release verzoegert. Zweitens ist dann die Doku wirklich final.

Gruesse
Johannes