¿Qué evento desencadenará la validación de campo y el formato de formulario de Javascript?

Question

Déjame decir primero, validamos todos los campos en el lado del servidor, por lo que esta es una pregunta sobre la usabilidad del lado del cliente.

¿Cuál es la sabiduría convencional en exactamente cuando para validar y formatear campos de entrada de formulario html mediante javascript?

Como ejemplo, tenemos un campo de número de teléfono. Permitimos números, espacios, paréntesis y guiones. Queremos que el campo tenga diez dígitos. Además, queremos que el campo se vea como (123) 456-7890, incluso si el usuario no lo escribe de esa manera.

Parece que podamos

• Validar y formato cuando el usuario sale del campo .
• Valida y formatea en cada carácter ingresado.
• Interceptar las teclas y evitar que el usuario ingrese caracteres que son incorrectos.
• Algunos combinación de los anteriores (por ejemplo formato a la entrada y en la salida validar, prevenir la entrada y el formato de salida, etc.)
• [Agregado] Esperar y hacer todo el validación y formato cuando el usuario hace clic enviar.

que he visto hacer todas estas formas, pero no puedo encontrar información acerca de lo que es mejor (o incluso generalmente aceptada) desde una perspectiva de usabilidad, y lo más importante, por qué.

[Editar : Algunas aclaraciones]

Estamos absolutamente no hacer cumplir todas las normas de formato. Cuando digo formato, quiero decir que usaremos javascript para reescribir las cosas para que se vean bien. Si el usuario escribe 1234567890, lo cambiaremos a (123) 456-7890. No hay "reglas de formato" que puedan fallar.

Distingo esto de la validación porque si no escriben suficientes números, tenemos que hacer que lo arreglen.

Creo que debería reformular la pregunta "¿cuál es la sabiduría convencional sobre exactamente cuándo va a validar y exactamente cuándo va a formatear ...?

buena información en las respuestas hasta el momento!

EDITAR: Estoy aceptando mi propia respuesta a continuación con la esperanza de que otros encuentren el enlace tan útil como yo.

Answer 1

De lejos, la mejor respuesta hasta ahora no fue una respuesta, sino un comentario (ver arriba). Lo estoy agregando como respuesta en caso de que alguien lo omita en el comentario.

Consulte el siguiente artículo en A List Apart.

Inline Validation in Web Forms by Luke Wroblewski

Answer 2

Encuentro que las tres primeras opciones son realmente molestas. No hay nada peor que ser interrumpido en el medio de escribiendo algo.

El objetivo principal de su usuario es obtener el formulario lo más rápido posible y todo lo que haga que los desacelere es solo una razón más para que renuncien por completo.

También odio ser forzado a escribir algo así como un número de tarjeta de crédito o el número de teléfono es exactamente el formato correcto para satisfacer el formulario.Siempre que sea posible, solo déle al usuario una caja para escribir cosas y no haga que se ocupen del formato.

En el caso de su número de teléfono, déjelos ingresar como lo deseen, elimine cualquier cosa que no le guste, intente volver a juntarlo en el formato que desee ((124) 567-8901) y arroje un error si no puedes.

Si absolutamente debe validar algo en un formato específico, hágalo cuando envíen el formulario y luego resalte los campos que tienen problemas.

Answer 3

Depende del campo. Pero para algo como un número de teléfono, generalmente es muy bueno evitar que alguien ingrese dígitos que no sean dígitos.

De esta manera, al escribir verá que su número de teléfono 1-800-HELLOWORLD no se muestra correctamente y se da cuenta de que el campo solo acepta números (que también puede resaltar con algún tipo de campo de información junto con el campo de entrada).

Esto me parece mucho más intuitivo y amigable que un cuadro de diálogo modal torpe, un campo de error emergente o un mensaje generado por el servidor que muestra después de que ha terminado de completarlo.

Por supuesto, siempre balancee la validación final del lado del cliente con los requisitos técnicos finales para construirla. Si comienzas por el camino de, digamos, la validación de cargas de imágenes con Ajax antes de que la página se envíe, ese puede ser un camino bastante largo.

Editar: también, tenga en cuenta su público. Los que tienen una mayor mentalidad técnica aceptarán formas "dinámicas" más que, por ejemplo, las personas que están más acostumbradas al enfoque no Ajax de Internet.

Answer 4

Iba a describir varias opciones, pero podría ser beneficioso utilizar un marco js existente para manejar las máscaras de entrada. Here is a good run down of various options

Answer 5

Personalmente creo que formatear y validar al salir es lo menos molesto para el usuario. Permita que ingresen el número en el formato que deseen (y hay muchos para un número de teléfono) y luego cámbielo al formato que desee. No fuerce al usuario a cumplir con sus preferencias cuando puede manejar los datos en su formato preferido.

Además, los mensajes de validación cuando no termino de escribir son molestos, y no poder poner un cierto carácter en un campo de texto es muy molesto.

La única excepción en la que puedo pensar es en las situaciones de "es este valor disponible" (como la creación de un nombre de usuario único); en ese caso, la retroalimentación inmediata es realmente conveniente.

Answer 6

La manera más fácil de usar que he visto para hacer la validación es tener un indicador que aparece junto al campo de entrada para indicar que el valor no es válido. De esta forma, no interrumpe al usuario mientras está escribiendo y, sin embargo, puede ver continuamente si ha escrito una entrada válida o no. Odio tener que escribir la información en una forma larga solo para que la cosa me diga al final "Oh, necesitas regresar y arreglar el campo 1".

Puede hacer que el indicador se muestre/oculte a medida que el usuario escribe. Uso un ícono de advertencia cuando el valor no es válido y configuro una información sobre herramientas en el ícono que explica por qué el valor no es válido.

Si tiene la pantalla de bienes inmuebles, puede simplemente poner texto como "Válido" o "Debe estar en formato XXX-YYY-XXXX".

Tenga en cuenta que cuando lo hace por validación de pulsación de tecla también necesita capturar el texto pegado.

Además de esto, también debe evitar ingresar las teclas no válidas en primer lugar.

Answer 7

Validar y formatear cuando el usuario sale del campo.

Sí. Proporcione comentarios no invasivos al usuario si las reglas de validación o formato fallan. Por no-intencional me refiero a que no aparece un cuadro de diálogo de alerta o modal, lo que obliga al usuario a hacer clic en algo. En lugar de mostrar dinámicamente un mensaje adyacente o debajo del campo donde falló la validación o el formateo.

Validar y formatear en cada carácter ingresado.

No. Creo que eso dificulta la usabilidad. En su lugar, proporcione al usuario una información sobre herramientas u otra sugerencia sobre cuáles son las reglas de formato o las reglas de validación. P.ej. para un campo "requerido", el asterisco prácticamente ubicuo, y para los campos con formato, indique al usuario por adelantado cuál es el formato esperado.

Interceptar las teclas y evitar que el usuario ingrese caracteres que son incorrectos.

Si va a evitar que el usuario ingrese caracteres no válidos, dígale al usuario por qué acaba de bloquear su entrada, de forma no invasiva. Además, no robe el foco del campo.

Así que para mí los principios generales son:

1. informar al usuario por adelantado acerca de las reglas de validación y de formato.
2. No asuma que el usuario es visto, así que tenga en cuenta la accesibilidad web y los lectores de pantalla. (A menos que esté desarrollando un sitio web que tenga un público objetivo limitado, como una Intranet.)
3. Proporcione al usuario comentarios no invasivos, es decir, no haga que el usuario haga clic en un cuadro de alerta o cuadro de diálogo modal sobre cada falla.
4. Haga que sea obvio qué cuadro de entrada no aprobó las reglas de validación o formato, y diga al usuario por qué falló su entrada.
5. No robe el puntero del mouse/puntero cuando proporcione comentarios.
6. Tenga en cuenta el orden de las pestañas, de modo que cuando los usuarios orientados al teclado completen un campo, puedan presionar la pestaña y acceder al siguiente campo de entrada/selección lógica.

Answer 8

bmb indica que aceptan cualquier formato y lo cambian al formato deseado (xxx) nnn-xxxx. Eso es muy bueno. La pregunta es el momento de A) el cambio de formato, y B) la validación.

A) El cambio de formato se debe realizar a medida que el usuario sale del campo. Más pronto es molesto y luego derrota el propósito de mostrar el cambio.

B) La validación se lleva a cabo de manera más apropiada al salir del campo o al enviar el formulario. Más pronto es frustrante y confuso para el usuario. En una forma larga y compleja, con más de una pantalla, preferiría hacer una validación al salir del control para facilitar las correcciones.En una forma corta, lo haría al presentarlo para evitar romper el flujo de llenar el formulario. Es realmente una decisión, así que pruébela con usuarios reales si es posible.

Preferiblemente, está probando su trabajo con usuarios reales de todos modos, pero si no tiene presupuesto o acceso para eso, una prueba rápida y sucia de "usuario" puede ayudar con decisiones como esta. Puede agarrar a un puñado de personas que no funcionó en el software (lo más parecido posible a sus usuarios finales) y pedirles que completen el formulario. Indíqueles que ingresen cosas específicamente para obtener un error y luego ver cómo lo corrigen. Pídales que hablen en voz alta sobre lo que están haciendo para no tener que adivinar su proceso de pensamiento. Busque dónde tienen problemas y lo que parece confundirlos/molestarlos más.

Answer 9

Para mejores prácticas de usabilidad, sugiero leer How To Design The Perfect Form (más precisamente Context & Assistance) y Beautiful Forms.

Para un marco de validación de formularios, consulte el combo fValidator y iMask, son complementarios y, por lo tanto, funcionan perfectamente juntos.