9 Si può fare di più.

Gino Roncaglia

Nel Capitolo 7 è stata espressa l’idea “costruiamo gli strumenti adatti al risultato che desideriamo”, con cui io sono molto d’accordo.

Questo presuppone, appunto, una certa chiarezza sulle forme di organizzazione dell’informazione che riteniamo desiderabili. Su chi debba costruire questi strumenti, sarei abbastanza pluralista: l’importante è che lo faccia qualcuno.

Certo alcuni soggetti hanno interesse a creare strumenti ‘chiusi’: iBook author è un ottimo strumento per creare enhanced books, ma ha l’enorme limite della chiusura propria dell’ecosistema Apple. Francesco Leonetti ha fatto un ottimo lavoro con ePubeditor ma molto è ancora da fare, e credo che in sostanza il suo lavoro abbia due potenziali fonti di revenue: da un lato apputo gli editori – che possono incorporare l’editor in strumenti di produzione rivolti all’interno o all’esterno – dall’altro direttamente gli autori, che possono usare un editor per la creazione di e-book multimediali avanzati. Anche gli e-book iLibra di Laterza-Repubblica sono degli esempi abbastanza interessanti, che nel contempo mostrano i grossi limiti che hanno ancora gli authoring tools. Le piattaforme a loro volta in molti casi sono troppo chiuse: la mia impressione è che – quando lo fanno – offrano API adatte al ‘riuso localizzato’ dei contenuti più che a una loro vera riorganizzazione, e sono API che cambiano in continuazione. Però non sono un programmatore, magari sbaglio. Certo è che finora ad esempio di applicazioni capaci di ‘potenziare’ conservazione e riuso dei contenuti di Facebook – per restare a questo esempio – non ne conosco.

Gli esempi che vengono citati nel Capitolo 7 (Firestorm, Snow Fall – interessante che siano in tutti e due i casi ricostruzione di disastri…) sostanzialmente usano HTML5, ma – anche se ePub3 si basa su HTML 5 – siamo ancora lontani dal riuscire a fare cose del genere in maniera facile e assistita dentro un e-book che usi ePub3, e produrre un contenuto del genere richiede un doppio sforzo – ideativo e tecnico – che è ancora assai costoso. Byliner, Atavist sono esperimenti interessanti in cui si mescola l’aspetto del supporto alla narrazione ‘enhanced’ e quello di piattaforma di distribuzione dei contenuti. Ma anche qui siamo ancora a strumenti molto d’élite. Medium è interessantissimo, e nel contempo ancora molto ‘tradizionale’ come authoring tool (anche se finiora l’ho usato solo da ‘lettore’ – quanto tempo che ci vorrebbe per provare davvero tutto…). Ma sono cose di questo genere quelle che dobbiamo tenere d’occhio.

Nel complesso, mi pare che lavoriamo su un confine in cui la distinzione – che in linea generale dovrebbe essere assai netta – fra contenuti e strumenti diventa di fatto più sfumata: alcuni strumenti nascono per permettere certe modalità di strutturazione dei contenuti, che a loro volta riguardano certe tipologie di contenuti. E alcuni contenuti ‘cercano’ gli strumenti che ne permettono la ‘giusta’ strutturazione e organizzazione. Ma sono d’accordo sul fatto che il punto non è tanto la novità dei contenuti in sé, quanto la disponibilità degli strumenti per organizzarli in maniera sensata e funzionale.

Passando invece alle tesi del Capitolo 8, sono d’accordo con l’autore Marco Ferrario, ma la mia tesi non è che la granularità sia necessariamente inutile o dispersiva. Semplicemente, non basta produrre granularità (come invece molti sembrano pensare), e non è una buona idea usare il concetto di ‘contenuto granulare’ come una sorta di manifesto paradigmatico per la cultura digitale. Il caso della programmazione è un caso di ‘riuso individuale’ di componenti granulari all’interno di un progetto più ampio, ed è un caso frequente (lo stesso si potrebbe dire ad es. per il riuso di immagini fuori copyright all’interno di un sito, ecc.). In molti di questi casi abbiamo contenuti granulari o modulari pensati per il riuso in strutture più complesse, e questo ovviamente va benissimo.

Nel dire che serve anche l’alto livello, non voglio certo negare l’utilità delle routine di basso livello come componenti riusabili che semplificano il lavoro. Ma se queste routine di basso livello non le riusiamo in progetti di alto livello, servono a poco. Nel caso della programmazione abbiamo buoni strumenti per farlo, nel caso ad esempio dei post su Facebook no. Certo poi leggere un post interessante, anche se granulare e disperso, arricchisce chi legge – e anche chi scrive. Ma gli strumenti per conservare, riusare, organizzare, far crescere questi frammenti secondo me sono ancora pochi, e come conseguenza in molti casi ci accontentiamo di vivere nei frammenti.

Magari siamo bravi a scegliere frammenti interessanti, ma si potrebbe fare molto di più.