Nel post precedente, abbiamo iniziato a concepire l'idea che possano esistere, in qualche modo, i "contenuti puri", modulari, scorrelati da una qualche forma. Ma ora come la sfruttiamo questa idea?
Per entrare nel vivo, immaginiamo un caso d'uso concreto.
Abbiamo un prodotto generico, che deve essere accompagnato da un set di documenti di vario tipo. Poniamo che il numero complessivo di documenti sia pari a 12.
In tutti questi documenti potrebbero esistere dei contenuti informativi condivisi. Ad esempio, il Glossario dei termini tecnici e degli acronimi. Oppure la Bibliografia. O magari la definizione delle Licenze di parti specifiche contenute nel prodotto ma realizzate da terze parti.
Per qualche motivo, tutte queste parti devono essere presenti in tutti i 12 documenti.
Nella figura seguente, identifichiamo il Glossario con il rettangolo rosso, la Bibliografia con quello giallo e le Licenze con quello verde:
Dovendo modificare il Glossario, la Bibliografia e i termini delle Licenze, se tali elementi sono immersi in 12 doc monolitici, bisogna realizzare ALMENO 3 modifiche in 12 documenti distinti, per un totale di 36 modifiche "fisiche" distinte.
Ora immaginiamo che questi 3 elementi informativi siano 3 elementi modulari, indipendenti, scorrelati dal contesto in cui dovranno essere collocati. E che siano memorizzati in un Data Base, dove questi contenuti possono "vivere" in quanto contenuti "puri", scorrelati da altri vincoli.
Se li concepiamo così, dobbiamo fare soltanto 3 modifiche, uno per ogni "blocco rettangolare"!
I contenuti aggiornati verranno poi "propagati" in qualche modo, che vedremo la prossima volta, nei 12 documenti che ci servono. Ma ora quello che importa sottolineare è che siamo passati da 36 modifiche "fisiche", a sole 3 modifiche, una per ogni blocco informativo.
Ora la prossima domanda è: se invece di 12 documenti dovessi aggiornare questi contenuti in 120 documenti diversi, quante modifche dovrei apportare? SEMPRE E SOLO 3!
Dove sta il trucco? In tre passaggi concettuali fondamentali:
- abbiamo estratto i moduli dal documento monolitico;
- li abbiamo messi in un DB centralizzato, per implementare una filosofia "single source";
- abbiamo "scorrelato" la modifica del generico modulo dalla sua collocazione all'interno di N documenti distinti.
Molti, ma almeno uno lo possiamo "vedere" subito, aiutandoci con la figura seguente:
La figura forse vi farà venire in mente il Lego, un gioco per bambini che noi ultra-quarantenni (sob!) ricordiamo bene. Ecco, direi che tutta questa roba ha molte idee in comune con il Lego e i suoi famosi mattoncini.
Se abbiamo un DB di contenuti indipendenti, li possiamo "riusare" in documenti diversi, ove in ogni documento i suddetti contenuti possono essere eventualmente "montati" anche in modi diversi, come si intuisce dalla figura, dove sono stilizzati 4 documenti diversi.
Al prossimo post, per vedere altri vantaggi di questo approccio.
3 commenti:
Buon pomeriggio Alessandro, avevo letto i due post precedenti sul passaggio dalla scrittura monolitica a quella modulare, ma questo mi ha colpito particolarmente per la chiarezza con cui esponi concetti e vantaggi della separazione fra contenuto e forma, della gestione univoca dei contenuti e del loro riutilizzo.
Nella nostra esperienza vi sono altri due termini chiave, sui quali forse tornerai nei tuoi prossimi post:
- granularità dei contenuti
- marcatura multidimensionale dei contenuti.
La granularità è importante, perché determina il livello di aggregazione con cui possiamo riprendere un contenuto (il livello può essere, per esempio, un capitolo, un paragrafo, un pezzettino di frase, un termine del nostro glossario aziendale, ecc.). Dobbiamo quindi definire per ogni contenuto il livello adeguato di granularizzazione, sia per poterlo gestire agevolmente, sia per poterlo riutilizzare con efficacia.
La marcatura multidimensionale è importante, perché il meta-descrittore, che ci dice in quali contesti riutilizzare un frammento di contenuto (un modello di macchina, un insieme di codici della distinta base, un mercato, un destinatario della comunicazione tecnica, ecc.).
Si tratta di temi, che mi piacerebbe approfondire con te, proprio perché stanno a cavallo fra technical writing e software CMS a supporto del processo di redazione e traduzione.
Grazie per questo bel post e a risentirci presto! Ciao,
Petra
KEA s.r.l.
Ciao Petra. Hai anticipato due temi che avrei trattato nei prossimi articoli. Purtoppo sono "asfaltato" di impegni lavorativi e ho dovuto interrompere il flusso di post che avevo preventivato. Tieni presente che questi temi sono per lo più sconosciuti anche in realtà aziendali medio-grandi, almeno in Italia, e a maggior ragione nelle piccole realtà, quindi l'impostazione che sto adottando è di tipo introduttivo/divulgativo per far capire la valenza di questa impostazione. Ovviamente, in quest'ottica non posso, almeno per ora, entrare in dettagli "troppo verticali" e tecnici, che solo una professionista molto esperta come te potrebbe apprezzare. Credo che ci sia molto da "seminare" a livello di cultura di base, per far capire i grandi vantaggi di questa filosofia, rispetto all'approccio tradizionale.
Per il resto, come sai, sono sempre aperto per eventuali "contaminazioni" finalizzate a dare sempre maggiori e migliori informazioni sui temi della comunicazione tecnica, anche disponendo solo di questo semplice blog, al quale ultimamente riesco a dedicare pochissimo tempo. A presto.
Ciao Alessandro, ti ringrazio davvero per la tua risposta e, come ti dicevo, apprezzo proprio il taglio introduttivo dei tuoi post. Qualche giorno fa mi sono stupita, quando un nostro cliente mi disse, che in un corso di una quarantina di redattori tecnici, solo due o tre avessero mai sentito parlare di CMS! A riprova del fatto, che il lavoro di "alfabetizzazione di base" è fondamentale, come giustamente sottolinei. A risentirci presto e buon lavoro!
Posta un commento