Hay varios factores a tener en cuenta. Para ilustrar esos puntos, usaré un ejemplo de un campo en el que un usuario debe ingresar un porcentaje en el contexto de una cuota definida para una tarea específica en términos de cuánto espacio en disco podría usar la tarea. 0% significa que la tarea no podría escribir nada en el disco; 100% significa que la tarea podría llenar todo el espacio en disco. Los valores intermedios significan lo que significan.
Como desarrollador, probablemente esté considerando que los valores aceptables son [0, 1, 2, 3, ⋯ 99, 100], y todo lo demás es una tontería. Veamos por qué los usuarios aún podrían estar ingresando esos valores "tontos".
Errores tipográficos
%^
El usuario estaba ingresando el valor 56, pero presionó por error Shiftal ingresarlos (por ejemplo, porque en el teclado francés, debe presionar Shiftpara ingresar dígitos, y el usuario estaba cambiando constantemente entre un teclado francés y un QWERTY).
De la misma manera, puede obtener un número, con algo después o antes, o en el medio:
56q
Aquí, el usuario probablemente estaba ingresando los dígitos, seguido de una pestaña para pasar al siguiente campo. En lugar de presionar ⇆ , el usuario presionó la tecla vecina.
Malentendidos y malas interpretaciones
Una entrada vacía es probablemente la más habitual. El usuario imaginó que el campo era opcional o no sabía qué poner en este campo.
56.5
El usuario pensó que los valores de coma flotante eran aceptables. O el usuario está equivocado, y la aplicación debe explicar cortésmente por qué solo se aceptan valores enteros, o si los requisitos iniciales eran incorrectos, y tiene sentido permitir que los usuarios ingresen valores de punto flotante.
none
El usuario no entendió que cuando se le preguntó por el espacio que la tarea podría ocupar, la aplicación esperaba un número. Esto podría indicar una interfaz de usuario deficiente. Por ejemplo, preguntar al usuario "¿Cuánto espacio en disco debería ocupar la tarea?" Invita a este tipo de entrada, mientras que un campo con un signo de porcentaje a continuación recibiría menos de ese tipo de entrada, porque "none%" no genera mucho sentido
150
El usuario no entendió lo que significa el porcentaje en este caso. Tal vez el usuario quería decir que la tarea puede tomar el 150% del espacio utilizado actualmente, por lo que si en un disco de 2 TB se usan 100 GB, la tarea podría usar 150 GB. Una vez más, una mejor interfaz de usuario podría ayudar. Por ejemplo, en lugar de tener un campo de entrada simple con un signo de porcentaje adjunto, se podría tener esto:
[____] % of disk space (2 TB)
Cuando el usuario comienza a escribir, cambiaría el texto sobre la marcha para convertirse en esto:
[5___] % of disk space (102.4 GB of 2 TB)
Representaciones
Los números grandes o los números con coma flotante se pueden representar de manera diferente. Por ejemplo, un número 1234.56 podría escribirse así: 1,234.56. Dependiendo de la cultura, la representación de texto del mismo número sería diferente. En francés, el mismo número se escribe así: 1 234,56. Mira, una coma donde no esperarías una, y un espacio.
Esperar siempre un formato específico usando un entorno local específico lo metería en problemas tarde o temprano, porque los usuarios de diferentes países tendrían diferentes hábitos de escribir números, fechas y horas, etc.
Humanos contra computadoras
Twenty-four
Los humanos comunes no piensan de la misma manera que las computadoras. "Veinticuatro" es un número real, independientemente de lo que le diga una PC.
Aunque (1) la mayoría de los sistemas no manejan en absoluto este tipo de entrada y (2) casi todos los usuarios no imaginarían ingresar un número escrito en letras completas, no significa que dicha entrada sea tonta. En About Face 3 , Alan Cooper señala que no manejar tales entradas es indicativo de la incapacidad de las computadoras para adaptarse a los humanos, e idealmente, la interfaz debería ser capaz de manejar esas entradas correctamente.
Lo único que tengo que agregar al libro de Alan Cooper es que, en muchos casos, los números se escriben en dígitos por error . El hecho de que las computadoras esperen que sus usuarios cometan errores (y no tolerarán a un usuario que escribe correctamente) es molesto.
Unicode
5𝟨
Unicode se reserva sus propias sorpresas: los personajes que podrían tener el mismo aspecto no son los mismos. ¿No convencido? Copie y pegue "5𝟨" === "56"en las herramientas de desarrollador de su navegador y presione Enter.
La razón por la que esas cadenas no son iguales es que el carácter Unicode 𝟨no es el mismo que el carácter 6. Esto crearía una situación en la que llamaría un cliente enojado, diciéndole que su aplicación no funciona, proporcionando una captura de pantalla de una entrada que parece legítima, y su aplicación alegando que la entrada no es válida.
¿Por qué alguien ingresaría un carácter Unicode que se parece a un dígito? Si bien no esperaría que un usuario ingresara uno involuntariamente, una copia-pegar de una fuente diferente podría causar eso, y tuve un caso en el que el usuario realmente hizo esa copia-pegar de una cadena que contenía un carácter Unicode que no aparecer en la pantalla.
Conclusión
Esos son los casos que obtiene para un campo de entrada de número elemental. Te dejaría imaginar lo que puedes manejar para formularios más complejos, como una fecha o una dirección.
Mi respuesta se centra en lo que usted llamó "tonto" de entrada. La prueba no se trata de verificar los caminos felices; también se trata de verificar que su aplicación no se dañe cuando un usuario malintencionado ingrese intencionalmente cosas extrañas, tratando de romperla. Esto significa que cuando solicita un porcentaje, también tiene que probar qué sucede cuando el usuario responde con una cadena que contiene 1,000,000 de caracteres, o un número negativo, o una mesa auxiliar .