1. UX: los cuadros de mensaje son en su mayoría malvados
Los cuadros de alerta son malos en todos los casos desde el punto de vista de UX. En aplicaciones de escritorio. En aplicaciones web como alertas o mensajes JavaScript en línea. En todas partes.
Puedes leer About Face 3 de Alan Cooper¹ si quieres saber por qué; explica muy bien cómo esto interrumpe el flujo de trabajo y molesta al usuario, y cómo casi todos los cuadros de alerta que existen en el software actual están profundamente equivocados . En la página 542, "El cuadro de diálogo que gritaba" ¡Lobo! "" Explica que los cuadros de alerta se descartan habitualmente, por lo que su modelo está completamente roto. En la página 543 del libro se enumeran tres principios de diseño principales:
- Hazlo, no preguntes.
- Haz todas las acciones reversibles.
- Proporcione comentarios no modales para ayudar a los usuarios a evitar errores.
Luego, los autores nos dicen cómo reemplazar los cuadros de alerta por el enfoque de diseño correcto.
Los mensajes rápidos son ligeramente diferentes. Y aún así, rompen la experiencia del usuario de su aplicación. Si desea que el usuario ingrese algo, considere usar un cuadro de texto o un área de texto, decorándolo con JavaScript cuando sea necesario. No seas perezoso, proporciona una interfaz rica en una era de aplicaciones habilitadas para RIA y AJAX ; en todos los casos, si JavaScript está deshabilitado, su solicitud no se mostrará.
En las páginas web, los cuadros de alerta y las indicaciones son en su mayoría molestos. Algunos ejemplos:
Algunos foros le permiten crear listas solicitando infinitamente los elementos de la lista. Significa que al crear la lista, no puede usar la página en sí, incluido copiar y pegar. También tienes un pequeño campo pequeño. ¿Qué pasa con el texto largo? ¿Qué pasa con negrita y cursiva?
"Si continúa, la foto se eliminará definitivamente de su perfil. ¿Está seguro?" . ¡Por supuesto que estoy seguro! ¿De lo contrario, haría clic en "Eliminar foto de mi perfil"? ¿Por qué su aplicación web supone que soy tan estúpido? En realidad, las aplicaciones de Google como GMail muestran el enfoque correcto. Puede eliminar, eliminar, destruir lo que desee, y cuando lo haga, la aplicación mostrará un pequeño enlace "Deshacer".
"¿Quieres hacer nuestra mejor encuesta?" . Bueno, en realidad estaba allí para visitar su sitio web, pero como me molesta con sus mensajes molestos, prefiero ir a otro lugar.
"El clic derecho está deshabilitado en este sitio web para proteger las fotos con derechos de autor" . Bueno, en realidad hice clic derecho para cambiar el idioma del corrector ortográfico antes de enviar mi comentario. Claro, lo enviaré sin revisar la ortografía.
Conclusión: desde el punto de vista de la experiencia del usuario, las aplicaciones usan cuadros de mensaje incorrectamente la mayor parte del tiempo.
¡Pero espera! Muchos sitios web de baja calidad reemplazan cuadros de alerta molestos por mensajes JQuery molestos con un fondo semitransparente que cubre toda la página. Entonces los inconvenientes permanecen.
Bueno, hay otras razones para no usar cuadros de mensaje en aplicaciones web:
2. Diseño: los cuadros de alerta tienen su propio diseño
No puede diseñar un cuadro de alerta en absoluto. No puede cambiar su color, su tamaño, su fuente. Esto lo hace aún más molesto para el usuario: estaba trabajando con una aplicación web y su flujo de trabajo se ve interrumpido por un mensaje que parece provenir de la nada y que ni siquiera coincide con el aspecto visual de la aplicación. Sin contar que el idioma de los botones también coincide con el idioma del sistema operativo / navegador, no con el de la aplicación web.
Para los diseñadores, los mensajes de JavaScript son mucho más potentes que los cuadros de alerta.
También son mucho más extensos. Puede agregar negrita y cursiva, puede elegir sus propios botones (¿qué pasa con: "Nos disculpamos pero la contraseña que ingresó no es válida. [Restablecer mi contraseña] [Intentar con otra] [Cancelar]") ².
3. JavaScript: el flujo de la aplicación se detiene
Al mostrar un cuadro de alerta, JavaScript deja de ejecutarse hasta que el usuario hace clic. En un sitio web, podría estar bien. Con una aplicación web, a menudo se convierte en un problema.
4. Sandbox: no obligue al usuario a reiniciar su computadora
¿Recuerdas los sitios web malos que te muestran un número infinito de cuadros de mensaje ? De hecho, la única forma para que los usuarios sin suficiente experiencia técnica pudieran continuar trabajando era reiniciar su computadora. Esto nos lleva a un problema: los cuadros de alerta están fuera del alcance del sitio web o la aplicación web. No tiene autorización para evitar que el usuario acceda a otras pestañas del navegador³.
El mismo problema obligó a los navegadores a resolverlo de diferentes maneras. Firefox, por ejemplo, permite el acceso a otras pestañas al mostrar una alerta en su pestaña. Chrome, por otro lado, le permite verificar que ya no desea recibir cuadros de alerta de una página, pero aún bloquea el acceso a otras pestañas.
Si bien el enfoque de Firefox es perfectamente válido, el de Chrome puede ser criticado (ya que todavía bloquea todas las pestañas) y causa un problema: ¿qué pasa si el usuario se molestó severamente por varios cuadros de mensajes emitidos por su aplicación y verificó el caso, y luego, usted trató de mostrar algo realmente importante? Correcto, el usuario nunca lo verá.
El hecho sigue siendo el mismo, la mayoría de los usuarios se molestarán por los cuadros de alerta, por lo que aún no son muy fáciles de usar y pueden bloquear severamente a un usuario sin suficiente experiencia técnica. En línea, los mensajes de JavaScript pueden bloquear la página, pero no el navegador en sí. Dado que el modelo de aplicación web es una especie de sandboxing, donde no puede, por ejemplo, acceder al teclado del usuario o reiniciar la computadora o leer archivos desde el disco duro o pasar a pantalla completa o usar dos monitores, los cuadros de alerta con su efecto de bloqueo rompen severamente esto modelo de sandboxing .
Por último, pero no menos importante, ¿qué pasa si el usuario estaba en otra pestaña cuando su aplicación decidió mostrar el cuadro de alerta? ¿Qué sucede si el usuario estaba haciendo algo importante y no desea interactuar con su aplicación en este momento?
¹ About Face 3, The Essentials of Interaction Design , Alan Cooper, Robert Reimann y David Cronin, ISBN 978-0-470-08411-3; Capítulo 25: Errores, alertas y confirmaciones.
² Esto es solo un ejemplo. Por favor, no lo haga en sus aplicaciones web, ya que es realmente una mala elección de diseño.
³ Si desea una comparación con el mundo de las aplicaciones de escritorio, un mensaje de JavaScript en línea es como un cuadro de mensaje de una aplicación de escritorio. Un cuadro de alerta en un navegador, por otro lado, es como una ventana que aparece de la nada, configurada como superior, en un fondo opaco de pantalla completa que le impide acceder a cualquier otra aplicación de escritorio. Cualquier aplicación que decida hacerlo una vez en mi computadora se eliminará de inmediato y para siempre.