MadCap hat eine neue Version seines Help Authoring Tools „Flare“ herausgebracht. Ich habe einen ersten Blick darauf geworfen.
Als ob die Erstellung einer Dokumentation für den Technischen Redakteur nicht schon schwierig genug wäre, stellt eine Onlinehilfe noch eine größere sprachliche und didaktische Hürde dar.
Neben der konsistenten Benutzerführung und der sachlogischen Beschreibung des Produkts muss eine Onlinehilfe auch sprachlich und didaktisch anders angefasst werden als eine Dokumentation, die als Papier oder PDF erscheinen soll: Einfach mal schnell noch eine Tabelle dran kleben genügt nicht mehr. Wenn Papier auch geduldig sein mag – der Online-Nutzer ist es nicht.
Er will auch auf seinem Smartphone alle relevanten Informationen schnell und sicher erreichen, er will nicht lange scrollen oder blättern, geschweige denn lesen. Eine Formulierung wie die folgende geht da gar nicht:
„Lesen Sie bitte die zu diesem Produkt gehörende Sicherheitsinformation insbesondere dann besonders sorgfältig, wenn Sie häufiger mit dem Produkt in einer potenziell gefährlichen Umgebung ohne Aufsicht durch sachkundige Fachkräfte arbeiten müssen.”
Das ist schon gedruckt eine Zumutung, auf dem Bildschirm ist es das erst recht, selbst wenn man auf die höfliche Bitte und das Personalpronomen verzichtet.
Bei Redakteuren, die das Thema Onlinehilfe ernst nehmen, wird zunehmend zugunsten einer schnelleren Erfassung auf textarme Anleitungen gesetzt. Bilder erleichtern die Erfassung, bewegte Bilder erst recht.
Aber nicht alle Sachverhalte lassen sich grafisch transportieren. Manche müssen die Vielseitigkeit der Sprache nutzen, ihre Fähigkeit zu abstrahieren und zu motivieren. Nur leider müssen Texte übersetzt werden.
Und dann kommt die Übersetzung
Wenn Sie einen guten Übersetzer haben und diesen auch anständig bezahlen, schafft er es vielleicht, den oben genannten Satz auch in die Zielsprache zu bringen, ohne den Leser zur Verzweiflung zu treiben1
Aber angenommen, Sie haben als Technischer Redakteur diese Herausforderung gemeistert und tatsächlich knappe und gut lesbare Sätze formuliert, die auch fachlich einwandfrei sind: Sie sind noch nicht ganz fertig, denn nach der Übersetzung wird die Onlinehilfe ja noch publiziert.2
In der modernen Onlinehilfe wird ein Inhaltsverzeichnis mit den jeweiligen Inhalten verknüpft und ein Suchindex automatisch angelegt (das sollten Sie auf jeden Fall verwenden), denn nur mit dem Inhaltsverzeichnis bzw. der Navigation kommt der Benutzer nicht weit. Danach werden alle Inhalte in ein Template gegossen, das das Aussehen vorgibt und gleichzeitig auf die Bildschirmgröße des Anzeigegeräts Rücksicht nimmt: Bilder werden skaliert, Navigation ausgeblendet, um Platz zu sparen, Sätze werden umgebrochen. Das Ziel ist die Ausgabe für alle Geräte, die eine Software besitzen, die HTML5 anzeigen kann. Nun damit sind ohne Aufwand auch nicht-europäische Sprachen darstellbar, können Inhalt und Form sinnvoll getrennt werden.
Der Benutzer soll davon nichts merken: der Inhalt ist der Gleiche, egal auf welchem Gerät er ihn konsumiert. Und zwar ih in allen Sprachen.
Umschalten
Was aber, wenn der Benutzer zwar in einem englischsprachigen Land wohnt und dort ein Produkt benutzt, dass in der Landessprache angezeigt wird, die Inhalte aber nicht versteht und nun Hilfe in seiner Muttersprache benötigt? Spanisch beispielsweise? Oder der Software-Administrator kommt aus Indien, soll aber eine Serverfarm in Italien einrichten und kann kein Italienisch? Das Personal will aber benötigt eine italienische Benutzeroberfläche.
Bislang wurde das meist so gelöst, dass sich der Administrator – um bei dem zweiten Beispiel zu bleiben – die Informationen ausgedruckt hat und mit einem dicken Handbuch bewaffnet (mehrere hundert Seiten sind fast normal) neben dem Rechner sitzt und versucht, den Inhalt des Handbuchs mit der Darstellung auf dem Bildschirm zusammen zu bringen: Bin ich auf der richtigen Seite im Handbuch? Wie heißt der Button auf Italienisch?
Es wäre jetzt viel einfacher, der Administrator könnte direkt auf dem Bildschirm die Sprache auswählen, die er besser versteht. Das geht seit kurzem mit MadCap Flare 12.
Neben anderen Features, mit denen die neueste Fassung beworben wird, ist dieses Feature für den Nutzer das wohl Sinnvollste. Gerade, wer eine Hilfe für einen internationalen Leserkreis publizieren möchte und mit dem Gedanken spielt, nicht für jede Sprache eine eigene Dokumentation zu verwalten und dann im Programm miteinander zu verbinden, ist das ein sehr reizvoller Gedanke. Flare erlaubt es damit, alle Projekte, die weiterhin getrennt vorliegen, aus einem Projekt heraus zu verwalten und zu veröffentlichen. Der Leser erhält einen zusätzlichen Button, mit dem er seine gewünschte Sprache aufrufen kann – und direkt auf der gleichen Seite landet, aus der er die Sprache aufgerufen hat.
Zwar lassen sich auf die gleiche Weise auch PDF zusammenpacken, indem alle Sprachen in der gleichen Reihenfolge aneinander gehängt werden, dies widerspricht aber komplett der Benutzerlogik.
Bonbon zum Schluss
Für den Redakteur hat sich MadCap noch ein Schmankerl einfallen lassen: Inhalte, die für den Überarbeitungsprozess die Änderungsverfolgung nutzen, werden mit Markierungen versehen, die für den Korrekturlauf direkt in die PDF übertragen werden können. Das erleichtert bei langen Dokumenten den Austausch per PDF oder Word und kommt damit dem Wunsch vieler SMEs entgegen, die einen Inhalt nicht ohne papierähnliches Format lesen möchten.
Der Bearbeitungsprozess verliert damit eine der größten Hürden: Häufiges Nachfragen, weil keiner der Beteiligten die richtige Stelle im Text findet, ist ein Produktivitätskiller erster Güte.
Kurz: Alleine wegen dieser beiden Features lohnt ein Umstieg auf Flare als Publishing-Lösung für Online- und auch Offline-Dokumente.
Bildquelle: MadCap Software
Wobei trotz bester Übersetzungsleistung diesem Satz immer anzumerken sein wird, dass er nur in der deutschen Sprache seinen Ursprung haben kann. ↩
Und selbst wenn Sie die Informationen in einem Druckformat wie PDF ausgeben, schadet ein gut aufbereiteter Inhalt dem Verständnis keineswegs. Es ist nämlich nicht so, dass die Benutzer bereit sind mehr zu lesen, nur weil es gedruckt ist. ↩