Scusate per la latitanza dal blog, ho più di un post in divenire che non riesco a chiudere e a proporvi, ma sono totalmente preso dal "giocattolo nuovo", MadCap Flare.
Sto imparando ad usare questo prodotto e non solo per passione e diletto, visto che dovrò presto mettere in campo un nuovo Help on Line prossimamente.
L'impresa non è banale, visto che solo per la gestione degli stili c'è un manuale di quasi 900 pagine!
Vi farò sapere...
Nel frattempo, vi segnalo uno SPLENDIDO articolo di Petra Dal Santo dal suo blog.
In questo momento, stiamo trattando argomenti analoghi, ma fra di noi non c'è concorrenza, anzi, l'unione fa la forza! E per unione s'intende l'idea di divulgare i vantaggi della pubblicazione di documenti basati su una gestione strutturata e "single source", usando strumenti adatti allo scopo e abbandonando una gestione "artigianale" della documentazione aziendale.
A presto!
Leggi questo articolo...
domenica 16 giugno 2013
sabato 25 maggio 2013
Il prossimo 26 Giugno a Milano, seminario COM&TEC: come cambia la comunicazione tecnica aziendale
Vi segnalo un evento COM&TEC che si svolgerà a Milano il prossimo 26 Giugno, dal titolo:
Come cambia la comunicazione tecnica aziendale: strumenti e processi.
Il programma è interessante ed è una delle pochissime occasioni di confronto su questo tema che possiamo avere sul territorio italiano.
Il tema del resto mi è molto caro, tanto da aver iniziato a scrivere un serie di articoli "di base" per descrivere la logica attraverso la quale si deve migrare da una produzione tradizionale, artigianale, di documentazione "monolitica", ad una produzione incentrata sulla "modularizzazione" dei contenuti e su processi automatizzati.
Per chi è interessato, di seguito i link ai primi 4 articoli della serie:
Dalla scrittura monolitica alla scrittura modulare
E' in fase di sviluppo il 5° articolo, poi altri seguiranno.
In sintesi, direi che quella del 26 Giugno è una bella occasione per una presa di contatto con la necessaria evoluzione dello sviluppo dei contenuti aziendali, che sono sempre più strategici per il successo di un'azienda. Chi può, ne approfitti. Io conto di esserci.
Leggi questo articolo...
Come cambia la comunicazione tecnica aziendale: strumenti e processi.
Il programma è interessante ed è una delle pochissime occasioni di confronto su questo tema che possiamo avere sul territorio italiano.
Il tema del resto mi è molto caro, tanto da aver iniziato a scrivere un serie di articoli "di base" per descrivere la logica attraverso la quale si deve migrare da una produzione tradizionale, artigianale, di documentazione "monolitica", ad una produzione incentrata sulla "modularizzazione" dei contenuti e su processi automatizzati.
Per chi è interessato, di seguito i link ai primi 4 articoli della serie:
Dalla scrittura monolitica alla scrittura modulare
E' in fase di sviluppo il 5° articolo, poi altri seguiranno.
In sintesi, direi che quella del 26 Giugno è una bella occasione per una presa di contatto con la necessaria evoluzione dello sviluppo dei contenuti aziendali, che sono sempre più strategici per il successo di un'azienda. Chi può, ne approfitti. Io conto di esserci.
Leggi questo articolo...
martedì 21 maggio 2013
L'Esattezza secondo Calvino: un insegnamento anche per la comunicazione tecnica
Ho spesso sostenuto che la "scrittura tecnica" è un tipo di scrittura molto specialistica, ma sempre di scrittura trattasi, non nasce su Marte e non è "altro" rispetto alle regole generali, di base, della buona scrittura.
Un calciatore, un pugile o un maratoneta praticano tutti la corsa di fondo, se pur con modalità diverse, perchè la corsa di fondo è un buon esercizio di base per migliorare la resistenza organica di qualsiasi atleta; allo stesso modo, un comunicatore tecnico dovrebbe, di tanto in tanto, riprendere confidenza con i classici.
E la lezione sull'Esattezza di Italo Calvino è particolarmente interessante per un comunicatore tecnico.
Per questo vi segnalo un bell'articolo di Alessandro Lucchini, uno dei pochi "guru" italiani della scrittura su web dai cui scritti molto ho imparato quando, nel 2005, ho iniziato ad occuparmi di comunicazione tecnica ed ho trovato nella Palestra della Scrittura un luogo dove ho rubato/assorbito idee e ispirazioni che spero di aver messo a frutto, almeno in parte.
Lucchini parte dal nucleo della lezione di Calvino sull'esattezza:
...e poi alza lo sguardo su aspetti dell'uso della lingua che sono parte viva anche della nostra quotidianità e che spesso ci sgomentano, come il seguente:
"Per mancanza di moneta divisionale i pazienti solventi sono pregati di presentarsi allo sportello muniti della suddetta."
... e pare che Munch, dopo aver letto questo, abbia dipinto il suo "Urlo"!
Cosa è l'Esattezza per un Com Tec? Per me significa:
1) scrivere tutto e solo quello che serve per comunicare un concetto
2) rafforzare quello che scrivo con supporti visuali (grafici, tabelle, immagini) che facilitino la comprensione del concetto
3) realizzare quanto ai punti 1 e 2 con la massima sintesi e proprietà di linguaggio, semplificando all'osso la struttura della frase
In particolare, estrapolo un brano dal testo originale di Calvino:
"... le lingue naturali dicono sempre qualcosa in più rispetto ai linguaggi formali, comportano sempre una certa quantità di rumore che disturba l’essenzialità dell’informazione...".
In molte occasioni vi ho indicato come abbattere il rumore della comunicazione sia l'aspetto FONDAMENTALE della comunicazione tecnica.
Come vedete, le idee di Calvino possono servire anche per scrivere della buona comunicazione tecnica. Leggi questo articolo...
Un calciatore, un pugile o un maratoneta praticano tutti la corsa di fondo, se pur con modalità diverse, perchè la corsa di fondo è un buon esercizio di base per migliorare la resistenza organica di qualsiasi atleta; allo stesso modo, un comunicatore tecnico dovrebbe, di tanto in tanto, riprendere confidenza con i classici.
E la lezione sull'Esattezza di Italo Calvino è particolarmente interessante per un comunicatore tecnico.
Per questo vi segnalo un bell'articolo di Alessandro Lucchini, uno dei pochi "guru" italiani della scrittura su web dai cui scritti molto ho imparato quando, nel 2005, ho iniziato ad occuparmi di comunicazione tecnica ed ho trovato nella Palestra della Scrittura un luogo dove ho rubato/assorbito idee e ispirazioni che spero di aver messo a frutto, almeno in parte.
Lucchini parte dal nucleo della lezione di Calvino sull'esattezza:
"... Esattezza vuol dire per me soprattutto tre cose:
1) un disegno dell’opera ben definito e ben calcolato;
2) l’evocazione di immagini visuali nitide, incisive, memorabili;
3) un linguaggio il più preciso possibile come lessico e come resa delle sfumature del pensiero e dell’immaginazione."...e poi alza lo sguardo su aspetti dell'uso della lingua che sono parte viva anche della nostra quotidianità e che spesso ci sgomentano, come il seguente:
"Per mancanza di moneta divisionale i pazienti solventi sono pregati di presentarsi allo sportello muniti della suddetta."
... e pare che Munch, dopo aver letto questo, abbia dipinto il suo "Urlo"!
Cosa è l'Esattezza per un Com Tec? Per me significa:
1) scrivere tutto e solo quello che serve per comunicare un concetto
2) rafforzare quello che scrivo con supporti visuali (grafici, tabelle, immagini) che facilitino la comprensione del concetto
3) realizzare quanto ai punti 1 e 2 con la massima sintesi e proprietà di linguaggio, semplificando all'osso la struttura della frase
In particolare, estrapolo un brano dal testo originale di Calvino:
"... le lingue naturali dicono sempre qualcosa in più rispetto ai linguaggi formali, comportano sempre una certa quantità di rumore che disturba l’essenzialità dell’informazione...".
In molte occasioni vi ho indicato come abbattere il rumore della comunicazione sia l'aspetto FONDAMENTALE della comunicazione tecnica.
Come vedete, le idee di Calvino possono servire anche per scrivere della buona comunicazione tecnica. Leggi questo articolo...
martedì 7 maggio 2013
Appunti sulla Comunicazione Tecnica: il blog di Petra Dal Santo
Quando ho iniziato nel 2009 ero pressocchè da solo. Ora, per fortuna, altri professionisti della Com Tec si affacciano in rete con i loro blog. In realtà, alcuni di loro sono da tempo in rete con i propri siti aziendali, ma il blog è uno spazio diverso dal sito aziendale, anche quando è collegato e funzionale a quest'ultimo.
Oggi vi segnalo Petra Dal Santo ed il suo blog, Appunti sulla Comunicazione Tecnica.
Petra ricopre dal 2000 il ruolo di Project Manager in Kea, società di cui è anche socia.
La Kea è una società italiana che fornisce servizi di documentazione tecnica ai propri clienti e il cui fiore all'occhiello è Argo, un CMS che aspira a confrontarsi con i migliori prodotti americani presenti sul mercato.
Dal mese di Febbraio di quest'anno, Petra ha messo in rete e gestisce il blog aziendale della Kea. Ovviamente, come qualsiasi blog aziendale, tende giustamemente a dare risalto alle soluzioni prodotte in casa, ma non si limita a questo solo compito "istituzionale".
Vi segnalo, ad esempio, un post sui criteri con i quali ci si deve orientare per la scelta di un CMS: in questo post Petra parla ovviamente anche di Argo, ma illustra sinteticamente delle linee guida di base che possono essere utili a chiunque stia pensando di trasformare i processi di sviluppo della documentazione, da una modalità "artigianale" e "monolitica" verso una modalità "automatizzata" e "modulare".
Io e Petra ci conosciamo da più di due anni. La contattai per avere una demo di Argo e non ci siamo più persi di vista. Condividiamo l'idea che si debba operare, in qualche modo, per diffondere la cultura della comunicazione tecnica, per spiegare gli enormi vantaggi che un 'azienda può ricavare da una gestione ben organizzata della produzione della documentazione di prodotto e di progetto, superando la visione retrograda che vede la produzione della documentazione soltanto come un "costo", visione per altro destituita di ogni fondamento, come i dati ormai ci dimostrano ampiamente.
E in Italia, in tal senso, c'è una prateria quasi vergine da seminare!
Io faccio del mio meglio, con il mio blog a cui posso dedicare solo poche ore alla settimana. Ora c'è anche lei.
Andate sul suo blog, ci sono cose molto interessanti da scoprire... poi però tornate anche qui!
Leggi questo articolo...
Oggi vi segnalo Petra Dal Santo ed il suo blog, Appunti sulla Comunicazione Tecnica.
Petra ricopre dal 2000 il ruolo di Project Manager in Kea, società di cui è anche socia.
La Kea è una società italiana che fornisce servizi di documentazione tecnica ai propri clienti e il cui fiore all'occhiello è Argo, un CMS che aspira a confrontarsi con i migliori prodotti americani presenti sul mercato.
Dal mese di Febbraio di quest'anno, Petra ha messo in rete e gestisce il blog aziendale della Kea. Ovviamente, come qualsiasi blog aziendale, tende giustamemente a dare risalto alle soluzioni prodotte in casa, ma non si limita a questo solo compito "istituzionale".
Vi segnalo, ad esempio, un post sui criteri con i quali ci si deve orientare per la scelta di un CMS: in questo post Petra parla ovviamente anche di Argo, ma illustra sinteticamente delle linee guida di base che possono essere utili a chiunque stia pensando di trasformare i processi di sviluppo della documentazione, da una modalità "artigianale" e "monolitica" verso una modalità "automatizzata" e "modulare".
Io e Petra ci conosciamo da più di due anni. La contattai per avere una demo di Argo e non ci siamo più persi di vista. Condividiamo l'idea che si debba operare, in qualche modo, per diffondere la cultura della comunicazione tecnica, per spiegare gli enormi vantaggi che un 'azienda può ricavare da una gestione ben organizzata della produzione della documentazione di prodotto e di progetto, superando la visione retrograda che vede la produzione della documentazione soltanto come un "costo", visione per altro destituita di ogni fondamento, come i dati ormai ci dimostrano ampiamente.
E in Italia, in tal senso, c'è una prateria quasi vergine da seminare!
Io faccio del mio meglio, con il mio blog a cui posso dedicare solo poche ore alla settimana. Ora c'è anche lei.
Andate sul suo blog, ci sono cose molto interessanti da scoprire... poi però tornate anche qui!
Leggi questo articolo...
domenica 5 maggio 2013
Dalla scrittura monolitica alla scrittura modulare: quarta parte
Prima di poter anche solo in parte apporofondire gli aspetti più "tecnici" della questione, presumo di dovervi convincere che il gioco vale la candela. Perchè dovreste abbandonare il modo "tradizionale" di scrivere documenti per la vostra azienda, a vantaggio di una nuova modalità che richiede di sicuro una curva d'apprendimento non banale? Per ALMENO 6 buonissimi motivi, che proverò ad esporre brevemente di seguito.
ZERO ERROR UPDATE
In un'architettura modulare, se un contenuto è replicato in N documenti, sarà necessario modificarlo una sola volta; le modifiche effettuate verranno propagate automaticamente in tutti i documenti in cui il contenuto è collocato, riducendo drasticamente le possibilità di errore che sono naturalmente implicate dalla necessità di effettuare N modifiche "a mano" in N documenti distinti.
RIUTILIZZO DEI CONTENUTI
Lo stesso contenuto può essere collocato in N documenti distinti. Questa proprietà dipende anche dalla "granularità" dei contenuti; più la granuralità di un contenuto è "fine", maggiore è la probabilità che quel contenuto possa essere collocato in ambiti diversi. Ovviamente, un eccesso di granularità può implicare problemi di gestione non banali, quindi devono essere utilizzati opportuni criteri per "spezzettare" il documento monolitico originario nel modo migliore, con la granularità più utile ai nostri scopi.
DOCUMENTI MULTICANALE
Ricordate la faccenda dei "contenuti puri" scorrelati dalla "forma"? Perfetto, visto che abbiamo contenuti puri, in che modo li vogliamo vestire? Vogliamo produrre una Scheda Tecnica in formato DOC o PDF? Vogliamo un Help on Line per Android? O vogliamo dei contenuto Web visualizzabili da un browser qualsiasi, da IE a Firefox? Non è un problema nostro, nel senso che i nostri contenuti, puri e modulari, possono essere vestiti secondo stili e formati diversi. Gli aspetti tecnici di questo passaggio non sono oggetto di questo post, sappiate solo che si può fare.
DOCUMENTI MULTILINGUA
Se ho un contenuto modulare, scritto in italiano, posso immaginare di tradurlo in tutte le lingue che mi servono. A quel contenuto si applicano tutte le considerazioni già illustrate in precedenza, per tutte le lingue che vi servono.
GESTIONE COLLABORATIVA
E' raro che una sola persona abbia la conoscenza per realizzare ogni parte di un documento tecnico. Più di frequente, una sola persona si trova a fare da collettore di molte informazioni diverse provenienti da fonti diverse. Tutto ciò può anche funzionare quando ci troviamo a lavorare su un numero molto limitato di documenti; ma immaginate di dover gestire anche solo 20-30 documenti diversi, con un tasso di aggiornamento anche solo del 30% annuo. Cosa succederebbe se fosse possibile assegnare a K persone diverse lo sviluppo di un documento? Ognuno svilupperebbe la parte di sua competenza (Giallo, Verde, Rosso, ...), senza interferire con il lavoro degli altri, condividendo solo un certo insieme di regole comuni definite nell'ambiente di sviluppo, abbattendo drasticamente i tempi di realizzazione.
INTEGRAZIONE TECNOLOGICA (XML, DITA)
Contenuti "puri", modulari, riutilizzabili. E con quale "vestito" tecnologico? E secondo quale metodo di definizione? Qui ci stiamo spingendo molto avanti, anche se è probabile che molti di voi abbiano già confidenza con lo standard XML, mentre dubito che abbiate lo stesso grado di confidenza con DITA.
Ma ora quello che importa è focalizzare il concetto che esistono diversi "mondi" paralleli in grado di manipolare contenuti modulari, secondo regole che implicano vantaggi e svantaggi, mentre NESSUNO DI QUESTI MONDI è in grado di gestire ed accogliere i vostri tradizionali documenti "monolitici".
Vi ho convinto? Ancora no? E allora riprendiamo un esempio già esposto nel post precedente.
Abbiamo sempre i nostri 12 documenti che ospitano il Glossario, la Bibliografia e le Licenze di parti specifiche contenute nel prodotto ma realizzate da terze parti.
In più, decidiamo di tradurre i nostri 12 documenti in 3 lingue: inglese, spagnolo e russo.
Abbiamo già visto che, 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. E a questo punto abbiamo sistemato i documenti scritti in italiano.
Ma ora dobbiamo anche tradurre le parti appena modificate in 3 lingue, quindi dobbiamo riportare le 3 modifiche in 12 documenti (per ogni lingua), cioè 36 modifiche "fisiche" distinte per ogni lingua, quindi 36 x 3 = 108 modifiche "fisiche" disitinte (se preferite, 9 x 12).
In totale quindi 36 + 9 + 108 = 153 modifiche distinte.
Ma se questi 3 elementi informativi sono 3 elementi modulari, indipendenti, memorizzati in un Data Base e scorrelati da altri vincoli... cosa cambia? Se li concepiamo così, dobbiamo fare soltanto:
- 3 modifiche sui contenuti in italiano
- 3 traduzioni per ogni modifica, quindi 9 modifiche/traduzioni
I contenuti aggiornati verranno poi "propagati automaticamente" in qualche modo nei 12 documenti che ci servono, nelle 4 lingue considerate (italiano, inglese, spagnolo e russo).
Quindi siamo passati da 153 modifiche "fisiche" a sole 12 modifiche.
Infine, sempre la stessa domanda: se invece di 12 documenti dovessi aggiornare questi contenuti in 120 documenti diversi, quante modifiche/traduzioni dovrei apportare? SEMPRE E SOLO 12!
Ora vi ho convinto?
Leggi questo articolo...
mercoledì 1 maggio 2013
Come si forma un comunicatore tecnico: terza parte
La Society for Technical Communication (STC) ci fornisce questa definizione:
Technical writing is a broad field that includes any form of communication that exhibits one or more of the following characteristics:
Mi sembra che anche la definizione della STC sia orientata in tal senso, ma avvitarmi in una disquisizione formalistica è proprio l'ultimo dei miei pensieri, mentre mi sembra interessante mettere sul tavolo una questione di metodo: per capire cosa mi serve per fare il mio lavoro, per capire cosa devo studiare e come mi devo formare, devo capire quali sono i diversi aspetti del mio lavoro, i diversi "cappelli" che devo indossare, in ultima analisi le competenze che devo acquisire.
Alla base, ci deve essere una buona predisposizione/preparazione linguistica, almeno per quanto riguarda tutti gli aspetti generali e fondamentali. Se avete una preparazione linguistica ottenuta attraverso un percorso accademico ben strutturato è meglio. In caso contrario, avere passione per la lettura e la scrittura aiuta; curiosità per le parole, confidenza con terminologie settoriali, un continuo allenamento anche inerente a diversi stili di scrittura, non necessariamente tecnici. Tutti questi aspetti vanno a definire una "base" ineludibile, un pò come la corsa di resistenza è la base per moltissimi sport.
Un secondo architrave su cui poggiare il vostro "edificio professionale" è la preparazione tecnica.
A mio avviso è molto meno fondamentale di quella linguistica, ma può facilitarvi nel velocizzare la comprensione delle tematiche che andate ad illustrare. Io sono un ingegnere informatico che normalmente documenta prodotti software, ma i miei studi di elettronica e di fisica mi aiuterebbero anche nel caso in cui dovessi scrivere il manuale di manutenzione di un impianto fotovoltaico. Se non siete ingegneri, è comunque necessario che abbiate passione e curiosità per la tecnologia, altrimenti non credo che possiate fare bene questo lavoro.
Poi dovete avere anche un briciolo di talento naturale per la comunicazione: dovete aver voglia di spiegare, insegnare, divulgare. E lo dovete fare nello stile di un comunicatore tecnico, ovviamente; ma ricordatevi che lo stile si può imparare, il talento si può solo perfezionare e amplificare, ma deve essere già presente.
Ma queste 3 colonne portanti sono solo le fondamenta dell'edificio professionale di cui sopra. Per costruire le mura, i solai e le diverse stanze dobbiamo classificare le competenze che un Tech Comm deve possedere.
Alcuni amano fare una suddivisione basata sul "livello" professionale (junior, senior, master/advanced) ma nella mia esperienza non è possibile definire dei confini di competenze ben netti sulla base di questo criterio.
Io preferisco classificare le competenze tentando di riconoscere 3 aree:
Technical writing is a broad field that includes any form of communication that exhibits one or more of the following characteristics:
- communicating about technical or specialized topics, such as computer applications, medical procedures, or environmental regulations;
- providing instructions about how to do something, regardless of how technical the task is, and regardless of whether technology is used to create or distribute that communication
Mi sembra che anche la definizione della STC sia orientata in tal senso, ma avvitarmi in una disquisizione formalistica è proprio l'ultimo dei miei pensieri, mentre mi sembra interessante mettere sul tavolo una questione di metodo: per capire cosa mi serve per fare il mio lavoro, per capire cosa devo studiare e come mi devo formare, devo capire quali sono i diversi aspetti del mio lavoro, i diversi "cappelli" che devo indossare, in ultima analisi le competenze che devo acquisire.
Alla base, ci deve essere una buona predisposizione/preparazione linguistica, almeno per quanto riguarda tutti gli aspetti generali e fondamentali. Se avete una preparazione linguistica ottenuta attraverso un percorso accademico ben strutturato è meglio. In caso contrario, avere passione per la lettura e la scrittura aiuta; curiosità per le parole, confidenza con terminologie settoriali, un continuo allenamento anche inerente a diversi stili di scrittura, non necessariamente tecnici. Tutti questi aspetti vanno a definire una "base" ineludibile, un pò come la corsa di resistenza è la base per moltissimi sport.
Un secondo architrave su cui poggiare il vostro "edificio professionale" è la preparazione tecnica.
A mio avviso è molto meno fondamentale di quella linguistica, ma può facilitarvi nel velocizzare la comprensione delle tematiche che andate ad illustrare. Io sono un ingegnere informatico che normalmente documenta prodotti software, ma i miei studi di elettronica e di fisica mi aiuterebbero anche nel caso in cui dovessi scrivere il manuale di manutenzione di un impianto fotovoltaico. Se non siete ingegneri, è comunque necessario che abbiate passione e curiosità per la tecnologia, altrimenti non credo che possiate fare bene questo lavoro.
Poi dovete avere anche un briciolo di talento naturale per la comunicazione: dovete aver voglia di spiegare, insegnare, divulgare. E lo dovete fare nello stile di un comunicatore tecnico, ovviamente; ma ricordatevi che lo stile si può imparare, il talento si può solo perfezionare e amplificare, ma deve essere già presente.
Ma queste 3 colonne portanti sono solo le fondamenta dell'edificio professionale di cui sopra. Per costruire le mura, i solai e le diverse stanze dobbiamo classificare le competenze che un Tech Comm deve possedere.
Alcuni amano fare una suddivisione basata sul "livello" professionale (junior, senior, master/advanced) ma nella mia esperienza non è possibile definire dei confini di competenze ben netti sulla base di questo criterio.
Io preferisco classificare le competenze tentando di riconoscere 3 aree:
- COMPETENZE FONDAMENTALI
- COMPETENZE SPECIALISTICHE
- COMPETENZE COMPLEMENTARI
lunedì 8 aprile 2013
Ospite del blog "Translator Thoughts": un'intervista sulla professione del Technical Writer
Translator Thoughts è il blog di Chiara Grassilli, una traduttrice professionista che si è laureata a Bologna ma che ora vive e lavora in Inghilterra, dove segue anche un Master in Lingue.
Chiara ha partecipato ai 3 webinar introduttivi sulla professione del Technical Writer che ho condotto per la EST. La scorsa settimana mi ha chiesto un'intervista in inglese per i lettori del suo blog.
Chi ascolterà la registrazione audio, avrà chiaro il senso delle mie parole quando dico che sto continuando a studiare per migliorare il mio inglese!
Oltre alla registrazione (circa 21 minuti), c'è la trascrizione completa dell'intervista. Il blog di Chiara è nato da poco, ma ha già un suo pubblico e propone tematiche molto interessanti per chi si interessa di traduzione e scrittura tecnica. Chiara mi colpito per l'energia e la determinazione che mi ha comunicato quando mi ha parlato del suo lavoro e delle sue scelte.
Rimarremo in contatto e spero di poterla ospitare nella mia sessione Open Blog.
La ringrazio per la sua gentilezza e le faccio un "in bocca la lupo" per la sua professione ed il suo blog. Leggi questo articolo...
Chiara ha partecipato ai 3 webinar introduttivi sulla professione del Technical Writer che ho condotto per la EST. La scorsa settimana mi ha chiesto un'intervista in inglese per i lettori del suo blog.
Chi ascolterà la registrazione audio, avrà chiaro il senso delle mie parole quando dico che sto continuando a studiare per migliorare il mio inglese!
Oltre alla registrazione (circa 21 minuti), c'è la trascrizione completa dell'intervista. Il blog di Chiara è nato da poco, ma ha già un suo pubblico e propone tematiche molto interessanti per chi si interessa di traduzione e scrittura tecnica. Chiara mi colpito per l'energia e la determinazione che mi ha comunicato quando mi ha parlato del suo lavoro e delle sue scelte.
Rimarremo in contatto e spero di poterla ospitare nella mia sessione Open Blog.
La ringrazio per la sua gentilezza e le faccio un "in bocca la lupo" per la sua professione ed il suo blog. Leggi questo articolo...
domenica 31 marzo 2013
Technical Writer... ovvero tutto quello che avreste voluto sapere ma non avete mai osato chiedere
Era da tempo che volevo segnalarvi questo post di Giulia Zanchi, una Tech Writer e blogger dotata di una stile di scrittura che mi ha catturato fin dal primo incontro... digitale s'intende!
Nel post riassume ed elenca tutta una serie di fosforiche ed ironiche informazioni sulla nostra comune professione.
E' un esercizio di stile da manuale: le stesse informazioni che su certi siti "professionali" sono presentate su un sub-strato di noia fulminante, che ammazzerebbe anche un cavallo da tiro ungherese, scorrono con ritmo e piacevolezza, sono colorate, dinamiche e divertenti, senza la pretesa enciclopedica di voler spiegare tutto ma con un taglio inusuale.
Il suo blog non parla solo di T-writing, non è un blog tecnico in senso stretto, ci potete trovare anche altro e mi piace anche per questo.
E con ciò, serena Pasqua a tutti.
P.S.
Il mese di Marzo è stato un mese intensissimo sul piano lavorativo, mi ha lasciato poco tempo per scrivere sul blog, ma spero di recuperare nel mese di Aprile. Leggi questo articolo...
Nel post riassume ed elenca tutta una serie di fosforiche ed ironiche informazioni sulla nostra comune professione.
E' un esercizio di stile da manuale: le stesse informazioni che su certi siti "professionali" sono presentate su un sub-strato di noia fulminante, che ammazzerebbe anche un cavallo da tiro ungherese, scorrono con ritmo e piacevolezza, sono colorate, dinamiche e divertenti, senza la pretesa enciclopedica di voler spiegare tutto ma con un taglio inusuale.
Il suo blog non parla solo di T-writing, non è un blog tecnico in senso stretto, ci potete trovare anche altro e mi piace anche per questo.
E con ciò, serena Pasqua a tutti.
P.S.
Il mese di Marzo è stato un mese intensissimo sul piano lavorativo, mi ha lasciato poco tempo per scrivere sul blog, ma spero di recuperare nel mese di Aprile. Leggi questo articolo...
mercoledì 27 febbraio 2013
Iper Glossario!
Per chi scrive documentazione tecnica, contenuti web, per i traduttori e i localizzatori, uno degli strumenti più utili, da sempre, è il Glossario.
Ma quale Glossario? Ogni ambito tecnologico, ogni area culturale, ogni settore linguistico ha "il suo" Glossario.
E allora ben venga un sito che li colleziona: Glossarissimo.
L'iniziativa è di Stefano Kalifire, un traduttore professionista che segue da tempo il mio blog (ed io periodicamente vado a curiosare nei suoi). Sono andato un po' a zonzo e ho scoperto dei Glossari "inaspettati", vi invito a darci un occhio, magari trovate proprio quello che stavate cercando. Leggi questo articolo...
Ma quale Glossario? Ogni ambito tecnologico, ogni area culturale, ogni settore linguistico ha "il suo" Glossario.
E allora ben venga un sito che li colleziona: Glossarissimo.
L'iniziativa è di Stefano Kalifire, un traduttore professionista che segue da tempo il mio blog (ed io periodicamente vado a curiosare nei suoi). Sono andato un po' a zonzo e ho scoperto dei Glossari "inaspettati", vi invito a darci un occhio, magari trovate proprio quello che stavate cercando. Leggi questo articolo...
domenica 24 febbraio 2013
Dalla scrittura monolitica alla scrittura modulare: terza parte
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:
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.
Leggi questo articolo...
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.
Leggi questo articolo...
Iscriviti a:
Post (Atom)
