Existem vários fatores a serem levados em consideração. Para ilustrar esses pontos, usarei um exemplo de campo em que um usuário deve inserir uma porcentagem no contexto de uma cota definida para uma tarefa específica em termos de quanto espaço em disco a tarefa poderia usar. 0% significa que a tarefa não seria capaz de gravar nada no disco; 100% significa que a tarefa pode preencher todo o espaço em disco. Valores entre significam o que significam.
Como desenvolvedor, você provavelmente está considerando que os valores aceitáveis são [0, 1, 2, 3, ± 99, 100] e todo o resto é tolo. Vamos ver por que os usuários ainda podem estar inserindo esses valores "tolos".
Erros de digitação
%^
O usuário estava inserindo o valor 56, mas pressionou por engano Shiftao digitá-los (por exemplo, porque no teclado francês, é necessário pressionar Shiftpara inserir dígitos, e o usuário alternava constantemente entre um teclado francês e um QWERTY).
Da mesma forma, você pode obter um número, com algo antes ou depois dele, ou entre:
56q
Aqui, o usuário provavelmente estava inserindo os dígitos, seguido por uma guia para ir para o próximo campo. Em vez de pressionar ⇆ , o usuário pressionou a tecla vizinha.
Mal-entendidos e más interpretações
Uma entrada vazia é provavelmente a mais comum. O usuário imaginou que o campo era opcional ou não sabia o que colocar nesse campo.
56.5
O usuário achou que os valores de ponto flutuante eram aceitáveis. O usuário está errado e o aplicativo deve educadamente explicar por que apenas valores inteiros são aceitos ou se os requisitos iniciais estavam errados, e faz sentido permitir que os usuários insiram valores de ponto flutuante.
none
O usuário entendeu mal que, quando solicitado pelo espaço que a tarefa poderia ocupar, o aplicativo esperava um número. Isso pode indicar uma interface de usuário ruim. Por exemplo, perguntar ao usuário "Quanto espaço em disco a tarefa deve levar?" Convida a esse tipo de entrada, enquanto um campo com um sinal de porcentagem a seguir receberia menos desse tipo de entrada, porque "none%" não gera muito sentido.
150
O usuário não entendeu o que a porcentagem significa neste caso. Talvez o usuário queira dizer que a tarefa pode ocupar 150% do espaço usado atualmente; portanto, se um disco de 2 TB for usado com 100 GB, a tarefa poderá usar 150 GB. Novamente, uma interface de usuário melhor poderia ajudar. Por exemplo, em vez de ter um campo de entrada vazio com um sinal de porcentagem anexado, pode-se ter o seguinte:
[____] % of disk space (2 TB)
Quando o usuário começa a digitar, ele muda o texto rapidamente para se tornar o seguinte:
[5___] % of disk space (102.4 GB of 2 TB)
Representações
Números grandes ou números com um ponto flutuante podem ser representados de maneira diferente. Por exemplo, um número 1234,56 poderia ser escrito assim: 1,234.56. Dependendo da cultura, a representação em texto do mesmo número seria diferente. Em francês, o mesmo número será escrito assim: 1 234,56. Veja, uma vírgula onde você não esperaria uma, e um espaço.
Sempre esperar um formato específico usando uma localidade específica poderia causar problemas mais cedo ou mais tarde, porque usuários de diferentes países teriam hábitos diferentes de escrever números, datas e horas, etc.
Humanos vs. computadores
Twenty-four
Os seres humanos comuns não pensam da mesma maneira que os computadores. "Vinte e quatro" é um número real, independentemente do que um PC diria.
Embora (1) a maioria dos sistemas não lide com esse tipo de entrada e (2) quase todos os usuários não imaginem inserir um número escrito em letras completas, isso não significa que essa entrada seja boba. No About Face 3 , Alan Cooper afirma que o não manuseio dessas entradas é indicativo da incapacidade dos computadores de se adaptarem aos seres humanos e, idealmente, a interface deve ser capaz de lidar com essas entradas corretamente.
A única coisa que tenho que acrescentar ao livro de Alan Cooper é que, em muitos casos, os números são escritos em dígitos por engano . O fato de os computadores esperarem que seus usuários cometam erros (e não toleram um usuário que escreve corretamente) é irritante.
Unicode
5𝟨
O Unicode reserva suas próprias surpresas: caracteres que podem parecer iguais não são os mesmos. Não convencido? Copie e cole "5𝟨" === "56"nas ferramentas de desenvolvedor do seu navegador e pressione Enter.
O motivo de essas cadeias não serem iguais é que o caractere Unicode 𝟨não é o mesmo que o caractere 6. Isso criaria uma situação em que um cliente irritado ligaria, informando que seu aplicativo não está funcionando, fornecendo uma captura de tela de uma entrada que parece legítima e seu aplicativo alegando que a entrada é inválida.
Por que alguém digitaria um caractere Unicode que se parece com um dígito, você perguntaria? Embora eu não espere que um usuário entre sem querer, uma cópia e colagem de uma fonte diferente poderia causar isso, e eu tive um caso em que o usuário realmente fez essa cópia e colagem de uma string que continha um caractere Unicode que não aparecer na tela.
Conclusão
Esses são os casos que você obtém para um campo de entrada de número elementar. Gostaria de imaginar o que você pode lidar com formulários mais complexos, como uma data ou um endereço.
Minha resposta está focada no que você chamou de entrada "boba". Testar não é verificar os caminhos felizes; também se trata de verificar se o aplicativo não quebra quando um usuário mal intencionado entra intencionalmente em coisas estranhas, tentando quebrá-lo. Isso significa que, quando você solicita uma porcentagem, também precisa testar o que acontece quando o usuário está respondendo com uma sequência contendo 1.000.000 caracteres, ou um número negativo ou uma tabela de bobby .