Sicherheits- und Warnhinweise – Ein LEIT-FADEN aus dem Dschungel?

leitfaden_warnhinweisWer technische Dokumentation schreibt, kommt früher oder später mit dem Thema Sicherheits- und Warnhinweise in Berührung. Herauszufinden, welche Normen und Gesetze für das aktuelle Projekt relevant sind, stellt in der Regel keine allzu große Herausforderung dar. Aber schnell stellt man fest, dass all diese Regelungen doch einen enormen Spielraum für die konkrete Umsetzung lassen. Dass viele Redakteure verunsichert sind, ist deshalb nicht verwunderlich…

Klare Ziele

Hier setzt der „Leitfaden Sicherheits- und Warnhinweise“ an. Mit ihrem Werk haben sich die Autoren zwei Hauptziele gesetzt:

  • Technischen Redakteuren einen Überblick über die gesetzlichen und normativen Anforderungen zu geben und
  • eine Entscheidungshilfe für die konkrete Umsetzung von sicherheitsbezogenen Informationen bereitzustellen, die mit konkreten Beispiele illustriert wird.

Klare Grenzen

Die Autoren machen von Anfang an auf zwei Einschränkungen aufmerksam: Einige klar definierte Branchen werden nicht behandelt. Außerdem werden die sicherheitsrelevanten Informationen nur aus Herstellersicht betrachtet, was in dem Kontext durchaus gerechtfertigt ist.
Das Thema wird dafür aber insgesamt sehr strukturiert abgearbeitet. Auch Definitionen zentraler Begriffe sowie ein Abkürzungs- und Literaturverzeichnis fehlen nicht. Viele Informationen sind tabellarisch dargestellt, was den Überblick erleichtert. Die Autoren bemühen sich, auch Hintergründe nachvollziehbar darzustellen statt nur abstrakte Fakten zu präsentieren. Dies erfolgt manchmal allerdings auf Kosten der angestrebten Übersichtlichkeit. Auch mit kleinen Einschüben à la „das Wichtigste in Kürze“ hätte man diese Anschaulichkeit erreichen können.

Bemerkenswert: Die Autoren unterscheiden begrifflich zwischen „Warnhinweise“ und „Sicherheitshinweise“, die oft eigentlich synonym verwendet werden. Sicherheitshinweise stehen am Anfang der Anleitung in einem gesonderten Kapitel. Ihr Zweck: Den Anwender mit dem Produkt insgesamt vertraut machen und ihn zum sicheren Umgang mit dem Produkt befähigen. Sie müssen also nicht zwangsläufig als normierte Warnhinweise formuliert sein. Warnhinweise hingegen stehen immer in dem Zusammenhang, in dem eine konkrete Gefährdung auftritt und sollten als solche eindeutig erkennbar sein.

Sicherheitsbezogene Information: Wege zur Qualität

Die ersten beiden Kapitel vermitteln wichtige Grundlagen darüber, welche Arten von sicherheitsbezogenen Informationen es gibt und wie diese in der Produkt- bzw. Dokumentationsentwicklung eingebettet sind. Typische Fehlerquellen zu Prozessbeginn, die aber gravierende Folgen haben, werden beleuchtet. Sehr wertvoll sind z. B. die Hinweise auf Mängel in der Risikobeurteilung. Dem Leser wird auch deutlich vorgeführt, wie wichtig eine klare und strukturierte Vorgehensweise schon zu Beginn der Produktentwicklung ist.

Aber auch andere wichtige Qualitätsfaktoren werden in einem größeren Gesamtkontext betrachtet. Die Textsorte „sicherheitsbezogene Informationen“ stellt besondere Anforderungen hinsichtlich der Verständlichkeit – mit dieser Aussage überraschen die Autoren wohl niemanden; sie stellen aber klar, warum „Verständlichkeit“ sich in diesem Kontext nicht auf „verständlich formuliert“ reduzieren lässt. Dass auch der Technische Redakteur nicht alleine die Verantwortung dafür trägt (und tragen darf), dürfte für einige eine angenehme Überraschung sein. Der Leitfaden erklärt, wie wichtig die Zusammenarbeit zwischen Konstruktion und Redaktion für die Qualität des Endergebnisses ist, und zeigt auch mögliche Wege auf, dies umzusetzen. Man erfährt zum Beispiel, warum es von zentraler Bedeutung ist, die getroffenen Entscheidungen über die Sicherheitsinformationen zu dokumentieren.

Rechtliche und normative Anforderungen: Ein klarer Überblick

Kapitel 3 und 4 geben einen Gesamtüberblick über die Quellen für gesetzliche und normative Anforderungen weltweit. Diese sind nach drei Aspekten gegliedert: Region, branchenübergreifende und branchenspezifische Anforderungen. Diese Art der Aufbereitung erweist sich fürs schnelle Nachschlagen als sehr praktisch. Damit lösen die Autoren ihr erstes Hauptziel.
Die kontrastive Darstellung der gesetzlich-rechtlichen Grundlagen in den USA und Europa und die praktischen Tipps zur Umsetzung helfen, Kriterien für prüfbare Qualität festzulegen.
Was die Normen betrifft, werden nur die relevantesten besprochen. Man kommt also nicht darum herum, selbst zur prüfen, wie die Sachlage im eigenen Fall ist. Aber der Leser bekommt jede Menge Anhaltspunkte, was er in Betracht ziehen soll.

Worauf es bei der Umsetzung ankommt…

Die Empfehlungen zur Umsetzung in Kapitel 5 vermitteln meiner Meinung nach eine gute Basis, um eigene Entscheidungen zu treffen, vor allem auch deshalb, weil die Autoren einige Grundlagen zur kognitiven Wahrnehmung berücksichtigen.
Behandelt werden die wichtigsten Aspekte:

  • Aufbau und Inhalt des Sicherheitskapitels (mit Mustergliederungen)
  • Gestaltung
  • Platzierung
  • Formulierung

Auch das Zusammenspiel mancher Aspekte (z. B. Gestaltung in Abhängigkeit von Platzierung) wird angesprochen.

Zwar gehen die Autoren gesondert auf die Warnschilder ein, aber dieses Thema fällt meines Erachtens etwas zu kurz aus. Dies hängt womöglich damit zusammen, dass diese in den Bereich der Konstruktion fallen.

Mein persönliches Fazit

Persönlich habe ich zwei Sachen vermisst.
Zum einen hätte ich erwartet, dass die Belange der mobilen Dokumentation auch einen deutlichen Raum bekommen. Denn insbesondere die Dokumentation, die auf dem Smartphone gelesen wird, stellt besondere Anforderungen an den Text, die durch die hier dargestellten Prinzipien nicht abgedeckt werden.
Auch hätte ich mir einen praktischen Teil gewünscht oder zumindest eine umfangreichere Sammlung kommentierter Beispiele.

Dennoch bleibt mein Gesamturteil positiv: Dieser Leitfaden vermittelt dem Leser die wesentlichen Grundlagen und stellt ihm ein wichtiges Instrumentarium bereit, um eigenständig sinnvolle Entscheidungen zu treffen.

Literatur: Heuer-James, Jens-Uwe u. a. [2014]: Leitfaden Sicherheits- und Warnhinweise, tekom Stuttgart, ISBN 978-3-944740-03-4

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als elektronisches Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

600 Regeln für die Content-Qualität

doctima_contentruleset600 Regeln? Das kann doch kein Mensch im Griff behalten! Stimmt. Deswegen haben wir bei doctima das ContentRuleset entwickelt, eine Software, die Technische Dokumente systematisch auf unterschiedliche Prüffälle hin untersucht. Heute wollen wir einmal zeigen, was das ContentRuleset ist und was sich damit machen lässt.

Was ist das ContentRuleset?

Das ContentRuleset ist eine Sammlung von Regeln, die typische Prüffälle aus allen sprachlichen Ebenen und zu häufigen Prozessschritten abbilden. Die Prüfroutinen sind technologisch umgesetzt mit dem ISO/IEC-Standard ‚Schematron‘ (ISO/IEC FDIS 19757-3). Es integriert sich nahtlos in die Schematron-Schnittstelle des Content-Management-Systems SCHEMA ST4 (Version 2014 und 2016).

Mit dem doctima ContentRuleset geben wir Ihnen die Möglichkeit, das Schematron-Modul in ST4 zu einem leistungsfähigen Controlled-Language-Checker auszubauen durch …

  • ein elaboriertes Set an Prüfroutinen, das alle relevanten Qualitätsdimensionen für Content prüft. Und das bereits im Redaktionssystem – also noch bevor der Content zu einem Informationsprodukt verarbeitet wurde.
  • ein ausgeklügeltes Ordnungssystem, mit dem Sie die Routinen einfach und schnell verwalten und anwenden können.
  • eine funktionale Erweiterung des ‚ST4 Schematron Reports‘, die Ihnen das zielgenaue Detektieren und Beheben von Standardverletzungen vereinfacht.

Wer braucht es?

Das ContentRuleset adressiert den typischen Bedarf in der Technischen Redaktion. Es berücksichtigt Prüfkriterien aus den aktuellen Branchenstandards wie die tekom-Leitlinie ‚Regelbasiertes Schreiben‚. Dadurch ist das doctima ContentRuleset die ideale Lösung für Technische Redaktionen, die bereits mit ST4 arbeiten und die ihre Qualitätsprozesse optimieren und straffen wollen.

Das Content-Ruleset ist leicht zu handhaben und integriert sich nahtlos in den Arbeitsprozess. Der Katalog der Prüfroutinen lässt sich auf unternehmensspezifische Standards anpassen und bietet dadurch volle Flexibilität.

Wie bekommt man es?

Haben Sie Lust bekommen, das doctima ContentRuleset einmal in Aktion zu sehen? Möchten Sie mehr erfahren? Benjamin Rauschenberger beantwortet gerne alle Ihre Fragen; per Email an benjamin.rauschenberger@doctima.de und telefonisch unter 0911/97567027. Oder Sie vereinbaren gleich eine kostenlose Online-Präsentation auf unserer Produktseite. Wir freuen uns auf Sie!

5 Gründe, warum du Technischer Redakteur werden musst

Technische Redaktion – ein Sammelbecken für Quereinsteiger. Zunehmend gibt es aber auch Leute, die den geraden Weg gehen; bei mir zum Beispiel mit einem Masterstudium an der Hochschule Merseburg. Deshalb dachte ich mir, ich wende mich heute mal an alle, die sich fragen, ob Technische Redaktion für sie das Richtige ist, und versuche mich an der Berufsberatung.

1. Du bist diejenige, die immer sagt „Hast du mal in die Anleitung geschaut?“

Wenn jemand in deinem Umfeld seine neueste technische Errungenschaft nicht versteht. Denn du weißt: Die Anleitung wurde schließlich nicht umsonst geschrieben. Und meist löst sie das Problem besser als irgendwelche Internettipps.

Und wo wir schon dabei sind: Du bist auch diejenige, die jede Anleitung aufhebt, sich die guten heraussucht und die schlechten heimlich korrigiert – oder wenigstens darüber ablästert.

Und darüber hinaus heißt es nach deiner Meinung …

2. … „Studieren geht über Probieren“

Klar, ein wenig Risiko macht auch mal Spaß. Die Bohrmaschine kann man bestimmt auch mal benutzen, um das neue Tapetenweiß anzurühren… Aber Sicherheitshinweise zum Beispiel werden ja nicht zum Spaß angebracht, wie man im Studium lernt. Sie sind eine Wissenschaft für sich und gar nicht so einfach zu erstellen. Und auch vieles andere erledigt sich nicht „mit einer flotten Schreibe“, sondern ist solides Handwerk.

3. Du suchst gern die Nadel in der Suppe

Äh. Das Haar im Wald. Beziehungsweise das Salz im Heuhaufen. Ach das gibt’s doch nicht!

Was ich damit sagen will: Du liebst Sprache. Und du kannst richtig ungemütlich werden, wenn ebendiese misshandelt wird. Das kommt dir zugute, wenn du Texte zu Immobilienfonds oder Werkzeugmaschinen lektorierst. Wo es unverständlich wird, greifst du ein und klärst mit den Entwicklern die Stellen, die überarbeitet werden sollten.

Und jetzt zu den weniger offensichtlichen Dingen…

4. Du magst Listen….

a) Alphabetische Listen
1. Nummerierte Listen
• Listen mit Punkten und
√ ganz besonders die mit Häkchen!

Und zu Recht. Listen sind die Helden des Alltags, auch in der Technischen Redaktion. Genauso wie man zu Hause aufräumt, wenn man sonst im Chaos versinkt. Listen strukturieren Projekte, Aufgaben, Kriterien usw. Und sie können ganz subtil sogar für eine funktionierende Qualitätssicherung sorgen.

5. Du brauchst Abwechslung

Im Büro, auf dem Schreibtisch, auf deinem Monitor.

Und die bekommst du, das garantiere ich dir. So viel Abwechslung wurde dir das letzte Mal mit sechs Jahren im Bällebad bei IKEA geboten. An einem Tag erklärst du Steuersoftware, am nächsten die Funktionsweise einer Pumpe oder eines Panzers. Und du findest diese ganzen unbekannten Fachbegriffe, Funktionen und Zusammenhänge jedes Mal aufs Neue spannend. Außerdem kann dich irgendwann keiner mehr auf dem Gebiet Allgemeinwissen schlagen. Jauch kann einpacken.

Du willst noch mehr Gründe?

Mir fallen noch viele Punkte ein, die hier folgen könnten. Zum Beispiel, dass du gerne über den engen Tellerrand der eigenen Abteilung hinausblickst. Denn Technische Dokumentation ist eine echte Querschnittsaufgabe, bei der man mit allen möglichen Bereichen im Unternehmen in Kontakt kommt.

Letzten Endes kann man nur in der praktischen Arbeit sehen, was einem am meisten Spaß macht. Für mich ist es die Kombination von Sprache, Technik, Anwenderorientierung und vor allem, Projektziele gemeinsam mit einem Team zu erreichen. Ich jedenfalls fühle mich als Technische Redakteurin pudelwohl.

Die Übersetzung von Anleitungen als Kultur

Cover_Konventionen technischer KommunikationBrigitte Horn-Helf stellt mit „Konventionen technischer Kommunikation: Makro- und mikrokulturelle Kontraste in Anleitungen“ die Ergebnisse ihrer kontrastiven Textsortenvariantenforschung vor. Anhand von 12 Korpora hat sie Profile erstellt, die u.a. Technischen Übersetzern als praktische Arbeitshilfen dienen sollen.

Den meisten sprachwissenschaftlichen Publikationen eilt nicht gerade der Ruf voraus, besonders praxisbezogen zu sein; noch seltener wird ihren Autoren eine altruistische Zielsetzung unterstellt. Horn-Helf versucht sich mit ihrer Publikation an einem Gegenbeispiel: Sie will den Arbeitsalltag Technischer Übersetzer erleichtern und damit die Qualität (übersetzter) Anleitungstexte verbessern.

Eine gute Übersetzung…

… muss selbstverständlich inhaltlich und sprachlich korrekt sein. Aber die schnöde Aneinanderreihung von in die Zielsprache überführten Textbausteinen gelingt mittlerweile sogar dem Google-Translator (einigermaßen). Die Kunst einer professionellen Übersetzung liegt darin, den Zieltext auch den (Textsorten-) Konventionen der Zielkultur anzupassen. Und genau an dieser Stelle erkennt Horn-Helf Komplikationen.

Probleme in der Übersetzungspraxis

Zwar wird die Berücksichtigung der Zielkultur in der Übersetzungstheorie immer wieder postuliert. Selten wird diese aber in Form von konkreten Anweisungen, Hilfestellungen und Sprachratgebern für die Übersetzer greifbar gemacht. Laut Horn-Helf können sich die Übersetzer das Wissen um Textsortenkonventionen aber selbst nicht aneignen, da dafür in ihrem (wohl sehr) stressigen Arbeitsalltag einfach keine Zeit bleibe.

Man könnte annehmen, dass gerade diese Kenntnis interkultureller bzw. intersprachlicher Konventionen eine Kernkompetenz professioneller Übersetzer sein müsste. Horn-Helf erkennt diesen Anspruch aber allenfalls als weit verbreitete und anmaßende Forderung an diesen Berufsstand: Solange die Wissenschaft nicht hilft, könnten Übersetzer Textsortenkonventionen ihrer Zielsprachen höchstens „erahnen“, nie aber systematisch erfassen.

Hilfe für Technische Übersetzer

Selbstverständlich kann Horn-Helf nicht alle Technischen Übersetzern aus ihrer misslichen Lage befreien; wohl aber die, die zwischen der deutschen, englischen und russischen Sprache hin und her übersetzen. Dazu stellt sie sich der ultimativen Herausforderung: Kontrastive Textsortenprofile; genauer: kontrastive Textsortenvariantenprofile!

Bereits im Titel der Publikation wird auf den Unterschied zwischen Makro- und mikrokulturellen Kontrasten hingewiesen:

  • Makrokulturen sind für Horn-Helf die verschiedenen Kulturen bzw. Sprachen (hier: D/E/R).
  • Als Mikrokulturen bezeichnet Horn-Helf technisch-wissenschaftliche Disziplinen, wobei ihre Entscheidung für die Gegenüberstellung auf ‚Maschinenbau‘ und ‚Gerüstbau‘ fällt.

Aber Anleitungstexte müssen oft nicht nur Brücken zwischen Sprachen oder wissenschaftlichen Disziplinen schlagen:

  • Zusätzlich zu den beiden Mikrokulturen betrachtet Horn-Helf die in der Fachsprachenforschung allseits bekannte vertikale Schichtung ihrer drei Korpussprachen, auch bekannt als Theorie- und Verteilersprache oder interne und externe Kommunikation.

3 Makrokulturen [mal] 2 Mikrokulturen [mal] 2 vertikale Schichtungen – das macht 12 Korpora, die Horn-Helf auf über 100(!) sprachwissenschaftliche Analysekriterien abklopft und miteinander vergleicht. Nur ein geübter Sprachwissenschaftler kann nicht überrascht sein, ob der Menge an Dingen, die man an einem Anweisungstext betrachten und auszählen kann: Deklarationen, Sprachhandlungen, Interpunktion, Gliederungsmittel, Satzkomplexität, Typographie, Text-Bild-Relation, Parenthesen und und und.

Insgesamt umfasst die Publikation fast 1000 Seiten – aufgrund dieser Menge an Daten und Auswertungen wurden Kapitel 4-8 auf eine beiliegende CD ausgelagert. Von Interesse für die Übersetzungspraxis ist aber allein Kapitel zwei:

„Kulturspezifische Präferenzen und Translation“:

Horn-Helf nimmt sich jedes Analysekriterium vor, beschreibt ihre Ergebnisse und formuliert darauf aufbauend einen Ratschlag zur ‚translatorischen Behandlung‘.

So erfährt der Russisch-Deutsch-Übersetzer, dass er russische Imperative in imperativische Infinitive überführen sollte, da diese in deutschen Anweisungstexten üblich seien.

Bei der typographischen Gliederung von Aufzählungen bevorzugen Russen Minuskeln, Deutsche den Spiegelstrich, in englischen Texten hingegen „sollte sich die Markierung der Aufzählungsglieder grundsätzlich auf Ziffern beschränken.“

Für die Anpassung der Parenthesendichte einer deutschen Anleitung gilt für den Übersetzer die Faustregel: „Im Zuge der Translation ist die Parenthesendichte für den russischen [Zieltext] um ca. ein Drittel, für den englischen [Zieltext] auf die Hälfte zu reduzieren.“

Welche Zielgruppe hat dieses Buch?

Eine wohl überraschende erste Antwort auf diese Frage lautet: (Angehende) Kulturwissenschaftler. In ihrem ersten (weit über 300 Seiten umfassenden) Kapitel führt Horn-Helf ihren Leser äußerst detailliert und mithilfe breit gefächerter Meinungen und Zitate durch den aktuellen Forschungsstand zum Thema ‚Kultur‘: über den Kulturbegriff per se, über Universalia, hin zu kulturspezifischer Farbsemantik, Geschlechterrollen oder Freundschafts- und Höflichkeitsdefinitionen. Damit bietet Sie – beabsichtigt oder nicht – eine Art Einführung in die Vergleichende Kulturwissenschaft.

Die eigentlich angesprochenen Technischen Übersetzer müssen selbst entscheiden, ob ihnen die Beschäftigung mit Horn-Helfs Forschungsbeitrag ihre Arbeit erleichtert. Ein selektives Querlesen ist für diesen Berufsstand sicher interessant; wobei aber ein wichtiger Faktor (vor allem in Hinblick auf die Qualität der übersetzten Texte) nicht übersehen werden sollte: Horn-Helf bildet den Status quo von Anweisungstexten zum Zeitpunkt ihrer Korpuszusammenstellung ab – ohne Einbeziehung der jeweiligen makrokulturellen Verständlichkeitsforschung. So mag der imperativische Infinitiv in deutschen Anleitungstexten die Vormachtstellung haben; viele Verständlichkeitsforscher und Technische Sprachratgeber wären den Übersetzern aber sehr dankbar, wenn wenigstens sie von seiner Verwendung absehen würden.

Literatur: Horn-Helf, Brigitte: Konventionen technischer Kommunikation: Makro- und mikrokulturelle Kontraste in Anleitungen. FFF – Forum Fachsprachen Forschung, Bd. 91. Verlag Franck & Timme, Berlin, 612 Seiten mit CD. ISBN 978-3-86596-233-1

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

Connecting Content

doctima_contentconnectWar mein letzter Beitrag ein Plädoyer dafür, die wertvollen Inhalte aus der Technischen Redaktion an möglichst vielen Stellen wiederzuverwenden, möchte ich diesmal davon berichten, wie wir Sie bei der Erledigung dieser Aufgabe unterstützen können. In diesem Beitrag geht es darum, was unser neues Werkzeug ContentConnect leistet, welche Aufgaben es dazu bewältigt, und welche Vorteile Sie als Anwender daraus ziehen können.

Ziele: Was ContentConnect leistet

ContentConnect verbindet Content-Plattformen miteinander. Um das Grundprinzip des Werkzeugs zu verstehen, beschränke ich mich in diesem Beitrag auf den einfachen Fall mit einer Quelle (SCHEMA ST4) und einem Ziel (TYPO3). Mit der Fähigkeit, auch Inhalte aus mehreren Quellen zu kombinieren und die Ergebnisse in mehrere Zielsysteme zu verteilen, sind der redaktionellen Fantasie aber grundsätzlich alle Türen geöffnet.

Unseren ersten ContentConnect -Kunden ging es darum, Produktinformationen aus dem CMS der Technischen Reaktion nahtlos in die vom Marketing betreute Unternehmens-Website zu integrieren. Besucher der Website sollten Zugang zu den Produkten finden

  • über die Navigation durch die Hierarchie der Produktgruppen,
  • durch die indizierte Suche des Web-CMS und
  • einen „Product Finder“, also eine Facetten-Suche, wie man sie von großen Webshops her kennt.

Für den Anwender sollten sich die Produktinformationen nahtlos in die Web-Umgebung integrieren, sie sollten nicht bemerken, dass die Daten extern in das System eingespeist werden.

Inhalte: Was überträgt ContentConnect?

ContentConnect kopiert nicht einfach Daten. Er nutzt die im Content enthaltene Information, um einen wirklichen Mehrwert zu erreichen.

Strukturierte Informationen

Struktur einer Produktseite auf hilscher.com

Struktur einer Produktseite auf hilscher.com

Produktbeschreibungen sind strukturierte Information: Produktbezeichnung, Highlights, Technische Details, Bestellinformationen, Produktbilder, usw. werden als identifizierbare Bausteine übertragen. Diese lassen sich z. B. in Seiten-Templates eines Web-CMS einpassen. Systeme wie TYPO3 oder Contao unterstützen modulare Seiten-Layouts und bieten hierfür eine hervorragende Grundlage.

Mehrsprachigkeit

Ein zentraler Vorteil von Redaktionssystemen in der Technischen Redaktion ist das meist hervorragende Übersetzungs-Management. Gängige Web-CMS können gerade bei diesem qualitäts- und kostenkritischen Thema bei weitem nicht mithalten. ContentConnect überträgt alle Informationen in beliebig vielen Sprachen.

Metadaten

Produktinformationen im Redaktionssystem der Technischen Redaktion sind in der Regel mit Metadaten zu Filter- bzw. Ausgabezwecken angereichert. Sie geben zum Beispiel an, ob ein Produkt eine bestimmte Farbe hat, ein bestimmtes Betriebssystem unterstützt oder für einen speziellen Markt geeignet ist. Diese Metadaten lassen sich auch im Web verwenden, um z. B. mit einem Produktfinder einen zusätzlichen Zugang zu den Produkten zu schaffen, oder um den Navigationspfad durch Filter zu verschlanken. Wie wir das mit unserem Kunden Hilscher umgesetzt haben, können Sie unter den folgenden Links nachvollziehen:

Grafiken und Binärdateien

Produktbilder, Downloads, Infografiken: Grafiken und Binärdateien sind essenzieller Bestandteil des Contents und werden selbstverständlich mit bereitgestellt.

Querbeziehungen

Querbeziehungen zwischen Informationsbausteinen werden beim Transfer aufrechterhalten: Bei unserem Kunden waren das beispielsweise:

  • Hierarchien, z. B. die Einordnung in Produktgruppen,
  • Verweise auf zugehörige Produkte wie Zubehör oder Alternativen,
  • Links auf zugehörige Treiber-Downloads oder
  • eingebettete Bilder und Grafiken.

Generierte Inhalte

Nicht immer liegen alle Informationen, die im Zielsystem benötigt werden oder sinnvoll sind, in der Technischen Redaktion vor. Deshalb haben wir in ContentConnect vorgesehen, die zu übertragenden Inhalte regelbasiert anzureichern. Einige Beispiele:

  • Download-Links erhalten – abhängig vom Datentyp den Linkziels – PDF- oder DVD-Symbole.
  • Das Metadatum „unterstützte Technologien“ eines Produkts wird in eine Galerie von Logos dieser Technologien umgesetzt.
  • Telefonnummern in Kontaktadressen werden automatisch mit Telefon-Links versehen, die vom Smartphone aus bzw. über Skype o. ä. direkt angewählt werden können.

Aufgaben des Werkzeugs

Um die oben beschriebenen Inhalte abbilden zu können, erledigt der Content Connect die folgenden Aufgaben:

  • Benutzerauthentifizierung in Quell- und Zielsystemen,
  • Integration des ContentConnect in Quell- und Zielsysteme,
  • Objekte in Quell- und Zielsystem identifizieren und aufeinander abbilden,
  • Umsetzung von Quell- in Ziel-Datenmodell,
  • Konvertierung und Anreichern der Inhalte in Ziel-Markup,
  • Differenz-Upload für Grafiken und Ressourcen.

Alle Abläufe werden dabei vollständig über eine individuelle Konfiguration gesteuert. So können wir auf Kundenwünsche flexibel eingehen.

Vorteile aus Anwendersicht

Der Leiter der Technischen Redaktion bei unserem Kunden Hilscher hat die Vorteile des Systems aus seiner Sicht zusammengestellt und mit mir in einem Vortrag auf der tekom-Tagung 2015 präsentiert.

  • Für den Kunden erleichtert sich der Zugang zu den Produkten des Unternehmens. Filter und Produktfinder ergänzen die Navigation. Die umfassende, konsistente Information liegt in allen relevanten Sprachen vor.
  • Für den Vertrieb sinkt der Kommunikationsaufwand, während die Vertriebsqualität steigt. Ein gemeinsamer Blick auf die Website ermöglicht ein viel direkteres Eingehen auf den Kunden.
  • Das Marketing erhält eine Website mit umfassenden, mehrsprachigen Produktbeschreibungen, optimal für SEO-Zwecke, bei gleichzeitiger Arbeitsersparnis.
  • Das Produktmanagement kann leichter individuelle Highlight-Informationen bereitstellen.
  • Für den Controller verbessert sich das Übersetzungs-Controlling. Unnötige Aufwände durch Mehrfacherfassung von Technischen Daten, Produktbeschreibungen etc. entfallen, dagegen steigen Publikationsgeschwindigkeit und -konsistenz.

Weitere Informationen finde sich in unserem Foliensatz zur tekom Jahrestagung 2015 (H. Hentsch, E. Hellfritsch „Technische Redaktion als Marketing-Turbo“).

Zusammenfassung

Der generische Ansatz, den wir mit ContentConnect verfolgen, stellt die Informationsfülle der Technischen Redaktion unternehmensweit zur Verfügung. Nahtlos eingebunden in die native Datenhaltung des Zielsystems kann der vorhandene Content an vielen unterschiedlichen Stellen zusätzlichen wertvollen Nutzwert generieren.

Standardsammlung ohne Standardkost

Fünf Standards, viel Wissen, kein Vergleich

Wer technischer Redakteur, Verantwortlicher für die Einführung eines CMS, Quereinsteiger oder überhaupt an standardisierter und strukturierter Information interessiert ist, der soll mit „Standardisierungsmethoden für die technische Dokumentation“ gut bedient werden. Das Werk ist eine Hilfestellung für alle, die auf der Suche nach einer Methode zur Standardisierung ihrer Dokumentation sind. Werk sage ich bewusst, denn es handelt sich nicht um ein Buch, sondern um eine Sammlung von Aufsätzen, die von Experten oder Entwicklern der jeweiligen Standards verfasst wurden.

Amüsanter Anfang und lockeres Lernen

Geschichte mal anders: Mitreißender Informationsstrom statt öder Textwüste

Die ersten Zeilen lassen mich allerdings schmunzeln. Statt des erwarteten ernsthaften Textes überrascht ein unterhaltsamer Einstieg von Jürgen Muthig zur Vorstellung von Firmenstandards als Eigenentwicklung. Er ist gespickt mit humorvoller und anschaulicher Bildsprache, ohne lächerlich zu wirken oder mich als Einsteiger in meiner Wahl zu beeinflussen. Manfred Krüger und Wolfgang Ziegler schaffen es, den unterhaltsamen Stil der ersten Seiten weiterzuführen. Statt trockener Textwüsten über die Geschichte der Standards folgt ein ansprechender und kurzweiliger Fluss von Informationen. Nebenbei erhalte ich so solides Hintergrundwissen, das mir bei der Einschätzung der danach folgenden Expertenaufsätze hilft. Durch die Ansprache mit „wir“ ist der Text kein endloser Monolog und ich kann der zeitlichen Entwicklung von SGML und CALS über HTML und DocBook zu S1000D, DITA und weiteren modernen Standards gut folgen. Der Geschichtsteil hat auch einige Überraschungen parat: Zum Beispiel plaudert Ziegler ganz nebenbei aus dem Nähkästchen über den von ihm entwickelten Firmenstandard DOCU für Liebherr.

Eine bunte Mischung aus Expertenwissen

Sammelband: Vom Lehrbuch bis zur Werbebroschüre alles vertreten

Sammelband: Vom Lehrbuch bis zur Werbebroschüre alles vertreten

An manchen Stellen stößt das Konzept eines Sammelbandes leider an seine Grenzen. Die Autoren (Muthig/Schäflein-Armbruster, Closs, Lehrndorfer/Reuter, Juhl, Böhler) kommen auf sehr unterschiedlichen Wegen zur technischen Redaktion und unterscheiden sich in ihrem Schreibstil. Das schlägt sich auch in der Sammlung nieder. Die einen schreiben pistolenartige Kurzsätze, die anderen stapeln Schachtelsätze. Manche Aufsätze lesen sich wie eine Werbebroschüre, andere dagegen wie ein Lehrbuch. Ein wirklich objektiver Vergleich kann konzeptbedingt nicht stattfinden – kein Experte wird den Standard schlechtreden, für den er sich entschieden hat, und kein Entwickler das verreißen, was er selbst mühsam aufgebaut und verbreitet hat. Vergleichen muss der Leser deshalb selbst.

Entscheiden muss ich selbst

Wegfindung: Viele Standards führen zum Ziel

Wegfindung: Viele Standards führen zum Ziel

Die Entscheidung, welcher Standard für mich geeignet ist, wird mir nicht abgenommen. Aber sie wird mir erleichtert: So unterschiedlich die Stile der Autoren auch sein mögen, so wenig auch verglichen wird – jeder Aufsatz erklärt genau, wie der vorgestellte Standard funktioniert, für welche Einsatzzwecke er geeignet ist und erklärt die Hintergründe und Anwendung des Standards. Jeder Experte, der zu Wort kommt, macht deutlich, dass er ein Experte ist und vermittelt das Wissenswerte zu „seinem“ Standard. Die meisten von ihnen liefern auch eine Zusammenfassung für Eilige mit. Erfreulich ist, dass der Sammelband trotz des mehrfachen Aufgreifens derselben Themen in der Einführung und im dazu passenden Aufsatz nicht repetitiv ist – oder es zumindest schafft, nicht so zu wirken. Wer mehr wissen möchte, der wird im Werk ebenfalls fündig: Literaturangaben zu den jeweiligen Aufsätzen bieten eine Anlaufstelle zum Weiterlesen und das Autorenverzeichnis erleichtert die Kontaktaufnahme.

Gescheiterte Standards gibt es nicht

Das Schlusswort des Intros beschreibt in etwa den Eindruck, den die Sammlung von Expertenschriften bei mir hinterlassen hat. Das größte Problem eines Standards ist die Marktdurchdringung. Alle Standards haben ihre Berechtigung, einen gescheiterten Standard gibt es nicht. Was zu meinen Anwendungszwecken passt, wird übernommen. Und was nicht ganz passt, wird passend gemacht oder nur teilweise übernommen (dafür haben Krüger und Ziegler das schöne Wort „Steinbruchnutzung“ gefunden).

Sinn und Zweck der Aufsatzsammlung ist es, einen Überblick über einige der etablierten Standards in der Technischen Dokumentation zu bekommen. Ein Vergleich findet nicht statt. Das hat den Vorteil, dass ich unvoreingenommen an meine Auswahl gehen kann. Das hat aber gleichzeitig auch den Nachteil, dass mir etwaige Schwierigkeiten erst nach meiner Entscheidung auffallen können. Denn die Experten erwähnen Probleme oder Schwächen bei der Einbindung „ihrer“ Standards in Technische Dokumentation nicht. Dazu sollte man andere Werke zu Rate ziehen, die auch explizit die Schwächen mit in den Vergleich einbeziehen. Trotzdem servieren die Autoren eine Menge mundgerecht aufbereitetes Wissen, das bei der Beurteilung hilfreich ist. Nebenbei erfährt man – gerade als Einsteiger wie ich – bei der Lektüre Dinge, die einen vorher vielleicht interessiert haben, für einen technischen Redakteur aber nicht unwichtig sind. Zum Beispiel hat OpenOffice bereits vor Word eines der heute meistgenutzten Datenaustauschformate genutzt: XML. Das war für mich neu. Für Sie auch?

Literatur: Jürgen Muthig (Hrsg.): Standardisierungsmethoden für die Technische Dokumentation (2008). Verlag Schmidt-Römhildt, Lübeck, 167 Seiten. ISBN 978-3-7950-7066-3

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als elektronisches Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

Wie wenig ist genug? – Rechtskonforme Dokumentation im Maschinen- und Anlagenbau

Querbeet durch die Technische Dokumentation im Maschinen- und Anlagenbau.

Querbeet durch die Technische Dokumentation im Maschinen- und Anlagenbau.

Hersteller müssen ihre Produkte rechtskonform machen. Neben dem Produkt selbst gehört dazu auch die Dokumentation. Dafür möchten sie so wenig Aufwand wie möglich betreiben. Doch wie wenig darf es werden und wie viel muss sein? Was braucht meine Dokumentation, um rechtlich auf sicheren Füßen zu stehen? Und wie kann meine Redaktion effizient und trotzdem sicher und konsistent schreiben? Antworten darauf will das Buch auf meinem Tisch geben: „Technische Dokumentation im Maschinen- und Anlagenbau“ von Heinz Schlagowski.

Für wen soll das Buch sein?

Das Buch will mich ansprechen und „alle, die mit technischer Dokumentation zu tun haben“. Das ist sehr breit gefächert und macht es dem Autor nicht einfacher – haben wir als technische Redakteure doch ganz anderes Fachwissen als der Laie, der sein Produkt auf den Markt bringen möchte und für das Drumherum wenig übrig hat. Das Buch will erklären, warum das Drumherum für rechtssichere Produkte weit mehr ist als nur eine lästige Pflicht.

Was liefert das Buch?

Gleich so viel: Nach dem Lesen werde ich mit einer Fülle an Informationen belohnt, die nicht nur den Technischen Redakteur, sondern auch den Hersteller eines Produktes ansprechen soll. Allerdings bläht diese Informationsfülle das Buch auch auf 700 Seiten auf, die gelesen werden wollen und größtenteils aus Text bestehen.

Europäische Gemeinschaft: Gesetze und Grundlagen für Produkte
Warum interessieren sich Entscheider zunehmend für das Thema technische Dokumentation – oder wären gut beraten das zu tun? Ich als angehender Technischer Redakteur weiß natürlich warum technische Dokumentation wichtig ist (schließlich habe ich diesen Weg nicht zufällig eingeschlagen) und erfahre in diesem Teil nichts Weltbewegendes. Aber wer neu oder quer einsteigt weiß nach diesem Teil des Buches ebenfalls warum diese Arbeit wichtig und sinnvoll ist.

Der Entscheider im Unternehmen weiß das vielleicht noch nicht und versteht durch die Vermittlung der rechtlichen Grundlagen und Vorschriften, warum konsistente und gute technische Dokumentation ein Thema ist, das Aufmerksamkeit verdient hat.

Normen und Richtlinien als „Stand der Technik“
Wenn ein Hersteller eine Maschine produziert oder ich die Dokumentation dazu schreibe, dann muss das nach dem „Stand der Technik“ erfolgen. Was das genau heißt, können der Hersteller und ich im Bereich der Normen und Richtlinien nachlesen. Das Buch klärt uns auf was getan werden muss, um Maschine und Dokumentation auf den Stand der Technik zu bringen. Dass der Autor das Thema sehr ernst nimmt erklärt auch, warum das Thema das halbe Buch in Anspruch nimmt.

Während der Hersteller von den VDI-Richtlinien angesprochen wird, sind für mich die tekom-Leitfäden ein nützliches Handwerkszeug für den Alltag in der Redaktion. Auszugsweise Abschnitte und Erklärungen unter anderem aus der Maschinenrichtlinie und einigen DIN-Normen wie dem Klassiker 82079 helfen mir zu verstehen, was die manchmal sehr schwammigen Normen aus unserem Schrank eigentlich aussagen wollen. Der Entscheider versteht, welche Dokumente ich für meine Dokumentation brauche und kann die Kommunikation mit anderen Abteilungen fördern.

Sicher ist sicher
Sicherheit ist wichtig für denjenigen, der meine Dokumentation zu lesen bekommt. Damit sicher auch wirklich sicher und rechtskonform ist, präsentiert mir Herr Schlagowski die Informationen, die die Normen und Richtlinien enthalten, nochmals in einem separaten Kapitel. Dazu bekomme ich genaue Instruktionen zur Gestaltung – praktisch, da ich sofort anfangen kann, die Theorie in die Praxis umzusetzen.

Der rote Faden für die Dokumentation
Um individuelle Redaktionsleitfäden erstellen zu können, liefert das Buch einige Hinweise zur Entwicklung von Redaktionsleitfäden und betont, warum diese sinnvoll sind.

Wenn ich in die Situation kommen sollte einen Leitfaden für eine Redaktion schreiben zu müssen, dann kann ich auf das Kapitel „Redaktionshandbuch“ zurückgreifen. Hier wird mir genau erklärt, warum ein Redaktionsleitfaden nützlich ist und wie man zu einem guten Redaktionsleitfaden kommt. Das Kapitel enthält aber keine Mustervorlage oder Beispiele für einen Redaktionsleitfaden. Die Schreib- und Recherchearbeit nimmt einem der Autor also nicht ab.

722015_original_R_K_B_by_Tim Reckmann_pixelio.de

Damit der Leitfaden nicht zum Kuddelmuddel wird: Kapitel Redaktionsleitfäden
(Bild: Tim Reckmann / pixelio.de)

Für einen potenziellen Auftraggeber ist dieser Teil uninteressant, denn ihn interessiert weniger, wie ich arbeite, sondern was dabei herauskommt.

Hilfe zur Selbsthilfe
Wie ein Redaktionsleitfaden aussehen kann, wird mir im nächsten Kapitel klarer, das mit Beispielen aus einem Redaktionsleitfaden gewürzt ist, die zusätzlich noch mit Erklärungen versehen sind. Als Inspirationsquelle ist dieses Kapitel sehr gut geeignet und für Neueinsteiger sind die fertigen Bausteine sehr praktisch.

Das Kapitel liefert aber noch mehr. Der Betreiber der dokumentierten und ausgelieferten Maschine hat auch einige eigene Dokumentationspflichten. Um diesen nachzukommen benötigt er weitere Informationen. Der informierte Hersteller weiß nach diesem Kapitel, welche Informationen das sind und kann diese gleich mitliefern.

Mehrere Maschinen sind eine Anlage
Das Schlusskapitel erklärt, wie aus der Maschine eine Anlage wird und welche Regeln dann für den Hersteller und meine Dokumentation gelten. Anhand des Kapitels können Entscheider festlegen, ob es sich um eine Anlage handelt und welche Einzeldokumente wie vorliegen müssen, um eine funktionale Gesamtdokumentation zu erzeugen.

Für wen ist das Buch tatsächlich geeignet?

Dem Anspruch „allen, die mit technischer Dokumentation zu tun haben“ wird das Buch gerecht, es waren nicht nicht nur für mich interessante Abschnitte im Buch.

Besonders die konkreten Hilfen zur Erstellung eines Redaktionsleitfadens und die Gestaltungsvorschläge für Sicherheitshinweise haben mir gefallen.

Die Entscheider im Unternehmen wissen nach dem Lesen des Buches, warum sie unseren Beruf wertschätzen sollten und wie sie ihren Käufer auch nach dem Kauf bei seinen Dokumentationspflichten unterstützen können.

Rundumschlag mit großem Umfang

Allerdings erfordert das Buch dazu auch 700 Seiten und hat mich daher im ersten Moment eher abgeschreckt. Es kann als Universalbuch auch nicht in dieselbe Detailtiefe wie Fachliteratur gehen. Als Universalbuch ist „Technische Dokumentation im Anlagen- und Maschinenbau“ von Heinz Schlagowski geeignet, als Nachschlagewerk für Detailfragen weniger, da mich nicht jedes Kapitel angesprochen hat und ich reichlich oft mit Umblättern beschäftigt war. Hier bevorzuge ich spezielle Literatur, die genau auf die Technische Redaktion zugeschnitten ist.

Literatur: Heinz Schlagowski (Autor): Technische Dokumentation im Maschinen- und Anlagenbau (2., überarbeitete Auflage 2015). Beuth Verlag GmbH, Berlin/Wien/Zürich, 749 Seiten. ISBN 978-3-410-25157-6

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

DITA und Deutschland – eine Antwort an die Redakteuse

Warum weht in Deutschland bei DITA ein anderer Wind? (c) lichtkunst.73 / pixelio.de

Warum weht in Deutschland bei DITA ein anderer Wind?
(c) lichtkunst.73 / pixelio.de

Im Nachgang zur #tekom15 hat Marijana Prusina hier die Diskussion auf der Tagung und ihre Gedanken zu DITA zusammengefasst. Unser Kommentar dazu.

Deutschland zu zögerlich? Ich denke eher nicht. Ich sehe den wichtigen Punkt eben doch darin, dass in Deutschland schon lange sehr leistungsfähige CCMS auf dem Markt sind.

Denn das heißt zunächst einmal: Alle early adopter haben sich frühzeitig damit beholfen.

Zweite Konsequenz: Die Unternehmen, die bisher bei unstrukturierten Workflows geblieben sind und bei denen DITA eine Lösung wäre, treffen auf einen Markt, auf denen DITA eine Lösung unter mehreren mächtigen Standards ist. Denn nur weil DITA eine Lösung wäre, heißt das ja nicht, dass ein CMS keine sein kann.

Drittens: Es gibt außerdem auch etliche Fälle, bei denen Unternehmen von DITA wegmigrieren. Auch das hält den Markt für DITA in Deutschland schlanker.

Und Viertens: Vielen Redakteure in Deutschland mit denen ich gesprochen habe, geht DITA schlicht und einfach auf die Nerven. In jedem zweiten internationalen Vortrag zu DITA wird zumindest angedeutet, dass die Redakteure in Deutschland sagen wir mal zu dumm sind zu verstehen, was DITA leistet. Zunächst ist das ja ohnehin schon keine besonders clevere Verkaufsstrategie. Und wenn ich die Argumente pro DITA dann schon in identischer Form seit mehreren Jahren von den CMS-Herstellern kenne, dann wirkt der DITA-Promoter auf mich nicht sonderlich kompetent.

DITA ist (genau wie CMS) immer nur so gut, wie die Leute damit arbeiten. Wir bei doctima haben in unseren Migrationsprojekten aus DITA schon die erstaunlichsten Fälle von Missbrauch erlebt. Leider versäumen viele Kunden von DITA (ebenso wie von CMS) ihre Redakteure auch redaktionell für strukturierte Schreibprozesse zu qualifizieren. Und dann hilft das beste System nichts…

Feedback, bitte! – Warum Technische Redaktion keine Einbahnstraße sein sollte

Martin Häberle arbeitet als Technischer Redakteur für ein mittelständisches Software-Unternehmen und ist Lehrbeauftragter an der Hochschule Gießen im Studiengang „Technische Redaktion und Multimediale Dokumentation“ für Wiki-basierte Dokumentation. Zu diesem Thema ist er auch als Berater, Trainer und Autor u.a. für die K15t Software GmbH tätig.

(c) K15t Software

(c) K15t Software

Lange Zeit war Technische Redaktion eine Einbahnstraße. Wir schickten Informationen in die eine Richtung, und aus der anderen kam nichts zurück. Doch in Zeiten des Web 2.0 ist das zu wenig. Technische Redakteure müssen heute kommunizieren und interagieren können – auch mit ihren Lesern. Feedback hilft ihnen dabei, Technische Inhalte nutzergerecht zu erstellen und kontinuierlich zu verbessern. Anstelle der Einbahnstraße ist Technik-Kommunikation heute ein iterativer Prozess, funktioniert also eher wie ein Kreisverkehr.  Für diese neuen Redaktionsprozesse benötigen wir neue Werkzeuge – weg von Redaktionssystemen oder DTP-Werkzeugen, hin zu kollaborativen Plattformen.

Lesen Sie in diesem Artikel, warum Feedback so wichtig ist, um hilfreiche Inhalte zu erstellen und wie Web-basierte Kollaborationswerkzeuge sowohl internes Feedback als auch Kundenrückmeldungen für Technische Dokumentation ermöglichen.

Gutes Feedback ist mehr als Lob

Feedback hat hier im Südwesten Deutschlands wenig Tradition. Denn in meinem Heimatland Baden-Württemberg heißt es „Net g’schimpft isch genug g’lobt“ und das bedeutet in der Praxis, dass man sehr wenig Feedback bekommt – sei es nun Lob oder Kritik. Dabei ist Rückmeldung wichtig, um besser zu werden! Gerade als Technischer Redakteure sind wir auf Feedback angewiesen. Nur so können wir hilfreiche Inhalte erstellen, die unsere Leser erwarten und den Nutzern Informationen bereitstellen, die sie wirklich benötigen.

Üblicherweise erhalten Technische Redakteure aber nur selten (nützliches) Feedback zu ihren Inhalten. Vielleicht kommen während der ohnehin viel zu kurzen Review-Phase ein paar handschriftliche Korrekturen von den Fachexperten hereingeflattert, und manchmal werden uns die Kollegen sogar mit ein paar erhellenden Erkenntnissen beglücken. Doch fast nie erhalten wir in der Technikkommunikation eine Rückmeldung von denjenigen, mit denen wir wirklich kommunizieren möchten: von den Leserinnen und Lesern.

Doch warum kommuniziert die Leserschaft nicht mit uns? Ein Grund für ausbleibendes Feedback ist, dass eine Beteiligung der Leserschaft in traditionellen Redaktionsprozessen entweder nicht vorgesehen ist oder nicht einfach und zuverlässig möglich ist. Erst die Web-2.0-Bewegung brachte entsprechende Web-basierte kollaborative Werkzeuge (z.B. Wikis) hervor – digitale Plattformen, auf denen Inhalte nicht nur konsumiert, sondern auch selbst erstellt werden können.

Moderne Web-basierte Plattformen gehen neue Wege, um Inhalte kollaborativ zu erstellen, zu überarbeiten und zu veröffentlichen. Dokumentation bereitzustellen ist damit nicht mehr länger ein Monolog gegenüber den Lesern, sondern wird zum Dialog. Der Technikredakteur wird endlich zum Technik-Kommunikator!

Der Content-Lebenszyklus „2.0“

In typischen Dokumentationserstellungs-Prozessen planen Technische Redakteure zunächst ihre Informationsprodukte, erstellen eine Struktur und recherchieren, bevor sie mit dem Erstellen der einzelnen Inhaltsbausteine loslegen. Die Entwürfe werden so lange angepasst und Überarbeitungen werden abgestimmt und zusammengeführt, bis jemand eine Freigabe erteilt und die Inhalte ins gewünschte Zielformat ausgegeben werden. Und schließlich gelangt die Dokumentation zu ihren Lesern.

(c) K15t Software

(c) K15t Software

Wenn wir einen kollaborativen Ansatz verfolgen, können wir noch eine fünfte Phase zu diesem Prozess hinzufügen: das aktive Einbeziehen unserer Leser („Engage“). Indem wir es ihnen ermöglichen etwas Inhaltliches beizutragen, schließt sich die Feedback-Schleife und wir beginnen miteinander zu kommunizieren. Auf Basis der Anregungen, Fragen und Wünschen ihrer Leser können Technische Redakteure ihre Dokumentation so kontinuierlich verbessern, wie dies beispielsweise in der agilen Software-Entwicklung praktiziert wird.

Im Wiki lässt sich jede Änderung nachverfolgen – der gesamte Prozess von der Erstellung bis zum Review wird transparent für alle Beteiligten. Und wenn wir Feedback sowohl beim internen Review als auch während der Nutzung der bereitgestellten Inhalte erhalten, dann wirkt sich das positiv auf die Qualität der Inhalte aus (entgegen einiger unhaltbarer Wiki-Mythen).

Feedback zu Inhalten im Entwurfsstadium

Während des internen Lektorats prüfen die eingeladenen Fachexperten unsere Inhalte. Sie kommentieren hier und dort, schließen ein paar Wissenslücken und klären inhaltliche Fehler und Missverständnisse mit den Technischen Redakteuren. Außerdem gibt es möglicherweise einen Schlussredakteur, der den Entwurf auch auf Sprache, Stil und Struktur prüft und dadurch eine gewisse Konsistenz und formale Richtigkeit sicherstellt. Schließlich wird der Entwurf freigegeben und publiziert.

In einer kollaborativen Plattform sind alle, die am Redaktionsprozess beteiligt sind, sprichwörtlich auf der gleichen (Wiki-)Seite. Soziale Funktionen wie Kommentare, ein „Gefällt mir“-Button oder die Möglichkeit, Inhalte einfach zu teilen, helfen den Nutzern, miteinander effizient zu kommunizieren und mit den Inhalten zu interagieren – sogar wenn die Beteiligten über verschiedene Standorte oder sogar Zeitzonen hinweg verteilt arbeiten.

Abhängig von der gewünschten Arbeitsweise ist die letzte Inhaltsversion entweder sofort online für die Nutzer verfügbar, oder es wird ein Freigabeschritt zwischengeschaltet.

Mit der Kollaborationsplattform Atlassian Confluence lassen sich beispielsweise Inhaltsfragmente aller Arten und Größen kommentieren, Überarbeitungen anregen und schließlich als gelöst markieren – und das mit wenigen Klicks und ohne das Browserfenster zu wechseln. Nutzer können Inhalte bei Bedarf hinzufügen, bearbeiten oder löschen. Dabei bleibt jede Änderung transparent und kann bei Bedarf auf eine vorherige Fassung der Seitenhistorie zurückgesetzt werden.

(c) K15t Software

(c) K15t Software

Über Erweiterungen, sogenannte Add-ons, können in diesem Unternehmens-Wiki Entwurfsversionen und freigegebene Versionen für Inhalte definiert werden. So ermöglicht beispielsweise die Erweiterung Comala Workflows, den Seiten einen Status zuzuweisen. Oder mit Hilfe des Add-ons Scroll Versions lassen sich freigegebene Inhalte bei Bedarf sogar in einen separaten Wiki-Bereich publizieren, der auf Wunsch öffentlich zugänglich ist. Darüber hinaus verwaltet dieses Add-on auf Wunsch auch mehrere Versionen und Varianten der Dokumentationsinhalte in einem zentralen Autorenbereich.

Diese Vorgehensweise ist an die Versionsverwaltung von Quellcode in der Software-Entwicklung angelehnt, wo in Entwicklungszweigen und Releases gedacht wird. Zunehmend verfolgen aber auch Technische Redakteure anderer Branchen diesen Ansatz, um Dokumentation agil erstellen und bereitstellen zu können.

Wege, wie wir von unseren Lesern lernen können

Die zweite (und spannendere) Art des Feedbacks kommt von den Leserinnen und Lesern, also all denen, welche die bereitgestellte Dokumentation auch tatsächlich nutzen um etwas zu lernen und um ein bestimmtes Problem zu lösen. Um deren Rückmeldungen effizient einzuholen, führt praktisch kein Weg an einer Web-basierten Plattform vorbei. Als Technische Redakteure können wir hier Bewertungs- und Kommentarfunktionen sowie Web-Analysewerkzeuge zu unseren Gunsten einsetzen.

Bewertungsfunktion für hilfreiche Inhalte
Am Naheliegendsten ist wohl die Verwendung einer Bewertungsmöglichkeit für die Nutzer der Dokumentationsinhalte. Technische Redakteure können über die Summe der Bewertungen eine Aussage über die Nützlichkeit der dargebotenen Inhalte erhalten – etwa auf einer Skala von 1–5 Sternen. In Confluence gibt es hierzu das Rate Macro, welches diese Funktion bietet.

Kommentare und Diskussionen
Manche Leser würden ausführlicheres Feedback in Form von Kommentaren hinterlassen – wenn wir es ihnen erlauben. Fehlt etwas, ist eine Information veraltet oder irreführend? Unsere Nutzer möchten vielleicht weiterführende Fragen stellen oder haben sogar selbst Antworten und Problemlösungen gefunden, die sie mit anderen Nutzern teilen wollen. Dies bereichert in vielen Fällen die von uns Technischen Redakteuren bereitgestellten Dokumentationsinhalte erheblich.

Die PHP-Dokumentation gewinnt beispielsweise erheblichen Nutzwert durch sogenannte „User-contributed notes“, also von Nutzern beigesteuerte Anmerkungen.

(c) K15t Software

(c) K15t Software

Andererseits können Nutzerbeiträge in großer Zahl auch eine echte Herausforderung für Technische Redakteure darstellen. Beim Software-Hersteller Atlassian, der seine Produktdokumentation im öffentlichen Confluence-Wiki bereitstellt, zeigte sich kürzlich, dass sich nur rund 20 % der Kommentare auf den Hilfeseiten direkt auf die Inhalte bezogen – der größte Anteil beinhaltete Support-Anfragen, Funktionswünsche etc. Dies führte dazu, dass das kollaborationsbegeisterte australische Unternehmen sich dazu entschied, dort die Kommentarfunktion vorerst zu deaktivieren.

Der zugehörige Blogpost, in dem Atlassian diese Entscheidung ankündigte, zeigt uns aber auch, wie gut Nutzerkommentare funktionieren und welchen Mehrwert sie bieten können. Mehr als 60 Personen kommentierten den Beitrag und diskutierten ihre Bedenken und Ideen mit den Atlassian-Verantwortlichen, die nicht nur in den Kommentarspalten den Dialog suchten.
In manchen Fällen mögen Kommentare also zu viel des Guten sein, aber sie sind definitiv etwas Gutes!

Detaillierte Webseiten-Zugriffsanalysen
Der dritte Weg, um an Feedback zu kommen führt über die Erhebung von Nutzerdaten. Mittels Web-Analysewerkzeugen wie Google Analytics können wir Technischen Redakteure beispielsweise schnell herausfinden, wie viele Nutzer unsere Web-basierte Dokumentation nach bestimmten Stichwörtern durchsuchen und wie lange Besucher auf den einzelnen Seiten verweilen. Web-Analysewerkzeuge sind wohl der leiseste Weg, um mehr über das Verhalten unserer „Kunden“ zu lernen.

Fazit

Erfolgreiche Technische Kommunikation ist mehr als Technische Redaktion. Dabei kommt es in hohem Maß auf das Nutzerfeedback an, damit wir passgenaue Inhalte für unsere Leserschaft erstellen können und um deren Informationsbedarf gemäß ihrer Erwartungen zu decken. Der beste Weg dorthin führt über kollaborative Methoden, die wir sowohl im internen Review-Prozess als auch zum Einholen von Kundenfeedback anwenden.

Viele Organisationen haben ein Enterprise-Wikis als optimale Plattform identifiziert, die beide Aspekte in einem Web-basierten Kollaborationswerkzeug vereint. Wenn wir Nutzer beim Erstellen und Optimieren von Inhalten beteiligen, so erhalten wir viel mehr ist als die Summe der einzelnen Bestandteile. Das gilt nicht nur fürs Web 2.0 allgemein, sondern auch für Technische Dokumentation.

Und wenn wir Technischen Redakteure aufmerksam in unseren Feedback-Kanal hineinhören, dann können wir möglicherweise sogar das eine oder andere Lob darin finden … 😉

Dieser Beitrag ist der erste Teil einer Artikelreihe im englischsprachigen Blog von K15t Software. Im nächsten Teil werden dort Lösungen vorgestellt, wie sich kollaborative Hilfeplattformen im Web bereitstellen lassen, damit wir als Technische Redakteure unsere Dokumentation auf die nächste Stufe bringen können.

Ergänzung doctima: Die deutsche Seite von Atlassian Confluence findet sich unter  https://de.atlassian.com/software/confluence.

Wort oder Fachwort?

Bauteile "immer" oder "nur" auf ebenen Unterlagen befestigen?

Bauteile „immer“ oder „nur“ auf ebenen Unterlagen befestigen?
(c) Petra Dirscherl / pixelio.de

Wenn ich nicht gerade meinem Job bei doctima nachgehe oder hier blogge, betreue ich bei der tekom ein Expertenforum zu Sprachthemen rund um die Technische Dokumentation. Dort kam letzte Woche eine interessante Frage auf, die ich hier noch einmal ausführlicher beleuchten möchte. Denn sie zeigt ein paar Dinge darüber, wie Wörter „funktionieren“ und wo es sich lohnt, Dinge zu standardisieren (oder nicht).

„Immer“ oder „nur“?

Worum ging es nun konkret. Ein Nutzer des Forums hatte darum gebeten, die Bedeutung von „immer“ und „nur“ möglichst eindeutig – „quasi mathematisch“ – zu definieren. Das klingt zunächst einmal einfach. Wo das Problem liegt, merkt man an den beiden Beispielsätzen, die er zur Erklärung mitgebracht hatte:

  1. „Das Bauteil immer auf ebenen Unterlagen befestigen.“
  2. „Das Bauteil nur auf ebenen Unterlagen befestigen.“

Hier braucht man eine eindeutige Lösung. Sonst führen die unterschiedlichen Formulierungsvarianten zu Verwirrung bei den Lesern.

Bedeutung und Deutung

Die beiden Beispiele machen klar: Auf den ersten Blick sind „immer“ und „nur“ recht verschieden. Sie haben aber einen gemeinsamen Bedeutungskern. Ich will diesen Bedeutungskern einmal abstrakt als „Ausschließlichkeit“ bezeichnen. Bei „nur“ ist diese Bedeutung offensichtlich, bei „immer“ ein wenig vermittelter. Hier ist die zeitliche Bedeutungskomponente im Vordergrund; der Aspekt „Ausschließlichkeit“ ergibt sich dadurch, dass das Wort „zu jeder Zeit“ bedeutet, also keine Ausnahme zulässt.

Fazit: „immer“ und „nur“ sind in diesem Kontext Synonyme, die lediglich eine ganz leichte Bedeutungsschattierung transportieren. Wenn ich mich festlegen müsste, würde ich sagen „immer“ fokussiert eher auf den Prozess, „nur“ eher auf das Produkt bzw. den Einzelfall. Reicht das als Erklärung? Ist das die Lösung für dieses Standardisierungsproblem?

Spannend?

Die Antwort dazu gebe ich weiter unten. Zuvor möchte ich ein wenig in die Theorie abschweifen. Denn spannend an dem „immer“/“nur“-Problem finde ich nicht nur die Bedeutungsdiskussion. Fast noch interessanter ist das – Achtung Theorie! – semantische Modell, das hinter dieser Frage bzw. Sicht auf die Wortbedeutung ergibt. Kann es sein, dass Wörter ihre Bedeutung je nach Kontext verändern? Kann es sein, dass bestimmte Aspekte der Wortbedeutung je nach Kontext ein- und ausgeblendet werden. Und was ist dann eigentlich die Bedeutung eines Wortes?

Viele von uns gehen intuitiv davon aus, dass jedes Wort eine klar umrissene Bedeutung besitzt, die sich zumindest prinzipiell in einzelne Bedeutungsbestandteile zerlegen lässt. „Mutter“ ist „direkter Vorfahr“ und „weiblich“ (mal abgesehen von „Schraubenmutter“ und ähnlichen Homonymen). So ähnlich mache ich das oben auch, wenn ich als Bedeutungselement der beiden Begriffe „Ausschließlichkeit“ isoliere. Diese Sicht auf die Wortbedeutung nennt man Merkmalssemantik.

Tatsächlich sind Wörter in ihrer Bedeutung aber gar nicht so fix, wie wir das glauben. Vielmehr besitzen sie einen Bedeutungskern, der nach außen hin aufweicht und nur fallweise aktualisiert wird. Das ganze nennt sich Prototypensemantik und ist mittlerweile durch psycholinguistische Experimente gut belegt. Allen, die sich gerne genauer damit beschäftigen möchten, empfehle ich die Magisterarbeit „Merkmalssemantik vs. Prototypensemantik. Anspruch und Leistung zweier Grundkonzepte der lexikalischen Semantik“ von Philipp Overbeck. Viele empfinden diese sprachliche Uneindeutigkeit, wie sie die Prototypensemantik beobachtet und erklärt, übrigens als unbefriedigend. Tatsächlich ist sie aber die Voraussetzung dafür, dass wir Sprache flexibel und kreativ verwenden und auf neue Sachverhalte und Ideen flexibel reagieren können.

Ein Fall für die Terminologie?

Dass die Prototypensemantik mit ihren Theorien wohl nicht ganz daneben liegt, zeigt ausgerechnet die Terminologiearbeit im Unternehmen. Denn durch die Definition von Termini bzw. Fachwörtern (Terminus ist das Fachwort für „Fachwort“) verleihen wir Wörtern eben den fixen Bedeutungskern, den sie als alltagssprachliches Wort nicht haben. Wir müssen also Aufwand betreiben, um Wörter passend für die Merkmalssemantik zu machen.

Ist es nun sinnvoll, die Bedeutung von „immer“ und „nur“ terminologisch exakt zu klären? Ich denke nein, denn ein wichtiger Aspekt eines Fachworts ist, dass es für den Leser leicht als solches erkennbar ist. Typische Fachwörter sind a) Fremdwörter, b) selten und c) vergleichsweise lang:

  • „Redux-Oxygenator“ erkennen wir sofort als Fachwort (obwohl ich das Wort gerade eben erfunden habe und auch nicht weiß was es bedeutet).
  • „Einbruch“ würden wir nicht als Fachwort einschätzen (obwohl das durchaus ein Terminus in der juristischen Fachsprache ist).

„Immer“ und „nur“ – das ist, denke ich, klar – sind so schlecht als Fachwörter erkennbar, wie es nur geht. Wenn wir die Bedeutung von „immer“ und „nur“ nun also merkmalssemantisch unterscheiden und fixieren wollten, müssten wir deshalb sehr, sehr deutlich machen, dass diese Wörter hier Fachbegriffe sind und als solche verstanden werden sollen. Von alleine würde ein Leser nicht auf die Idee kommen, hier ein Fachwort zu vermuten.

Was also tun?

Grundsätzlich ist es zwar möglich, die beiden Bedeutungen zu unterscheiden. Fragt sich nur, was dadurch gewonnen ist. Denn die Krux in dem Beispiel liegt ja darin, dass die beiden Begriffe fast gleichbedeutend sind. Die Bedeutungsschattierungen, die „immer“ und „nur“ transportieren, sind in diesem Kontext eigentlich irrelevant, sozusagen eine Geschmacksfrage.

Bleibt das Verwirrungspotenzial, wenn beide Begriffe nebeneinander verwendet werden. Und das ist tatsächlich vorhanden. Es ist durchaus vorstellbar, dass ein Leser versucht einen (nicht beabsichtigten) Sinn zu finden, warum ähnliche Sachverhalte unterschiedlich formuliert sind und er dadurch verwirrt wird.

Die Lösung des Ganzen ist letzten Endes recht einfach: Statt den Sinn genau abzugrenzen, würde ich mich in diesem Fall auf eine Variante (egal welche) beschränken und nur noch diese verwenden. Dadurch sind Missverständnisse ausgeschlossen und der Leser wird von semantischen Details verschont.