Per provare a reagire, IDPF ha lanciato Readium:

Readium is an open source reference system and rendering engine for EPUB publications. The overall aim of the Readium project is to ensure that open source software for handling EPUB 3 publications is readily available, to accelerate adoption of EPUB 3 as the universal, accessible, global digital publishing format (NdA, corsivo mio).

Come spiega Bill McCoy (executive director IDPF) nell’intervista qui sotto, Readium non è un applicazione di lettura. L’intenzione, piuttosto, è fornire ai produttori di applicazioni di lettura la possibilità di implementare un motore di rendering standard e aperto, offrendo un framework sulla base del quale costruire le singole applicazioni.

Readium è stato lanciato durante l’ultimo TOC. Il progetto ha ottenuto il supporto di partner importanti (tra gli altri Google, B&N, Adobe, Kobo, Sony, Samsung, Bluefire, tutti produttori di sistemi di lettura) e ha iniziato subito a dare risultati: supporto a MathML, compatibilità con i Fixed Layout Epub, un’estensione per Google Chrome.

Tutti segnali incoraggianti, tanto che all’ultima PePcon è stato dichiarato questo:

Readium is open source EPUB3 ereader and is starting to be implemented by major vendors. #pepcon #eprdctn

— Colleen Cunningham (@BookDesignGirl) Mag 15, 2012

Può darsi (è un auspicio, non scetticismo), eppure ad ora effetti concreti non se ne vedono. Di sicuro è molto presto: è sensato aspettare il lancio di nuovi prodotti hardware o un aggiornamento importante dei sistemi di lettura software.

Restano alcune valutazioni. Nessuno dei player più importanti ha davvero bisogno di Readium, soprattutto da un punto di vista tecnologico e di sviluppo dei prodotti. La separazione dei rendering engine – che variano a seconda del dispositivo o dell’applicazione utilizzata – rende molto difficile organizzare un flusso di lavoro efficiente, contribuendo così a indebolire gli editori e a rafforzare l’attuale assetto oligopolistico del mercato. Per questo decidere di adottare Readium potrebbe essere una scelta strategica, un segnale importante, una dichiarazione d’intenti.

E ancora: se IDPF decide di investire sviluppo e risorse in un progetto basato su WebKit – e dunque legato per necessità a dispositivi con display LCD – possiamo considerare la sorte dei lettori a inchiostro elettronico definitivamente segnata?

Ivan Rachieli: Le applicazioni web basate su HTML5 e CSS3 consentono di sviluppare prodotti editoriali potenzialmente molto complessi e accessibili utilizzando qualsiasi dispositivo dotato di un browser. Cosa pensi di queste tecnologie? Tra l’altro di Locusta Temporis esiste già una versione accessibile online: stai pensando anche a una vera e propria web app?

Enrico Colombini: La versione online di Locusta Temporis contiene solo il primo capitolo, ma non ci sono ostacoli tecnici che impediscano di pubblicare in questo modo un intero libro, o corsi interattivi, o altre opere. È interessante notare che, siccome concettualmente ciascuna pagina contiene in sé l’intero stato di lettura, non c’è alcuna necessità né di programmazione lato server o lato client, né di ‘salvare’ la situazione: basta usare un normale segnalibro (bookmark) del browser per conservare memoria di tutte le azioni compiute.

HTML5 è certamente interessante e le web app si diffonderanno sempre più, anche se penso che il loro costo di sviluppo sia più alto di quanto possa sembrare, a causa dei ricorrenti problemi di compatibilità con i diversi browser e le relative versioni, dei molteplici aspetti da considerare (server, client e comunicazione) e della necessità di un testing esaustivo. Parlo ovviamente di applicazioni affidabili, perché a fare un programma che funziona solo sui computer di prova sono capaci tutti. Lo so che oggi il software prima si vende e poi lo si fa funzionare, ma io sono della vecchia scuola. :)

Lavorando di HTML5 è possibile giocare a Angry Birds nel browser. Ma i costi di sviluppo per un ambiente in continua evoluzione sono sostenibili?

Personalmente non sono troppo attirato né dalla programmazione per il Web né a maggior ragione dalle web app, un po’ perché sono un orso delle caverne e non amo troppo la comunicazione permanente, un po’ perché ciò mi richama il tempo dei terminali che accedevano a un sistema centrale (il sistema dittatoriale che credevamo definitivamente rovesciato dalla rivoluzione del personal computer), ma specialmente perché mi piace lavorare su basi solide e ben definite e avere tutto sotto controllo, in modo da poter costruire sistemi complessi e affidabili.

A lavorare col Web sembra di programmare una spugna che cambia continuamente forma, per di più usando necessariamente librerie altrui che a loro volta possono avere problemi e cambiare di versione, il tutto navigando su standard in perenne mutamento e mai del tutto rispettati… insomma, mi sembra di costruire le bancarelle della fiera di paese, che domattina saranno smontate, piuttosto che la Tour Eiffel.

Ivan Rachieli: Parliamo di interfacce. Come si guida il lettore attraverso decisioni, scelte ed enigmi, facendo in modo che non finisca per perdersi o per imboccare un vicolo cieco?

Enrico Colombini: Il vicolo cieco è indubbiamente una delle peggiori situazioni che possano capitare al lettore; è assai poco desiderabile rimanere bloccati senza via d’uscita. Per prevenire questa evenienza ho usato tre accorgimenti: un’attenta organizzazione del ‘libro sorgente’ (non dover tenere traccia manualmente delle pagine e degli stati è di grande aiuto), un accurato testing delle possibili scelte e sequenze e, per sicurezza, un ulteriore programmino ausiliario.

Quest’ultimo ha il compito di verificare che la pagina finale (o le possibili pagine, nel caso di finali multipli) sia raggiungibile attraverso una catena di link da ciascuna delle altre pagine, di modo che non possa esistere una pagina ‘bloccante’.

Per quanto riguarda l’interfaccia propriamente detta, uno dei problemi connessi alla presenza di enigmi è che il lettore si ritrova a passare e ripassare più volte dalle medesime pagine… o almeno da pagine che possono sembrargli le stesse perché magari appartengono a un altro stato per effetto di una scelta precedente (e fin qui tutto bene, il lettore non deve saperlo) oppure hanno qualche piccola variante: ad esempio, nella descrizione la finestra è aperta anziché chiusa.

Come può il lettore rilevare la differenza nel testo senza rileggersi ogni volta la pagina, il che porterebbe a una noia mortale? Nel mio caso, oltre ad adottare pagine brevi pensate per essere completamente visibili sullo schermo (almeno con molti reader) ho cercato di piazzare le modifiche in testa o in coda alla pagina, in modo che possano essere individuate con facilità; mi rendo conto che non si tratta comunque di una soluzione ottimale, ma temo che il problema sia insito in questo tipo di lettura.

Tra libri interattivi e videogame si pongono problemi di interfaccia sempre nuovi. Anche per Frotz, una app nata per rigiocare in ambiente mobile le gloriose avventure testuali Infocom.

Per il resto ho cercato di far immedesimare il lettore con il protagonista di turno, in modo che l’interfaccia tendenzialmente sparisca dentro la vicenda stessa, ossia non venga percepita come separata dal testo; ovviamente non pretendo di avere trovato una soluzione ottimale, anzi sono certo che vi sia ancora molto spazio per la sperimentazione.

Ivan Rachieli: Quali sono i tuoi piani per il futuro? Stai lavorando su nuovi ebook interattivi?

Enrico Colombini: Magari! I miei appunti debordano di spunti e idee, ma al momento è meglio che mi dedichi a trovare qualcosa da fare, possibilmente che sia minimamente interessante (cosa assai difficile in Italia dove c’è un’atavica paura di ogni innovazione). Non mi spiacerebbe lavorare ancora nell’industria dei videogame, anche se i grandi sviluppatori cercano più che altro iperspecialisti da incatenare a una specifica scrivania, mentre i piccoli (dove è più facile trovare creatività e innovazione) hanno da far quadrare i conti, soprattutto in questo periodo, e faticano a cogliere i frutti del loro lavoro. Ma qualcosa mi inventerò.

Ivan Rachieli: Grazie di tutto Enrico, e a presto :)

Enrico Colombini: Grazie a te per l’ospitalità e la pazienza :)

(6-fine. I segmenti precedenti dell’intervista sono stati pubblicati in questa sequenza, dall’inizio: Tra ebook e videogiochi: parla Enrico Colombini, 4 maggio; Enrico Colombini: lettori interattivi, libri a misura, 8 maggio; Enrico Colombini, tra narrazione e gioco, 11 maggio; Gioco o ebook? Risponde Enrico Colombini, 15 maggio; Anatomia della Locusta di Enrico Colombini, 18 maggio).

Ivan Rachieli: Veniamo a Locusta Temporis. La prima cosa che mi piacerebbe spiegassi ai nostri lettori è come hai progettato e costruito l’architettura della narrazione, delle interazioni e degli enigmi.

Enrico Colombini: Durante la progettazione di Locusta Temporis ho deciso di pensare al racconto interattivo come a una macchina a stati. Supponiamo che il lettore abbia la scelta se lasciare aperta o meno una finestra dalla quale, più avanti nella storia, potrà entrare un’allodola. L’unica cosa che il lettore può fare è scegliere tra due link: un link porterà alla pagina in cui la finestra rimarrà chiusa, l’altro alla pagina in cui la stessa finestra starà aperta.

Il problema è come memorizzare questa scelta, in modo da poterne tenere conto dopo qualche pagina, quando l’allodola potrà entrare e svegliare il protagonista solo se la finestra era stata precedentemente lasciata aperta. In un programma per computer mi basterebbe tenere lo stato della finestra in una variabile (scriverlo in una casella di memoria) per rileggermelo più tardi; in alcuni formati e lettori di ebook ciò potrebbe essere possibile, ma in altri no e non ci posso quindi far conto: devo comportarmi come se stessi scrivendo un libro stampato, che non possiede memoria. E nemmeno voglio obbligare il lettore a tenere nota dello stato della finestra segnando una crocetta su un’apposita casellina, come si usava negli antichi libri-gioco.

Non ho che una soluzione: far proseguire il lettore lungo due serie di pagine parallele, magari contenenti identico testo ma comunque separate tra loro; è come passare uno scambio ferroviario scegliendo tra due binari, che però rimangono paralleli. Solo più avanti nella vicenda le due serie di pagine divergeranno descrivendo eventi diversi, a seconda di quale binario sia stato imboccato all’inizio; ciascuna delle due serie di pagine rappresenta un diverso stato (finestra aperta o finestra chiusa).

La scelta del lettore sposta la narrazione su un binario possibile, corrispondente a una serie di pagine almeno inizialmente parallela alle altre.

Parrebbe che con un simile meccanismo di base non si possano realizzare costruzioni troppo complesse né tantomeno enigmi interessanti, dato che ad ogni scelta aggiuntiva la complessità si moltiplica; ad esempio per memorizzare cinque scelte indipendenti servono ben trentadue serie di pagine separate. Invece è perfettamente possibile se si riesce a tenerne sotto controllo la complessità: per chi fosse interessato, ho pubblicato un articolo che esplora alcune costruzioni realizzabili con questo sistema, molte delle quali sono usate in Locusta Temporis.

Pensavo anche che fosse difficile realizzare enigmi non banali, tanto che nei primi capitoli mi sono forse concentrato un po’ troppo sui puzzle rispetto alla narrazione, ma i risultati sono stati comunque interessanti, forse anche troppo, dato che diversi lettori hanno trovato alcuni enigmi più impegnativi di quanto mi aspettassi, benché avessi fatto leggere/giocare il libro a diversi collaudatori e in vari casi avessi ridotto la difficoltà dei puzzle. Probabilmente la forma libro fa sembrare le stesse situazioni più complesse di quanto apparirebbero se incontrate in un gioco.

Qui ci starebbe anche una questione di progetto dei racconti interattivi: puntare molto sugli enigmi (gioco puro) oppure renderli semplicissimi, quasi automatici o addirittura assenti, per non disturbare la narrazione (lettura pura)? Ho cercato di tracciare una delle possibili infinite vie di mezzo, ma saranno i lettori a dire se ci sia riuscito o meno.

Ivan Rachieli: Locusta Temporis è sia un ebook (in ePub, mobi e PDF) sia un’applicazione per iOS. Ci spieghi come hai organizzato il flusso di lavoro in modo da poter partire da una base comune di contenuti?

Enrico Colombini: Il sorgente comune del libro è un ibrido tra un testo e un programma: ciascuna pagina è in realtà una funzione in linguaggio Lua che, per così dire, stampa il testo corrispondente allo stato corrente della pagina stessa. Si tratta di un’impostazione per vari aspetti simile a quella del mio vecchio Idra, uno strumento per la costruzione di racconti interattivi Web, ovvero un normale programma che usa variabili per memorizzare tutte le informazioni necessarie.

La conversione di questo sorgente in un insieme di pagine immutabili collegate da link, ciascuna delle quali è una diversa istanza di una delle mie pagine originali e ne rappresenta un diverso stato, è opera di Medusa (Macchinario Esente Da Un Significativo Acronimo). Si tratta di un compilatore che non saprei se definire di Intelligenza Artificiale o di Pigrizia Naturale, dato che lo scrissi per evitare il lavoraccio di tener traccia a mano di tutte le necessarie varianti delle pagine e soprattutto dei numerosi link incrociati.

Questo è solo l'inizio dello schema della toolchain Medusa, che invitiamo a consultare per intero seguendo il link proposto nell'articolo.

I frammenti di codice del ‘libro sorgente’ vengono eseguiti non durante la lettura, dato che ciò non sarebbe possibile, ma durante la fase stessa di compilazione (tecnicamente si tratta di un metaprogramming compiler), producendo tutte le pagine necessarie per rappresentare ogni possibile stato raggiungibile durante la lettura.

Medusa produce un singolo file HTML contenente tutte le pagine del libro, o più comunemente quelle della parte di libro che scelgo di compilare per risparmiare tempo di caricamento nel browser durante le prove: se mi limito a un capitolo, in un paio di secondi dalla modifica del ‘sorgente’ posso leggere le pagine prodotte e verificarne il corretto funzionamento (durante la lavorazione produco una singola pagina HTML con link interni, invece che tanti file quante sono le pagine finali, perché il sistema operativo è relativamente lento nella creazione di molti file).

Una volta verificato che tutto sia a posto, a partire dal singolo file HTML produco le differenti versioni: ePub, Kindle/Mobipocket, PDF, pagine Web separate (per il demo) e infine l’applicazione iOS. Il lavoro dal lato PC è svolto da una serie di programmi che formano una toolchain – ma penso che il termine tecnico sia accrocchio – composta da convertitori scritti per la maggior parte in linguaggio Lua, ma comprendente anche tool esterni come kindlegen di Amazon e html2ps (un convertitore da HTML a PostScript scritto in Perl da Jan Kärrman).

La messa a punto di questa toolchain è costata molto più lavoro del previsto. In particolare la produzione della versione PDF necessita del citato html2ps, l’unico convertitore open source che si sia dimostrato capace di trattare correttamente le 5.800 pagine e gli 11 mila link di Locusta Temporis, sia pure in tempi molto lunghi (45 minuti sul mio PC).

Purtroppo il programma non è recente e accetta solo HTML (in pratica il 3.2), quindi niente CSS veri e propri; ciò ha condizionato l’intero meccanismo costringendomi a partire dall’HTML puro (con tutti i suoi limiti) e a convertirlo poi in XHTML per convenienza del resto della toolchain e dei reader, con annessa conversione da ISO-8859-1 a UTF-8… e sorvolo su altri problemi.

Ulteriori complicazioni sono venute dai cosiddetti ‘standard’ come ePub, che in pratica ciascun produttore di reader (hardware o software) interpretava e forse ancora interpreta a modo suo, spesso introducendo limitazioni arbitrarie (è inevitabile l’analogia con i browser Web, specie quelli dei primi tempi).

Arrivare a fare funzionare Locusta Temporis su tutte le piattaforme di ebook più diffuse più una app iOS ha richiesto un lungo lavoro di affinamento.

Ad esempio, alcuni reader non riuscivano nemmeno a caricare l’obbligatorio (quanto inutile, nel mio caso) elenco XML delle pagine del libro, costringendomi a comprimerne i numeri con un codice in base 26 per occupare meno spazio nel file stesso. Naturalmente ciascuna versione finale richiede modifiche particolari (formato, stili, pagine di testa e di coda, indici, qualche pagina da sostituire eccetera) per cui c’è voluto un po’ di lavoro. Ho anche preferito scrivere il programma che produce la versione ePub invece che usare uno dei vari tool liberamente disponibili, perché non ne ho trovati che rispettassero interamente lo standard e fossero capaci di trattare correttamente un libro complesso come questo.

Per la versione iOS le pagine sono compattate in un unico file indicizzato, con l’aggiunta di un paio di file ausiliari per trasferire le necessarie informazioni (ad esempio per l’indice, in cui appaiono automaticamente certe pagine chiave man mano le si visita) e il tutto è accessibile al Mac via rete locale. Il resto, dal lato iOS, è un normale programma Objective-C con una parte in JavaScript per la visualizzazione; per la verità all’inizio c’era molto più JavaScript, ma alcuni problemi delle librerie mi hanno costretto a cambiare strada. Inoltre i primi tester hanno (giustamente) stroncato la mia prima versione di interfaccia, per cui anche quella è stata progettata e programmata due volte. Per semplificare il lavoro ho scritto poi vari programmini ausiliari… insomma, ho avuto di che passare il tempo. :)

(5-continua. Ivan Rachieli e Enrico Colombini raccontano di paralleli tra ebook e videogiochi, tendenze verso la personalizzazione dei libri), differenze tra intrattenimento letterario e ludico e differenze di interattività tra gioco e libro).

HTML, neanche OpenDocument. È aperto e sganciato da software particolare; il sovraccarico della marcatura è minimo rispetto al testo; le possibilità espressive e descrittive sono invece illimitate; permette semplicità e indipendenza dall’aspetto della pagina così come la creazione di documenti sofisticati. La ricetta è semplice:

HTML and CSS are the fundamental technologies for building Web pages: HTML (html and xhtml) for structure, CSS for style and layout, including WebFonts. Find resources for good Web page design as well as helpful tools.

Avrei potuto scrivere quanto sopra rispetto al corpus letterario di uno scrittore moderno. Gli ebook stanno per affacciarsi sul mercato più ampio: scrivo mentre in prima serata nazionale passa la promozione di un libro disponibile esclusivamente in formato digitale.

Saremo invasi da legioni di libri autoprodotti (niente di male) realizzati con strumenti di massa riconosciuti automaticamente da Amazon o iBookstore.

Strumenti nessuno dei quali permette veramente la creazione di un ePub con la precisione e la qualità tipografica consentite da un uso accorto delle specifiche, di HTML, di CSS.

Un appello agli autori (e agli editori). Siate snob. Gli ebook non gratificano il tatto come la carta, né l’odorato come l’inchiostro. Ma possono gratificare la vista come nessuna orrenda paginata in Arial e Times New Roman farà mai. Imparate HTML. Imparate CSS. Distinguetevi.

Ivan Rachieli: Capovolgendo i termini della questione rispetto alla domanda precedente ci si potrebbe anche chiedere: se un videogioco dalla buona complessità narrativa mi permette (proprio perché é un videogioco) di entrare completamente a far parte della storia, perché dovrei perdere tempo leggendo un romanzo, per quanto interattivo?

Enrico Colombini: Sgombriamo subito il campo da un equivoco: la libertà del giocatore è limitata in un videogioco quanto lo è quella del lettore in un ebook interattivo: è vero che in un computer sono teoricamente possibili infinite combinazioni e percorsi, ma in pratica lo sforzo necessario per costruire un insieme coerente dipende dal numero delle possibili combinazioni della vicenda, per cui delle due l’una: o si abbandona la coerenza, lasciando il giocatore libero ma disperso e perdendo il controllo delle emozioni che è parte fondamentale del raccontare una storia, oppure si limitano le possibilità.

Ad esempio, per motivi prevalentemente di costi produttivi, anche (o soprattutto) i recenti videogame dai costi miliardari sono artisticamente curati nei minimi dettagli come film interattivi, ma guidano il giocatore lungo un percorso obbligato.

La libertà di movimento nei videogiochi a volte è illusoria: per alcuni, come l'acclamato Rage HD di iD Software, si parla di "railroading", dal momento che il personaggio procede su un vero e proprio binario.

La differenza tra videogame e romanzo interattivo sta quindi sostanzialmente solo nel mezzo di comunicazione tra autore e lettore, come nel vecchio dualismo libro/film. Se è vero che un’immagine vale mille parole, si può anche affermare che una parola vale mille immagini: nessuna scena, per quanto ben disegnata, potrà mai essere come quella della mia fantasia e un singolo aggettivo può evocare un intero mondo. Dal punto di vista tecnico, l’uso della parola scritta comporta minori costi per cui consente di costruire strutture più complesse e sofisticate, a parità di storia narrata.

Un altro motivo per leggere ebook interattivi può essere la semplice curiosità: la narrazione non lineare realizzata con meccanismi non banali e buona cura del linguaggio è una novità che si distingue nettamente dagli schematici e ipersemplificati libri-gioco degli anni ’80; si tratta di un territorio nuovo e in gran parte inesplorato, per il lettore come per l’autore.

A questo punto rigirerei la domanda: perché perdere tempo a scrivere un libro interattivo? Alcuni dei problemi che si presentano all’autore non esistono nella classica narrazione sequenziale, cioè nel solito libro. Per esempio, come posso evitare ripetizioni se a una stessa pagina si può arrivare provenendo da molte pagine diverse? Come guidare le emozioni del lettore se non conosco il percorso che seguirà? Come adattare un testo organizzato in pagine allo schermo (spesso minuscolo) dei lettori di ebook? Per quanto riguarda l’ultimo punto, ad esempio, ho optato per paginette molto brevi (riducendo così anche il problema di riconoscerle quando si ripresentano) pur se qualche lettore avrebbe forse preferito descrizioni meno sintetiche. Ma è impossibile accontentare tutti.

(4-continua. Ivan Rachieli e Enrico Colombini hanno già discusso di paralleli tra ebook e videogiochi, tendenze verso la personalizzazione dei libri) e differenze tra intrattenimento letterario e ludico.

Ivan Rachieli: L’interazione e la personalizzazione sembrano essere tendenze importanti per il 2012, tanto per gli editori quanto per i lettori. Secondo te è sensato ipotizzare che la lettura – intesa come strumento cognitivo – venga gradualmente affiancata da processi più complessi, incentrati sull’utente (lettore?), sulle sue scelte e sulla sua relazione attiva coi contenuti?

Enrico Colombini: Per quanto riguarda l’editoria tecnica e divulgativa in genere, l’interazione è senz’altro desiderabile: il coinvolgimento del lettore, anche solo con semplici test di controllo e di rafforzo positivo, rende l’apprendimento più interessante ed efficace. La possibilità di approfondire o meno un certo argomento, o in genere di seguire il proprio percorso personale, consente a ciascun lettore di avere il proprio libro su misura.

È vero che l’autore si trova ad affrontare un compito ben più arduo rispetto alla semplice scrittura di un testo sequenziale, ma questo lavoro può essere semplificato dall’uso di programmi riutilizzabili (framework) e, punto importante, tale impegno aggiuntivo contribuirà a rendere l’opera ben più utile e produttiva rispetto alle solite pagine Web trovate in giro. Naturalmente a un’opera editoriale si possono affiancare ulteriori materiali sul Web o anche Web app… costi permettendo, s’intende.

Guardando al futuro (ma neanche poi tanto) sarà possibile misurare l’interazione del lettore col libro, come già si fa con i videogame, in modo da individuare possibili punti di miglioramento. Ad esempio, se la grande maggioranza dei lettori dà la risposta sbagliata al primo test del capitolo 3, probabilmente l’argomento non è spiegato abbastanza bene ed è opportuno rivederlo.

Locusta Temporis, un libro avventura ben diverso dal banale albero binario che abbiamo conosciuto con i librogame cartacei.

Un possibile lato ambivalente del futuro è l’eventuale diffusione di ebook gratuiti che si ripagano con la pubblicità. L’esperienza del Web e delle app per smartphone fa supporre che ciò potrebbe portare a ricavi decrescenti per gli autori (e quindi probabilmente a uno scadimento del prodotto) oltre che a forme pubblicitarie particolarmente invasive come animazioni o audio. D’altra parte, proprio quest’ultimo punto può essere un motivo di preferenza per il libro a pagamento in cui la lettura non viene disturbata da elementi estranei; inoltre un’eventuale pubblicità non invadente, con la quale il settore editoriale ha da sempre convissuto specie per quanto riguarda i periodici, potrebbe contribuire ad alleviare i problemi economici, consentendo di tenere un prezzo più basso senza rinunciare alla qualità. In ogni caso è da sperare che non si verifichi uno scadimento simile a quello che la pubblicità ha causato alla televisione, ma spero che la natura riflessiva della lettura possa costituire una buona difesa nei confronti di simili eccessi.

C’è poi l’interazione tra autori e lettori, senz’altro desiderabile (almeno in campo tecnico) sia per il feedback che per il rapporto diretto che si viene a creare, ma anche molto costosa per l’autore a causa del tempo che è necessario dedicarvi anche dopo la data di pubblicazione. È comunque vero che, nel bene e nel male, in genere solo un piccolo numero di lettori si prende la briga di partecipare attivamente in qualche modo, per cui i vantaggi potrebbero superare gli inconvenienti (pur se rimane il rischio che l’autore possa farsi un’immagine errata del suo pubblico, basandosi solo sulle opinioni dei lettori più attivi).

Chiedo scusa se tendo a vedere le cose prevalentemente dal punto di vista dell’autore, ma temo sia in qualche modo inevitabile e penso comunque che l’interesse dell’autore stesso coincida in gran parte con quello del lettore: se il primo si ripaga lo sforzo necessario per produrre un lavoro di qualità, anche il secondo ne trae vantaggio.

(2-continua. Ivan Rachieli e Enrico Colombini avevano già parlato di paralleli tra ebook e videogiochi)

La questione non deve essere da poco visto e considerato che oggi l’organizzazione Defective by Design (satellite della Free Software Foundation) celebra la quarta edizione della Giornata Internazionale Contro il DRM.

Ma che cos’è il DRM per questi attivisti? Prendendo a prestito le loro stesse parole:

it is a growing problem in the area of ebooks, where people have had their books restricted so they can’t freely loan, re-sell or donate them, read them without being tracked, or move them to a new device without re-purchasing all of them.

A growing problem. E allora si torna all’inizio, alla domanda banale dalla risposta scontata: per alcuni il DRM è un problema, una seria e grave limitazione alla libertà personale. Per altri, al contrario, è la soluzione alla spinosa questione della pirateria.

Non serve qui discutere sulla reale efficacia dei DRM nella lotta alla pirateria, né tantomeno sui danni (veri o presunti) che questa arreca all’industria editoriale. Forse conta di più puntare i riflettori su un fatto: l’assenza di DRM non è necessariamente sinonimo di pirateria.

E un esempio – importante – viene proprio dal mondo editoriale. L’editore O’Reilly, storicamente contrario all’adozione di DRM, da anni pubblica e vende ebook DRM-free e proprio oggi rilancia l’invito a seguire il suo esempio, come qualcuno già ha fatto.

Celebriamo questa giornata con le parole di Tim O’Reilly, da una sua intervista a forbes.com del 23 marzo 2011:

People who don’t pay you generally wouldn’t have paid you anyway. We are delighted when people who can’t afford our books don’t pay us for them, if they go out and do something useful with that information.

Ivan Rachieli: Prima di entrare nel dettaglio del tuo lavoro, mi piacerebbe sapere che idea ti sei fatto dello stato attuale dell’editoria. Pensi che sia possibile individuare dei parallelismi o dei pattern comuni con quanto hai visto accadere all’industria dei videogame negli ultimi trent’anni?

Enrico Colombini: Ho avuto il privilegio di vivere dall’interno quello che viene considerato il periodo d’oro dell’editoria informatica, e ho assistito alle sue successive evoluzioni, che in parte penso coincidano con quelle dell’editoria in generale. Mi pare che stiamo vivendo un periodo di transizione, con molti problemi ma anche opportunità non ancora ben delineate.

In sintesi vedrei almeno tre punti importanti: la crescente importanza dell’immagine e del multimedia in generale rispetto alla parola scritta, la presenza sul Web di una grande quantità di materiale liberamente accessibile e, più recentemente, l’affermazione del libro elettronico.

Il primo importante gioco di avventura in italiano, Avventura nel Castello, aveva una interfaccia integralmente testuale. Oggi la parola d'ordine è multimedia.

Il primo punto, il multimedia, è correlato al differente linguaggio delle ultime generazioni cresciute a pane e video e non più abituate a dominare il mondo della parola. Parlare questa nuova lingua implica, dal punto di vista editoriale, una certa difficoltà nella trasmissione di concetti complessi, un possibile impoverimento dei contenuti e purtroppo anche un significativo aumento dei costi di realizzazione. Mentre i costi aumentano cresce la concorrenza dell’informazione gratuita sul Web, e non è sempre facile far capire quanto sia ancora importante la funzione di autori ed editori, che possono fare da filtro e guida tracciando una rotta sicura nell’oceano di un’informazione spesso indifferenziata e incoerente, troppo spesso ridotta a veicolo pubblicitario per gli interessi di pochi monopolisti.

Infine, a proposito di ebook e distribuzione digitale in genere, oltre alla pirateria – indotta dalla facilità di copia a basso costo – c’è anche il fatto che molti autori pensano di poter fare a meno di un editore, senza considerare che così facendo si devono sobbarcare anche (oltre al lavoro di impaginazione) la parte commerciale e pubblicitaria in concorrenza con una massa di infiniti altri auto-editori da cui è sempre più difficile distinguersi, rinunciando tra l’altro alla possibilità di inserire il proprio lavoro in una tela più vasta e complessa.

È interessante il tuo parallelo con l’industria videoludica. Confesso di non averne sempre seguito le evoluzioni, (almeno non con la stessa attenzione che ho dedicato ai suoi prodotti) ma certamente si possono rilevare alcuni parallelismi. La transizione dalla parola al video, per intenderci dalle avventure testuali alle avventure grafiche, è avvenuta durante l’infanzia del settore, nei primi anni ’80. Per contro, la pirateria è stata un problema fin dall’inizio (in Italia, lasciata indisturbata e persino incoraggiata da qualche produttore di hardware, stroncò il settore sul nascere ai tempi del Commodore 64) mentre l’affermazione della distribuzione digitale e dell’autoproduzione è recentissima e sta scuotendo l’industria dalle fondamenta.

Maniac Mansion, avventura nata da LucasFilm su Commodore 64 e con schermate a sostituire le tradizionali descrizioni testuali. Il settore videoludico venne fortemente penalizzato dalla pirateria.

Passando alle opportunità, per quanto riguarda l’approccio multimediale, con un buon progetto si possono fare cose interessanti anche senza affrontare i costi miliardari di un videogame 3D. I costi di realizzazione aumentano ma quelli di distribuzione scendono drasticamente per la mancanza di distributori, resi e macero; si possono raggiungere senza costi aggiuntivi anche i numerosi lettori che abitano lontano dai centri principali; il digitale e la carta possono aiutarsi e rafforzarsi a vicenda; il coinvolgimento diretto dei lettori offre l’opportunità di correggere rapidamente gli errori e affinare le opere; l’interattività degli ebook può personalizzare e rendere più efficaci le spiegazioni, mentre l’autopubblicazione può comunque essere un’utile palestra e palcoscenico per i nuovi autori.

Sono le prime considerazioni che mi vengono in mente ma sicuramente ci sono moltissime altre opportunità da cogliere, come in ogni periodo di cambiamento. L’importante è coglierle e non stare fermi ad aspettare un improbabile ritorno al passato.

(1-continua)

Afferma Shatzkin:

30% of those who read e-content say they now spend more time reading, and owners of tablets and e-book readers particularly stand out as reading more now.

Come processo cognitivo, la lettura mi sembra assolutamente al sicuro. È un modo semplice ed efficace di acquisire informazioni. È radicata nelle consuetudini culturali di buona parte dell’umanità e l’accesso rapido e semplice a ogni genere di contenuto non può che aumentarne diffusione, forza e importanza. Si scrive e si legge: in modo sempre diverso e su altri supporti, ma è la sostanza che conta e quella resta. Da questo punto di vista, libri e ebook sono un’eventualità.

Those who have taken the plunge into reading e-books stand out in almost every way from other kinds of readers. Foremost, they are relatively avid readers of books in all formats: 88% of those who read e-books in the past 12 months also read printed books.

Tendiamo tutti a polarizzare e semplificare. Stabilire chi ammazzerà chi è una tentazione molto forte (e radicalizza il dibattito, aumenta le visite e i commenti). Immaginare dispositivi unificanti è altrettanto naturale, così come procedere per sostituzioni: questo va al posto di quello. D’altra parte sembra che le cose non stiano così: in un contesto di abbondanza la fruizione si frammenta, cerchiamo istintivamente la soluzione migliore alle diverse esigenze. A volte è carta, a volte è il telefono, il computer, il tablet, l’ereader. A volte è un video, una conversazione, un videogame. Sarebbe bello limitare le schematizzazioni, non ridurre troppo la complessità.

42% of readers of e-books in the past 12 months said they consume their books on a computer; 41% of readers of e-books consume their books on an e-book reader like original Kindles or Nooks; 29% of readers of e-books consume their books on their cell phones; 23% of readers of e-books consume their books on a tablet computer.

Molta lettura su PC, e su schermo LCD in generale. Anche qui molta frammentazione: si interrompe e si ricomincia altrove. Dato il peso (in termini di utilizzo) dei dispositivi non e-ink (di cui parla anche O’Reilly), è da tenere d’occhio lo sviluppo del motore di rendering open source dell’IDPF, Readium, basato su Webkit. E viene da chiedersi, come fa notare Shatzkin:

If nearly half the ebook audience already reads on fully capable PCs, they are already able to consume ebooks with color and illustrations and video and audio without needing a tablet. But they aren’t. The question is, “will they ever?”

Proveremo a dire qualcosa al riguardo nel prossimo articolo.

Su The Unofficial Apple Weblog, tuttavia, Erica Sadun racconta una propria esperienza di lettura “manuale” dopo molto tempo altrimenti passato sui libri elettronici e rivela che la questione potrebbe avere una angolazione diversa:

For one thing, there was no built-in light source in the book. For another, I could not tap words to define them or adjust the font size presentation to my precise mood. In fact, the entire book for all its narrative value had about as much interactive GUI appeal as, forgive me, a large pile of dead wood.

La richiesta del partner di spegnere la luce perché non riesce a dormire diventa inedita nel resoconto, invece che normalità.

E la cosa più tremenda? Quando il libro inizia a perdere di interesse, non offre suggerimenti alternativi di lettura.

Oltre a discutere di come debba cambiare il libro nell’era digitale, ci sono da guardare anche i lettori. Come sintetizza Sadun, nel momento in cui ho iniziato a leggere, mi sono resa conto che il tradizionale libro stampato non è cambiato molto negli ultimi decenni, ma come lettrice io l’ho fatto.