modal dialog - ventana - ¿Por qué los cuadros de diálogo modales son malos?
ventana modal javascript (11)
Con respecto a la pregunta reciente, ¿ cuándo son realmente necesarios los diálogos modales? . ¿POR QUÉ son malos los cuadros de diálogo modales? ¿Es porque la gente no los lee de todos modos? Porque a menudo se implementan tan mal? ¿Algo más?
Antes de leer mi respuesta, debe leer detenidamente el siguiente mensaje en su totalidad. Todos los procesos, subprocesos, tareas e hilos se suspenden indefinidamente en espera de su respuesta. Y, una vez que comprenda completamente el mensaje, y posiblemente acepte algunas cuestiones legales, y todas las implicaciones de todo esto, entonces, y solo entonces, podrá continuar.
Aproximadamente la mitad de las respuestas hasta ahora están abordando los defectos de los diálogos de confirmación , no de los diálogos modales . Si bien la gran mayoría de los diálogos de confirmación son modales, esto no significa que los dos términos sean sinónimos.
Un diálogo de modo es aquel que coloca el programa en un modo específico y no le permite hacer nada que no corresponda a ese modo mientras está abierto. En la implementación más común, esto significa que no puede acceder a ninguna otra ventana.
Esto es malvado
Considere una aplicación de libreta de direcciones. Supongamos que tiene una persona existente en la libreta de direcciones y desea agregar a su compañero de cuarto.
- Si el cuadro de diálogo "agregar persona" no es modal, puede alternar entre el registro anterior y el nuevo copiando y pegando sus datos.
- Si el cuadro de diálogo "agregar persona" es modal, no puede hacer nada con el registro anterior mientras está abierto el cuadro de diálogo Agregar. Puede seleccionar algo para copiar antes de seleccionar "agregar", pero solo una cosa. Todo lo demás tiene que ser reescrito manualmente.
En raras ocasiones, se encuentra con algo que realmente debe hacerse de una sola pieza sin permitir que el usuario se desvíe de esa tarea hasta que esté completo. Los diálogos modales son apropiados para tales casos. ¡Pero estos casos son muy raros! Que es básicamente el punto del otro hilo al que hace referencia esta pregunta.
Una de las razones por las que no me gustan es porque muestran información en serie (una gran cantidad de información a la vez) y no en paralelo (toda la información que necesita ver a la vez), paralela permitirá al usuario elegir Lo que quieren ver es que, como en serie, prácticamente los obligas a elegir una opción.
Además, el hecho de que rompen el flujo de control de los usuarios (por ejemplo, roba el foco del objeto sobre el que trabajas), lo que realmente no me gusta hacer. Entonces, en efecto, el usuario simplemente presionará OK para que puedan volver a lo que estaban haciendo e ignorar la información en el cuadro de diálogo.
Eso sí, los necesitas en algunos casos.
El artículo de Wikipedia tiene una buena suma de las quejas.
En una aplicación de estilo de consumidor, son más o menos inútiles; los usuarios no las leen, aprenden a descartarlas y, cuando las LEYEN, generalmente se confunden. Creo que un diálogo Sí / No / Cancelar es un diseño de IU totalmente vago. El cuadro de diálogo "los botones dicen lo que hacen" es un poco mejor, porque el usuario no tiene que leer mucho.
Dicho esto: en aplicaciones de intranet / "empresa" de datos críticos, son más o menos necesarias para confirmar acciones destructivas o para verificar la cordura de flujos de trabajo no estándar que pueden permitirse pero no recomendar.
Por lo tanto, no creo que sean conceptualmente "malvados", sino que, en la mayoría de los casos, son el resultado de un mal diseño de IU.
La gente no los lee, y eso es algo bueno. Desea que las personas formen hábitos en torno a su UI, pero tener una opción importante en la ventana emergente solo hará que el usuario presione Aceptar.
Interrumpen al usuario, evitan que el usuario haga otras cosas.
¿Qué pasaría si quisiera copiar y pegar algo de la ventana principal? ¿Qué sucede si quiere copiar el mensaje en el cuadro de diálogo modal? ¿Qué pasa si no te importa ?
Simplemente compare el diálogo Buscar de IE con Firefox
Compare IE''s "¿Desea que recordemos esta contraseña por usted?" a Firefox
Las mejores IU son modales. Como son los peores.
Una interfaz de usuario modal, independientemente de si está construida a partir de cuadros de diálogo, botones de la barra de herramientas o mensajes de texto, solo es deseable siempre que cada modo coincida con las expectativas del usuario que realiza la transición. Cuando el programa pasa a un modo inesperadamente ... o el modo requiere que el usuario posea información que no tiene fácilmente disponible ... entonces causará dificultades al usuario, ya sea forzándolo a volver a un modo anterior o adivinar el acción apropiada con resultados potencialmente indeseables.
Una UI no modal es un conjunto completo de herramientas. Algunos son relevantes para el trabajo en cuestión, otros no. Un usuario debe tener suficiente habilidad tanto para elegir las herramientas correctas como para aplicarlas de la manera correcta. Si bien una IU no modal nunca puede ser tan óptima como una buena UI modal (la herramienta adecuada para la tarea actual que ya se tiene a mano), tampoco puede ser tan subóptima como una IU modal mala (la herramienta incorrecta para la tarea actual golpeando sus dedos descuidados).
Diseñar una buena interfaz de usuario modal puede ser una tarea tremendamente difícil para aplicaciones no triviales, especialmente para programas de propósito general destinados a ser utilizados por una amplia variedad de usuarios para una gama más amplia de propósitos. Los sistemas de menús y los cuadros de diálogo intentan cerrar la brecha, permitiendo pequeñas secciones modales específicas de la tarea en una aplicación no modal más grande. Sin embargo, ninguno se adapta particularmente bien, y el mal uso y el uso excesivo los han dejado con una mala reputación, a menudo visto como el primer refugio del programador perezoso. Los cuadros de diálogo en particular se usan más como un medio de forzar a los usuarios a la idea de un programador (o diseñador) de cómo se debe usar una aplicación, o tomar decisiones de diseño difíciles y manejar un error en el usuario, en lugar del objetivo del mismo nombre comunicación.
De hecho, el auge de las aplicaciones web ha sacado esas tendencias a la superficie en numerosos foros, grupos de noticias y sitios de preguntas y respuestas como este, ya que los programadores acostumbrados a escribir lógica ultra-lineal que solicita a los usuarios el aporte cuando lo necesita el programa y no cuando disponible para el usuario ... son forzados a un sistema donde los usuarios pueden navegar de forma no lineal, y pueden ver cualquier intento de restringir esta libertad como una molestia pintoresca para ser subvertida en lugar de un mal necesario. Los lamentos quejumbrosos de estos pobres codificadores hacen eco en toda la red mientras sus intentos de forzar este crudo comportamiento modal hacia un sistema no modal se derrumban a su alrededor. Para aquellos de nosotros que hemos sufrido durante mucho tiempo bajo sus "diálogos" crueles, de hecho es una melodía preciosa.
No recuerdo dónde vi esto primero, pero un mejor enfoque para un diálogo modal a menudo es permitir una capacidad de "deshacer" fácil de encontrar y usar. Windows Explorer realmente hace ambas cosas cuando elimina un archivo. Solicita confirmación (diálogo modal), luego, inmediatamente después de eliminar el archivo, el menú Edición tiene una opción "Deshacer Eliminar". simplemente una forma simple de acceder a la Papelera de reciclaje, pero en este caso, Microsoft realmente podría haber eliminado el diálogo.
El punto es que a menudo puede prescindir del diálogo con un poco de pensamiento, y tal vez un poco de código adicional, pero es una opción demasiado fácil para un desarrollador perezoso, o quizás, más generosamente, de tiempo limitado.
Dicho esto, a veces realmente quieres un diálogo. Piense en todas las opciones en un diálogo de Imprimir típico. ¿Qué impresora? Todas las páginas, o solo algunas? Cuantas copias? No sé cómo lo harías sin un cuadro de diálogo ...
Noboy los lee y ellos interrumpen el flujo del programa. A menudo, cuando se utilizan como notificación de error, son el precursor de una falla del programa. Cuando el usuario se da cuenta de lo que está sucediendo, el mensaje se va y se les deja recordar o inventar el mensaje lo mejor que pueden.
Personalmente creo que depende completamente de cómo se hace.
Intenta copiar 10 archivos donde cada archivo existe en el directorio de destino, hazlo usando Windows Explorer.
Es un diálogo modal único para cada archivo realmente la respuesta correcta en tal operación. Sé que tienes "Sí a todos", pero todo el sistema de bucle debería haberse construido de forma diferente. Debería haber reunido todos los archivos que existen en una gran lista y preguntó una vez "¿Qué quieres hacer con estos archivos?", Y luego dejar que decida por cada archivo de la lista qué hacer antes de hacer clic en Aceptar y reanudar la operación .
Y muchas veces los cuadros de diálogo simplemente interrumpen el flujo de trabajo normal.
Y sí, la gente no lee los cuadros de diálogo. Así que un consejo de oro si debe usar un cuadro de diálogo es volver a redactarlo.
En lugar de "¿Desea eliminar esta fila en la base de datos?", Intente redactarla para que pregunte (pero esto no está redactado correctamente) "¿Desea no eliminar esta fila en la base de datos?" De esta forma, si solo presionan Sí, que es la respuesta típica de un usuario que solo quiere seguir adelante, terminarán sin hacer nada.
Son malvados porque violan el principio básico de que se supone que el usuario puede dirigir la acción del software. Los diálogos modales (la forma diabólica de los cuadros de diálogo en general) limitan al usuario a una sola acción.
Algunas respuestas parecen entender erróneamente que es cualquier ventana emergente que pida, por ejemplo, la confirmación del usuario. Esto podría lograrse sin atar toda la aplicación o la computadora; es este comportamiento al que la gente se opone.
En algunos entornos, los diálogos modales solo limitan al usuario en el contexto de una sola aplicación (o tal vez menos). Los diálogos modales realmente malos evitan que el usuario haga algo más en todo el sistema operativo (por ejemplo, Windows).