Da Builder a Parser: Refactoring strutturale

Fin dalla sua origine, EVT è stato progettato per essere uno strumento generico per la pubblicazione di edizioni digitali. Per questo motivo, oltre ai vari strumenti di manipolazione dell’immagine o di collegamento di quest’ultima con il testo, il software offriva anche il supporto a due diversi livelli di edizione, diplomatico e interpretativo, entrambi codificati all’interno dello stesso file XML TEI.

Man mano che lo sviluppo è andato avanti e che il software è cresciuto in termini di caratteristiche, sono aumentati anche i problemi, in particolare quelli legati alla configurazione dei vari parametri da parte di studiosi con competenze informatiche di base e quelli legati alla navigazione all’interno dell’edizione digitale e alla gestione di un’applicazione completamente client side. Per coprire un numero maggiore di casi d’uso, infatti, le variabili di configurazione e gli elementi all’interno dell’appli- cazione web sono aumentati notevolmente; ciò ha fatto crescere il grado di difficoltà dell’utilizzo di EVT e ha reso più difficile e lungo lo sviluppo di nuove funzionali- tà, soprattutto perché ogni diversa variabile che influisce sul layout dell’interfaccia utente finale può interagire e potenzialmente entrare in conflitto con le altre. Se si pensa, poi, che le funzioni JavaScript, con cui è gestita l’intera applicazione web, incrementano notevolmente, sia l’utilizzo di memoria principale utilizzata dal bro- wser, sia l’occupazione della CPU necessaria, si comprende che il problema legato al grado di difficoltà nell’utilizzo/sviluppo, si completa con un ben più grande pro- blema, che è quello legato alle prestazioni dell’interfaccia, che tendono a rallentare considerevolmente.

Per questo motivo, si è deciso di rimodellare l’intera struttura del software, in modo da renderlo più leggero, usabile e adattabile, usufruendo dell’approccioModel

View Controller (MVC)113_{, un pattern architetturale molto comune nella program-}

mazione orientata agli oggetti che permette di separare le logiche di presentazione dei dati dalla logica applicativa e dal nucleo di elaborazione. Volendo mantenere la caratteristica originaria di EVT, e quindi non abbandonare l’approccio client only, si è deciso di utilizzare AngularJS114, unframework JavaScript ispirato alla logica di programmazione MVC, particolarmente adatto per lo sviluppo di applicazioni Web client side, che permette di definire componenti HTML personalizzati e sfrutta il meccanismo del data-binding per associare il modello agli elementi dell’interfaccia

113

MVC - Wikipedia: https://en.wikipedia.org/wiki/Model-view-controller/.

114

utente e gestire gli aggiornamenti di quest’ultima evitando manipolazioni dirette del DOM.

Prima delrefactoring, EVT era composto da due unità principali: EVT Builder, per la trasformazione del testo codificato tramite appositi template XSLT 2.0, e EVT Viewer, per la visualizzazione su browser dei risultati della trasformazione e l’interazione con essi (Fig. 1.28).

Figura 1.28: EVT Builder: flusso di trasformazione

L’idea che sta alla base della nuova versione di EVT (da ora in poi EVT 2.0) è invece quella di lasciare a EVT Viewer il compito di leggere e parsare il file del testo codificato in XML e salvare quanto più possibile all’interno di un modello dati che rimane client side nella memoria principale, ed è organizzato in maniera tale da permettere un rapido accesso ai dati in caso di necessità. Ciò porta ovviamente all’eliminazione del livello di EVTBuilder e permette, quindi, allo studioso di aprire la propria edizione digitale direttamente nel browser, senza dover effettuare alcuna trasformazione tramite processore Saxon. Il complesso lavoro direfactoring ha por- tato con sé numerose difficoltà (per esempio riscrivere in JavaScript le funzioni che permettono la suddivisione in pagine del file XML) e modifiche dell’interfaccia uten- te, ma nel presente elaborato verranno affrontate soltanto le problematiche legate all’edizione critica.

Capitolo 2

EVT 2.0: Progettazione

dell’interfaccia utente

Negli ultimi anni, i software disponibili sono cresciuti in complessità e raffinatezza e hanno raggiunto un pubblico sempre meno tecnico. Ciò ha inevitabilmente spostato la progettazione e lo studio dell’interfaccia utente (UI) in una posizione di rilievo: infatti, per essere realmente utili, i nuovi strumenti digitali devono essere intuitivi, facili da usare e accessibili, così da poter essere adoperati dal più alto numero di persone.

Ciò vale anche nel campo delle edizioni digitali: le innovative funzionalità di ri- cerca granulare, allineamento di varianti, collegamenti ipertestuali e intratestuali che potenziano le edizioni accademiche pubblicate in formato elettronico sono importan- ti, in quanto permettono di raggiungere livelli di studio e analisi precedentemente impensabili; tuttavia, se queste rimangono nascoste nell’interfaccia e quindi difficil- mente accessibili dall’utente, risulteranno inutili. Un’interfaccia complessa, inoltre, va contro lo scopo secondario di molti progetti di digitalizzazione di far uscire il proprio lavoro dalla piccola nicchia del mondo accademico e diffonderlo nel grande pubblico: sia la persona completamente estranea al mondo delle edizioni critiche, sia lo studente che ha iniziato da poco a familiarizzare con tale ambiente, devono riuscire ad orientarsi e cogliere almeno le informazioni principali riguardo l’edizione digitale visualizzata.

Risulta quindi fondamentale iniziare a curare maggiormente la progettazione dell’interfaccia grafica di un’edizione digitale; deve essere semplice, chiara e intuitiva; deve mettere l’utente in condizione tale da sapere subito cosa fare, cosa cliccare, cosa aspettarsi; deve permettere una navigazione dell’edizione sia a un livello profondo di analisi e ricerca testuale, sia a un livello più “superficiale” di semplice raccolta di informazioni a proposito del testo presentato; deve infine essere piacevole e ispirare affidabilità1.

1

Dopo aver introdotto brevemente le norme esistenti che guidano lo sviluppo di interfacce efficienti, in questo capitolo verrà illustrato il percorso che ha portato alla definizione dell’interfaccia grafica finale di EVT 2.0, evidenziando le principali problematiche affrontate e approfondendo lo studio legato agli elementi caratteristici di un’edizione critica digitale.

2.1

Principi di Human Computer Interaction

La Human Computer Interaction (HCI) è una disciplina nata agli inizi degli anni

’802, che si occupa della progettazione, valutazione e implementazione di sistemi informatici interattivi e dello studio dei principali fenomeni che li circondano, con l’obiettivo principale di realizzare prodotti usabili, sicuri e efficaci. Si tratta di un’area interdisciplinare in cui si possono ritrovare aspetti di informatica, psicolo- gia, sociologia, ergonomia, ingegneria e visual design. I principi dell’HCI «mirano a rendere adeguate le tecnologie alle categorie di utenti a cui sono indirizzate [e] per- mettono di tenere conto sistematicamente delle caratteristiche degli utenti finali, dei loro bisogni, delle loro capacità e dei contesti in cui essi interagiranno col prodotto tecnologico»3.