giovedì 10 aprile 2014

La Ricerca Italiana nel campo della Comunicazione Tecnica: Marrying Technical Writing with LRT

La mia  amica Petra Dal Santo mi ha segnalato una bella notizia e io la condivido con voi.
Il 27 Maggio 2014 a Reykjavik (Islanda), in occasione del:

LREC Workshop W2: Controlled Natural Language Simplifying Language Use

...nell'ambito della 9a edizione del Language Resources and Evaluation Conference (26-31 Maggio), un gruppo di ricercatori italiani del CNR presenterà un documento intitolato:

Marrying Technical Writing with LRT

... ove l'acronimo LRT sta per Language Resource and Technologies.
Se volete scaricare una preview del documento, potete cliccare su questo link.

I protagonisti di questo lavoro sono Giovanni Antico (S.Te.L S.r.L e socio COM&TEC), Valeria Quochi e Monica Monachini (Istituto di Linguistica Computazionale - CNR) e Maurizio Martinelli (Istituto di Informatica e Telematica - CNR).

Nel campo della Comunicazione Tecnica è sempre più cruciale il tema di come integrare gli aspetti metodologici nella definizione e nella strutturazione dei contenuti con gli aspetti linguistici e le relative tecnologie, in special modo per quanto riguarda le problematiche di traduzione dei contenuti.

Su questo campo di gioco si intrecciano diverse esigenze.

Da una lato normative spesso molto stringenti, che obbligano i produttori a tradurre la documentazione di prodotto in molte lingue, con ovvi problemi di costi ed annessa qualità della traduzione, che se non verificata potrebbe rendere il prodotto di difficile utilizzo o in alcuni casi addirittura indurre il cliente in un uso scorretto e pericoloso del prodotto stesso.

Dall'altro il tentativo di razionalizzare questa attività di traduzione con strumenti e teconologie sempre più
automatizzate ma "intelligenti", in modo da ridurre i costi generali ma senza perdere di vista le esigenze di chiarezza ed esattezza che la documentazione tecnica richiede e che si ottengono attraverso l'uso appropriato degli attributi e delle regole di una lingua.

E' un campo molto affascinante che non mi appartiene in maniera "nativa" (io sono un ingegnere e la mia formazione è tecnica, non sono un linguista), ma leggerò con attenzione questo lavoro e vi esorto a fare altrettanto.

E' comunque una bella notizia sapere che il CNR ha dedicato tempo e lavoro a questo tema.

Come sapete, ho scritto molti articoli sul fatto che da noi non esista un percorso di formazione definito e strutturato per la professione del Comunicatore Tecnico, come accade invece nei paesi anglosassoni.

C'è moltissimo da costruire in Italia in questo senso e credo che ognuno debba portare il proprio mattone, come può. Io lo faccio dal 2009 con questo blog, altri colleghi, come Petra, in altri modi.

Giovanni, Valeria, Monica e Maurizio porteranno "il loro mattone" anche in Islanda e noi faremo il tifo!

In bocca al lupo!


Leggi questo articolo...

giovedì 13 marzo 2014

Il 31-3-2014 a Prato - Realizzare un Help OnLine: concetti, strumenti, esempi

Nell'ambito delle attività di formazione proposte da COM&TEC per la prossima primavera, ci sarò anche io, con un corso di base in cui cercherò di illustrare i concetti fondamentali per realizzare un Help On Line.

L'appuntamento è a Prato, il prossimo 31 Marzo, in Via Valentini 14 c/o Palazzo dell’Industria.

Il corso si rivolge anche a comunicatori tecnici molto esperti ma che fino ad ora hanno avuto come "media" prevalente il documento stampabile/cartaceo e che desiderano avere una prima presa di contatto con il mondo delle Guide OnLine.

Tutte le informazioni del corso le trovate sul sito della COM&TEC.

In 7 ore molto "dense", proverò a dare una panoramica essenziale ma completa di tutti gli elementi che devono essere valutati quando ci si accinge a progettare un HOL.

Questi strumenti, tradizionalmente legati al mondo delle applicazioni software, sono destinati a diffondersi massicciamente in tutti gli ambiti in cui le informazioni fluiscono attraverso pagine Web, App eseguite su smartphone e tablet e, più in generale, in tutte le modalità "OnLine" con le quali siamo sempre più coinvolti, giorno dopo giorno.

Il nostro "essere OnLine" sta cambiando il modo in cui desideriamo ottenere le informazioni: in qualche modo, non siamo più noi che andiamo a cercare le informazioni, ma desideriamo sempre di più che sia "l'informazione a cercare noi", accompagnandoci in maniera "mirata" e "contestualizzata" rispetto al compito che dobbiamo portare a termine "in questo momento".

Tutto ciò proverò a spiegare durante questo corso di base, anche con esempi pratici effettuati con l'ausilio di MadCap Flare, prodotto leader di mercato.

Spero di vedervi a Prato il 31 Marzo.
Ciao.

Leggi questo articolo...

martedì 11 marzo 2014

Dal "monolite" ai "moduli" ovvero come definisco i miei Topic: seconda parte

Il Topic è un segmento di contenuto autosufficiente, tale da poter essere aggregato ad altri topic per dare vita a contenuti più articolati.

Le dimensioni o "granularità" di un Topic sono molto variabili: potrebbe essere un intero capitolo, un singolo paragrafo, una tabella o un frammento di testo anche di poche righe.


Il dimensionamento di un Topic può dipendere da diversi aspetti.

In generale, un Topic dovrebbe essere caratterizzato da almeno una (o più) delle seguenti proprietà:
  • chiusura rispetto ad un preciso tema
  • potenziale riuso
  • appartenenza ad una classe generale
  • derivare dalla composizione di Topic "chiusi"
Un Topic è "chiuso" se può essere considerato a se stante, singolarmente, ed è in grado di esprimere compiutamente il senso del proprio contenuto.

TOPIC A
 
Se questa sequenza operativa è riutilizzabile anche in altri contesti, il Topic oltre ad essere "chiuso" è "riusabile", quindi possiede 2 delle 3 proprietà sopracitate.

TOPIC B
 
Questo Topic è chiuso ma potrebbe essere spezzato in due Topic di granularità minore, entrambi chiusi. In generale, è sempre opportuno ridurre al minimo possibile la granularità.
TOPIC C

Questo Topic non è "chiuso", perchè fa riferimento al concetto di Accounts, non espresso esplicitamente nel TOPIC C. In generale, sarà possibile esprimere una o più RELAZIONI tra un certo Topic ed altri Topic.

TOPIC D
Questo Topic potrebbe essere collocato nella "classe" dei Topic relativi alle "convenzioni redazionali" della documentazione aziendale. La classe di appartenenza di un Topic può essere definita in base a diversi criteri.

In generale, definiamo classe è un insieme omogeneo di elementi.

Per esempio in DITA distinguiamo tra 3 classi principali:
  • Concept Topic (concetti)
  • Reference Topic (ad esempio, una tabella)
  • Task (ad esempio, la descrizione step-by-step di una certa operazione)
Esistono anche altre metodologie che ci suggeriscono classificazioni diverse, come Information Mapping, Functional Design o S1000D.

Come sempre, non esistono in assoluto metodologie migliori di altre, ma il punto da cogliere è che se operiamo una classificazione dobbiamo essere coerenti con la classificazione scelta, perchè da questa deriva una proprietà fondamentale nella definizione dei Topic sui quali poi costruiremo il nostro nuovo modo di produrre contenuti tecnici.

Nel prossimo post vedremo come:
  • definire relazioni tra i Topic
  • aggregare diverse tipologie di Topic per definire contenuti complessi in modo efficente

Leggi questo articolo...

mercoledì 26 febbraio 2014

TC Europe Colloquia - 25/4/2014 in Provenza: ci sarò anche io

Il prossimo 25 Aprile 2014, ci sarà l'edizione annuale del TC Europe Colloquia ad Aix-en-Provence.


Stimolato da un invito ricevuto dalla dott.ssa Flacke, in occasione della conferenza di Bologna per il decennale COM&TEC, ho presentato un paper che, bontà loro, è stato giudicato interessante.

Quindi in Provenza ci sarò anche io, con un intervento intitolato:

Skills and Tools for Technical Communicators in Web 2.0 era

Le precedenti edizioni sono state organizzate a Parigi (2010), Bruxelles (2011), Aveiro (2012) e Bruxelles (2013).

TC Europe è una delle maggiori organizzazioni europee per la promozione della professione della Comunicazione Tecnica. La sua mission è delineata di seguito:
The objectives of TCeurope are:
  • to represent our members at the European level;
  • to improve the quality of technical documentation in general;
  • to promote a more intensive exchange of information and knowledge between specialists in technical communication in Europe;
  • to standardize qualifications for technical communicators in Europe and to improve vocational, academic and further training in all European countries;
  • to develop and share a European market for jobs and services in technical communication;
  • to promote and actively support societies for technical communication in those European countries where national societies are still lacking or where existing organizations need assistance.

 
Leggi questo articolo...

domenica 16 febbraio 2014

Dal "monolite" ai "moduli", ovvero come definisco i miei Topic: prima parte

Fino ad ora ho cercato di spiegare i vantaggi implicati da una produzione della documentazione imperniata sulla modularità dei contenuti, abbandonando un approccio "Word based" o, in più generale, rifuggendo da qualsiasi strumento WYSIWYG (What You See Is What You Get).


Tengo a precisare che questi vantaggi non appartengono all'empireo delle MIE OPINIONI soggettive, non sono concetti contrattabili, sono elementi che possono essere QUANTIFICATI sul piano economico.

In uno dei prossimi post tornerò a tirare fuori "i numerelli" che supportano queste affermazioni, ma allora sorge una domanda semplice:

Perchè non scriviamo documentazione nel modo giusto e si continua a farlo nel modo sbagliato?

Semplicemente perchè il 90% delle aziende (e scrivo 90 perchè sono ottimista), NON CONOSCE le metodologie, gli strumenti, i protocolli, le tecnologie che consentirebbero vantaggi economici non banali.

Dobbiamo avere contenuti modulari, topic-based, riusabili, perchè solo in questo modo possiamo:
  • pubblicare contenuti per documenti diversi, in formati diversi e per media diversi;
  • legare i contenuti modulari secondo schemi diversi per contenitori diversi;
  • importare/ri-definire/integrare contenuti diversi provenienti da sorgenti diverse;
  • usare Templates e regole per guidare più redattori verso la produzione di contenuti coerenti e consistenti con le policy aziendali;
  • scambiare contenuti definti attraverso tecnologie standard per abbattere i costi di gestione;
  • recuperare efficentemente le informazioni;
  • tradurre efficentemente i contenuti in diverse lingue.
Su alcuni di questi aspetti mi ero già espresso, ma è bene puntualizzare con maggiori dettagli questi elementi, come farò nei prossimi articoli.

Ora però facciamo un passo indietro. Ormai siamo convinti di dover passare "dal monolite" al "modulare".


Ma come? Con quale criterio "spezziamo il monolite"? Come riorganizziamo i contenuti per seguire un approccio topic-based? Che caratteristiche dovranno avere i nostri topics?

C'è da divertirsi! Alla prossima!





Leggi questo articolo...

domenica 2 febbraio 2014

Dalla scrittura monolitica alla scrittura modulare, ovvero lavorare "a strati"

Nel post precedente ho provato a chiarire definitivamente un aspetto fondamentale nello sviluppo della documentazione modulare, relativo al disaccoppiamento tra lo strato dei contenuti e lo strato della loro rap-presentazione, attraverso il concetto di "foglio di stile" CSS (Cascading Style Sheet) ben noto ormai da alcuni anni a coloro che si occupano di contenuti per il Web.

Questi due strati sono INDIPENDENTI.

Quindi posso, con N diversi CSS, fornire N distinte rap-presentazioni formali/editoriali SENZA MODIFICARE I CONTENUTI. Quando dobbiamo esportare i nostri contenuti verso l'esterno, ci possono essere altri "livelli di formalizzazione" che possono entrare in gioco.

Il primo livello è rappresentato dalla scelta del CSS.

Un altro livello è dettato dal FORMATO di output che vogliamo ottenere (ad esempio, un PDF, un DOC o un formato Web, come protrebbe essere Web Help o HTML5).

Se poi nel secondo livello scegliamo un formato Web, ad esempio nel caso di un Help on Line (HOL) in formato HTML5, allora dovremo andare a gestire anche il "look&feel" o "skin" di questo oggetto.

Quest'ultimo livello può risultare fondamentale, ad esempio, quando è necessario "brandizzare" un HOL con il logo e i colori aziendali del vostro cliente o quando si devono introdurre o mascherare una serie di elementi nell'architettura dell'HOL.

Senza entrare nei dettagli di tutti questi aspetti, possiamo però già osservare come il principio della "modularità" e "dell'indipendenza tra diversi strati" attraversa più ambiti del processo redazionale dei contenuti tecnici.

Qui mi riallaccio alla mia tesi per cui oggi non si può parlare più di "technical writer" come colui che opera solo e soltanto sui contenuti "puri", ma di "technical communicator" con uno skill estremamente composito e multidisciplinare, perchè egli deve poter gestire tutti gli aspetti di quel processo editoriale che porta a formalizzare contenuti tecnici nella modalità adatta all'utente target.

Quindi tutto si lega: non si può parlare di documentazione modulare se non parliamo di CCMS, cioè degli strumenti che consentono di manipolare TUTTI GLI STRATI che intervengono nel processo redazionale. E non si possono gestire i diversi strati se non si conoscono le metodologie, le tecnologie e gli standard coinvolti.

Il concetto da focalizzare è, in estrema sintesi, il seguente: al termine di un processo editoriale che si basa sul riuso di contenuti modulari, il "documento" finale sarà dato dalla "sovrapposizione" di diversi "strati/elementi" INDIPENDENTI che vanno a "vestire" i contenuti "puri". Leggi questo articolo...