domenica 21 novembre 2010

Perchè un'azienda dovrebbe assumere un Technical Writer: seconda parte

Nel post precedente ho illustrato 5 ottimi motivi per i quali un'azienda dovrebbe avvalersi della professionalità di un TW. Ed ora, altri 5 motivi... vediamo se vi convinco!
;-)

6: Una buona documentazione parla della Qualità e dell'affidabilità di un'azienda

Quando compro un prodotto e la Quick Start Guide è incomprensibile, mi sento un cliente di serie B e probabilmente non comprerò un nuovo prodotto da quell'azienda, perchè mi comunica la sensazione di non aver cura dei suoi clienti. Forse è un'azienda solo motivata a massimizzare il proprio profitto, comprimendo anche i costi necessari a sviluppare la qualità del prodotto, probabilmente priva di una visione di medio-lungo periodo. E perchè dovrei fidarmi di un'azienda che non si proietta nel SUO futuro? Perchè IO dovrei credere in qualcuno che non crede in se stesso?
Una buona documentazione nobilita il brand di un'azienda ed è un moltiplicatore del rapporto di fiducia fra l'azienda e i suoi clienti.

7: La documentazione fornisce una "memoria" utile a chi sviluppa il prodotto.

Quando un prodotto è particolarmente potente e versatile, risulta inevitabilmente anche complesso da configurare e difficile da usare. Questo non dipende, in tal caso, dal fatto che sia stato progettato/disegnato male, ma deriva dalla sua ricchezza funzionale. L'evoluzione di un prodotto di questo tipo, prima ancora della sua commercializzazione, richiede lo sviluppo di una documentazione accurata, prima di tutto per uso interno, facilitando l'attività di sviluppo del prodotto medesimo.

Tipicamente, quando un nuovo membro viene inserito nel team di sviluppo, se dispone di un set di documenti adeguato può acquisire rapidamente il know-how necessario e risultare produttivo in un tempo molto breve.
Se invece deve essere continuamente affiancato da un supervisore più esperto e deve acquisire le competenze secondo lo schema "prova-sbaglia-impara-riprova", il suo inserimento sarà più lento ed inefficace.

Non siete convinti? Venerdì scorso il mio collega Riccardo ha chiesto di prendere in visione il manuale di un'applicazione Web sviluppata per un cliente, perchè deve realizzare le procedure di collaudo dell'applicazione medesima.

Grazie al fatto che il manuale è già pronto, Riccardo potrà realizzare un documento di collaudo preciso ed efficace molto velocemente.

8: Una documentazione accurata riduce i costi di supporto ed help-desk

Se un prodotto è ben documentato, i clienti possono trovare la maggiorparte delle risposte che necessitano all'interno della documentazione. Ovviamente questo non esime l'azienda che realizza quel prodotto a fornire supporto tecnico e servizi di help-desk. Ma tali servizi costano non poco e sono tanto più onerosi quante più ore di supporto devono fornire.
Se non siete convinti, vi invito a leggere questo post, datato 1995 ma ancora attuale, dal sito Web della AllBusiness.

9: Un Technical Writer può fornire supporto alla realizzazione di corsi d'aggiornamento

Dovendo documentare i prodotti/servizi/soluzioni/architetture di un'azienda, il TW finisce per divenire un esperto di tali argomenti. In particolare, è molto frequente che un tecnico conosca alla perfezione il prodotto di cui si occupa, ma magari non conosca altrettanto bene il prodotto sviluppato dal collega che lavora nella stanza accanto. Il TW  invece acquisisce una conoscenza a 360° della soluzioni aziendali. E' inoltre un esperto di comunicazione ed è abituato a guardare ognoi aspetto dal punto di vista del cliente.

Quindi è particolarmente in grado di sviluppare la documentazione e occuparsi della conduzione dei corsi d'istruzione che vengono erogati ai clienti.
 
10: Un Technical Writer possiede uno skill molto versatile

Il TW sa scrivere i documenti che accompagnano un prodotto, ma può essere coinvolto anche nella scrittura di altre tipologie di documenti, come i contratti o i documenti di offerta. Conosce tutti i prodotti aziendali, quindi può condurre corsi presso i clienti che hanno acquistato il prodotto. Ha conoscenze di grafica e di tecnologie Web (Html, Xml, CMS, Blog,...) e può contribuire alla gestione del sito Web aziendale e alla costruzione dei suoi contenuti. Aiuta il team tecnico a testare e collaudare un prodotto. Sa realizzare una presentazione e conoscendo i prodotti aziendali può affiancare l'attività di pre-vendita o diventare egli stesso un pre-seller.

Un TW può quindi essere utile in diverse zone della scacchiera, può giocare in diversi ruoli, può adattarsi alle esigenze dell'azienda.

---
Adesso avete 10 buone idee sulle quali ragionare.

Ricordatevi che qualsiasi cosa state realizzando, SEMPLICEMENTE NON ESISTE... se non c'è qualcuno che la va a raccontare in giro.

La comunicazione tecnica è solo un sottoinsieme della più ampia strategia di comunicazione, che include la pubblicità e il marketing, finalizzata a sostenere un prodotto. Potete scegliere di non investire nella comunicazione, ma in tal caso non potrete lamentarvi della pochezza dei vostri risultati.
Per la serie "Uomo avvisato...".

POST SCRIPTUM

Recentemente, ho sentito un ingenuo collega affermare che "... Oracle è un prodotto che si vende da solo...".
Nel 1982, quando avevo 16 anni e programmavo in assembler il mio Commodore 64, Oracle era poco più di una start-up, nata qualche anno prima dalle ceneri di un vecchio progetto commissionato dalla CIA e miseramente fallito. Fatevi i conti di quanto hanno investito negli ultimi 28 anni, in termini di pubblicità, marketing e documentazione tecnica, prima di arrivare ad essere "un prodotto che si vende da solo", autentico dominatore del mercato. Sono i migliori? Oggi credo di si, ma negli anni '80 certamente no!

Cosa ha fatto la differenza, cosa ha scavato un solco che oggi sembra difficile da colmare, come hanno moltiplicato i ricavi del loro business? E' solo merito dell'indubbia sagacia tecnica delle loro soluzioni? Fatevi una domanda... datevi una risposta... E NON PRENDETE SCORCIATOIE COME IL MIO INGENUO COLLEGA!
Leggi questo articolo...

sabato 20 novembre 2010

Perchè un'azienda dovrebbe assumere un Technical Writer: prima parte

Mi sono imbattuto in un interessante articolo di Ben Minson, che illustra diversi motivi per i quali un'azienda dovrebbe considerare conveniente l'apporto di un Technical writer e valutare l'opportunità di avvalersi dei suoi servizi.

Per chi volesse leggere l'originale in inglese, può andare su questo link.
Per tutti gli altri, vi propongo una sintesi tradotta e ragionata, conforme all'originale ma con qualche licenza personale, finalizzata a snellire, riorganizzare e contestualizzare le ottime indicazioni di Minson.

1: L'utente finale ha bisogno della documentazione

Sembrerebbe un motivo ovvio e banale, in grado già di giustificare l'apporto di un TW.
Alcuni utenti hanno bisogno di essere istruiti attraverso un corso, altri preferiscono imparare ad usare un prodotto semplicemente usandolo, secondo lo schema "prova-sbaglia-impara-riprova", altri si stanno abituando all'uso dei video-tutorial e privilegiano tale modalità.

Ma la maggiorparte necessitano sicuramente di una documentazione, in formato cartaceo e/o digitale, quanto più completa ed accurata, in grado di illustrare, al contrario degli approcci sopraindicati, TUTTI gli aspetti del prodotto.

Inoltre, più il prodotto è complesso e sofisticato, meno risultano efficaci gli approcci che prescindono da un set organico di documentazione dedicata.

Se parlate con i progettisti di un certo prodotto, vi diranno quasi sempre che la loro "creatura" è ben disegnata e facile da usare.

NON GLI DATE ASCOLTO! STANNO MENTENDO! Ma non perchè sono in malafede o perchè vogliono vendervi per forza la loro soluzione. Semplicemente perchè essendo utenti esperti e spesso poco inclini alla comunicazione, non sono in grado di valutare le difficoltà dell'utente finale nell'uso del prodotto.

Il lavoro del TW è proprio quello di rendere comprensibile e facile da usare ciò che può spesso risultare complicato, sia esso un prodotto/un processo/un'architettura.

2: La buona documentazione può evitare pericoli per la salute dell'utente finale

Sembrerebbe un'affermazione "forte", forse eccessiva. Ma immaginate un dispositivo elettro-meccanico non accompagnato da un'accurata documentazione relativa ai corretti livelli di tensione e di corrente per la sua installazione e il suo funzionamento. Oppure, per un medicinale importante, un foglietto informativo (tristemente noto come "il bugiardino") impreciso e/o incompleto. In questi casi la salute degli utenti è messa rischio e l'affermazione iniziale appare ben ponderata.

3: Documentare correttamente il prodotto è una tutèla anche per il produttore

Dall'uso scorretto di un prodotto possono derivare danni per l'utilizzatore. Se mi accingo ad utilizzare un elettrodomestico e nessuno mi avvisa che è pericoloso utilizzarlo con le mani bagnate, posso essere folgorato e potrei successivamente tentare di rivalermi sull'azienda che non mi ha fornito le giuste indicazioni. In generale, avvisare il cliente delle insidie che scaturiscono da un uso improprio di un prodotto rappresenta la linea di tutèla minima che qualsiasi azienda dovrebbe praticare onde evitare contenziosi legali indesiderati e pericolosi, sia in termini di immagine che in termini economici.

Anche in quest'ottica l'apporto di un TW può essere particolarmente incisivo.

4: La documentazione come volàno per la vendita del prodotto

Minson cita la testimonianza di Matt Asay, ex dirigente per lo sviluppo del business per Alfresco, uno dei Content Management System open source più "rampanti" degli ultimi tempi. Matt afferma: "Il 30% degli utenti che visitano il sito di Alfresco lo fanno per scaricare e prendere in visione la documentazione, per poter valutare le caratteristiche del prodotto. La documentazione è stata spesso vista come la "parente povera" dello sviluppo del software. Ma lo sviluppo di software senza documentazione è banalmente autoreferenziale. Un'azienda che sviluppa buona documentazione, mostra attenzione per i clienti e li induce a scaricare il software ed utilizzarlo, favorendone la diffusione".

Hanna Kirk sostiene: "Aiutando il cliente ad usare un prodotto con facilità, si aumenta la percezone della qualità del prodotto, quindi il suo successo".

5: Il Technical Writer può aiutare a migliorare il prodotto

L'ottica di chi sviluppa un prodotto è focalizzata sul rispetto delle specifiche, che vanno armonizzate con le tecnologie diponibili, e sul rispetto dei tempi di consegna prefissati. E' quindi improbabile che possa anche tener contro del "punto di vista" dell'utente che dovrà usare quel prodotto. Il TW è invece abituato a guardare il prodotto "con gli occhi del cliente".

Nella aziende più illuminate, il TW viene coinvolto nello sviluppo del prodotto e contribuisce a migliorarne le prestazioni DURANTE la fase di progettazione. La sua sensibilità nel cogliere difetti e limiti di una soluzione può anche risultare preziosa per risparmiare tempo e denaro, ottimizzando la fase di progettazione. In questo modo arricchisce "la consapevolezza" del team di sviluppo che quello che si sta progettando non è un oggetto autoreferenziale, ma lo si sta realizzando perchè lo dovrà usare qualcun'altro.
Inoltre, usando il prodotto per poterlo documentare, è il primo "cliente virtuale" in grado di tracciarne tutti i difetti del prima che venga immesso sul mercato.
Spesso riesce anche a cogliere comportamenti indesiderati di un prodotto, che emergono quando vengono realizzate delle sequenze operative inusuali, che i progettisti non avevano preso in considerazione.

Tutto ciò si traduce in un solo concetto: MIGLIORAMENTO DELLA QUALITA'DEL PRODOTTO.

Al prossimo post, per esplorare altri buoni motivi per assumere un Technical Writer...
;-)
Leggi questo articolo...

domenica 14 novembre 2010

E' in libreria "Comunicazione low cost" di Cristina Mariani

E' da poco disponibile nelle migliori librerie il nuovo libro di Cristina Mariani: "Comunicazione low cost".

Cristina è una brillante consulente di marketing, che ha da molti anni concentrato la sua attenzione su tecniche e strumenti di marketing e comunicazione a basso costo, rivolte in particolar modo alle piccole (a volte piccolissime) e medie imprese.

Nelle piccole realtà imprenditoriali spesso non si dispone di un budget tale da poter impiantare delle campagne di marketing "tradizionali". Ma oggi esistono moltissimi strumenti in grado di far conoscere la qualità di un'azienda e dei suoi prodotti a costi irrisori.

Nel libro c'è anche un mio breve intervento sull'argomento White Paper, uno degli strumenti di pre-vendita più potenti che si possano immaginare, ma che nella cultura della comunicazione d'impresa italiana non è ancora sufficentemente considerato.

Da Giovedì scorso è attivo il link per acquistare il libro sul sito della Franco Angeli.

Per chi volesse prendere in visione l'indice del libro, può farlo seguendo questo link.

Ovviamente vi invito anche a frequentare il suo blog, già presente nella sezione DA VISITARE di questa pagina.

Ringrazio ancora Cristina per la considerazione espressa nei miei confronti e spero che questa sua ultima fatica abbia ancor più successo del suo primo libro, "Marketing low cost", già molto apprezzato dai suoi lettori. Leggi questo articolo...

mercoledì 27 ottobre 2010

Ecco un blog interessante ed originale sulla comunicazione tecnica

Oggi vi segnalo il blog curato da Barbara Zen.

Barbara è un'esperta di grafica e illustratrice tecnica, talvolta impegnata anche nella redazione della documentazione tecnica dei prodotti di cui si occupa.

Nel sul blog vi potrete imbattere in diversi contenuti interessanti, idee e video spesso originali, curiosità e spunti quasi sempre incentrati sulla ricerca della Qualità da conferire al processo di comunicazione che deve guidare il cliente all'utilizzo dei prodotti. La cosa che più mi ha "intrigato" è proprio la sua attenzione ad un'ottica incentrata sui bisogni del cliente finale.

Questo approccio, che dovrebbe essere un "must" per il comunicatore tecnico, non sempre viene perseguito e praticato con la giusta energia. Spesso, ci ritroviamo a scrivere documenti strangolati nei limti di standard formali/legali o normative che provvedono ad ogni sorta di obiettivo meno che all'obiettivo principale, che dovrebbe essere l'efficacia del processo di comunicazione  prodotto/manuale/uomo.

Fra le altre cose, ho scoperto che abbiamo una comune passione per Robert M. Pirsig ed il suo immortale "Lo Zen e l'arte della manutenzione della motocicletta".

Non mi chiedete di cosa parla... leggetelo!

E visitate il blog di Barbara, sperando che vi piaccia come è piaciuto a me. Leggi questo articolo...

venerdì 22 ottobre 2010

Il mio PC ha fatto booommmm!

Ehhh si... si vede che lo stresso troppo. Uno dei famigerati update di Windows lo ha steso! Ora l'ho rimesso in piedi, ma con tutto il software che devo reinstallare, mi ci vorrà almeno tutto il week-end. E ancora non mi funziona il Wi-Fi. Sgrunt! Ma alcuni post sono quasi pronti, quindi non cambiate canale!
Azz... mi starò montando la testa?
:-) Leggi questo articolo...

sabato 16 ottobre 2010

Calcolare il valore degli Indici di Leggibilità con Word

Nel post del 10-10-2010 ho introdotto il tema degli Indici di Leggibilità.
La gran parte delle persone che scrive un testo sul PC usa Office Word.
Ma pochi sanno che Word offre la possibilità di valutare la leggibilità di un testo attraverso il calcolo degli indici Gulpease e Gunning Fog.

L'Indice Gulpease, presentato nel post sopraindicato, è adatto alla lingua italiana mentre il Gunning Fog è finalizzato alla lingua inglese (parole più corte e con poche sillabe).
 
Per poter eseguire il calcolo di tali indici, bisogna configurare Word con pochi semplici passaggi:

1.    Dalla barra dei Menù, selezionare Strumenti > Opzioni
2.    Nel pannello Opzioni, selezionare la scheda Ortografia e Grammatica
3.    Nella sezione Grammatica, spuntare la check-box Mostra le statistiche di leggibilità
4.    Premere il pulsante Ok, in basso a destra nel pannello Opzioni

A questo punto, se volete analizzare la leggibilità del vostro documento, dovete eseguire un controllo ortografico:

1.    Dalla barra dei Menù, selezionare Strumenti > Controlli Ortografia e Grammatica

Al termine del controllo ortografico viene visualizzato il pannello riassuntivo:

 
 I dati presenti nel pannello sono riferiti alle prime 3 frasi di questo post.

Leggi questo articolo...

lunedì 11 ottobre 2010

Buone prospettive per la professione di Technical Writer!

Ogni tanto una buona notizia ci vuole!

Dal blog di Luisa Carrada vi segnalo un post in cui si prospettano buone possibilità per la professione di Technical Writer, specialmente per coloro che padroneggiano la lingua inglese. La notizia si riferisce al mercato USA per il 2010, ma con le dovute pinze possiamo immaginare di poterla proiettare anche sul mercato nazionale ed Europeo.

Nel post Luisa cita anche il mio blog, bontà sua.

Ho la piacevole sensazione che forse si sta iniziando a capire l'importanza della comunicazione tecnica per sviluppare e creare valore aggiunto nella logica di business di un'azienda.

Nel mondo anglosassone questo concetto è già consolidato e in crescita, in Italia ci sono ancora praterie inesplorate a disposizione.

Se son rose... Leggi questo articolo...

domenica 10 ottobre 2010

La Qualità della documentazione tecnica: la Leggibilità

Quante volte, davanti ad un documento tecnico, avete avvertito la sgradevole sensazione che stavate leggendo qualcosa di poco comprensibile, anche se magari eravate degli esperti dell'argomento trattato?

Quante volte avete pensato che quel documento era poco "leggibile"?

Con il termine "leggibilità" intendiamo una particolare proprietà per cui un testo risulta comprensibile, facile da leggere. Tale proprietà può essere associata a qualsiasi testo scritto ed è influenzata sia da aspetti fisici che da aspetti linguistici.

La lettura di un testo sullo schermo di un PC risulta mediamente più lenta del 20-30% rispetto allo stesso testo scritto su carta. Anche la capacità di concentrazione di un lettore tende a ridursi più velocemente se legge un testo da una pagina Web piuttosto che da un libro tradizionale. Di conseguenza, l'utente Web legge di rado parola per parola, ma tende a "scannerizzare" la pagina alla ricerca di punti "sensibili" alla sua attenzione (titoli, elenchi, spaziature, immagini, ecc...) e saltando velocemente da una parte all'altra della pagina.

Queste osservazioni, dipendenti dal supporto "fisico" sul quale collochiamo il testo, hanno permesso di formulare specifiche regole di scrittura per il Web, che sono riassunte nelle diverse Guide di Stile che potete trovare in rete e sulle quali tornerò prossimamente con un post dedicato.

La leggibilità "linguistica" riguarda l'uso della lingua in tutte le sue componenti, dalla scelta dei termini e della sintassi impiegata all'articolazione dei contenuti.

Lo studioso americano Rudolf Flesch fu il primo a proporre un metodo "oggettivo" per misurare la leggibilità (Indice di Flesch, 1946).
La formula tiene conto della lunghezza media delle parole, misurate in sillabe, e della lunghezza media delle frasi, misurata in parole.
I principi basilari sono molto semplici:
  • una parola lunga è in genere usata meno di una breve;
  • una frase lunga è di solito sintatticamente più complessa di una breve.
La formula di Flesch, adattata alla lingua italiana da Roberto Vacca, è la seguente:

F = 206 - (0,6 * S) - P

ove:
  • 206 è una costante normalizzatrice, finalizzata a mantenere i valori della formula compresi fra 0 e 100;
  • 0,6 è una costante relativa alla lunghezza media delle parole italiane;
  • S è il numero di sillabe contenute in un campione di 100 parole;
  • P è il numero medio di parole per frase presenti in un campione di 100 parole.
Se F>60, il testo è MOLTO leggibile.

Se 50<60, il testo è di MEDIA leggibilità.

Se F<50, il testo è POCO leggibile.

Per calcolare la leggibilità con questo indice è necessario scegliere un campione adeguato alla lunghezza del testo stesso (tanto per semplificare, una sezione almeno pari al 10-15% del testo).
Terminata questa operazione, si dovranno contare le sillabe contenute nel campione e calcolare il numero medio di parole per frase.

Come vedete, non è un'operazione banale.
Esistono anche altri indici, oltre a questo.

Nel 1987 un gruppo di linguisti dell'Università La Sapienza di Roma si è riunita attorno a Tullio De Mauro per costituire il GULP, Gruppo Universitario Linguistico Pedagogico. In questi laboratori è nato l'Indice Gulpease.


La scala di leggibilità secondo questo indice va da 100 (leggibilità massima) a 0 (leggibilità nulla). I lettori che hanno un'istruzione elementare leggono facilmente i testi che presentano un indice superiore a 80. I lettori che hanno un'istruzione media leggono facilmente i testi con indice superiore a 60. I lettori che hanno un'istruzione superiore leggono facilmente i testi con indice superiore a 40.
 

Quindi, per ottenere testi leggibili, bisogna semplificare!

La formula dell'Indice Gulpease è:

G= 89 - (Lp / 10) + (3 × Fr)

ove:

  • Lp = (100 × totale lettere) / totale parole
  • Fr = (100 × totale frasi) / totale parole
L'Indice Gulpease è il primo indice di leggibilità tarato sulla lingua italiana e ha il vantaggio di calcolare la lunghezza delle parole in lettere, anziché in sillabe. In rete è possibile trovare dei siti Web che consentono il calcolo dell'indice Gulpease e io ve ne propongo tre:

ANALIZZATORE LEGGIBILITA' 1 


ANALIZZATORE LEGGIBILITA' 2 


ANALIZZATORE LEGGIBILITA' 3

Sperimentateli.

Generalmente non siamo abituati a calcolare l'Indice di Leggibilità di quello che scriviamo.
Ma realizzare documenti leggibili può essere molto desiderabile quando scriviamo per il Web o quando dobbiamo valutare i costi da sostenere per tradurre i nostri documenti o quando scriviamo documenti per la Pubblica Amministrazione che poi devono essere proposti agli utenti.

Tali indici sono delle armi molto utili nella lotta al "burocratese" che, soprattutto in Italia, è spesso molto diffuso. Non è certo banale semplificare testi che trattano argomenti/concetti complessi, qualche volta è quasi impossibile. 


A maggior ragione, se ci riusciamo, possiamo dire di aver aggiunto un pezzo al puzzle della Qualità di un documento tecnico che tentiamo di costruire.

Leggi questo articolo...

giovedì 7 ottobre 2010

Come realizzare un Video Tutorial: i fondamentali

Per realizzare un Video Tutorial bisogna dotarsi di un software in grado di manipolare un filmato, magari realizzato con una videocamera o una web-cam, e che possa catturare le immagini che fluiscono sullo schermo di un PC. Ai fini della realizzazione di un Video Tutorial, sono veramente fondamentali poche funzionalità ed essenzialmente:
  • la possibilità di realizzare un filmato in diversi formati;
  • la possibilità di partizionare lo schermo in diverse zone;
  • la possibilità di avere funzionalità di "post-produzione", come quella di aggiungere la voce narrante dopo aver realizzato il video (rendendo asincrona la realizzazione dell'audio rispetto al video) o aggiungere testi scritti ed elementi grafici al video
 Io conosco direttamente due prodotti:
  • CamStudio
  • Camtasia Studio

CamStudio è un prodotto Open Source, gratuito, molto spartano ma efficace e la sua installazione dura circa un minuto. Consente di registrare qualsiasi attività che si svolge sullo schermo del vostro computer, prendendolo in considerazione nella sua interezza o selezionandone solo una regione specifica.
Il video prodotto è in formato AVI o SWF (formato Flash).
CamStudio consente inoltre di catturare l'audio dal microfono o dalle periferiche audio del sistema, nonchè di personalizzare il video con testo e note. L'interfaccia di CamStudio offre un menù essenziale ed intuitivo.
Se siete dei noefiti e non avete pretese iper-professionali, va benissimo.

CamtasiaStudio è un prodotto molto professionale, con licenza a pagamento, che fornisce numerose possibilità di configurazione. Produce filmati in diversi formati, oltre al formato proprietario CAMREC:
  • Flash (SWF/FLV) - Adobe Flash output
  • WMV - Windows Media streaming video
  • MOV - QuickTime movie
  • AVI video
  • iPod/iTunes
  • RM - Real Media streaming media
  • CAMV - Camtasia for RealPlayer streaming media 
  • GIF animation file
Anche Camtasia Studio consente di realizzare un video che registra tutto ciò che accade sull'intero schermo o solo in una parte di esso. Una volta terminata la registrazione si dispone di un ampio insieme di opzioni di post-produzione (diverse modalità di editing, effetti di transizione, aggiunta del commento audio, zoom, definizione di rapporti di compressione del video, aggiunta di un watermark,...).

Prendere confidenza con questi strumenti è un pre-requisito per poter iniziare a sviluppare un Video Tutorial.
Come ripeto, ce ne sono molti altri, sia freeware (gratuiti) che a pagamento.

Dovete valutare quello che vi interessa in base alle vostre esigenze e poi potete iniziare a "giocare". A presto.
Leggi questo articolo...

lunedì 4 ottobre 2010

Un esempio di White Paper tecnico

Nel mese di Aprile vi avevo illustrato una classificazione dei diversi tipi di White Paper che si potevano realizzare. Tra questi, avevo indicato quali erano le caratteristiche fondamentali di un White Paper "tecnico".
Ora ecco un un esempio classico di questa tipologia. Potete confrontare la struttura di questo WP della Symantec con le linee guida che vi avevo fornito nel post del 25 Aprile e rilevare una sostanziale sovrapposizione delle due impostazioni... oppure no?!? Si accettano eventuali contestazioni! :-) Leggi questo articolo...