Un materiale formativo distribuito su CD-ROM resta leggibile finché esiste il software che lo apre, e dal formato dipende se quel software è un browser conforme a standard pubblici o il runtime di un singolo fornitore. La differenza non si vede al collaudo, quando tutto gira sul portatile di chi lo ha prodotto. Si vede tre anni dopo, su un’altra macchina, con un sistema operativo aggiornato e il fornitore del runtime che nel frattempo ha cambiato versione o ha chiuso.

Ho lavorato alla produzione di un CD-ROM didattico sull’autovalutazione dei corsi di studio per la Fondazione CRUI (Conferenza dei Rettori delle Università Italiane), dentro le attività sulla qualità della didattica che nascono dal progetto CampusOne. Il contenuto è materiale di metodo: procedure di analisi interna, indicatori, schede di riferimento per gli atenei. Niente di effimero. Proprio per questo il modo in cui lo si impacchetta pesa più di quanto sembri.

Contesto

Nel 2006 un CD-ROM «multimediale» si confeziona di solito con un autore proprietario — Macromedia Director con i .dcr di Shockwave, un eseguibile Flash, oppure un menu compilato con un generatore di autorun per Windows. Il risultato apre pulito al collaudo e produce un unico file che parte con il doppio clic. Il costo resta nascosto finché non si presenta: il contenuto è leggibile solo dove gira quel player, in quella versione, su quel sistema operativo.

Per un materiale istituzionale che deve girare negli atenei per anni, è qui il problema centrale. Un ateneo non ha un parco macchine omogeneo, e un CD-ROM stampato non si tocca più: quello che ci è inciso deve restare apribile, e non si può pubblicare un aggiornamento.

Architettura

La struttura che ho adottato tiene separati tre livelli, ognuno ancorato a una specifica pubblica.

Il filesystem è ISO 9660, lo standard ISO già del 1988, disponibile gratis come ECMA-119 (https://ecma-international.org/publications-and-standards/standards/ecma-119/). Un disco ISO 9660 conforme si legge su sistemi e architetture diverse. Per i nomi lunghi e Unicode si aggiungono le estensioni Joliet (Microsoft) per Windows e Rock Ridge per i sistemi POSIX: un disco ibrido le porta entrambe nello stesso master, così lo stesso albero di file si legge sotto Windows, Mac OS X e Linux senza fare copie separate.

Il contenuto è XHTML 1.0 e CSS. XHTML 1.0 è Raccomandazione W3C nella seconda edizione dell’agosto 2002 (https://www.w3.org/TR/2002/REC-xhtml1-20020801/); per la presentazione resto su CSS livello 2 — Raccomandazione del 1998 — e di CSS 2.1 (a oggi ancora Working Draft, ultima revisione giugno 2005) prendo solo ciò che i browser implementano in modo stabile. Le pagine sono file statici su disco. La navigazione non lineare fra le sezioni è una rete di link relativi: nessun server, nessun database, nessuna logica lato server.

L’apertura la fa un browser conforme. Il disco non porta con sé un motore di rendering: si appoggia a quello già installato sulla macchina. Su Windows l’autorun.inf, come da specifica Microsoft introdotta con Windows 95, non lancia un eseguibile incorporato ma chiede al sistema di aprire il file index di partenza con il gestore predefinito per l’HTML. Su Mac OS X e Linux non c’è autorun e il punto di ingresso resta lo stesso file, aperto a mano.

Nel 2006 l’asticella per «browser conforme» si è appena alzata: Firefox 1.5 esce il 30 novembre 2005 (https://en.wikipedia.org/wiki/Firefox_version_history) con un supporto più solido a CSS e DOM, e su queste basi sta accanto agli altri motori dell’epoca. Scrivere XHTML/CSS verificato, e non istruzioni cucite addosso a un singolo browser, è ciò che rende il disco apribile su più di una macchina.

Punto critico

Sotto scadenza la tentazione è l’effetto: una transizione, un menu animato, una sezione che si comporta «meglio» dentro Flash. Ogni elemento di questo tipo è un pezzo di contenuto che smette di essere un file e diventa un comportamento legato a un player. Sposta il contenuto da «leggibile da qualunque cosa sappia interpretare lo standard» a «leggibile solo da chi ha quel runtime in quella versione».

La regola che ho seguito: nessuna informazione vive dentro un formato che per essere letto richiede un interprete proprietario. Animazioni e interattività restano ornamento facoltativo; il testo, gli indicatori, le schede sono XHTML servito da disco, leggibile anche aprendo il file grezzo. Se domani il browser di riferimento sparisse, il contenuto si recupera con un editor di testo. Un .dcr o un .swf questa proprietà non l’hanno: il formato proprietario è opaco, e quando il suo interprete non gira più non lo si recupera con uno strumento comune.

Implicazioni

Per un disco fisso e non aggiornabile la scelta degli standard aperti decide per quanti anni il materiale resta usabile, e non è una questione di gusto. Un CD-ROM CRUI sull’autovalutazione è documentazione di metodo che un ateneo può consultare ben oltre l’anno di stampa. Ancorandolo a ISO 9660 e alle Raccomandazioni W3C lo si lega a specifiche pubbliche, implementate da più fornitori indipendenti, che nessuna singola azienda può ritirare.

Il costo si paga in produzione: senza l’autore visuale tutto-in-uno, impaginazione e navigazione si costruiscono a mano in markup e fogli di stile, e gli effetti vistosi diventano più laboriosi. È un costo concentrato a monte, una volta sola, su chi produce. Il costo del runtime proprietario è invece diffuso a valle, su ogni utente e a ogni anno che passa, ed emerge proprio quando non si può più rimediare perché il disco è già stampato. La produzione del CD-ROM CRUI sull’autovalutazione, coordinata dal Consorzio Quinn, è documentata in un insight di noze: https://www.noze.it/insights/cdrom-crui/.

Limiti

Gli standard aperti non garantiscono una resa identica ovunque: nel 2006 i motori divergono sui dettagli CSS, e una pagina va provata su più browser invece che su un solo player «certificato». Il rendering offline ha confini netti — niente componenti server-side, ricerca a testo solo se si imbarca un indice statico — e per audio e video pesanti resta la dipendenza dai codec presenti sulla macchina, un altro problema di portabilità che XHTML non risolve. Infine «leggibile fra dieci anni» è una previsione su come evolveranno i browser, non una certezza: lo è meno per uno standard pubblico con più implementazioni che per il runtime di un solo fornitore, ma resta una previsione.

https://ecma-international.org/publications-and-standards/standards/ecma-119/ https://www.w3.org/TR/2002/REC-xhtml1-20020801/ https://www.w3.org/TR/CSS21/ https://en.wikipedia.org/wiki/Firefox_version_history https://www.crui.it/

Immagine di copertina: Superficie inferiore riflettente di un compact disc che mostra i colori iridescenti dovuti alla diffrazione della luce, con il foro… — foto di Arun Kulshreshtha, CC BY-SA 2.5 — https://commons.wikimedia.org/wiki/File:Compact_Disc.jpg