¿Cómo manejaría a los usuarios que no leen los cuadros de diálogo?[cerrado]
https://stackoverflow.com/questions/125269
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Un artículo reciente sobre Ars Técnica analiza un estudio reciente realizado por el Departamento de Psicología de la Universidad Estatal de Carolina del Norte, que mostró que los usuarios tienen una tendencia a hacer lo que sea necesario para deshacerse de un cuadro de diálogo y volver a su tarea en cuestión.La mayoría de ellos haría clic en Aceptar o Sí, minimizaría el cuadro de diálogo o cerraría el cuadro de diálogo, independientemente del mensaje que se mostrara.Algunos de los cuadros de diálogo que se mostraban eran reales y otros eran falsos (como esas ventanas emergentes que muestran las páginas web que se hacen pasar por una advertencia de antivirus).Los tiempos de respuesta indicarían que esos usuarios realmente no están leyendo esos cuadros de diálogo.
Entonces, sabiendo esto, ¿cómo afectaría esto a su diseño y qué intentaría hacer al respecto (si es que hay algo)?
Solución
Intento diseñar aplicaciones para que sean robustas ante los accidentes, ya sean deslices (operaciones inadvertidas, como hacer clic en el lugar equivocado) o errores (errores cognitivos, como hacer clic en Aceptar o en hacer clic en Aceptar).Cancelar en un diálogo).Algunas formas de hacer esto son:
- Deshacer/rehacer infinito (o al menos de varios pasos)
- integrar la documentación con la interfaz, a través de información sobre herramientas dinámica y otros medios de comunicación sensibles al contexto (un documento que es particularmente relevante es sobre 'Sorpresa, explicación, recompensa' (enlace directo: SER) -- usar respuestas psicológicas típicas ante comportamientos inesperados para informar a los usuarios)
- Incorporar el estado del sistema en dicha documentación (utilizar los datos del usuario actual como ejemplos, y concretar la documentación utilizando datos que puedan ver ahora mismo)
- Esperar error de usuario.Si existe la posibilidad de que alguien intente escribir en:\ cuando no hay un disco en su lugar, implemente un tiempo de espera para que el sistema pueda fallar sin problemas y solicite otra ubicación.Guarde los datos en la memoria hasta que estén seguros en el disco, etc.
Esto se reduce a dos cosas fundamentales:(1) Programe de manera defensiva y (2) Mantenga al usuario lo más informado posible.Si la interfaz del sistema es fácil de usar y se comporta según sus expectativas, es más probable que saber qué botón hacer clic cuando aparece un cuadro de diálogo molesto.
También intento con todas mis fuerzas evitar cualquier cosa modal, por lo que los usuarios poder Ignoro la mayoría de los diálogos que tengo que usar, al menos por un tiempo (y cuando realmente necesitan prestarles atención, tienen suficiente información para saber qué hacer con ellos).
Es imposible crear un sistema completamente infalible, pero he descubierto que las técnicas anteriores contribuyen en gran medida en la dirección correcta.(y se han incorporado en los sistemas utilizados para desarrollar la recompensa de explicación sorpresa y otras herramientas que han sido examinadas mediante amplios estudios de usuarios).
Otros consejos
En primer lugar, el uso de colores e íconos debería ayudar a que el usuario tenga cierta conciencia visual de la gravedad del problema: el rojo para transmitir algo excepcional, el amarillo para transmitir una advertencia y el blanco para transmitir información.
En segundo lugar el uso de verbos en los botones de diálogo les da a los usuarios una idea de lo que le están diciendo al sistema que haga incluso si no leen el texto del cuadro de diálogo.
Por último, si está interesado en buscar un paradigma de notificación completamente diferente, consulte la barra de información o barra de notificaciones que está implementada en Firefox e Internet Explorer.StackOverflow utiliza el mismo tipo de mecanismo para notificar a los usuarios cuando obtienen una nueva insignia.
La barra de información no molesta y permanece en la parte superior de la pantalla esperando la atención del usuario.Creo que es una gran metáfora del diseño.
Aquí hay un par de tutoriales de implementación:
Aquí está Guía de Microsoft sobre el diseño de diálogos, también toca el concepto de barra de información.
Inmediatamente el libro de Steve Krug. No me hagas pensar me viene a la mente.
En el diseño de cuadros de diálogo, mensajes de estado al usuario, etc.Es bueno utilizar iconografía y sugerencias de color sobre lo que realmente dicen las palabras.
Por lo tanto, resalte los mensajes de error en rojo, las advertencias en amarillo, etc.
La interfaz humana, por Jef Raskin vale la pena leerlo.Un cuadro de diálogo es el último recurso y una señal de mal diseño.La mayoría son innecesarios y, como descubrió, los usuarios los ignoran.
¿Por qué hay un cuadro de diálogo?Resuelva ese problema: no pida a los usuarios que confirmen una operación, en lugar de eso, facilite deshacer la operación.No muestre un cuadro de diálogo emergente anunciando un error; realice cualquier recuperación que vaya a realizar de todos modos (o lo que sea posible).Definitivamente no muestre cuadros de diálogo que tengan un solo resultado (los cuadros "OK" son el diablo), presente la información dentro de la aplicación de manera discreta.
Un par de sugerencias
- Utilice cajas únicamente cuando sea absolutamente necesario.
- Establezca siempre la opción predeterminada en la opción menos peligrosa
A Rocas .NET Me viene a la mente el episodio (creo episodio 338, "Mark Miller sobre la ciencia de la buena interfaz de usuario") analiza este mismo tema.Creo que la clave de toda esta discusión es que se trata de un diseño básico de interfaz de usuario llevado demasiado lejos.Mientras que el modal alguna vez fue un medio de comunicación aceptable, ahora descubrimos que se ha convertido en un paso en falso de la programación.Los usuarios entienden que 6 de cada 10 veces la información no es lo suficientemente pertinente como para preocuparse.Como resultado, tratan a todos los modales de la misma manera: impotencia aprendida.Si aparece un modal y me dice que se produjo el Error de aplicación X y lo único que puedo hacer es hacer clic en "Aceptar", incluso cuando no creo que esté "OK", aprendo un comportamiento particular.Asocio los modales con la idea de que probablemente no pueda hacer mucho al respecto, pero si hago clic en Aceptar/Sí, entonces puedo volver a lo que necesito.
Entonces, ¿por qué se sigue utilizando?Quizás los desarrolladores hayan intentado evitar el hecho de que el desarrollo de aplicaciones se está convirtiendo en algo más que una simple interfaz básica, y los usuarios requieren un diseño de interfaz de usuario fluido: es difícil renunciar a los viejos recursos...
Creo que la clave aquí es comprender que un buen diseño de interfaz de usuario ahora indica que las interrupciones (incluso para el usuario de computadora más novato) son molestias y que debemos esforzarnos por tener una experiencia de usuario perfecta donde el foco de la aplicación sea el usuario, no las necesidades de la aplicación a través de indicaciones e informes de errores; no permita que un usuario se meta en situaciones en las que no le importa.
A menudo los desarrolladores utilizan cuadros de diálogo modales simplemente porque es fácil codificarlos.
Sin embargo, las notificaciones no modales suelen ser más cómodas de manejar para el usuario.
Una sugerencia:
- No utilice cuadros de diálogo.Especialmente cuadros de diálogo modales, Aceptar/Cancelar.
A veces eso es difícil...¿Cómo manejas la apertura de un archivo?A veces es fácil...¿Realmente necesitas advertir al usuario que está a punto de sobrescribir un archivo?Lo más probable es que, si hago clic ciegamente en "Aceptar", no prestaré atención a ninguna advertencia.
Si debe utilizar un cuadro de diálogo, coloque títulos descriptivos en los botones dentro del cuadro de diálogo.
Por ejemplo, en lugar de los botones Aceptar y Cancelar, haga que digan "Enviar factura" y "Regresar", o lo que sea apropiado en el contexto de su cuadro de diálogo.
De esa manera, el texto estará justo debajo del cursor y tendrán buenas posibilidades de comprenderlo.
Mac OS X hace esto la mayor parte del tiempo. Aquí hay una imagen de ejemplo.
Editar:
Esta es una mejor imagen., y lo encontré en el sitio de la Guía de interfaz humana de Apple, que es una excelente referencia y muy legible. Este documento en ese sitio trata sobre Diálogos.
Pregunta equivocada."¿Cómo manejarías a los usuarios?" comienza en el extremo equivocado.
La pregunta correcta es "Dado que los cuadros de diálogo distraen a los usuarios de la tarea en cuestión, ¿qué mejores alternativas existen?".
A la hora de trabajar para conseguir un objetivo o finalizar una tarea, podemos distinguir tres situaciones:
(1) La aplicación llega a la conclusión de que no hay ninguna acción que pueda realizar para que el usuario alcance su objetivo.Aparece un mensaje emergente, con un botón para descartarlo.No te importa si el lector lo entiende, ya que el resultado no importa de todos modos.
(2) Sólo hay una acción que puede realizar o las alternativas son irrelevantes para el usuario.No lo molestes en absoluto.
(3) Hay dos o más formas de lograr el objetivo.Deje que el usuario elija entre estos.No formule esto como una pregunta de sí o no.(Vista ofrece esto como un cuadro de diálogo común, para reemplazar el cuadro de mensaje). Si es posible, no haga de esta una elección irreversible.
La excepción a esta regla es la situación en la que el usuario esperar una pregunta de sí/no.Pero realmente, si ese es el caso, ¿por qué la pregunta no forma parte del flujo de trabajo normal?Los cuadros de diálogo están fuera del flujo de trabajo normal.
Creo que probablemente quieras leer este artículo:"Impacto de las interrupciones de estilo negociado de alta intensidad en la depuración del usuario final", T.J.Robertson, Joseph Lawrance y Margaret Burnett, Journal of Visual Languages and Computing 17(2), 187-202, abril de 2006.
Hizo una pregunta similar.El resultado fue hacerle saber al usuario que desea su atención y luego sentarse y esperar a que el usuario responda.Sin embargo, no interrumpas al usuario, eso no es lo que él o ella quiere.
La [Caja de luz](http://en.wikipedia.org/wiki/Lightbox_(JavaScript)) El diálogo modal parece una técnica eficaz en algunos casos (derivación web 2.0, pero puede implementarse en otros contextos).
Otro punto:si puede renunciar a un cuadro de diálogo para un Deshacer función (Gmail, por ejemplo, defendió este concepto como comportamiento estándar de la aplicación web) eso es algo a considerar.
Si debe utilizar un diálogo, recompense al usuario con comentarios divertidos, comprensivos o incluso satíricos y muy corto texto explicativo.Si de vez en cuando repartes algo graciosamente escandaloso, lo leerán. todo.
El usuario se está ejecutando peligrosamente bajo en sentido común.Elimine este usuario e inserte otro.
Tengo poca paciencia con los usuarios que no leen lo que me ha costado mucho tiempo y esfuerzo desarrollar:1) la aplicación 2) las instrucciones Aparte de eso, si no lees y simplemente haces "lo que sea necesario", estás solo.Lo digo desde el principio.Diseño mis aplicaciones para que sean lo más intuitivas posible y todavía hay personas que hacen llamadas telefónicas de soporte de la nada, como un niño que grita en clase cuando no debería hacerlo.No tengo tolerancia para eso.Lea el manual, lea los cuadros de diálogo: las respuestas al 99% de los problemas están ahí.
Muchos buenos consejos arriba.Solo quiero agregar recomendaciones a los libros: vale la pena leer el libro "Diseño de interfaz de usuario para programadores" de Joel Splosky:
Una cosa que puedes hacer es tener el botón Aceptar desactivado durante 3 segundos.
Firefox hace esto cuando instalas una extensión.
Editar: Muy bien, algunas personas encuentran esto molesto.Sigo pensando que aproximadamente 1 segundo estaría bien.Suprimiría el instinto instantáneo de hacer clic en OK que tienen las personas (incluido yo mismo) y obligaría a pensar dos veces.Por supuesto, incluso esto molestará a las personas si su diálogo no es algo que realmente necesiten leer.
En primer lugar, una estupidez debería doler, pero normalmente no es así...
La mejor opción es incluir un ícono que intente transmitir la gravedad del problema.Un porcentaje de aquellos que no leen podrían cambiar su hábito si el ícono del diálogo parece siniestro.Un porcentaje no lo leerá de todos modos.
Incluya un cuestionario de opción múltiple al final del cuadro de diálogo, en el que el usuario debe seleccionar la respuesta que demuestre que realmente leyó y entendió el texto.Cambie aleatoriamente el orden de las opciones para que no siempre puedan hacer clic en la misma.
Cambiar la redacción y el funcionamiento del diálogo ayuda.Por ejemplo, tener botones Aceptar/Cancelar tiende a permitir que los usuarios ignoren la mayor parte del diálogo.Si elimina los botones normales y los reemplaza con enlaces de comandos más detallados, es más probable que los usuarios lean cada botón porque la opción "rápido, desaparecer" no está disponible.
A esto lo llamo el problema del "piloto automático".
- No utilice los botones Aceptar y Cancelar en la parte inferior de la pantalla.Mire la forma en que Vista intenta obligar a los usuarios a tomar una decisión real.
- Desactive los botones durante unos segundos, muestre un temporizador/barra de progreso "Tiempo para pensar".Entonces el usuario no puede hacer clic en piloto automático.Los usuarios tienden a encontrar esto muy molesto.
No utilices la confirmación (¿Estás seguro?Sí/No), pero utilice Deshacer.
No muestre advertencias emergentes que sean bloqueando, porque los usuarios intentarán volver a trabajar lo más rápido posible, ignorando el mensaje y simplemente haciendo clic para eliminarlo.Utilice algo como la barra de información de Internet Explorer, que no bloquea.
¡Puedes evitar el uso de cuadros de diálogo por completo!En algunos programas hay un minibúfer que muestra errores y advertencias.Además de eso, también puede preguntarte algo, donde debes escribir lo que quieres hacer.Es una solución bastante limpia y agradable, tiendo a preferirla a una barra de menú.
Pero si realmente debes usar cuadros de diálogo, prueba esto:
- Sólo una frase por diálogo
- Como máximo dos o tres botones
- Hacer que el texto sea legible dentro del cuadro de diálogo (más grande, negro sobre blanco)
- Prefiera utilizar un cuadro de diálogo en lugar de muchos pequeños repetidamente (consejo:cuadro de lista)
¿Qué pienso sobre los cuadros de diálogo?En pocas palabras:Son cosas tontas y estúpidas.Los programas que los utilizan se interponen en mi camino y me frenan con sus estúpidas preguntas sin sentido.Además, a menudo los programas que utilizan cuadros de diálogo son bastante tontos.
