Jakob Nielsen à propos des liens applicatifs et du web 2.0

Cette semaine Jakob Nielsen, le grand gourou de l’utilisabilité, s’illustre avec ces deux articles :

  • Web 2.0 ‘neglecting good design’, où il nous explique que la plupart des start-up du web 2.0 négligent les principes essentiels de l’utilisabilité (simplicité, intuitivité…) ;
  • Command Links, où il est question de l’utilisation propice des liens et des boutons.

C’est sur ce dernier point que je souhaite insister : les liens servent pour naviguer, les boutons servent à réaliser des actions. Voilà en substance la point de vue de Jakob Nielsen (que je partage entièrement).

Mais là où ça devient intéressant c’est que ce dernier fait preuve d’une étonnante souplesse en préconisant l’utilisation de command link (liens applicatifs ?) et ceci pour plusieurs raisons :

  • ils sont utilisés dans la nouvelle interface de Windows Vista ;
  • ils prennent peu de place et sont utiles pour les actions qui sont longues à décrire (4 mots et plus) ;
  • ils sont très faciles à mettre ne oeuvre et à modifier ;
  • ils doivent cependant être restreint aux actions réversibles (édition, ajout).

Voilà une position pleine de sagesse, et il faut reconnaitre que ces command links sont bien utiles pour éviter de saturer une interface. Si vous prenez l’exemple de BaseCamp (l’application en ligne de gestion de projet que j’utilise), il faut bien reconnaitre que ces liens fonctionnent parfaitement :

CommandLinks

Petit conseil : essayez donc d’enjoliver vos liens applicatifs avec un traitement graphique proche de celui des boutons (comme ici : Rediscovering the Button Element ou là : 3D CSS buttons).

Un commentaire sur “Jakob Nielsen à propos des liens applicatifs et du web 2.0

  1. Euh… c’est quoi des command links ? Ca ressemble à quoi ? L’exemple barcamp, ok, mais ils sont où ? rogé le boulé

  2. Je pense que Jakob Nielsen appelle « command link » des liens tout à fait normaux à l’execptions près qu’ils éxécutent une action (ce qui n’est pas le rôle d’un lien). Il accepte donc les entorces à son premier point si ces liens éxécutent des actions réverssibles. Attention toutefois, certains logiciels préchargent les liens d’une page, vous pourriez vous retrouver avec des paniers rempli de produits sans que l’utilisateur n’est cliqué une seule fois sur le lien acheter.

  3. Pareil, j’ai pu lire l’article de l’ami jacobi, j’ai pas tout compris à ces « command link », j’esperais avoir une definition ici … maieuhhh … vous allez cracher le morceau ? A moins que ca ne soit tout simplement des liens classiques mais qui servent à réaliser des actions ?

  4. Je pense que Jakob Nielsen appelle « command link » des liens tout à fait normaux à l’execptions près qu’ils éxécutent une action (ce qui n’est pas le rôle d’un lien). Il accepte donc les entorces à son premier point si ces liens éxécutent des actions réverssibles. Attention toutefois, certains logiciels préchargent les liens d’une page, vous pourriez vous retrouver avec des paniers rempli de produits sans que l’utilisateur n’est cliqué une seule fois sur le lien acheter.

  5. Hum, les boutons pourquoi pas, mais s’ils ont trop de texte, cela devient ridicule. Et puis sur l’exemple de Basecamp, les deux actions proposées en page d’accueil sont des liens écrits en plus gros que le reste du texte.

  6. J’ai du mal à saisir le sujet… Ca m’a l’air intéressant mais il faudrait que tu explicites un peu ce que sont ces command links ! (liens d’actions ?) Et si leur intérêt est d’être plus simple graphiquement (cf. « éviter de surcharger une interface ») que les boutons… Pourquoi proposes-tu de les habiller comme des boutons ? :-)

  7. Voilà, j’ai rajouter une capture d’écran. @ Stéphane > L’intérêt de traiter graphiquement les liens comme des boutons est de profiter de leur simplicité de mise en oeuvre mais de conserver l’intuitivité des boutons (on a envie de cliquer dessus). Mais bon, c’est une option à prendre ou pas. /Fred

  8. Il y a un bête règle qui résume ce que Jacob Nielsen vient de développer : « GET should be safe ». Une requête HTTP GET ne doit pas modifier les données. Sachant qu’un lien fait génère une requête GET (sauf horrible bidouille javascript malheureusement trop courante), il en découle que tout ce qui modifie les données doit être déclenché par un bouton de formulaire (méthode POST, voire PUT ou DELETE). Concernant le style, on peut aussi faire ressembler des boutons à des liens, même si ça a tendance à moins bien marcher.

  9. Si je peux me permettre et, au vu des commentaires, pas mal de personnes ne semblent pas avoir bien compris la différence entre un lien applicatif et un lien tout court. L’obsession de Nielsen est de toujours rendre la plus simple et la plus compréhensible une interface utilisateur, que cela s’applique au web ou pas. Tenant compte de ce fait, il faut bien comprendre qu’un lien hypertexte (texte avec une balise <a href> autour) ne doit et ne devrait servir qu’à emmener un utilisateur vers une autre page du web sans déclencher aucun processus (insertion de champs dans une base de données, ajout d’un favori ou bien, validation d’un formulaire), tandis qu’un bouton ne devrait servir qu’à valider un processus. Mais ceci n’est qu’une convention et n’est pas toujours respecté. Pour valider un processus « Ajouter à mes favoris », les concepteurs de site utilisent souvent un lien hypertexte, ce qui est contraire à la règle de Nielsen. La nouveauté ici, c’est qu’il préconise également d’utiliser des liens hypertextes (nommés alors « liens applicatifs ») pour « valider/annuler » des processus, comme l’exemple que tu as montré dans BaseCamp. Il est vrai que la différence est subtile, mais il est vrai que Windows fait une utilisation extensive de ces « liens applicatifs » et que cela fonctionne bien dans l’esprit des gens (en tout cas, dans le mien, ce qui est déjà pas mal). Autrement dit, un « lien applicatif » est un lien hypertexte qui agit comme un bouton, mais dont l’importance dans la hiérarchie visuelle d’une page ne nécessite pas un impact aussi fort que le graphisme 3D d’un bouton. Bon, je ne sais pas si tout ça est très clair, il faudrait trouver des exemples.

  10. Jacob Nielsen a connu ses heures de gloire … mais là franchement ce qu’il raconte est d’un creux assez lénifiant. On dirait un pappy qui vit dans un home déconnecté de ce qui s’est passé depuis quelques années. Certains sites comme MySpace peuvent évidemment collecter ce genre de critiques mais nombres de succès dépendent en grande partie de la simplicité que leurs concepteurs ont réussi à mettre en oeuvre. Et encore un MySpace peut nous apprendre bien des choses comme soi-disant contre-exemple Prenons un seul exemple avec Netvibes. S’il doit bien son succès c’est 100% du à sa simplicité. Comme certains le recommandent, il faudrait que Mr Nielsen se mette à suivre quelques blogs et se remette à niveau avant d’emballer tout aussi simplement.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s