Non è mai colpa della macchina

Siamo abituati a imputare alle macchine (computer, smartphone, ecc.) una serie di difficoltà che, spesso, più che di un diavoletto sono il frutto di un difetto di metodo. Poche semplici regole e molta pazienza possono aiutarci a ridurre, il più delle volte, la frustrazione di risultati diversi da quelli che avremmo desiderato.

«Il computer si è spento da solo [e ho perso tutto ciò che avevo fatto finora]».
«Il programma non funziona [e non fa ciò che voglio]»
«In stampa sono uscite delle cose strane [e non capisco come ci sono finite, su quel foglio]»
A tutti è capitato di dire, o almeno sentir dire, una frase del genere.
Una vecchia lista destinata agli operatori di help desk raccoglieva, agli albori di un altro mondo sulla gloriosa rete Usenet (antesignana dei forum web, elencava gruppi di interesse e liste di news), gli argomenti delle chiamate più frequenti degli utenti; accanto a chi non riusciva a trovare il pulsante di accensione del computer o aveva dimenticato di collegare il cavo di alimentazione (sembra incredibile, ma non è banale, e resta in ogni caso una difficoltà frequente ancora oggi) o aveva scambiato il lettore CD per un portabicchiere (!), c’era soprattutto chi affermava la recalcitranza del computer a fare (o non fare) qualcosa.

Oggi le chiamate più frequenti riguardano la lentezza del computer o lo smarrimento della password di accesso, ma soprattutto in ambito di produzione o di redazione spesso ci si trova a pensare (e a dire) che il computer fa ciò che vuole indipendentemente dalla nostra volontà o, per i più raffinati, che tra noi e il prodotto finale si è intromesso un «diavoletto delle bozze».
Esisterebbe anche un colpevole: il medievale Titivillus che raccoglie i frammenti delle parole distraendo prima i monaci amanuensi, poi i tipografi e gli addetti ai lavori inducendoli in errore – è in realtà una creazione di origine francese del XIX secolo, resa popolare da Anatole France; ne parla un gradevole libretto di Julio Ignacio González Montañés, Titivillus. Il demone dei refusi, Perugia, Graphe.it 2018 – oggi potrebbe assurgere a «protettore», oltre che dei calligrafi, dei tipografi e dei giornalisti, anche degli errori di redazione o dei comportamenti delle macchine che paiono inspiegabili.

Ma il fatto è che, al di là delle questioni tecniche – l’errore di sistema, o anche la schermata blu che in inglese si chiama «Blue Screen of Death», un nome degno di Star Wars – per la maggior parte dei casi, pressoché sempre, facciamocene una ragione, non è colpa della macchina.

Si va dall’errore più banale – inavvertitamente, magari con il ginocchio, si preme il tasto di reset del computer; oppure si schiaccia una combinazione di tasti che corrisponde a un comando inatteso – a quello più frequente – si sono installati e disinstallati programmi che lasciano sempre delle tracce, e alla lunga il computer è diventato lento: ha bisogno di manutenzione, come per le placche di colesterolo, di essere «ripulito».

Ma, soprattutto in fase di creazione (di un documento, di un testo promozionale, ecc.; gli esempi però potrebbero essere estesi a tutti i lavori di creazione di contenuti, e probabilmente anche oltre) per lo più si tratta di imprecisione nel metodo.

Basta tenere presenti poche regole.
Si comincia da quella che richiede, in fase di sviluppo di un contenuto, di pensare bene a quale sia il programma più adatto per gestirlo.
Se cerchiamo di impaginare un libro con illustrator o di gestire un testo lungo con Powerpoint – credeteci, è successo davvero –, o ancora una serie di formule complesse con Word, dobbiamo aspettarci di trovare qualche difficoltà.
Soprattutto la incontrerà chi viene dopo di noi (il tipografo, il grafico, ecc.), perché certamente saremo stati costretti a utilizzare una serie di espedienti per ottenere un risultato che almeno apparentemente funzioni, ma potrebbe non farlo nella versione finale.
A ciascuno il suo programma, insomma.

La regola successiva è quella di fare in modo che quanto stiamo producendo sia, almeno informaticamente, corretto: se generiamo un documento lasciando una serie di spazi vuoti o dei ritorni di carrello (gli Enter a vuoto), probabilmente l’aspetto sarà quello che desideriamo, ma se poi apportiamo delle modifiche – anche solo aggiungendo o togliendo una parola – dobbiamo essere pronti al pericolo che il testo «scorra» e, come dicevano i navigatori quando passavano l’emisfero, niente tra le stelle sia più dove dovrebbe essere.
Essere rigorosi, e impostare il lavoro in modo che sia riutilizzabile per sé stessi e per chi verrà a lavorarci dopo; non importa se un documento è generato «solo per noi stessi»: il metodo vale anche, e a maggior ragione, per i noi stessi che riprenderanno quel documento a distanza di tempo.

Infine, prendersi il tempo per cercare la soluzione migliore – o il comando giusto, o l’impostazione più semplice – per ottenere l’effetto che si desidera: se stiamo utilizzando un programma specifico, è probabile che la funzione che stiamo cercando esista, o esista ancora se ne stiamo usando una nuova versione. Si tratta di impiegare qualche minuto (o anche di più; ma normalmente i tutorial d’aiuto funzionano bene, basta non fidarsi troppo) per scorrere i menu, dovunque i programmatori li abbiano messi, e trovare il comando giusto.
Se ci pare una perdita di tempo, pensiamo a quanto ne guadagneremo dopo.
Magari nel frattempo possiamo, blandamente, imprecare alle ragioni di una logica di programmazione che non è sempre trasparente e che di solito obbedisce a esigenze di mercato, più che di utilità; ma potrebbe anche essere, come sopra, una questione di mancanza di metodo. Appunto.

In ogni caso, non è (quasi) mai colpa della macchina.