Ho alcune informazioni da inserire in una casella di testo. I dati sono strutturati e solo alcune sequenze sono valide. Per un numero di telefono, ad esempio, una lettera come A
non è valida.
Quindi dovrei intercettare gli eventi della tastiera e impedire che le lettere digitate raggiungano la casella di testo o dovrei disegnare alcune linee rosse (o un altro segnale visivo) per far sapere al mio utente che la lettera non è accettabile? Qual è la migliore esperienza utente?
Ignorare il controllo di un utente sul proprio computer sarà sempre un'interruzione, e spesso sarà percepita come un'invasione, del flusso di lavoro di quell'utente. Il sito Web "non dovrebbe" avere il controllo dei nostri computer, quindi esercitare tale controllo sarà almeno un po 'allarmante.
Detto questo, affronti un argomento davvero importante, essendo l'importanza di far sapere a un utente che la sua voce non è valida prima che compili un intero set di campi e li invii.
L'approccio che ho trovato essere il meno invadente, ma fornire la risposta di inversione più rapida è il flusso di seguito.
In sostanza, attendi che compili il loro primo campo, quindi mentre fanno clic/tab attorno a un nuovo campo (o un campo che è stato invalidato), controlla il campo che è stato appena completato. Se il campo che è stato appena completato è valido, stampa un'icona "buona" discreta accanto ad essa (verde, segno di spunta, faccia felice, ottieni l'idea). Se non riesce le regole di convalida, stampa in modo discreto un'icona "errata" (rossa, "X", ecc.) E una breve riga su ciò che è fallito.
Ma ricorda, non interrompere il loro flusso di lavoro:
Quando hanno finito con il campo in cui si sono spostati, torneranno al campo non valido o passeranno e torneranno più tardi. Ad ogni modo, vedranno che hanno una modifica da apportare ma possono farlo nel loro tempo libero.
Alla fine, avranno un modulo completamente valido prima di inviarlo, il che significa
Essendo alle due estremità dell'uso di un modulo, ecco alcune linee guida che preferisco:
onBlur()
e non prima. Ciò offre all'utente la possibilità di correggere la "A" digitata in modo errato prima di mostrare un messaggio di errore. Consentire all'utente di correggere un errore mentre si è ancora nel campo di input offre una possibilità in meno per un tipo di messaggio "ehi, incasinato, amico".Se si impediscono caratteri non validi durante la digitazione, potrebbero potenzialmente pensare che la tastiera non funzioni correttamente. All'utente piace che le cose funzionino come si aspettano. Se hai intenzione di impedire la pressione di alcuni caratteri sulla pressione dei tasti, almeno dovresti anche visualizzare contemporaneamente un messaggio di errore vicino all'ingresso. In questo modo sanno perché non sta scrivendo.
Un'altra cosa che può diventare fastidiosa è quando hai appena finito di compilare un modulo lungo e il sito utilizza la convalida lato server, quindi devi tornare indietro attraverso il modulo per scoprire cosa c'è che non va. Mi piace utilizzare principalmente la convalida lato client, ma ricadere sul lato server. Visualizzerò un errore durante la digitazione o quando l'ingresso perde lo stato attivo. In questo modo l'utente sa subito che c'è un problema e sa esattamente qual è il problema.
Trovo che impedire agli utenti di fare errori sia sempre 10 volte più difficile di quanto pensassi inizialmente. Esempio: il numero di telefono di qualcuno potrebbe avere un interno, come x2333. Ho usato plugin maschera di input jQuery per le carte di credito e ha funzionato bene. Uso il suggerimento automatico ogni volta che è possibile.
In qualsiasi sistema complesso, avrai circostanze che sono costose da rilevare in linea e devi dirle dopo il fatto. Per me, la risposta è caso per caso e assicurati di coprire ogni caso Edge.
Suggerirei un ibrido di entrambi gli approcci, ma solo per campi strettamente validati come numeri di telefono (SSN, codici postali, ecc ... qualsiasi cosa che deve sia numerica per definizione).
Tieni traccia di ogni sequenza di tasti e, quando l'utente digita un carattere non valido, mostralo ... ma segnala immediatamente che qualcosa non va. Forse gira il campo di input in rosso e visualizza un "Inserisci solo caratteri numerici" a destra del campo.
Bloccare l'input è un no-no perché può essere male interpretato dall'utente. Potrebbero presumere un problema con la loro macchina o dispositivo di input, non che non avrebbero dovuto digitare una lettera in una casella di immissione numerica.
La convalida dopo l'inserimento è completo può essere fastidioso. In particolare con campi come quelli utilizzati nella creazione di password. Alcuni siti richiedono password di 6 caratteri con solo caratteri alfanumerici. Altri richiedono password di 9 caratteri e consentono qualsiasi carattere (inclusi! @ # $% E simili). Digitando una password e scoprendo solo dopo l'ho digitato è il tipo di modulo più fastidioso che ho trovato e in realtà mi ha allontanato da diversi servizi .
Fornire feedback dinamici quando l'utente immette i dati li aiuta
Il blocco dell'input non riesce su tutti e 3 gli account. L'evidenziazione degli errori di convalida dopo che la casella di testo è stata completata non riesce su tutti e 3.
Dipende dal caso. Se possibile, utilizzare il suggerimento automatico. Se intercetti l'input dell'utente, un feedback immediato è cruciale. Una delle possibili soluzioni è la "casella degli indizi" che compare immediatamente dopo l'intercettazione della chiave. Puoi vederlo nella schermata di accesso di Windows, si apre se si preme $ sign per esempio.
Come per la maggior parte delle cose ... dipende dal contesto. Ho un approccio più specializzato sull'argomento. La maggior parte delle applicazioni su cui io, o il mio gruppo, lavoriamo sono di natura tecnica e sono utilizzate solo da persone ragionevolmente addestrate. In quanto tali, possiamo mettere più responsabilità e libertà nelle mani degli utenti di quanto tu possa fare con il grande pubblico. In breve, alcune delle linee guida che utilizziamo ...
Quasi tutti gli esempi sono richiesti dall'utente e, sì ... l'implementazione a volte è un vero orso/incubo/assassino ma raramente impossibile.
Avvertenza: Ancora una volta, questi esempi sono riportati nel contesto di un sistema verticale con una base di utenti tecnica .... non un modulo pubblico in generale per il web, ecc. Il tuo chilometraggio può variare.
* Tranne il rosso. Nel nostro business il rosso significa: pericolo che potresti essere ucciso ... o peggio.