Ich finde es ist wichtig, für jede Aufgabe das geeignete Tool einzusetzen. In der Technischen Dokumentation arbeitet der Redakteur häufig in MS Word oder in Adobe FrameMaker. Beide ermöglichen das Erstellen der entsprechenden Inhalte. Ohne weitere Unterstützung liegen diese Inhalte dann als Dokumente in Verzeichnissen des Dateisystems. Die Verzeichnisstruktur wird typischerweise die Projekte, Sprachen und Versionen wiederspiegeln. Die Dokumente selbst stellen meist große Informationseinheiten dar: Kapitel oder vielleicht sogar die komplette Dokumentation.

Ein kleines Team, gut organisierter Redakteure, kann bei dieser Vorgehensweise effizient arbeiten. Es gibt kaum Verwaltungsaufwand. In vielen Fällen müssen die Informationseinheiten aber besser verwaltet werden. Größere Teams, viele Übersetzungen, viele Varianten und unterschiedliche Ausgabeformate sind Gründe für eine umfassendere Lösung.

Man braucht also ein Inhaltsverwaltungssystem oder Englisch Content-Management-System (CMS). Offensichtlich denken bei dem Begriff CMS inzwischen zu viele an die weborientierte WCMS Variante. Für Systeme die nicht nur Webseiten, sondern auch Druck und andere Ausgabeformate unterstützen verwendet man deshalb auch den Begriff Redaktionssystem.

Wir haben uns näher mit SCHEMA ST4 befasst, einem sehr mächtigen Vertreter unter den Redaktionssystemen. Dabei haben wir uns soweit eingearbeitet, dass wir SCHEMA Certified Partner wurden. Wir betreiben eine Testinstallation und eine Kollege und ich waren bei SCHEMA zu einer mehrtägigen Konfigurationsschulung.

 

Eine SCHEMA Konfiguration hat sehr viel mit XML/XSL Programmierung zu tun. Das System ist sehr offen und modifizierbar. Es ist wirklich sehr viel möglich, man darf aber keine Angst vor spitzen Klammern haben.

Ansonsten gefällt mir als .NET Entwickler natürlich der Technologie-Stack: Als Datenbank kommt standardmäßig ein SQL Server 2005 zum Einsatz, darüber kommt ein .NET basierter Applikationsserver auf den wiederum .NET Clients zugreifen. Alle Daten treten als XML in Erscheinung und werden über XSL formatiert. Selbst die in der Benutzeroberfläche dargestellten Elemente werden über XPath gesteuert.

Nach einer kleinen Einleitung, möchte ich nun einen Überblick geben, wie unsere 3D Ersatzteilkatalog-Lösung interaktive PDFs mit 3D Objekten erzeugt. SPCat3D selbst besteht aus mehreren Komponenten, die wiederum mit externen Programmen zusammenarbeiten:

Auf der linken, oberen Seite sehen wir unsere klassische Katalog-Software SPCat. Dieser Ersatzteilkatalog bietet uns sehr viele Möglichkeiten hierarchische Teilelisten zu importieren und zu bearbeiten. Wir verwenden diese erprobte Technologie als Stücklisten-Datenbasis weiter.

SPCat3D PDF Creator greift bei der PDF Produktion auf die SPCat Datenbank zu. Die Schnittstelle ist aber so ausgelegt, dass auch andere Datenquellen möglich sind. Unser eigener SPCat ist nur die nächstliegende und einfachste Anbindung. Andere Katalog-Systeme oder direkter Zugriff auf ERP Daten (SAP) sind auch denkbar.

Parallel müssen die 3D-CAD Daten aufbereitet werden. Wir verwenden dazu von Right Hemisphere die Deep Exploration CAD Edition. Mit diesem Tool können wir alle relevanten CAD Formate öffnen und bearbeiten. Unter anderem können wir damit die CAD Daten reduzieren und mit einer animierten Explosionsdarstellung versehen.

Der nächste Schritt ist die Zuordnung der Stückliste zu den CAD Grafiken und den einzelnen Objekten innerhalb einer Grafik. Dabei hilft es, dass Deep Exploration die Metadaten aus den meisten CAD Formaten übernehmen kann. Die genaue Vorgehensweise in dieser Stelle hängt sehr stark von den Ausgangsdaten ab.

Deep Exploration enthält ein PDF Publishing Module das es ermöglicht 3D Illustrationen in eine PDF Vorlage (Template) einzufügen. Von Right Hemisphere gibt es bereits einige fertige Templates die interaktive PDFs ermöglichen. Wir benötigen aber eine sehr viel weitergehende Funktionalität. Deswegen arbeiten wir mit unseren eigenen SPCat Templates.

Die Ausgabe des PDF Publishing Modules sind PDF Dateien mit eingebetteten 3D Objekten in unserem Template. Aber noch ohne die Möglichkeit zur Interaktion, denn dafür wir benötigen wir die Informationen aus der Stückliste.

Das ist dann die eigentlich Aufgabe unseres SPCat3D PDF Creators. Dieses Tool führt alle Informationen und Dateien zusammen. In die vorher erzeugten, statischen PDF Dateien wird die Stücklisten Information eingebettet. Es werden zusätzliche PDF Dateien erzeugt, die den Zusammenhang der einzelnen Baugruppen darstellen und die entsprechenden PDF Dateien miteinander verknüpfen.

Im Ergebnis erhält man ein Verzeichnis mit PDF Dateien, die die komplette Stückliste wiedergeben und die einzelnen 3D Illustrationen hierarchisch korrekt miteinander verbinden. Zusätzlich gibt es einen PDF Datei die einem Bestellformular entspricht und wie ein Warenkorb interaktiv aus den anderen PDF Dateien heraus gefüllt werden kann.

Wir bieten seit langem einen elektronischen Ersatzteilkatalog an, unseren Spare Part Catalog SPCat. Diese Software kommt sehr gut mit Stücklisten und 2D Zeichnungen klar. Bei 3D CAD Daten hatten wir bisher keine Lösung. Genau diese Funktionalität wird aber immer häufiger nachgefragt.

Die Visualisierung dreidimensionaler CAD Objekte ist aber ein Problem, das eine kleine Entwicklergruppe nicht mal eben lösen kann. Man muss zum einen die Dateien aus verschiedensten CAD Programmen verarbeiten können. Zum anderen braucht es einen Viewer, der die erstellten 3D Illustrationen darstellen kann sich gut in die restliche Ersatzteilkatalog-Software integrieren lässt.

Alle mir bekannten Anbieter von elektronischen Ersatzteilkatalogen haben sich entschlossen, dieses Know-How einzukaufen. Die meisten verwenden die Produkte von Lattice3D und binden deren freien XVL Player in Ihre Kataloge ein.

Es gibt auch eine interne SPCat Demo Version mit XVL Player die ganz gut funktioniert. Aber irgendwie fand ich es langweilig, wenn am Ende alle Kataloge den gleichen 3D Viewer verwenden und habe weiter gesucht. Dabei bin ich auf die Firma Right Hemisphere gestoßen. Auch von diesem Anbieter gibt es einen Betrachter (Deep View) der sich in eigene Anwendungen einbinden lässt. Deren Produkte können über 80 CAD Formate importieren und alle von uns getesteten Dateien wurden problemlos eingelesen.

Besonders spannend wurde es aber, als ich die Zusammenarbeit von Adobe und Right Hemisphere verstanden hatte: Right Hemisphere ist der Anbieter, der die Ausschreibung von Adobe gewonnen hatte, das PDF Format um einen 3D Viewer zu erweitern. Entsprechend gut ist in deren Produkten die Erzeugung von PDF Dateien mit eingebetteten 3D Objekten realisiert.

Bisher hatten wir in Richtung einer Software mit integrierten Viewer gedacht, jetzt gibt es eine weitere Möglichkeit: Die 3D Illustrationen werden in PDF Dateien eingebetteten und die Verknüpfung zur Stückliste und die Interaktion mit dem Anwender erfolgt komplett innerhalb das Acrobat Readers. Das bedeutet die Auslieferung des fertigen Katalogs vereinfacht sich enorm. Man muss lediglich einige PDF Dateien verteilen. Der Endanwender benötigt lediglich einen installierten Acrobat Reader 8.1. Die weite Verbreitung des Readers führt dazu, dass in aller Regel gar keine Vorbereitungen oder Installationen beim Endanwender nötig sind. Er öffnet nur eine PDF Datei.

Aktuell gibt es den Acrobat Reader in der Version 8.1 für folgende Betriebssysteme: Windows, Mac, Linux und Solaris. Das heißt ein SPCat 3D PDF-Ersatzteilkatalog funktioniert plattformübergreifend.

Zum Beispiel ein Pumpstand, dargestellt mit Linux Ubuntu 6.1 und dem Acrobat Reader 8.1.1 für Linux:

Der Testrechner ist nach heutigen Maßstäben wirklich langsam mit seinem Athlon 900. Ich habe eine nackte Ubuntu Installation verwendet, lediglich den Acrobat Reader 8.1.1 habe ich installiert. Es war von Seiten der Grafikkarte keinerlei 3D Unterstützung vorhanden. Trotzdem wurde das PDF mit dem 3D Objekt problemlos dargestellt und alle Interaktionen haben funktioniert. Lediglich bei Veränderung der 3D Ansicht kam das System ins Stocken und fiel auf eine Drahtgitter-Darstellung zurück.

Bei der eigentlichen Darstellung von 3D Illustrationen hat uns Adobe eine Menge Arbeit abgenommen. Wir können uns also ganz auf die Interaktivität und die Integration mit den Stücklisten und Ersatzteilinformationen konzentrieren.

Weiter geht es mit einem kleinen Überblick.

Im Rahmen der tekom-Jahrestagung 2007 vom 07. bis 09. November findet eine Messe mit Ausstellern aus dem Bereich der Technischen Dokumentation statt. Da darf die CPTec GmbH natürlich nicht fehlen. Dr. Kurt Schopper und ich werden den Stand bewachen und versuchen jeden Besucher für unsere Konzepte zu interessieren.

Ich denke wir werden unsere Kompetenz in der Technischen Dokumentation und bei elektronischen Ersatzteilkatalogen überzeugend darstellen können. Ein paar Informationen gibt es bereits auf unserer Webseite. Weitere Details, insbesondere zu unseren 3D Ambitionen, folgen hier in Kürze.

Die Strichmännchen leben weiter gefährlich!

Wie ich inzwischen erfahren habe, ist die englische Übersetzung von Strichmännchen nicht notwendig Stickmann, auch Stick Figure ist möglich. Mit diesem neuen Wissen konnte ich weitere Abenteuer der kleinen Kerle aufspüren: Stick Figures in Peril auf Flickr.

Zum Zeitpunkt dieses Eintrags waren dort bereits unglaubliche 10.308 Bilder abgelegt! Da müssen wir mit unseren paar Varianten richtig bescheiden bleiben. Alleine auf diesem Bild finden sich unglaubliche Gefahren:

Und als Abschluss diesen gefährlichen Hechtsprung in Untiefen. "Es hat sich bereits ein Krater gebildet, von all den Strichmännchen die an der gleichen Stelle aufprallen."

Ich radle fast täglich am Münchner Olympiastadium vorbei. Das Stadium wurde anlässlich der Olympischen Sommerspiele 1972 erbaut. Was man vielleicht nicht weiß, dass mit dieser Olympiade die jedem bekannte Zeichensprache der modernen Piktogramme entstand:

Otl Aicher hat alle vertretenen Sportarten und das komplette Leitsystem dieser Olympiade entworfen. Bei Erco liegen die Rechte und wenn die Webseite funktionieren würde, könnte man sich auch über den heutigen Stand der Bildersammlung informieren.

Im Rahmen der Gestaltungsarbeit für das visuelle Erscheinungsbild der XX. Olympischen Spiele in München im Jahre 1972 entwickelte der Grafiker Otl Aicher, einer der Mitbegründer der Ulmer "hochschule für gestaltung", erstmals eine systematisch aufgebaute Zeichensprache. Ein umfassendes und komplexes Repertoire von Bildzeichen diente dazu, ein internationales und vielsprachiges Publikum zu den diversen Veranstaltungsorten zu leiten und mit relevanten Informationen zu versorgen.

Am weitesten hat es das in den damaligen Piktogrammen verwandte, Strichmännchen gebracht. 1972 durfte es sich noch bei diversen sportlichen Aktivitäten stärken. Heute begegnet es uns eher in vielen gefährlichen Situationen. Manchmal zeigt es uns auch, wie wir uns richtig verhalten sollen.

Im Rahmen der Technischen Dokumentation schicken wir von CPTec das Strichmännchen regelmäßig von einem gefährlichen Abenteuer zum nächsten:

Die Erholungsphasen sind kurz und dringend benötigt:

Inzwischen gibt es sogar eine Sammlung seiner wichtigsten Einsätze!

Das deutsche Strichmännchen gibt es auch als englischen Stickman, dem es aber auch nicht besser ergeht. Überall lauert die Gefahr. Jetzt auch als reflektierende Aufkleber:

 

 

Gefunden über Rick Strahl - Stickman in Peril :)

Jeff Atwood hat etwas zum Thema "Technische Dokumentation" gefunden: How to Write Technical Documentation

Welcome to the world of technical documentation!

The situation you are in is no different from any other tech writer. The technical writing process:

   1. Ask engineer how the damn thing works.
   2. Deafing silence.
   3. Crickets.
   4. Tumbleweed.
   5. Just start writing something. Anything.
   6. Give this something to the engineer.
   7. Watch engineer become quite upset at how badly you've missed the point of everything.
   8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
   9. Collect these nuggets, as they are the only reliable technical information you will receive.
  10. Try like hell to weave together this information into something enlightening and technically accurate.
  11. Go to step 6.

Ok, you're not the doc writing type. That's okay, neither am I. However, people are already working to make this better, and I will continue to do so.

Das hat natürlich mit der Wirklichkeit gar nichts zu tun!
;)

In Ask Jeeves - neu und besser als Google? hat Günter Ratz auf der deutschen Beta von Ask Jeeves mal nach dem Begriff Technischer Dokumentation gesucht. Und natürlich habe ich da auch mal klicken müssen...

Dabei ist mir eines der neuen Features dieser Suchmaschine aufgefallen. Zu einigen Treffern gibt es ein Fernglas als Icon. Wenn man mit der Maus darüber fährt, wird ein kleine, gespeicherte Voransicht der Webseite geladen und eingeblendet. Sehr nett:

Da freut man sich doch, wenn man optisch so schön gefunden werden kann!

Doch, oh Schreck, was passiert da bei dem Treffer zum Tekom WebPortal?




Ah! Das barrierefreie Web...

Kein Vergleich der Funktionalität, sondern der Performance und des Speicherbedarfs von Microsoft Office 2003 im Vergleich zu Open Office 2.0:

Performance analysis of OpenOffice and MS Office by ZDNet's George Ou

Au Backe, da sieht Open Office 2.0 aber richtig schlecht aus. Es braucht deutlich länger und verwendet mehr Speicher.

Vielleicht findet sich ja die Zeit, daß ich selber mal damit rumspiele. Technische Dokumentation und Open Source geistert bei uns schon länger als Thema rum. Unter dem Gesichtspunkt könnte Open Office interessante Möglichkeiten bieten.