Notificación UI: dialogs, modals y alerts

Si has tenido que diseñar los componentes UI para web o producto digital, quizá te hayas sentido al borde de la locura a la hora de diseñar tus componentes de notificación. Parece haber mil distintos pero como ahora te contaré no son tantos, es sólo que se les pone distinto nombre. 

En la entrada de hoy te cuento que dialogs, modals y alerts son lo mismo, ventanas emergentes a las que se les llama diferente según el sistema de diseño. Recuerda que esto también sucedía con los tooltips y toggletips solo que estos además se confunden entre ellos. 

¿Qué son los dialogs, modals o alerts?

A las ventanas emergentes yo siempre las he llamado Modals porque es el nombre con el que primero las conocí. Sin embargo es cierto que gente más mayor que yo y los desarrolladores de Android les suelen llamar Dialogs que es como se les nombra en Material y quienes trabajan diseñando o programando para los sistemas de Apple suelen estar influidos por el nombre de las Human Interface Guidelines, así que las llaman Alerts.

Curiosamente, en Fluent de Microsoft diferencian entre dialog y modal en función de si el texto es corto o largo. Texto corto = dialog, texto largo = modal. Por su parte, en Carbon de IBM consideran que el dialog puede ser modal o non-modal como veremos más abajo. 

En cualquier caso, este tipo de ventana emergente es un diálogo entre el sistema y el usuario pues interrumpen un flujo de tareas de éste y esperan del mismo una respuesta. Son una conversación. En concreto los modals presentan información crítica o solicitan información necesaria para completar su flujo de trabajo.

En palabras de las HIG de Apple:

“La modalidad es una técnica de diseño que presenta contenido en un modo separado y enfocado que impide la interacción con la vista principal y requiere una acción explícita para cerrarlo”.

Cuando estos diálogos se abren, el usuario no puede volver a su flujo de trabajo anterior hasta concluir la conversación con el sistema. Esto en la práctica se traduce en que los modales solo se pueden cerrar eligiendo una de las contestaciones que ofrece el sistema y que bloquean toda actividad con cualquier otra parte de la GUI. Además se añade una capa de oscuridad entre el contenido y el modal para que sea más obvio la sensación de bloqueo.

No permitir al usuario nada más allá de esta conversación puede parecer contraintuitivo pero lo cierto es que, dado que se deben limitar para información importante, es clave centrar la atención del usuario exclusivamente en esa tarea o información. En consecuencia, no debemos abusar de los diálogos modales.

¿Cuándo utilizar modals, dialogs o alerts?

Cuando se precisa una respuesta inmediata del usuario. Es decir, cuando se requiere información necesaria para que el sistema continúe funcionando. Por ejemplo cuando en el teléfono nos conectamos a una red WiFi y el diálogo nos solicita la contraseña.

Para notificar al usuario información urgente. Esto es cuando la ventana emergente tiene que notificar al usuario información urgente relacionada con su trabajo actual. Por ejemplo cuando el teléfono nos avisa de que tenemos poca batería y nos plantea qué hacer en consecuencia, ahorrar batería o continuar igual.

Confirmar una decisión del usuario. O lo que es lo mismo, para que el usuario demuestre que es consciente de lo que está haciendo y de las consecuencias de sus actos. Como ejemplo de esto, cuando Word o Photoshop nos preguntan si de verdad queremos cerrar el documento sin guardar los cambios.

Tipos de modal

Pasivo:Presenta información clave que el usuario debe conocer sobre su flujo de trabajo actual. No contiene ninguna acción para el usuario.

Transaccional: Requiere que se realice una acción para que el modal se complete y se cierre. Contiene un botón de cancelación y otro de acción principal.

Peligro: Variante específica del modal transaccional que se utiliza para acciones destructivas o irreversibles.

Reconocimiento: El sistema requiere un reconocimiento de la información por parte del usuario. Contiene un único botón, normalmente «Aceptar».

Progreso: Requiere que se completen varios pasos antes de poder cerrarse. Contiene botones de cancelación, anterior y siguiente/completar.

Ventanas emergentes non-modal 

Podríamos decir que hay otro tipo de modal que presenta información relevante pero no crucial y que no bloquea el resto de la GUI aunque esté activo. Sin embargo, a este tipo de diálogo en Carbon lo consideran non-modal, es decir que no es modal.

Anatomía de los modal dialog

La ventana de las ventanas emergentes modal dependerá del tipo al que pertenezcan y de las funciones que deban cumplir. Sin embargo, en términos generales la anatomía de las ventanas modales estará configurada por un título revelador y conciso, un cuerpo de texto que amplíe la información del título, un par de botones con opciones contrapuestas y un icono X para cerrar el dialog. Esto significa deshacer la acción que lo activó.

En casos más particulares, como veíamos antes según el tipo de modal, encontraremos una anatomía diferente. Además hay que entender las siguientes particularidades:

• En ocasiones el propio título es suficientemente conciso como para necesitar un cuerpo de texto que amplíe esa información.
• Si el título puede dejar hueco a alguna duda, se puede incluir una etiqueta de contexto por encima del título o un subtítulo que en una frase sea aclarador.
• Comúnmente de los dos botones, uno es Cancelar y coincide con el icono de la X. Curiosamente Material renuncia a este icono de cerrar y solo da opciones en los botones inferiores.
• Alguna vez podemos solo tener un botón de Aceptar para confirmar que se ha leído la información. Ninguna otra acción es requerida.
• Otras veces podemos necesitar más de dos botones porque las posibilidades son múltiples.

Diseñar modals, dialogs o alerts con éxito

A la hora de diseñar modals, alerts o dialogs deberíamos leer la documentación de cada sistema operativo en el que vayamos a entregar nuestro producto para adaptarnos a las consideraciones “del fabricante”. 

Sin embargo, más allá de eso y sobre todo de cara a diseñar para web, hay una serie de claves que debemos utilizar si queremos diseñar este tipo de ventana con éxito. 

• El título debe ser breve, simple y describir claramente el propósito del diálogo.
• El texto irá alineado a la izquierda y el botón con el icono de X será lo único alineado a la derecha.
• El conjunto del texto debe dejar margen a los lados. No así los botones de la parte inferior.
• Todo el contenido que aparezca en el modal debe ser relevante y tener relación con el flujo que se interrumpe. No añadiremos información por añadirla.
• El copy de los botones será lo más preciso posible y entendible en el contexto de la tarea que se estaba realizando. Mira esta entrada para descubrir más sobre botones UI.
• Los botones deben reflejar una jerarquía siendo el botón primario aquel que avanza más la tarea y secundario aquel que la avanza menos o la retrocede.
• No es obligatorio pero sí conveniente colocar el botón primario a la derecha y el secundario a la izquierda.