Dlaczego polegamy na iiRDS i c-rex.net IDS dla naszego bloga?
Sytuacja początkowa
Do tej pory nasz blog był generowany jako statyczny HTML ze źródeł DITA. Było dla nas jasne, że to tylko tymczasowe rozwiązanie.
Na długo przed wydaniem nowej wersji naszego bloga zadbaliśmy o to, aby nasze struktury danych, a zwłaszcza metadane w naszej dokumentacji i treści na blogu, były dobrze przygotowane.
Do tej pory nasz blog nie posiadał funkcji wyszukiwania. Z wyjątkiem odsyłaczy, nie było również żadnych powiązań między poszczególnymi postami.
Metadane i relacje między treściami, produktami, firmami lub innymi interesariuszami są naszym zdaniem niezbędne. Dlatego było jasne, że tymczasowy statyczny blog zostanie w przyszłości zastąpiony przez iiRDS i c-rex.net IDS.
A teraz przełączyliśmy ten przełącznik: Pierwszy na świecie system blogowy iiRDS już jest!
Być może zastanawiasz się teraz, dlaczego nie używamy narzędzi takich jak Wordpress lub podobnych systemów do pisania naszych postów na blogu?
Oczywiście tworzenie bloga za pomocą klasycznych systemów jest najłatwiejszym sposobem na pierwszy rzut oka. Ale dla nas istnieje wiele powodów, dla których wybraliśmy inne podejście.
(1) Żadnych silosów - zwłaszcza zewnętrznych.
Gdybyśmy mieli korzystać na przykład z Wordpress, byłoby to rozwiązanie chmurowe. Nasza zawartość byłaby zatem w chmurze, w - przynajmniej w szczegółach - zastrzeżonym formacie danych.
Jeśli chcesz zrobić coś innego ze swoimi raczej nieustrukturyzowanymi informacjami równolegle do publikowania ich na blogu, wiązałoby się to z bardziej złożoną konwersją danych lub nawet złożoną migracją.
Teraz przechowujemy tylko niezbędne dane jako kopię w chmurze, jeśli w ogóle, aby zmniejszyć naszą zależność od systemów. Ponadto, tam gdzie to możliwe, korzystamy również z dostępnych standardów do przechowywania własnych danych.
Podstawowym wymogiem jest zatem zapisywanie treści w neutralnym dla mediów, znormalizowanym formacie, tak aby edycje - a może to być również publikacja Wordpress - były zawsze odtwarzalne.
(2) Powtarzalna zawartość
Kiedy wysyłamy nasze treści do szerszego świata za pośrednictwem publikacji, chcemy mieć pewność, że te opublikowane treści można również opublikować ponownie za naciśnięciem jednego przycisku.
Zmiana środowiska redakcyjnego, w którym tworzymy treści, nie może prowadzić do konieczności ponownego dotykania (migracji) treści.
Nasz system będzie nadal ewoluował. Wiele z nich nie zostało jeszcze wdrożonych w obecnym stanie i będą one wdrażane stopniowo.
Możliwe nowe funkcje zależą od metadanych.
Nie wiadomo jeszcze, jakie zmiany czekają publikację. Czas pokaże, czy na przykład obecna kwestia terminów płci zostanie utrzymana.
Staraliśmy się skonfigurować nasz zestaw danych tak, aby był gotowy na nadchodzące wymagania dotyczące publikacji.
(3) Publikowanie z jednego źródła za pomocą XML
Koncepcja pojedynczego źródła z pewnością może być również wdrożona w Wordpress. W końcu od tego zaczyna się strategia treści.
Na przykład Andreas Zettl udostępnia wtyczkę do Wordpress, która może wyświetlać treści z Wordpress jako profesjonalny plik PDF w oparciu o podejście Print-CSS.
Ale to nie jest nasz świat. Jako XML-Geeks preferujemy przepływy pracy oparte na podejściu jednoźródłowym opartym na XML - w szczególności DITA.
A ponieważ skupiamy się na dokumentacji technicznej, tematy automatyzacji i strukturyzacji danych są częścią naszego DNA. DNA, które jest również potrzebne w digitalizacja horyzontalnej.
Używając XML, spełniamy dwa pierwsze wymagania: nie tworzymy silosów i jesteśmy w stanie odtworzyć dane wyjściowe w dowolnym momencie.
(4) Związki między zawartością
Relacje między treściami to coś więcej niż odsyłacze między poszczególnymi postami.
Są to metadane, które ustanawiają relacje między zasobami wewnętrznymi i zewnętrznymi w czasie wykonywania. Wymagania wykraczają daleko poza to, co zapewnia standardowy system CMS.
Z pewnością można to również jakoś zaimplementować, ale często nie jest to standardowa funkcjonalność i musi być rozwiązana za pomocą wtyczek innych firm lub wewnętrznego rozwoju.
Nasze wpisy na blogu są w dużej mierze poświęcone nam jako firmie i naszym produktom. Nic więc dziwnego, że nasze wpisy na blogu mają również coś wspólnego z informacjami o produktach lub bardziej ogólnie z dokumentacją techniczną.
A co może być bardziej oczywistego niż wykorzystanie obecnie ustalonego standardu iiRDS dla metadanych i relacji między treścią a produktami?
(5) Procesy są najważniejsze i ostateczne
Jeśli uznamy nasz blog za rodzaj dokumentacji technicznej, wymagania wynikają bezpośrednio z tego obszaru.
Oczywiście obejmuje to tłumaczenie, ale także zapewnienie jakości poprzez odpowiednie zarządzanie terminologią, prawidłowe i spójne struktury danych.
W tym celu ustanowiliśmy już odpowiednie procesy dla dokumentacji technicznej, które mogą i będą wykorzystywane bez dalszych ceregieli do tworzenia wpisów na blogu.
W ten sposób zapewniamy płynny proces za naciśnięciem jednego przycisku.
(6) Wreszcie
I wreszcie, co nie mniej ważne, ważne jest dla nas, aby w naszym codziennym życiu zawodowym stosować procesy, które zalecamy naszym klientom w projektach.
Dlatego korzystanie z własnych systemów jest dla nas naturalne i opłacalne. Nie ma nic lepszego dla rozwoju produktu niż bycie swoim własnym klientem.
Wnioski
Musimy zacząć myśleć o naszych treściach jako o części digitalizacja firm i procesów.
Zawartość to nie tylko gotówka od dziś. Jako proces twórczy, żadna sztuczna inteligencja nie stworzy dla nas treści w dającej się przewidzieć przyszłości.
Dostarczanie wartościowych treści naszym klienci i czytelników pozostanie zatem pracochłonne, czasochłonne, a tym samym kosztowne.
Właśnie dlatego musimy przede wszystkim rozbijać silosy, a nie tworzyć nowe.
Podstawą jest Content Management Systemą, w którym treść jest tworzona i zarządzana.
Wszystkie wynikowe formaty wyjściowe, czy to PDF, czy iiRDS, muszą być generowane w sposób powtarzalny.
Nawet jeśli zdecydujemy się dostarczać treści dla innego systemu lub formatu wyjściowego, nie powinno to już być powodem do konieczności dostosowywania lub nawet migracji naszych treści.
Z tych wszystkich powodów potrzebujemy jasnej strategii dotyczącej miejsca i sposobu tworzenia treści.
Widzimy, że krajobraz formatów obecnie się rozwija. Jednym z powodów jest to, że programiści piszą więcej dokumentacji, dlatego jest dużo szumu wokół Markdown i jego pochodnych.
Równolegle redaktorzy techniczni piszą swoje treści w Word, FrameMaker lub w strukturach XML.
Treści są tworzone w różnych obszarach w oparciu o różne systemy i formaty. Może to być całkiem przydatne.
Podejście to musi jednak stać się częścią strategii treści firmy, aby zdefiniować jasne obowiązki i procesy wyjściowe.
Ma to znaczenie nie tylko w przypadku publikacji.
Coraz częściej widzimy, że niegdyś ugruntowane systemy rozpadają się, zwłaszcza w sektorze tłumaczeń, i że każdy sektor robi swoje.
Konsekwencją tego jest nieuchronnie gorsza, bo w większości nieplanowana, jakość tłumaczeń.
Dokumentacja techniczna ma wszystkie te procesy związane z tworzeniem treści, tłumaczeniem i publikacją pod kontrolą od wielu lat.
Wykorzystaj tę wiedzę i zintegruj inne obszary z tymi dojrzałymi i dobrze przemyślanymi procesami.
Chętnie ci w tym pomożemy!