5 types de notifications pour applications web

Notification SoluoCRM

Aperçu de l’application SoluoCRM

 

Chez Soluo nous travaillons actuellement sur un projet d’application web. C’est dans ce cadre que je me suis penchée sur les différentes manières d’afficher des messages d’erreur, d’avertissement, d’information et de confirmation.

Les messages d’erreur sont probablement les plus connus, mais les autres types de notifications peuvent aussi être utiles. Parfois, on veut signaler à l’utilisateur que l’action qu’il a déclenché s’est déroulée comme prévue, car si rien ne se passe à l’écran, il peut croire qu’une erreur s’est produite et c’est très frustrant.

D’autres fois, une partie des actions ont réussi tandis que d’autres ont échoué. Il faut donc en informer l’utilisateur.

J’ai identifié 5 manières de présenter de telles informations au sein d’une interface web. Le souci est de savoir laquelle utiliser et dans quel cas. De plus, dans une application comme sur un site web, il faut faire preuve de cohérence : on évitera d’utiliser ces 5 styles de notifications sur une même interface, on risquerait de désorienter l’utilisateur.

1ère méthode : la zone unique de notification

C’est un emplacement, souvent situé en haut de l’interface, qui sert à afficher les notifications de tous types à travers l’application. Cette zone vient toujours se positionner à la même place. Si on décide de la situer dans le header, cela implique de la laisser vide en l’absence de notification. On peut aussi choisir de l’afficher sous le header de manière à ce qu’elle pousse le contenu vers le bas lorsqu’elle apparaît.
Exemple de zone unique de notification

Avantages : Participe à la cohérence de l’application car les messages sont toujours au même endroit. Il n’y a donc pas de surprise, et c’est une bonne chose. De plus, rien ne nous empêche d’utiliser cette approche et de la combiner avec la suivante dans certains cas.

Inconvénients : Quand l’utilisateur est descendu en bas d’une page longue, cette zone est alors masquée. Si on ne voit pas le message, on peut avoir l’impression que rien ne s’est passé. Si la page revient brusquement tout en haut afin que le message soit visible, cela peut être frustrant pour l’utilisateur que l’on a presque redirigé, sans lui demander son avis.

2ème méthode : les messages contextuels

Ce sont les messages que l’on positionne au sein même de la zone concernée. Le meilleur exemple est celui des formulaires. Si le formulaire ne valide pas car un champ comporte une erreur, on préférera mettre en valeur ce champ – en rouge par exemple – plutôt que de mettre un message générique en haut du formulaire. De cette manière l’utilisateur n’a pas trop d’effort à faire : il sait tout de suite ce qui s’est passé et comment rectifier le problème.

Pour faire encore mieux, on peut allier les méthodes 1 & 2 en mettant un message en haut de page avec les détails de l’erreur ET en faisant ressortir les champs à modifier.
Exemple de message contextuel

Avantages : Le message est positionné dans la zone de l’interface concernée, donc l’utilisateur a toutes les chances de le voir.

Inconvénients : Représente un peu plus de travail pour les développeurs et intégrateurs car chaque message est un peu « sur mesure ».

3ème méthode : la fenêtre modale

Elles sont très à la mode, surtout pour la présentation de galeries photo, mais aussi pour les notifications importantes. En général elles sont positionnées de manière centrale dans la fenêtre, avec un calque transparent en fond, signifiant ainsi que le reste de l’interface est désactivé.
Exemple de fenêtre modale (lui-même présenté dans une fenêtre modale)

Avantage : On peut être sûr que l’utilisateur va voir le message. Il y a une idée « d’urgence », ou du moins à une situation critique qu’il faut examiner de plus près.

Inconvénient : C’est une approche assez agressive car on empêche l’utilisateur d’interagir avec le reste de l’application. De plus, on l’oblige à prendre une décision, sans quoi il ne peut pas se débarrasser de la fenêtre. Bref, il ne faut pas abuser des fenêtres modales.

4ème méthode : la boite de dialogue

Par boite de dialogue, j’entends « l’alert box » du navigateur. Elle s’apparente à la fenêtre modale car elle requière une action de la part de l’utilisateur. Par contre le web designer n’a aucun contrôle sur son aspect visuel et son positionnement : cette boite appartient à l’interface du navigateur plutôt qu’à celle de l’application web ou site web.
Exemple de boite de dialogue

Avantages : Le sentiment d’urgence et de gravité qu’elle procure si utilisée avec parcimonie.

Inconvénient : C’est encore plus intrusif qu’une fenêtre modale : on l’associe plus à une « erreur fatale ». Son utilisation est troublante quand il s’agit de communiquer un message purement informatif ou de confirmation car on s’attend à un message d’une certaine gravité.
Contrairement à la fenêtre modale, la boite de dialogue peut passer inaperçue : le reste de l’interface est désactivé mais ce n’est pas mis en évidence visuellement.
Vous l’aurez compris, je n’ai pas beaucoup d’affection pour ce mode de notification et je ne vois pas très bien où il a sa place sur le web.

5ème méthode : les notifications de type « Growl »

Ce sont ces messages qui apparaissent assez discrètement dans un coin de l’écran ou de la fenêtre. Parfois ils disparaissent d’eux-même au bout de quelques secondes, d’autres fois il faut cliquer sur un bouton pour les fermer. Ces notifications se superposent donc à l’interface de manière plutôt subtile.
Voir la démo d’un plugin de type « Growl »

Avantages : Ce système permet d’afficher des messages dans une même zone de la fenêtre quelle que soit la longueur de la page. Cela résout donc le problème de la 1ère méthode où le message peut être masqué si on est en bas de page. Ce type de notification permet de discrètement afficher des messages informatifs et n’empêche pas l’utilisation du reste de l’interface.

Inconvénients : Si on utilise ce système pour des notifications importantes, on risque de ne pas les voir ou de ne pas comprendre l’urgence du message car leur positionnement dans la page n’est pas contextuel. De plus il y a des zones auxquelles nous faisons moins attention (en bas à gauche/droite).

Alternative aux notifications intrusives

deleteJe suis arrivée à la conclusion que toutes ces méthodes – à part peut être la boite de dialogue – sont des solutions valides, mais qu’il faut savoir utiliser au bon moment.

Les solutions intrusives telles que les fenêtres modales et les boites de dialogue sont à utiliser le moins possible, car leur problème est justement… qu’elles sont intrusives.
Et si on pouvait s’en passer complètement ?

En lisant le chapitre « Notifying and Confirming » du livre About Face 2.0, The essentials of interaction design (Alan Cooper & Robert Reimann, Wiley Publishing, 2003), j’ai réalisé qu’il y avait presque toujours une alternative au message intrusif.

Par exemple, si l’utilisateur clique sur un bouton « supprimer » afin d’effacer un document de l’application, pourquoi afficher une fenêtre modale lui demandant de confirmer l’action à effectuer ? Dans 95% des cas, la personne veut vraiment effacer le document. Lui demander de confirmer cette action peut instiguer le doute et créer un certain stress. Par ailleurs, si la même fenêtre apparaît à chaque fois que l’utilisateur souhaite effacer quelque chose, il risque d’y être tellement habitué qu’il va machinalement cliquer sur « OK ».

Mieux vaut donc effacer le document sans rien demander, mais en donnant après coup la possibilité de le restaurer. Gmail fait ça très bien ; il m’arrive parfois de sélectionner un email et de cliquer sur « signaler comme spam » au lieu d’un autre bouton. Aussitôt l’action effectuée, la possibilité de l’annuler est bien visible dans la zone de header, sur fond jaune.

Cette manière de faire est beaucoup plus pertinente car elle traite des cas rares – ces 5% – où l’utilisateur s’est trompé, au lieu d’ajouter une étape pour les 95% des cas où tout se passe comme prévu.

Il faut tout de même savoir que la création d’une fonction « annuler » peut représenter une tonne de travail pour les développeurs. Il peut donc être plus rentable de s’en passer. Par exemple, permettre d’annuler la suppression d’un document est assez simple. En revanche, si l’élément à supprimer est relié à d’autres éléments, tout se complique.

Exprimez vous!

*