Augmented Reality is out - content delivery portals are in?

This blog post is a call for a new mindset for providing information.

The photo shows a person wearing data glasses. The person looks at the viewer and stretches his hands forward.

In a recent article, there was talk that after initial euphoria, Augmented Reality had not arrived in technical documentation. Instead, companies increasingly relied on videos and content delivery portals to distribute information. Cause for a few thoughts on information distribution requirements.

What is it about?

Yes, it is quite true and is in line with what we also discussed in our Meetup #4: Augmented Reality (AR) has not arrived in everyday life, especially with regard to technical documentation - or should we better say: not yet arrived?

Even if it is true that AR is not a use case for technical documentation, it is therefore correct to say: We don't deal with that anymore, we rely on videos and content delivery portals?

Deploy videos in content delivery portals instead of using Augmented Reality? Is this the right question for alternatives when it comes to information provision?

Content Delivery Portals (CDP)

There is nothing fundamentally wrong with content delivery portals. After all, they are also a use case of c-rex.net IDS and are used to map technical documentation on the web. Regular readers our blog know that our approach goes far beyond bringing PDF documents to the web in HTML5 format, and finding topics using metadata. We are all about integrating technical documentation.

Content delivery portals are definitely an advance over PDF. However, many implementations we have seen so far do not really go beyond the document approach. The metadata there is limited to the topic Assignment of a product hierarchy to a document. In advanced stages, the target group may be differentiated at the document level.

This brings us to Google and YouTube. But, as in PDF, we are still document-oriented; from creation to delivery to users.

And what are we supposed to do with Augmented Reality now? Nothing! Or is it?

Of course, Augmented Reality (AR) or even Virtual Reality (VR) is far from a technical documentation application in many cases. However, depending on the use case, the use of AR/VR and the integration of content from technical editing does make sense in individual cases.

Even if AR/VR is not an issue directly, the requirements that AR/VR places on the preparation of content very much are.

In fact, when we look at the requirements for data and processes, we find a starting point that actually forces us to deal intensively with the topics of AR and VR in technical documentation, just on a different level.

Data requirement

When we look at different videos about Augmented Reality use cases on YouTube, we notice one thing: we need very small fragments of content to be displayed on the glasses. This content must also be identifiable and provided by software on the device and/or in the cloud.

Individual action steps and warnings must be identifiable for AR/VR to work. In many cases, a decision tree must be in place for this.

Aren't these the same, or at least similar, requirements for making content available to a chat bot?

So AR/VR forces us to become more granular in delivering content, to deliver smaller units.

Doesn't this requirement also exist in general when you want to provide the right information at the right time in the right quantity? Think, for example, of cases such as predictive maintenance or intelligent fault management, as we have already outlined in our HOMAG use case.

We need to make content identifiable via metadata. Our content needs to be delivered in bites, in units of meaning, depending on identified use cases.

Requirements for the processes

Requirements for AR/VR also have an impact on the processes in the documentation and even in the company, right through to the customers.

The requirements for AR/VR force us to think in terms of a continuous delivery process. Thus, we do not deliver documents but individual content components. These are only compiled as needed in a specific use case or situation. In the future, we no longer publish, we deliver! And in this thinking, a content delivery portal or even the PDF is just one of many use cases.

But even if all this is not yet convincing, let's consider the following case: In development and design, many companies are running campaigns to bring the user closer to the products and the company.

To this end, content is developed from time to time bypassing the established processes of technical documentation.

At the latest, this should give us pause for thought, as this approach negatively affects the quality of the content provided!

What is needed instead is an end-to-end process that ensures that content is delivered throughout the company in line with the target group's information needs. Already at the creation stage, care must be taken to ensure that this is automated and reproducible.

Let's just change our mindset!

AR and VR are certainly not the main topics we have to worry about in technical documentation at the moment. But who tells us that tomorrow we will not be in the position of having to serve the demands placed on us as a result? And even if that never happens, we already have sufficient requirements to organize our data and processes differently than before. We need to get away from this PDF mindset.

PDF thinking does not refer to the format or the desire to print documents. This is also a legitimate requirement in digitized processes. PDF thinking means thinking in terms of documents, as is also implemented in many cases in content delivery portals.

Instead, we have to think in terms of Topics or even Fragments. This is certainly one of the reasons for the iirds:Topic and iirds:Fragment classes in the iiRDS standard. Topics and fragments must become identifiable - or better - findable.

And these are exactly the requirements for technical documentation that AR and VR are putting in the room. And that is precisely why we need to address these issues - albeit in a somewhat more abstract way.