Vi sono diversi fattori da tenere in considerazione. Per illustrare questi punti, userò un esempio di un campo in cui un utente dovrebbe inserire una percentuale in un contesto di una quota definita per un'attività specifica in termini di spazio su disco che l'attività potrebbe utilizzare. 0% indica che l'attività non sarebbe in grado di scrivere nulla sul disco; 100% indica che l'attività potrebbe riempire tutto lo spazio su disco. I valori in mezzo significano cosa significano.
Come sviluppatore, probabilmente stai considerando che i valori accettabili sono [0, 1, 2, 3, ⋯ 99, 100] e tutto il resto è sciocco. Vediamo perché gli utenti potrebbero ancora inserire quei valori "stupidi".
Errori di battitura
%^
L'utente stava inserendo il valore 56, ma ha premuto per errore Shiftdurante l'immissione (ad esempio perché sulla tastiera francese, è necessario premere Shiftper inserire le cifre e l'utente passa costantemente da una tastiera francese a una QWERTY).
Allo stesso modo, puoi ottenere un numero, con qualcosa dopo o prima di esso, o tra:
56q
Qui, probabilmente l'utente stava inserendo le cifre, seguito da una scheda per passare al campo successivo. Invece di premere ⇆ , l'utente ha premuto il tasto vicino.
Incomprensioni e interpretazioni errate
Un input vuoto è probabilmente il più comune. L'utente immaginava che il campo fosse facoltativo o che non sapesse cosa inserire in questo campo.
56.5
L'utente ha ritenuto accettabili i valori in virgola mobile. O l'utente ha torto e l'applicazione dovrebbe spiegare educatamente perché sono accettati solo i valori interi o i requisiti iniziali erano sbagliati ed è logico consentire agli utenti di inserire valori in virgola mobile.
none
L'utente ha frainteso che quando è stato chiesto lo spazio che l'attività potrebbe richiedere, l'app si aspettava un numero. Ciò potrebbe indicare un'interfaccia utente scadente. Ad esempio, chiedendo all'utente "Quanto spazio su disco dovrebbe essere occupato dall'attività?" Invita a questo tipo di input, mentre un campo con un segno di percentuale che segue riceverà meno di quel tipo di input, perché "none%" non crea molto senso.
150
L'utente ha frainteso il significato della percentuale in questo caso. Forse l'utente voleva dire che l'attività può occupare il 150% dello spazio attualmente utilizzato, quindi se su un disco da 2 TB vengono utilizzati 100 GB, l'attività potrebbe utilizzare 150 GB. Ancora una volta, potrebbe essere utile un'interfaccia utente migliore. Ad esempio, invece di avere un campo di input nudo con un segno di percentuale aggiunto ad esso, si potrebbe avere questo:
[____] % of disk space (2 TB)
Quando l'utente inizia a digitare, cambierà il testo al volo per diventare questo:
[5___] % of disk space (102.4 GB of 2 TB)
Rappresentanze
Numeri di grandi dimensioni o numeri con virgola mobile possono essere rappresentati in modo diverso. Per esempio, un numero di 1.234,56 potrebbe essere scritta così: 1,234.56. A seconda della cultura, la rappresentazione testuale dello stesso numero sarebbe diversa. In francese, lo stesso numero sarà scritto in questo modo: 1 234,56. Vedi, una virgola dove non te lo aspetti, e uno spazio.
Aspettarsi sempre un formato specifico utilizzando una specifica lingua ti metterà nei guai prima o poi, perché gli utenti di diversi paesi avrebbero abitudini diverse di scrivere numeri, date e ore, ecc.
Umani contro computer
Twenty-four
Gli umani comuni non pensano allo stesso modo dei computer. "Ventiquattro" è un numero reale, indipendentemente da ciò che un PC ti direbbe.
Sebbene (1) la maggior parte dei sistemi non gestisca affatto questo tipo di input e (2) quasi tutti gli utenti non immaginerebbero di inserire un numero scritto a lettere intere, ciò non significa che tale input sia sciocco. In About Face 3 , Alan Cooper sottolinea che non gestire tali input è indicativo dell'incapacità dei computer di adattarsi all'uomo e, idealmente, l'interfaccia dovrebbe essere in grado di gestire correttamente quegli input.
L'unica cosa che devo aggiungere al libro di Alan Cooper è che in molti casi i numeri sono scritti in cifre per errore . Il fatto che i computer si aspettino che i loro utenti commettano errori (e non tollerino un utente che scrive correttamente) è fastidioso.
Unicode
5𝟨
Unicode riserva le sue sorprese: i personaggi che potrebbero apparire uguali non sono gli stessi. Non convinto? Copia e incolla "5𝟨" === "56"negli strumenti di sviluppo del tuo browser e premi Enter.
Il motivo per cui quelle stringhe non sono uguali è che il carattere Unicode 𝟨non è uguale al carattere 6. Ciò creerebbe una situazione in cui un cliente arrabbiato chiamerebbe, dicendo che la tua app non funziona, fornendo uno screenshot di un input che sembra legittimo e che la tua app afferma che l'input non è valido.
Perché qualcuno dovrebbe inserire un carattere Unicode che assomiglia a una cifra, chiederesti? Anche se non mi aspetto che un utente ne inserisca uno involontariamente, una copia-incolla da una fonte diversa potrebbe causare ciò, e ho avuto un caso in cui l'utente ha effettivamente fatto tale copia-incolla di una stringa che conteneva un carattere Unicode che non avrebbe appare sullo schermo.
Conclusione
Questi sono i casi che ottieni per un campo di immissione di numeri elementari. Ti farei immaginare cosa puoi gestire per forme più complesse, come una data o un indirizzo.
La mia risposta è focalizzata su ciò che hai chiamato input "sciocco". Il test non riguarda il controllo dei percorsi felici; si tratta anche di verificare che l'app non si rompa quando un utente malintenzionato sta inserendo intenzionalmente cose strane, cercando di romperla. Ciò significa che quando chiedi una percentuale, devi anche testare cosa succede quando l'utente sta rispondendo con una stringa contenente 1.000.000 di caratteri, un numero negativo o una tabella bobby .