I moduli Web consentirebbero un input non valido?

Perché le interfacce utente sono spesso costruite dai programmatori. I programmatori tendono a pensare a interfacce utente come interfacce con qualsiasi altro sottosistema: l'input deve essere fornito in un formato specificato non ambiguo e l'input non valido deve essere rifiutato.

Il supporto di più formati di input diversi o formati flessibili (ad esempio trattini e spazi opzionali) non fornisce alcun valore nell'integrazione dei sistemi, ma aumenta solo la complessità e il rischio di errori non rilevati.

Un esperto di UX sosterrà che le interfacce uomo-computer sono diverse dall'integrazione dei sistemi e che un formato di input più flessibile fornisce valore in un'interfaccia utente. Ma un tipico sviluppatore senza formazione UX non la penserà come predefinita.

Si noti che il supporto di un solo formato univoco è il più semplice e sicuro. I formati flessibili richiedono alcune decisioni di progettazione (ad esempio quanti trattini, spazi e parentesi sono consentiti in un numero di telefono? Sono consentiti solo in determinate posizioni o ovunque?) Quindi c'è un certo (piccolo) costo rispetto al solo consentire un singolo input formato.

Ragioni tecniche

Il modo più semplice per mettere in linea un modulo è progettarlo in HTML . Il browser ha la responsabilità di raccogliere i dati e di inviarli al server quando l'utente lo invia. È veloce da sviluppare, economico e non richiede molta esperienza. Tutto questo a spese dell'esperienza utente dovuta all'elaborazione asincrona da parte del server.

Avere controllo di input interattivo, convalide e avvisi richiedono più lavoro. Sia sul lato client (ad esempio JS o altri linguaggi di scripting) o sul server (ad esempio, in particolare per convalide più complesse, che dipende dai dati inseriti in precedenza). Ma poi con una comunicazione attiva tra client e server (ad es. Ajax) e più larghezza di banda. L'esperienza utente è molto migliore, ma richiede più esperienza, più tempo e più costi.

Ambiguità, complessità e arbitrato

Alcuni dati sono ambigui. Data in genere vengono immesse in DD / MM / AAAA in alcune parti del mondo, MM / DD / AAAA in altre parti (e AAAA-MM-DD nel mondo ISO). E i vecchi utenti (io?) Continuano a provare AA invece di AAAA. Quindi il 10/12/16 sarebbe molto ambiguo e troppo rischioso per interpretare liberamente.

Si potrebbe immaginare di aggiungere un dialogo sulla disambiguazione. Ma la terza volta che l'utente disambigerebbe qualcosa che gli appare chiaro, comincerà a arrabbiarsi. Così o tieni complesso, o lasci che la tua app web impari le preferenze dell'utente. Si potrebbe consentire un dialogo ancora più semplice "il prossimo lunedì" non è ambiguo, ma richiederebbe più intelligenza per analizzare la risposta.

And here come the chatbots that will make webforms belong to the past...

Analisi dei requisiti insufficiente e mancanza di anticipazione

Non passa una settimana, che qualcuno della mia compagnia richieda ulteriori controlli su alcuni campi. "Eviterà molti errori stupidi". Sì ! Ma potrebbe anche evitare molti input validi che non sono considerati quando è stato richiesto il controllo.

In genere, i numeri di telefono internazionali, gli indirizzi stranieri, i codici postali stranieri vengono spesso dimenticati dalle aziende locali che non sono abituati a gestire tali casi ogni giorno (vivo all'estero e incontro tali casi almeno una volta al trimestre!).

Ma per favore, non incolpare i programmatori !!!

Sarebbe facile dare la colpa alla gente sbagliata: "È colpa dell'IT" o "È un programmatore pigro o incompetente".

Non posso essere d'accordo. Nella maggior parte dei casi arriva un cliente o una mangiatoia e dice: " voglio questo nuovo webform per ieri, e dovrebbe costare meno di quanto me lo chieda ". E il programmatore cercherà quindi la soluzione più veloce, più semplice ed economica ... (vai al paragrafo 1)

Penso davvero che le aziende inizino a riconoscere l'importanza di UX, quando temono il rischio di perdere clienti perché i concorrenti fanno UX meglio. Solo allora ci sono abbastanza investimenti per questo tipo di problemi.

Why does this input technique seems ubiquitous? Explicit requirements? A common design pattern? Modern software layers? Specific web technologies? Cost? Risk aversion? Inexperienced developers? Offshoring? Or do many developers simply see no difference -- these are equivalent solutions ?

Non c'è una buona ragione tecnica. Il motivo per cui vedi spesso questo è che molti programmatori sono programmatori pigri che non pensano né si preoccupano dell'usabilità dell'utente finale.

Se i dati possono essere resi accettabili con semplici trasformazioni (ad esempio: rimuovere o aggiungere un trattino o spazi nei numeri di telefono e sicurezza sociale) assolutamente dovrebbe. Infatti, molti siti non lo fanno perché, francamente, sono stati scritti da programmatori cattivi.

Naturalmente, questa non è una valutazione vera al 100%. A volte la soluzione migliore richiede più tempo per risolvere che una soluzione "abbastanza buona" e i vincoli di business non consentono una soluzione ottimale.

È lo stesso motivo per cui vedi sempre i messaggi del modulo "hai 1 elemento (i) ...". Il computer è abbastanza intelligente da sapere se pluralizzare o meno, ma un programmatore è semplicemente troppo pigro o semplicemente non gli interessa.

Given that it seems like such a poor user experience, why does it continue to be so common?

Che dire:

Pigrizia ...

... e lavoro amatoriale in generale. E il fatto che molti programmatori non si preoccupano dell'esperienza utente.

Prendi i numeri di telefono. Nel mio paese, i numeri di telefono nazionali sono composti da dieci cifre, la prima cifra è necessariamente zero. Mentre un numero può essere inserito come:

• 0123456789
• 01 23 45 67 89
• +33 1 23 45 67 89
• +33 (0) 1 23 45 67 89

la maggior parte dei siti Web accetta solo il primo modulo, indipendentemente dal fatto che:

• È difficile entrare e soggetto a errori (metà del tempo in cui digito il mio numero di telefono usando il primo modulo, commetto un errore ... l'altra metà semplicemente inserisco intenzionalmente un numero che non esiste ).

• Rende impossibile per uno straniero utilizzare il modulo (registrarsi su un sito, ad esempio).

Invece, ciò che uno sviluppatore professionista farebbe è di consentire a qualsiasi numero di telefono ¹ di essere inserito, e quindi provare ad analizzarlo. In realtà, non è nemmeno così difficile: Twilio fa un ottimo lavoro di analisi dei numeri per te.

Lo stesso vale per gli indirizzi postali: Google API fa un ottimo lavoro di analisi di un indirizzo rappresentato come una stringa.

Tuttavia, ha senso essere rigoroso durante l'analisi di alcuni tipi di campi . Ad esempio, l'utilizzo di un formato rigoroso per una data può essere utile se gestisci più culture: "04/07/2016" indica il 4 luglio 2016 in Francia, ma il 7 aprile 2016 negli Stati Uniti, quindi l'utente può inserire la data in qualsiasi formato e cercando di capire quale sia la data potrebbe portare a risultati indesiderati.

Parlando di spazi ...

Nei campi che sono solo un gruppo di numeri o caratteri, come i numeri di telefono, contano spazi . Prova un piccolo esperimento: trova su Windows qualsiasi disco Windows o Microsoft Office con un numero di serie. Copia questo numero in un editor di testo e rimuovi gli spazi (finirai con 25 caratteri casuali). Prova a copiarlo a mano dallo schermo su un pezzo di carta (senza spostare il cursore sullo schermo). Ora riprova mentre aggiungi spazi o newline ogni quattro caratteri. Quale era più facile?

Sfortunatamente, il valore degli spazi è sottostimato da molti programmatori. Non solo molti campi non accettano spazi (numeri di telefono, numeri di carte di credito), ma molti numeri visualizzati mancano spazi, il che è molto importante quando questi numeri devono essere scritti durante una telefonata o copiati a mano (e se non lo sono, perché visualizzarli del tutto?)

Ad esempio, il mio ultimo ordine da Amazon mostra un numero di spedizione come 6Z00148794199. Ottimo che posso semplicemente copiarlo e incollarlo sul sito web del corriere per il monitoraggio; meno grande è il fatto che quando ho ricevuto la spedizione, l'agente ha dovuto copiare il codice a mano dal mio cellulare sul suo computer per poter accedere alle informazioni. Quanto sarebbe difficile per la società visualizzare il numero come 6Z 001 487 941 99?

Lo stesso ordine è identificato da Amazon come 402-9261109-4961946. Almeno hanno fatto lo sforzo di aggiungere trattini. Sfortunatamente, questi trattini non sono di grande aiuto se qualcuno deve chiamare il supporto di Amazon e scrivere l'ID. Sarebbe così difficile scriverlo come 402 926 110 949 619 46 invece?

Recentemente, ho fatto un viaggio in Scozia usando ScotRail. Ho ordinato i biglietti attraverso il loro sito web e ho ricevuto una e-mail contenente il numero CFJRC9T9 da utilizzare per recuperare i biglietti presso la stazione ferroviaria. Ora, com'è facile digitare otto personaggi privi di significato su una biglietteria self-service, con persone che camminano dappertutto? Non sarebbe molto più semplice se fosse CF JR C9 T9 invece?

^{Si può essere abbastanza liberali nell'accettare veramente qualcosa di sano. I limiti possono essere puramente tecnici; ad esempio, la lunghezza del campo può essere limitata a 50 caratteri: la probabilità che un valore più lungo sia un numero errato è vicina al 100% (se non esattamente al 100%).}

A volte non è sempre chiaro quale sia l'intenzione dell'utente o quale data, numero, ecc. stiano tentando di inserire.

A volte i framework come Ruby on Rails sono utilizzati da programmatori non esperti nelle tecniche di User Experience sui moduli Web per aiutare gli utenti con i formati di dati.

Inoltre alcuni programmatori non conoscono i tipi di dati HTML5 non disponibili sul Web che aiutano a immettere il formato corretto e vengono utilizzati dai dispositivi client-side.

A volte l'internazionalizzazione e la localizzazione possono rendere più difficile la validazione per eseguire il lato client

Il testo Web e i menu a discesa sono di per sé generici, spesso utilizzando solo elementi di base input e select in modo da convalidare correttamente l'effettivo utilizzo semantico degli elementi, ad es. 'età' o 'colore' richiede un lavoro extra da parte dei programmatori.

Le buone pratiche possono aiutare a migliorare la situazione, come

• menu a discesa per un numero limitato e fisso di voci consentite (evitando i campi di testo e i relativi problemi di convalida intrinseca)

• gli errori di testo non sono solo rossi, usano grassetto e 'x'

• ajax per ogni campo che mostra se valido 'as you go' anziché dopo l'invio del modulo
• testo segnaposto che descrive i dati e qualsiasi formato per i campi di immissione del testo

Tutti i tuoi suggerimenti potrebbero essere la ragione per i fenomeni descritti e spesso non sarà stata una decisione concreta fare un modulo web comportarsi in quel modo, ma ... in generale, in qualsiasi tipo di comunicazione, è un cattiva idea di andare con "Penso di sapere cosa intendi".

Più è esplicito l'utente, più è probabile che otterrai ciò che l'utente intende fornire.

Se non permetti tratteggi o spazi, è più facile perdere un personaggio e non notarlo. Se chiedi un indirizzo e-mail una volta o permetti che il secondo venga copiato e incollato, è più facile digitarlo e non notarlo. Sì, sta spingendo il lavoro all'utente, ma per una buona ragione, lo sviluppatore non può sapere quali dovrebbero essere i dati giusti e supporre non è ciò che ci piace fare. Quindi il meglio che puoi fare è chiarire in anticipo ciò che il sistema si aspetta da un utente e farglielo "sillabare" piuttosto che fargli mormorare e correggerlo in un secondo momento, sperando che tu possa farlo bene.

A causa ...

• è più veloce
• è più facile
• richiede conoscere molto più di alert('Fail!');

E a nessuno importa abbastanza da consentire una combinazione di più tempo per risolvere i problemi correttamente, insistere su un lavoro più intenso da parte degli sviluppatori o assumere sviluppatori che siano effettivamente in grado di svolgere il lavoro.

Perché Chase Bank consente solo password alfanumeriche anche se questo è solo un problema di metodo di escape della stringa della libreria principale nella maggior parte dei casi e rende tutti i loro account estremamente vulnerabili alle tabelle rainbow in caso di violazione? Non ci sono misteri qui. È solo gente che succhia.

Inoltre, ho davvero bisogno di cambiare banca.

Non è pigrizia. Come fai notare la stessa quantità di codice per analizzare l'input in entrambi i modi. Ma mi chiedo se qualcuno di voi abbia avuto questa conversazione ...

QA. "ok e poi ho digitato 'ciao mondo' nel campo telefonico e l'ho appena salvato nel db"

Dev. "Beh, non ci sono requisiti per il controllo del numero di telefono degli utenti, cosa vuoi che faccia?"

BA. "hmm Dovrebbe essere un bel errore quando dici solo numeri, per favore"

QA. "E i numeri di telefono in stile americano con trattini e parentesi, ecc?"

BA. "ok, 'solo numeri, spazi parentesi e / o trattini'"

QA. "per quanto riguarda i prefissi internazionali? hai bisogno di un vantaggio"

BA. "ok" solo numeri, parentesi spazi e / o trattini e vantaggi ""

UX. "perché non lasciare che l'utente digiti quello che vuole?"

QA. "dovremmo analizzare qualsiasi formato di numero di telefono nel mondo!"

BA. "dev, qual è la stima per te per scrivere qualcosa che analizzi qualsiasi numero di telefono nel mondo"

Dev. "hai un elenco dei formati?"

BA. "No".

Dev. "Infinito?"

BA, "e il messaggio?"

Dev. "1 ora"

BA. "Ok, fai il messaggio"

Il nocciolo della questione è che la prima soluzione, il solo salvataggio di qualunque cosa l'utente abbia digitato, andava bene.

Ma il processo di test e la richiesta di specifiche, ha spinto il team in primo luogo richiedendo che i numeri siano convalidati e poi scrivendo una specifica facile da raggiungere.