- La debilidad clave de las notificaciones toast es que el punto de atención actual del usuario y la ubicación del feedback están separados, por lo que es difícil conectar de inmediato el resultado con la acción que acaba de realizar
- En el flujo de guardado de YouTube, la mirada se mueve entre el botón Save a la derecha, el modal al centro y el toast abajo a la izquierda, lo que interrumpe la interacción, y además no hay indicador de carga durante la demora
- Después de cambiar una casilla de verificación, hay que esperar a que desaparezca el toast anterior para ver el mensaje de confirmación más reciente, y el botón Undo del toast también es innecesario si basta con volver a hacer clic en la casilla
- Una mejor forma es poner el feedback dentro del lugar donde ocurre la acción: mostrar la lista de reproducción debajo del botón y enseñar un indicador de carga mientras cambia la casilla para mostrar el estado del progreso
- Lo único peor que un toast es no tener ningún feedback, así que si no hay tiempo para diseñar o implementar algo mejor, un toast sigue siendo preferible a no mostrar nada
El problema básico de los toast
- Las notificaciones toast por lo general aparecen lejos del lugar hacia donde está dirigida la atención del usuario
- Si el feedback aparece en un lugar distinto al botón que se acaba de presionar o al área que se está editando, al usuario le cuesta relacionar y entender la acción y su resultado
Problemas del flujo de guardado de YouTube
- En el ejemplo de YouTube, el usuario hace clic en el botón Save del lado derecho de la pantalla y luego termina mirando el modal en el centro y el toast abajo a la izquierda, en ese orden
- Este flujo mueve la vista entre varias zonas y también hace que el feedback sea más difícil de entender de inmediato
- El toast se retrasa sin mostrar indicador de carga
- Si dentro del modal se marca o desmarca una casilla, hay que esperar varios segundos a que desaparezca el toast anterior para poder ver el toast de confirmación más reciente
- El botón Undo del toast es innecesario porque el usuario simplemente puede volver a hacer clic en la casilla
Cómo resolverlo sin toast
- Incluso con un rediseño simple, el mismo feedback puede resolverse sin usar toast
- Mostrar la lista de reproducción justo debajo del botón, en vez de dentro de un modal
- Mostrar un indicador de carga mientras se marca o desmarca la casilla
- Cuando desaparece el indicador de carga, se entiende de forma natural que la acción se completó
- Como el feedback permanece en el lugar donde el usuario interactuó, no hace falta un toast aparte
Casos de Gmail y feedback de copiado
- En Gmail, cuando se archiva un correo aparece un toast de confirmación
- Pero el simple hecho de que el correo desaparezca de la lista ya indica que se archivó correctamente
- Aun así, el toast puede ser útil para la función de deshacer y cuando se usan atajos de teclado
- También hay casos donde aparece un toast después de copiar algo al portapapeles
- En el ejemplo, el propio botón ya incluye un estado de confirmación, así que el toast es totalmente innecesario
Aun así, el feedback sí es necesario
- Lo único peor que un toast es no tener ningún feedback
- Si no hay tiempo para diseñar o implementar un mejor mecanismo de feedback, un toast sigue siendo mejor que no mostrar nada
Cómo evitó Cakedesk los toast
- Cakedesk es una app de facturación offline-first y sin suscripción, y permite enviar correos dentro de la app
- En vez de dar feedback con un toast después de presionar el botón Send del correo, está diseñada para que el cambio de estado continúe dentro del mismo flujo
- Las facturas no enviadas muestran un botón Send en la lista
- Mientras se envía el correo, el modal permanece abierto y el botón de envío muestra el estado de envío en curso
- Si el envío se realiza con éxito, el correo se anima hacia fuera de la pantalla para indicar que se completó el envío
- El botón Send de la lista cambia a una casilla Paid, lo que confirma que el correo se envió y lleva al siguiente paso útil
- El usuario también puede presionar el botón contextual para comprobar si el correo fue enviado
2 comentarios
O sea, ¿lo que pasa es que los malos toasts son los malos??
Opiniones de Hacker News
https://en.wikipedia.org/w/index.php?title=Toast_(computing)
No me convence. La mayor parte del argumento parece decir que una UX redundante es una mala UX.
Me cuesta estar muy de acuerdo con ejemplos como que, si archivas un correo, este desaparece de la lista y eso ya implica éxito, o que como el botón tiene una marca de verificación, el toast es innecesario. Comunicar lo mismo de distintas maneras al mismo tiempo no es un bug, es una funcionalidad, y existe en todo el lenguaje humano. Porque ayuda a que el mensaje llegue incluso en condiciones que no son ideales.
Los toast informan el estado de todas las acciones de una forma estándar y, cuando es posible, incluso ofrecen deshacer, lo que permite que el usuario aprenda rápido el patrón. Las indicaciones adicionales cerca de la acción también tienen valor, pero muchas veces su significado queda más claro cuando están junto con un toast. Si se eliminan los toast y se reemplazan por varias indicaciones específicas, el usuario tiene que aprender, solo por contexto, múltiples expresiones que significan “ya terminó”. Puede ser especialmente malo para personas mayores, personas con discapacidad visual y niños.
Mientras no sean realmente intrusivos, los toast no son mala UX sino UX redundante, y los diseñadores de UX no deberían obsesionarse con eliminar la redundancia.
En el ejemplo de YouTube, la casilla de verificación es 100% una actualización optimista, y la notificación toast significa que la solicitud enviada de forma asíncrona al backend tuvo éxito. Lo mismo pasa con archivar un correo: el mensaje se quita de la lista de forma optimista y el toast indica que efectivamente se archivó.
Preferiría recibir un toast solo cuando falle el commit del cambio. Normalmente, que aparezca un toast de golpe me distrae de lo que intento hacer, y si está visualmente lejos de donde ocurrió la acción en la pantalla, distrae todavía más.
Hay que poner los mensajes donde ya está dirigida la atención del usuario. La UI llevó mi mirada hasta ahí, así que muéstralo ahí.
La lección es no enviarle al usuario información que no sea estrictamente necesaria.
Para leer más:
https://en.wikipedia.org/wiki/Banner_blindness
https://en.wikipedia.org/wiki/Alarm_fatigue
https://en.wikipedia.org/wiki/Inattentional_blindness
https://en.wikipedia.org/wiki/Habituation
En el peor de los casos, un toast tiene sentido como último recurso cuando hay que comunicar algo al usuario sin contexto. Por ejemplo, si el usuario desmarca una playlist, cierra la lista de playlists mientras se está guardando y luego el guardado falla, el contexto de la acción ya desapareció, así que se entiende usar un toast para mostrar la información en algún lugar arbitrario de la pantalla.
Aun así, si quieres que el usuario entienda bien el error, probablemente un toast no sea la mejor opción. En una app basada en publicidad como YouTube, donde el usuario es el producto, quizá no importe mucho que el usuario no vea estos errores, o incluso quizá sea lo deseable; pero en una app de trabajo, no querrías apostar a que el usuario no se pierda el toast o no lo confunda con otro error. Normalmente, al usuario le ayuda más volver a abrir el elemento correspondiente y mostrar el error dentro de su contexto. Se podría abrir la lista de playlists y usar una animación para llamar la atención sobre el hecho de que el cambio no se guardó. Puede ser un idealismo difícil de implementar de forma sistemática, pero idealmente siempre deberíamos ver errores dentro del contexto.
Lo peor es que los toasts desaparecen demasiado rápido y, además, llaman la atención innecesariamente incluso en acciones cuyo éxito debería darse por sentado. La combinación de ambas cosas es especialmente molesta. Te roban la atención sin necesidad, pero desaparecen tan rápido que no puedes saber si en realidad no había algo importante. A la inversa, también existe la variante que permanece demasiado tiempo y tapa una parte de la UI que ibas a mirar o usar de inmediato.
Me gusta el enfoque tradicional de escritorio: mostrar los mensajes de error como modales para que no se pasen por alto, y mostrar los mensajes de éxito como texto normal, sin interrumpir, en una barra de estado siempre visible y sin límite de tiempo. Si no aparece un modal de error, el usuario puede asumir que la acción tuvo éxito; y si necesita confirmarlo, puede revisarlo en la barra de estado sin presión de tiempo. También puede incluir información adicional.
Algunas apps también muestran en un popup el historial de mensajes de la barra de estado. En este enfoque, la barra de estado es como la última línea de salida de una terminal de línea de comandos, y también se puede recuperar la salida anterior.
Muchas veces termino entrando a las notificaciones para ver lo que me perdí. Parecía importante, pero no hubo tiempo suficiente para leerlo todo. Al tocar allí un elemento que parece un mensaje truncado, esperaría que me llevara al contexto completo, pero en realidad la notificación desaparece, solo se abre la app y no hay deep link al problema correspondiente. Entonces tengo que andar buscando un problema que quizá aparezca, o quizá no, dentro de la UI estándar de la app.
Me ha pasado incontables veces, y cada vez me enojo con quien diseñó ese sistema.
Hoy tuve este problema con mi hijo. Está practicando su velocidad de lectura y estábamos usando juntos una app nueva, pero seguían apareciendo toasts y le costaba seguirlos; además, lo distraían. Al final tuve que leérselos en voz alta. Si los mensajes hubieran permanecido más tiempo, podría haberlo logrado sin ayuda adicional.
YouTube tiene un ejemplo aún mejor.
Ve a https://www.youtube.com/feed/history, pulsa “Comments” a la derecha y elimina un comentario: aparece un toast que indica que se va a eliminar, y 1 o 2 segundos después aparece otro toast que confirma que se eliminó.
Si eliminas varios comentarios rápidamente, uno tras otro, primero aparecen varios toasts de eliminación pendiente y, tras una demora de 1 o 2 segundos, aparecen en orden los toasts de confirmación correspondientes. Como la eliminación real también se hace de forma secuencial, tienes que esperar todos los toasts de confirmación. Aunque hayas hecho clic en 10 comentarios en 2 o 3 segundos, la confirmación tarda más de 10 segundos.
Lo mismo pasa con los comentarios en vivo:
https://myactivity.google.com/page?page=youtube_live_chat&co...
En general, no estoy de acuerdo con la parte de que “el botón Undo del toast es innecesario porque el usuario puede volver a hacer clic en la casilla”. Deshacer es muy útil cuando hiciste clic accidentalmente en algún lugar, no sabes exactamente dónde, y no conoces la app lo suficiente como para revertirlo fácilmente solo viendo el mensaje.
Como ejemplo extremo, imagina que, mientras estabas de espaldas, una pelota rodó desde un estante, cayó y golpeó el teclado. ¿Cambió algo? ¿Qué cambió? ¿Cómo lo corriges?
Hay un solo caso en el que los toasts tienen sentido: cuando son notificaciones que no están relacionadas con la acción actual del usuario. Es algo parecido a las notificaciones de tipo sistema operativo que creó el desaparecido Growl.
La retroalimentación sobre una acción del usuario debe darse dentro del contexto de esa acción. Si es una acción asíncrona, ese hecho debe quedar claro, y la retroalimentación debe mostrar de inmediato que la tarea entró en la cola de procesamiento. En ese caso, la retroalimentación debe ofrecer opciones para cancelar, acceder a la cola y, mejor aún, ver el progreso.
Si quitaste una tarea de un tablero, no puedes mostrar sobre esa tarea la forma de deshacerlo. Puedes deshacer con un atajo de teclado, pero ¿cómo se enteraría visualmente el usuario?
Una lista de tareas debe contener solo tareas, así que no pondrías una nota en lugar de la tarea. Tampoco crearías algo como una tarea derivada que solo muestre un mensaje. Eso sería inyectarle a un componente de tarea una intención sin funcionalidad. Tampoco me gusta no avisarle nada al usuario. Es obvio que la tarea fue eliminada, pero no es obvio cómo revertir una acción inquietante que ocurrió con un solo clic. Y tampoco voy a pedir una confirmación molesta cada vez antes de borrar una tarea. Es una función central de la lista de tareas, así que debe ejecutarse de inmediato y poder deshacerse de inmediato.
Debe haber muchos casos especiales pequeños como este. Los toasts se inventaron por una razón. Que la gente haya abusado de ellos de forma simpática no significa que no sean concretamente útiles en ciertos escenarios.
Esas acciones no tienen contexto en pantalla y a menudo requieren una acción adicional. Incluso si no la requieren, claramente es útil confirmar que se detectó la acción del usuario.
Para quien se haya confundido: este artículo trata sobre un tipo de widget de UI [2], no sobre pan tostado [1].
[1] https://en.wikipedia.org/wiki/Toast_(food)
[2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)
Es la palabra más importante de la página, y está claro que incluso entre lectores técnicos hay gente que no entiende este término especializado.
Aunque quizá la participación subió gracias a lectores interesados en recetas de panadería y desayunos.
Sobre eso de que “el botón Undo en un toast es innecesario porque el usuario puede volver a hacer clic en la casilla”: yo agradezco muchísimo esa función. Innumerables veces pensé que había archivado un correo, pero el toast me avisó que en realidad había presionado el botón de reportar spam. Si no, jamás me habría enterado.
Otro problema de base de los toasts que el texto original pasa por alto es que las acciones web son asíncronas. No puedes saber si una acción tuvo éxito, falló o siquiera se registró en el servidor. Los toasts dan actualizaciones asíncronas sobre el estado del servidor.
Por supuesto, coincido en que algunos toasts son molestos, y que a veces tapan contenido importante de la UI y ni siquiera se pueden cerrar.
Así que si presionaste algo por error y de pronto el correo desapareció de la bandeja de entrada, necesitas un toast con un botón para deshacer. Si simplemente estás quieto y te apoyas sobre un botón y de pronto aparece un toast, agradecerás que exista. Idealmente, debería incluir una descripción de la acción realizada y un botón para deshacer.
En Gimp, si presionas Tab, se oculta toda la UI, y si no conoces el atajo no hay forma de revertirlo. Es una función deseable para artistas que quieren concentrarse en ver la imagen. Pero cuando lo presioné por accidente y tuve que buscar “gimp how to fix interface disappeared”, no saben cuánto deseé tener un toast con botón de undo. Ni me imagino cómo habría reaccionado alguien con poca experiencia en computadoras.
Los toasts pueden ser mala UX. Normalmente lo son cuando son la única retroalimentación, pero si se usan junto con otros elementos pueden ser excelentes.
Un toast de confirmación que aparece junto con una redirección de página sirve como una señal adicional de que el envío fue exitoso.
Un toast de advertencia o error junto con los indicadores estándar de validación de formularios es una excelente señal secundaria de que el usuario debe cambiar algo.
Si se implementa para capturar errores no especificados, puede preservar el estado de la página del usuario sin enviarlo a una página de error.
Si se usa como una herramienta más de la caja de herramientas, y no como la única herramienta, es una buena opción.
Hay algo peor que los toasts: los paneles deslizables ocultos. Básicamente son toasts ocultos, pero aunque son necesarios para ciertas acciones, no son nada intuitivos y no se pueden encontrar ni descubrir. La peor experiencia fue usando Waze en el teléfono de otra persona. Tenía que hacer algo, ya no recuerdo qué, y me quedé mirando la pantalla, tratando de adivinar qué tenía que hacer. Al final, esa persona tomó el teléfono y me mostró el panel oculto deslizándolo desde la derecha.
Entiendo que ahorran espacio, pero de verdad es absurdo. ¿Cómo espera un experto en UX que el usuario adivine eso? ¿Las UI de hoy están diseñadas pensando en gente que descubre cosas tocando por todos lados como un niño?
La app móvil de Discord antes usaba este método tanto para la sidebar izquierda como para la derecha, pero en algún momento a alguien se le ocurrió la brillante idea de que el gesto de “deslizar para responder” era más importante que la navegación de la app, y ahora para ver la sidebar derecha hay que tocar un botón pequeño y ambiguo.
En cuanto a los “paneles ocultos”, siempre pensé que eran un bug, aunque quizá alguien los consideró una buena idea.
Uso con frecuencia la app Apple Connect para administrar apps en la App Store. Si uso un iPad Mini en modo vertical y selecciono una de mis apps, muchas veces desaparece el botón para volver. Entonces no puedo seleccionar otra cuenta ni otra app dentro de la cuenta actual.
Hasta que giro físicamente el iPad a modo horizontal. Entonces aparece el navegador a la izquierda y puedo seleccionar otra app o cambiar de cuenta.
Sinceramente, me decepciona bastante toda la UX del backend de Apple App Store. El frontend tampoco me encanta, pero el backend es lo que uso todo el tiempo. Es bastante chocante si uno piensa en cuánto cuidado ponen en el resto de la experiencia de usuario de la plataforma.