it-swarm-eu.dev

Convalida e divulgazione progressiva

Sto cercando di trovare un esempio di validazione progressiva. Abbiamo un'interfaccia utente per un editor visivo in cui un utente fa cose come indicare dimensioni in pixel o percentuale.

Le proprietà dell'editor sono in gruppi di schede, quindi non tutti i campi sono visibili contemporaneamente. Abbiamo discusso di come e se eseguiamo la convalida in questa UI.

Vengo dal punto di vista che: a) la convalida è utile perché creerà un canale di comunicazione in cui l'utente può apprendere le aspettative del software e "migliorare" in base alle esigenze. b) È sempre meglio indicare direttamente gli errori di convalida nei campi di input (indipendentemente dal fatto che un riepilogo sia utilizzato o meno altrove) in modo che gli utenti abbiano un segnale visivo di ciò che deve essere modificato.

La mia collega, per la quale non ho nient'altro che il massimo rispetto, non è d'accordo. La sua logica è la seguente: a) Sarà più opportuno prevenire determinati tipi di voci o, nel caso di alcune voci, cambiarlo in un valore più appropriato se non è valido. Ad esempio, se qualcuno utilizza un valore percentuale maggiore di 100, l'interfaccia utente reimposterà il valore su 100 in un evento focus perso. b) Poiché ci troviamo in un ambiente a schede, alcuni degli errori non saranno visibili all'utente. L'uso di un riepilogo è inutile poiché potenzialmente possono esserci "molti" errori di convalida.

Ho pensato che una soluzione al riguardo potesse essere una divulgazione progressiva di valori non validi. Quando un utente immette valori che potrebbero non essere corretti, vengono contrassegnati in una sorta di riepilogo. Il riepilogo consente agli utenti di navigare anche nei campi in questione senza che siano visibili.

Vorrei essere una persona originale ma sono sicuro che ci sono precedenti qui. Le mie domande sono le seguenti:

  1. Qualcosa da aggiungere alle prospettive di me o del mio collega?

  2. Qualche esempio di un'interfaccia utente come questa con una voce complessa che esegue la convalida progressiva?

11
David in Dakota

Attualmente stiamo affrontando lo stesso problema per un'app desktop, sebbene non basata su tab. Puoi provare un approccio come questo:

alt text

dove appare una piccola icona se qualcosa richiede l'attenzione dell'utente. Forse anche usare due colori: giallo per gli avvertimenti e rosso per cose che devono essere riparate prima che l'utente possa andare oltre.

7
Hisham

La cosa migliore che puoi fare in questa complessa situazione è creare un prototipo di quanta più interfaccia utente puoi e testalo sulla tua base di utenti per vedere cosa succede. È possibile utilizzare l'HTML in combinazione con qualcosa come l'interfaccia utente di jQuery per ottenere rapidamente molti controlli interattivi disponibili e pronti per il test rapidamente.

Il tuo sistema di schede sembra complicato, quindi devo suggerire un paio di cose per semplificare:

  • Crea pulsanti "applica" all'interno di ogni scheda in modo che lo stato possa essere salvato solo per le proprietà che l'utente può vedere in questo momento. Se ciò comporterebbe uno stato dell'applicazione non valido, riprogettare le schede in modo che gli utenti abbiano raggruppate le proprietà in modo che possibile siano salvate indipendentemente l'una dall'altra.
  • Se non puoi farlo, puoi evidenziare le schede con un'icona "non valida" e un colore per indicare le proprietà in quella scheda richiedono attenzione. Mentre le schede non sono valide, il pulsante "Applica" è disabilitato. Potresti considerare di aggiungere una notifica al pulsante se viene cliccato per visualizzare un messaggio che indica che ci sono ancora errori. I riepiloghi di ciò che è sbagliato verrebbero visualizzati all'interno di ogni scheda anziché avere un riepilogo generale.
  • Un riepilogo globale potrebbe funzionare, ma sono titubante nel suggerirlo in quanto sembra che non ci sia una posizione immediatamente ovvia per dirlo e, a meno che non sia così, gli utenti se ne accorgeranno?
  • Come vengono raggruppate le proprietà? Probabilmente funzionalmente? Prova a guardarli da una prospettiva diversa, ad esempio dalla probabilità di utilizzo. Questo fa parte del modo in cui Microsoft ha affrontato il progetto Ribbon per i suoi prodotti Office 2007. Forse potresti progettare le tue schede in modo tale che la maggior parte degli utenti abbia solo bisogno di confondere le proprietà nella prima, o immediatamente visibile, e le altre schede potrebbero essere considerate "avanzate" o contestuali.

Alla fine, e l'ho già detto, prova il tuo design! :-)

Per quanto riguarda gli errori di gestione, la mia esperienza è stata che se si impediscono determinati input, gli utenti verranno confusi. Ad esempio, se da un campo di input non è chiaro che sono consentiti solo numeri, ma in ogni caso non si accettano altri caratteri, ciò sarà frustrante per l'utente: non lo sperimenteranno come un modulo intelligente che sta cercando di aiutarli . Quindi ti suggerisco di usare la microcopia chiara se decidi di seguire il percorso dell'uso degli eventi e del rilevamento degli input per correggere automaticamente le cose.

Ma tutto ciò è aneddotico - non ho fatto alcuna ricerca in questo settore. Invece di crederci sulla parola, fai riferimento al libro di Luke Wroblewski, Web Form Design: Filling in the Blanks , e la sua ricerca sulla gestione degli errori per alcune intuizioni utili su come affrontare situazioni come questa (per ad esempio, questo post sulla riprogettazione del modulo di checkout di Apple discute come gestiscono gli errori in dettaglio).

4
Rahul

Di recente ho lavorato a un progetto che ha riscontrato un problema simile. Puoi vedere uno screenshot di come l'abbiamo risolto nel mio articolo " Minimizing Complexity " dello scorso anno.

1
Tyler Tate

Ho pensato a un caso in cui viene utilizzato un riepilogo per molti errori e un tipo di lavori, forse.

In any IDE, ad esempio Visual Studio, è possibile che si verifichino infiniti errori durante la creazione o l'utilizzo di strumenti di analisi statica durante la scrittura di codice. Generalmente ci sono dozzine o centinaia di file e molti di essi si aprono in schede, con una o due visibili contemporaneamente,

Gli errori vengono quindi elencati in un elenco ridimensionabile scorrevole che scorre (per impostazione predefinita) sotto l'interfaccia utente principale. Questo potrebbe essere fatto non appena viene intrappolato un errore. Quando si fa clic o si fa doppio clic su un errore, si porta nel posto giusto e ci si concentra per correggerlo - e l'errore scompare dall'elenco quando non è più valido.

(In realtà, molti di questi errori richiedono un'azione avviata dall'utente per essere rivalutati, ma ci sono molti componenti aggiuntivi di analisi statica che lo fanno in background e aggiornano effettivamente l'elenco degli errori in modo dinamico durante la modifica del codice) .

0
Oskar Duveborn

a) Ad esempio, se qualcuno utilizza un valore percentuale maggiore di 100, l'interfaccia utente reimposterà il valore su 100 in un evento focus perso.

Buon punto, ma poi devi assicurarti:

  1. L'utente si rende conto che il suo input è stato corretto.
    Forse, per esempio, fai lampeggiare il campo per un secondo se aggiusti il ​​valore.

  2. Puoi ragionevolmente indovinare cosa intendesse veramente l'utente.
    Ad esempio, prendi un selettore di colori con cui ho lottato ieri. Volevo che alcuni elementi corrispondessero a quelli di un altro sito, quindi mi sono procurato i valori esadecimali e li ho incollati nelle minuscole caselle di testo ad hoc. Il primo valore era #202040, ma per qualche motivo ho incollato solo #20204, che è stato prontamente "corretto" su #020204. Il secondo valore in cui ho incollato era #BCD (scorciatoia per #BBCCDD), anch'esso "riparato" su ... #000BCD. Sospiro.
0
badp