Was wird gewünscht?

Als Informationsanbieter stehen wir vor einer Reihe von Fragen und Problemen:

• Wie können wir unsere Informationen leicht zugänglich und auffindbar machen?
• Welche Datenformate und Medien sind geeignet?
• Wie organisieren wir unsere Datensammlungen, damit Änderungen und Aktualisierungen zentral und effizient durchgeführt werden können?
• Wie können mehrere Stellen denselben Informations-Pool füllen und bearbeiten?
• Wie können wir bereits vorhandene Informationen effizient wieder verwenden?

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.

Was heißt Single-Source-Publishing?

Single-Source-Publishing hat viele Aspekte:

• Aus denselben Quelldaten Dokumentationsprodukte für unterschiedliche Medien produzieren
• Dieselbe Information mehrfach für unterschiedliche Zwecke verwenden
• Im Idealfall nur ein Format für alle Daten einsetzen und möglichst wenig Tools
• An einer zentralen Stelle ablegen, erstellen und verwalten
• Single-Source-Verfahren gut in die bestehende IT-Landschaft einbinden
• Inhalte mit allgemein vorhandenen Werkzeugen (in der Regel Microsoft-Office-Produkte) erstellen

Was bieten heutige Lösungen?

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.

Von Papier nach Online

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.

Von Online nach Papier

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.

Integrierte Entwicklungsumgebungen

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.

Content-Management-Systeme

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.

Wie sehen erfolgreiche Lösungsansätze aus?

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.

Technische Umsetzung

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.

Beispiel für Single-Source-Publishing mit XML

Ausgangssituation

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:

• als Fehlermeldungen auf den Geräte-Displays (im Textformat)
• in den Druckerhandbüchern (im FrameMaker-Format)

Warum Single-Source?

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:

• Gemeinsame Meldungen, die bei verschiedenen, verwandten Druckmaschinen vorkommen, sollen nur einmal beschrieben werden.
• Die Ausgabe einer Meldung auf verschiedenen Medien soll aus derselben Quelle generiert werden.

Damit verringert sich der Erstellungsaufwand. Fehlerquellen und Übersetzungsaufwand werden reduziert.

XML-Lösung

XML scheint für die gestellte Aufgabe geeignet, da es Inhalt, Struktur und Layout strikt trennt, was die Informationsverarbeitung erheblich vereinfacht.

Meldungstexte erfassen

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>

Informationen auswählen und zusammenstellen

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.

Druckerhandbücher produzieren

Ü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.

Meldungen in druckerinterne Software integrieren

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.