¿Qué es una mejor experiencia de usuario: resaltar errores o bloquear las pulsaciones de teclas incorrectas?
Tengo información para ingresar en un cuadro de texto. Los datos están estructurados y solo algunas secuencias son válidas. Para un número de teléfono, por ejemplo, una letra como A no es válida.
Entonces, ¿debo interceptar los eventos del teclado y evitar que las letras escritas lleguen al cuadro de texto, o debo dibujar algunas líneas onduladas rojas (u otra señal visual) para que mi usuario sepa que la letra no es aceptable? ¿Cuál es una mejor experiencia de usuario?
Anular el control de un usuario sobre su computadora siempre será una interrupción, y a menudo se percibirá como una invasión, del flujo de trabajo de ese usuario. El sitio web "no debe" tener el control de nuestras computadoras, por lo que ejercer dicho control será al menos un poco alarmante.
Dicho esto, aborda un tema realmente importante, que es la importancia de informar a un usuario que su entrada no es válida antes de que complete un conjunto completo de campos y los envíe.
El enfoque que he encontrado que es el menos intrusivo pero que proporciona la respuesta de respuesta más rápida es el siguiente flujo.
Esencialmente, espere a que completen su primer campo, luego, cuando hacen clic/tabulan alrededor de un nuevo campo (o un campo que ha sido invalidado), verifique el campo que se acaba de completar. Si el campo que se acaba de completar es válido, imprima un ícono discreto "bueno" al lado (verde, marca de verificación, cara feliz, se entiende la idea). Si falla las reglas de validación, imprima discretamente un ícono "incorrecto" (rojo, "X", etc.) y una línea corta sobre lo que falló.
Pero recuerde, no interrumpa su flujo de trabajo:
- No hay ventanas emergentes
- sin superposiciones
Cuando terminen con el campo al que se mudaron, volverán al campo no válido o continuarán y volverán más tarde. De cualquier manera, verán que tienen que hacer una edición, pero pueden hacerlo en su propio tiempo.
Al final, tendrán un formulario completamente válido antes de enviarlo, lo que significa
- Solo tendrán que enviar una vez
- No pasan el tiempo enojándose o frustrados cuando su sumisión "falla"
- Les gustará más tu sitio
- Todos tendrán pastel
Al estar en ambos extremos del uso de un formulario, aquí hay algunas pautas que prefiero:
- Las entradas del usuario casi nunca deben prevenirse Es decir, si escribo la letra 'A' en un campo de número de teléfono, esperaría ver esa 'A'.
- Comienzo mi validación de campo de texto en un evento
onBlur(), y no antes de eso. Esto le da al usuario la oportunidad de corregir esa 'A' mal escrita antes de mostrar un mensaje de error. Permitir que el usuario corrija un error mientras aún está en el campo de entrada proporciona una oportunidad menos para un tipo de mensaje molesto de "oye, te equivocaste, amigo".
Si evita caracteres no válidos mientras escriben, podrían pensar que su teclado no funciona correctamente. A los usuarios les gusta que las cosas funcionen de la manera que esperan. Si va a evitar ciertos caracteres al presionar una tecla, al menos también debe mostrar un mensaje de error cerca de la entrada al mismo tiempo. De esta manera, saben por qué no está escribiendo.
Otra cosa que puede ser molesta es cuando acaba de completar un formulario largo y el sitio utiliza la validación del lado del servidor, por lo que debe volver a través del formulario para encontrar qué está mal. Me gusta usar la validación del lado del cliente principalmente, pero recurro al lado del servidor. Mostraré un error ya sea mientras están escribiendo o cuando la entrada pierde el foco. De esa manera, el usuario sabe de inmediato que hay un problema y sabe exactamente cuál es el problema.
Encuentro que evitar que los usuarios cometan errores siempre es 10 veces más difícil de lo que pensaba originalmente. Ejemplo: el número de teléfono de alguien puede tener una extensión, como x2333. He usado el jQuery input mask plugin para tarjetas de crédito y funcionó bien. Utilizo la sugerencia automática siempre que sea posible.
En cualquier sistema complejo, tendrá circunstancias que son costosas de detectar en línea y debe informarlas después del hecho. Para mí, la respuesta es caso por caso y asegúrese de cubrir todos los casos de Edge.
Sugeriría un híbrido de ambos enfoques, pero solo para campos estrictamente validados como números de teléfono (SSN, códigos postales, etc ... cualquier cosa que debe ser numérica por definición).
Realice un seguimiento de cada pulsación de tecla y, cuando el usuario escriba un carácter no válido, muéstrelo ... pero inmediatamente señale que algo está mal. Tal vez cambie el campo de entrada a rojo y muestre "Ingrese solo caracteres numéricos" a la derecha del campo.
El bloqueo de entrada es un no-no porque puede ser malinterpretado por el usuario. Pueden suponer un problema con su máquina o dispositivo de entrada, no es que no se suponía que escribieran una letra en un cuadro de entrada numérico.
Validar después de que se complete la entrada puede ser molesto. Particularmente con campos como los utilizados en la creación de contraseñas. Algunos sitios requieren contraseñas de 6 caracteres con solo caracteres alfanuméricos. Otros requieren contraseñas de 9 caracteres y permiten cualquier carácter (incluido! @ # $% Y tal). Escribiendo una contraseña y solo descubriendo después de que he escrito es el tipo de formulario más molesto que he encontrado y en realidad me ha alejado de varios servicios .
Proporcionar retroalimentación dinámica a medida que el usuario ingresa datos los ayuda
- Sepa qué campo tuvo el error mientras todavía están en el campo
- Corrija los errores de entrada de forma proactiva antes de enviar datos
- Aprende de la experiencia a medida que avanza
El bloqueo de entrada falla en las 3 cuentas. Destacar los errores de validación después de que el cuadro de texto está lleno también falla en los 3.
Depende del caso. Si es posible, utilice la sugerencia automática. Si intercepta la entrada del usuario, una retroalimentación inmediata es crucial. Una de las posibles soluciones es el "cuadro de pista" que aparece inmediatamente después de que se intercepta la clave. Puede verlo en la pantalla de inicio de sesión de Windows, aparece si presiona $ sign, por ejemplo.
Como con la mayoría de las cosas ... depende del contexto. Tengo una opinión más especializada sobre el tema. La mayoría de las aplicaciones en las que yo o mi grupo trabajamos son de naturaleza técnica y solo son utilizadas por personas razonablemente capacitadas. Como tal, podemos poner más responsabilidad y libertad en manos de los usuarios de lo que podría con el público en general. Brevemente, algunas de las pautas que utilizamos ...
- Haga caso omiso de cualquier entrada no válida ... bloquee las pulsaciones de teclas no válidas.
- Indique campos no válidos, un estado que debería ser casi imposible, por contraste y color *.
- El foco siempre está bajo control del usuario. No atrape al usuario ni evite un cambio de enfoque.
- Nunca arroje un cuadro de advertencia/error modal. Siempre.
- Nunca haga preguntas al usuario. El software es una herramienta, no una persona. Sí, estoy seguro.
- Las teclas Enter/Return siempre significan: Aceptar cambios y seguir adelante. No cambie esto usando el foco en un botón cancelar/salir como predeterminado en Enter.
- La tecla Escape siempre significa: descartar y salir.
- Proporcionar autocompletado siempre que sea posible.
- Proporcione una entrada de acceso directo para los números que tienen un límite mínimo/máximo. p.ej. Si un valor válido está entre 0.12 y 100.387, las entradas mayores que 100.387, como 999, se toman como 100.387, etc.
- Establezca reglas de comportamiento muy claras en blanco y negro ... reglas que el usuario pueda entender. Si esto se vuelve demasiado complejo ... vuelva a pensarlo.
Casi todos los ejemplos son solicitados por el usuario y, sí ... la implementación es a veces un verdadero oso/pesadilla/asesino pero rara vez imposible.
Advertencia: na vez más, estos ejemplos se dan en el contexto de un sistema vertical con una base técnica de usuarios ... no un formulario público general web, etc. Su millaje puede variar.
* Excepto rojo. En nuestro negocio, rojo significa: peligro de que te maten ... o algo peor.