Captchas para forzar la interacción del usuario?

https://stackoverflow.com/questions/458443

19-08-2019
|

Pregunta

Actualmente estoy trabajando en un programa que tiene muchos de esos & "; el usuario DEBE leerlo pero hará clic en Aceptar como un estúpido mono &"; diálogos ... Entonces estaba pensando en agregar algo como un captcha para evitar hacer clic sin pensar ...

Mis ideas fueron:

Cambiar botones al azar
Coloque botones al azar en algún lugar del formulario
El usuario debe hacer clic en una palabra de color aleatorio dentro del texto que debe leer
agregar captcha
agregar captcha que incluye el mensaje para el usuario

¿Alguien ha hecho alguna experiencia con tal situación? ¿Qué sugerirías hacer?

Solución

Bueno, pediste opiniones y aquí va la mía, pero no creo que esto sea lo que te gustaría escuchar ...

A los usuarios les gustan los programas en los que pueden confiar. No les gusta cuando las cosas cambian y no les gusta hacer trabajo extra.

Cambiar botones al azar y colocar botones al azar en algún lugar del formulario solo hará que presionen el botón incorrecto o se molesten con su aplicación, porque como usted dice, no leen el texto, y si lo piensa, nosotros tampoco. Como ejemplo, piense en un cuadro de diálogo Aceptar / Cancelar, siempre espera que el botón Aceptar esté a la izquierda, y la mayoría de las veces lo presiono sin leerlo. Sucederá exactamente lo mismo con sus usuarios.

El usuario debe hacer clic en una palabra de color aleatorio dentro del texto que debe leer
agregar captcha
agregar captcha que incluye el mensaje para el usuario

Con estas 3 opciones agregará trabajo extra a su aplicación, sus usuarios lo maldecirán por eso. Solo piense en algo que tendría que hacer 10 veces al día, digamos que verifique su código para obtener una fuente segura. ¿Cómo te sentirías si tu jefe te dijera que a partir de ahora tendrás que llenar un captcha por cada archivo que intentes registrar?

Creo que nuestro trabajo es facilitar la vida de las personas que usan nuestro software. Si deben leer algún tipo de texto y no quieren, no hay absolutamente ninguna manera de que puedan hacerlo.

No puedes & # 180; t hacer que las personas trabajen bien, todo lo que puedes hacer es proporcionarles las mejores herramientas posibles y esperar que sean lo suficientemente profesionales como para hacer su trabajo.

Entonces, básicamente, todo lo que digo es: haz tu mejor esfuerzo para facilitar su trabajo. Si esto es realmente importante, usted (o quien esté a cargo) debe hablar con ellos y EXPLICAR POR QUÉ esto es importante.

Te sorprendería cómo las personas se comprometen con las cosas que entienden.

Otros consejos

Sugiero que no lo hagas; y que, a menos que sepa mejor, emula interfaces de usuario respetables, bien probadas y conocidas como < gran minorista en línea > o < sitio de banca en línea > ;.

Jugar juegos con el usuario para que lean los mensajes está condenado. Los usuarios centrarán los recursos mentales en completar tu juego, en lugar de entender el mensaje. Es probable que sus usuarios menos entiendan realmente la parte importante del mensaje si tiene cosas como botones movidos, reetiquetado, búsquedas del tesoro, captchas o retrasos. Ellos & # 8217; se centrarán en las instrucciones para el juego, no en el problema real. Es probable que los errores aumenten.

Usuarios & # 8217; la negativa a leer los cuadros de mensaje se debe a que los usuarios desean hacer las cosas rápidamente en lugar de tomarse el tiempo para leer cosas, y también se debe a que los cuadros de mensajes se usan en exceso y se usan mal en tantas aplicaciones. La inclusión de juegos tontos en los cuadros de mensaje solo hará que los usuarios se resentgan aún más, agravando el problema.

Aquí & # 8217; s lo que puede hacer:

Regla 1. No & # 8217; t use cuadros de mensajes. Solo deberían aparecer en circunstancias excepcionales. Una aplicación no debe tener & # 8220; muchos & # 8221; cuadros de mensaje. No debería ser necesario leer una gran cantidad de documentación cada vez que el usuario usa una aplicación. Si el uso normal de su aplicación da como resultado un cuadro de mensaje, entonces su IU es incorrecta. Encuentra otra forma.

En lugar de mensajes de verificación, muestre claramente en la ventana principal lo que sucedió y proporcione una forma clara de deshacerlo.
Utilice la corrección automática, los campos ilustrados / enmascarados y la desactivación en lugar de los mensajes de error.
Use buenos valores predeterminados y automatización para evitar mensajes. Por ejemplo, en lugar de mostrar un mensaje de error que dice que el usuario no puede & # 8217; t cargar porque & # 8217; no está conectado al servidor, simplemente vuelva a conectarse automáticamente.
Rompe comandos a lo largo de las opciones. En lugar de un cuadro de mensaje para preguntar si el usuario desea pegar con o sin formato, proporcione dos comandos diferentes en el menú.
No & # 8217; t aparecen mensajes informativos que le muestran al usuario que todo funcionó bien (p. ej., & # 8220; ¡Preferencias guardadas! & # 8221;)
Don & # 8217; t tiene ventanas emergentes que proporcionan sugerencias útiles o documentación. Proporcione un tutorial o ayuda con globos si puede & # 8217; t hacer que su UI se auto documente.
Don & # 8217; t tiene regaños & # 8220; actualízame & # 8221; mensajes.
Considere proporcionar texto de mensaje en la ventana principal en lugar de en un cuadro de mensaje separado (por ejemplo, & # 8220; la página puede no verse o actuar correctamente porque ActiveX está desactivado por seguridad. & # 8221; ) Las ventanas emergentes de la navegación web han condicionado a los usuarios a descartar automáticamente todo lo que aparezca como irrelevante.

Regla 2. Si tiene para usar un mensaje:

Haga que el texto sea lo más breve posible para transmitir la información clave. Más texto no es equivalente a más útil. Utilice & # 8220; No coincide con [máscara de archivo] en [ruta]. & # 8221; Don & # 8217; t use & # 8220; Error no fatal 307: acción de búsqueda anulada. [Appname] no puede completar su búsqueda de cadenas para la expresión regular que proporcionó porque la máscara de archivo que proporcionó, concretamente [filemask], no da como resultado ningún archivo coincidente en el directorio que especificó (que era [ruta]). Verifique su máscara de archivo o la selección de ruta y vuelva a ingresarla en el cuadro de diálogo Archivos para buscar. Haga clic en el botón Aceptar a continuación en este cuadro de mensaje para volver al cuadro de diálogo Archivos para buscar. Haga clic en el botón Cancelar en el cuadro de diálogo Buscar archivos cuando llegue allí para cancelar su búsqueda de cadenas. & # 8221; Si hay algunos usuarios que necesitarán más explicación de la que se puede lograr en un breve mensaje, proporcione un botón de Ayuda o un & # 8220; ¿Cómo puedo & # 8230; & # 8221; enlace en el cuadro de mensaje.
Use lenguaje simple y sin jerga en el mensaje. Eso incluye & # 8220; inocente & # 8221; palabras como & # 8220; diálogo, & # 8221; & # 8220; base de datos, & # 8221; y & # 8220; tóner. & # 8221; No tome texto de excepción sin procesary tíralo en un mensaje de error. No incluya ningún número de error o volcados; registrar estos en su lugar. Purgue su aplicación de cualquier cuadro de mensaje de depuración dejado por los desarrolladores. Es mejor simplemente dejar que la aplicación desaparezca en un error fatal que poner un mensaje lleno de jerga y luego la aplicación desaparece.
Etiquete los botones de un cuadro de mensaje con lo que hace la acción, no & # 8220; OK. & # 8221; Como mínimo, los usuarios deben centrarse en el botón de activación para descartar un cuadro de mensaje. Si ese botón está etiquetado como & # 8220; Eliminar & # 8221; o & # 8220; Instalar, & # 8221; debería darles una pausa. Nunca debería tener que explicar en el mensaje de texto lo que hace cada botón. Por cierto, dicho etiquetado es un estándar GUI en la mayoría de las plataformas.

Rediseñe su aplicación para que no use cuadros de mensaje.

Podrías probar con un temporizador que espera el " supuesto tiempo de lectura " antes de habilitar el botón de enviar. Incluso puede calcular el tiempo de lectura supuesto a partir del número de palabras.

Creo que las formas sutiles de obligar al usuario a leer su texto (como moverse por los botones o pedirles que lean un captcha) pueden hacer que se sientan como monos estúpidos.

Mi sugerencia, conviva con ella o rediseñe sus cuadros de diálogo / interfaz. no agregue aleatoriedad a los diálogos o trate al usuario como un idiota, aunque piense que la mayoría son :-).

Hace poco leí un artículo de Joel on Software, Diseñando para personas que tienen cosas mejores Que ver con sus vidas . Señala que la mayoría de las personas no leerán nada y discute formas de evitarlo o, al menos, no empeorarlo.

Podría usar una pregunta de elección basada en lo que el usuario debería leer.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow