Combien de temps une notification temporaire (toast) doit-elle apparaître?
Pour notre application intranet, nous avons de petits messages de notification (toasts) qui indiquent des opérations réussies comme "informations enregistrées", "déconnecté", etc. La plupart d'entre elles ne sont pas assez importantes pour nécessiter une opération modale (comme les fenêtres "cliquez pour fermer" de Stack Exchange ) afin qu'ils se ferment automatiquement après 2500 ms et j'essaie de les perturber le moins possible l'utilisateur. Ils sont cependant importants à présenter, car les utilisateurs doivent confirmer qu'une action a réussi, car elle peut faire partie d'un flux de travail répétitif ou complexe.
Je veux m'assurer qu'elles sont lisibles et compréhensibles dans les délais, donc je me demandais s'il y avait des recherches sur le temps qu'il faut aux gens pour lire les informations, en particulier dans un contexte de style "pop up". Ce n'est pas en fait une fenêtre contextuelle, plus comme la barre de notification de SE, mais elle disparaît automatiquement. Si je pouvais dire combien de temps attendre la lecture, cela aiderait à régler la durée du message et la longueur des messages.
Pour ce que ça vaut - j'ai moi-même essayé une variété de timings et je me suis retrouvé à 3200 ms pour un message de deux lignes pouvant contenir jusqu'à 20 mots. Mais je place également un petit point (10px de diamètre) à gauche, qui est coloré selon le type de message (par exemple rouge/erreur, bleu/info, orange/avertissement) et qui s'estompe au cours des 3200 ms. Lorsque le fondu atteint 100%, le message lui-même disparaît rapidement. Les utilisateurs ont dit qu'ils l'appréciaient car cela rend le message légèrement plus visible sans être trop distrayant et cela le rendait moins "surprenant" lorsque le message disparaît.
Cela varie, mais pour la langue anglaise ...
Généralement, le temps de lecture d'un avis flash varie en fonction de la complexité des informations, de la durée de l'avis et du niveau de concentration/distraction de l'utilisateur.
Cela dit, j'ai tendance à utiliser l'approche éclairée suivante:
1. Les avis flash doivent être courts
- Si un avis dépasse 1,5 ligne, il est probablement trop long pour un rejet automatique. Dans ces cas, réexaminez le contenu et déterminez si vous souhaitez l'afficher de manière modale (par exemple dans une boîte de dialogue que l'utilisateur ferme manuellement) ou via un changement d'écran (par exemple, amener l'utilisateur vers une nouvelle page contenant les informations)
2. J'utilise généralement la formule suivante:
La formule correcte est min (max (toast.message.length * 50, 2000), 7000)
- Ce n'est pas une science exacte, mais cela a fonctionné pour moi et il est raisonnablement soutenu par des données ergonomiques ...
En gros, la logique est la suivante:
- Afficher l'animation de 200 à 400 ms est à peu près cohérent avec le temps de saccade pour que l'œil se recentre sur un nouvel endroit à l'écran.
- La durée d'affichage de 50 ms x nombre de caractères correspond à peu près à la vitesse de lecture de l'utilisateur. Le lecteur moyen en anglais lira environ 250-300 mots par minute , avec une moyenne de 5,8 caractères par mot (espaces compris). À une estimation "sûre" pour un avis de 200wpm, cela donne environ 1 caractère toutes les 50 millisecondes .
- J'applique un 2000 ms minimum pour permettre à l'utilisateur de changer de contexte de manière congénitale même pour de courtes notifications, et un 7000 ms maximum parce que j'ai trouvé que les tests sont à peu près corrects pour le seuil sur lequel l'avis ne devrait vraiment pas être un avis flash (voir le point # 1 ci-dessus).
Animation de fondu de 700-2000 ms . L'animation de fondu est plus lente que l'animation de spectacle, car elle donne aux utilisateurs le temps de terminer la lecture ou d'agir (par exemple, cliquez pour empêcher le licenciement) s'ils ne sont pas encore terminés. Les utilisateurs se sentent très frustrés s'ils sont à mi-chemin de la lecture de quelque chose et cela disparaît soudainement avant de pouvoir faire quoi que ce soit.
Vous devrez l'adapter à votre situation spécifique, mais le cadre général peut être utile.
Je suis surpris que personne n'ait signalé cela comme un problème d'accessibilité. Je vous recommande d'éviter tout message chronométré car vous ne pouvez pas déterminer combien de temps il faut à quelqu'un non seulement pour lire le message, mais aussi pour le comprendre.
Recommandation: inclure un bouton "Ignorer" pour permettre aux utilisateurs de fermer l'alerte à leur propre rythme.
Source: http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits.html
Je suggérerais que toute notification auto-show-auto-hide ne devrait contenir qu'une courte phrase, ou tout au plus une courte phrase. Nous utilisons ces petites bulles qui se glissent dans et en arrière après qu'un utilisateur clique sur un bouton d'enregistrement et il réussit simplement dire "enregistré". Ils s'affichent pendant environ deux secondes et demie et donnent à l'utilisateur la rétroaction non modale dont il a besoin pour savoir que cliquer sur le bouton a fait quelque chose.
Maintenant, un message d'erreur où une action des utilisateurs n'a pas produit de résultat devrait probablement être un peu plus important ou nécessiter un accusé de réception. Je ne dis pas de les rendre modaux, mais peut-être de faire en sorte que l'utilisateur le x ou quelque chose. Il en va de même pour un long message. Si je suis occupé à faire quelque chose dans l'application et qu'une petite fenêtre apparaît, je vais probablement le regarder, mais seulement après avoir terminé ce que je fais. Si c'est parti au moment où je vais le regarder, je ne serai probablement pas très réconforté par cela.
Sur l'intranet de mon client, nous utilisons 3 secondes pour les courts messages de confirmation et d'erreur, et environ 5 secondes pour les messages plus longs (en gardant à l'esprit que plus longtemps ne peut pas être aussi long).
Ce qui a attiré mon attention, c'est ce que vous avez dit que vous vouliez que l'utilisateur soit le moins perturbé possible. Sur notre intranet, sur la publication de formulaires pour les éditeurs, car ils verront beaucoup de messages de confirmation, nous avons permis qu'en cliquant sur Echap, le message disparaisse immédiatement. Comme ils ont tendance à utiliser des claviers et des onglets lors de la publication, Esc sera optimal lorsqu'ils tabulent + cliquent sur Enregistrer.
Quelques suggestions pour afficher "Fenêtre de notification temporaire" 1. Le temps devrait être suffisant pour qu'une personne normale puisse lire le message en entier. 2. Le message ne doit pas s'éteindre lorsque l'utilisateur garde le pointeur de sa souris dessus, cela montre que l'utilisateur se concentre sur cela. 3. Lorsque la fenêtre disparaît, elle ne devrait pas être brusquement animée lentement. 4. le message doit être simplement écrit en texte clair et doit être précis.
Cela dépend toujours du nombre de mots contenus dans la notification. Si les mots vont de 5 à 10, 3 secondes suffisent et que les mots vont de 10 à 20 mots, il vaudra mieux qu'il soit visible pendant 5 secondes.