Tuttavia, per migrare verso un approccio "topic-based", incentrato sul riuso dei contenuti e ottenere tutti i vantaggi che vi ho illustrato, dobbiamo dotarci di strumenti e metodologie che ci aiutino ad ottenere tale risultato.
Ma quali sono le caratteristiche fondamentali di questi strumenti/metodologie?
Nella figura successiva ho provato a mettere insieme alcuni concetti fondamentali, ipotizzando anche una sorta di "flusso" ottimale tra di essi.
Lo schema non pretende di esaurire ogni possibile architettura o casistica.
Tuttavia può essere un buon modello di partenza, ad alto livello, per mettere insieme alcune idee chiave espresse nei precedenti articoli.
Il "cuore" del modello è il Repository centralizzato dei contenuti, suddivisi in "moduli" o topic distinti. Questi elementi, memorizzati in un vero e proprio DataBase, possono essere realizzati e modificati da più autori, in grado di accedere al DB.
La gestione collaborativa dei contenuti, scalabile su N autori, può essere declinata secondo diverse strategie, ma dovrà comunque prevedere strumenti di accesso concorrente e profilato, nonchè la gestione del versioning dei contenuti.
Se i diversi topic vengono memorizzati nel DB secondo un formato "standard" come il formato XML, sarà oltremodo semplice interfacciare tali contenuti con strumenti specializzati per la traduzione multilingua, come i CAT Tools.
Gli stumenti più avanzati presenti oggi sul mercato possono contemplare anche dei CAT Tools direttamente integrati nel modello.
Nel nostro modello è necessario disporre di uno strato in grado di "montare" i contenuti modulari del nostro DB secondo diverse modalità, per ottenere diverse tipologie di documentazione, attraverso dei Template automatizzati.
L'ultimo strato del nostro modello è quello che ci permette di gestire la multicanalità, laddove possiamo ottenere i nostri contenuti in diversi formati (.doc, .pdf, .html, ecc..).
In alcuni prodotti non sempre gli ultimi due strati sono nettamente distinti, ma nel mio modello ho preferito dividere nettamente i 3 elementi di cui dobbiamo sempre tener conto nella nostra strategia di scrittura modulare:
- i contenuti "puri"(nel Repository)
- il modo in cui "li montiamo" insieme (i Template)
- "la forma" in cui li presentiamo
Al prossimo articolo, a presto.
2 commenti:
Ciao Alessandro, buongiorno! Complimenti per il tuo post, sintetico ed esaustivo al tempo stesso. Trovo particolarmente interessante la nota sul layer dei "template automatizzati", fondamentale per realizzare documentazione aderente a normative e standard (sia universali come DITA, che specifici di determinati settori industriali o di singole aziende), preservando la neutralità e quindi la riusabilità dei contenuti. Le condizioni di riutilizzo associate al contenuto e il template dell'output permettono di auto-comporre il documento specifico. Buona giornata e a presto, ciao, Petra
Buongiorno Petra. Questo schema logico nasce da un'attività di scouting in cui ho preso in esame le caratteristiche di diversi prodotti, da quelli free per utenti con esigenza semplici a quelli professionali per le esigenze d utenti "advanced". Come tutti gli schemi logici, emergono gli elementi salienti, che non sono necessariamente TUTTI quelli che servono, ma sono di certo quelli dai quali non si può prescindere. Poi ogni prodotto realizza ogni strato anche con soluzioni molto originali, ma mi premeva fornire nel breve spazio di un post un quadro "visuale" di molti concetti che ho provato ad esporre nei precedenti 4 post. Grazie per l'apprezzamento. A presto.
Posta un commento