SimpleWeb.fr

Saviez-vous que le format PDF a été créé en 1993 par Adobe ? Autant dire que ce format de fichiers est aussi vieux que le web (presque). Toujours est-il que les fichiers PDF font partie du quotidien des internautes mais qu’ils ne sont pas sans poser de problèmes. Le principal étant de provoquer l’ouverture d’une nouvelle fenêtre ou de lancer le téléchargement du fichier alors que l’utilisateur croit avoir cliqué sur un “simple” lien.

Idéalement il faudrait que chacun des liens pointant vers un fichier PDF soit clairement identifiable et précise le poids du fichier. C’est ce que je m’efforce généralement de faire en le précisant dans le lien mais il y a différentes possibilités :

• Ceci est un exemple de fichier (PDF, 55 Ko)
• Ceci est un exemple de fichier (fichier PDF, 55 Ko)
• Ceci est un exemple de fichier (PDF, 55 Ko)
• Ceci est un exemple de fichier [PDF, 55 Ko]

C’est en tombant sur un article récemment publié (How should you display links to PDF files?) que j’ai eu envie de relancer ce vieux débat. Un débat ? Oui tout à fait, celui qui concerne les système de formatage automatique des liens en fonction du format des fichiers. Car le problème est que vous ne pouvez pas vous reposer sur la bonne volonté des rédacteurs qui n’auront pas toujours la conscience de préciser le format ainsi que le poids.

Il y a bien les recommandations d’Adobe en la matière (Use of Adobe icons and web logos) mais elles ne disent pas comment mettre ça en oeuvre de façon automatisée sur un existant avec une multitude liens dans une multitude de pages :

Il existe des solutions pour faire cela avec les feuilles de style (Showing Hyperlink Cues with CSS) mais cela ne règle pas le problème de l’affichage du poids du fichier et vous pousse à reformater l’ensemble des liens (créant ainsi de la pollution visuelle) :

Idéalement il faudrait limiter ce formatage supplémentaire (ajout d’un picto et du poids) aux liens pointant vers des fichiers et l’intégrer directement à l’outil de gestion de contenu qui se chargerait de rajouter un picto ainsi que de calculer et afficher le poids du document. Savez-vous si ce type de solution existe ?

Sinon il ne vous reste plus qu’à le faire à la main…

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 enpré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 :

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

/!\ Article initialement publié sur FredCavazza.net.