The lament of a disillusioned ebook reader

«You’d expect that a lot of things have improved in the last couple of years. But I’ll argue that buying ebooks is still a mostly depressing, frustrating and infuriating experience for me, notwithstanding the fact that I work with computers for a living and I have no problem, moral or practical, about doing 90% of my shopping online. I’ll try to explain the main pain points that make me wary of buying ebooks to this day. And I’ll be as honest as I can, if not utterly blunt.»

(Full post on Medium)

 

Notes on the refactoring process

We developers love to talk and moan about many aspects of our job. And we do it a lot. Any given day you’ll find plenty of posts, on HN or elsewhere, discussing the next big thing, the new framework that will heal the sick world of web development, ranting about hiring managers and ill-conceived management processes. And there’s nothing wrong with it: our job is awesome in many different aspects, but sometimes it’s not so great. I get it.

 

You won’t find a lot of information and opinion pieces about one fundamental part of our day to day life, though: how to deal with refactoring. Sure, we have a ton of classic books about the subject, and the most vocal proponents of TDD and XP will talk at great lengths about the overall importance of striving for clean code and how important it is to not forget the “refactoring” part of the canonical TDD cycle. I personally didn’t find as much information as I wanted, and what I’m really curious about is reading other people’s experiences: how do you deal with legacy code? What do you do when confronted with some large module you don’t fully understand? What do you look for? Where do you start from? I’d like to know more.

 

I’ll try to explain what I do in those cases. Be warned: it might not be the best way, it’s probably naive and inexperienced, and I’m sure there is a lot of room for improvement (I’m not a particularly gifted developer, nor do I consider myself to be intelligent, and that’s why I have to do anything I can in order to keep things manageable, straightforward and accessible when I touch them or write them from scratch). Nevertheless, it’s my attempt at describing my overall thought process. I’d love to get some feedback about it, so please be cruel and smash my method into pieces, if you think you can do better. But please, keep in mind that English is not my first language, and sometimes it may show in weird syntax or wrong orthography.

First things first: when you scroll through a module or class for the first time, your goal is to understand its purpose: code is (usually) there for a reason, nobody (well, almost) writes code if he can avoid doing so (we’re lazy bastards), so don’t rush to dismiss other peoples’ code as meaningless or useless. Use your tool of choice to look for occurrences and usages, look at the big picture but don’t be afraid of the minutiae. At the same time, don’t keep your sight on only one layer of abstraction: one of the bad things about legacy code is often the mixing up between different concerns and abstractions. Be ready to go up and down, left and right when you read code for the first time.

 

Tests: don’t even think about doing a major refactor without having a satisfactory suite of tests. Write your tests first, if not unit at least functional, to make sure you can go ahead with confidence and not break anything in the process. It really depends on your application, but usually you want to make sure that the outermost APIs work in the intended way, and keep going forward until you’ve established what the acceptable behaviour is for the largest set of inputs. If you find this too difficult, or if there is a significant amount of ambiguity about what something is supposed to do, stop here: You have a bigger fish to fry, and you should address the problem first and come back later.

 

Clarify intent: once you understand the purpose, you’ll find that something works in an unintuitive or obscure way. One thing I find useful is renaming variables or functions. Perhaps that function or method name was chosen a long time ago, and then someone decided to add a boolean flag to address a corner case. Don’t be afraid of using a silly long name or putting ands, ors, ifs in those names. If anything, it will help to remind you when a function does more than one thing and clearly identify areas that need work. Go around, explore, put comments wherever you want (writing code is cheap! Reading code is not!); you’re not supposed to share your comments yet, so be foolish as much as you want. You want to be able to read the code again as if it were a novel: if you read an article in plain English, isn’t it easy for you to spot obvious problems or logical inconsistencies? There is no reason your code can’t tell you the story.

 

Let your code breathe: this is somewhat controversial, but I really like to put a lot of space around blocks of code when first dealing with a module I want to refactor. It somehow helps me in drawing a mental map of what’s going on in the code, isolate logical units, and who knows? Sometimes those “blocks” between a couple of white lines will translate in a comfortable function call effortlessly. Move lines around, stick declarations near each other, try to group functions by their purpose: did you find more than one function that does the same thing slightly differently?

 

Divide: almost 99% of the time you’ll end up with functions “too large to follow and maintain”. I don’t know about you, but being not particularly intelligent myself, I have a hard time dealing with complexity. It’s much easier to build a block with several different tiny components than it is to do so with only one purposely built big component. Try to split them up into independent components, and keep doing that until you reach the ideal point where every function does exactly one thing. You can use your IDE’s tools to help in doing that: IntelliJ has a useful Refactor to method feature that tries to extract the selected text in a function, and automatically infers its input and output arguments; this allows you to spot really quickly the data structures that are taken and returned, and get a glimpse of shared state between them.

 

Isolate state: it’s a source of confusion. There’s nothing inherently wrong with state, a good deal of web applications are inextricably linked to variable state at some point, and it’s not always possible/effective to strive for complete immutability. What you want to do is isolate the state as much as possible, and reduce the amount of shared state and possible mutation in objects, leaving mutability in a few very obvious spots, where it’s easier to keep under control.

 

Write docstrings. Every language on earth will allow this with some standard / recommended way, please use them if you’re rewriting code. It may not be essential, but will provide some solid value to future developers digging through your code (and again, your IDE could be able to use them to provide context when you hover over a function/class).

 

Delete all the comments. Comments are, again, controversial: you should use plenty of them in your git history, and in your PR descriptions, when words are the only allowed way to communicate. But they have no place in code. 99% of the time, you think you need a comment because your code is not obvious or behaves in a bizarre way. But in code there must be no surprise. Especially if you’re using a very explicit and expressive high-level language like Python or Scala or Ruby, there should really be no need to comment. Delete all the comments, re-read your code and spot the places where it doesn’t make sense anymore. Change that to make sense. You’ll make yourself and your mates happier.
(There are exceptions to this rule: perhaps you’re doing something that seems wrong but it’s needed because an external API does the wrong thing, maybe you need to mangle the contents of a file because it’s expected to be incorrect as it is. Or maybe you’re describing a complex, long and difficult algorithm that only people from your field of expertise will recognise.)

 

Constantly test your changes: you might need fast tests for this, you don’t want to end up not running the tests because they slow you down (I’ve done this several times in the past, and I’m not proud of it). There is no need for a comprehensive set of tests to be slow at all, unless you’re doing things wrong or maintaining a very, very large enterprise application (and still: you shouldn’t need to run an entire test client of the application just to test if a function returns the expected values when given an input – integration and functional tests should live in different modules/folder, so that you can run them every once in a while to make you sure you haven’t introduced any regression – i.e. before committing).

 

Don’t optimise ahead of time: if you’re still coming to grips with the code and you’re busy understanding how all the pieces fit together, don’t be afraid to use inefficient data structures or waste loop cycles, or even write useless functions. You want to optimise at some point, yes, and this point comes always at the end of the process. Don’t be like the bazaar: you want your application to be solid, predictable and correct. Having it running faster and faster shouldn’t come at the expense of testability or correctness, ever.

 

Keep the story going: if you’re refactoring a piece of legacy code (and every application has some legacy code: every single piece of code eventually goes to rot – if you have some corners of the application you dread to touch, that’s legacy my friend), it usually helps people reviewing your code to be able to follow your thought process. So if you’re implementing a particular strategy or following a pattern, clarify that in your commits, even using descriptions fully: you want to end up with a series of commits that reads like a novel (again) and help people to glimpse your purpose without having to open the diff view in Github/Gitlab/whatever. Don’t be afraid to waste commits, they cost nothing to you (and you can always squash them together). Do the same thing when you’re addressing PR comments: one commit per remark/amendment, to acknowledge the action you’ve taken to address your fellow coder comment.

 

Never forget that code is a collective effort, and communicating is your best strategy, always. In software development, code is both the artifact and the instructions; coding is communicating. You’re speaking both to the machine, telling it what to do, and to your colleague or even future self. Don’t try to be super smart with clever one-liners that do not improve anything except your self-esteem. If there is a way to explicitly say something, say it explicitly: the machine does not value your cleverness, and every micro-second you might have shaved will cost you dear in terms of time and effort. If you think that CPU time or HTTP response time cost, think again at how much the equivalent developer time will cost to your business.

 

Last but not least: refactoring has nothing to do with reducing LoCs. Most of the time you’ll think that a 1300-line class/module is a mess, just because it’s long. Most of the time you’ll be right, but only because a lot of lines are a symptom of code repetition and incorrect use of patterns. If your program is in fact complex and deals with a lot of corner cases, you can expect it to grow longer as time goes by. It might even be the case that your refactoring will make the module/class grow: there’s nothing inherently bad about it, especially if your language of choice has a lot of boilerplate around basic object-oriented structures (I’m looking at you, Java). LoCs are simply not a good metric. I personally prefer a longish module that is correct and clear (long variable names, explicit iteration, vertical space) and does what it says it does, over a shortish module full of one-letter variables, obscure patterns and global variables being passed around.

 

Phew. That was long. I think I managed to explain a little bit of what I do and what my principles are when dealing with legacy code in dire need of a refactoring. But that’s not the point. What I want to know is: what’s your strategy? What are your principles to follow through a good refactoring job?
 

Prototipi, ovvero di cose belle che faremo quest’estate al Festivaletteratura

Cosa

Con l’edizione 2015 Festivaletteratura inaugura Prototipi, un laboratorio di riflessione e sviluppo attorno a un tema che mi è particolarmente caro, ovvero l’innovazione del prodotto editoriale. Il laboratorio sarà allestito in forma intensiva per la durata di due settimane, è vedrà lavorare insieme dalle otto alle dodici persone, selezionate tra le tre aree che compongono le professionalità prevalenti dell’editoria digitale (informatici, umanisti, esperti di comunicazione e design) allo scopo di costruire insieme un prototipo a partire da una traccia, un’idea di neo-libro proposta da un autore del festival.

Chi

A guidare il lavoro della squadra saranno tre tutor, diversi per competenze e background professionale: quest’anno ci saremo io, Letizia Sechi (RCS) e Claudia Busetto (Architecta).

Dove e quando

Prototipi durerà dal 24 agosto al 6 settembre 2015, avrà luogo a Mantova, presso una struttura ben attrezzata messa a disposizione dal Festival per tutta la durata dei lavori, e i risultati del lavoro verranno presentati durante il Festivaletteratura (9–13 settembre). Le persone selezionate lavoreranno fianco a fianco per le due settimane del laboratorio, coadiuvati dai tutor che offriranno la propria esperienza e daranno supporto pratico alle idee che verranno sviluppate. Le partecipazione al laboratorio è interamente a spese del Festival, che provvederà al trasporto e all’alloggio dei partecipanti selezionati. Il lavoro di pianificazione e organizzazione comincerà subito dopo le selezioni, quando ci metteremo in contatto e cominceremo a conoscerci meglio prima di passare all’azione.

L’idea

La traccia dell’edizione 2015 di Prototipi è stata proposta dallo scrittore Hans Tuzzi:

L’attuale offerta di prodotti editoriali digitali è in gran parte limitata a un prodotto di base, che non offre al lettore la possibilità di personalizzare la propria esperienza di lettura trasformandola in qualcosa che risponda meglio ai suoi bisogni o ai suoi desideri. È possibile immaginare uno sviluppo che, avvalendosi di nuove competenze professionali, arricchisca le possibilità di fruizione di tali prodotti, tenendo conto delle nuove esigenze dei lettori? È possibile realizzare in modo convincente un passaggio da un prodotto industriale e seriale a un prodotto personalizzabile e individuale?

Tra i possibili indirizzi di sviluppo di un prototipo, si considerino i seguenti nodi da sciogliere:

  • Linearità: raccontiamo e argomentiamo in modo lineare, e questo limita la nostra prospettiva sulle potenzialità più forte del digitale che è il link, la relazione tra idee;
  • Esperienza di lettura: pensiamo il prodotto editoriale in modo definito, immutabile e questo limita l’esperienza che possiamo fare del contenuto;
  • Relazione tra libro e mondo: ogni prodotto vive immerso nel mondo che lo circonda, arricchendo la relazione tra il lettore e il suo mondo: in che modo si può esprimere e valorizzare questa relazione in un paradigma digitale?

Come candidarsi

Trovate il bando completo sul sito di Festivaletteratura. In sintesi, dovrete compilare una scheda di partecipazione (che trovate qui), insieme a un vostro breve profilo (niente curriculum o cover letter, per favore: parlateci di cosa fate, di cosa vi piace fare e di cosa non vi piace fare) e a un pre-prototipo, cioè un tentativo di risposta alla traccia su cui lavorerà Prototipi 2015. Tenete presente che i profili che cerchiamo sono grossomodo informatici, umanisti e designer: non è necessario candidarsi per un profilo specifico, ma fateci capire come potreste contribuire alla costruzione del prototipo. Invierete le vostre candidature all’indirizzo prototipi@festivaletteratura.it. Avete tempo fino al 14 agosto, perché il 18 agosto contiamo di aver già selezionato i partecipanti.

Perché

Il format del laboratorio si basa su un’idea di collaborazione e fattività che rimette al centro la riflessione sui contenuti e cerca di slegarsi dalla pura suggestione tecnica che finora ha guidato, per lo più ciecamente, lo sviluppo delle forme editoriali alternative al volume cartaceo. Come efficacemente sintetizzato da Letizia, si tratta di passare dalle parole ai prototipi: colpisce particolarmente il fatto che uno dei maggiori festival letterari del Paese, peraltro quello a maggior vocazione letteraria e con un consistente seguito di pubblico, abbia pensato di aprire una riflessione sui temi dell’innovazione e abbia voluto spendersi ben al di là della banale tavola rotonda tra esperti, e mi onoro di essere stato scelto come coordinatore della prima edizione e poter così dare il mio piccolo contributo a portare un passo più avanti la riflessione sul futuro possibile della letteratura elettronica, condividendo la mia piccola esperienza, i miei entusiasmi e i miei dubbi, sperando di poter contribuire a creare e condividere qualcosa di veramente nuovo.

 

Che fare? Problemi scottanti dell’editoria digitale italiana

Lavorare nell’editoria digitale a metà del 2014, e farlo nel mercato italiano, significa in primo luogo dover operare una riflessione sugli scopi e sui risultati a cui siamo giunti dopo anni di roboanti promesse e propositi rivoluzionari. Riflettere, cioè, sui problemi scottanti del nostro movimento, mettendo per un attimo da parte i proclami evangelizzatori, le percentuali a tre cifre, le prospettive visionarie e i tempi verbali al futuro prossimo.

A sei mesi dalla conclusione del 2013, un anno che ha brillato per la sostanziale mancanza di innovazione, la quale ha portato prevedibilmente con sé la stagnazione della crescita del digitale nei mercati di riferimento come quello statunitense, le cifre sono piuttosto chiare e ci raccontano nitidamente una storia. AIE ci conferma, senza sorprendere, che il mercato trade è digitale solo per il 3%, e questo si traduce in una crescita troppo lenta per incoraggiare gli attori della filiera a investire in prodotti, flussi di lavoro, canali nuovi. D’altro canto, nello stesso comunicato stampa, ci si rallegra di un +0,3% nei libri per l’infanzia, quando invece si dovrebbe osservare con sgomento che si è venduto un complessivo -6,8% di libri. La trama della nostra storia prende nel suo svolgimento una piega sempre più preoccupante, con tinte di viva angoscia da parte dei nostri protagonisti editori, che pure hanno passato, tutti o quasi, il triennio 2010/13 preparandosi a produrre, oltre alla carta, anche degli ebook.

È la storia di una rivoluzione fallita? L’editoria digitale italiana e le sue pratiche di liberazione sono state arrestate dalla tempra di un Kornilov a sembianza di paperback? Non esattamente.

Ritengo fuorviante, oltreché inesatto, chiamare rivoluzione digitale l’aver immesso sul mercato online delle conversioni in formato markup dei PDF di stampa che governavano il workflow delle case editrici, piccole, grandi e colossali, da trent’anni. Ritengo fuorviante chiamare rivoluzione l’aver fornito dette conversioni ad attori già esistenti come le librerie online italiane o il Moloch Amazon affinché le vendessero per conto degli editori, replicando pedissequamente un modello di business sicuro e sperimentato. Ritengo fuorviante, infine, scomodare il termine rivoluzione per definire un processo di transizione incompleto, che certamente stampa su vetro i caratteri del libro ma ne fa nient’altro che prodotti, tariffati e venduti come entità singole e scollegate, ciascuna racchiusa da un ISBN e ferma nel tempo alla data della messa in stampa, e per giunta immessa sul mercato con i cicli e le tempistiche della distribuzione in libreria. Avevamo minacciato un nuovo ordine mondiale, ma abbiamo prodotto nient’altro che un Putsch in una birreria. Dove abbiamo sbagliato? Anzi: cosa avremmo considerato un successo?

Abbiamo creduto che lettura digitale significasse caricare degli ePub su un dispositivo, e che per essere innovativi bastasse migliorare i propri InDesign affinché generassero degli ePub non eccessivamente brutti, e pagare qualcuno affinché avesse cura di distribuirli, insieme alle informazioni bibliografiche, ai principali store. La lettura digitale non è questo. Ritrovarsi in birreria e ripetere che “non poteva funzionare, in Italia notoriamente non si legge” è un modo, per quanto elegante, di commiserarsi senza rinunciare a quella punta di snobberia a buon mercato che i social network ci hanno insegnato ad amare.

Aver ritenuto che leggere in digitale potesse limitarsi a scaricare un archivio compresso, all’interno del quale riprodurre la struttura di un sito web tuttavia privo delle caratteristiche che hanno decretato il successo del web è stato la madre di tutti gli errori. Non per questo considero tempo buttato l’elaborazione e l’adozione di uno standard condiviso per i contenuti editoriali offline, anzi: gli standard sono il motore degli eventi, nel mondo digitale.

Gli standard fanno parlare sistemi diversi e fissano le regole del gioco. Gli standard e le loro implementazioni sono delizia e croce degli addetti ai lavori, dei tecnici, dei digital platform plumber; non però per gli utenti, che sono entusiasticamente disinteressati ai particolari, agli ingranaggi, ai framework. E cosa hanno visto gli utenti, quel 3% di curiosi che in uno sforzo di fiducia hanno riempito un form coi numeri della propria credit card per finanziare la Rivoluzione? Una brutta copia del libro di carta (a volte brutalmente fallata), che ha bisogno di un dispositivo apposito per essere fruita, che quando va bene ha gli hyperlink nell’indice ma nient’altro, che nel 90% dei casi deve essere aperto da un programma di un’azienda che non è né la libreria né l’editore, azienda presso la quale dobbiamo registrare un account affinché graziosamente ci permetta di autorizzare non solo la mia persona ma anche il mio dispositivo (ma non più di sei) a fruire del contenuto che è stato addebitato sulla credit card di cui sopra, addebito che naturalmente è stato istantaneo, e ci mancherebbe.

Oppure no, oppure gli utenti hanno acquistato il libro dei desideri con un click, perché il venditore si ricorda di loro, e l’hanno scaricato direttamente sul proprio dispositivo, il più economico e solido di tutti, senza autorizzare niente e nessuno, e possono leggerlo anche dal cellulare, se ne hanno uno, senza neanche disturbarsi a ricordare a che pagina fossero arrivati. Ma questi sono i clienti di Amazon, sono i clienti che acquistano di più in digitale, sono quelli che ho visto coi miei occhi prendere il Kindle dallo zaino e comprare all’istante Ask the Dust dopo avergli detto che non potevano entusiasmarsi davvero per qualcosa prima di aver letto la storia di Arturo e Camilla, e sono quelli che noi abbiamo deciso di chiamare nemici.

Amazon è un’azienda che, tra le altre cose, ha spesso fondato la propria comunicazione sul valore dei propri clienti, corteggiandoli in modi leciti e meno leciti, ma sempre offrendo servizi che rimangono impareggiabili per immediatezza e vicinanza al portafogli.

Non sono dichiarazioni così distanti da quelle che sentiamo a ogni maggio dei libri: case editrici, distributori, editori gareggiano tra loro per vezzeggiare il lettore, cioè il loro cliente, sostenendo di farne il loro patrimonio, di renderlo il proprio padrone: ma quali servizi e facilitazioni, nel concreto, offrono le case editrici ai propri lettori? L’increscioso equivoco della legge Levi, che ha limitato per legge lo sconto praticabile sui libri al tetto del 15%, è stato recepito dal pubblico di lettori esattamente per quello che era: una miope manovra di autotutela che andava paradossalmente a danneggiare proprio quei lettori forti che AIE vede diminuire a ogni report di fine anno, quei lettori che vedevano nello sconto un rinforzo motivazionale per riempire ancor più la propria casa di libri.

In questo senso, mi sono ritrovato a pensare che «l’editoria è l’unica industria al mondo che incolpa il consumatore dei propri insuccessi». Parimenti, ritengo che gli operatori italiani del digitale abbiano prematuramente inteso la propria professione come un’opera rivoluzionaria, vedendosi schierati contro le forze oscurantiste della Reazione, preoccupate di perdere il proprio ruolo egemone nel dibattito culturale. Dimenticando, colpevolmente, che la tecnologia è kuhnianamente conservativa rispetto alla cultura: i paradigmi creati dalla tecnologia portano alla luce saperi minoritari, aumentano la circolazione dei saperi esistenti e imprimono ad esseri una vertiginosa accelerazione. Dal 1994 a oggi abbiamo assistito a una rivoluzione scientifica in tecnologia, composta di HTML e HTTP, che sono a tutti gli effetti i mattoncini attraverso cui viaggiano i saperi che vengono rappresentati dagli attori del dibattito culturale, siano essi giornalisti, saggisti o romanzieri. Dimenticando, inoltre, e ancor più colpevolmente, che le tecnologie proposte per armare la rivoluzione digitale sono, tutte, invariabilmente, tecnologie che ormai di rivoluzionario non hanno assolutamente nulla, e che anche per questo vengono senza sforzo adottate da un esercito di improvvisati e dilettanti, alcuni dei quali preposti a produrre quei materiali fallati che ogni lettore digitale ha avuto il dispiacere di aver acquistato, mettendo in piedi script in Perl (1987) che operano sostituzioni con regular expression (1968) e magari pubblicando contenuti su un WordPress e un paio di plugin in PHP (1995).

Non è falso che una parte piuttosto consistente della critica al digitale e ai suoi paradigmi sia in effetti condotta secondo gli schemi della reazione, e rappresenti fedelmente le istanze sociali della classe borghese, tradizionalmente proprietaria dei mezzi di produzione culturale, e comprensibilmente allarmata da un progresso che svincola la produzione e la diffusione di contenuti culturali da quei mezzi che solo una buona disponibilità di denaro rendeva accessibili. Abbiamo contato dozzine di articoli crucciati, alcuni anche firmati da nomi eccellenti, colmi di ammonimenti riguardo al self-publishing, tracciati con la stessa logica con cui, dieci anni fa, si derideva il gigantesco tentativo di Wikipedia di darsi una disciplina e conquistare una credibilità pari almeno a quella dell’enciclopedia multimediale Encarta (Microsoft Encarta non viene più prodotta dal 2008, mentre gli errori di Wikipedia riempiono i coccodrilli delle principali testate nazionali).

Non è difficile percepire, dietro ai catenacci che denunciano in Google, negli smartphone, in Facebook, in Twitter il batterio che aggredisce una società civile fino a quel momento indaffaratissima a leggere (pardon: rileggere) la Recherche, una velata preoccupazione di perdere un ruolo da protagonista che, dalla macchina a vapore in avanti, è stato solidamente occupato in ambito culturale da una classe borghese che poteva contare su solidi patrimoni e al contempo lavarsi via, per così dire, l’onta, rappresentandosi come mecenate generosa e illuminata.

Questo non solleva però gli operatori del digitale italiano dalla responsabilità dei propri errori di valutazione e calcolo: abbiamo schierato un’organizzazione di rivoluzionari laddove nessuno aspettava una rivoluzione, armandoci con strumenti antiquati e concetti novecenteschi. Abbiamo introdotto strumenti tutto sommato nuovi nel lavoro editoriale, ma le nostre parole sono rimaste quelle di sempre: abbiamo cercato di incastrare un prodotto nuovo, elettronico, veloce e in evoluzione, all’interno di cicli di produzione e consumo pensati al cartaceo, ottenendone nient’altro che la brutta copia, il residuo di scarto della lavorazione del libro, un prodotto imperfetto che abbiamo necessariamente dovuto prezzare a meno della metà, se non addirittura a meno di un euro, implicitamente supplicando il lettore di concederci una possibilità. Vedere ancora oggi offerte a prezzo stracciato, intere collane in prezzo lancio 0.99, si traduce in un reiterato grido d’ascolto che il mercato non ha più intenzione di ascoltare, almeno finché permarranno i limiti e le idiosincrasie che abbiamo voluto applicare al digitale per renderlo più “digeribile”.

Quindi: che fare?

Comprendere come la lettura digitale e l’ebook non solo non siano la stessa cosa, ma neanche si somiglino granché: leggere digitale comprende un universo di pratiche e mezzi che va da Twitter a Medium, passando dai blog agli ebook e sconfinando nei videogame (che sono opere d’arte interattive, narrazioni, storie, raccontate con un linguaggio non alfabetico). Un ebook è una fetta di web, un pacchetto di XML, XHTML, JPEG e CSS (con l’occasionale JS), che per lo più vive uno splendido isolamento e non ha rapporti con l’universo che lo circonda.

Chiedersi se davvero il calo delle vendite dei libri cartacei debba condurre a un futuro di libri elettronici: secondo quale logica il mancato acquisto di libri dovrebbe condurre a un acquisto di qualcosa che è praticamente un libro cartaceo, è a rischio di dissoluzione al primo cambio di schema DRM o al primo hard disk in panne? Chiedersi, allo stesso modo, se i lettori non stiano leggendo di meno per via della concorrenza di medium diversi come le serie televisive americane, le letture disimpegnate del blog di grido, o la semplice ossessione per se stessi da nutrire a suon di selfie.

Chiedersi se sia giusto, se sia davvero onesto, proseguire nella rappresentazione del libro e della lettura come se trattassimo materiale magico, di per sé investito di un’aura salvifica, e non stessimo semplicemente cercando di vendere un’esperienza, che pur certo è intellettuale ma può avere un valore di intrattenimento, di evasione, di passatempo: la retorica del libro che si respira nella sfera degli addetti ai lavori dell’editoria è tale e così fitta che non raramente atterrisce.

Chiedersi, chiedersi davvero, chi siano i propri lettori e cosa chiedano ai propri referenti, siano essi editori o librerie: quali delle loro richieste viene soddisfatta dal digitale? Come potrebbe, inoltre, il digitale migliorare le loro vite, rendendo più semplice, piacevole, immediato e soddisfacente l’acquisto di un bene di consumo letterario? In altre parole: che problema stiamo cercando di risolvere?

Rispondere a queste semplici ma essenziali domande è il requisito che, ritengo, serva soddisfare affinché il 2014, o quello che del 2014 ci resta, sia per noi professionalmente soddisfacente e che il prossimo Natale segni, dopo anni di falso allarme, il trionfo della lettura in digitale. In mancanza, continueremo a combattere la nostra guerriglia nella giungla, incerti sul nemico da combattere, mentre tutt’intorno i lettori, quei pochi rimasti, entreranno in libreria per uscirne a mani vuote.

A questo post ha fatto seguito una interessante serie di considerazioni di Fabrizio Venerandi, editore di Quintadicopertina, esposte in forma di corollari al mio “j’accuse”. Consiglio caldamente di leggerli per integrare questa lettura.

 

Le vite controverse delle tecnologie per i contenuti

«Se abbiamo a che fare con i contenuti, oggi, ci piaccia o no, lavoriamo anche con la tecnologia: sul piano del prodotto, della comunicazione e dell’ambiente in cui entrambi abitano. Dovremo quindi essere in grado di prendere decisioni in questo campo: abbiamo bisogno di competenze per fare scelte consapevoli ed efficaci. Possiamo muoverci in due modi: acquisendo noi stessi quelle competenze o sapendole riconoscere in altri professionisti con cui collaborare.»

Il resto in un post a due mani con Letizia Sechi, sul suo blog.

 

Quanto vale un ebook?

Scrive Venerandi:

A settembre non cadono le foglie, ma fioriscono nei blog di tutto il mondo i consigli su come impostare la propria attività lavorativa, specie se digitale, ancora di più se editoriale. Accanto a consigli comprensibili, come quelli di vendere in bundle ebook ed equivalente libro cartaceo, apro una parentesi, il che è una implicita ammissione di sconfitta per il digitale, non solo perché si palesa il fatto che l’ebook non è in grado di sostituire in toto il libro di carta, abbiamo ancora bisogno del libro di carta, apro una seconda parentesi, anche se vale il contrario, non mi basta più solo il libro di carta ed ho bisogno anche di quello digitale, chiusa parentesi tonda interna, non solo dicevo perché si palesa che l’ebook non è indipendente, ma soprattutto perché si riduce l’ebook ad essere una appendice del prodotto che resta principe nella sua progettazione, ovvero il libro di carta di cui l’ebook è un utile surrogato, chiusa parentesi tonda esterna, dicevo, accanto a consigli comprensibili come il summenzionato affogato in confuse ipotassi, si trovano alcune considerazioni che io sono sicuro di aver già sentito tempo addietro, tra cui quella in cui si dice che content is not the king, il contenuto non è così importante, ma è importante l’accesso al contenuto stesso, quello che si deve far pagare – in sostanza – è la possibilità e la facilità di accedere ai dati. Non i dati. E qui, da creatore di dati, mi chiedo se veramente questa sia una novità del digitale. Ovvero: davvero quando comperiamo un tradizionale libro cartaceo compriamo un contenuto, o anche in quel caso paghiamo una forma che ci permette di accedere ai dati stampati all’interno della forma libro? Io penso che da sempre si paghi l’accesso ai dati, non è un caso che buona parte del prezzo di copertina di un libro di carta finisca nelle tasche dei vari intermediari che si occupano della distribuzione, ovvero di coloro che facilitano/complicano l’accesso ai contenuti.

Tra le due parentetiche, Venerandi coglie un paio di punti che a mio modo di vedere è cruciale mettere in discussione oggi, subito: la prima (1) è la questione del ruolo dell’ebook come veicolo di informazioni e (1b) la sua efficacia in tale ruolo, la seconda (2) è la questione del valore dell’ebook come merce a cui il consumatore riconosce un certo prezzo. Le due cose non coincidono o coincidono solo marginalmente, ed è importante che i due punti (e mezzo) vengano sollevati da uno come Venerandi, che gestisce una casa editrice digitale e che è tra i non moltissimi che in Italia hanno il rapporto fare/chiacchierare col segno positivo.

Poiché sono stato (e sono tuttora) un convinto sostenitore delle strategie di bundling (al punto da aver giochicchiato con un sistema alternativo per permetterlo), proprio per questo, ritengo che la prospettiva del problema sollevato da Fabrizio sia parziale. La digitalizzazione dei beni di consumo culturale e l’evoluzione dei modelli di business dei loro editori mostrano una transizione ben precisa, che a mio modo di vedere è cruciale per comprendere le nuove criticità e le nuove possibilità di mercato sulla Rete: la transizione, cioè, da un’ottica di prodotto a una prospettiva di servizio. È sotto gli occhi di tutti l’accaduto per la musica, per la quale i consumatori hanno abbracciato entusiasticamente un modello di subscription di tipo all you can listen. Qualcuno ha le idee confuse e crede che si possa tradurre l’esperienza di Spotify (ma anche di Netflix) con i libri, tirando fuori qualcosa chiamato “ebook in streaming” (qualsiasi cosa ciò significhi); questa è, secondo me, la risposta sbagliata, perché dimentica che l’editoria (l’editoria tipicamente libraria a cui pensiamo quando pensiamo agli ebook in Italia) è un mercato basato su prodotti simili ma diversissimi (i nuovi libri di un editore competono essenzialmente l’uno contro l’altro ad ogni giro promozionale) e che non possono essere consumati distrattamente, nel modo in cui io sto consumando il mio abbonamento Spotify scrivendo queste righe. Ma la prospettiva di servizio, quella sì: l’ebook non è un bene durevole, non viene percepito come tale e – credo – è profondamente sbagliato cercare di venderlo come tale. Vendere un ebook come sostituto del libro di carta significa fare un’ingiustizia alle sue potenzialità, in cambio di un vantaggio tangibile non appetibile per tutti (a meno che voi non crediate che sia possibile uscire dal 4% appellandoci a fantomatici lettori che hanno il problema di portarsi appresso centinaia di libri – il mercato editoriale è fatto di editori a caccia di lettori che, se va proprio bene, di libro a casa ne portano uno all’anno). Ma questo l’ho già detto altre volte, è ozioso tornarci su.

Veniamo ai punti.

(1) Siamo stati fuorviati da anni in cui abbiamo ripetuto come un mantra che content is the king. Non che l’affermazione sia falsa, anzi: è vera, e una dozzina d’anni di Internet di massa sta lì a dimostrarlo. Quello che abbiamo sbagliato è credere che il contenuto, di per sé solo, possa fare il grosso del lavoro per noi. Un buon romanzo non è niente se non viene veicolato in una forma acconcia verso il suo lettore, un grande classico non vale niente se per leggerlo devo districarmi tra errori di formattazione, stili sghembi e refusi introdotti da qualche espressione regolare troppo “maggica”. Il contenuto è il re, ma il contenuto lo fruiamo attraverso un vettore, che sia esso un EPUB, un PDF o un tascabile paperback. È un esercizio piuttosto inutile farci la guerra di bande e cercare di stabilire che “un PDF non è un ebook”, che “il cartaceo è morto“, oppure anche che “l’esperienza della lettura vera è quella cartacea”. Il problema del vettore di contenuto è un problema tecnologico, e dalla tecnologia deve provenire una risposta ai problemi, non la proposizione di problemi nuovi. Che problema risolve il libro elettronico? Rispondere a questa domanda può indirizzare il lavoro che dobbiamo fare nel 2014. Quello che dovremmo assicurare al lettore, già da oggi, è la massima flessibilità: abbiamo digitalizzato il catalogo, se non siamo dei cialtroni abbiamo un formato sorgente affidabile da cui derivare i formati adatti ai dispositivi (qualcuno usa XML, come Fabrizio, qualcun altro – tipo me – degli XHTML; il concetto è quello): offriamo tutti i formati ai lettori (non tutti lo fanno, qualcuno è pigro e non l’ha ancora fatto, qualcun altro – il più grave – non saprebbe come farlo). Possiamo cominciare da qui. Poi pensiamo ad allargare il discorso, pensando ad esempio a come coinvolgere le librerie nel commercio di ebook. Il bundling risolve, parzialmente, questo problema. Ma è un passo ulteriore.

(1b) Tutt’altro problema è chiedersi se gli ebook siano sufficientemente efficaci per risolvere i problemi per cui vogliamo impiegarli, e se siano efficaci nel modo in cui li facciamo adesso. Parlo dalla mia prospettiva: la casa editrice per cui lavoro pubblica romanzi, narrativa prevalentemente straniera, intesa per la lettura immersiva e prolungata. L’ereader è un ambiente perfetto per questi scopi. Da questo punto di vista però i vantaggi del digitale si assottigliano: la carta non offre un’esperienza di lettura sensibilmente meno ricca, e il prodotto digitale non differisce sensibilmente dal cartaceo, è solo una divaricazione del workflow. Per questo non credo che offrirlo gratuitamente insieme al cartaceo sia una “sconfitta del digitale”. Diverso il discorso per la saggistica o la manualistica. Se potessimo provare l’esperienza di studio di un testo digitale ben progettato, con indici analitici veri, diversi percorsi di lettura e una semantica che renda facile consumare l’ebook come una banca dati, probabilmente lo faremmo pagare come il cartaceo e non li offriremmo insieme se non con una subscription di sorta. Questo genere di esperienze non sono ancora diffusamente disponibili, ed è un limite dei formati, dei dispositivi di lettura e delle capacità di progettazione delle case editrici. Questo è il secondo passo da affrontare.

(2) Dall’unione di 1 e 1b otteniamo il problema della valorizzazione del prodotto digitale. Il valore di un prodotto o di un servizio, materiale o immateriale, è una funzione del valore che tale prodotto o servizio aggiunge alle nostre esistenze. Produrre, vendere e allucchettare il libro elettronico per renderlo più simile a un libro di carta significa sottrargli valore. Da quale cannibalizzazione ci stiamo difendendo, se il mercato è al 4%? Siamo sicuri che rendere la vita impossibile ai lettori onesti con i DRM di Adobe sia la soluzione al problema della pirateria, quando esistono siti con dettagliati tutorial su come toglierli in due mosse? Riusciremo a convincere il pubblico a pagare gli ebook quando gli ebook risolveranno problemi senza crearne altri o limitare delle funzionalità che il cartaceo svolge benissimo.

 

Bundling cartaceo/digitale: un’opportunità (e un affare) per il libro

Oltre alla convenienza per il consumatore, un bundling su larga scala può alleviare la diffidenza che librerie e promotori nutrono nei confronti dell’ebook, restituendo alle librerie indipendenti un vantaggio competitivo che temevano di perdere nella transizione a un paradigma di consumo digitale.

Il resto nel mio guest post su eBookReader Italia.