venerdì 9 agosto 2013

Dalla scrittura monolitica alla scrittura modulare: DITA overview (dal blog di Petra Dal Santo)

Da un po' di tempo stavo preparando un lungo post per offrirvi una visione generale e completa su DITA (Darwin Information Typing Architecture), uno degli standard più importanti per la strutturazione dei contenuti tecnici.

Ma all'inizio della settimana mi sono accorto che Petra Dal Santo, sul suo blog, aveva pubblicato un ottimo articolo sull'argomento, sollevandomi dal gravoso incarico di terminare la mia fatica!

E in onore al principio del "riuso dei contenuti", vi invito a leggere il suo lavoro, molto ben realizzato.

DITA nasce nella pancia di IBM e viene poi "regalato" alla comunità "open" come standard OASIS.
IBM, fin dall'inizio degli anni '90 del secolo scorso, si trovò a dover gestire migliaia di manuali, con una rilevante percentuale di ripetizione dei contenuti. Come razionalizzare tutto il ciclo di sviluppo e produzione della manualistica, migliorando la qualità dei contenuti, abbattendo i costi e i tempi di realizzazione? La risposta fu DITA, una metodologia basata sullo standard XML che consente di realizzare contenuti ri-usabili e topic-oriented.

Vi rimando al lavoro di Petra per una panoramica di tutte le caratteristiche salienti e mi limito ad una considerazione "filosofica".

Da molti anni, anche tra coloro che apprezzano DITA, si discute sulla sua effettiva "semplicità d'uso".

Io non utilizzo DITA per produrre la documentazione tecnica di CrossIdeas, l'azienda in cui lavoro. E il motivo è semplice.

Lo sforzo iniziale che si richiede per produrre documentazione secondo le regole di DITA è molto elevato ed è giustificabile solo se:

  • i volumi di documentazione da produrre sono notevoli;
  • la % di ripetizione dei contenuti è apprezzabilmente congrua e costante nel tempo;
  • si è ragionevolmente certi che tali parametri rimangano invariati nel medio-lungo periodo (alcuni anni).
Inoltre, è altamente improbabile che siate in grado, al primo progetto, di mettere su un processo di authoring e publishing "DITA-based" se non vi affidate alla consulenza esterna di professionisti esperti, che possano fornirvi un minimo di formazione di base e vi possano aiutare ad avviare i necessari processi.

In altri termini, DITA è una straordinaria metodologia per le esigenze di IBM (che produce i suoi manuali con questo standard) e per altre grandi aziende che producono tecnologia, ma dubito che una piccola/media impresa  possa investire su DITA per produrre i suoi 15-20 manuali, che descrivono prodotti che cambiano rapidamente nel tempo.

Ma questa è solo la mia opinione. Aspetto le vostre indicazioni.

Condividi


Articoli correlati per categorie



4 commenti:

Petra Dal Santo ha detto...

Buongiorno Alessandro!
Molte grazie per la tua segnalazione!
Sono d'accordo con le tue osservazioni. Sia l'apprendimento di DITA, che l'utilizzo di tool come XMetal non sono semplici e quindi consigliabili solo nelle condizioni che giustamente sottolinei.
Penso comunque che per vari motivi sia importante tenere d'occhio DITA:
- Disporre di un tool di publishing open source e multiformato come DITA Open Toolkit è attraente: un unico strumento standardizzato per produrre una grande varietà di formati per carta, web, help online, ecc. con la possibilità di personalizzare la resa grafica in modo relativamente facile;
- Aziende che lavorano con l'estero, in particolare con gli USA, ma anche la Germania e il mondo anglosassone possono essere sollecitati dai loro clienti a fornire documentazione in standard DITA;
- Quando anche l'Italia fornirà percorsi formativi specifici per technical communicator, è probabile che DITA sarà materia di insegnamento, perché è comunque uno standard "universale" (cioè non legato specificatamente a un settore industriale) e open source.
A presto, buona giornata e buon inizio di questa settimana ferragostana, ciao,
Petra

Alèxandròs ha detto...

Concordo su ogni punto, anche se sono particolarmente scettico sull'ultimo: un percorso formativo completo e articolato è ancora un miraggio in Italia. Tieni anche presente che il mio punto di vista è quello di un com. tec. che gestisce un piccolo team di documentazione che lavora in una piccola impresa e produce la doc aziendale al suo interno. Se invece un'azienda decide di produrre la propria doc in outsourcing, affidandosi ad un'azienda specializzata, allora cambia il contesto a alcune delle difficoltà a cui accennavo, per un approccio DITA-based, vengono in gran parte appianate.

Anonimo ha detto...

Mi inserisco nella discussione perché prima di affidarmi e promuovere Information Mapping sono stata in dubbio se approfondire DITA oppure no. In STC (http://www.stc.org) DITA è stato argomento del girno per diversi anni.

DITA, è uno "standard" basato su una forte tecnologia. Aiuta soprattutto a rendere coerente documentazione scritta da più persone, dove occorre annullare la capacità individuale di stabilire formati e organizzare il contenuto.
È molto costoso implementarlo e non offre ai redattori un metodo per analizzare le informazion che vogliono scrivere.

Information Mapping è al contrario un metodo che produce uno "standard". Se "sotto" un documento Information Mapping mettessimo del codice XML, ecco che avremmo una struttura per i redattori.

Sul web trovate diverse discussioni sulle due pratiche..qui per esempio trovate il confronto proposto da Information Mapping:
http://www.writec.com/cms-per-manuali-testi-tecnici.asp?zona=servizi

Per esempio noi usiamo Information Mapping, ma raramente riusciamo in un CMS a gestire l'unità minima di informazioni (block). Quella sarebbe la cosa più opportuna in presenza di output di diverso genere (es.: brochure e schede tecniche, pagine web, manuali). Arriviamo a quindi a gestire un insieme di unità minime (map), perché spesso le aziende lavorano in "silos": il marketing usa un CMS per i cataloghi, InDesign per le brochure e il reparto di redazione un altro CMS per i manuali...

Alèxandròs ha detto...

Vilma, grazie per il tuo contributo. Hai sintetizzato più efficacemente di me il senso delle mie perplessità su DITA. Io mi fermo molto prima rispetto alle ottime considerazioni specifiche che ci hai offerto: se i volumi di documentazione da gestire non raggiungono almeno le 15-20.000 pagine "tradizionali" equivalenti e se il team di documentazione non è molto numeroso, percorrere l'impervio sentiero che porta a DITA mi sembra veramente uno sforzo sovradimensionato. Non cito nemmeno la compessità semantica di DITA, con circa 200 elementi/tags da gestire. Infine, capisco il punto di vista di Petra, che non può non porsi l'obiettivo della gestione di contenuti DITA-based. Se IBM usa DITA per produrre i migliori manuali del mondo ICT (questa è la mia opinione) un motivo ci sarà, ma IBM è una multinazionale e in tal caso solo una standardizzazione imposta "manu militari" può produrre risultati sia sul piano qualitativo che su quello quantitativo.

Posta un commento