Technischer Überprüfungsprozess bei der Verwendung von FrameMaker

Ich bin Ingenieur. In meinem Unternehmen scheinen Ingenieure viel Zeit damit zu verbringen, technische Dokumentation zu überprüfen, die von Menschen geschrieben wurde, die in verschiedenen Büros und Zeitzonen arbeiten. Ein Teil des Grundes, warum wir so viel Zeit aufwenden, ist, dass uns viele kleine Fragen gestellt werden, eine E-Mail nach der anderen, anstatt größere Blöcke von Überprüfungsaufgaben zu erhalten, die einer Ansicht der vollständigen Dokumentation überlagert sind.

Die Autoren verwenden FrameMaker. Ingenieure haben keine FrameMaker-Lizenzen, wissen aber, wie man Code-Review-Tools verwendet. Meine Fragen sind:

  1. Gibt es eine Standardmethode zur Verwendung von FrameMaker, bei der die Dokumentationsartefakte als Textdateien (z. B. XML) in ein Quellcodeverwaltungssystem eingecheckt werden, sodass sie mit Standard-Codeüberprüfungstools überprüft werden können?
  2. Wenn nicht, gibt es einen anderen guten Mechanismus/Prozess, der es technischen Redakteuren und Prüfingenieuren ermöglicht, an gemeinsam genutzten FrameMaker-Dokumenten zusammenzuarbeiten?
Willkommen bei Writing.SE Eric ! Wenn Sie etwas Freizeit haben, möchten Sie vielleicht die Tour und das Hilfezentrum besuchen . Habe Spaß!

Antworten (2)

Lange Erfahrung hat viele von uns gelehrt, dass wenn Sie einer beschäftigten Person eine E-Mail mit mehr als einer Frage schicken, sie nur die erste beantwortet und den Rest ignoriert. Daher haben sich viele von uns angewöhnt, pro E-Mail eine Frage zu stellen. Möglicherweise können Sie einen Teil des Problems lösen, indem Sie die Autoren bitten, Ihnen eine Reihe von Fragen in einer einzigen E-Mail zu senden – solange Sie sie tatsächlich alle beantworten.

Erwarten Sie jedoch nicht, dass Sie als Erstes ein fertiges Dokument mit angehängten Überprüfungsfragen erhalten. Technische Redakteure haben selten Zugang zu Informationsquellen, die es ihnen ermöglichen würden, ein vollständiges Dokument zu schreiben, ohne den Ingenieuren einen Haufen Fragen zu stellen. Sie brauchen Ihre Antworten, um das Dokument schreiben zu lassen.

Was FrameMaker betrifft: Framemaker gibt es in zwei Varianten, unstrukturiert und strukturiert, und heutzutage werden strukturierte Framemaker mit Unterstützung für ein strukturiertes Schreibsystem namens DITA geliefert. Wenn Ihre Autoren die strukturierte oder DITA-Version von Framemaker verwenden, gibt es eine XML-Version des Dokuments, die mit Standard-Code-Review-Tools überprüft werden kann. Wenn sie jedoch unstrukturierten Framemaker verwenden, lautet die Antwort nein. Mein Eindruck ist, dass die meisten Organisationen, die FrameMaker verwenden, immer noch die unstrukturierte Version verwenden.

Eine gängige Methode zur Überprüfung von Dokumentationen, die mit unstrukturiertem FrameMaker erstellt wurden, ist die Verwendung von PDFs und die Verwendung der in Adobe Acrobat Reader integrierten Überprüfungswerkzeuge. Es gibt sogar eine serverbasierte Version (zumindest gehe ich davon aus, dass es sie noch gibt), mit der mehrere Prüfer dieselbe Kopie einer PDF-Datei kommentieren können, sodass sie die Kommentare sehen können, die andere bereits abgegeben haben.

Ich persönlich hätte lieber eine Wurzelkanalbehandlung als eine Überprüfung auf diese Weise. Wie Sie würde ich es vorziehen, dass der gesamte Prozess mithilfe von strukturiertem Text und standardmäßigen textbasierten Überprüfungstools stattfindet. Aber viele technische Redakteure scheinen diesen Ansatz zu bevorzugen, und es gibt auch einige Ingenieure, die darauf bestehen, dass sie die endgültige gedruckte Form des Dokuments überprüfen müssen – ich habe keine Ahnung warum, aber es ist eine unglückliche Tatsache des Lebens.

Danke Mark. Wir behandeln die Probleme der Vordokumentation (was Ingenieure den Autoren in Form von Notizentwürfen, Demos usw. zur Verfügung stellen sollen) auf einer separaten Spur, aber ich verstehe den Punkt in Ihrem zweiten Absatz auf jeden Fall. Serverbasierte Überprüfungen von PDF-Dokumenten wären für mich besser als unser derzeitiger Prozess, Wurzelkanäle und alles. Ich werde sehen, was wir zwischen den beiden von Ihnen skizzierten Ansätzen finden können.
@EricHirst finden Sie heraus, ob sie (1) die strukturierte Version (XML) und (2) die Quellcodeverwaltung verwenden. Wenn ja, dann haben Sie bessere Optionen zum Überprüfen als die PDF-Kommentare, die schlechter als Root-Canal sind (ich hasse die auch).

Die Verwendung von Code-Review-Tools für FM XML hat einige Nachteile:

  1. Sie laufen Gefahr, dass Programmierer den XML-Code und nicht nur den Text ändern wollen. Sie müssten Tools verwenden, um die XML-Struktur schreibgeschützt zu machen und nur Änderungen an den Textelementen zuzulassen.

  2. Der Text wird durch die Inline-Tags für Xrefs, Texteinschübe, Zeichenstile usw. weniger lesbar.

PDF vermeidet all dies und hat einige zusätzliche Vorteile:

  1. Es hindert die Korrektoren daran, den Quelltext zu ändern. Ingenieure sind keine Autoren, als Autor möchte ich die endgültige Autorität über den Text in meinem Dokument.
  2. Wenn Sie PDF verwenden, können Sie den Änderungsverfolgungsmechanismus in FrameMaker verwenden, um den neuen Text zu markieren, sodass sich der Korrektor darauf konzentrieren kann, anstatt das gesamte Dokument lesen zu müssen.
  3. Mit PDF können Sie ein Dokument gleichzeitig von mehreren Korrektoren prüfen lassen und anschließend die Kommentare einsammeln. Oder sie können nacheinander prüfen und auf die Kommentare früherer Prüfer reagieren.
  4. Mit PDF-Kommentaren kann der Prüfer angeben, warum eine Änderung vorgenommen werden muss. Dies gibt dem Autor einen besseren Einblick in das, worüber er schreibt.