mercoledì 22 febbraio 2017

Il peso degli accenti regionali

 
Le pronunce locali italiane rappresentano un grosso punto di incertezza per i sistemi di riconoscimento del parlato. In fin dei conti, esistono numerose pronunce diverse, con caratteri al tempo stesso marcati e molto diversi tra di loro. Inoltre, le pronunce locali sono più la regola che l’eccezione: ancora oggi è spesso possibile individuare l’origine di un italiano semplicemente sentendolo parlare – e con la possibilità a volte di individuare non solo la regione di provenienza, ma anche la città o addirittura il quartiere.
 
Interpretare l’italiano regionale è quindi molto importante per un qualunque sistema basato sul riconoscimento del parlato. Per fortuna, mi sembra che i sistemi attuali funzionino molto bene da questo punto di vista e il corpus CLIPS permette di verificare la cosa. Per esempio, una frase con un marcato accento napoletano come questa (audio CLIPS DGmtA02N, dopo 0:03) viene comunque interpretata correttamente:
 
 
Questa capacità è notevole, e si mostra tale anche in punti in cui sarebbe del tutto naturale avere problemi. Alcuni studenti del mio corso di Linguistica italiana II hanno individuato registrazioni del corpus CLIPS in cui il mancato riconoscimento da parte di Google o Dragon sembrava direttamente collegato alle caratteristiche della pronuncia. Tuttavia questi errori sono molto rari e, soprattutto, a volte dipendono forse da problemi di audio: quando ho tentato, non sono mai riuscito a replicarli.


 
Per esempio, nella registrazione LMp2A02N (Napoli) Alessandro Giosi aveva notato che la sequenza “camion rosso”, pronunciato con pesante accento per chiusura metafonetica, veniva interpretata da Google come “camion russo” (da 0:25). La sequenza è questa:
 
 
Tuttavia, quando ho provato a controllare, né Google né Dragon hanno dato la stessa risposta: in entrambi i casi la trascrizione è stata “camion rosso”.
 
Nella registrazione DGmtA04E (Parma) Sofia Ghisellini ha notato che alla pronuncia “all’esterno” diventava “ha le stanno” in evidente rapporto col fatto che la -r- veniva pronunciata con la caratteristica pronuncia uvulare emiliana (da 4:11):
 
 
Neanche qui sono stato in grado di riprodurre il problema: tanto Google quanto Dragon mi hanno fornito la trascrizione “all’esterno”.
 
In opportune circostanze, una pronuncia marcata potrebbe quindi forse indurre in errore i sistemi di riconoscimento. Nella pratica, questo non succede quasi mai... anche perché le situazioni di ambiguità fonetica sono molto poche. Parole come automobbile, per quanto marcate, non possono confondere perché non ci sono parole simili ad automobile che Google o Dragon possano scambiare in questo modo.
 
Tuttavia, è difficile precisare quanto debba essere marcata la pronuncia, per un’ottima ragione: non esistono modi per misurare sinteticamente quanto un accento regionale sia diverso dallo standard. Le differenze possono per esempio collocarsi su piani diversi: nel ritmo, nell’intonazione, nella pronuncia delle vocali o in quella delle consonanti, e così via. Due accenti locali possono sembrare ugualmente lontani dallo standard a un ascoltatore, e al tempo stesso esserlo per ragioni molto diverse. Quanto contano i diversi piani, o la loro interazione, per i sistemi di riconoscimento del parlato? Non esistono informazioni pubblicate, e sospetto che nemmeno le aziende che li sviluppano abbiano dati del genere.
 

venerdì 23 dicembre 2016

Comprensione del dialogo: scarsa

Continuando il mio confronto tra i sistemi di dettatura ho visto che il parlato spontaneo in italiano pone ancora enormi problemi. La percentuale di errori, espressa in WER, è di regola superiore al 50%: 10 volte superiore rispetto a quella per lettura ad alta voce.
 
Una parte di questi problemi è senz’altro dovuta al fatto che i prodotti con cui ho fatto il confronto non sono pensati per interpretare dialoghi. Non compiono quindi alcune operazioni moderatamente semplici e che con ogni probabilità permetterebbero di migliorare molto il risultato: non distinguono tra le voci dei dialoganti, non cercano di disambiguare le sovrapposizioni… Inoltre, eliminano spesso le ripetizioni di parole o segmenti, che però fanno parte costitutiva di un dialogo.
 
Tuttavia, le scarse prestazioni nel riconoscimento sono sicuramente dovute anche ad altri fattori, e in particolare al fatto che il parlato reale è difficile da comprendere, con le sue sovrapposizioni, ripetizioni, incertezze, parole che sfumano l’una nell’altra e via dicendo.
 
Qui di sotto riporto i risultati del riconoscimento di un dialogo interpretato da due diplomati o studenti universitari baresi, un maschio e una femmina, di poco più di vent’anni: Corpus CLIPS, sottocorpus Dialogico – Bari – Map Task, file DGmtA02B.wav. Il dialogo è in italiano, con accento ben percepibile ma lieve; in qualche punto in cui si passa all’italiano regionale o direttamente al dialetto. Ho passato gli audio a Dragon (senza addestramento utente) e a Google (Docs). Le percentuali di errore sono queste:
 
Dragon
Parlante a: 53,9 (22,7 sostituzioni, 30 cancellazioni, 1,3 inserimenti)
Parlante b: 71,4 (28,6 sostituzioni, 39,3 cancellazioni, 3,4 inserimenti)
Totale: 58,6
 
Google
Parlante a: 45,7 (12,1 sostituzioni, 32,3 cancellazioni, 1,3 inserimenti)
Parlante b: 74,3 (15 sostituzioni, 56,8 cancellazioni, 2,4 inserimenti)
Totale: 53,4
 
In entrambi i casi, inoltre, i problemi sono dovuti al riconoscimento di un numero molto basso di parole. La trascrizione ortografica originale del dialogo contiene 767 parole. Dragon ne trascrive solo 530, Google arriva al massimo a 481. Per Google poi occorre mettere in campo tutta una serie di stratagemmi, visto che il riconoscimento online di Google Docs ogni tanto si blocca. La soluzione migliore che ho trovato è stata quella di inserire pause di silenzio di 3 o 5 secondi nel file audio originale e interrompere il riconoscimento di Google Docs in corrispondenza di queste pause: apparentemente questo dà al sistema il tempo di elaborare l’input precedente. Tuttavia, come mostra il WER, anche se riconosce poco, quel poco Google lo riconosce bene.
 

giovedì 10 novembre 2016

Primi dati: Google meglio di Dragon

 
Finalmente ho i primi risultati del confronto tra i sistemi di dettatura.
 
Per questo lavoro ho usato sei file audio del corpus “Lettura frasi” contenuto all’interno del corpus CLIPS. I testi sono ancora brevissimi (12 minuti in totale) ma l’importante è iniziare…
 
I file che ho usato per il confronto sono:
 
LFp1A02B
LFp1A03B
LFp1B02B
LFp2A02B
LFp2A03B
LFp2B02B
 
Tutti i testi sono in italiano regionale con leggero accento barese e sono letti da diplomati o studenti universitari di poco più di vent’anni. Ho passato gli audio a Dragon (senza addestramento utente) e a Google (Docs). In nessuno dei due casi la trascrizione è stata perfetta, ma le percentuali di errore sono state molto basse – come del resto accade nei testi letti, molto diversi dalle conversazioni spontanee (tra queste ultime, percentuali del genere sarebbero da record).
 
Soprattutto, Google ha ottenuto un ottimo WER: solo il 5,5%. Dragon, che nelle mie prime prove sembrava addirittura superiore, ha commesso errori a un tasso quasi doppio, il 9,2%. Ecco i risultati di dettaglio sui singoli audio, calcolati con SCLITE:
 
Dragon
LFp1A02B: 13,7 (sostituzioni 6,3, cancellazioni 7,3)
LFp1A03B: 8,1 (sostituzioni 3,7, cancellazioni 4,1, inserimenti 0,3)
LFp1B02B: 8,4 (sostituzioni 4,4, cancellazioni 4,1)
LFp2A02B: 7,1 (sostituzioni 3,7, cancellazioni 3,4)
LFp2A03B: 8,7 (sostituzioni 4,3, cancellazioni 4,0, inserimenti 0,3)
LFp2B02B: 9,0 (sostituzioni 4,3, cancellazioni 4,7)
Media: 9,2
 
Google
LFp1A02B: 4,7 (sostituzioni 2,7, cancellazioni 1,3, inserimenti 0,3)
LFp1A03B: 4,1 (sostituzioni 2,0, cancellazioni 1,4, inserimenti 0,7)
LFp1B02B: 7,1 (sostituzioni 3,0, cancellazioni 3,0, inserimenti 1,0)
LFp2A02B: 4,7 (sostituzioni 3,7, cancellazioni 1,0)
LFp2A03B: 6,7 (sostituzioni 3,7, cancellazioni 2,0, inserimenti 1,0)
LFp2B02B: 5,7 (sostituzioni 3,3, cancellazioni 2,0, inserimenti 0,3)
Media: 5,5
 

martedì 8 novembre 2016

Assistenti vocali e riga di comando

  
 
Google Home
Che somiglianza può esserci tra un assistente vocale e una riga di comando? Cioè, tra l’interfaccia informatica più recente e intuitiva e quella più antica e controintuitiva? Più di quelle che si potrebbe pensare, si scopre leggendo un approfondito articolo (pubblicato il 3 novembre da Ars Technica) che discute le funzionalità e i limiti di Google Home: Google Home review: A step forward for hotwords, a step backward in capability.
 
L’autore, Ron Amadeo, nota molte altre cose su Google Home. Per esempio, che diverse funzioni disponibili sui telefoni Pixel non sono presenti in Google Home, anche se il sistema alle spalle, Google Assistant, è lo stesso. Come mai? In parte per ragioni di praticità, in parte per motivi poco chiari. Tuttavia, per me la sezione più interessante dell’articolo è stata quella che riguarda i “Command line problems without comprehensive documentation”. Cioè un problema che ho incontrato spesso: senza manuale di istruzioni è molto difficile capire che cosa un assistente vocale può o non può fare. Per questo proliferano le liste di funzioni  e qualche esempio, anche se non a scopi pratici, si è visto anche su questo blog.
 
Alla radice c’è una moda della comunicazione contemporanea: il divieto di creare manuali di istruzioni. Questa è un’ottima linea guida per applicazioni semplici e con pochi parametri, soprattutto nel caso di un uso occasionale. Tuttavia, quando si devono eseguire compiti complessi, è molto importante avere indicazioni chiare e facilmente reperibili. Anche solo rimanendo nell’ambito dei servizi on-line, se ci si deve iscrivere a un corso di laurea occorre sapere un bel po’ di cose e leggere un bel po’ di informazioni. Se si deve consultare un catalogo di biblioteca alla ricerca di una pubblicazione precisa, tra pubblicazioni che hanno titoli simili o sono opera dello stesso autore, un’interfaccia specializzata può essere indispensabile. E così via. La tendenza a progettare interfacce ipersemplificate (“col gufetto”, come le chiamo io) ha senso solo davanti a compiti ipersemplici. Per attività complesse semplicemente non funziona.
 
Non funziona, però, nemmeno con gli attuali assistenti vocali. Per un programma su computer, perfino un’interfaccia semplificata fornisce almeno qualche indicazione grafica su ciò che si può fare. Con un’interfaccia vocale le cose non funzionano così. Paradossalmente, nota Amadeo, questo riporta gli utenti a una condizione simile a quella delle vecchie interfacce a riga di comando:
 
Using Google Home is a lot like using a command line. With no real interface to speak of, you have an infinite amount of input possibilities—you can say anything to Google Home, and you can type anything into a command line—but getting anything done relies on knowing what commands will actually do something. If you sit down in front of a command line system you've never seen before, you could blindly enter commands into the terminal and hope to hit on something, but you'll quickly find the command line is only as good as the documentation surrounding it.
 
Google è una delle aziende più redditizie del mondo e non avrebbe certo problemi a trovare i fondi per migliorare i servizi: l’anno scorso ha avuto un utile di 16 miliardi di dollari. Tuttavia, non è nuova a questo genere di problemi. Per esempio, con Google in linea strumenti che consentano di trovare libri in modo efficiente dal punto di vista del lettore: la lunga storia di Google Libri è una storia di grandi risultati tecnologici e immense frustrazioni da parte degli utenti. Non sarei sorpreso se la storia si dovesse ripetere e le grandi potenzialità di uno strumento rimanessero prive di utenti semplicemente perché gli utenti non hanno modo di capire in che modo funziona lo strumento stesso.
 

giovedì 3 novembre 2016

Il corpus CLIPS

  
 
Il logo del progetto CLIPS
I risultati di un sistema vocale dipendono dalle caratteristiche dei testi cui è applicato. Un conto è essere capaci di riconoscere il parlato di speaker professionisti che leggono singole parole, un conto sbobinare una conversazione spontanea.
 
Per valutare un prodotto è quindi indispensabile sottoporgli campioni di parlato che rispondano a ciò che il prodotto deve fare. Se si tratta di un sistema di dettatura, dovranno essergli sottoposte registrazioni di dettature. Se si tratta di un assistente vocale, dovranno essergli sottoposti testi esempi di conversazione.
 
Mettere assieme materiali realistici di questo tipo è però molto oneroso. Per fortuna, nel caso italiano esiste un corpus sviluppato proprio per questo: il corpus CLIPS, “Corpora e Lessici dell’Italiano Parlato e Scritto”. Il corpus è stato sviluppato grazie a un finanziamento del Ministero dell’Istruzione, dell'Università e della Ricerca (MIUR) dal 1999 al 2004, e la sua sezione che riguarda il parlato è disponibile in linea assieme a una gran quantità di informazioni di presentazione. Per accedere ai materiali, che comprendono trascrizioni e registrazioni di circa 100 ore di parlato, è sufficiente registrarsi (automaticamente) sul sito.
 
Il fuoco del lavoro è rappresentato dalla variazione diatopica. Il corpus CLIPS infatti mira a rappresentare il parlato di 12 città italiane scelte come rappresentative: Bari, Bergamo, Bologna, Cagliari, Catanzaro, Firenze, Genova, Lecce, Milano, Napoli, Palermo, Parma, Perugia, Roma. Il materiale è poi suddiviso in:
 
a) parlato radiotelevisivo (notiziari, interviste, talk show) b) parlato raccolto sul campo (dialoghi raccolti secondo le modalità del map task e del ‘gioco delle differenze’) c) parlato letto d) parlato telefonico
 
La presentazione della variazione diatopica corrisponde a una fissazione degli altri parametri sociolinguistici. Per il “parlato raccolto sul campo”, il riferimento scelto è quello delle persone di livello socioloinguistico “medio o mediosuperiore”: tutti i parlanti usati sono diplomati o studenti universitari che al momento della registrazione avevano tra i 18 e i 30 anni. Non si tratta quindi di una campionatura del “parlato” italiano nel suo assieme, ma solo di una sua sezione. D’altra parte, raccogliere campioni di n varietà di parlato avrebbe richiesto di moltiplicare il lavoro per n!
 
La disponibilità dei file audio e delle trascrizioni permette quindi di valutare in modo abbastanza semplice le prestazioni di strumenti come Google, Dragon o simili. Io ho cominciato a fare questo lavoro, e conto di fornire qui un po’ di dati nelle prossime settimane.
 
Un punto debole: per gli assistenti vocali sarebbe particolarmente utile il parlato delle conversazioni telefoniche. All’interno di CLIPS queste però sono state registrate con una campionatura molto ridotta (8000 Hz) rispetto al resto del corpus (20.050 Hz). Il risultato è una serie di registrazioni poco comprensibili agli esseri umani, e a maggior ragione anche alle macchine. Ciò non toglie che CLIPS resti uno strumento magnifico, e molto utile.
 

venerdì 28 ottobre 2016

Miglioramenti nel WER

  
 
Geoffrey Zweig (foto dal sito Microsoft)
Il mese scorso Microsoft ha annunciato un risultato notevole: il gruppo di ricerca “Speech & Dialog” guidato da Geoffrey Zweig ha sviluppato un sistema che nel riconoscimento del parlato in lingua inglese ottiene un WER (Word Error Rate) del 6,3%.
 
L’annuncio è rilevante anche perché accompagnato da una pubblicazione scientifica che documenta con un minimo di dettaglio la situazione: W. Xiong, J. Droppo, X. Huang, F. Seide, M. Seltzer, A. Stolcke, D. Yu, G. Zweig, The Microsoft 2016 Conversational Speech Recognition System, arXiv:1609.03528, 12 settembre 2016. In molti casi, invece, le aziende sviluppatrici presentano simili percentuali di errore senza contesto, rendendo impossibile sapere che cosa significhino veramente: a seconda del tipo di parlato con cui è confrontato, uno stesso sistema può avere percentuali di errore dallo 0 al 100%. Nel caso Microsoft sappiamo invece che il WER del 6,3% è riferito a un corpus molto usato nell’industria, Switchboard.
 
Più in dettaglio, il corpus è costituito da due componenti.
 
La prima, Switchboard-1, è una raccolta di parlato telefonico messa assieme dalla Texas Instruments tra il 1990 e il 1991 grazie a un finanziamento della DARPA. La versione della raccolta usata oggi è in sostanza quella revisionata nel 1997 e comprende 2.400 conversazioni telefoniche tra 543 parlanti (302 uomini e 241 donne) provenienti da diverse aree degli Stati Uniti.
 
Le conversazioni raccolte non sono del tutto naturali, anzi, sono state messe assieme in modo complesso. Come spiega il sito di presentazione:
 
A computer-driven robot operator system handled the calls, giving the caller appropriate recorded prompts, selecting and dialing another person (the callee) to take part in a conversation, introducing a topic for discussion and recording the speech from the two subjects into separate channels until the conversation was finished. About 70 topics were provided, of which about 50 were used frequently. Selection of topics and callees was constrained so that: (1) no two speakers would converse together more than once and (2) no one spoke more than once on a given topic.
 
Switchboard-2 è stato invece raccolto dal Linguistic Data Consortium (LDC) per un progetto del Ministero della Difesa degli Stati Uniti. Il corpus è composto da 3.638 conversazioni telefoniche di cinque minuti che hanno coinvolto 657 parlanti (358 donne e 299 uomini). Tuttavia, non mi è chiaro se Microsoft abbia usato anche questo (credo di sì), visto che nella forma originale Switchboard-2 non è stato trascritto.
 
I due Switchboard fanno parte fin dal 2000 del pacchetto di valutazione del NIST statunitense. In aggiunta a loro, il pacchetto di valutazione comprende anche il corpus Call Home, usato anch’esso da Microsoft ma con percentuali d’errore ben più alte (11,9% nel caso migliore).
 
Lo strumento usato da Microsof è innovativo: comprende una serie di sistemi basati su reti neurali Alla base si trovano due diverse architetture di modelli acustici basati su “convolutional neural nets” (CNN) e “long-short-term memory nets” (LSTM); entrambi i modelli sono presenti in diverse varianti. La loro combinazione, permette appunto di arrivare al 6,3% (il miglior sistema singolo si ferma al 6.9%).
 
Naturalmente, però, tutto dipende dal corpus! Nel caso di Switchboard, le conversazioni sono una simulazione ben riuscita di un parlato reale (come si può sentire da questo campione). Il WER è stato quindi calcolato su una ragionevole approssimazione di situazioni tipiche... perlomeno per la lingua inglese.
 

mercoledì 26 ottobre 2016

Il word processing, la luce e la voce

  
 
Copertina di Track Changes di Matthew Kirschenbaum
Dal punto di vista storico, il lavoro di ufficio ha spesso avuto una forte componente vocale. Anzi, che le persone importanti (tipo i dirigenti di un’azienda) possano scrivere da sole su una tastiera è un’idea molto recente, nata all’inizio degli anni Ottanta negli Stati Uniti e diffusasi solo con l’avvento dell’informatizzazione. Fino quel periodo, per un dirigente usare una tastiera rappresentava una degradazione sociale: un ridursi al rango di segretaria. Un po’ più tollerata era la scrittura a mano, ma l’unica forma di comunicazione davvero dignitosa era quella orale. “Scrivere” una lettera, nella logica di un dirigente, significava dettarla.
 
Qualche ricordo di quel periodo si trova all’interno di un bel libro di Matthew G. Kirschenbaum, Track Changes, di cui sto parlando a parte su un altro blog. Il centro di interesse del libro è il modo in cui gli scrittori hanno iniziato ad adottare il word processor, ma nel ricostruire questa storia l’autore deve parlare spesso del contesto.
 
In retrospettiva, del resto, uno degli aspetti più curiosi della storia dell’informatica è stata la difficoltà ad accettare l’idea scrivere su uno schermo. “The iconic conjunction of a cathode ray or video display and typewriter has a much more tangled history than many of us realize”, dice Kirschenbaum (p. 120), che se ne occupa nel sesto capitolo del suo libro. Non potrei essere più d’accordo. Come ho cercato di raccontare in altre occasioni, l’avvento questa idea fu graduale e sorprendentemente tardo.
 
Storicamente, la “madre di tutte le demo” di Douglas Engelbart, nel dicembre 1968, rappresentò uno spartiacque e mostrò per la prima volta le possibilità della videoscrittura. Come ricorda Kirschenbaum, uno degli spettatori della demo di Engelbart fu Andy van Dam, che iniziò a collaborare sulla videoscrittura con Ted Nelson, teorico dell’ipertesto (p. 121); un altro pioniere ispirato da Engelbart fu Larry Nelson, così come Douglas Hofstadter. Poi Kirschenbaum cita Charles Simonyi, l’informatico ungherese creatore di uno dei primi programmi di videoscrittura e poi di Word, con una delle sintesi più belle che mi sia mai capitato di sentire: “‘In retrospect it all [la videoscrittura] seems so obvious. Uh-uh, it wasn’t obvious to anyone” (p. 124).
 
Chi iniziò a occuparsi di scrittura sul video correva notevoli rischi professionali (p. 125). Tuttavia, è evidente che far comparire le parole su uno schermo produceva un’impressione profonda: tra gli scrittori citati nel libro lo ricorda esplicitamente per esempio Peter Straub. La “scrittura con la luce” (p. 46) aveva insomma fascino. I lavori andarono quindi avanti, e nel giro di pochi anni si iniziò a parlare di WYSWYG (p. 126). Nel 1974 Larry Tesler, insieme ad altri, iniziò a sviluppare un’interfaccia senza modalità (mode) per i computer Bravo. Secondo Tesler questo fu il primo prodotto a funzionare come un programma di scrittura moderno (p. 127). Negli anni successivi, Bonnie McBird, che poi sposò Alan Kay, scrisse con l’interfaccia Gypsy la sceneggiatura del film Tron (pp. 127-131).
 

Ma mentre gli sperimentatori andavano avanti, il mondo delle aziende sposava un altro concetto, completamente basato sulla voce e sulla carta (per la carta, Kirschenbaum cita non solo Sellen e Harper, ma anche il film promozionale di Jim Henson The Paperwork Explosion). Quello era il mondo del “word processing”, etichetta che probabilmente venne usata per la prima volta negli USA nel 1970 secondo una definizione che “includes the concepts of both dictation and typing, utilizes the language of centralization, efficiency, and flow, and compares word processing to what Henry Ford’s assembly line did for automobiles”. Tuttavia, il termine sembra nato da un’interazione “between one of IBM’s German sales executives, Ulrich Steinhilper, and an American counterpart, Samuel J. Kalow” (p. 174). Quest’ultimo sosteneva che un dirigente doveva usare solo due macchine: il telefono e il dittafono (p. 175).
 
Da parte sua, Steinhilper aveva già dal 1955 pensato al textverarbeitung come uno dei due percorsi, assieme all’elaborazione dati, che nascevano dal pensiero e portavano alla realizzazione rispettivamente di testi o di dati. Alla fine, entrambi i percorsi dovevano unirsi sotto il marchio IBM! Steinhilper studiò nella sede della Merceds a Stoccarda il costo della produzione di comunicazioni scritte e lo giudicò tanto alto da giustificare l’acquisto di attrezzature dedicate. All’interno della IBM, nel frattempo, si parlava già di “text processing”, definizione preferita a quella di “word processing”. L’obiettivo finale, comunque, era la carta (p. 176).
 
Questa è la storia che Kirschenbaum racconta soprattutto nel cap. 7 del suo libro, prendendo un punto di partenza insolito, il poeta Wendell Berry. Quest’ultimo pubblicò nel 1987 una lista delle ragioni per cui non intendeva usare il computer: una di queste ragioni era il fatto che i suoi manoscritti venivano già efficientemente ribattuti e corretti dalla moglie! Per questa osservazione, Berry fu (comprensibilmente) criticato e deriso. Tuttavia, l’episodio spinge a distinguere i diversi tipi di lavoro al computer. Scrivere non è solo “composition” ma anche “typing and retyping, to say nothing of the work of correspondence and copying, of filing and bookkeeping, and so forth” (p. 140), e ci si può chiedere chi sia a svolgere questi lavori.
 
Alla fine degli anni Settanta le “killer app” disponibili su computer erano il programma di scrittura e il foglio di calcolo (a partire da VisiCalc, 1979, per Apple II). Gli utenti del foglio di calcolo venivano visti come uomini. “By contrast, the word processor was imagined from the outset as an instrument of what labor and technology historian Juliet Webster has termed ‘women’s work’” (p. 141). Lo stesso era successo per la macchina da scrivere, che però alla fine aveva portato nell’immaginario visivo due figure molto diverse: non solo la segretaria, ma anche lo scrittore di hardboiled. Programmi come Gypsy, invece, erano stati esplicitamente pensati per segretarie. Jeannette Hoffman ha notato che sistemi di videoscrittura come i Wang si basavano su schemi predefiniti di lavoro (un lavoro compartimentalizzato e alienato) e avevano livelli diversi di autorizzazione: una poesia di Patricia Freed Ackerman scritta su un word processor Wang (p. 143) è un buon esempio dei sentimenti che un lavoro di questo genere poteva suscitare.
 
I programmi di scrittura sembravano promettere un approccio diverso. Tuttavia, le prime versioni di WordStar, WordPerfect o Perfect Writer si basavano su un gran numero di comandi non intuitivi e avevano una ripida curva di apprendimento. Erano, insomma, strumenti per chi faceva il “word processor” di mestiere. Secondo Jeannette Hoffman, solo per l’adozione delle interfacce grafiche mise fine a questa impostazione.
 
In ufficio, tutto questo si inseriva all’interno di un paradigma preciso: quello che gli studiosi di management definivano “l’ufficio del futuro” (pp. 143-149). Uno degli obiettivi di questa impostazione era quello di ridurre le perdite di tempo e “razionalizzare” le attività dei lavoratori. Di qui l’idea di una totale divisione del lavoro basata su centri specializzati nel word processing. Per evitare che le segretarie perdessero tempo tra un lavoro e l’altro, per esempio, una delle idee più apprezzate all’epoca era quella di far dettare i dirigenti su nastro e spedire poi le registrazioni al centro di word processing.

Tra i pochi a tenere in considerazione in questo periodo il lavoro delle donne fu Evelyn Berzin con la sua Redactron Corporation, fondata nel 1969 (pp. 149-155). I prodotti della Redactron, come il Data Secretary, vennero presentati come strumenti per eliminare i compiti più ripetitivi – per esempio, la battitura di lettere sempre uguali per le spedizioni di massa – e consentire alle segretarie di dedicarsi a quelli più creativi.

La crisi finale della Redactron Corporation, quando avvenne, alla fine degli anni Settanta, non fu legata a scelte femministe ma alla crisi del concetto generale di “word processing” dal punto di vista organizzativo. A sostituirla fu il modello di “office automation” che nel giro di dieci anni avrebbe portato un computer su tutte le scrivanie. A quel punto, “Executives would increasingly be doing their own typing” (p. 153).
 
Tuttavia, il concetto originale di “word processing” non riguardava solo corpi, mani e tastiere. Includeva anche, come anticipato, “the voice and the ear, speaking and listening, dictation and transcription” (p. 155). Prima di essere elaborate le parole dovevano “originate somewhere”, e questo “was assumed to be oral, from the mouth of an executive”. Come nota Thomas Haigh, i sistemi di dettatura venivano spesso venduti assieme a quelli di scrittura, e tutto il concetto di “word processing” “did not refer exclusively, or even primarily, to the use of full-screen video text editing”. I sistemi inventati includevano spedizione di nastri, dettatura per telefono, registratori “tank type” in cui il nastro permetteva alla segretaria di iniziare a sbobinare la registrazione prima ancora che il dirigente avesse finito di dettare, e così via (p. 156). In un episodio del 1960 di The Twilight Zone si vede un famoso autore teatrale che opera unicamente dettando.
 
E d’altra parte, dice Kirschenbaum, “today dictation is once again rising in importance” (p. 158), essendo diventata finalmente usabile - come cerco di raccontare su questo blog. Il più famoso portavoce di queste tecnologie nell’ambito letterario è Richard Powers, che, secondo Kirschenbaum, vede il “word processing” come “fundamentally multimodal, involving speech, pen or stylus, touch, and the keyboard” (p. 159). Com’è ovvio, anche qui condivido completamente l’idea.
 
Matthew G. Kirschenbaum, Track Changes. A Literary History of Word Processing, Cambridge (Massachusetts), Belknap Press, 2016, pp. xvi + 344, € 25, ISBN 978-067441707-6. Letto nella copia della Biblioteca di Lingue e letterature romanze dell’Università di Pisa.