{"id":344,"date":"2013-03-04T10:50:36","date_gmt":"2013-03-04T09:50:36","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/siti-dal-doppio-volto\/"},"modified":"2013-03-04T10:50:36","modified_gmt":"2013-03-04T09:50:36","slug":"siti-dal-doppio-volto","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/siti-dal-doppio-volto\/","title":{"rendered":"Siti dal doppio volto"},"content":{"rendered":"

Come il dio romano Giano<\/a> (e molti politici), ogni applicazione web ha due facce: quella umana che interagisce con le persone e quella della macchina che interagisce con i sistemi di computer, spesso come risultato delle interazioni con l’utente. Mostrare troppo una delle due facce al pubblico sbagliato crea l’opportunit\u00e0 di sbagliare.<\/p>\n

Quando un’interfaccia utente, pensata per l’utilizzo umano, riflette troppo il funzionamento interno di un sistema nel suo design e nel suo linguaggio, \u00e8 probabile che confonda le persone che la utilizzano. Ma allo stesso tempo, se i dati non sono conformi a una specifica struttura, \u00e8 probabile che confondano le macchine che devono usarli, per cui non possiamo nemmeno ignorare i requisiti di sistema.<\/p>\n

Le persone e le macchine manipolano le informazioni in maniera completamente diversa. Dobbiamo trovare un modo per equilibrare i bisogni di entrambe.<\/p>\n

\n

Faccia il suo ingresso il Principio di Robustezza<\/h2>\n

Nel 1980, l’informatico Jon Postel<\/a> pubblic\u00f2 una prima specifica<\/a> del Transmission Control Protocol, che rimane un meccanismo di comunicazione fondamentale di internet. In quella specifica, enunci\u00f2 il Principio di Robustezza:<\/p>\n

\n

Siate conservativi in quello che fate, siate liberal in quello che accettate dagli altri.<\/p>\n<\/blockquote>\n

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.<\/p>\n

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\u00e9 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<\/a> e validare il formato di tutto quello che manda ai sistemi pi\u00f9 in basso nel flusso.<\/p>\n

Creare un sistema che adotti questi insieme radicalmente differenti di vincoli non \u00e8 facile. Ad alto livello potremmo dire che una applicazione web robusta<\/em> \u00e8 una che:<\/p>\n

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

    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\u00f2 aiutarci a chiudere il gap tra l’uomo e la macchina in una gran variet\u00e0 di circostanze.<\/p>\n

    Numeri<\/h3>\n

    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 \u00e8 un diverso tipo<\/a> di dato con caratteristiche uniche. Cercare di fare delle operazioni matematiche sul tipo di dato sbagliato pu\u00f2 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\u00f2 possono facilmente emergere nelle interfacce utente.<\/p>\n

    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”: \u00e8 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?<\/p>\n

    Spesso pu\u00f2, se mettiamo al lavoro il Principio di Robustezza per far s\u00ec che la nostra applicazione accetti una variet\u00e0 di input da parte dell’utente e li trasformi in qualcosa che soddisfa i bisogni di una macchina.<\/p>\n

    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:<\/p>\n

    \"Form<\/div>\n

    HTML 5 introduce<\/a> dei nuovi attributi per l’elemento input<\/code>, incluso un tipo<\/code> di numero<\/code> e un attributo pattern<\/code>, il cui scopo \u00e8 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<\/a> e inconsistente. Ma con un po’ di JavaScript si pu\u00f2 fare lo stesso lavoro. Per esempio:<\/p>\n

    <input onkeyup=\"value=value.replace(\/[^0-9\\.]\/g,'')\" \/>\n<input onblur=\"if(value.match(\/[^0-9\\.]\/)) raise_alert(this)\" \/><\/code><\/pre>\n
    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.<\/p>\n
    Possiamo rendere questi semplici esempi molto pi\u00f9 sofisticati<\/a>, 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 regolare1<\/a><\/sup> 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.<\/p>\n
    Il volto umano liberal della nostra applicazione supporr\u00e0 che questi eventi siano delle eccezioni: se abbiamo progettato ed etichettato bene le nostre interfacce, la maggior parte delle persone fornir\u00e0 un input ragionevole la maggior parte delle volte. Sebbene possa variare quello che le persone immettono (“$10.00” o “10”), il computer potr\u00e0 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\u00e0 quella supposizione prima di fare qualsiasi azione. Se la transazione \u00e8 importante, come quando un utente immette il valore di una donazione, il sistema avr\u00e0 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\u00e0. Altrimenti, la riduzione aggressiva di testo in numero potrebbe risultare in un risultato inaspettato, e potenzialmente molto problematico, per l’utente:<\/p>\n
    \"Semplificazione<\/div>\n
    Date<\/h3>\n
    Per un computer le date e le ore sono solo casi speciali di numeri. Nei sistemi UNIX-based, ad esempio, il tempo \u00e8 spesso rappresentato come il numero di secondi trascorsi<\/a> dal primo Gennaio 1970.<\/p>\n
    Tuttavia, per una persona, il contesto \u00e8 la chiave per interpretare le date. Quando Alice chiede “Possiamo incontrarci Gioved\u00ec?” Bob pu\u00f2 tranquillamente assumere che il gioved\u00ec in questione sia il prossimo sul calendario e sicuramente non deve chiedere se intende il gioved\u00ec di settimana prossima. Gli interface designer dovrebbero cercare di avvicinarsi quanto pi\u00f9 possibile a questa esperienza umana considerando il contesto in cui viene richiesta una data.<\/p>\n
    Possiamo fare ci\u00f2 rivisitando alcuni metodi tipici per richiedere una data agli utenti:<\/p>\n