Feindliche Übernahme: Print-orientierte Dokumente ins medienneutrale CMS migrieren

Von Print zu Digital: Eine sorgfältige Planung erleichtert die Migration von technischen Dokumenten

Viele Unternehmen nutzen den Schwung der aktuellen Digitalisierungsbestrebungen, um auch ihre technische Kommunikation, also Datenblätter, Handbücher usw. elektronisch verwertbar zu machen. Wo vormals Papier und PDF als Maßstab dienten, soll Information nun auch online, mobil und interaktiv bereitgestellt werden.

Die Idee hinter „Information 4.0“ ist, die richtige Information zur richtigen Zeit an die richtige Person auszuliefern. Um das zu bewerkstelligen, muss im Vorfeld aber festgelegt werden, was jeweils hinter dem Begriff „richtig“ zu verstehen ist. Das bedeutet, dass Informationen systematisiert und in mundgerechte Bausteine (diese Metapher klingt nur für Leute abwegig, die keine Kinder haben) zerlegt und aufbereitet werden. Schnell fallen Begriffe wie Metadaten, Modularisierung, Taxonomien, HTML 5 oder Content Delivery. An diesem Punkt kommt man nur noch mit Mühe, wenn überhaupt, ohne ein Content-Management-System weiter. So führen derzeit recht viele Unternehmen, deren Technische Redaktion bisher vorwiegend Dokumente mit DTP-Werkzeugen (Desktop Publishing) wie InDesign erstellt hat, ein Baustein-orientiertes CMS (auch „Component-CMS“ oder „CCMS“) als Publikationslösung ein.

Ist die Systementscheidung getroffen (als Goldpartner von SCHEMA empfehlen wir meistens deren ST4, aber das tut hier nichts zur Sache), das System installiert und die Mitarbeiter geschult, steht die Übernahme der bestehenden Dokumente ins neue System an. Und diese Migration bestehender Dokumente gestaltet sich möglicherweise wesentlich aufwändiger als gedacht. Warum das so ist, möchte ich in diesem Beitrag erläutern. Vergleichen wir dazu das Ausgangsmaterial mit dem Zielsystem.

Das Ausgangsmaterial

Verbreitete Werkzeuge, mit denen Dokument-orientierte Technische Redaktionen arbeiten, sind InDesign, Word oder FrameMaker. Unabhängig vom eigentlichen Tool finden sich eine Reihe von ähnlichen Merkmalen in der Redaktionsarbeit, die in unsere Betrachtung hineinspielen:

  • Dokument-Dateien als Arbeits-Einheit
    Die Datei ist die führende Informationseinheit im Prozess, auch wenn sich z. B. mit Buchfunktion oder Variablen im gewissen Umfang über- und untergeordnete Informations-Strukturen definieren lassen. Vom Inhalt her gedacht, agieren wir mit ganzen Dokumenten, bestenfalls in Kapiteln. Auf diesem Korn werden auch Varianten gebildet: Übersetzungen, Gerätevarianten, Dokumenttypen sind jeweils eigene Dateien. Bedingte Texte und Variablen leisten hier zwar je nach Werkzeug ihren Beitrag, das Ausmultiplizieren der Optionen im Griff zu behalten, ändern aber nicht das Grundprinzip.
  • Informationen sind linear strukturiert
    Im Wesentlichen ordnen sich Absätze und Tabellen brav hintereinander von der Titelseite bis zum Anhang. Alternativ dazu verteilen sich Text- und Bildrahmen auf einzelne Seiten. Besonders bei eher werblich genutzten Informationen wie Datenblättern kann man von einem hohen Maß an individuellen Layout-Entscheidungen ausgehen. Beliebt ist es, komplexe Tabellen zu gestalten, die bis hinunter zur einzelnen Zelle mit unterschiedlichen Schriftarten, Rahmen und Hintergründen versehen sind.
  • Dokumente und Arbeitsprozesse hängen vom Werkzeug ab
    Viele Porzesse sind auf das verwendete Werkzeug zugeschnitten und damit proprietär. In Word kann man Zeichnungen erstellen, in InDesign lassen sich Illustrator-Grafiken einbetten. Felder und Textmarken, Layout-Automatismen wie Silbentrennung, Seitenumbruch mit Schusterjungen-Regeln oder generierte Verzeichnisse sind praktische Hilfsmittel, die die Tools bereitstellen, die aber nur dort funktionieren.

Das Zielsystem

Baustein-orientierte Content-Management-Systeme sind deswegen ein hervorragende Basis für die Digitalisierung der Technischen Kommunikation, weil sie genau die Mechanismen mitbringen, um Informationen für die Digitalisierung zu systematisieren. Für unsere Betrachtung relevant sind u.a. diese Aspekte:

  • Medienneutrales Arbeiten mit CCMS
    CCMS sind auf die Ausgabe in diversen Zielmedien spezialisiert. Inhalte werden also nicht direkt gelayoutet, sondern als klassifizierte Elemente typisiert, z. B. als Überschrift, Auflistung oder Grafik mit Bildunterschrift. Wie diese Elemente im Ausgabemedium dargestellt werden, wird frühestens beim Erzeugen einer Publikation generisch anhand der Klassifizierung festgelegt. In digitalen Publikationen, z. B. im iiRDS-Format, kann das Layout auch vollständig dem anzeigenden System überlassen werden. Damit die Generik effektiv funktioniert, muss der Content im CCMS konsequent strukturell und semantisch aufbereitet sein. Das bedeutet auch, dass punktuelle, individuelle Anpassungen in der Darstellung nur sehr aufwändig zu realisieren sind und tunlichst vermieden werden sollten.
  • Textbausteine als Arbeits-Einheiten
    Die Arbeit im CCMS dreht sich um Textbausteine, die vor einer Publikation zusammengestellt werden. Diese Bausteine können Hierarchien bilden (z. B. Kapitel und Unterkapitel), lassen sich mehrfach wiederverwenden (typisch z. B. für Sicherheitshinweise) und v. a. lassen sie sich mit Eigenschaften bzw. Metadaten versehen, die sie beschreiben (z. B. Titel oder Schlagwörter) oder nach unterschiedlichen Kriterien klassifizieren (z. B. als Sicherheitshinweis, als einem Produkt X zugehörig oder als nur relevant für Wartungstechniker). Auf Basis der Textbausteine erfolgt im CCMS die Ausbildung von Varianten und Versionen, und auch Übersetzung und Mehrsprachigkeit wird normalerweise auf diesem Korn verwaltet.

Womit Sie also rechnen sollten

Wir haben also als Ausgangsmaterial linear strukturierte, möglicherweise individuell gelayoutete Dokumente in proprietären Formaten. Diese sollen in ein System übernommen werden, in dem klassifizierte Textbausteine mit medienneutralen Inhalten zu Hierarchien und Publikationen zusammengestellt werden. Sie müssen also damit rechnen, dass eine Reihe von Änderungen und Ergänzungen bei der Migration notwendig sein werden.

Wie gut sich die Übernahme automatisieren lässt, hängt dabei zum großen Teil davon ab, wie heterogen und individuell gestaltet das Ausgangsmaterial ist. Hier die wichtigsten Überlegungen:

  • Der Aufwand steigt mit der Heterogenität
    Je heterogener die Ausgangsdokumente, aber auch je höher die gesteckten Ziele, was Wiederverwendung, Vereinheitlichung und Klassifikation von Bausteinen angeht, desto mehr Aufwand bedeutet das für die Content-Übernahme. Ein umfassender Migrationsplan, der sowohl technische Details der Abbildung von alt nach neu als auch eine Timeline der Übernahme-Aktivitäten beinhaltet, sollte auf jeden Fall erstellt werden. Positiver Nebeneffekt: Die dazu notwendige Analyse der Bestandsdaten lädt dazu ein, alte Ausnahmen und Sonderfälle auszumerzen.
  • Nicht alles muss mit
    Nicht alle vorhandenen Dokumente müssen ins neue System übernommen werden. Je länger ein Dokument nicht mehr angefasst wurde, desto geringer die Wahrscheinlichkeit, dass es noch einmal überarbeitet wird. Hier lässt sich einiges an Aufwand einsparen. Denn sei es, weil Redaktionsteams sich nach und nach besser organisieren, oder weil die ganze Tech-Dok-Branche sich insgesamt weiterentwickelt, oder weil die Werkzeuge früher nicht so gut waren: ältere Dokumente verursachen erfahrungsgemäß mehr Aufwand als neuere.
  • Semantik fällt nicht vom Himmel
    Aus der linearen Abfolge von Absätzen, Überschriften, Auflistungen, Grafiken  und Tabellen der Ausgangsdokumente lassen sich zwar einige Strukturen und Attribute für das Zielsystem ermitteln. Aus einer Überschrift und dem nachfolgenden Text bis zur nächsten Überschrift lässt sich noch relativ leicht ein Textbaustein erzeugen. Aus einer zweispaltigen, einzeiligen Tabelle mit Warnsymbol-Grafik lässt sich vielleicht ein Warnhinweis ermitteln. Aber spätestens wenn es darum geht, eine Folge von Listenpunkten als Handlungsanweisung mit Arbeitsschritten und Zwischenergebnissen zu erkennen, wird eine automatische Konvertierung schwierig. Auch das Klassifizieren der Bausteine, meinetwegen als Sicherheits- oder Wartungsinformation, oder als nur für den amerikanischen Markt relevant, lässt sich oft nur manuell nachträglich zuordnen.
  • Vorsicht bei Übersetzungen
    Dass Ausgangsdokumente heterogen sein können, wirkt sich an einer Stelle besonders aus: Beim Übernehmen von Übersetzungen. Auch die Übersetzung basiert im CCMS auf dem Textbaustein als Einheit. Sind nicht alle übersetzten Dokumente exakt so strukturiert wie das Ausgangsdokument, weil beispielsweise ein Überschrift versehentlich zum Standard-Absatz wurde, kann die Zusammenführung schnell chaotisch werden. Wenn deshalb die vorliegenden Übersetzungen bereits mithilfe eines Translation-Memory-Systems (TMS) entstanden sind, empfiehlt es sich, nur die Ausgangssprache zu migrieren und die Übersetzung der Bausteine über die TMS-Anbindung abzuwickeln, die alle gängigen CCMS besitzen, um mit den zu erwartenden Hundertprozent-Matches günstig einen sauberen Übersetzungsstand zu erhalten.
  • Achten Sie auf Grafiken
    Proprietäre Mechanismen und Formate lassen sich nicht immer übernehmen. Als Beispiel möchte ich hier auf Grafiken etwas näher eingehen. CCMS arbeiten i.d.R. mit dem medienneutralen XML-Format, um Inhalte zu strukturieren. Grafiken in gängigen Austauschformaten von PNG und JPG über TIFF und EPS lassen sich dort verwalten, anzeigen und einbinden. In den Ausgangsdokumenten finden sich aber nicht nur hauseigene Dateiformate wie Illustrator (AI) oder Photoshop (PSD) in InDesign oder in WMF-Container verpacktes EPS  in MS-Word. Grafiken können auch direkt im Werkzeug gezeichnet sein und sind dann als Gruppe frei schwebender Objekt auf der Seite positioniert. Oder sie sind mithilfe der Grafikeinstellungen individuell beschnitten, skaliert und mit Effekten versehen. In all diesen Fällen ist eine Konvertierung in ein medienneutral verwertbares Format nötig.
  • Schützen Sie sich vor Doppelungen
    Dass man Textbausteinen  ggf. vielfach wiederverwenden kann, ist einer der großen Vorzüge von CCMS. Nach der Übernahme von Dokumenten, wo die Mehrfachverwendung eine eher untergeordnete Rolle spielt, bleibt hier ein großer Spielraum für Nacharbeiten. Es hat sich bewährt, bei der Migration dafür zu sorgen, dass zumindest Sicherheitshinweise, die ja gerne an vielen Stellen des gesamten Dokumentbestands in identischer Form wiederkehren, als eigene, wiederverwendbare Bausteine zu extrahieren und an zentraler Ablage-Stelle einzusammeln. Ähnlich lässt sich ggf. mit Konformitätserklärungen, einleitenden Bemerkungen u. ä. verfahren. Damit hat man einen guten Ausgangspunkt, um den Informationsbestand nach und nach von Doppelerfassungen zu bereinigen.

Schlussbemerkungen

Die Migration von DTP-orientierten Dokumenten in ein Baustein-orientiertes CCMS kann im einfachsten Fall (nicht zu viele homogene, strukturiert erfasste Dokumente, einfache Projektziele) sehr schnell und mit Bordmitteln (CCMS besitzen in der Regel eine Dokument-Import-Schnittstelle) von Statten gehen. Der Regelfall ist das unserer Erfahrung nach leider nicht.

Unerlässlich ist daher eine umfassende Analyse des Ausgangs-Materials und davon ausgehend ein ebenso umfassender Migrationsplan, der auch eine Zeit- und Ressourcenplanung beinhalten sollte. Da man die Fähigkeiten und Besonderheiten des neu beschafften CCMS vielleicht selbst noch nicht vollständig einschätzen kann, lohnt es sich fast in jedem Fall, sich dabei von einem erfahrenen Dienstleister beraten und auch begleiten zu lassen.

Ist Ihre Technische Dokumentation fit für die Digitalisierung? Planen Sie den Umstieg von DTP zu einem CCMS? Wir beraten Sie gerne zur Migration Ihrer Daten! Schicken Sie uns einfach eine Mail an: benjamin.rauschenberger@doctima.de.

Digital oder Papier? Vorteile der mobilen Dokumentation

Mobile Dokumentation per App hat viele Vorteile gegenüber Papier.

Digitalisierung, Industrie 4.0 und das Internet of Things verändern auch die Art, wie wir über Technische Dokumentation denken. Eine der ersten Maßnahmen auf dem Weg zu „Information 4.0“ ist es, die Dokumentation weg von der Kapitelstruktur themenbezogen zu strukturieren und sie mithilfe von Metadaten semantisch zu markieren.

Anstatt Handbücher auf Papier oder als A4-formatierte PDF-Datei auszuliefern, erzeugen wir auf dieser Basis dynamische Informationen in HTML5, die sich auf unterschiedlichen Displays, auf Maschinenkonsolen oder auf Mobilgeräten verteilen und betrachten lassen. Weiterlesen

Weltweit erfolgreich mit Single Source Publishing

Hilscher Produktseite

Hilscher Produktseite

Unser Kunde Hilscher als Hersteller von Komponenten für Industrienetzwerke agiert weltweit. Um seine wichtigsten Märkte optimal zu versorgen, pflegt Hilscher seine Website in sieben Sprachen. Sie zeigt unter anderem ein vollständiges, aktuelles Produktportfolio mit 1500 Produkten. Der Effekt dieser umfassenden Kommunikationsleistung ist messbar: bereits im ersten Jahr nach dem zurückliegenden Relaunch verdoppelten sich die Besucherzahlen des Internetauftritts. Dennoch bleibt der Gesamtaufwand für die Verwaltung der Inhalte überschaubar, die Website wird von zwei Mitarbeitern nebenbei betreut. Wie das gelingt, möchte ich in diesem Beitrag schildern.

Produktinformationen mit Single-Source-Ansatz

Detaillierte Informationen zu den einzelnen Produkten machen bei Hilscher das Gros des Website-Contents aus. Diese Inhalte werden nicht direkt im Internet-CMS TYPO3 gepflegt, sondern über einen Connector aus dem Redaktionssystem SCHEMA ST4 dort eingespielt. Es gibt eine Reihe von Gründen, die Produktbeschreibungen in dem für Single-Source-Publishing ausgelegten Redaktionssystem zu pflegen:

1. Mehrfachverwendung

Der naheliegendste Grund: Aus denselben Produktinformationen werden u. a. auch gedruckte Datenblätter erstellt. Um Konsistenz zu gewährleisten und Doppelarbeit zu vermeiden, ist da eine gemeinsame Datenquelle unabdingbar. Mit den HTML- und PDF-Ausgabmechanismen von ST4 lassen sich beide Formate auf Knopfdruck generieren.

2. Modularisierung

Eine Produktbeschreibung ist ein hochgradig strukturiertes Dokument. Sie besteht aus einem festgelegten Satz von Textbestandteilen wie Features, technischen Daten oder Bestellinformationen (Beispiel). Einige dieser Bausteine können dabei für ganze Produktgruppen identisch sein, wofür sich der Wiederverwendungsmechanismus des Redaktionssystems anbietet. Web-CMS sind nicht unbedingt für die Verwaltung dieses Komplexitätsgrads ausgelegt. TYPO3 erlaubt es immerhin, eine Seite aus mehreren Content-Elementen aufzubauen, aber Bearbeitung und Übersetzung verlieren schnell an Übersichtlichkeit.

3. Metadaten

In ST4 is es ein Leichtes, jedes Produkt mit Eigenschaften bzw. Metadaten zu versehen, die sich automatisiert aus dem Produktdatenmanagement übernehmen lassen. Im Internetauftritt entsteht mit diesen Informationen nützliche Zusatzfunktionalität. Bei Hilscher haben wir einen Technologiefilter (Beispiel) und einen kriteriengesteuerten Produkt-Finder implementiert. Beide Mechanismen erleichtern es dem Anwender, die für seine Zwecke richtigen Produkte zu identifizieren.

4. Übersetzungsmanagement

Die Produktbeschreibungen werden mithilfe von TRADOS in einer Agentur übersetzt. Die COTI-Übersetzungsschnittstelle von ST4 erlaubt eine zügige, kosteneffiziente Abwicklung der Übersetzungen und stellt mit seinem Übersetzungsreport ein mächtiges Werkzeug for die Qualitätssicherung zur Verfügung.

5. Qualitätssicherung

Der Abgleich nach TYPO3 aus dem ST4 erfolgt automatisiert über die von doctima entwickelte Standard-Schnittstelle ContentConnect, die Fehlerbehandlung, Datenmodellabgleich und Reporting mitbringt.

Redaktionsarbeit in TYPO3

Überblicksinformationen und Unternehmensbeschreibung sind in der Regel Freitext und lassen sich deshalb leichter als die Produktinformationen im Web-CMS verwalten. Auch sind bei diesen Texten die Nutzeffekte kleiner, die sich z.B. aus Modularisierung und Wiederverwendung ergeben. Deshalb werden diese Informationen direkt in TYPO3 gepflegt.

Um auch in TYPO3 ein systematisches Übersetzungsmanagement zu implementieren, haben wir die vorhandene Extension Localization Manager von Loctimize in Abstimmung mit der Übersetzungsagentur unseres Kunden angepasst.

Aus dem Produktivbetrieb

Das oben beschriebene Setting befindet sich mittlerweile seit einiger Zeit erfolgreich im Produktivbetrieb und die Projekterwartungen konnten vollständig realisiert werden. Neben den erhofften Nutzeffekten haben sich für unseren Kunden aber immer wieder auch unerwartete Benefits ergeben. Ein Beispiel: Wir hatten den  automatisierter Import von Inhalten und verknüpften Metadaten eigentlich für die Produktfinder-Funktion gedacht. Nebenbei liefert er aber systematisch Keywords und verbessert damit u.a. die Statistik-Auswertung von Marketing-Aktionen. Fazit: Wenn sich Dokumentation und Marketing enger zu verzahnen, steht dem weltweiten Erfolg nichts mehr im Weg.

Information 4.0 – Schritte auf dem Weg zur Intelligenten Information

Industrielle Steuerung?Die Digitalisierung der Arbeitswelt ist derzeit eines der meist diskutierten Themen. Auch unserer Branche, der Technischen Dokumentation, stehen tief greifende Veränderungen bevor.
Seit Anfang 2016 bin ich Mitglied der tekom-AG „Information 4.0“ und gestalte dadurch diese Veränderungen mit. In der AG arbeiten wir iiRDS aus, einen Standard zur Bereitstellung von intelligenter Information in digitalisierten, vernetzten Umgebungen. Mit diesem Beitrag fasse ich einige meiner Gedanken zum Thema Industrie 4.0 und intelligente Information zusammen.

Einige Begriffe

  • Industrie 4.0, digitale Fabrik: Sich selbst steuernde, weitestgehend automatisierte Fertigungsprozesse, die der Mensch nur noch „orchestriert“ und bei Bedarf eingreift.
  • Cyberphysikalisches System: Komponente, die aus einem dinglichen Objekt und aus einer digitalen, vernetzten Repräsentation besteht.
  • RAMI 4.0: dreidimensionales Referenzarchitekturmodell der Plattform Industrie 4.0. Strukturiert das Thema nach Lebenszklus von Entwurf bis Entsorgung, Hierarchie von Einzelkomponente bis zur umgebenden Cloud und nach Integrationslevel von Objekt („Asset“) bis Geschäftsmodell („Business“).
  • Verwaltungsschale: Digitale Repräsentation eines cyberphysikalischen Systems. Enthält beschreibende und identifizierende Eigenschaften, Sensordaten und Zugriffsmöglichkeiten zu digitalen Funktionen.

Technische Dokumentation heute

Für die meisten Akteure im Umfeld Industrie 4.0 findet Technische Dokumentation auf dem sog. „Asset Level“ in der digitalen Fabrik statt. Sie gehen gedanklich vom aktuellen Status Quo (oder eigentlich von dem Stand vor zehn Jahren) aus, und der heißt PDF. Dokumente für Installation, Wartung, Betrieb und ggf. Entsorgung werden als Einheiten betrachtet und als abrufbare Eigenschaften in der Verwaltungsschale eingeplant.

Auf diese Granularität zielt wohl auch die in Arbeit befindliche VDI-Richtlinie 2770 zur digitalen Herstellerinformation ab. Für einige Branchen (gerade ältere Industrieanlagen sind in der Regel auf Papier dokumentiert) ist das auch sicher ein Fortschritt. Aber natürlich geht viel mehr.

Intelligente Information

Technische Dokumentation lässt sich viel präziser modularisieren. In vielen Redaktionen wird das bereits heute betrieben, v. a. als Basis des Variantenmanagements: Die Filterung nach Zielgruppen, Sprachen, Gerätevarianten findet heute bereits statt und zwar beim Publizieren von Dokumentvarianten.

In einer Industrie-4.0-Umgebung lässt sich diese Filterung zum Lesezeitpunkt hin verlagern. Damit werden gezielte Abfragen möglich, die dem Anwender die von ihm benötigte Information passend zu seiner aktuellen Aufgabe bereitstellen.

Dazu werden Metadaten benötigt, die die einzelnen Informationsmodule klassifizieren und identifizieren. Zuordnung zu Hersteller, Gerät, Variante, Komponente und Funktionsgruppe sind ebenso entscheidend wie Sprache, Zielgruppe und Informationstyp. Außerdem erfordert die Integration ein Auslieferungsformat, das sich embedded, mobil und am Schreibtisch sauber anzeigen lässt. Standardisierung ist nötig, damit sich die Dokumentation unterschiedlicher Hersteller zu einer Gesamtinformation integrieren lässt.

Bei der tekom arbeiten wir an einem solchen Standard, dem iiRDS. Die Arbeitsgruppe hat ihre Zwischenergebnisse auf der tekom-Jahrestagung vorgestellt. Der Standard soll Mitte nächsten Jahres verfügbar sein.

Wo am Ende die Informationen bereitgestellt werden, ob direkt beim Komponentenhersteller, beim Anlagenbauer, vor Ort beim Betreiber der digitalen Fabrik oder direkt auf der Komponente, ist dabei offen. Ebenso ist offen, ob die Information auf einem eigenen Content Delivery Server, einem integrierten Webservice (der zum Beispiel über den doctima ContentConnect mit Inhalten versorgt wird) oder als Informationsbausteine in einem Asset Management System wie SAP AIN zu liegen kommen. Das abstrakte Konzept der Verwaltungsschale erlaubt hier viele Wege zu gehen.

Die Idee, dass alle (bleiben wir realistisch: möglichst viele) Ersteller von Technischer Information ein gemeinsames Format bereitstellen, um dem Anwender einen integrierten Wissensschatz zu einem aus vielen Komponenten bestehenden System bereitzustellen, erscheint mir auch ohne den direkten Bezug zu Industrie 4.0 ein absolut erstrebenswertes Ziel zu sein – weil es u. a. zu Verbesserungen für das leidige Thema Zulieferdokumentation bringen kann. In der Denkweise des RAMI 4.0 lässt sich die Dokumentation von der untersten Ebene mit PDF-Dokumenten als „Assets“ auf die vierte Ebene, das Information Layer, mit Content-Delivery-Diensten als funktionaler Teil der übergreifenden Verwaltungsschale aufwerten.

Ich bin sehr gespannt auf die kommenden Entwicklungen und wie sich das iiRDS-Format in der Praxis bewähren wird – und auf Ihre Meinung. Wie sind Ihre Erwartungen bezüglich der Digitalisierung der Arbeitswelt? Diskutieren Sie mit uns in den Kommentaren!

Eine App für Arbeitssicherheit und Umweltschutz

dka_screenshot

Die Startseite der Handbuch-App

Heute möchte ich ein Projekt aus dem Bereich Mobile Dokumentation vorstellen, das wir mit unserem Kunden Dresdner Kühlanlagenbau GmbH, kurz: DKA, umgesetzt haben. Einen kurzen Vortrag dazu habe ich bereits im „Showcase Mobile Doku“ auf der letzten tekom-Jahrestagung gehalten. Nach einem Jahr im Produktivbetrieb liegt uns nun eine ganze Reihe von positiven Rückmeldungen vor, die unser Credo bestätigen, dass mobile Dokumentation im richtigen Kontext einen deutlichen Mehrwert gegenüber herkömmlichen (Papier-)Dokumenten schafft.

Die DKA installiert und wartet Kühlanlagen und Klimatechnik für Handel, Gewerbe und Industrie. Die mehreren hundert Monteure im Außeneinsatz sind verpflichtet, ein Handbuch mit Betriebsanweisungen dabei zu haben, die den Umgang mit Gefahrstoffen und gefährlichen Situationen regeln. Das Unternehmen ist vielfach zertifiziert, u. a. nach ISO9001 und §6 ChemKlimaschutzV, und wird auch von seinen Kunden regelmäßig evaluiert. Mit dem Handbuch als Loseblattsammlung war es schwierig sicherzustellen oder nachzuweisen, dass alle Monteure immer mit dem aktuellsten Stand von Informationen versorgt sind. Daraus entstand die Idee, das Handbuch in eine Smartphone-App umzusetzen und um einige hilfreiche Funktionen zu ergänzen.

Was die App leistet

Die App soll im Kern zwei Dinge erreichen: Sicherstellen, dass die Mitarbeiter Änderungen in den Betriebsanweisungen zeitnah und nachweisbar erhalten.Und sie motivieren, das Handbuch tatsächlich zu verwenden.

Um auch in Kellern und Tunneln verfügbar zu sein, bringt die App alle wesentlichen Inhalte – das sind v.a. Betriebsanweisungen und ein Gefahrstoffverzeichnis mit Sicherheitsdatenblättern der Hersteller – offline mit. Verteilt und aktualisiert wird sie via Mobile Device Management.

Um unsere eher handwerklich fokussierte Zielgruppe zum Lesen zu motivieren haben wir uns einige Dinge einfallen lassen. Begonnen mit einer ansprechenden Aufmachung, weiter mit schnellen und alternativen Zugangswegen zur Information, deren Formulierungen wir gestrafft und auf Verständlichkeit optimiert haben bis hin zu einer Kommentarfunktion, um den Kollegen die Möglichkeit zu geben, sich aktiv in den Gestaltungsprozess des Handbuchs mit einzubringen.

Geänderte Anweisungen werden direkt auf der Startseite angezeigt. Im Dokument selbst sind die geänderten Abschnitte farbig hervorgehoben. Zudem erscheint in geänderten Dokumenten ein Button um zu bestätigen, dass man die Änderungen wahrgenommen hat. Nach dem Bestätigen verschwinden Button und Markierungen. Die Bestätigungen aller Mitarbeiter werden auf einem Server gesammelt, wo sie sich für Audits auswerten lassen.

Um einen weiteren Anreiz zu schaffen, regelmäßig in das Handbuch hineinzusehen, haben wir eine Rubrik mit aktuellen Meldungen eingerichtet. Das sind die einzigen Inhalte die direkt vom Server bezogen werden. Sie werden prominent auf der Startseite angezeigt.

Welche Technologien wir verwenden

Das Handbuch ist eine hybride Android-App, d.h. HTML-Seiten verpackt mit Adobe PhoneGap. Das HTML für die Inhalte basiert auf dem responsiven Framework Bootstrap von Twitter, das wir um einige eigene Funktionen erweitert haben. Von den PhoneGap-Features nutzen wir v. a. den lokalen Dateizugriff, um die zugelieferten Sicherheitsdatenblätter-PDFs anzuzeigen, und die lokale Datenbank und die Abfrage des Verbindungsstatus zu Pufferungszwecken. Die Interaktionen mit dem Server erfolgt über Javascript und HTTP.

Ein TYPO3-Server, den wir entsprechend erweitert haben, dient als zentrale Gegenstelle für die Nutzerverwaltung, die aktuellen Meldungen, das Feedback und die Lesebestätigungen.

Für die Redaktion der Inhalte verwenden wir SCHEMA ST4. Dessen Datenmodell mit klassifizierten Knoten, Links und Metadaten nutzen wir, um die Inhalte mit Intelligenz auszustatten.

Intelligenter Content

Neben der Wiederverwendung (in den Betriebsanweisungen werden sehr viele Textbausteine mehrfach eingesetzt) und dem Single Source Publishing (neben einer Desktop-Ausgabe fürs Intranet gibt es von der App auch eine PDF-Druckversion) nutzen wir die Features unseres Redaktionssystems v. a. dazu, um ein möglichst smartes Endprodukt zu erzeugen. Im Folgenden will ich ein paar Beispiele zeigen:

Aufklappbereiche strukturieren die einzelnen Betriebsanweisungen. Zu diesem Zweck haben wir die Betriebsanweisungen in einzelne Objekte (in ST4: „Fragmente“) zerlegt, die über ein Metadatum als Aufklappbereiche markiert sind. Im HTML werden diese Bausteine zu Bootstrap-Panels mit klickbarer Kopfzeile und versteckbarem Body. Der Aufwand für dieses Feature besteht hauptsächlich darin, redaktionell ein Metadatum zu setzen und in der Generierung dafür zu sorgen, dass das Fragment mit Metadatum in ein DIV der Klasse „panel“ umgesetzt wird.

Ein anderes Metadatum steuert, welche Sicherheitssymbole zu Beginn eines Seitenbereichs ausgegeben werden. Das Erfassen über eine Mehrfachauswahl ist leichter und flexibler als das direkte Zuordnen von Bildreferenzen.

Die Einteilung des Inhalts in Bausteine ist auch Voraussetzung dafür, dass einzelne Abschnitte ihr Überarbeitungsdatum kennen und in der App als geändert markiert werden können. Auch hier wird ein Metadatum aus dem Redaktionssystem, diesmal als HTML-Attribut „data-lastchanged“,ins Endprodukt übertragen.

Eine wesentliche Verbesserung der Bedienbarkeit am Smartphone erreichen wir durch die einfache Maßnahme, dass Links als Buttons dargestellt werden. Insbesondere die Notrufnummer, die im Bereich Erste Hilfe immer wieder im Text erscheint, wird als roter Button mit Telefonsymbol umgesetzt – der natürlich bei Betätigung sofort den Notruf auslöst.

Gefahrstoffverzeichnis

Type Ahead: Das Gefahrstoffverzeichnis verkürzt sich während des Tippens

dkagefstoff

Alles zum Gefahrstoff auf einen Blick

Die umfassendste Veränderung haben wir der Gefahrstofftabelle angedeihen lassen. Die ist im Original eine Tabelle mit einem Dutzend Spalten und einigen hundert Zeilen, die sich im Querformat über mehrere DIN-A4-Seiten verteilt. Gefolgt wird sie im Original von einer Reihe von Legenden, da in der Gefahrstofftabelle nur Platz ist für die ISO-Kürzel der verwendeten Gefahrensymbole und Hazard- bzw. Precautionary Statements. Diese Tabelle und ihre Legenden haben wir in einzelne Objekte und Querbeziehungen zwischen ihnen aufgelöst. Das erlaubt uns, mit einer Type Ahead-Auswahlliste in der App einen schnellen Zugang zu den Gefahrstoffen zu legen und jeden Gefahrstoff als eigene übersichtlich gelayoutete HTL-Seite zu erzeugen. Im PDF generieren wir wieder die Tabelle im Querformat.

Mit diesen Beispielen möchte ich zeigen, dass intelligente Information schon mit kleinen Eingriffen in den Redaktionsprozess erreicht werden kann. Die Liste ist nicht vollständig, aber sie soll auch nur ein Gefühl dafür geben, dass es mit überschaubarem Aufwand und ohne das Budget eines Großkonzerns möglich ist, dem Medium mobile Dokumentation einen spürbaren Mehrwert zu verleihen.

Projektergebnisse

Nach einem Jahr Produktivbetrieb sehen wir alle Projektziele erreicht. Die Aktualität nach Rechts- und Sachstand ist deutlich verbessert. Reaktionszeiten sind verkürzt, Lesbarkeit und Zugänglichkeit erhöht, und nebenbei wurden die Verteilkosten gesenkt. Die Nachweisbarkeit ist erreicht, was bereits beeindruckte Rückmeldungen von Auditoren und Großkunden zur Folge hatte. Die App kommt bei der Zielgruppe ebenso gut an wie bei führenden Mitarbeitern und hat im Unternehmen einen hohen Stellenwert, sodass Erweiterungen und weitere ähnliche Anwendungen diskutiert werden.

Wir als doctima (das „wir“ bisher in diesem Beitrag bezog sich immer auf das Projektteam bei uns und bei DKA) haben aus diesem Projekt viel gelernt, insbesondere, was das Zusammenspiel von Redaktionssystem und intelligentem mobilem Informationsprodukt angeht. Im Augenblick entsteht eine Masterarbeit auf der Grundlage unserer Erkenntnisse.

Auf der kommenden tekom-Tagung haben wir außerdem eine Demo-App im Gepäck, mit der Sie sehen können, wie die hier erarbeiteten Konzepte in der Praxis aussehen. Falls Sie noch keine Karten zur tekom Messe haben – kein Problem: Hier anmelden und Sie erhalten gratis von doctima Ihren persönlichen Aktions-Code für eine Freikarte. Und übrigens: Besucher unseres Messestands erhalten einen kostenlosen 3D-gedruckten „Textbaustein“.

Warum ich SCSS nicht mehr missen möchte

Schickes CSS mit Sass

Schickes CSS mit Sass

Ich beschäftige mich mit Redaktionsprozessen und deren Optimierung. D. h. ich werde immer hellhörig, wenn es eine Chance gibt, etwas zu vereinfachen oder besser zu strukturieren.

In einem anderen Teil meines Jobs gestalte ich Online- und mobile Medien. Dort spielt HTML 5 eine große Rolle. Für dessen Gestaltung verwendet man CSS, und mit CSS habe ich als jemand, der in Strukturen denkt, ein Problem.

Mein Problem mit CSS

CSS bietet kaum Möglichkeiten, zu strukturieren. Es ist auf schnelle Verarbeitung durch den Browser hin optimiert, Wartbarkeit hat nicht Priorität. Im Wesentlichen bestehen CSS-Dateien deswegen aus einer linearen Abfolge von Regelsätzen, die bestenfalls in Blöcke für unterschiedliche Zielmedien gruppiert sind, also z.B. für Mobilgeräte oder Drucker. Alle Angaben sind explizit. Das bedeutet, jede Farbangabe, die mehr als ein Element betrifft, muss mehrfach identisch hingeschrieben werden. Es gibt keine Variablen. Damit werden komplexe Stylesheets schnell unübersichtlich und sind schwierig zu pflegen.

Eine Lösung

Konzeptionell lässt sich die Unstrukturiertheit von CSS nur rudimentär behandeln: Man kann die CSS-Regeln auf mehrere Dateien verteilen. Effektiver wäre es aber, CSS zumindest für die Erfassung um gängige Programmierkonzepte zu erweitern wie Variablen, Vererbung, Hierarchien oder Berechnungsfunktionen.

Tatsächlich haben sich seit Längerem mehrere Formate etabliert, die genau das leisten. Beispiele sind LESS, Coffeescript oder SASS. Das Format SCSS, das ich hier vorstellen will, ist eine syntaktisch andere Geschmacksrichtung von SASS. Diese Sprachen erlauben es, Regelsätze strukturiert zu erfassen, sind aber leider für Browser nicht lesbar. Deshalb werden sie mit sog. Präprozessoren ausgeliefert. Präprozessoren sind Konverter, die Dateien vor dem Ausliefern an den eigentlichen Prozessor (hier: den Browser) verarbeiten. Somit besteht SCSS aus zwei Komponenten:

  • einem Format, bei dem es sich um eine funktionale Erweiterung von CSS handelt.
  • einem Prozessor, der für unterschiedliche Betriebssysteme unter einer MIT-Opensource-Lizenz frei erhältlich ist.

Sassy CSS

Ich möchte die wesentlichen Features von SASS (die Abkürzung steht für „Syntactically Awesome Style Sheets“) bzw. SCSS („Sassy CSS“) hier nur kurz anreißen.

  • Regelsätze schachteln: Angaben beispielsweise für Links, die im Footer oder im Header stehen, lassen sich innerhalb des Regelsatzes für allgemeine Links platzieren, anstatt sich irgendwo über die CSS-Datei zu verteilen.
  • Abgeleitete Klassen: Formate für Warn- und Gefahrenhinweis-Boxen lassen sich von einer gemeinsamen, allgemeineren Klasse Hinweis-Box ableiten, anstatt alle Angaben zu wiederholen oder in mehrere gemeinsame und spezifische Regelsätze zu verteilen.
  • Ausgelagerte Dateifragmente, Partials: In sich geschlossene Teilbereiche, beispielsweise die Regelsätze für das Navigationsmenü, lassen sich in einzelne Dateien auslagern. Das geht auch mit CSS, wo aber jede ausgelagerte Datei im HTML-Kopf explizit referenziert werden muss. Der SCSS-Präprozessor fasst die Partials zu einer einzigen Datei zusammen, was sowohl die Verwaltung der Referenzen im HTML erleichtert als auch die Performance verbessert.
  • Variablen: Werte, aber auch ganze Regeln lassen sich in Variablen deklarieren. Wiederkehrende Gestaltungselemente oder CI-Farben lassen sich somit an einer Stelle verwalten und bei Bedarf zentral austauschen.
  • Operationen und Funktionen: SCSS stellt eine ganze Reihe von Manipulationen und Berechnungen zur Verfügung. Das Spektrum reicht von einfachen Farbänderungen wie darken($color) über Textfunktionen und Mathematik bis hin zur Verarbeitung von assoziativen Listen wie mit map_get($map, $key).
  • Mixins: Mixins sind aufrufbare Makros, denen man Parameter mitgeben kann. Um auf das Beispiel mit den Hinweis-Boxen zurückzukommen: Ein Mixin hinweisbox($severity, $symbol) kann die Darstellungsregeln für eine Hinweis-Box enthalten, mit Parametern für die Gefahrenstufe und das anzuzeigende ISO-Symbol. Die Gestaltung eines Gefahrhinweises mit Augenschutz kann sich dann auf den Aufruf @include hinweisbox(‚Gefahr‘,‘Laser‘) beschränken.

SCSS im Alltag

Wir verwenden SCSS mittlerweile seit mehreren Jahren in praktisch allen Projekten, in denen CSS eine Rolle spielt, und bereuen den Schritt in keiner Weise. Die Aufwände für Installation und Einarbeitung waren kaum der Rede wert. SCSS ist anders als SASS eine reine Erweiterung der CSS-Syntax, womit der Einstieg sehr schnell vonstattenging.

Die Features, die wir am meisten nutzen und die uns massiv Zeit ersparen, sind Variablen und Partials, die besonders in Projekten mit mehreren Layouts (Kunde und Tochterfirma, Eigenmarke und OEM) ihren Nutzen ausspielen. Und, ganz wesentlich: das Schachteln von Regelsätzen, das ein sinnvolles Strukturieren der Stylesheets erst ermöglicht und nebenbei sehr viel Schreibarbeit erspart.

Eine nicht zu unterschätzende Nebenwirkung dieser Strukturierung ist, dass wir automatisch sehr viel systematischer an die Gestaltung der Stylesheets herangehen als zu Zeiten, als wir nur einzelne Regeln hintereinander weggeschrieben haben. Da war es schnell passiert, dass der allgemeine Regelsatz für Links und der spezielle Regelsatz für Links im Footer tausend Zeilen weit auseinander standen. Mit SCSS erhöht sich die Wartbarkeit der Lösung deshalb ganz ungemein.

Was den Übersetzungsvorgang von SCSS nach CSS angeht: Wir haben das in den beiden Entwicklungsumgebungen, mit denen wir arbeiten, PhpStorm und Visual Studio, über Plugins so eingerichtet, dass der Präprozessor beim Speichern der SCSS-Datei automatisch anspringt. Das bedeutet, dass die generierten CSS-Dateien nebenbei und ohne unser explizites Zutun entstehen. Der administrative Mehraufwand besteht also vor allem im einmaligen Einrichten der jeweiligen Plugins.

Fazit

Wir haben SCSS für meinen Geschmack viel zu spät entdeckt, als es bereits jahrelang zur Verfügung stand. Mittlerweile ist es aber für mich und mein Team aus dem Arbeitsalltag nicht mehr wegzudenken, wenn es um Online- und mobile Medien geht. Auch wenn wir seine Möglichkeiten nicht bis ins Letzte ausreizen, sind bereits die wenigen Key Features, die wir ausführlich nutzen, eine erhebliche Erleichterung beim strukturierten Entwickeln und Warten von Stylesheets. Wenn Sie also mit CSS im Vanillegeschmack arbeiten, und gerne effizienter damit umgehen möchten, kann ich Ihnen dringend einen Blick auf SCSS empfehlen.

 

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.

Content Connected

Content Connected

Content Connected

Kürzlich gestand mir eine Technische Redakteurin: „…Und dann kopiere ich die einzelnen Technischen Daten in die Eingabemaske für die App und das Online-Portal. Das ist schon recht mühselig.“

Ein anderer Redakteur zeigte mir vor einiger Zeit seine Lösung: Er erzeugt aus seiner Redaktionslösung einige tausend statische HTML-Produktbeschreibungen, mit eigenem Navigationsbereich und allem, um das Ganze dann in einem iFrame in die Webseite einzukleben, die selbstverständlich dynamisch von einem Web-CMS (WCMS) erzeugt wird. Weder die Suchmaschine noch die Sprachumschaltung der Site sind angebunden. Optik und Bedienbarkeit sind damit -nun ja- diskutabel.

Solche und ähnliche Szenarien begegnen mir immer wieder. Was mich dabei fuchst: In beiden Fällen arbeiten Technische Redaktion und Marketing mit hochprofessionellen Werkzeugen und Methoden. Auf dem Weg zum Anwender verpufft aber die ganze schöne Effizienz an fehlenden Schnittstellen.

Schatzkiste Technische Dokumentation

Was leider oft übersehen wird: In der Technischen Redaktion entstehen mit professionellen Methoden und Werkzeugen hochwertige Inhalte:

  • Konsistente, qualitätsgesicherte und umfassende Produktinformationen,
  • Strukturierte Informationen, die personalisierte Darstellung bzw. Filterung erlauben – so entstehen aus demselben Ausgangsmaterial Sichten für Kunden, Partner, Mitarbeiter,
  • Hochwertige und durch Standardisierung kostengünstige Übersetzungen,
  • Professionell erstellte Grafiken und Bilder,
  • Metadaten, die z. B. über Facettensuche oder Kriterienfilter einen gezielten Zugang zum Produktportfolio ermöglichen.

Diese Inhalte werden häufig ausschließlich für die mit dem Produkt ausgelieferte Technische Dokumentation verwendet. Bestenfalls erstellt die Technische Redaktion auch Schulungsunterlagen und Produktblätter.

Profit für mehr Abteilungen

Wir haben uns diese Schnittstellen einmal systematisch angesehen und waren selbst überrascht, wie viele Unternehmensbereiche von diesem Datenschatz profitieren könnten. Insbesondere für Vertrieb und Marketing bieten sich vielfältige Optionen, die Informationen im Unternehmen weiter zu verwerten:

  • Produktbroschüren, Kataloge
  • Website, Shop
  • Produktpräsentations-Unterlagen
  • Reparatur- und Wartungsanleitungen
  • Support-Datenbank, Knowledge Base
  • Anforderungs-Management
  • ERP, PLM
  • … u. v. m.

Diese Informationsangebote entstehen zum überwiegenden Teil nicht in der Technischen Redaktion. Es gibt aber an zahlreichen Stellen Schnittmengen zu den Daten, die in der Technischen Redaktion erarbeitet werden. Nicht immer, und da sind wir wieder bei den Beispielen vom Anfang dieses Beitrags, findet allerdings an diesen Schnittstellen ein effizienter Abgleich statt.

Ein typisches Szenario sieht meist so aus:

  • Mehrfacherfassung und/oder Copy-Paste,
  • inkonsistente, teils widersprüchliche Stände zwischen den Medien,
  • fehlende Sprachversionen in einigen der Medien,
  • Verzögerungen und Koordinationsprobleme zwischen den Medien,
  • detaillierte Produktinformationen sind im Web nur als PDF verfügbar (Lokale Suchmaschine, Google, User Experience, etc.).

 

Aus diesen Erfahrungen heraus haben wir unser neues Produkt ContentConnect entwickelt. Mit ihm schaffen wir eine konfigurierbare Schnittstelle, um die Informationen aus der Technischen Redaktion an fast beliebiger Stelle automatisiert einbinden zu können. Zu den Details des ContentConnect und konkreten Einsatzbeispielen lassen wir demnächst einen eigenen Beitrag folgen.

Pluralis Maiestatis – lateinische Fremdwörter auf -us

Wie jetzt?

Wie jetzt? – Unklarheiten gab es wohl bereits im Mittelalter. Eigenes Foto.

Nachdem mir immer wieder und aus allen Richtungen Stati um die Ohren fliegen, und ich kürzlich mit umfangreichen Textkorpi konfrontiert wurde, möchte ich unser Blog zum beruflichen Schreiben einmal dazu hernehmen, meinen inneren Klugscheißer unverblümt nach außen zu kehren. Auch wenn ich mich damit als Informatiker zwischen all den Linguisten und Redakteuren auf ganz dünnes Eis wage.

Die folgende Liste enthält Beispiele für die unterschiedlichenauf -us endenden Deklinationen im Lateinischen, die sich in Form von Fremdwörtern bis ins heutige Weiterlesen

Adobe PhoneGap – die wesentlichen Fakten

Desktop-Telefon

PhoneGap – nichts fürs Tastentelefon

PhoneGap ist ein kostenloses Opensource-Tool, mit dem sich in HTML geschriebene
Web-Apps via Kommandozeile in native App-Container verpacken lassen. PhoneGap bringt außerdem Javascript-Erweiterungen mit, um in der Web-App auf Gerätefunktionen wie GPS oder Kamera zuzugreifen.

Dieses Vorgehen bringt gegenüber tatsächlicher nativer Entwicklung einige Vorteile mit sich: Weiterlesen