¿Cuán indulgente deberían ser las entradas?

Question

Fui al sitio web de mi banco el otro día e ingresé mi número de cuenta con un espacio al final. Apareció un mensaje de error que decía: "El número de cuenta debe consistir solo en valores numéricos". Pensé para mis adentros: "¿En serio? No podrías haberme despojado del espacio". Si fuera menos fanático de la informática, incluso podría haber pensado, "¿Qué? ¡Hay que son con solo números!" (no ser capaz de ver el espacio).

La calculadora que viene con Ubuntu, por otra parte, acepta alegremente espacios y comas, pero extrañamente no le gustan los puntos finales (sin los dígitos subsiguientes).

Así que, eso plantea la pregunta. ¿Cuán indulgente deberían ser los formularios web? No creo que recortar el espacio en blanco sea demasiado pedir, pero ¿qué pasa con otros campos enteros?

• ¿Deberían permitir las señales +/-?
• ¿Cuántos espacios deben permitirse entre el signo y el número?
• ¿Qué hay de las comas para separadores de miles?
• ¿Qué pasa en otras partes del mundo donde se usan puntos en su lugar?
• ¿Qué pasa si están entre cada 4 dígitos en lugar de cada 3?
• ¿Qué pasa con las representaciones hexadecimales y octal?
• Notación científica?
• ¿Qué sucede si presiono accidentalmente el botón de cita cuando estoy tratando de presionar enter, en caso de que también se elimine?

Sería muy fácil para mí eliminar todos los caracteres que no sean dígitos, y eso sería extremadamente indulgente, pero ¿qué pasa si el usuario comete un error real que afecta la entrada y debería haber sido capturado, pero ahora Acabo de despojarlo?

¿Qué pasa con cosas como los números de teléfono (que tienen una gran variedad de formatos), códigos postales, códigos postales, números de tarjetas de crédito, nombres de usuario, correos electrónicos, URL (¿debería asumir http? ¿Qué pasa con .com mientras estoy en ¿eso?)?

¿Dónde trazar la línea?

Answer 1

Para algo tan importante como la banca, no me importa quejarse de mis comentarios, especialmente si la otra opción es transferir erróneamente una gran cantidad de dinero a la cuenta de un extraño en lugar de a la de mi esposa (debido a un dígito faltante o incorrecto por ejemplo).

Un ejemplo clásico es uno de mis bancos que no permite valores monetarios a menos que tengan ".99" al final (donde 9 puede ser cualquier dígito, por supuesto). La gran mayoría de las cosas que hago son por montos exactos en dólares y es un poco molesto tener que ingresar siempre 500.00 en vez de solo 500.

Pero estaré más feliz por eso la primera vez que evito pagarle accidentalmente a alguien $ 5072 en su lugar de $ 50.72 solo porque olvidé el punto decimal. En realidad, eso es bastante improbable ya que también pide confirmación y soy bastante anal en el control de mi dinero :-)

Habiendo dicho eso, la regla general que trato de seguir es "ser liberal en lo que aceptas, sé estricto" en lo que produces ".

Esto permite que otro software que use mi salida espere un rango limitado de posibilidades (haciendo sus vidas más fáciles). Pero hace que mi software sea más útil si puede manejar misteaks simples.

Answer 2

de entrada numérico:
decapantes no dígitos me parece razonable, pero el problema está en conflicto notación decimal. Algunas regiones esperan , (coma) para denotar el separador decimal, mientras que otras usan . (punto). A menos que la entrada sea en otras bases, solo asumiría la base 10. Si es razonable suponer una entrada no base 10 (base-16 para entrada de color, por ejemplo), iría con las convenciones estándar para denotar las bases: 0 a la izquierda significa base 8, 0x significa la base 16.

entrada de cadena:
Esto se pone mucho más complicado. En su mayoría depende de lo que la entrada realmente pretende representar. Un nombre de usuario debe excluir los caracteres que causarán problemas, pero el significado de "causar problemas" variará según el uso de la aplicación y el sistema en sí. Las URL tienen una definición concreta de lo que califica, pero esa definición es bastante amplia. Afortunadamente, muchos lenguajes vienen con herramientas para discernir URLs, sin tener que codificar su propio análisis sintáctico (si el lenguaje lo hace a la perfección o no, es otra cuestión).

Al final, es realmente caso por caso. Sin embargo, me gusta la regla general de paxadiablo: acepte todo lo que pueda y genere solo lo que debe.

Answer 3

Dibuja la línea en el punto donde la computadora está adivinando cuál debería ser la entrada correcta.

Por ejemplo, un cuadro de entrada de clave de licencia que escribí una vez acepta espacios y guiones, tanto en mayúscula como en minúscula, aunque internamente las teclas estaban sin dichos espacios, guiones y todas eran mayúsculas. Podría hacerlo, ya que sabía que ninguna de las teclas tenía espacios o guiones.

Su ejemplo sobre las URL es otro buen ejemplo. Me di cuenta de que los navegadores modernos (estoy usando Chrome), cuando se escribe algo como 'flores' en la barra de direcciones, sabe que debería buscarlo, ya que no es una URL válida. Si, en cambio, escribo 'st', corrige automáticamente (o sugiere automáticamente) 'stackoverflow.com' ya que es un marcador.

Un sistema de entrada bien escrito se quejará cuando, de lo contrario, se vería forzado a adivinar cuál debería ser la entrada correcta.

Answer 4

Depende totalmente de cómo se van a utilizar los datos.

Si la entrada es una cantidad monetaria, para una transacción, por ejemplo, la variable ingresada se debe normalizar a un conjunto de estándares con seguridad.

Si se trata simplemente de un número de teléfono, entonces es poco probable que los datos almacenados proporcionen un tipo funcional de uso para que pueda ser más indulgente.

No hay nada de malo en forzar el formato correcto para que el aspecto visualice mejor, pero debe equilibrar la irritación del usuario con los micro beneficios.

Una vez que comience a recopilar datos puede escanear a través de él y ver qué tipo de patrones surgen, y puede quitar automáticamente el formato ingresado.

Answer 5

Creo que estás reaccionando un poco. Si hay algo en el campo que no debería estar allí, quítelo. de lo contrario, intente forzar la entrada en el formato que desee, y si no le queda, rechace.

Answer 6

Yo diría "Aceptar cualquier cosa excepto procesar solo datos válidos".

Espere que sus usuarios se comporten como un novato en la computadora. Valide los datos de entrada usando expresiones regulares y otros validadores.

Busque expresiones regulares regulares para direcciones URL, correos electrónicos y otras cosas.

tiro en una exp regular como este "/ (?: ([A-zA-Z0-9] [\ s,] +)) ([a-zA-Z0-9] +) $/"para valores separados por coma o espacio. Con pequeños ajustes este exp funcionará para cualquier cantidad de valores separados por comas.

Answer 7

¿Dónde se traza la línea?

Cuando las consecuencias de aceptar los datos "no válido" superan la irritación de no aceptarla.

¿Deberían permitir las señales +/-?

Si los valores negativos son válidos, entonces por supuesto que deberían.

Si no, entonces no simplemente quite silenciosamente los signos menos, ya que cambia totalmente el significado de los datos. La eliminación de ventajas no es un problema.

¿Qué sucede si [los separadores de miles son] entre cada 4 dígitos en lugar de cada 3?

En los países que usan agrupación de tres dígitos, se puede suponer que "1,0000" es un error tipográfico. ¿Pero es un error tipográfico para "10,000" o para "1,000"? No me atrevería a adivinar, ya que una suposición incorrecta podría costar al usuario $ 9,000.

¿Qué hay de hexidecimal y octal representaciones?

A menos que esté ejecutando la función de búsqueda de unicode.org, no puedo imaginar por qué alguien usaría hexadecimal en formato web.

Y "" es casi seguro que la intención de ser 1.234 en lugar de 668.

¿Qué pasa con cosas como números de tarjetas de crédito ...

favor permiten espacios o guiones en el crédito números de tarjeta. Es realmente molesto cuando tengo que escribir un número no limitado de 16 dígitos.

Answer 8

Lo que me irrita como usuario son los números de tarjetas de crédito, convencionalmente aparecen como grupos de 4 dígitos con espacios que los separan, pero el formulario web impar solo aceptará una sola cadena de dígitos sin espacios y sin indicación de que esto sea el formato que está buscando. De forma similar, los números de teléfono, los humanos a menudo usan espacios para mejorar la claridad, los formularios web a veces aceptan los espacios y otras no.