MadCap Central: Einsteigen bitte! 23.11.201603.11.2018 Es geht ein Riss durch die Technische Dokumentation: Applikationen auf der einen Seite, Systemlösungen auf der anderen. Auf der einen Seite stehen die Nutzer der „klassischen“ Werkzeuge der Redaktionsstuben, die Word-User, FrameMaker-Apologeten und die InDesign-Anwender – und auf der anderen Seite die XML-DITA-Verfechter, die mächtige Informationsverwaltungssysteme benutzen wie andere Leute ihren Akkuschrauber. Für die einen bedeutet Dokumentation ein Copy & Paste aller Fehler, aber dafür WYSIWYG, für die anderen trennen die Redaktionssysteme sauber zwischen Inhalt, Form und Struktur. Was für die einen bequem ist und vor allem nachvollziehbar, ist für die anderen kaum zu verwendender Datenmüll, der für jedes Format und jede Ausgabe neu kompostiert werden muss. Wo die einen alle Daten brav auf einer Festplatte halten und schon beim Gedanken an Informationsnetzwerke den kalten Angstschweiß spüren, können die anderen die Informationen nicht früh genug verteilen. Eine geteilte Welt, die sich auch beim Geld unterscheidet: Selbst anspruchsvolle Software für die Bearbeitung umfangreicher Dokumentationen ist heutzutage vergleichsweise günstig zu haben – und sie funktioniert direkt nach der Installation. Redaktionssysteme können das nicht. Sie müssen installiert, konfiguriert und administriert werden, greifen auf Datenbanken zu, die selbst schon ein kleines Vermögen kosten. Selbst wenn das System noch vergleichsweise günstig ist: die Zeit und der Aufwand, der zu treiben ist, bis endlich eine verwendbare Information publiziert werden kann, übersteigt bei Weitem die Ressourcen eines einzelnen Redakteurs oder Dienstleisters. Solche Systeme werden daher fast ausschließlich in großen Unternehmen eingesetzt, in denen Spezialisten damit beschäftigt sind, die Informationsprozesse abzubilden und zu steuern, ohne je einen einzigen Satz zu schreiben. Dort werden dann auch die Vorteile genutzt und benötigt, um beispielsweise direkt den Dokumentationsstatus der Anlage in Indonesien abrufen zu können, oder die Übersetzung ins Xhosa zu überwachen. Die Kleinen können das nicht. Dort hapert es schon beim verteilten Arbeiten. Da muss für jede Grafik beim Kollegen eine Mail geschrieben werden („Hast Du die Grafik schon geschickt?“, „An welchem Abschnitt arbeitest Du gerade?“). Was bei zwei Leuten noch angehen mag (auch wenn es nicht besonders effizient ist), lähmt bei mehr als drei Personen den Prozess bis zum Stillstand („Ach ich dachte, Du hättest…?!“). Man hilft sich dann mit mehren Tools gleichzeitig: eines zum Schreiben, eines für die Grafiken, eines für die Kommunikation, eines für die Planung, eines für die Notizen, … Das Problem haben auch Hersteller wie MadCap erkannt, deren Tool „Flare“ es erlaubt, lokal Dokumente zu erstellen, die sowohl gedruckt als auch online publiziert werden können, die Grafiken, Bilder und auch Filme und Animationen beinhalten und auf Publikationsziel hin maßgeschneidert werden können: Installationshandbuch gedruckt, Netzwerkkonfiguration auf dem Smartphone, Onlinehilfe mit Wartung und Sicherheitshinweisen für die Techniker, Bedienung und Tutorialfilme für die Benutzer – alles aus einer Quelle. Das klingt nicht nur gut, das ist es auch. Aber es fehlt noch etwas: das, was sich neudeutsch Zusammenarbeit nennt: das verteilte Arbeiten im Team, das Zusammenhalten der Informationen zwischen allen Teilnehmern an einem Platz, das gemeinsame Planen und Durchführen von Dokumentationsprozessen. Das, was eben auch die „großen“ Systemlösungen auszeichnet: Workflows, Versionen, Aufgaben, Bearbeitungsstände, etc. Dafür hat sich MadCap nun eine eigene Lösung einfallen lassen: MadCap Central1. MadCap Central Zwar ist das Produkt noch in der Beta, es verspricht aber schon jetzt zu einem zentralen Werkzeug der Dokumentationsprozesse zu werden. Central macht dabei die anderen Tools aus dem hause nicht überflüssig, es ergänzt sie äußerst geschickt und sinnvoll: Central ist die server-basierte Dokumentverwaltung aller Flare-Projekte. Während der einzelne Redakteur seine Dokumente immer noch lokal auf dem Rechner bearbeitet, werden diese nach dem Speichern mit dem Cloud-Server abgeglichen und automatisch eine Mitteilung an den Korrekturleser verschickt, dass dieses Dokument zur Bearbeitung freigegeben ist. Dieser kann es dann wieder mit seiner Version auf dem Rechner synchronisieren, Anmerkungen und Korrekturen hinzufügen und nach dem Speichern wieder zurück in den Kreislauf schicken. Keine Mails, kein zusätzlicher Verwaltungs- und Kommunikationsaufwand. Central übernimmt das. Das ist aber nur der Anfang. Welche Funktionen bereits in der Beta vorhanden sind und wie man sie nutzen kann, wird in den kommenden Folgen beleuchtet. Soviel aber schon jetzt: Technische Kommunikation war noch nie so cool. „Central“ ist hier gleichbedeutend mit „Hauptbahnhof“ ↩Teilen mit:MastodonWhatsAppE‑MailMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … dokumentation redaktion ArbeitDokumentenverwaltungFlare
appseits Smarter mailen mit Spark 09.10.201708.01.2022 Wer ein neueres Gerät mit iOS und macOS besitzt und sich vor allem bei iOS… Teilen mit:MastodonWhatsAppE‑MailMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More
dokumentation Konzeptionelles Arbeiten in der Technischen Dokumentation: Wider die Linearität 03.03.201108.01.2022 Die Technische Dokumentation verlangt Papier. Sie schreit nach Papier, wenn es um die „Unterlagen“ geht,… Teilen mit:MastodonWhatsAppE‑MailMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More
redaktion Multichannel-Publishing: Wir senden auf allen Kanälen! 22.01.201114.12.2017 Und wieder macht ein neues »Buzzword« die Runde: »Multichannel-Publishing«. Ausgerufen von großen Software-Herstellern, soll es… Teilen mit:MastodonWhatsAppE‑MailMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More