Traduzione a cura di Seti Srl

Ciò che vedete è ciò che ottenete (What You See Is What You Get): per molto tempo questo è stato uno degli acronimi più importanti nel campo del desktop publishing (editoria personale). Se lo strumento di creazione non era targato "WYSIWYG", era ritenuto disperatamente antiquato. Ovviamente era vostro desiderio che il "vostro" ambiente di compilazione (editing) offrisse un'anteprima istantanea di come il contenuto sarebbe apparso su supporto cartaceo. Chi non desidererebbe vedere in anteprima ciò che otterrà?

Ebbene, grazie alla crescente importanza del "single-sourcing" (fornitore unico) ( pubblicazione dello stesso contenuto in diversi formati in uscita) e del riutilizzo (riutilizzo di bit e di parti da un documento ad un altro), il WYSIWYG ha perso molto del suo fascino. E mentre la composizione strutturata sta assumendo un ruolo centrale sempre più crescente nel mondo della documentazione tecnica, tocca ora agli strumenti WYSIWYG apparire fuori moda.
Il nuovo arrivato si chiama XML e gli ambienti di editing "pure XML" possono contare su un interesse pubblico maggiore di quanto non abbiano mai goduto i loro predecessori SGML o HTML. Ma "pure XML" è realmente migliore del WYSIWYG? Perché gli strumenti XML, comprese le anteprime sottobanco dei possibili risultati , sono preminenti? Esiste un altro paradigma che concilia le virtù del vero XML con il comfort del WYSIWIG?

In principio fu il Verbo (e non molto altro)

Prima dell'era del desktop publishing , quando la maggior parte delle persone utilizzava degli editor di testo che giravano su DOS o UNIX, la formattazione era chiamata composizione ed era realizzata da specialisti presso aziende che si occupavano di stampa. All'epoca, gli autori erano dei veri scrittori, dei produttori di contenuti, scevri dall'onere di far apparire "bello" il loro lavoro in forma "stampata". Sia tale compito sia la corrispondente responsabilità gravavano su qualcun altro. L'autore era responsabile unicamente della correttezza e della completezza del contenuto.
In assenza di formati, gli autori dovevano annotare il loro testo puro e semplice con le relative istruzioni per i compilatori professionali: rendere questo titolo in caratteri più grandi, aggiungere elenchi puntati a queste frasi, ecc. E in molti casi, il compilatore poteva, in misura maggiore o minore, determinare la larghezza dei titoli e il tipo di carattere puntato particolare da utilizzare. Gli autori creavano il contenuto, i compilatori si occupavano della formattazione/preparazione.
Anche dopo la conquista del posto di lavoro da parte di Windows e dopo che gli stampatori digitali avevano consentito la trasformazione del lavoro dei compilatori nella formattazione assistita da computer, tali lavori di formattazione erano largamente lasciati ai professionisti con programmi particolari di layout di pagina fatti spesso "girare" su dei Mac.
Ricordo ancora i tempi in cui ero l'unico dipendente in possesso di un Mac presso una società tedesca di computer di alto livello, che raccoglieva dati in entrata da tutti gli uffici e che li elaborava di notte trasferendoli in un manuale di 150 pagine per un super computer che alla fine non venne mai costruito. L'unico modo per portare a termine quel lavoro prima della scadenza era quello di rimuovere tutta la formattazione da qualsiasi informazione in entrata ricevuta e di riapplicare rigorosamente i tag di formato. Se solo avessi avuto un input XML, un editor con le capacità XSLT e un motore decente di editoria (publishing) – avrei potuto godere di un paio di ore di sonno la notte. Ma sto andando oltre e quindi facciamo un passo indietro.

Gli affanni del WYSIWYG

Con l'introduzione dei software di desktop publishing, meno costosi e caratterizzati da un più facile utilizzo, la creazione di contenuti formattati divenne alla portata di tutti. Gradualmente, vennero introdotte capacità sempre più sofisticate di formattazione negli editor comuni come Microsoft Word. Con l'affermazione che il risultato a video sarebbe stato identico a quello che la stampante avrebbe riprodotto su carta, gli autori iniziarono a preoccuparsi del risultato, cercando di fare in modo che la formattazione potesse combaciare con le loro preferenze personali.
Alla formattazione alla portata di tutte le persone, nella maggior parte dei casi, però, non addestrate a livello formale, seguì una pletora di stili. Alcuni vennero strutturati graziosamente, utilizzando stili e nessun override, ma la maggior parte di questi furono semplicemente introdotti "ad hoc" utilizzando i pulsanti di formattazione che erano i più semplici da utilizzare: sottolineatura, neretto, corsivo e dimensione carattere. Ho potuto vedere documenti di enorme lunghezza che consistevano interamente di stile "Normal" con migliaia di override per i singoli paragrafi, frasi, parole o anche singoli caratteri. In questi documenti, modificare lo stile di partenza – o anche solo applicarlo per la prima volta – diventava un incubo.
WYSIWYG prometteva di permettere a chiunque di usufruire delle capacità della vera editoria sul proprio desktop, ma non informava la gente dei "mostri nascosti" e delle "tigri in agguato" che accompagnavano questo paradigma. Il contenuto e la formattazione si mescolarono in un singolo ambiente di composizione. É con l'aumento della quantità di caratteristiche di formattazione che furono aggiunte ad ogni nuova versione di ogni editor di testo, arrivarono anche nuovi livelli di dipendenza tra il contenuto puro e semplice e il modo in cui esso veniva reso.

Figura 1: Le opzioni di formattazione invadono tutto lo spazio della barra strumenti in Word.

Il problema peggiorò quando la stessa sorgente iniziò ad essere utilizzata per diversi formati in uscita: non solo per la stampa ma anche CHM, WebHelp e, infine, una serie di output per i PDA, per i telefoni mobili e per i tablet. Per il momento, il "single-sourcing" (fornitore unico) sembrava una buona idea, ma non lo sarebbe stato nel caso aveste deciso di tenere sotto controllo la formattazione come indicato dagli editor WYSIWYG. Con la "single-sourcing", la promessa del WYSIWYG venne infranta nella maggior parte dei risultati. Sì, potete sicuramente far sembrare "buono" il contenuto di un formato in uscita, ma se desiderate riutilizzare lo stesso contenuto per un formato completamente diverso, i risultati che potreste ottenere sarebbero completamente inutili. Ed anche se sembra andare bene nel vostro browser, un utilizzatore potrebbe aumentare le dimensioni del carattere nel proprio browser e "rovinare" la vostra pagina HTML tanto attentamente preparata. Forse bisognerebbe aggiungere il termine "In Print" all'acronimo, facendolo diventare "WYSIWYGIP".

Un nuovo arrivo nella "città della creazione tecnica"

Contemporaneamente alla richiesta di "single-sourcing" sorse anche la necessità di disporre di diversi formati del prodotto ottenuto (output) e, all'epoca, il formato più importante era l'HTML. Mentre alcuni ambienti di authoring (progettazione) dotati della funzione Help in linea si basavano sul sistema Word (mantenendo così quanto più possibile il parco clienti all'interno del loro ambiente sicuro) - successivamente trasformato in HTML - altri prodotti come ad esempio il RoboHelp convertirono l'HTML nell'ambiente di lavoro dell'autore (dal quale, se necessario, il contenuto poteva essere esportato in Word). Con tale approccio, applicare diversi fogli di stile al medesimo contenuto in diversi livelli "single-source" consentiva di separare in qualche modo il contenuto dalla formattazione. In ogni caso, i tag HTML erano principalmente definiti come tag di formattazione, più o meno come gli stili di paragrafo e di carattere applicati in un documento di Word o di FrameMaker.
Fece quindi la sua apparizione l'XML. Improvvisamente la separazione tra contenuto e formattazione divenne molto più profonda, in quanto i tag non erano più legati alla formattazione in modo immediato. I tag semantici introdussero un livello aggiuntivo tra il contenuto e la formattazione e nel quale il contenuto stava per essere reso graficamente (rendered). Nello standard DITA 1.2, ad esempio, designare un argomento un <task> o un <concept> poteva causare o meno delle differenze nel formato applicato all'elemento figlio <title>. Le diversità nella formattazione potevano anche dipendere dall'output che era stato selezionato; le opzioni di formattazione offerte dai Kindles non sono così ampie come il PDF, ma i tablet ne offrono molte di più.
Mettere i label semantici nei file per definire il significato di ogni voce del contenuto e la sua posizione nella struttura sottostante del documento fu la sola e più importante modifica nella documentazione tecnica per questo tipo di lavoro dall'introduzione dei personal computer. Di punto in bianco, i software intelligenti sono in grado di recuperare le informazioni dai documenti XML basandosi sui label semantici significativi. E'possibile dire ad una piccola parte di software di prendere l'elenco delle <supplies> da un <task> ed inviarlo al <warehouse employee> il quale prepara gli imballi delle forniture per i <maintenance engineers>. Se, nella documentazione tecnica, tutte queste informazioni sono disponibili e sono contrassegnate da label semantici, il software è in grado di trovarle e di elaborarle. Nello stesso identico modo, è possibile elaborare la Distinta Materiali di una macchina trasformandola in un catalogo di parti di ricambio senza bisogno di alcun intervento umano.
L'XML offriva un vantaggio ancora maggiore rispetto agli ambienti di editing: l'autore che creava un contenuto XML, non doveva più dipendere da uno strumento di composizione specifico (authoring tool). Era possibile utilizzare qualsiasi editor di testo poiché i label semantici erano essi stessi espressi nello stesso testo come il contenuto, e a tale scopo veniva fatto uso di parentesi graffe per distinguerli dal contenuto. L'XML non è solo Xtensibile, è anche Xcambiabile [il suono /x/ non funziona in italiano perché le parole iniziano in modo diverso] (Xtensible and Xchangeable).

PureXML e le performance dell'autore

Ovviamente, qualcuno – il redattore tecnico – deve innanzitutto introdurre le informazioni di formattazione nel contenuto. E deve utilizzare i label semantici per contraddistinguere il contenuto anziché applicare i soliti <h1>, <b>, <i> e gli altri tag di formattazione hanno modificato le esigenze degli strumenti di editing. I tag dovevano diventare visibili per consentire ai redattori tecnici di vedere quale semantica essi stessero applicando.
Negli editor "pure XML", i tag appaiono come tag e tutta la formattazione del testo viene rimossa. I tag possono essere visualizzati in rosso e gli attributi in blu, proprio per fare in modo che i metadati risaltino rispetto al contenuto. Il fatto che la maggior parte degli editor XML sia dotata di un'opzione che indichi che vi potrebbe essere qualche cosa di errato con la nozione, consente agli autori, grazie all'editing del pure XML, di avere maggiore efficacia nel creare un ottimo contenuto.

Figura 2: Editor oXygen di SyncRO Soft che illustra un task DITA con visualizzazione XML

E' vero, i redattori non sono più tentati dal mettere a punto il loro contenuto in modo da adattarlo alla pagina o da farlo combaciare con le proprie preferenze di formattazione. Ma come si ritiene che i redattori possano capire se la struttura nel contenuto è realmente quella che essi intendono esprimere? Se avete un file lungo con passi ed elenchi ed elenchi nidificati, come possono i tag aiutarvi a scoprire che una particolare voce è stata nidificata ad un livello troppo profondo? E se siete nuovi all'editing strutturato e all'XML, come potrete sopravvivere a questo paradigma totalmente nuovo in cui dovete scegliere un tag fra quelli disponibili in un lungo catalogo e creare delle anteprime di output per vedere se ciò è realmente ciò che intendevate fare?

La risposta è l'WYSIWYM

In realtà, mentre creano il loro contenuto, i redattori ne sono anche i lettori. Mentre stanno creando un contenuto con una data struttura, essi devono controllare la correttezza sia del contenuto che della struttura. Lasciare ad essi il compito di leggere ed interpretare i tag e di visualizzare il risultato voluto nella loro mente, li sobbarca di un notevole peso ed introduce il fattore dell'errore umano che non è necessario.
Dopo tutto, la struttura di un documento deve essere espressa in una qualche formattazione, in caso contrario i lettori del risultato finale non saranno in grado di capire che cosa è quella struttura. Non tutti i dettagli devono necessariamente essere visibili, ma sono necessari almeno alcuni segnali affinché il risultato sia del tutto leggibile. E qualche formattazione, anche se non strettamente richiesta, è talmente utile che sarebbe un peccato non utilizzarla. Un elemento in un argomento può ricevere l'icona che rappresenta un martello e un cacciavite per indicare che si tratta di un compito. Lo stesso elemento in un<concept> potrebbe avere l'icona di una lampadina. La struttura è espressa attraverso gli elementi di formattazione e se questi elementi sono definiti in modo efficace, i lettori capiranno rapidamente la struttura del contenuto e sapranno immediatamente dove trovare le informazioni che stanno cercando.
Il mercato degli ambienti tecnici di progettazione ha messo in luce la necessità che i redattori hanno di vedere almeno un minimo di formattazione mentre procedono alla creazione del contenuto. Questo tipo di supporto è stato aggiunto nella maggior parte o nella totalità degli ambienti XML di punta. In molti casi, quest' interfaccia utente è chiamata "Author View". In questo tipo di visualizzazione, il documento XML non somiglia affatto all'XML. Al contrario, esso sembra un documento di Word o di FrameMaker con i limiti della pagina (intestazioni, piè di pagina, numeri di pagina) rimossi. Questi tipi di interfaccia utente sono noti con l'acronimo WYSIWYM: What You See Is What You Mean (Ciò che vedi è ciò che intendi).
Spesso, l'interfaccia "Author View" è combinata con qualche tipo di panoramica della struttura in una finestra o in una finestra temporanea separata dall'interfaccia utente. Il sistema Oxygen di SyncRO Soft offre, oltre al catalogo elementi, una visualizzazione del profilo ed aggiunge un tool di navigazione nella barra del menu per segnalare dove si trovi l'utente nella struttura del documento. Ma le barre strumenti, i menu di contesto e le finestre temporanee aggiuntive ed opzionali creano confusione, se non addirittura spavento, a molti neofiti del sistema XML.
Nella nuova versione di FrameMaker, la ben nota interfaccia WYSIWYG (ovviamente per documenti stampati) è ora accompagnata sia dalla visualizzazione "pure XML" che da Author View. In questo caso, la visualizzazione del redattore WYSIWYM è veramente fondamentale nell'offrire solo ciò di cui il redattore strutturato ha realmente bisogno: la visualizzazione della struttura per facilitare la navigazione e in più una finestra di creazione (authoring) che illustra le variabili mete sintattiche, i menu del contesto, un catalogo elementi per l'inserzione degli stessi e solo quelle barre strumenti di cui il redattore dovesse mai aver bisogno per procedere alla creazione di un contenuto strutturato.

Figura 3: FrameMaker 11 che visualizza un documento DITA con la nuova Author View.

L'anteprima istantanea di WYSIWYM arriva senza la falsa promessa di WYSIWYG. E' pensata come un'anteprima approssimativa, utile unicamente per controllare se la struttura sia corretta e per consentire all'utente di concentrarsi sul contenuto durante l'operazione di creazione. Essa assomma il meglio di entrambi i mondi: la separazione tra il contenuto e la formattazione offerta da "pure XML" con in più il comfort e il lusso degli editor con cui si ha larga familiarità. Elimina il goffo aspetto del vero XML come pure la tentazione del WYSIWYG di aggiustare il contenuto per meglio adattarlo alla pagina. Non vi sono pagine e non vi sono comandi di formattazione. C'è solo il contenuto e la struttura visibile – non visualizzabile.

Jang F.M. Graat ha seguito studi di Fisica, Psicologia e Filosofia prima di iniziare la propria carriera nel settore internazionale dei computer High-Tech. Ha lavorato come redattore tecnico e addestratore per oltre 20 anni ed attualmente gestisce una propria società di comunicazione ad Amsterdam.

jang[at]jang.nl
www.jang.nl