Uno dei cambiamenti più importanti nell’utilizzo del computer alla fine degli anni ottanta, inizio degli anni novanta, è stata l’introduzione del WYSIWYG, ciò che vedi è ciò che ottieni, specie per tutto ciò che aveva a che fare con la stampa. Non solo il DTP, ma anche il word processing sono stati fortemente influenzati dalle interfacce che mostravano su video esattamente (o quasi) quello che sarebbe uscito in stampa. Voglio un bodoni bold 18pt, vedo un bodoni bold 18pt, ottengo un bodoni bold 18pt. Dopo il WYSIWYG l’umanità a contatto con una tastiera e una stampante è diventata una collettività di grafici. Comic sans lo sa.

Effettivamente quello che rimane del processo di produzione del testo improntato alla stampa, è quello che rimane sul foglio. WYSIWYG funziona benissimo per la stampa su carta perché sulla carta rimane attaccato solo l’inchiostro o il toner: davvero nella carta stampata ottengo ciò che vedo a video. Al di fuori dei segni non c’è altro e tutto deve essere risolto in quello che si vede. Spazi, lettering, grafica.

Non è l’unica modalità di progettazione, altro acronimo utilizzato è quello del WYSIWYM, ciò che vedi è ciò intendi. Con questo tipo di progettazione chi scrive/impagina, non vede il risultato grafico, ma vede i comandi di formattazione. È un sistema tipico di linguaggi come latex, html o xml.

Arrivo al punto: da tempo e da più parti si sta cercando l’araba fenice, ovvero un equivalente di Word/Indesign per la creazione di ebook. Un tool basato su un WYSIWYG che permetta alle redazioni di creare ebook senza, cito parole testuali ascoltate qualche giorno fa, “aver bisogno di un ingegnere per fare un libro” (risate della sala).

È una richiesta legittima, ma con diverse controindicazioni.

La prima è che un ingegnere, in una redazione che deve comporre testi digitali, farebbe solo bene. Del gran bene. Perché, e siamo già alla seconda controindicazione, un testo digitale non è solo quello che ottieni. La parte di testo che viene composta per essere letta dal lettore, quella che, tanto per capirci, in un libro di carta andrebbe stampata, è solo una piccola parte di quella che viene composta in fase di progettazione digitale.

Il testo digitale è come il mare, lascia affiorare alcune cose, ma sotto alla superficie dell’acqua possono esserci ancora un sacco di cose da usare. Vedo un’immagine, ma sotto l’acqua c’è la descrizione dell’immagine che può essere ascoltata con uno screen reader. Leggo un avvenimento storico e sotto l’acqua c’è la data e le correlazioni con altri avvenimenti, che la redazione potrà usare per creare la cronologia storica interattiva. Leggo un verso di una poesia e sotto c’è la sua traduzione in inglese, in modo da farla apparire toccando il verso stesso.

La controindicazione più grossa del WYSIWYG, insomma, è fare dei testi digitali che assomiglino alla carta, ovvero al risultato che si vede, e non alla costruzione di un ambiente di informazioni, in cui queste informazioni che non si vedono possono essere processate per fare cose.

Questa cosa di non avere il WYSIWYG spaventa. Siamo abituati all’ottenimento immediato di quello che si vede, e di considerarlo come prodotto finale, che l’uso di cose che non si vedono sembra uno spreco. Che senso ha codificare cose che il lettore non vede?

È invece vero il contrario. L’ingegnerizzazione di un contenuto redazionale permette di abbattere drasticamente i costi redazionali per realizzarlo. Nel momento in cui non realizzo più un testo che si deve vedere in un solo modo, ho maggiore facilità di creare modi diversi che interrogano il mio ambiente di lettura per ottenere diversi prodotti editoriali. Se faccio entrare l’ingegnere (magari umanistico) in redazione, certi processi meccanici che vedo ancora fare a mano, li faccio fare alla macchina.

Che, per quanto possa sembrare cosa strana, è nata per quello.

BZ34ow1IUAAp_h4.png-large

(continua)

Advertisements