Als Informationsanbieter stehen wir vor einer Reihe von Fragen und Problemen:
Wunsch wäre eine gemeinsame Quelle, die zentral, konsistent und redundanzfrei erstellt und gepflegt wird. Aus dieser Quelle sollen dann alle Informationsangebote ganz nach Bedarf zusammengestellt und produziert werden: Single-Source-Publishing.
Single-Source-Publishing hat viele Aspekte:
Seit Jahren bemühen sich Hersteller, Single-Source-Tools anzubieten. Dazu kommen von Publikationsseite die Content-Management-Systeme und von Entwicklungsseite die Umgebungen, bei denen die Erstellung der Dokumentation in den Entwicklungsprozess integriert ist.
Historisch bedingt ist bei den meisten Autorensystemen als Ausgangspunkt die Papierdokumentation, aus der mit Konvertern direkt oder über weitere Tools die Online-Dokumentation erzeugt werden kann. Bekannte Systeme sind Acrobat, Doc-To-Help, FrameMaker mit WebWorks Publisher und Help Workshop.
Wo liegen die Probleme?
Eine 'ver-online-te' Papierdokumentation ist noch lange keine optimale Online-Dokumentation. Bei einem Papierdokument, das mit einem herkömmlichen Tool erstellt wurde, ist es nicht möglich, automatisch Teile nach Belieben zu modularisieren, um sie in der Online-Welt als eigene Informationsknoten über Verweise wieder zu verwenden. Auch gibt es keine Möglichkeit, mit einem papierorientierten Autorensystem typische Online-Features (Modularität, Dynamik, Interaktivität, Kontextsensitivität) direkt in die Quellen zu integrieren. Schließlich ist die technische Seite nicht zufriedenstellend. Plattform-, Tool- und Herstellerunabhängigkeit sind nicht gegeben. Hoher Konfigurationsaufwand, Inflexibilität und z. T. erhebliche technische Mängel führen bei diesem Weg auch heute noch häufig zum Scheitern.
Den umgekehrten Weg - mit der Online-Hilfe beginnen und daraus eine Papierform generieren - bieten Online-Autorensysteme: RoboHelp und ForeHelp sind bekannte Vertreter.
Wo liegen die Probleme?
Die Konvertierung basiert in der Regel auf einer Reihe von voreingestellten Parametern und kann nur sehr eingeschränkt beeinflusst werden. Viele für die Papierdokumentation zentrale Funktionen wie Buchfunktion, Generierung von Verzeichnissen, Variantensteuerung, Seitenlayout-Gestaltung sind nur dürftig unterstützt. Das führt auf Papierseite zu Ergebnissen, die deutlich unter dem Niveau liegen, das heute mit papierorientierten Autorensystemen erreicht wird. Passable Ergebnisse lassen sich nur mit einem sehr hohen Konfigurationsaufwand erzielen, der sich aber nie rechnet.
Bei der Software-Dokumentation liefert die Entwicklung einen großen Teil der Inhalte. Viele Informationen sind bereits in den Programmquellen enthalten. Um die Fehlergefahr einzugrenzen und den Erstellungsprozess der Dokumentation zu beschleunigen, ermöglichen Entwicklungsumgebungen, Dokumentation aus den Programmquellen zu generieren. Jbuilder ist eine bekannte moderne Entwicklungsumgebung, die mit JavaDoc die Möglichkeit bietet, Dokumentation in die Programmquellen zu integrieren und aus den Quellen Online-Hilfe oder gedruckte Dokumentation zu generieren.
Wo liegen die Probleme?
Diese Lösungen sind für sich gesehen sehr gut und bieten häufig Verwaltungsunterstützung wie Versionierung, Zugangskontrolle und Multi-User-Fähigkeit, die konventionelle Autorensysteme nicht bieten. Allerdings sind es Insellösungen, die sich nicht in bestehende Autorensystemlandschaften integrieren lassen. Single-Source ist mit der Entwicklung realisierbar, nicht aber mit all den anderen Stellen (wie Vertrieb, Marketing, Schulung), die als Lieferanten und Nutzer der Dokumentation in Frage kommen.
Ausgehend von der Idee, möglichst alle Inhalte bequem zusammenzuführen, bieten diese Systeme die Möglichkeit, Daten aus unterschiedlichsten Quellen ins System einzustellen und über dieselbe Anzeige-Software anzuzeigen.
Wo liegen die Probleme?
Diese Lösungen sind im Hinblick auf eine qualitative Verbesserung der Informationsangebote eher ein Rückschritt, da sie dazu verführen, unüberlegt irgendwelche Inhalte einzustellen. Häufig basieren die Systeme auf einem dokumentorientierten Ansatz. Online-Features werden nur spärlich unterstützt, Schnittstellen zu den bekannten Online-Autorensystemen sind nicht oder nur ungenügend vorhanden.
Erfolgreiche zukünftige Lösungen basieren auf einem strukturorientierten Baukastenprinzip. Noch unabhängig von der konkreten technischen Umsetzung und den eingesetzten Tools, werden die Informationen umfassend nach logischen und anwendungsorientierten Gesichtspunkten strukturiert. Basierend auf dem von Prof. Sissi Closs entwickelten Klassenkonzept, sind erfolgreiche Strukturkonzepte mit vertretbarem Aufwand realisierbar. Knotenklassen geben die Regeln vor, wie die Informationen auf einzelne Bausteine verteilt werden. Verweisklassen legen fest, wie aus einzelnen Bausteinen sinnvolle Informationsgebilde systematisch zusammengestellt werden. Die Klassen reduzieren Komplexität und Umfang auf überschaubare Größen. Sie bieten außerdem die Möglichkeit, entworfene Konzepte sofort in Prototypen umzusetzen, um ihre Tauglichkeit zu testen. So ergeben sich ganz neue Möglichkeiten zur Systematisierung, Automatisierung und Qualitätssicherung.
Mehr und mehr kommt uns auch die Technik zu Hilfe. Bereits heute gibt es Autorenwerkzeuge wie Author-it, die das Klassenkonzept in Ansätzen unterstützen. Der Trend in Richtung XML verspricht hier gewinnbringende Weiterentwicklungen.
Ein wesentlicher Bestandteil der in Druckern integrierten Software sind die Fehlermeldungen.
Auf Grund des modularen Aufbaus von Hardware und Software kann dieselbe Fehlermeldung bei unterschiedlichen Druckertypen vorkommen. Außerdem werden die Fehlermeldungen eines Druckermodells mehrfach verwendet:
Die Fehlermeldungen haben bei hochwertigen Druckmaschinen einen Umfang von mehreren hundert Seiten. Sie müssen verwaltet, aktualisiert und in viele Sprachen übersetzt werden. Vermeidung von Redundanz ist daher ein wesentlicher Aspekt:
Damit verringert sich der Erstellungsaufwand. Fehlerquellen und Übersetzungsaufwand werden reduziert.
XML scheint für die gestellte Aufgabe geeignet, da es Inhalt, Struktur und Layout strikt trennt, was die Informationsverarbeitung erheblich vereinfacht.
Die Fehlermeldungen werden in XML beschrieben (siehe Textbeispiel).
Aufgrund der klaren, einheitlichen Struktur der Fehlermeldungen eignet sich XML hervorragend für diese Textsorte. Jede Fehlermeldung wird nur einmal erfasst (= Single-Source). Automatisierte Abläufe sorgen dann dafür, dass für jede Verwendung einer Fehlermeldung die passende Ausgabevariante maschinell generiert wird.
<?xml version="1.0" ?>
- <fehler>
<nr>T20.34</nr>
- <anzeige>
<p>Ende Tonervorrat</p>
</anzeige>
- <behebung>
- <ursache>
<p>Die eingesetzte Tonervorratsflasche ist leer</p>
</ursache>
- <aktion>
<p>Bitte ersetzen Sie die leere Tonerflasche durch eine
neue Flasche vom gleichen Typ</p>
</aktion>
- <ursache>
<p>Sollte sich noch genügend Toner in der Vorratsflasche
befinden, ist die Toneransaugung zu überprüfen</p>
</ursache>
- <aktion>
<p>Bitte überprüfen Sie die Tonerzuführung auf eine evtl.
Verstopfung und beseitigen Sie diese.</p>
</aktion>
- <sonst>
<p>Läßt sich der Fehler nicht beseitigen, so verständigen
Sie bitte die Serviceleitstelle</p>
</sonst>
</behebung>
</fehler>
Die einzelnen Fehlermeldungen werden passend für jeden Druckertyp und jede Auslieferungsvariante aus dem Pool der vorhandenen Fehlermeldungen zusammengestellt.
Das können in einfachen Fällen Hub-Dokumente bewerkstelligen. In größeren Umgebungen kommen XML-Datenbanken zum Einsatz.
Über eine geeignet eingerichtete Publikationsumgebung, basierend auf einem Werkzeug wie zum Beispiel FrameMaker+SGML, können die Fehlermeldungen in die übrigen Teile der Papierdokumentation nach geringfügigen Vorbereitungen automatisch eingebunden werden.
Für die Darstellung der Fehlermeldung auf den Drucker-Displays ist das Papier-Layout nicht geeignet. Deshalb werden über weitere Publikationsschienen dieselben XML-Quelldateien für die jeweilige Drucker-Software passend umgewandelt.
Kleinere Drucker zeigen die Fehlermeldung in einem einfachen Text-Display an.
Bei größeren Druckmaschinen ist ein Rechner mit einem grafikfähigen Display eingebaut. Hier kann die Fehlermeldung im HTML-Format angezeigt werden. Über Hyperlinks können auch weitergehende Beschreibungen, z. B. Wartungsprozeduren, angesprungen werden.
20.01.05
Prof. Sissi Closs - Inhaberin und Geschäftsführerin von Comet Computer und Comet Communication sowie Professorin für Informations- und Medientechnik im Studiengang Technische Redaktion an der Hochschule Karlsruhe
Herausgeberin:
Comet Computer GmbH
Rückertstr. 5
80336 München
Tel.: 089-54 45 60 45
Fax: 089-54 45 60 46
E-Mail: comet@comet.de
Verantwortlich:
Prof. Sissi Closs
Comet zählt seit Ende der 80er Jahre zu den führenden Anbietern im Bereich Technische Dokumentation. Mit unserem Team aus Informatikern, Natur- und Geisteswissenschaftlern sowie Grafikern und Web-Designern entwickeln wir anspruchsvolle Lösungen, die passgenau auf Ihre Anforderungen zugeschnitten sind. Wir erstellen Handbücher, Online-Hilfen und Bedienungsanleitungen – mediengerecht und in mehrsprachiger Übersetzung. Selbstverständlich übernehmen wir auch die Lokalisierung Ihrer Software und unterstützen Sie bei der Umstellung Ihrer Technischen Dokumentation auf Single Source Publishing.
In unserem modernen Schulungszentrum bieten wir Kurse zu allen aktuellen Themen der Technischen Dokumentation – von den Grundlagen bis zu den Tools wie RoboHelp, AuthorIT und Framemaker.
Die Comet Communication GmbH bietet Ihnen Beratung, Schulung und Service rund um die Technische Redaktion, Technische Dokumentation und Technische Kommunikation.
| 21.09.2010 | DITA (Darwin Information Typing Architecture) |
| 22.09.2010 | InDesign als DTP-Programm |
| 24.09.2010 | Lokalisierung |
| 29.09.2010 | Online-Hilfen - Grundkurs |
| 06.10.2010 | Captivate - multimediale Tutorials für die Software-Dokumentation |