È accettabile normalizzare il contenuto della casella di testo quando perde lo stato attivo?

Question

Ho ricevuto requisiti che chiedono di normalizzare il contenuto della casella di testo quando l'utente cambia lo stato attivo su un altro controllo sullo stesso modulo di input dei dati. Normalizzazione di esempio:

• lo spazio bianco all'inizio e alla fine dell'input viene tagliato
• Se la casella di testo è stata vuota e ciò non è valido, sostituire il contenuto della casella di testo con il valore predefinito

Ho la sensazione che ciò non sia in linea con un buon design della GUI. Ho letto le Linee guida di Windows UX per le caselle di testo ma non l'ho fatto trova immediatamente le regole pertinenti.

La normalizzazione del contenuto delle caselle di testo in questo modo è accettabile?

Answer 1

L'ho già visto prima (alcuni esempi mi sfuggono in questo momento) ma personalmente non mi piace quando l'interfaccia utente cambia il mio input. Se l'interfaccia utente è abbastanza intelligente da cambiare il mio input su di me, allora dovrebbe accettarlo così com'è e cambiare il valore quando deve elaborarlo.

Quando l'ingresso cambia in modo automatico, stai forzando l'utente a fermarsi e chiedersi perché è cambiato e se ha fatto qualcosa di sbagliato o se l'applicazione ha un errore. Non far pensare all'utente!

Answer 2

Generalmente, dovresti accettare l'input dell'utente esattamente se lo hanno inserito. È probabile che gli utenti lo abbiano fatto in quel modo per una buona ragione. Ad esempio, immagina che un utente inserisca un indirizzo straniero e quindi la tua app lo rovini cercando di formattare come un indirizzo nazionale. Per lo meno, gli utenti hanno inserito l'input nel modo in cui sono abituati, quindi modificarlo può rendere difficile per loro il controllo incrociato.

Tuttavia, ci sono diverse eccezioni:

• Aggiungi i valori predefiniti all'input incompleto. L'aggiunta di input che l'utente ha lasciato (ad esempio, anni a date, unità a dimensioni) fornisce un buon feedback su come l'app sta interpretando l'input che sarebbe altrimenti ambiguo. Ciò incoraggia inoltre l'utente a utilizzare le impostazioni predefinite, rendendo i propri input più efficienti.

• Risolvi altre ambiguità. Passa a un formato non ambiguo se il formato dell'utente è aperto all'interpretazione. Ad esempio, se hai utenti internazionali, potresti voler cambiare "9-9 settembre" in "8 settembre 2009" (o "9 agosto 2009") per fornire un feedback su ciò che la tua app considera il mese e il giorno.

• Aggiungi delimitatori quando non forniti. L'aggiunta automatica di delimitatori standard o persino arbitrari a stringhe alfanumeriche lunghe (ad es. Numeri di telefono, numeri di carte di credito, numeri di serie) fornisce un display di input che gli utenti possono controllare più facilmente. A volte gli utenti possono inserire una stringa senza delimitatori per andare più veloci o perché sono vittime di abusi web da parte di siti che rifiutano di accettare anche delimitatori standard.

• Correzione ortografica, grammaticale e maiuscola. Gli utenti lo apprezzano spesso, ma solo se esiste anche un modo per ignorarlo. Ad alcuni utenti piace usare " i " come pronome in prima persona.

Se il campo è utilizzato da più di un utente, probabilmente dovresti formattare automaticamente il valore in un modo standard che soddisfi la maggior parte dei tuoi utenti, ma ciò dovrebbe essere fatto quando il valore è archiviato sul back-end, non quando la messa a fuoco lascia il campo. Ad esempio, se un utente inserisce un orario di 15:30, dovrebbe rimanere fino a 15:30 finché l'utente visualizza la pagina. Tuttavia, la prossima volta che un utente (qualsiasi utente) recupera i dati, dovrebbe apparire come 3:30 pm (se è così che la maggior parte dei tuoi utenti sono abituati a vedere il tempo).

Tale formattazione del back-end si applica al taglio degli spazi bianchi in modo che tutti gli utenti possano cercare, trovare e ordinare sul campo in modo coerente. Probabilmente non è una buona idea sostituire un valore vuoto (o qualsiasi valore non valido) con il valore predefinito perché è improbabile che gli utenti anticipino di ottenere quel valore. Un'eccezione potrebbe forse cambiare lo spazio vuoto su 0 per i campi numerici in situazioni in cui ovviamente vuoto == none == zero, ma ancora una volta questo dovrebbe essere fatto quando si memorizza nel back-end, non nel campo stesso. Se il bianco è ambiguo, (ad esempio, può significare 0 o può significare "non lo so"), si applica il secondo punto sopra riportato e potresti voler eseguire la correzione automatica nel campo quando si perde lo stato attivo.

Naturalmente, se i tuoi utenti variano nel modo in cui devono avere un tipo di dati formattato, puoi avere diverse varianti dell'app che visualizzano il tipo di dati in diversi modi per diversi gruppi di utenti, oppure puoi creare il formato di i dati digitano una preferenza dell'utente, ma questo è davvero un altro problema.

Answer 3

Se l'utente lo desidera e lo Stakeholder lo richiede, è perfettamente sicuro. Il taglio è molto comune. e la sostituzione è comune quando si parla di riempire la casella di testo con numeri. (uno 0 anziché uno spazio vuoto).

Answer 4

È una funzionalità abbastanza standard, in particolare il taglio degli spazi bianchi. La sostituzione del valore predefinito genera un flag più grande solo perché è meno comune.

Answer 5

Sono abbastanza sicuro di aver visto le versioni di Microsoft Office che lo fanno - mettendo " pt. " dopo un valore in punti, ad esempio. L'approvazione di Microsoft dovrebbe essere un buon segno.

Answer 6

Abbiamo alcuni di questi tipi di requisiti. Il motivo fornito per forzare un valore predefinito anziché uno spazio vuoto è che sembra migliore nei report o se il client vuole vedere il sistema live. Uno spazio vuoto assomiglia un po 'a "non si può disturbare a inserire nulla". Per un motivo simile, spesso il testo è maiuscolo per coerenza poiché gli utenti non usano mai una formattazione coerente.