Últimamente he estado desarrollando un sistema de gestión basado en la web para un gimnasio. Su aplicación anterior fue desarrollada en Visual Basic. Para la nueva aplicación, todas las secuencias de comandos front-end usan jQuery, el servidor ejecuta PHP y MySQL ... ya sabes, la típica pila basada en el-cheapo linux.
De todos modos, me preguntaba por qué los diálogos de mensajes de aviso, confirmación y alerta de JavaScript están tan subutilizados hoy en día. Hay muchos complementos de jQuery para ventanas modales y mensajes de alerta que intentan imitar algo que el idioma ya ofrece y que cada navegador se ve obligado a soportar correctamente.
El uso de soluciones hechas a mano o basadas en complementos está bien para formularios complejos y necesidades especiales, pero si solo necesita solicitar un valor único o confirmar la eliminación de un registro, ¿por qué agregaría esa sobrecarga a su aplicación web? Además, iOS y Android ofrecen cuadros de diálogo de mensajes muy bien adaptados cuando usa prompt, confirm y alert.
fuente
Respuestas:
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:
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.
fuente
confirm()yprompt(); conalert(), el comportamiento depende del navegador (la ejecución puede continuar incluso cuando se muestra alert (); la razón es que "de todos modos solo hay una salida").En pocas palabras: los cuadros de diálogo predeterminados de solicitud, confirmación y alerta coinciden con el estilo de su navegador, no con el estilo de su sitio. La mayoría de las personas de IU desean que todos los cuadros de diálogo fluyan con la IU de su sitio. Utilizan ventanas modales para presentar mensajes y recopilar datos utilizando las mismas fuentes y colores que la interfaz de usuario del sitio, no el gris y azul predeterminados de MSIE o FF.
fuente
Solo está agregando gastos generales si no necesita los cuadros de diálogo sofisticados en otro lugar, lo que probablemente sí necesita. En ese punto, no hace mucha diferencia si la funcionalidad se incluye como parte del navegador o como parte del marco que está utilizando, y también puede mantener todas sus ventanas emergentes con un aspecto coherente.
Si bien puedes hacer mucho con javascript y sin frameworks, recuerdo lo que fue desarrollar en javascript antes de que los frameworks estuvieran disponibles, y no me gustaría volver a ello.
fuente
Porque los navegadores no los manejan muy bien . Como habrás notado, generalmente son cuadros de diálogo modales y no solo evitan que los usuarios se muevan y cambien el tamaño de sus navegadores, sino que también evitan el acceso a otras pestañas, lo cual es muy molesto.
Para diálogos como confirmar y alterar, sigo pensando que el navegador debería aplicar el comportamiento, y para el último navegador Firefox puede ver que han solucionado el problema que mencioné anteriormente. Se usan en alertas de página que tienen un alcance de la página actual.
Por lo tanto, le sugiero que anule el comportamiento de alerta para que todos los navegadores puedan manejar (al menos las alertas) de manera más elegante.
Algunas razones resumidas:
fuente