Archive pour la catégorie ‘Web design’

5 types de notifications pour applications web

Par raphaelle, publié dans Applications web, Ergonomie, Web design le 12 mai 2010

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

Je 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.

Typographie, navigateurs et CSS

Par raphaelle, publié dans Web design le 19 mars 2010

Tags : css, Design, intégration, navigateur, texte, typographie

Récemment, alors que j’étais en phase d’intégration d’un site dont je venais de réaliser la maquette graphique, je me suis heurtée à quelques problèmes de rendu de typographie.

Il faut savoir que le site en question a un fond très foncé avec du texte clair, et que j’ai plus souvent conçu des sites clairs au texte foncé (meilleure lisibilité).

1er problème : rendu du texte plus gras sur mac

A ma grande surprise, mes titres en Palatino italisés apparaissaient en gras sur Mac. Je savais que sur Mac le texte était plus gras que sur Windows, ce que je ne savais pas c’est que l’écart est encore plus élevé quand le fond est foncé et le texte clair. En plus de ça chaque navigateur a un rendu un peu différent. Je n’étais pas prête à accepter une telle injustice donc je me suis lancée en quête d’une solution.

Je n’en ai pas trouvé à ce jour. Les différentes valeurs de font-weight (100, 200, … 900) ne servent à rien si la famille de police d’écriture ne contient pas suffisamment de variations, ce qui est souvent le cas. J’espérais trouver un moyen de tricher un peu avec de Javascript, sans succès.

Pour éviter ce genre de surprise, je vais peut-être essayer TypeKit sur le prochain projet. C’est une bibliothèque de polices d’écritures qui ne coûte pas cher (gratuit jusqu’à 2 polices pour un site) et qui est censée avoir un impact négligeable sur la performance du site. Cela me permettra de jouer sur les différentes variations d’une même police (extra light, light, roman, etc.).

2ème problème : rendu du letter-spacing

Dans Photoshop j’avais choisi de réduire l’espacement entre les lettres par -5 pour les titres. Dans ma feuille de style j’ai donc joué avec différentes valeurs de letter-spacing afin d’arriver à un résultat similaire. J’étais plutôt satisfaite de la valeur -0.02em. Sauf que ça ne marchait ni dans IE6 ni dans IE7, mais ce qui me dérangeait le plus était que ça ne marchait pas bien dans Chrome alors que le rendu devrait être le même que sur Safari (en théorie).

Je n’ai pas trouvé d’explication valable mais sur un forum on m’a proposé d’utiliser la valeur -1px au lieu d’une valeur relative en EMs et c’est l’option que j’ai choisie. J’utilise toujours des valeurs relatives pour le texte mais dans ce cas particulier j’estime que ça n’enlève rien à l’accessibilité du site.

Par contre sur la dernière version de Firefox pour Mac (3.6), les lettres de mes titres sont un peu trop serrées. A propos de Firefox, voici un article qui révèle quelques bugs qui varient d’une version de Firefox à l’autre. Mon problème pourrait en être un de plus.

Au final j’ai donc choisi la valeur -1px car elle rend bien sur la plupart des navigateurs. Après tout, peu de gens sont sur Firefox pour Mac et quand bien même ils utiliseraient ce navigateur, c’est tout à fait lisible.

Conclusion

Il faut accepter que les rendus seront un peu différents d’un navigateur à l’autre et que ça fait partie du jeu. En tant que designer web avec des qualités d’intégrateur, j’ai toujours envie que le site soit la réplique exacte de mon PSD, puisque c’est ce que le client a validé, cependant certains détails échapperont toujours à notre contrôle.

Quand on pense au temps que le designer passe à rendre son site « joli » dans tous les navigateurs, l’idée de travailler directement dans celui-ci fait sens. Nous explorerons cette idée dans le prochain article.