Siti dal doppio volto

Faccia il suo ingresso il Principio di Robustezza#section1

Nel 1980, l’informatico Jon Postel pubblicò una prima specifica del Transmission Control Protocol, che rimane un meccanismo di comunicazione fondamentale di internet. In quella specifica, enunciò il Principio di Robustezza:

Siate conservativi in quello che fate, siate liberal in quello che accettate dagli altri.

Sebbene spesso applicato a protocolli tecnici di basso livello come il TCP, questa regola d’oro dell’informatica ha una vasta applicazione anche nel campo della user experience.

Per creare un’esperienza positiva, dobbiamo dare alle applicazioni un volto umano che sia liberal: empatico, flessibile e tollerante di qualunque numero di azioni l’utente possa fare. Ma perché un sistema sia davvero robusto, il suo volto da macchina deve anche prestare molta cura ai dati che gestisce: trattare l’input dell’utente come malevolo di default e validare il formato di tutto quello che manda ai sistemi più in basso nel flusso.

Creare un sistema che adotti questi insieme radicalmente differenti di vincoli non è facile. Ad alto livello potremmo dire che una applicazione web robusta è una che:

1. accetta l’input degli utenti in una varietà di forme, basandosi prima sui bisogni e sulle preferenze degli umani piuttosto che sulle macchine;
2. accetta la responsabilità di tradurre quell’input umano per soddisfare i requisiti dei sistemi di computer;
3. definisce i limiti di ciò che è ragionevole in un dato contesto;
4. fornisce un chiaro feedback all’utente, specialmente quando l’input tradotto eccede i limiti definiti.

Sia che si tratti di una semplice form o di un’applicazione sofisticata, ogni volta che chiediamo dell’input agli utenti, le loro aspettative sono quasi sicuramente diverse in qualche modo da quelle del computer. I nostri cervelli non sono fatti di silicio, ma pensare nei termini del Principio di Robustezza può aiutarci a chiudere il gap tra l’uomo e la macchina in una gran varietà di circostanze.

Numeri#section2

Gli umani capiscono che i termini “uno”, “1” e “1.00” grossomodo si equivalgono. Tuttavia, questi stessi sono molto differenti per un computer. Nella maggior parte dei linguaggi di programmazione, ognuno di questi è un diverso tipo di dato con caratteristiche uniche. Cercare di fare delle operazioni matematiche sul tipo di dato sbagliato può portare a risultati inattesi. Quindi, se un’applicazione web ha bisogno che l’utente inserisca un numero, i suoi sviluppatori dovranno assicurarsi che quell’input soddisfi la definizione del computer. Ai nostri utenti non interessano queste sottigliezze, che però possono facilmente emergere nelle interfacce utente.

Quando si compra qualcosa al telefono, la persona che prende l’ordine non deve mai dire “Per favore, mi dia il numero della sua carta di credito usando solo cifre, senza spazi o trattini”, non si confonde se vi fermate durante il discorso o se includete qualche “mmm”: è in grado di riconoscere un numero quando ne sente uno. Tuttavia, questi suggerimenti riempiono di solito le form web, istruendo gli utenti ad adeguarsi alle esigenze del computer. Non sarebbe bello se il computer potesse soddisfare invece i bisogni della persona?

Spesso può, se mettiamo al lavoro il Principio di Robustezza per far sì che la nostra applicazione accetti una varietà di input da parte dell’utente e li trasformi in qualcosa che soddisfa i bisogni di una macchina.

Per esempio, potremmo farlo proprio a livello dell’interfaccia, modificando i campi per fare un pre-process dell’input dell’utente, fornendo un feedback immediato all’utente riguardo a quello che sta succedendo. Considerate il campo di input che richiede un valore di una valuta:

HTML 5 introduce dei nuovi attributi per l’elemento input, incluso un tipo di numero e un attributo pattern, il cui scopo è quello di dare agli sviluppatori un modo per definire il formato atteso di un’informazione. Sfortunatamente, il supporto nei browser di questi attributi rimane limitato e inconsistente. Ma con un po’ di JavaScript si può fare lo stesso lavoro. Per esempio:

<input onkeyup="value=value.replace(/[^0-9\.]/g,'')" />
<input onblur="if(value.match(/[^0-9\.]/)) raise_alert(this)" />

Il primo input semplicemente blocca l’immissione di qualunque carattere che non sia un cifra o un punto inserito dall’utente. Il secondo fa invece partire una notifica.

Possiamo rendere questi semplici esempi molto più sofisticati, ma queste tecniche lasciano ancora le regole del computer tra i piedi dell’utente. Un’alternativa potrebbe essere quella di accettare silenziosamente qualunque cosa l’utente scelga di fornire e poi di usare la stessa espressione regolare¹ per trasformarla lato server in un valore decimale. Seguendo la linea guida numero tre, l’applicazione fa un controllo di buonsenso sul risultato e riporta un errore se un utente ha inserito qualcosa di incomprensibile o al di fuori del range atteso.

Il volto umano liberal della nostra applicazione supporrà che questi eventi siano delle eccezioni: se abbiamo progettato ed etichettato bene le nostre interfacce, la maggior parte delle persone fornirà un input ragionevole la maggior parte delle volte. Sebbene possa variare quello che le persone immettono (“$10.00” o “10”), il computer potrà processare facilmente la maggior parte di questi valori immessi per dedurne il valore decimale di cui ha bisogno, sia che lo faccia inline o lato-server. Ma il suo volto cauto, machine-oriented, controllerà quella supposizione prima di fare qualsiasi azione. Se la transazione è importante, come quando un utente immette il valore di una donazione, il sistema avrà bisogno di fornire un feedback chiaro e di chiedere la conferma prima di procedere, anche se il valore ricade all’interno dei limiti della normalità. Altrimenti, la riduzione aggressiva di testo in numero potrebbe risultare in un risultato inaspettato, e potenzialmente molto problematico, per l’utente:

Date#section3

Per un computer le date e le ore sono solo casi speciali di numeri. Nei sistemi UNIX-based, ad esempio, il tempo è spesso rappresentato come il numero di secondi trascorsi dal primo Gennaio 1970.

Tuttavia, per una persona, il contesto è la chiave per interpretare le date. Quando Alice chiede “Possiamo incontrarci Giovedì?” Bob può tranquillamente assumere che il giovedì in questione sia il prossimo sul calendario e sicuramente non deve chiedere se intende il giovedì di settimana prossima. Gli interface designer dovrebbero cercare di avvicinarsi quanto più possibile a questa esperienza umana considerando il contesto in cui viene richiesta una data.

Possiamo fare ciò rivisitando alcuni metodi tipici per richiedere una data agli utenti:

• Un input testuale, spesso con delle richieste di formattazione specifica (MM/DD/YYYY, ad esempio)
• Una widget di un calendario in miniatura, che sistema le date in una griglia mese per mese

Questi pattern non sono mutualmente esclusivi e un’applicazione robusta potrebbe offrirne uno o entrambe, a seconda del contesto.

Ci sono casi in cui la widget del calendario può essere molto utile, come l’identificazione di una data futura che non è nota (scegliendo il secondo giovedì del prossimo Febbraio). Ma per la maggior parte delle volte, un input testuale offre probabilmente il percorso migliore per inserire una data nota, specialmente se è in un futuro molto vicino. Se Bob vuole farsi un appunto per l’incontro di giovedì, potrebbe essere più efficiente per lui inserire la parola “Giovedì” o l’abbreviazione “Giov” piuttosto che richiamare un calendario e spostare il mouse (o peggio il suo dito su un touchscreen) per scegliere il piccolo box giusto.

Ma quando imponiamo dei requisiti di formattazione troppo restrittivi, danneggiamo quel vantaggio: se Bob deve capire la data numerica corretta e inserirla in un modo molto specifico, potrebbe aver ancora bisogno del calendario. O, se un’applicazione richiede che la data di nascita di Alice sia nel formato MM/DD/YYYY, perché dovrebbe dare errore se inserisce 1/1/1970, omettendo gli zeri antecedenti i numeri di mese e giorno? Nella sua testa è una data facilmente comprensibile.

Un’applicazione che abbracci il Principio di Robustezza accetterebbe dall’utente qualunque cosa che assomigli a una data, fornendo ancora un feedback per confermare l’input, ma riportandolo come problema solo se l’interpretazione fallisse o se eccedesse i limiti. Esiste un certo numero di librerie software per aiutare i computer a tradurre le descrizioni umane delle date come “domani”, “il prossimo Venerdì” o “11 Aprile” nei loro equivalenti valori machine-oriented strutturati. Sebbene molte siano piuttosto sofisticate, hanno comunque dei limiti: quindi, quando le usate, è utile fornire agli utenti anche degli esempi dei pattern più affidabili, anche se il sistema può accettare altre forme di input.

Indirizzi#section4

Forse più spesso che qualunque altro tipo di input, i campi per l’indirizzo tendono ad essere basati sulla progettazione del database piuttosto che sulla convenienza degli utenti umani. Considerate questo comune layout:

Questo insieme di campi può coprire la maggioranza dei casi per gli indirizzi degli USA, ma non si adatta molto bene agli utenti internazionali. E anche negli USA ci sono indirizzi che non rientrano bene in questo schema.

Un’applicazione che vuole accettare completamente l’input umano potrebbe adottare il coraggioso approccio dell’uso di una singola textarea per catturare l’indirizzo, permettendo all’utente di strutturarlo proprio come farebbe se stesse scrivendo una lettera. E se l’indirizzo sarà usato solo ed esclusivamente nella sua interezza, memorizzarlo come un singolo blocco di testo potrebbe essere tutto quello che è richiesto. Vale la pena chiedere che livello di dettaglio è davvero necessario per usare i dati.

Tuttavia, spesso abbiamo un bisogno preciso legato al nostro business per memorizzare l’informazione in campi discreti. Ci sono molti servizi basati sul web e applicazioni che girano in locale che possono accettare una varietà di formati di indirizzo e li standardizzano, sia che siano stati raccolti mediante un singolo input o con un insieme minimo di elementi strutturati.

Considerate l’indirizzo seguente:

Ad esempio, la Google Geocoding API potrebbe tradurlo in qualcosa di simile a quello che segue, con un alto livello di granularità per le applicazioni di mapping:

"address_components" : [
  {
     "long_name" : "20",
     "short_name" : "20",
     "types" : [ "street_number" ]
  },
  {
     "long_name" : "Avenue Appia",
     "short_name" : "Avenue Appia",
     "types" : [ "route" ]
  },
  {
     "long_name" : "Geneva",
     "short_name" : "Geneva",
     "types" : [ "locality", "political" ]
  },
  {
     "long_name" : "Genève",
     "short_name" : "Genève",
     "types" : [ "administrative_area_level_2", "political" ]
  },
  {
     "long_name" : "Geneva",
     "short_name" : "GE",
     "types" : [ "administrative_area_level_1", "political" ]
  },
  {
     "long_name" : "Switzerland",
     "short_name" : "CH",
     "types" : [ "country", "political" ]
  },
  {
     "long_name" : "1202",
     "short_name" : "1202",
     "types" : [ "postal_code" ]
  }
]

I dettagli (e i termini della licenza) di questi sistemi di standardizzazione variano e potrebbero non essere adeguati per tutte le applicazioni. Gli indirizzi complessi potrebbero essere un problema e avremo bisogno di dare all’applicazione un modo alternativo per gestirli. Sarà necessario più lavoro, ma per ottenere la miglior user experience, dovrebbe essere responsabilità dell’applicazione cercare prima di dare un senso a un input ragionevole. Non è probabile che gli utenti si preoccupino se un database CRM vuole memorizzare il loro numero di appartamento separatamente dal nome della via.

L’eccezione o la regola#section5

Fare il parsing del linguaggio umano per trasformarlo in dati strutturati non funziona sempre. Sotto la linea guida numero quattro, un sistema robusto individuerà e gestirà gentilmente e con rispetto i casi limite, contemporaneamente cercando di minimizzare la loro frequenza. Questa lunga coda di user experience non dovrebbe far scodinzolare il proverbiale cane. In altre parole, se possiamo creare un’interfaccia che funziona senza errori nel 96% dei casi, riducendo il tempo per completare i task e mostrando un livello di empatia che supera le aspettative degli utenti, probabilmente vale lo sforzo necessario per creare un loop di feedback extra che gestisca il restante 5%.

Pensate ancora al processo con cui si fa un ordine al telefono, parlando ad una persona. Se non comprende qualcosa che dite, potrebbe chiedervi di chiarire. Anche quando capisce, potrebbe rileggervi i dettagli per avere una vostra conferma. Quelle interazioni sono normali e solitamente cortesi. Infatti, rassicurano tutti noi che il risultato finale dell’interazione sarà quello che ci aspettiamo.

Tuttavia, probabilmente non vi darà un insieme di istruzioni rigide non appena risponde al telefono e poi vi rimprovera se non riuscite a rispettarne alcune. Nonostante ciò, le applicazioni web creano sempre la stessa interazione (a volte saltando le istruzioni e andando direttamente alla sgridata).

Per la maggior parte degli sviluppatori, l’integrità del sistema è una priorità comprensibilmente alta. Una struttura migliore nei dati forniti dall’utente implica che possiamo gestirli in maniera più affidabile. Vogliamo sistemi affidabili, così diventiamo avvocati dei bisogni della macchina. Quando l’input non passa la validazione, tendiamo a vederlo come un fallimento dell’utente, un errore, un tentativo di mandare dei dati cattivi nella nostra applicazione progettata così attentamente.

Ma sia che i nostri job title includano la frase “user experience” sia che non lo contengano, dobbiamo sostenere almeno le persone che usano il nostro software tanto quanto facciamo per i nostri sistemi di computer. Qualsiasi problema stia risolvendo un’applicazione web, in ultima analisi è stata creata per il beneficio di un essere umano. Chiunque lavori nella realizzazione di un’applicazione influenza l’esperienza, quindi migliorarla è il nostro lavoro. Pensare in termini di robustezza può aiutarci a bilanciare i bisogni sia delle persone sia dei computer.

La legge di Postel ha provato il suo valore facendo funzionare internet per più di tre decenni. Mi auguro che noi si possa realizzare software (e le esperienze che questo crea) con uno standard così alto.

Note#section6

• 1. Gran parte del text processing si basa sulle espressioni regolari per fare il match dei pattern. Questa tecnologia ha una lunga storia nell’informatica, ma spesso la si trova anche in applicazioni meno tecniche. Le espressioni regolari possono far paura sulle prime perché spesso coinvolgono molte notazioni “shorthand”, ma vale la pena imparare come funzionano perché hanno un valore inestimabile per chiunque lavori con il testo, che sia un programmatore o uno scrittore. Online abbondano i tutorial, i riferimenti e i tool per i test.

Illustrazioni: {carlok}