L’interfaccia è il prodotto

Jef Raskin, progettista Apple ai tempi del primo Mac, evidenziava come le modalità di un’interfaccia sono fonte di confusione. Gli errori “modali” avvengono quando l’utente ha sviluppato dei comportamenti automatici sbagliati a causa di un funzionamento poco coerente dell’interfaccia.

 

Per comprendere meglio il concetto di modalità bisogna definire cosa sia un atto. Un atto è una sequenza di azioni che una volta memorizzata viene eseguita in modo automatico dal utente.

«Dato un atto l’interfaccia si trova in modalità specifica se l’interpretazione di questo atto è sempre costante».
Gli errori modali avvengono, quando «lo stato attuale dell’interfaccia non è il fuoco dell’attenzione dell’utente e l’interfaccia risponderà all’atto in uno fra più modi possibili a seconda dello stato attuale del sistema»

 

Le scorciatoie da tastiera di un software applicativo sono un classico esempio di modalità. Quando la stessa combinazione di tasti può essere usata per compiere operazioni diverse a seconda dello stadio dell’interfaccia (quindi del programma in esecuzione) si incorre nell’errore modale. Ciò, infatti, non consente che ad ogni atto corrisponda un unico e costante comportamento del sistema.

 

Secondo Raskin, i sistemi interattivi a misura d’uomo sono costruiti su un unico ambito di azioni; ognuno è formato dall’insieme di stati in cui una azione ha interpretazione costante. Ad esempio la pressione del tasto comando e della lettera “v” in molti applicazioni permette di copiare elementi. L’operazione ha efficacia in diversi stati dell’interfaccia, (poiché l’atto è uguale) per cui si configura come l’ambito di un determinato atto.

 

I programmi che utilizzeranno la combinazione per compiere operazione diverse, creeranno inevitabilmente un nuovo ambito, dunque una ulteriore modalità. Nei sistemi non modali ogni atto dell’utente ha un risultato unico: questa è un aspetto fondamentale per fare abituare le persone che si concentrano sulle attività da svolgere piuttosto che sul funzionamento del sistema.

 

Tuttavia nella progettazione di interfacce si pensa ancora in termini di «compromessi tra facilità di apprendimento e rapidità di esecuzione»Tale assunto ha come conseguenza diretta quella di creare modi diversi per eseguire la stessa operazione secondo dicotomie discutibili che ritengono gli utenti bisognosi a seconda del loro grado di esperienza.

 

Queste sembrano le maggiori difficoltà rispetto alle questioni di usabilità, poiché nessun utente, principiante o esperto, è esente da errori modali. Come continua Raskin oltre a non includere modalità inutili le interfacce dovrebbero tendere alla monotonicità: «un’interfaccia monotona è quella in cui un dato risultato può essere ottenuto in un solo modo». Questo non significa che ci sia un’unica soluzione per arrivare a un dato contenuto ma piuttosto che: «ciascun comando deve essere invocabile mediante un unico atto».

 

Un interfaccia completamente non-modale e monotona «ha una corrispondenza 1:1 fra cause (comandi) ed effetti (operazioni)». Solo così l’utente può sviluppare un grado di fiducia nelle sue abitudini d’uso, per cui l’interfaccia scompare permettendogli di concentrarsi su ciò che gli interessa.

 

Uno dei principali standard nella progettazione di interfacce software stabilisce di creare modalità in grado di annullare le operazioni messe in atto dagli utenti. “Progettare per l’errore” significa fare in modo che nessuna azione dell’utente abbia un carattere irreversibile e definitivo. Questo è il motivo per cui le interfacce grafiche, per svolgere ogni operazione, richiedono continue conferme. L’idea è che la richiesta di conferma attrae l’attenzione di un utente facendolo passare da un comportamento inconscio ed automatico ad uno stato conscio e vigile.

 

Tuttavia la tendenza delle persone a formare comportamenti automatici o abitudini è inevitabile, per cui qualsiasi sequenza di azioni ripetuta diventa automatica. Anche le operazioni che richiedono di confermare una scelta diventano, se riproposte nello stesso modo, parte di una sequenza automatica. E l’abitudine umana in questo caso vanifica le richieste di conferma che risultano solo una complicazione (quindi un’operazione in più) nel corso dell’interazione con il sistema.

 

Raskin segnala un metodo più efficace per ovviare a questi problemi: permettere agli utenti di annullare un comando sbagliato anche se, nel frattempo, si sono effettuate altre operazioni; oppure «si può almeno cercare di assicurare che la conferma data dall’utente non sia automatica». Questi meccanismi, infatti, hanno efficacia solo quando non si presentano mai nello stesso modo attivando, dunque dei comportamenti consci delle persone che non possono scaturire, con il passar del tempo, in una risposta prevedibile ed automatica.