mercoledì 14 ottobre 2020

Documentare le API? Le risposte nascono dalle domande...

Come detto in precedenza, le API sono la pietra angolare della trasformazione digitale che sta attraversando tutte le aziende. Se non foste convinti di questo assunto, vi basti pensare alle conseguenze della pandemia COVID-19 che stiamo vivendo: quale impatto abbiamo registrato sui processi lavorativi?

Le aziende più efficienti hanno fatto fronte alle difficoltà con meno danni  e sono quelle che dispongono di processi digitalizzati realizzabili senza la necessità che TUTTI i lavoratori siano necessariamente presenti nel perimetro aziendale.

Un esempio? Ai primi di Giugno mi chiama il responsabile della documentazione aziendale di un'importante azienda italiana, di cui non farò il nome.

Il suo problema: a seguito della pandemia, i clienti richiedevano training digitalizzati, da fruire attraverso piattaforme LMS (Learning Management Systems) e lui voleva produrrre degli oggetti SCORM a partire dalla documentazione di prodotto, scritta secondo lo standard DITA.

Prima della pandemia, l'azienda forniva sessioni di training face-to face, ma non era più possibile; tuttavia, la necessità di fornire training ai clienti era pressante. 

Ragionando su questo problema, l'azienda in questione si è resa conto che era conveniente intraprendere questa trasformazione INDIPENDENTEMENTE dalla pandemia!

Al netto della soluzione che ho suggerito, il nocciolo della questione è: possiamo ridefinire e digitalizzare processi non solo perchè siamo obbligati dalle circostanze ma perchè è SEMPLICEMENTE CONVENIENTE! 

E questo fa la differenza nell'era della "API economy".

Se le API sono la spina dorsale dei processi di digitalizzazione, non ci vuole un'intelligenza cartesiana per capire quale ruolo può giocare la Comunicazione Tecnica incentrata sulle API.

Per inizare questo percorso, voglio partire dai dati prodotti da una recente indagine condotta da SmartBear.

Io analizzerò solo alcuni aspetti del report (per una lettura completa, potete accedere da qui).


SETTORI INDUSTRIALI COINVOLTI NELL'INDAGINE











Tutti i maggiori settori industriali sono coinvolti e non solo il settore ICT, che ovviamente fa la parte del leone col 28%.


DA QUANTO TEMPO STATE SVILUPPANDO API?

Questa domanda mostra che solo il 18% delle aziende che hanno partecipato al sondaggio stanno sviluppando API da almeno 10 anni, mentre il 29% sta intraprendendo questa strada da 3-5 anni.

Quindi è un'area di sviluppo ancora molto giovane.









PER QUALI MOTIVI STATE SVILUPPANDO API?

Questa è una delle domande  "chiave" del sondaggio, perchè ci da una panoramica delle motivazioni e ci trasmette un dato essenziale: sviluppare API non è "una moda", una specie di "picco" tecnologico frutto di una momentanea espressione del mercato, ma qualcosa destinato a durare da qui ai prossimi 10-15 anni, che nel campo ICT equivale ad un'era geologica!

Come vedete, prevalgono le motivazioni di interoperabilità tra sistemi diversi (64%) e la capacità di estendere una funzionalità nell'ottica di una logica "a servizi" (53%), sullo sfondo di un più generale processo di trasformazione digitale (43%).

Tutte queste motivazioni (e le altre comprese nel grafico) si alimentano a vicenda, in una sinergia che tenderà a crescere nei prossimi anni.


QUALI PARAMETRI DETERMINANO IL SUCCESSO DI UNA API?

E qui iniziamo ad entrare nell'ambito che più ci interessa, cioè nel delineare come la Comunicazione Tecnica viene coinvolta in questo fenomeno. Nella prossima figura ho evidenziato una voce:










E' evidente che se parliamo di Usability/developer experience, questa voce è largamente influenzata dalla documentazione che accompagna l'API. Ma non cadiamo nel luogo comune per il quale la documentazione delle API è ad uso e consume esclusivo degli sviluppatori: vedremo prossimamente che non è proprio del tutto vero.

Ora tralasciamo altri dati interessanti ma più focalizzati sullo specifico dello sviluppo software e continuiamo ad investigare alcuni aspetti della documentazione delle API, un elemento critico nel ciclo di vita delle API. La documentazione può fare la differenza tra una API di successo ed una inusabile.


IN AZIENDA ESISTE UN PROCESSO PER LA DOCUMENTAZIONE DI API?












Dal grafico si capisce chiaramente che, indipendentemente dalla dimensione dell'azienda, esistono processi dedicati alla documentazione delle API almeno nel 57% dei casi (26-100 dipendenti), per arrivare al 69% nelle grandi organizzazioni. Vi è poi circa un terzo delle aziende "piccole" (e circa un quarto delle aziende maggiori) che sta pianificando l'adozione di processi di documentazione delle API.

Ma ora entriamo a "gamba tesa" sul tema che ci interessa: cosa significa documentare un API?


LE 5 COSE PIU' IMPORTANTI PER DOCUMENTARE UN API














Come vedete esistono almeno 16 "tipologie" diverse di "elementi" attraverso i quali si può articolare la documentazione delle API. E sottolineo ALMENO perchè in realtà potremmo aggiungere qualche altra voce. 

Se un'azienda fornisse ai propri clienti una documentazione strutturata attraverso tutti questi elementi, sarebbe di certo da considerare un'azienda "virtuosa". 

In molti casi, sarebbe ottimale indirizzare anche solo alcuni di questi elementi.

Nel prossimo post, ripartiremo dall'ultimo grafico.

A presto!


Leggi questo articolo...

martedì 6 ottobre 2020

DITA events: occasioni A COSTO ZERO da non perdere!

Oggi inizia Adobe DITA World 2020.

E' uno dei maggiori eventi mondiali online nel campo della Comunicazione Tecnica e il maggior evento in assoluto per quanto concerne lo standard DITA.

Come sapete, DITA è lo standard aperto per la strutturazione dei contenuti più diffuso al mondo. Questa è l'occasione più importante che avete per toccare con mano lo "stato dell'arte".

L'evento si struttura su tre giornate ed è animato dai maggiori esperti mondiali del settore.

Nel 2018 ebbi l'onore di essere tra gli speaker e fu un'esperienza eccezionale.

Vi consiglio di iscrivervi, anche perchè gli iscritti possono poi visionare tutti gli interventi con comodo e non necessariamente in direttta.

MA NON E' FINITA QUI!

In data 8 Ototbre 2020, vi segnalo anche  il DCL DITA Day 2020, altro grande evento online sullo standadrd DITA.

ENTRAMBI GLI EVENTI SONO GRATUITI!

Se volete capire l'evoluzione di questo standard, potrete imparare moltissimo in soli 3 giorni.

Registratevi, e ci vediamo in chat durante gli eventi! A presto!

Leggi questo articolo...

domenica 27 settembre 2020

API "economy": quale impatto sulla Comunicazione Tecnica?

Chi realizza informazioni per gli utenti che devono usare una piattaforma software, almeno una volta nella vita si è trovato a dover produrre documentazione relativa alle Application Programming Interface (API).


Le API sono interfacce che espongono le funzionalità di applicazioni software.

Per interagire con una certa funzione dell'applicazione, non dovete conoscere i dettagli di quest'ultima, ma solo alcuni parametri che dovete "passare" ad una certa API, la quale vi restituirà il risultato previsto da quella funzione.

Volendo generalizzare, un API è formata da un insieme di metodi di comunicazione chiaramente definiti. Attraverso tali metodi è possibile richiedere servizi alla piattaforma software, che sia un sistema operativo o altra applicazione.

Io ricordo di aver iniziato a "documentare API" per la prima volta nel 2003, quindi non sono una novità. Ma perché oggi sono diventate così importanti?

Perché oggi lavoriamo normalmente in ecosistemi digitali complessi ed eterogenei, ospitati da architetture Cloud e basati su standard e tecnologie diverse, attraverso applicazioni web che devono cooperare per scambiare un grande volume di dati.

I sistemi IoT (Internet of Things) producono un grande volume di dati che alimentano i repository di Big Data. I motori di intelligenza artificiale (AI) devono essere addestrati da grandi volumi di dati strutturati e non, estratti dai Big Data. Tutti questi flussi informativi devono essere gestiti da solide politiche di Information Security. 

IoT, Big Data, AI, Information Security e altre aree tecnologiche devono lavorare insieme, collegate attraverso reti di grandi dimensioni e completamente integrate per ottenere funzionalità sempre più sofisticate.

Come realizziamo queste architetture complesse? 

L'unica possibilità è fornire insiemi di API che possano essere utilizzate per integrare diversi sistemi digitali, senza che vi sia la necessità di conoscere la struttura dei singoli sistemi.

L' "API Economy" sta diventando il principale motore dell'attività di digitalizzazione, in qualsiasi settore industriale.

Puoi pensare a un'API come a un "livello" che nasconde la natura del sistema sottostante.
È possibile attivare un'API tramite un breve set di parametri.
Questo set di parametri (numerici o testuali) consente di eseguire un'azione precisa sul sistema.

Non è necessario conoscere il motore interno del sistema o tutti i dettagli sui diversi algoritmi implementati. È sufficiente conoscere il set di API di sistema per gestire tutte le interazioni necessarie.

Oggi scrivere la documentazione che accompagna una piattaforma software significa, principalmente, scrivere la documentazione delle API, cioè tutto quello che serve all'utente per utilizzare le API.

Chi è il nostro utente target in tal caso? Di solito, un programmatore.
Perché le API servono a scrivere il codice che permette di costruire gli strati d'integrazione tra due sistemi eterogenei, e questo lavoro è il lavoro degli sviluppatori software.

Questa osservazione non è banale, perché se dovete scrivere per un programmatore, allora sarà bene avere confidenza con l'attività di scrittura del codice e con i più diffusi linguaggi di programmazione.

E qui si apre un primo fronte nell'eterno conflitto tra due posizioni:
  1. Quelli che... "chi scrive la documentazione del prodotto deve essere un esperto del prodotto..."
  2. Quelli che... "un Comunicatore Tecnico può scrivere la  documentazione di qualsiasi prodotto... anzi meno è esperto di una certa tecnologia e meglio è..."
Non sono mai stato un manicheo e non inizierò oggi.

L'esperienza mi ha insegnato che se non hai confidenza con la tecnologia che devi descrivere, puoi comunque fare un buon lavoro, ma probabilmente impiegherai una quantità di tempo superiore a quella che sarebbe stata necessaria se avessi avuto "le mani in pasta" con quella tecnologia.
E LA VELOCITA' è un valore!
Ma questa è un'altra conversazione che riprenderemo più avanti.

Certamente, nel caso della documentazione di API, è opportuno avere una "profonda confidenza" con la programmazione software e questo è un punto da tenere a mente.

A presto.
Leggi questo articolo...

domenica 14 giugno 2020

Un evento online: Because Online ROADSHOW

Nei giorni 23, 24, e 25 Giugno ci sarà un evento online da non perdere, soprattutto se siete dei professionisti della Comunicazione Tecnica.




In tempi di COVID-19, quando qualsiasi conferenza frontale è stata di fatto neutralizzata, abbiamo scoperto l'utilità dei processi digitalizzati e delle comunicazioni remotizzate.

E il primo ROADSHOW della Because si inserisce perfettamente in questo contesto.

Tre giornate (2 ore e mezza ogni giorno) in cui diversi professionisti del settore si avvicenderanno in uno schema di lavoro molto flessibile per parlare di diversi aspetti:
  • GIORNO 1 (23 Giugno): Creazione di contenuti tecnici
  • GIORNO 2 (24 Giugno): La tecnologia al servizio delle lingue
  • GIORNO 3 (25 Giugno): CCMS & Content Delivery
Io sarò presente il primo giorno e metterò a disposizione il mio punto di vista e la mia esperienza sulle tematiche del processo redazionale.

Vi invito a partecipare perchè occasioni come queste sono rare in Italia, probabilmente uniche, almeno per tutto il 2020.

Vi aspetto.

Leggi questo articolo...

domenica 31 maggio 2020

Comunicazione Tecnica e COVID-19: quali impatti sulla professione

La pandemia mondiale ha avuto un impatto fortissimo su diversi aspetti della nostra vita, e largamente sulla nostra vita professionale.

Il collega Tom Johnson, autore di uno dei più importanti blog sulla scrittura tecnica, ha preso l'iniziativa di costruire un sondaggio al fine di indagare in che modo la professione del Com Tecnico sia stata "tocccata" dal COVID-19.

E i risultati sono molto interessanti.
Ad esempio, durante la pandemia solo il 4.76% dei partecipanti ha perso il proprio lavoro.

Il sondaggio è ancora aperto e vi invito a partecipare. Per ora, l'Italia ha contribuito con due partecipanti su 256 (ed uno dei due sono io).

Come sapete, in Italia non ci sono dati pubblici sulla nostra professione; non si fanno sondaggi tematici di alcun genere, e quindi non abbiamo alcun dato nel contesto nazionale.
Quindi varrebbe la pena partecipare a queste iniziative, per provare a dare un contributo basato sulle esperienze dei professionisti italiani. Leggi questo articolo...

venerdì 3 aprile 2020

Un elenco aggiornato delle norme armonizzate inerenti alla Direttiva Macchine 2006/42/CE

Il 2 aprile 2020 la Commissione Europea ha pubblicato un elenco aggiornato delle norme armonizzate relative alla Direttiva macchine (2006/42/CE).

Tali norme possono essere utilizzate dai produttori di macchinari per dimostrare che i loro macchinari sono conformi alla Direttiva Macchine.

L'elenco aggiornato è importante per i produttori di macchine marcate CE che hanno utilizzato norme armonizzate per dimostrare la conformità CE.

Controllate il nuovo elenco per verificare se uno degli standard applicati è stato aggiornato o se sono disponibili nuovi standard. Tenete presente che se una norma armonizzata viene aggiornata è necessario rivalutare i prodotti e aggiornare la Dichiarazione di Conformità.

In alcuni casi può accadere che solo alcune parti di uno standard risultino armonizzate.

Ad esempio, lo standard EN ISO 20607: 2019 è ora uno standard armonizzato.
Ma non "integralmente": solo alcune parti della norma sono armonizzate (vedi Annex ZA).

Ad esempio, sono armonizzate le clausole 4 e 5, ma non la 6.

A presto.

Leggi questo articolo...

domenica 2 febbraio 2020

Tecnologie ICT e standardizzazione: a che punto siamo?

Nel mese di Gennaio sono entrato a far parte del gruppo ISO/IEC JTC1/SC7/WG 2 "System software documentation", attraverso l'adesione ad UNINFO - UNI/CT 504 "Ingegneria del Software.

Questa opportunità è scaturita dopo aver partecipato, in qualità di membro del Advisory Board for Standard & Legislation della Tekom Europe, ai lavori di revisione dello standard ISO/IEC/IEEE_26514.

Questo gruppo di lavoro ISO è diretto da JoAnn Hackos e lavorare con lei è stato un onore; quando nel 2005 ho iniziato a fare questo lavoro, studiavo sui suoi libri.

Ora mi trovo a condividere idee e orientamenti con lei e altri colleghi di tutto il mondo, ed è un'esperienza molto formativa.

E in questo solco, vi segnalo un report prodotto dalla StandICT.eu.

Il report è basato sul contributo dei singoli esperti europei che hanno lavorato alla standardizzazione delle tecnologie ICT.

Nel report trovate un elenco di 178 nomi, ma la cosa più interessante è vedere in quali aree si sta lavorando (gruppi di standardizzazione ISO/IEEE, consorzi internazionali, etc.) per intuire come ci si sta muovendo in Europa (e non solo) in alcuni settori quali Blockchain, Security, 5G, Internet of Things, AI ed altro.

Il report lo potete scaricare da questo link.

Buona lettura. Leggi questo articolo...

sabato 9 novembre 2019

Minimalismo: mettiamo in ordine le idee

Vi segnalo questo articolo in cui Ferry Vermeulen intervista il Prof. Hans van der Meij, considerato il maggior esperto del Minimalismo.
E' un'occasione da non perdere, per due motivi:

  • Non capita spesso di poter accedere "direttamente" alla sorgente della conoscenza di un determinato argomento.
  • Sul Minimalismo c'è da sempre molta confusione... conviene chiarirsi le idee.
Il Minimalismo è una filosofia per la redazione dei contenuti che si basa su 4 principi:

  1. Orientato all’azione.
  2. Associazione tra lo strumento e il compito da eseguire. 
  3. Supporto al riconoscimento e alla risoluzione degli errori.
  4. Fornire all’utente le informazioni essenziali e lasciarlo libero di scoprire i dettagli in autonomia.

I primi due principi significano "orientati al processo" (Task Oriented)
Il terzo significa "risoluzione dei problemi" (Troubleshooting)
Il quarto significa "sintesi sul contesto" (Context Oriented)

Tutto semplice vero? Parrebbe di no.

Nell'ultima versione dello standard IEC IEEE 82079-1, al paragrafo 5.5.3 viene fornita una definizione di Minimalismo... vagamente imprecisa:

Minimalism is an approach to information for use that includes
critical information and the least amount of other information needed to be complete. Critical information includes the safe use of the product, the security of the information created with the product, or the privacy of the information created by or stored with the product.

Questa NON E' LA DEFINIZIONE DI MINIMALISMO... e credo che su questo punto ci siano pochi dubbi.

Il MInimalismo, peraltro, ha ispirato anche alcune caratteristiche di DITA, lo standard più diffuso al mondo per l'ingegnerizzazione dei contenuti.

Ad esempio, nella versione 1.3 di DITA, è stato introdotto il Troubleshooting Topic Type, che va a mappare proprio il principio n°3.

Quindi, andate sul sito di Ferry e seguite le risposte del Prof. Hans van der Meij.
A presto.


Leggi questo articolo...

martedì 3 settembre 2019

Un brevetto per la sincronizzazione dei contenuti

Da qualche tempo è disponibile su Google Patent il brevetto che ho ideato nelle prime settimane del 2015, mentre lavoravo in IBM:

ON DEMAND SYNCHRONIZATION OF INFORMATION
(Sincronizzazione delle informazioni su richiesta)

Di che si tratta? Di un'idea finalizzata a risolvere un problema classico delle grandi (ma anche delle piccole) organizzazioni: la proliferazione di silos di contenuti completamente scorrelati e disallineati.

Sul tema sono stati scritti fiumi d'inchiostro, spesso invano, nonostante le migliori intenzioni di alcuni manager aziendali "illuminati" e la disponibilità di tecnologie e best practice adatte allo scopo.

A questo punto, è necessario un breve flash-back.

Arrivato in IBM nel ruolo di Documentation Manager di CrossIdeas, ed essendo quindi il massimo esperto della documentazione della piattaforma IDEAS, nei primi mesi di lavoro venni contattato da diversi colleghi di altre aree (training, marketing, integration, etc) che sviluppavano contenuti inerenti al prodotto.

Di fatto, vidi in presa diretta lo sviluppo di diversi "silos" di contenuti.



Inizialmente, tali silos erano legati alla "radice" della documentazione tecnica di prodotto.
Ma in seguito e per tutta una serie di ovvie ragioni, queste aree tendevano a procedere con un certo grado di autonomia, costituendo silos informativi potenzialmente disallineati.

Mi resi conto che questa dinamica implicava un problema: nel momento in cui apportavo una modifica "significativa" alla doc di prodotto (sorgente), questa modifica doveva essere comunicata a tutti i referenti interessati.

Non sarebbe stato opportuno instaurare un "automatismo" per tenere allineati i diversi silos?

Da questa banale osservazione, ideai una generalizzazione della soluzione dell'allineamento dei silos (ATTENZIONE! NON DELL'ELIMINAZIONE DEI SILOS... cosa che ritengo impossibile, specialmente nelle grandi organizzazioni... ma questa è un'altra conversazione).

L'idea è semplice:

  1. Un UTILIZZATORE di contenuti elegge una SORGENTE AFFIDABILE di contenuti e instaura un CONTRATTO con la sorgente.
  2. L'utilizzatore può includere nei suoi documenti dei contenuti pubblicati dalla sorgente.
  3. Quando un contenuto della sorgente cambia, l'utilizzatore ha la possibilità (mai l'obbligo) di aggiornare AUTOMATICAMENTE la variazione.
  4. In questo modo, i documenti dell'utilizzatore sono sempre allineabili con la sorgente.


UN ESEMPIO SEMPLICE

Immaginate di utilizzare delle tabelle della FAO in una presentazione.
Le tabelle, nel tempo, cambiano. Se volete essere certi di utilizzare sempre la tabella più recente, magari dovete andare ogni tanto sul sito della FAO e verificare eventuali variazioni.
Se la tabella è cambiata, dovete decidere se prendere la nuova tabella e aggiornare la presentazione oppure no.

Il paradigma è "L'UTENTE CHE CERCA L'INFORMAZIONE"... ricordate?
Questo paradigma è SEMPLICEMENTE il paradigma SBAGLIATO!

Non sarebbe meglio avere un meccanismo che, al variare della tabella, trasferisce automaticamente la tabella aggiornata nella mia presentazione? Cioè "L'INFORMAZIONE CHE CERCA L'UTENTE"... il paradigma giusto!

Ora allarghiamo il campo di gioco.

Immaginate di avere N documenti che attingono da K sorgenti (di solito con N>K). Ora, al variare dei contenuti di K sorgenti, dovete andare periodicamente a verificare se non sia necessario aggiornare "a mano" gli N documenti.

In questo gioco, voi perdete sempre e perdete tanto più velocemente quanto più alti sono i valori di N e K.

Se invece avete K contratti con le K sorgenti, potete allineare gli N documenti in modo quasi indolore. Ora non entro nei dettagli tecnici del meccanismo (content tagging, notifica della variazione, accettazione, etc), che potete approfondire leggendo il brevetto.

Si pone una sola ipotesi: la sorgente espone contenuti attraverso un linguaggio taggato (XML, HTML, etc).

La bontà del brevetto consiste nel non fare nessuna assunzione specifica sul:

  • tipo della sorgente
  • numero di sorgenti
  • contenuti della sorgente
  • tipo/formato di documenti collegati alla sorgente

Per la precisione, il brevetto è stato realizzato grazie alla preziosa collaborazione di altri 4 colleghi:
Cristina Bonanni, Patrizia Manganelli, Andrea Durastante e Andrea Di Maio.
Devo sottolineare il fondamentale apporto di Cristina e Patriza, perchè io ero al primo brevetto mentre loro avevano già alle spalle diversi brevetti e la loro esperienza è stata decisiva nella formalizzazione di questa intuizione.

Il brevetto è attualmente di proprietà della IBM, a cui abbiamo ceduto tutti i diritti.

Se l'argomento vi interessa e volete approfondirlo mi potete contattare.

Ciao. Leggi questo articolo...

mercoledì 22 maggio 2019

Breve guida al nuovo standard IEC / IEEE 82079-1: 2019

Il 16/5/2019 è’ stato pubblicato lo standard IEC / IEEE 82079-1: 2019 che sostituisce la prima edizione, IEC 82079-1: 2012

Lo standard fornisce i principi generali per la progettazione e la formulazione delle istruzioni per l'uso di prodotti di tutti i tipi, da un frigorifero domestico, ad un software o a prodotti di grandi dimensioni o molto complessi, come un trattore o grandi macchinari industriali.

Questa edizione, rispetto alla precedente, include notevoli modifiche.

NUOVA STRUTTURA
Una  riorganizzazione della struttura del documento, per facilitare l'applicazione dello standard e la ricerca di informazioni.

INFORMAZIONI PER L'USO... e non documentazione
Le informazioni per l'uso sono introdotte come termine generico.
Le istruzioni per l'uso sono sinonimo di informazioni per l'uso.
Questo approccio riflette una tendenza che si orienta nel rimuovere il termine “documentazione” che tradizionalmente richiama l’idea di una forma documentale cartacea. Oggi le informazioni per l’uso necessarie ad utilizzare un prodotto possono assumere diversi formati digitali (oltre al sempre possibile formato cartaceo) e quindi il termine “informazioni per l’uso” risulta molto più flessibile.

PRINCIPI
Il Capitolo 5 si concentra sullo scopo delle informazioni per l'uso, sulla qualità e sul processo di gestione delle informazioni.

GESTIONE
Il Capitolo 6 definisce gli elementi principali del processo di gestione delle informazioni per l'uso. Vengono forniti i criteri di riferimento per la definizione del “processo redazionale” , innervata da alcuni elementi di project management, risk management, quality assurance e test dei contenuti.

CONTENUTI
Il Capitolo 7 entra nel dettaglio di cosa deve essere contenuto nelle informazioni per l’uso.
Tra i molti aspetti trattati, mi preme orientarvi sul paragrafo 7.11, che parla degli aspetti relativi alla sicurezza e di come le tematiche di sicurezza devono essere gestite nella definizione delle informazioni per l’uso “sicuro” di un prodotto.

STRUTTURA
Il Capitolo 8 parla della struttura delle informazioni per l’uso.
In particolare, nel paragrafo 8.2 si delinea la distinzione tra tre tipi di informazioni:

  • concept
  • task
  • reference

Quindi, chi adotta uno standard come DITA, automaticamente si ritrova ad essere conforme con questa area dello standard.
Inoltre, nel paragrafo 8.4.3.2 si indica il concetto di “context sensitivity” (riferita in particolare alle informazioni per l’uso fruite attraverso dispositivi digitali).
Ne riparleremo presto, perché su questo concetto si basa il futuro della Comunicazione Tecnica: context-based e user-based, ma definita dinamicamente e non pre-determinata (se non nelle componenti molecolari).

FORMATO
Nel Capitolo 9 si fa riferimento ai diversi formati con i quali possono essere distribuite le informazioni per l'uso.

CHECK-LIST DI CONFORMITA'
Infine, tra gli allegati, una check-list per verificare se le vostre informazioni per l’uso sono conformi allo standard.

Questo standard deve essere noto a tutti coloro che sono coinvolti nella concettualizzazione, creazione, manutenzione, traduzione, localizzazione, integrazione di contenuti, produzione, e valutazione delle informazioni per l'uso associate ad un prodotto.

Infine, voglio sottolineare come questo deve essere inteso come uno standard “orizzontale”, che si propone come lo standard di riferimento per la redazione di qualsiasi tipo di informazione per l’uso, per qualsiasi prodotto.

Se volete prendere in visione un estratto ridotto dello standard, compreso l’indice dei contenuti, potete accedere a questo link.

Leggi questo articolo...