Augmented Reality odpada - portale dostarczania treści wchodzą?

O co chodzi?

Tak, to prawda i pokrywa się to z tym, o czym rozmawialiśmy podczas Meetupu nr 4: Augmented Reality (AR) nie pojawiła się jeszcze w codziennym życiu, zwłaszcza w odniesieniu do dokumentacji technicznej - a może powinniśmy powiedzieć: jeszcze się nie pojawiła?

Nawet jeśli prawdą jest, że AR nie jest przypadkiem użycia dla dokumentacji technicznej, słuszne jest zatem stwierdzenie: Nie mamy już z tym do czynienia, ale polegamy na filmach i portalach dostarczających treści?

Udostępnianie filmów w portalach dostarczania treści zamiast korzystania z Augmented Reality? Czy jest to właściwe pytanie dotyczące alternatyw w dostarczaniu informacji?

Portale dostarczania treści (CDP)

Zasadniczo nic nie przemawia przeciwko portalom dostarczania treści. W końcu są one również przypadkiem użycia c-rex.net IDS i służą do mapowania dokumentacji technicznej w sieci. Stali czytelników naszego bloga wiedzą, że nasze podejście wykracza daleko poza przenoszenie dokumentów PDF do sieci w formacie HTML5 i wyszukiwanie tematów za pomocą metadanych. Zajmujemy się integracją dokumentacji technicznej.

Portale dostarczania treści są zdecydowanie lepszym rozwiązaniem niż PDF. Jednak wiele implementacji, które widzieliśmy do tej pory, tak naprawdę nie wykracza poza podejście dokumentowe. Metadane są tam ograniczone do tematu przypisywania hierarchii produktów do dokumentu. Na zaawansowanych etapach grupa docelowa może być zróżnicowana na poziomie dokumentu.

To prowadzi nas do Google i YouTube. Ale nadal jesteśmy zorientowani na dokumenty, jak w PDF, od tworzenia do dostarczania użytkownicy.

A co mamy teraz zrobić z Augmented Reality? Nic! A może jednak?

Oczywiście Augmented Reality (AR) lub nawet Virtual Reality (VR) ) jest w wielu przypadkach daleka od zastosowania w dokumentacji technicznej. W zależności od przypadku użycia, wykorzystanie AR/VR i integracja treści z edycji technicznej ma jednak sens w indywidualnych przypadkach.

Nawet jeśli AR/VR nie jest bezpośrednim problemem, wymagania, jakie AR/VR nakłada na przygotowanie treści, są bardzo istotne.

Rzeczywiście, gdy spojrzymy na wymagania dotyczące danych i procesów, znajdziemy punkt wyjścia, który faktycznie zmusza nas do intensywnego zajmowania się tematami AR i VR w dokumentacji technicznej, tylko na innym poziomie.

Wymagania dotyczące danych

Kiedy patrzymy na różne filmy o przypadkach użycia Augmented Reality rzeczywistości na YouTube, zauważamy jedną rzecz: potrzebujemy bardzo małych fragmentów treści do wyświetlenia na okularach. Zawartość ta musi być również identyfikowalna i dostarczana przez oprogramowanie na urządzeniu i/lub w chmurze.

Poszczególne kroki działania i ostrzeżenia muszą być możliwe do zidentyfikowania, aby AR/VR działało. W wielu przypadkach w tym celu należy wdrożyć drzewo decyzyjne.

Czy nie są to te same lub przynajmniej podobne wymagania, które są stawiane, gdy chcesz udostępnić zawartość botowi czatu?

Tak więc AR/VR zmusza nas do bardziej szczegółowego dostarczania treści, do dostarczania mniejszych jednostek.

Czy ten wymóg nie istnieje również ogólnie, jeśli chcesz dostarczyć właściwe informacje we właściwym czasie i we właściwej ilości? Pomyślmy na przykład o przypadkach takich jak konserwacja predykcyjna lub inteligentne zarządzanie usterkami, jak już opisaliśmy w naszym przypadku użycia HOMAG.

Musimy umożliwić identyfikację treści za pomocą metadanych. Nasze treści muszą być dostarczane w kawałkach, w jednostkach znaczeniowych, w zależności od zidentyfikowanych przypadków użycia.

Wymagania dotyczące procesów

Wymagania dotyczące AR/VR mają również wpływ na procesy w dokumentacji, a nawet w firmie, aż do klienci.

Wymagania dotyczące AR/VR zmuszają nas do myślenia w kategoriach procesu ciągłego dostarczania. Oznacza to, że nie dostarczamy dokumentów, ale poszczególne komponenty treści. Są one kompilowane tylko w razie potrzeby w konkretnym przypadku użycia lub sytuacji. W przyszłości nie będziemy już publikować, będziemy dostarczać! W tym myśleniu portal dostarczania treści lub nawet PDF to tylko jeden z wielu przypadków użycia.

Ale nawet jeśli to wszystko nie jest jeszcze przekonujące, rozważmy następujący przypadek: W zakresie rozwoju i projektowania wiele firm prowadzi kampanie mające na celu przybliżenie użytkownikowi produktów i firmy.

W tym celu treść jest wielokrotnie opracowywana bez uwzględnienia ustalonych procesów dokumentacji technicznej.

Powinno to dać nam do myślenia najpóźniej w momencie, gdy proceder ten negatywnie wpływa na jakość udostępnianych treści!

Zamiast tego potrzebny jest kompleksowy proces, który zapewni dostarczanie treści w całej firmie zgodnie z potrzebami informacyjnymi grupy docelowej. Już na etapie tworzenia należy zadbać o to, aby było to możliwe w sposób zautomatyzowany i powtarzalny.

Po prostu zmieńmy nasze nastawienie!

AR i VR z pewnością nie są obecnie głównymi tematami, o które musimy się martwić w dokumentacji technicznej. Ale kto nam powie, że jutro nie będziemy musieli spełnić żądań, które się z tym wiążą? A nawet jeśli tak się nigdy nie stanie, mamy już wystarczające wymagania, aby zorganizować nasze dane i procesy inaczej niż wcześniej. Musimy odejść od tego myślenia PDF.

Myślenie PDF nie odnosi się do formatu lub chęci drukowania dokumentów. Jest to również uzasadniony wymóg w procesach cyfrowych. Myślenie PDF oznacza myślenie w dokumentach, ponieważ w wielu przypadkach jest ono również wdrażane w portalach dostarczania treści.

Zamiast tego musimy myśleć w kategoriach tematów lub nawet fragmentów. Jest to z pewnością jeden z powodów powstania klas iirds:Fragment iirds:Topic i w standardzie iiRDS. Tematy i fragmenty muszą stać się identyfikowalne - lub lepiej - możliwe do znalezienia.

I to są właśnie wymagania dotyczące dokumentacji technicznej, którą tworzą AR i VR. I właśnie dlatego musimy zająć się tymi kwestiami - choć w nieco bardziej abstrakcyjny sposób.