Passendes Konzept für eine Anwenderdokumentation

[Uwe Raabe]

Ich benutze Help & Manual in der professional Variante.

- Module: es gibt dort u.a. die Möglichkeit einzelne Teile bei der Ausgabe zu unterdrücken (oder einzuschließen - je nach Standpunkt).
- Bei der kundenspezifischen Doku bin ich mir nicht sicher, wie man das am besten löst, aber die Community ist sehr rege und hilfreich.
- Single-Source-Publishing: hier ist der Name Programm
- Versionshistorie: das Projekt besteht aus XML-Dateien, die sich mit jedem VCS bequem verwalten lassen
- Zugriffsrechte: kann ich nichts zu sagen -> Community
- Mehrsprachigkeit: unterschiedlich-sprachige Dokus sind untereinander verlinkt, so daß Änderungen am Original leicht in den anderen Sprachen darstellbar sind.

[Sybok Factor]

Ich kann Uwe da nur zustimmen. Help & Manual ist vergleichsweise günstig und leicht zu bedienen. Ich habe vor zwei Jahren verschiedene Tools verglichen, an zweiter Stelle wäre Author-it gekommen, ist aber sehr teuer und konnte unser bestehendes Handbuch nicht importieren.

Für Help & Manual spricht außerdem: Ist in DELPHI geschrieben!

Viele Grüße
Sybok Factor

[Aurelius]

@ Bernhard: Ist eigentlich ein guter Einwand, daher habe ich den Teil erst einmal rausgenommen. Bei Bedarf sollte soetwas, wenn es dann doch benötigt wird, relativ einfach zu bewerkstelligen sein.

[Aurelius]

Ein kleiner Push

[Aurelius]

Und nochmal ein letztes Schubserchen.

Software der DPler scheint so gut zu sein, die benötigen keine Doku

[mkinzler]

Ich lasse die Doku immer von den Anwendern erstellen ( sind interne Anwendungen)

[Dezipaitor]

Anwenderdokumentation entsteht aus der Spezifikation, u.a. den Anwendungsfällen.
Schau dir am Besten viele verschiedene Dokus, z.B. u.a. http://confiss.org (Mitwirkender)

Weiterhin muss man sagen, dass viele Handbücher garnicht gelesen werden. Manchmal ist es daher besser, (zusätzlich) eine Art Wissensdatenbank aufzubauen (oder FAQ) und zu propagieren, wo der Anwender gezielt suchen kann.
Weiterhin sollten Begriffe definiert werden (meist bereits in der Spezifikation gemacht), damit Anwender und Hersteller über dasselbe Thema reden.
Auch wichtig ist, dass der Schriftstil nicht zu kompliziert oder zu einfach gehalten wird, da dadurch die Anwender den Inhalt schlechter verstehen.
Und letztendlich ist es sehr wichtig, die Dokumentation auch am Anwender zu testen, um zu sehen, wo Nachbesserungsbedarf besteht.

Meine Liste ist nur eine Aufzählung und ist sicherlich nicht vollständig oder der Weisheit letzter Schluss.