- La principale faiblesse des notifications toast est que le point d’attention de l’utilisateur et l’emplacement du feedback sont séparés, ce qui rend difficile d’associer immédiatement le résultat à l’action qui vient d’être effectuée
- Dans le flux d’enregistrement de YouTube, le regard passe du bouton Save à droite, à une modale au centre, puis à un toast en bas à gauche, ce qui interrompt l’interaction, sans indicateur de chargement pendant le délai
- Après avoir modifié une case à cocher, il faut attendre que le toast précédent disparaisse pour voir le dernier message de confirmation, et le bouton Undo du toast est inutile dans une situation où il suffit de cliquer à nouveau sur la case
- Une meilleure approche consiste à placer le feedback à l’endroit de l’action : afficher les playlists sous le bouton et montrer l’état d’avancement avec un indicateur de chargement pendant la modification des cases à cocher
- Pire qu’un toast, il y a l’absence totale de feedback ; donc, si vous n’avez pas le temps de concevoir ou d’implémenter un meilleur feedback, un toast vaut mieux que rien
Le problème de base des toasts
- Les notifications toast apparaissent généralement loin de l’endroit où se porte l’attention de l’utilisateur
- Quand le feedback apparaît à un autre endroit que le bouton qui vient d’être cliqué ou la zone en cours de modification, l’utilisateur a du mal à comprendre le lien entre l’action et le résultat
Les problèmes du flux d’enregistrement de YouTube
- Dans l’exemple de YouTube, après avoir cliqué sur le bouton Save à droite de l’écran, l’utilisateur voit successivement une modale au centre de l’écran puis un toast en bas à gauche
- Ce flux force le regard à se déplacer à plusieurs endroits et rend le feedback difficile à comprendre immédiatement
- Le toast est retardé sans indicateur de chargement
- Quand on coche ou décoche une case dans la modale, il faut attendre plusieurs secondes que le toast précédent disparaisse pour voir le dernier toast de confirmation
- Le bouton Undo du toast est inutile, puisque l’utilisateur peut simplement cliquer à nouveau sur la case à cocher
Comment résoudre le problème sans toast
- Une simple refonte suffit à gérer le même feedback sans toast
- Afficher les playlists directement sous le bouton, plutôt que dans une modale
- Afficher un indicateur de chargement pendant que l’on coche ou décoche une case
- Quand l’indicateur de chargement disparaît, l’utilisateur comprend naturellement que l’action est terminée
- Comme le feedback reste à l’endroit que l’utilisateur a manipulé, aucun toast séparé n’est nécessaire
Exemples de Gmail et de feedback de copie
- Dans Gmail, lorsqu’un e-mail est archivé, un toast de confirmation apparaît
- Mais le simple fait que l’e-mail disparaisse de la liste suffit déjà à indiquer que l’archivage a réussi
- En revanche, pour la fonction Annuler et l’utilisation de raccourcis clavier, le feedback par toast peut être utile
- Il existe aussi des cas où un toast s’affiche après la copie d’un élément dans le presse-papiers
- Dans l’exemple, le bouton lui-même inclut déjà l’état de confirmation, ce qui rend le toast totalement inutile
Il faut tout de même du feedback
- Pire qu’un toast, il y a l’absence totale de feedback
- Si vous n’avez pas le temps de concevoir ou d’implémenter un meilleur mécanisme de feedback, un toast vaut mieux que rien
Comment Cakedesk évite les toasts
- Cakedesk est une application de facturation offline-first, sans abonnement, qui permet d’envoyer des e-mails depuis l’application
- Plutôt que de donner un feedback via un toast après l’appui sur le bouton Send d’un e-mail, l’interface est conçue pour que le changement d’état reste dans le même flux
- Les factures non envoyées affichent un bouton Send dans la liste
- Pendant l’envoi de l’e-mail, la modale reste ouverte et le bouton de soumission indique l’état d’envoi en cours
- Si l’envoi réussit, l’e-mail est animé vers l’extérieur de l’écran, indiquant que l’envoi est terminé
- Dans la liste, le bouton Send devient une case à cocher Paid, confirmant que l’e-mail a été envoyé et menant à la prochaine action utile
- L’utilisateur peut aussi vérifier si l’e-mail a été envoyé en appuyant sur le bouton contextuel
2 commentaires
Donc, c’est bien que les mauvais toasts sont mauvais, c’est ça ??
Avis de Hacker News
https://en.wikipedia.org/w/index.php?title=Toast_(computing)
Pas convaincu. La plupart de l’argumentaire semble dire que l’UX redondante est une mauvaise UX.
J’ai du mal à être fortement d’accord avec les exemples selon lesquels, quand on archive un e-mail, il disparaît de la liste et suggère donc déjà le succès, ou qu’une coche sur un bouton rend le toast inutile. Transmettre la même information simultanément de différentes manières n’est pas un bug, c’est une fonctionnalité, et cela existe dans tout le langage humain. Parce que cela permet au message de passer même dans des conditions qui ne sont pas idéales.
Les toasts indiquent l’état de toutes les actions selon une méthode standard unique et, si possible, proposent même d’annuler l’action, ce qui permet à l’utilisateur d’apprendre rapidement le schéma. Des indicateurs supplémentaires près de l’action ont aussi de la valeur, mais leur sens devient souvent clair lorsqu’ils sont accompagnés d’un toast. Si l’on supprime les toasts et qu’on les remplace par plusieurs indicateurs spécifiques, l’utilisateur doit apprendre, uniquement à partir du contexte, plusieurs façons de dire « c’est terminé ». Cela peut être particulièrement mauvais pour les personnes âgées, les personnes malvoyantes et les enfants.
Tant qu’ils ne gênent pas réellement, les toasts ne sont pas une mauvaise UX, mais une UX redondante, et les designers UX ne devraient pas être obsédés par l’élimination de la redondance.
Dans l’exemple de YouTube, la case cochée est à 100 % une mise à jour optimiste, tandis que la notification toast signifie que la requête envoyée de manière asynchrone au backend a réussi. Il en va de même pour l’archivage d’un e-mail : le message est retiré de la liste de façon optimiste, et le toast indique qu’il a effectivement été archivé.
Je préférerais recevoir un toast uniquement lorsque le commit de la modification échoue. En général, quand un toast surgit, il détourne mon attention de ce que j’essaie de faire, et s’il est visuellement éloigné de l’endroit où l’action a eu lieu, c’est encore plus distrayant.
Il faut placer le message là où l’attention de l’utilisateur est déjà dirigée. Puisque l’UI a guidé mon regard vers cet endroit, c’est là qu’il faut l’afficher.
La leçon est qu’il ne faut pas envoyer à l’utilisateur des informations qui ne sont pas strictement nécessaires.
Pour aller plus loin :
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
Dans le pire des cas, les toasts ont du sens comme solution de dernier recours pour transmettre quelque chose à l’utilisateur sans contexte. Par exemple, si l’utilisateur décoche une playlist, ferme la liste des playlists pendant l’enregistrement, puis que l’enregistrement échoue, le contexte de l’action a disparu ; il est alors compréhensible d’afficher un toast quelque part à un emplacement arbitraire de l’écran.
Même ainsi, si l’on veut que l’utilisateur comprenne correctement l’erreur, il est très probable qu’un toast ne soit pas la meilleure option. Dans une application financée par la publicité comme YouTube, où l’utilisateur est le produit, le fait que l’utilisateur manque ce type d’erreur peut ne pas beaucoup importer, voire être souhaité ; mais dans une application professionnelle, on ne voudrait pas parier sur le fait que l’utilisateur ne manquera pas le toast ou ne le confondra pas avec une autre erreur. En général, il est plus utile de rouvrir l’élément concerné pour l’utilisateur et d’afficher l’erreur dans son contexte. On pourrait ouvrir la liste des playlists et utiliser une animation pour attirer l’attention sur le fait que la modification n’a pas été enregistrée. C’est peut-être un idéal difficile à mettre en œuvre de manière systématique, mais idéalement, on devrait toujours voir les erreurs dans leur contexte.
Le pire, c’est que les toasts disparaissent trop vite et attirent inutilement l’attention même pour des actions dont la réussite devrait aller de soi. Les deux combinés sont particulièrement agaçants. L’attention est détournée sans nécessité, mais le message disparaît trop vite pour qu’on sache s’il contenait réellement quelque chose d’important. À l’inverse, il existe aussi des variantes qui restent trop longtemps et masquent une partie de l’UI qu’on voulait consulter ou utiliser tout de suite.
La méthode classique des applications desktop est préférable : afficher les messages d’erreur en modal pour qu’ils ne soient pas manqués, et les messages de succès sous forme de texte ordinaire, non intrusif, dans une barre d’état toujours visible et sans limite de temps. En l’absence de modal d’erreur, l’utilisateur peut supposer que l’action a réussi ; s’il a besoin de vérifier, il peut le faire dans la barre d’état sans pression temporelle. On peut aussi y inclure des informations supplémentaires.
Certaines apps affichent aussi l’historique des messages de la barre d’état dans une fenêtre pop-up. Dans ce modèle, la barre d’état ressemble à la dernière ligne de sortie d’un terminal en ligne de commande, avec la possibilité de consulter les sorties précédentes.
Il m’arrive souvent d’aller dans les notifications pour retrouver ce que j’ai manqué. Le message semblait important, mais je n’ai pas eu le temps de le lire en entier. Là, quand je clique sur un élément qui ressemble à un message tronqué, je m’attends à être redirigé vers le contexte complet ; en réalité, la notification disparaît, l’app s’ouvre simplement, sans deep link vers le problème en question. Il faut alors fouiller dans l’UI standard de l’app pour trouver un problème qui peut être visible… ou pas.
J’ai vécu ça un nombre incalculable de fois, et à chaque fois cela me met en colère contre la personne qui a conçu ce système.
J’ai eu ce problème aujourd’hui avec mon fils. Il est en train de s’exercer à lire plus vite et nous utilisions ensemble une nouvelle app ; les toasts n’arrêtaient pas d’apparaître, il avait du mal à suivre et cela le déconcentrait. J’ai fini par devoir les lui lire à voix haute. Avec des messages restant affichés plus longtemps, il aurait sans doute pu réussir sans aide supplémentaire.
YouTube offre un meilleur exemple.
Allez sur https://www.youtube.com/feed/history, cliquez sur « Comments » à droite, puis supprimez un commentaire : un toast apparaît pour indiquer que la suppression est prévue, puis, une ou deux secondes plus tard, un autre toast indique que la suppression a été effectuée.
Si vous supprimez rapidement plusieurs commentaires à la suite, plusieurs toasts de suppression prévue apparaissent d’abord, puis, après un délai d’une ou deux secondes, chaque toast de confirmation apparaît dans l’ordre. Comme la suppression réelle se fait aussi séquentiellement, il faut attendre tous les toasts de confirmation. Même si vous avez cliqué sur 10 commentaires en 2 ou 3 secondes, les confirmations prendront plus de 10 secondes.
C’est pareil pour les commentaires en direct :
https://myactivity.google.com/page?page=youtube_live_chat&co...
Je ne suis généralement pas d’accord avec l’idée selon laquelle « le bouton Undo d’un toast est inutile parce que l’utilisateur peut simplement recliquer sur la case à cocher ». Quand on a cliqué quelque part par erreur sans savoir exactement où, et qu’on ne connaît pas assez bien l’app pour annuler facilement en se fiant uniquement au message, l’annulation est très utile.
Exemple extrême : imaginons qu’une balle roule d’une étagère et tombe sur le clavier pendant qu’on a le dos tourné. Quelque chose a-t-il changé ? Qu’est-ce qui a changé ? Comment le corriger ?
Les toasts n’ont de sens que dans un seul cas : lorsqu’il s’agit d’une notification sans rapport avec l’action en cours de l’utilisateur. Un cas similaire aux notifications de type OS que Growl, aujourd’hui disparu, avait popularisées.
Le feedback sur une action de l’utilisateur doit se faire dans le contexte de cette action. Si l’action est asynchrone, cela doit être clair, et le feedback doit montrer immédiatement que la tâche correspondante a été placée dans une file d’attente de traitement. Dans ce cas, le feedback devrait offrir la possibilité d’annuler, d’accéder à la file d’attente et, mieux encore, de voir la progression.
Si vous supprimez une tâche d’un tableau, vous ne pouvez pas afficher sur cette tâche un moyen de l’annuler. On peut annuler via un raccourci clavier, mais comment l’utilisateur le saurait-il visuellement ?
Une liste de tâches ne doit contenir que des tâches, donc on ne va pas y mettre une note à la place d’une tâche. On ne va pas non plus créer une sorte de tâche dérivée qui ne servirait qu’à afficher un message. Ce serait injecter une intention sans fonctionnalité dans le composant de tâche. Je n’aime pas non plus l’idée de ne pas informer du tout l’utilisateur. Le fait que la tâche ait été supprimée est évident, mais la manière d’annuler une action anxiogène effectuée en un clic ne l’est pas. Et je ne vais pas non plus demander une confirmation agaçante à chaque suppression de tâche. C’est une fonction centrale de la liste de tâches : elle doit être immédiate et immédiatement annulable.
Il y a sans doute beaucoup de petits cas particuliers de ce genre. Les toasts ont été inventés pour une raison. Le fait que des gens en aient abusé parce que c’était mignon ne signifie pas qu’ils ne soient pas concrètement utiles dans certains scénarios.
Ces actions n’ont pas de contexte à l’écran et nécessitent souvent une action supplémentaire. Même lorsqu’il n’y en a pas, confirmer que l’action de l’utilisateur a été détectée est clairement utile.
Pour ceux qui étaient perplexes : cet article ne parle pas de pain grillé [1], mais d’un type de widget d’UI [2].
[1] https://en.wikipedia.org/wiki/Toast_(food)
[2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)
C’est le mot le plus important de la page, et il est clair que même parmi les lecteurs techniques, certains ne comprennent pas ce terme spécialisé.
Cela dit, les lecteurs intéressés par la boulangerie et les recettes de petit-déjeuner ont peut-être augmenté l’engagement.
À propos de « le bouton Annuler d’un toast est inutile, puisque l’utilisateur peut simplement cliquer de nouveau sur la case à cocher » : j’apprécie tout particulièrement cette fonction. Il m’est arrivé un nombre incalculable de fois de penser avoir archivé un e-mail, puis que le toast m’informe que j’avais en fait appuyé sur le bouton de signalement comme spam. Sans cela, je ne l’aurais jamais su.
Un autre problème fondamental des toasts que l’article original a manqué, c’est que les actions sur le Web sont asynchrones. On ne sait pas si l’action a réussi, échoué, ni même si elle a été enregistrée sur le serveur. Le toast fournit une mise à jour asynchrone sur l’état côté serveur.
Bien sûr, je suis d’accord pour dire que certains toasts sont pénibles, et qu’il arrive qu’ils masquent des éléments importants de l’UI sans même pouvoir être fermés.
Donc si vous cliquez accidentellement sur quelque chose et qu’un e-mail disparaît soudain de votre boîte de réception, vous avez besoin d’un toast avec un bouton d’annulation. Si vous ne faites rien et que votre corps s’appuie sur un bouton, puis qu’un toast apparaît soudain, vous serez content qu’il soit là. Idéalement, il devrait inclure une description de l’action effectuée et un bouton d’annulation.
Dans Gimp, appuyer sur Tab masque toute l’UI, et si l’on ne connaît pas le raccourci, il n’y a aucun moyen évident de revenir en arrière. C’est une fonction souhaitable pour les artistes qui veulent se concentrer sur l’image. Mais la fois où j’ai appuyé dessus par erreur et dû chercher « gimp how to fix interface disappeared », je ne saurais dire à quel point j’aurais voulu un toast avec un bouton d’annulation. Je n’ose même pas imaginer la réaction de quelqu’un peu à l’aise avec l’informatique.
Les toasts peuvent être une mauvaise UX. C’est généralement le cas lorsqu’ils sont le seul feedback, mais utilisés avec d’autres éléments, ils peuvent être excellents.
Un toast de confirmation affiché en même temps qu’une redirection de page est un bon indicateur supplémentaire que l’envoi a réussi.
Un toast d’avertissement ou d’erreur affiché avec les indications standard de validation de formulaire devient un excellent signal secondaire indiquant à l’utilisateur qu’il doit modifier quelque chose.
Implémenté comme mécanisme fourre-tout pour les erreurs non spécifiées, il permet de préserver l’état de la page de l’utilisateur sans l’envoyer vers une page d’erreur.
Utilisé comme un outil parmi d’autres dans la boîte à outils, et non comme unique outil, c’est une bonne option.
Il y a pire que les toasts : les panneaux coulissants cachés. Ce sont, en gros, des toasts cachés, dont certaines actions ont besoin, mais qui ne sont absolument pas intuitifs et qu’on ne peut ni trouver ni découvrir. Ma pire expérience, c’était en utilisant Waze sur le téléphone de quelqu’un d’autre. Je devais faire quelque chose, je ne me souviens plus quoi, et je suis resté à fixer l’écran en essayant de deviner quoi faire. Au final, la personne a repris son téléphone et m’a montré un panneau caché en le faisant glisser depuis la droite.
Je comprends l’idée de gagner de la place, mais c’est vraiment absurde. Comment un expert UX peut-il s’attendre à ce que l’utilisateur le devine ? Les UI d’aujourd’hui sont-elles conçues en partant du principe que les gens vont les découvrir en tapotant partout comme des enfants ?
L’app mobile de Discord utilisait autrefois ce fonctionnement pour les sidebars gauche et droite, jusqu’à ce qu’à un moment quelqu’un ait la brillante idée que le geste « faire glisser pour répondre » était plus important que la navigation dans l’app ; désormais, pour voir la sidebar droite, il faut appuyer sur un petit bouton ambigu.
Quant aux « panneaux cachés », j’ai toujours pensé que c’étaient des bugs, mais quelqu’un a peut-être trouvé que c’était une bonne idée.
J’utilise souvent l’app Apple Connect pour gérer des apps sur l’App Store. Quand j’utilise un iPad Mini en mode portrait et que je sélectionne l’une de mes apps, le bouton de retour disparaît souvent. Je ne peux alors plus choisir un autre compte ni une autre app dans le compte actuel.
Jusqu’à ce que je tourne physiquement l’iPad en mode paysage. Là, le navigateur apparaît à gauche, et je peux sélectionner une autre app ou changer de compte.
Franchement, je suis assez déçu par toute l’UX du backend de l’Apple App Store. Le frontend ne m’enthousiasme pas non plus, mais le backend, c’est ce que j’utilise tout le temps. C’est assez surprenant quand on pense à toute l’attention portée au reste de l’expérience utilisateur sur la plateforme.