Augmented Reality ist out – Content-Delivery-Portale sind in?

Worum geht es?

Ja, es ist durchaus richtig und entspricht dem, was wir auch in unserem Meetup Nr. 4 diskutiert haben: Augmented Reality (AR) ist im Alltag gerade in Bezug auf die technische Dokumentation nicht angekommen – oder sollen wir besser sagen: noch nicht angekommen?

Selbst wenn es stimmt, dass AR keinen Anwendungsfall für die technische Dokumentation darstellt, ist es deshalb richtig zu sagen: Wir beschäftigen uns nicht mehr damit, sondern setzen auf Videos und Content-Delivery-Portale?

Videos in Content-Delivery-Portalen bereitstellen statt Augmented Reality einsetzen? Ist das die richtige Fragestellung für Alternativen beim Thema Informationsbereitstellung?

Content-Delivery-Portale (CDP)

Nichts spricht grundsätzlich gegen Content-Delivery-Portale. Sie sind ja auch ein Usecase von c-rex.net IDS und dienen zur Abbildung der technischen Dokumentation im Web. Regelmäßige LeserLeserinnenLeser und LeserinnenLeser:innen unseres Blogs wissen, dass unser Ansatz weit darüber hinausgeht, PDF-Dokumente im HTML5 Format ins Web zu bringen, und Topics mittels Metadaten zu finden. Es geht uns darum, technische Dokumentation zu integrieren.

Content-Delivery-Portale sind definitiv ein Fortschritt gegenüber PDF. Viele Implementierungen, die wir bislang gesehen haben, gehen über den Dokumentansatz jedoch nicht wirklich hinaus. Die Metadaten begrenzen sich dort auf das Thema Zuordnung einer Produkthierarchie zu einem Dokument. In fortgeschrittenen Stadien wird dann ggf. auf Dokumentebene noch die Zielgruppe unterschieden.

Damit sind wir bei Google und YouTube angekommen. Aber wir sind, wie im PDF, weiterhin dokumentorientiert unterwegs; von der Erstellung bis zur Bereitstellung an AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen.

Und was sollen wir jetzt mit Augmented Reality? Nichts! Oder doch?

Natürlich ist Augmented Reality (AR) oder auch Virtual Reality (VR) in vielen Fällen weit weg von einem Einsatz der technischen Dokumentation. Je nach Usecase macht der Einsatz von AR/VR und die Integration von Inhalten aus der technischen Redaktion im Einzelfall aber doch Sinn.

Selbst wenn AR/VR direkt kein Thema ist, sind es die Anforderungen, die AR/VR an die Aufbereitung der Inhalte stellt, sehr wohl.

Wenn wir uns mit den Anforderungen an Daten und Prozesse beschäftigen, finden wir nämlich einen Ansatzpunkt, der uns eigentlich dazu zwingt, uns in der technischen Dokumentation intensiv mit den Themen AR und VR auseinanderzusetzen, nur auf einer anderen Ebene.

Anforderung an die Daten

Wenn wir uns verschiedene Videos über Anwendungsfälle zum Thema Augmented Reality auf YouTube anschauen, stellen wir eines fest: wir benötigen sehr kleine Inhaltsfragmente, die auf den Brillen angezeigt werden. Diese Inhalte müssen zudem identifiziert werden können und von einer Software auf dem Device und/oder in der Cloud bereitgestellt werden.

Einzelne Handlungsschritte und Warnhinweise müssen für AR/VR identifizierbar sein, damit das funktioniert. In vielen Fällen muss dafür ein Entscheidungsbaum vorhanden sein.

Sind das nicht die gleichen oder zumindest ähnliche Anforderungen, die gestellt werden, wenn man Inhalte einem Chat-Bot zur Verfügung stellen möchte?

AR/VR zwingt uns also, bei der Bereitstellung von Inhalten granularer zur werden, kleinere Einheiten zu liefern.

Gibt es diese Anforderung nicht auch generell, wenn man die richtigen Informationen zum richtigen Zeitpunkt in der richtigen Menge zur Verfügung stellen will? Denken Sie da zum Beispiel an Fälle wie Predictive Maintenance oder bei einem intelligenten Fehlermanagement, wie wir in unserem Anwendungsfall HOMAG schon einmal skizziert hatten.

Wir müssen Inhalte über Metadaten identifizierbar machen. Unsere Inhalte müssen abhängig von identifizierten Anwendungsfällen in Häppchen, in Sinneinheiten, bereitgestellt werden.

Anforderungen an die Prozesse

Anforderungen an AR/VR wirken sich auch auf die Prozesse in der Dokumentation ja sogar im Unternehmen bis hinaus zu KundenKundinnenKunden und KundinnenKund:innen aus.

Die Anforderungen an AR/VR zwingen uns, in einem kontinuierlichen Delivery-Prozess zu denken. Damit liefern wir keine Dokumente sondern einzelne Inhaltsbestandteile. Diese werden erst bei Bedarf so zusammengestellt, wie sie in einem konkreten Usecase oder einer konkreten Situation benötigt werden. Wir publizieren künftig nicht mehr, wir liefern! Und in dieser Denke ist ein Content-Delivery-Portal oder auch das PDF nur einer von vielen Anwendungsfällen.

Aber selbst, wenn das alles noch nicht überzeugt, lassen Sie uns folgenden Fall betrachten: In der Entwicklung und Konstruktion laufen in vielen Unternehmen Aktionen, die den Anwender näher an die Produkte und das Unternehmen bringen sollen.

Dazu werden immer mal wieder Inhalte an den etablierten Prozessen der Technischen Dokumentation vorbei entwickelt.

Spätestens das sollte uns zu denken geben, da dieses Vorgehen die Qualität der bereitgestellten Inhalte negativ beeinflusst!

Benötigt wird stattdessen ein durchgehender Prozess, der unternehmensweit sicherstellt, das Inhalte passend zum Informationsbedarf der Zielgruppe ausgeliefert werden. Schon bei der Erstellung muss darauf geachtet werden, das dies automatisiert und reproduzierbar möglich ist.

Ändern wir doch einfach unser Mindset!

AR und VR sind sicherlich nicht die Hauptthemen, um die wir uns im Moment in der Technischen Dokumentation kümmern müssen. Wer sagt uns aber, dass wir morgen nicht in die Lage kommen, die dadurch gestellten Anforderungen bedienen zu müssen? Und selbst wenn das niemals passiert, haben wir bereits heute ausreichend Anforderungen, unsere Daten und Prozesse anders als bisher zu organisieren. Wir müssen weg von dieser PDF-Denke.

PDF-Denke bezieht sich nicht auf das Format oder den Wunsch, Dokumente zu drucken. Das ist auch in digitalisierten Prozessen eine legitime Anforderung. PDF-Denke meint die Denke in Dokumenten, wie sie eben in vielen Fällen auch in Content-Delivery-Portalen umgesetzt ist.

Stattdessen müssen wir in Topics oder sogar in Fragmenten denken. Das ist sicherlich mit einer der Gründe für die Klassen iirds:Topic und iirds:Fragment im iiRDS Standard. Topics und Fragmente müssen identifizierbar – oder besser – auffindbar werden.

Und das sind exakt die Anforderungen an die technische Dokumentation, die durch AR und VR im Raum stehen. Und genau deshalb müssen wir uns – wenn auch etwas abstrakter – mit diesen Themen auseinander setzen.