Pratiche di convalida dei dati: come posso costruire meglio il feedback degli utenti?

La domanda che dovresti porci è: come faccio a rendere la mia interfaccia utente più fruibile e amichevole nel complesso? Per fare ciò, leggi libri come "Non farmi pensare" e gli altri libri elencati qui .

Per rispondere alla tua domanda specifica sulla convalida dell'input dell'utente, ho tre suggerimenti:

1. Usa il buon senso, la cortesia e la cortesia nei confronti della tua verbosità.
2. Assegna loro tutte le convalide contemporaneamente, nella stessa pagina. Non farli camminare attraverso una serie di messaggi di errore singoli. Usa una sorta di segnale visivo per distinguere i campi non validi.
3. Se possibile, preferisci una tecnica che eviti le finestre di dialogo di conferma modali. Ad esempio, quando elimini un'email in Gmail, questo non viene confermato; al contrario, sposta il messaggio nel cestino e ti offre un'opzione per annullare.

Come hai detto la questione della convalida è soggettiva. La ragione di questo però è che si riferisce all'esperienza utente / usabilità che non è facilmente riducibile ad un numero finito di do o dont. Detto questo, esistono alcune regole generali che possono essere utilizzate per prendere decisioni di progettazione / implementazione

1. Contenuto: la prima regola dell'esperienza utente riguarda l'esperienza utente, il che significa che è più semplice per l'utente lavorare con il software, il che significa pensare come utente e non come sviluppatore (o peggio hacker)
2. Contenuto: da 1., di seguito, fornisce all'utente informazioni rigorosamente per sapere . L'utente ha solo bisogno di informazioni che sono appena sufficienti per risolvere il problema, è non interessato (in realtà si infastidisce con) in un sacco di gergo tecnico
3. Grammar: Ancora una volta cerca di utilizzare la voce passiva il più possibile, ad esempio "valore non deve essere nullo", invece di "non devi inserire valore nullo" che a seconda della cultura può sembrare maleducato / conflittuale.
4. Consegna: il feedback dovrebbe essere consegnato in modo tale da ridurre al minimo qualsiasi sforzo / tempo da parte dell'utente, motivo per cui dovrebbe essere il più immediato e accurato possibile dopo l'errore, in modo che l'utente possa correggerlo. Ad esempio è una casella di testo con input errato che dovrebbe essere immediatamente indicata con un diverso colore di invalidazione.
5. Consegna: un'estensione di 4. quando si richiede all'utente di verificare tutti gli input validi devono essere conservati, ad eccezione della password.
6. Consegna: dovrebbero essere consegnati il meno discretamente possibile, il che significa che all'utente viene notificato l'errore, ma non dovrebbe dover spendere altro tempo, quindi i dialoghi modali sono un grande no-no che dovresti cerca il più possibile di attaccare per disabilitare il pulsante OK / Successivo / Applica e invalida il controllo di input (esempio dato in 4).
7. Registrazione: Fai in modo che sia possibile attivare la modalità di registrazione. Mentre l'aiuto per la registrazione nella risoluzione dei problemi è un ostacolo alle prestazioni.
8. I18N / L10N: varia da caso a caso implementalo in modo specifico solo se ne hai bisogno ora o ne avrai bisogno in un prossimo futuro.

Aggiornamento:

Ora la situazione cambia leggermente nel contesto di un'applicazione web, con thin client e tutte le convalide che si verificano sul lato server. Per considerare questo caso, dovrebbe esserci una regola aggiuntiva successiva per importanza solo a 1. punto (vale a dire tutto su exp dell'utente), cioè performance . Qualunque cosa facciamo, la prestazione dovrebbe essere una priorità. Ora nel nostro caso le prestazioni sono strongmente influenzate dal numero di messaggi tra client e server, motivo per cui potrebbe non essere la migliore idea per inviare un messaggio dopo ogni input. Invece si potrebbe provare un approccio diverso.

Per dare un esempio, supponiamo che l'input abbia 5 passi e che l'utente inserisca dati errati nei passaggi 2 e 4, anche il passo 3 ha una password, in questo caso dopo che l'utente ha completato tutti i passaggi, il client deve inviare un messaggio per la convalida , dopo la convalida sul lato server, all'utente deve essere richiesto solo di inserire solo quell'input che era errato (o una password) per i passaggi 2,3 e amp; 4. Anche l'input da reinserire dovrebbe essere chiaramente indicato .

Aggiornato di nuovo: Reg. accessibilità per disabili, non ho mai lavorato per l'interfaccia utente, ma penso che il principio di base sia lo stesso solo invece di indicare input non validi per colore, dovrebbe essere indicato con l'aiuto dell'audio. Anche in questo caso potrebbe essere una buona idea dare un feedback immediato invece di aspettare fino alla fine di tutti gli input.

Contenuti

Tendo a utilizzare più schemi di convalida, ognuno con una breve frase, in genere la frase descriverà la violazione che hanno fatto. "XXX non può essere vuoto."

Grammatica

Non lo personalizzo come dire "potresti non avere un XXX vuoto", se vuoi renderlo più leggero puoi trattare il campo come se fosse una sua entità: "Non posso essere vuoto!" o "Devo essere almeno 30"

consegna

Preferisco una stringa di errore a colori contrastanti (rosso contro bianco) accanto al campo, il tuo flusso dovrà essere malleabile affinché funzioni.

Accesso

Non ho nei miei progetti, ma potrebbe essere necessario per ragioni specifiche (o legali / politiche) specifiche del dominio.

Internazionalizzazione

Se questo è davvero così importante, puoi suddividere le stringhe di errore in parti che potrebbero essere scambiate:

• "{field} {verbo essere vuoto"
  • XXX non può essere vuoto
  • XXX non deve essere vuoto

Should I be describing what the user did correctly or incorrectly, or simply what was expected?

Se non descrivi "erroneamente" e "cosa era previsto", l'utente è perso e non può apportare modifiche. Quello che hanno fatto correttamente è ovvio, dal momento che non è valido.

Ciò che hanno fatto in modo errato dice loro cosa cambiare.

Quello che ci si aspetta dovrebbe dirgli che tipo di modifiche apportare.

How much detail can the user read before they get annoyed?

Varia da utente a utente. Non c'è una risposta generale. E non c'è un modo semplice per sapere. Gli utenti esperti vogliono messaggi brevi. N00bz ha bisogno di lunghi messaggi. E non puoi conoscere il livello di esperienza dell'utente fino a quando dopo si lamentano dei messaggi.

How do I decide between phrases like "must not," "may not," or "cannot"?

Non puoi decidere. Non è una tua scelta. Sono i tuoi utenti. Nell'inglese americano (che non usa nemmeno "deve" se non nei documenti legali) le differenze sono minori e variano a seconda dell'utente. Ogni utente ha un livello personale di disagio (o comfort). Non puoi conoscere il livello di comfort dell'utente finché dopo non si lamentano dei messaggi.

In generale, alla gente non piace che i computer dicano loro come "devono" fare. Oltre a questo, sono le preferenze individuali.

This can depend on the project, but how should the information be delivered to the user?

Um ... Questo non ha senso. Se i dati non sono validi, non puoi andare avanti.

Should it be obtrusive (e.g. JavaScript alerts) or friendly?

Questo non ha senso. "invadente" e "amichevole" non sono ortogonali.

Should they be displayed prominently? Immediately (i.e. without confirmation steps, etc.)?

Questo non ha senso. Se i dati non sono validi, non possono andare avanti, quindi deve essere prominente.

Do you bother logging validation errors?

Parla con i tuoi avvocati delle conseguenze degli errori di immissione degli utenti. Nel campo medico, potrebbe importare. In altri campi, raramente conta. Se stai perfezionando la tua presentazione, ti consigliamo di registrare le cose in modo da poter capire qual è l'errore più comune e riprogettare le cose in modo che non possa essere fatto. Se i tuoi utenti sono tutti n00bz (perché l'app non è mai esistita prima) devi registrare le cose in modo da poter calcolare i casi d'uso reali. Se i tuoi utenti sono tutti esperti, non preoccuparti della registrazione.

How do I cater to the majority of users?

Non puoi. Le preferenze per il supporto e l'orientamento variano a seconda delle persone, del loro livello di esperienza e del loro comfort generale con i computer e l'applicazione. Ampie generalizzazioni culturali sono meno importanti di quelle individuali.

Cosa mi piace fare quando pratico:

Se il campo di input è categoricamente non valido, lo sfondo diventa rosso. Se al momento non è valido, ma potrebbe contenere una versione incompleta di una risposta valida, la spengo in giallo. Visualizzo anche in una posizione vicina un messaggio che descrive cosa è previsto e se è complesso un messaggio sul motivo per cui l'articolo non è valido.

(Esempio: l'intervallo di input è 100-2000. "1" diventa giallo. "3000" diventa rosso.)

Ecco i miei 2 centesimi:

• contenuto

Penso che dovresti descrivere perché il valore non è corretto, come "nome utente non può avere caratteri speciali" , quindi l'utente sa cosa ha fatto di sbagliato e può risolverlo. errore come "nome utente errato" sta facendo in modo che l'utente combatta l'app (ad esempio, una volta ho creato la password 50char con tutto quello che potevo pensare perché ero stanco di combattere con il pass-system, tuttavia era molto strong password e ho dovuto tenerlo in un file di testo per ricordarlo.)

• Dettagli

Penso che dovresti aggiungere abbastanza dettagli in modo che l'utente sappia cosa sta succedendo, ma non troppo (se ricevo un grosso messaggio di avviso con un sacco di spam lì, non lo leggerò nemmeno - è troppo lavoro e se posso solo fai clic su "ok" del motivo per cui preoccuparti? Potrei leggerlo la seconda volta che lo vedo, se mi interessa perché qualcosa non funziona).

• consegna

Preferisco il testo rosso vicino al campo o nella parte superiore della pagina. Uso l'avviso solo come ultima risorsa (fare clic su OK per tutto il tempo suona come qualcosa che può infastidire le persone).

• Accesso

no, se la convalida è interrotta, l'utente ti avviserà (se è un'app di lavoro o la usa molto / a)

• internazionalizzazione

Penso che dire "per favore" all'utente sia fastidioso, perché dovrebbe essere in grado di ignorare ciò che stai chiedendo e fare ciò che vuole fare. Tuttavia se dici "per favore" come "devi farlo", sarebbe fastidioso per me più il suo testo extra inutile (aka spam).

Contenuti

L'approccio Consegna offre un margine di attenzione molto maggiore sul contenuto. Spiegalo come necessario. Le persone odiano i sistemi che li fanno sentire stupidi. Un ottimo modo per farli sentire stupidi è metterli in situazioni in cui finiscono per indovinare - erroneamente.

Grammatica : leggi Elementi di stile

consegna

• renderlo visualizzabile mentre un utente modifica il modulo dati - mai colpito un avviso che ti dice cosa c'è che non va in diversi campi solo per uscire da esso e non ricordare cosa deve fare?
• mostra le restrizioni sull'immissione dei dati iniziali - accanto a ogni campo o tooltip attivo per esempio
• convalidare la sfocatura nelle situazioni che hanno senso (ad esempio, il nome utente deve essere univoco).

Accesso

Di solito no, con un grosso grasso "dipende". Vi sono situazioni in cui i guasti ripetuti giustificano la registrazione. Ad esempio, ripetere tentativi di accesso non riusciti.

Internazionalizzazione

pacchetti di risorse Java . Pensa a quest'area senza una buona risposta. Lascia ai programmatori che sia troppo dominante o troppo prolisso :). Ma forse non attribuisco abbastanza credito ai miei simili.

La mia risposta propone di uscire dal problema e di avere una visione più ampia. Se questo è più di quanto richiesto, le mie scuse e salta alla prossima risposta:)

Risposta breve: leggi Inchiostro magico .

Risposta lunga ...

Perché troviamo software frustrante da usare? Prendi in considerazione alcuni casi:

• Sei sicuro di voler ...? Gosh, io pensavo ero sicuro (dopotutto, ho emesso il comando), ma la tua domanda mi fa dubitare di me stesso - ci deve essere qualche terribile conseguenza. Spero davvero di sapere quale sia stata questa conseguenza ...

• Immissione non valida, inserisci una data valida. Mi dispiace terribilmente di averti offeso con quell'input! E 'solo che non sono completamente sicuro di come vuoi che io entri in quella data. Vorrei avere un calendario a portata di mano ...

Ok, questi esempi sono estremi, ma li abbiamo visti tutti, giusto? Mi darò da fare e dire che ho scritto una buona parte di queste domande. Il problema è che a volte passo ore, giorni o più a riflettere su tutti i possibili flussi di lavoro. Come programmatore, costruisco un modello mentale dell'intero nido di topi finché non ho interiorizzato l'intera cosa. Così ora posso vedere: "Ah sì, passaggio 7b, ho bisogno di un po 'qui per dirmi se dovrei continuare o abortire, so: sei sicuro (sì / no)? voilà! mi prenderà la mia parte. " Il problema è che l'utente non ha vissuto quelle ore e quei giorni e certamente non ha costruito il modello mentale. Non sa nemmeno che siamo al passo 7b! L'utente avrà bisogno di molte più informazioni ...

Racconto queste storie di cani irsuti per fare un punto: suggerisco che la messaggistica associata alla validazione dei dati sia in realtà solo un caso speciale del problema più generale di come presentare tutti del business- informazioni correlate (contenuto, errori, tutto). Quindi, per andare al sodo ...

Inchiostro magico è un documento che affronta frontalmente "l'ubiquità di interfacce software frustranti e inutili". Sostiene che "l'interattività è in realtà una maledizione per gli utenti e una stampella per i progettisti, e gli obiettivi degli utenti possono essere soddisfatti meglio attraverso altri mezzi". Il documento contiene anche indicazioni su altri riferimenti utili.