it-swarm-es.com

¿Debería deshabilitarse el botón 'Continuar' si la validación está incompleta?

En los formularios, a menudo vemos el botón 'continuar' inactivo hasta que se completen todos los campos obligatorios:

mockup

descargar fuente bmml - Wireframes creados con Balsamiq Mockups

¿Es esto realmente una ayuda para el usuario o un obstáculo?

Me imagino que el Pro para esto es que es un indicador visual para el usuario de que no ha terminado de completar el formulario o tratar con errores (porque incluso con la validación en línea, un usuario no será informado si nunca ha interactuado realmente con un campo, por lo que no mostrará ningún error para aquellos en ese punto).

Pero la principal desventaja de esto (que también he visto en las pruebas de usabilidad) es que los usuarios se confundirán por qué no pueden hacer clic en el botón.

¿El patrón de deshabilitar el botón Continuar hasta que se complete la validación realmente proporciona una experiencia de usuario negativa?

99
JonW

Tipo de información capturada y número de campos requeridos

Realmente depende del tipo y el alcance de la información que está solicitando y la cantidad de campos que deben completarse:

He probado y utilizado este patrón con éxito en el inicio de sesión y la creación de contraseñas. Creo que debido a que la interfaz es muy simple y la cantidad de campos requeridos es limitada, no hubo ambigüedad con respecto a la información necesaria para activar el botón Continuar.

(En mi opinión), los usuarios generalmente se centran en la tarea, por lo que comenzar con la tarea es lo primero antes de finalizar cualquier tarea al comprometerse a la acción.

Como ejemplo, considere el caso de una página de creación de contraseña con requisitos de contraseña específicos (la situación para la que he diseñado). En este caso particular, he desactivado el botón Continuar hasta que se hayan cumplido todas las reglas para la contraseña, con la advertencia de que el usuario necesitaba obtener comentarios visuales mientras escribían su nueva contraseña y veían que su entrada cumplía con todos los requisitos de contraseña.

El sistema siempre debe mantener a los usuarios informados sobre lo que está sucediendo, mediante comentarios apropiados dentro de un tiempo razonable.

fuente: 10 heurísticas de usabilidad para el diseño de la interfaz de usuario

A continuación se muestra un excelente ejemplo de este enfoque que también incorpora la lógica de gamificación y puede probar la cosa real aquí junto con otras variaciones:

enter image description here


Prevención de errores

Como regla general, trato de evitar (cuando sea posible) mensajes de error que aumentan la frustración del usuario y erosionan su confianza. Entonces, en lugar de mostrar un mensaje de error manteniendo activo el botón Continuar, trataría de transmitir activamente sugerencias e información sobre los campos requeridos cuando y donde sea posible.

Incluso mejor que los buenos mensajes de error es un diseño cuidadoso que evita que ocurra un problema en primer lugar. Elimine las condiciones propensas a errores o verifíquelas y presente a los usuarios una opción de confirmación antes de comprometerse con la acción.

fuente: 10 heurísticas de usabilidad para el diseño de la interfaz de usuario


Validación en línea: proporcionar mensajes de error en contexto

A continuación se muestra otro gran ejemplo de un formulario simple con un botón deshabilitado, los campos se validan en línea y el botón deshabilitado se "sacude" para indicar que el formulario está incompleto. Además, con respecto a su punto:

Incluso con la validación en línea, un usuario no será informado si nunca ha interactuado realmente con un campo, por lo que no mostrará ningún error para aquellos en ese momento

Cualquier interacción con el formulario se traduce en progreso (marca) o (mensaje de error en línea). El único caso en el que esto no funcionará es cuando el usuario hace clic en "registrarse" sin proporcionar ninguna información que sea altamente improbable/comportamiento irracional y no tenga que atenderla.

enter image description here

Si se trata de formularios más largos y complejos, vale la pena hacer todo lo posible para estructurar su formulario fragmentando la información requerido en de manera significativa e introduciendo un proceso por etapas/asistente o patrón similar si es relevante. Esto ayudará a optimizar su diseño y mantenerlo enfocado en la prevención de errores.


Contenido de los mensajes de error

La otra área que debe considerar si está habilitado "Enviar" o "Botón Continuar" es:

Partido entre el sistema y el mundo real

Este podría ser un caso de Edge, pero vale la pena mencionarlo; considere un formulario de inicio de sesión típico con el botón de inicio de sesión habilitado y el usuario hace clic en el inicio de sesión sin proporcionar ningún detalle, ¿qué le diría el mensaje de error al usuario sin violar la seguridad del sistema: el mensaje más simple que he visto, lea lo siguiente: "Nombre de usuario o contraseña no válidos"

Este es un claro desajuste entre lo que el usuario ha hecho y lo que el sistema le responde. Entonces, en este caso específico, optaría por desactivar el botón de inicio de sesión hasta que se completen los campos obligatorios.


¿Cuándo podría usarse un botón deshabilitado?

El objetivo de un botón deshabilitado es evitar y evitar mensajes de error y pueden lograr esto de manera óptima cuando:

  1. El formulario tiene número limitado de campos y los usuarios pueden ver de un vistazo qué campos faltan.
  2. Hay énfasis visual en los campos obligatorios y comentarios claros cuando se llena cada campo (Objetivos que deben cumplirse para activar el botón)
  3. las etiquetas de campo son cortas y se pueden escanear fácilmente , por ejemplo, nombre, nombre de usuario, pueblo/ciudad, etc., lo que refuerza el primer punto.
  4. Todos los campos son obligatorios ya que ofrece una ruta clara para que los usuarios activen el botón y se comprometan a la acción *.

    * Me parece que cuando hay campos opcionales, los usuarios pueden malinterpretar lo que realmente se necesita para activar el botón, aunque no tengo pruebas para respaldar esto.


¿El botón deshabilitado es un obstáculo?

Es claramente no . Es un mano amiga que representa una vieja máxima "Prevenir es mejor que curar" pero viene con advertencias y requiere sopesar algunos de los factores que he mencionado anteriormente y probarlo con su público objetivo para asegurarse de que haga lo que se pretende hacer.


Diseñando para personas, no para máquinas

Los mensajes de error castigan a las personas por no comportarse como máquinas. Es hora de dejar que las personas se comporten como personas. Cuando surge un problema, deberíamos llamarlo error de máquina, no error humano: la máquina fue diseñada incorrectamente, exigiendo que cumplamos con sus requisitos particulares. Es hora de diseñar y construir máquinas que cumplan con nuestros requisitos. Deja de confrontarnos: colabora con nosotros.

Fuente: Don Norman: Designing For People

Supongo que lo que estoy tratando de decir es que los "usuarios" son personas como todos nosotros y que no debemos subestimar su inteligencia y tratarlos con condescendencia:

  • Ellos Leerán y entenderán etiquetas si son claro, legible y conciso
  • Ellos verificarán lo que se necesita de ellos si el formulario está bien estructurado y está en línea con lo que quieren lograr (centrado en la tarea)
74
Okavango

Debo decir que este comportamiento dificulta la experiencia del usuario.

Si alguna vez has leído Don't Make Me Think por Steve Krug , rápidamente te darás cuenta de que este patrón está rompiendo la regla establecida en el título.

Uno podría preguntarse, ¿por qué está deshabilitado?

No hay beneficio para hacer que un usuario salte a través de este aro.

Básicamente, lo que quiero decir es que el usuario es recibido con un formulario que no es apto para la acción y, mediante el descubrimiento, o peor aún, la lectura, tendrá que descubrir cómo usar correctamente el formulario que se le presenta.

Una solución alternativa para esto sería llamar la atención de inmediato sobre los campos obligatorios, pero eso los enviaría al pánico al preguntarse por qué fueron recibidos con un montón de errores rojos a pesar de que ni siquiera han tocado el formulario.

No impida que el usuario realice la tarea prevista de presionar el botón Enviar, se siente bien saber que el formulario le permite probar con una repercusión mínima. Un mensaje de error suave que dice "Revise los errores de formulario resaltados en rojo" será suficiente.


Otros pensamientos:

No estoy seguro de en qué sitios web o páginas está viendo esto con frecuencia, pero un vistazo rápido de los primeros 10 formularios del sitio web "Contáctenos" que se encuentran en Google parece argumentar en contra de su observación.

Mis dos centavos:

Si tuviera que adivinar, deshabilitar el botón Enviar se ha convertido en una característica predeterminada de un popular complemento de validación y los "desarrolladores" simplemente lo dejan como está.

23
MonkeyZeus

a menudo vemos el botón 'continuar' inactivo

Creo que esto puede ser falso. Sigue leyendo!

Por lo que vale, estoy actualizando algunas investigaciones antiguas sobre formularios de registro para sitios web populares en este momento, y he descubierto que un porcentaje bastante pequeño, alrededor del 5% o menos, deshabilita el botón Enviar (ya sea el final registrarse o un continuar botón de tipo) hasta que los datos se consideren "válidos".

Después de estudiar tantas formas, se convierte en un comportamiento notable en lugar de invisible comportamiento, cuando el botón enviar está deshabilitado. Es por eso que creo que puede sentir que lo ve más a menudo de lo que realmente lo ve.

También existe el problema adicional con los botones deshabilitados, que a menos que el formulario haga un trabajo notable al validar los datos sobre la marcha sin distraer al usuario al mismo tiempo, entonces evita que el usuario pueda ver qué está mal con el contenido.

Un sitio que hace esto aceptablemente es para una identificación de la BBC

enter image description here

Sin embargo, hacen excepcionalmente claro sobre la marcha lo que es válido y lo que no.

enter image description here

Otro ejemplo notable de un formulario de registro que deshabilita el botón es MailChimp, pero solo lo deshabilitan hasta la contraseña es aceptable, no todo el formulario, por lo que puede ingresar una contraseña y habilitar el botón, sin otros datos válidos en el formulario.

Claramente ven la contraseña como algo que tiene que ser correcto antes de que pueda considerar enviar el formulario. El resto de los datos se puede validar al enviar. Ellos no deshabilitan el botón de enviar para iniciar sesión.

El formulario de registro de Mailchimp es, en mi opinión, excepcionalmente bueno en muchos sentidos.

enter image description here

GoDaddy es un tercer ejemplo de un sitio que desactiva el botón de enviar. Sin embargo, aquí no deshabilitan el botón hasta que los datos sean todos válidos - los campos solo deben estar en blanco - entonces una letra en cada campo hará.

Aquí el botón deshabilitado está ayudando al usuario a detectar campos perdidos en lugar de inválido campos.

enter image description here

Entonces en resumen:

Si realmente desea deshabilitar el botón hasta que todos los datos sean realmente válidos entonces el formulario debe ser muy corto y - excepcionalmente bien validado sobre la marcha. Una forma larga no será muy clara en cuanto a lo que está mal, y el nivel de validación necesario sería una distracción excesiva para todos los campos.

Hacerlo te pondría en una pequeña minoría, especialmente para una validación completa, sea cual sea la sensación de que 'a menudo' lo ves :)

15
Roger Attrill

No se debe deshabilitar el botón

Considere la situación desde la perspectiva del usuario. Divida a los usuarios en dos grupos.

  • Aquellos que actualmente no creen que pueden continuar, por lo que no están buscando una manera de continuar
  • Aquellos que creen que están listos para proceder y están buscando una manera de hacerlo.

Para el primer grupo, deshabilitar el botón "continuar" es simplemente un artefacto visual visto en la esquina de la visión. Es útil, pero no más útil que cualquier otro gráfico que represente el estado del formulario. Para estas personas, un cambio gráfico (como una flecha que apunta al botón Continuar o un botón Continuar resaltado) es tan significativo como un botón que cambia de gris a negro.

Para el último grupo, creen que el formulario está completo. Un botón deshabilitado les permite saber que están equivocados, pero no les ayuda a identificar qué salió mal. Ahora deben escanear todo el formulario que piensan que se completó correctamente en busca de cualquier notación que se haya perdido, lo que indica una sección incompleta. Esto pierde la oportunidad de interactuar con el usuario. Esa interacción puede ayudarlos a encontrar las secciones del formulario que no están completamente llenas. Perder esta interacción convierte el formulario en un rompecabezas: "los administradores de web saben que hiciste algo mal, pero tienes que encontrarlo".

Dado que hay otras formas de manejar la sugerencia gráfica de que un formulario está completo (a mí me gustan los botones resaltados), y el botón Continuar proporciona una forma para que los usuarios soliciten ayuda, no veo ninguna razón para deshabilitar el botón.

12
Cort Ammon

Esta es una meta respuesta basada en las diversas opiniones expresadas.

Si desea deshabilitar el botón, aún debe verificar los clics y explicar por qué está deshabilitado. Esto tiene dos ventajas: se muestran menos errores, y si por alguna razón no comunicó previamente por qué no se puede enviar el formulario, puede hacerlo explícitamente.

5
hildred

Los botones están destinados a hacer clic. Si el usuario ve un botón, le gustaría hacer clic. El botón deshabilitado se activa solo cuando todos los datos se completan en ese formulario específico no es una buena experiencia. Prefiero decirle al usuario (lo que hago con los formularios que diseño) al principio que todos los campos son obligatorios y que no puede registrarse si alguno de estos campos se deja vacío. Tu formulario no es un juego en el que el usuario tiene que terminar el nivel que está jugando para desbloquear otro. Solo un pensamiento :)

4
Guru Munishwar

el botón " Continuar " debe deshabilitarse hasta que todos los campos obligatorios se completen en menos algún texto (esto supone que los campos obligatorios están designados como tales para el usuario de alguna manera). La ventaja aquí es que el sistema ni siquiera puede intentar continuar hasta que tenga la entrada requerida del usuario.

Una vez que se hayan completado los campos obligatorios, el botón " Continuar " debe habilitarse inmediatamente para indicar que el sistema tiene lo que necesita intento de continuar.

A partir de ahí, al hacer clic en el botón " Continuar " se ejecutará el validación completa y puede devolver mensajes de validación al usuario.

1
landonz

El botón 'Continuar' de un formulario debería estar deshabilitado hasta que todos los campos requerido se hayan completado y hayan pasado la validación.

¿Por qué? Bueno, es sentido común, realmente:

Imagina que eres un banco. Y tiene una configuración de formulario simple que permite la transferencia de dinero de una parte a otra. Tienes un '¿Desde qué cuenta te gustaría transferir dinero?' campo, un campo 'Destinatario' y un campo 'Cantidad a enviar'.

Si alguno de esos campos no se completa, la transferencia no puede llevarse a cabo. Por lo tanto, los tres campos son obligatorios. Sin la información de todos los campos obligatorios, no hay forma de que esta transferencia pueda llevarse a cabo.

Ahora, ¿qué sucede si hacemos obligatorios los tres campos e indicamos esto al usuario, y el usuario ingresa información en todos los campos obligatorios, pero comete un error en el campo 'Cantidad a enviar'?

Digamos que el usuario ingresó 0.00.

Bueno, no podemos enviar $ 0.00. Si el backend no está configurado correctamente para manejar casos como el envío de cero dólares, ¿qué podría pasar? Cuando el usuario hace clic en "Continuar", esto no solo hace que pierdas ancho de banda y tiempo, sino que también hace que tu usuario pierda ancho de banda y tiempo. Y en los negocios, el tiempo es igual a dinero, y si muchas personas cometen errores constantemente o no ingresan los detalles cuando deberían, efectivamente estarás creando demasiados gastos para ti (permitiendo que se utilicen demasiados recursos) y yo Apuesto a que esto eventualmente causará datos no coincidentes en algún momento.

Además, como usuario, no validar un formulario y permitirme continuar sin decirme que algo está mal es muy molesto. Especialmente cuando la página se actualiza y me obliga a completar todo por segunda vez.

1
Jase

Creo que hay un término medio. Un botón visualmente deshabilitado no tiene que significar que al hacer clic en él "no hace nada" como se sugiere. Lógicamente, evitará que el usuario avance en ausencia de lo que sea necesario para habilitar esa acción principal, pero no hay ninguna razón por la que al hacer clic no se pueda presentar un mensaje de alerta al usuario que explique por qué está deshabilitado y cómo habilitarlo.

1
Bryan

Mientras diseñaba algunas páginas web, vine a este sitio para ver lo que otros tenían que decir para tomar algunas decisiones. He concluido que la mejor respuesta es "depende".

Pensé en mis propias experiencias con los botones habilitados que no hacen más que decirme lo que hice mal y, a veces en una página web mal diseñada, ¡borrar todo! Especialmente me siento molesto cuando estoy en un formulario largo y el error está en la parte superior de la página ... que no veo hasta que hago clic en el botón Enviar varias veces y luego me desplazo hacia arriba para ver el problema. Además, no todos los sitios web dejan en claro lo que se requiere hasta que se hace clic en el botón Enviar. ¡No me atrapen en un mal día con un sitio web que me dice que tengo que ingresar algo!

Creo que las páginas web deben tener absolutamente claro lo que se requiere en un formulario ANTES de presionar un botón para que, si presiono el botón Enviar antes de ingresar a un campo requerido, estoy pensando, duh, no puedo creer que me haya perdido eso, lo sabía fue requerido! Por otro lado, tengo que estar de acuerdo con Jase en que, desde luego, ¡no quiero habilitar un botón Enviar en el sitio web de mi banco hasta que haya ingresado todos los campos obligatorios! Uso el sitio web de mi banco más que cualquier otro sitio y el botón deshabilitado nunca me ha causado confusión.

Entonces, mi conclusión? Si tiene un formulario extenso con múltiples campos, algunos son obligatorios, otros son opcionales, marque claramente todos los campos obligatorios, active el botón Enviar y, cuando el formulario se envíe con datos requeridos no válidos o faltantes, resalte los campos problemáticos y enumere los mensajes con los errores Si tiene un formulario donde todos los campos aparecen en la misma página ... junto con el botón Enviar, desactive el botón e indique claramente lo que el usuario debe hacer para habilitar el botón. El botón Enviar también se puede habilitar; sin embargo, de cualquier manera debería funcionar bien y proporcionar una buena experiencia de usuario ... aquí radica la belleza del diseño web ... ¡depende de usted! Finalmente, sepa qué forma es más difícil de codificar, ya que esto también puede ayudarlo a tomar una decisión de una forma u otra cuando parezca estar bien ... mantener los costos bajos para el cliente siempre debe ser una consideración.

Ah ... ¿y con qué frecuencia el usuario típico "deshabilita" su HTML? Creo que eso no es común y el usuario promedio (que no es de TI) ni siquiera sabe cómo hacerlo, así que no creo que sea una razón suficiente para tenerlo en cuenta al diseñar un sitio web fácil de usar. ¡Si el usuario es lo suficientemente inteligente como para deshabilitar su HTML, entonces debe saber que debe habilitarlo para que el sitio web sea completamente funcional! ¡Feliz diseño! :)

1
My Two Cents

Lo mantendré breve y al punto, ya que la mayoría de las respuestas ya cubren muchas áreas válidas y buenas.

¿Agrega valor?

No puedo pensar en un caso en el que el usuario deba/deba mirar el botón Continuar para saber si ha terminado de completar un formulario. Cada vez que un usuario desea hacer clic en el botón él cree ha terminado el formulario y es necesario dirigirlo a las acciones requeridas en este momento. En principio, esto ya debería estar claro en una forma bien diseñada, pero el hecho de que el usuario creía que había terminado prueba que este no era el caso, Por lo tanto, enfocar, parpadear temporalmente o de alguna otra manera dirigir al usuario es un buen plan de acción.

¿Qué pasa con la validación que no es sincrónica?

Una cosa que aún no se ha cubierto es que muchos formularios son formularios web o dependen de Internet y no toda la validación puede ser instantánea. Para dar un ejemplo típico de un formulario de registro con un nombre de usuario: el nombre de usuario debe buscarse en la base de datos y si el nombre de usuario ya está en uso, el campo requerirá que se ingrese un nombre de usuario diferente. Normalmente, esta es una búsqueda extremadamente rápida, pero ¿qué sucede si el usuario está, por ejemplo, usando Internet móvil y acaba de perder su conexión o tiene una conexión increíblemente lenta? Con un botón de continuar deshabilitado, el usuario terminará con un formulario completado y ningún botón para hacer clic, lo cual es comparativamente más confuso que hacer clic en un botón y esperar a que se cargue la siguiente página que se utilizará en una conexión a Internet deficiente. tomar un poco más tiempo.

Por supuesto, lo anterior se puede evitar de alguna manera si los campos que están en espera de validación muestran esto muy claramente, pero generalmente no se hace y si todos los campos están activados lado del servidor, ya que cada vez es más común, esto podría confundir al usuario: "¿Por qué hay un cosquilleo al lado de mi nombre completo?". Por lo tanto, si desea hacer esto, la única solución que pude pensar fue poner una ruleta en el botón de envío deshabilitado mientras se ejecuta la validación. El único peligro de eso es que el usuario podría pensar que ya envió el formulario por error, ya que un botón deshabilitado a menudo se asocia con un estado presionado/presionado.

1
David Mulder

Creo que es malo deshabilitarlo cuando se trata de la validación de restricciones de formulario HTML nativo. Elimina toda la usabilidad de la validación fuera de forma, dejándolo solo con la validación.

Tome este sencillo formulario, por ejemplo, cuando complete algo en el campo a y presione Entrar, no sucede nada. No obtienes ningún comentario visible. No sabes lo que se requiere simplemente mirando la interfaz de usuario visual.

<form>
  <input type="text" name="a" required>
  <input type="text" name="b" required>
  <input type="submit" disabled>
</form>

Donde como si tuvieras el botón habilitado

<form>
  <input type="text" name="a" required value="sometext">
  <input type="text" name="b" required>
  <input type="submit">
</form>

Ahora, si presiona enter después de haber ingresado algo en el campo a, aparece una ventana emergente y el campo de entrada también se enfoca

enter image description here


Tener una validación de formulario perfectamente estructurada sin deshabilitar el botón continuar

  • No necesitarías ningún javascript
  • La página no se volvería a cargar (ahorrando así ancho de banda)
  • Obtiene una buena retroalimentación detallada en su propio idioma sobre lo que está mal (se le agregan números con paso, mín. Máx., Obtiene algo como: "ingrese un número válido, los dos números válidos más cercanos son x, y")
  • El campo lleno erróneamente también se enfoca
  • No confunde a un usuario en cuanto a por qué no puede hacer clic en él, de hecho, es todo lo contrario, ahora sabe lo que está mal en el formulario
0
Endless