Retour à la page d'accueil L'atelier

  

N°RF-100 - L'information principale est donnée au début de chaque segment de texte. - Niveau 2 - Rubrique : Hyperliens - Sous-rubrique : Libellé

Noter :
  • (Moyenne : 0)

  

Objectifs

Mise en Oeuvre

La mise en oeuvre de cette BP n'est pas encore rédigée. Vous pouvez proposer une solution de mise en oeuvre dans les commentaires ou par email (commentaires_AT_opquast.org)

Vérification

Liens

Tags

Voir les 11 commentaires archivés

  

Commenter cette bonne pratique

Florent V. - 07/11/2009 12:22 (0 réponse(s))

Intérêt très limité à mon sens. Donc le projet fixe une limite, et le message est passé aux rédacteurs.

Soit la limite est très large (1000, ou même 200 caractères), et les rédacteurs l'oublient. Le fait même d'avoir une limite définie dans le projet devient alors totalement caduque.

Soit la limite est excessivement courte (30, 40 caractères), ce qui conduit les rédacteurs à créer de mauvais liens, cryptiques ou peu explicites, dans certains cas de figure.

Soit la limite est plus raisonnable, mettons fixée à 60 caractères, mais le rédacteur n'a pas le compas dans l'oeil ni d'outil de comptage dans son interface d'admin, et donc vérifier cette BP au moment de l'appliquer à la source n'est pas gérable, on peut juste utiliser la limite du projet pour une vérification manuelle ou automatique après coup. Intérêt faible.

Le but est-il de limiter ou supprimer les blocs «teaser» (titre et intro d'article) cliquables? Et donc le public concerné ne serait pas les rédacteurs, mais chefs de projet, designers et intégrateurs? Et dans ce cas, si le designer veut utiliser ce type de lien-bloc (avec la bénédiction de HTML5, soyons fous), la limite pour le projet sera fixée à longueur maximale du titre de news + longueur maximale de l'extrait, par exemple 500 caractères. Et on dira au rédacteur: au fait, on a fixé une longueur max de 500 caractères pour les liens. Arf.

La BP 101 ({Le libellé des hyperliens, éventuellement complété par son contexte proche, est représentatif de leur cible et décrit la nature du contenu vers lequel ils pointent.}) me semble être une recommandation beaucoup plus utile pour un rédacteur, et dont l'application aurait pour effet de rendre la BP discutée ici inutile pour les rédacteurs dans la quasi-totalité des cas. Pour les designers et intégrateurs, la question des liens longs est un sujet bien différent, qu'il faudrait peut-être traiter différemment... ou ne pas traiter dans une BP Opquast. ;)

Répondre à ce commentaire

Jérémie P. - 07/11/2009 11:33 (1 réponse(s))

Inapplicable pour moi. C'est se poser des contraintes là ou il n'y a aucun consensus connu. ça va virer au n'importe quoi juste pour être conforme.

On pourrait éventuellement dire {Les libellés des liens on une taille raisonnable}... mais qui définie le "raisonnable".

Je ne le sens pas du tout là.

Répondre à ce commentaire

Laurent Denis - 07/11/2009 11:39 (1 réponse(s))

C'est parfaitement applicable puisque la limite est définie par le projet Web (et par exemple ses règles éditoriales).

Sinon, on n'empêchera en effet pas les mauvais joueurs de fixer et d'afficher une limite à 1000 caractères, mais on ne les empêche jamais de contourner quoi que ce soit ;-)

Répondre à ce commentaire

Jérémie P. - 07/11/2009 12:18 (2 réponse(s))

Si je suis ton raisonnement, l'important ce n'est pas la longueur des liens, mais le fait de se fixer des règles et de s'y tenir.

Je suis d'accord pour dire que c'est une bonne pratique de gestion de projet web, mais ça n'a rien à voir avec les longueur des libellés de lien.

Sur cette question de lien, je ne connais aucun consensus qui permettent d'en tirer une bonne pratique capable de fédérer les réalisateurs de sites web (mais si vous avez ça sous le coude, je suis preneur).

Par contre, qu'on requalifie cette BP pour en faire une BP de gestion de projet, pourquoi pas.

Répondre à ce commentaire

Laurent Denis - 07/11/2009 12:26 (0 réponse(s))

Bah, il s'agit expliciteùment du cas des libellés de liens, là, tout de même ;-)

Sinon, concrètement : fixer une telle limite rend les rédacteurs, leurs envies mais aussi leurs contraintes, gérables. Pour un projet Web, c'est énorme. Pour l'utilisateur, c'est un bénéfice immédiat car c'est le seul moyen universel, vérifiable de gérer au mieux ce problème (puisqu'aucune limite arbitraire ne sera acceptable).

Répondre à ce commentaire

Florent V. - 07/11/2009 12:30 (2 réponse(s))

«Si je suis ton raisonnement, l'important ce n'est pas la longueur des liens, mais le fait de se fixer des règles et de s'y tenir.»

Et aujourd'hui même, le compte twitter Opquast rappelle ce texte de 2005 qui dit qu'Opquast ne se mêle pas de l'organisation interne.
http://blog.opquast.com/post/2005/07/12/39-les-dix-regles-du-contributeur-connaitre-il-te-faut

La première règle est «Des bonnes pratiques vérifiables en ligne tu proposeras», qui dit que les BP de gouvernance sont à exclure. Le principe même de demander à ce qu'une limite soit fixée au sein d'un projet, puis observée, semble contraire à cette règle.

Répondre à ce commentaire

Laurent Denis - 07/11/2009 12:38 (0 réponse(s))

les BP de gouvernance ne sont en aucun cas exclues. Sinon, une large partie d'Opquast va passer à la trappe ;-)

Répondre à ce commentaire

Élie Sloïm - 07/11/2009 12:53 (1 réponse(s))

Ca mérite un éclaircissement de ma part :

Ce qu'on se propose de vérifier, c'est que le site a défini une limite. Autrement dit, c'est la partie visible d'une bonne pratique de gestion de projet. On a choisi de faire comme ça à chaque fois qu'on ne pouvait pas fixer de limite universelle. C'est parfaitement faisable, et en arrière plan nous avons l'idée de proposer aux webmasters de consigner cet ensemble d'informations dans un fichier mis à la racine du site.

Répondre à ce commentaire

Jérémie P. - 08/11/2009 15:21 (1 réponse(s))

Ok, mais dans ce cas, il faudrait créer une catégorie "Gestion de projet Web" et se donner les moyen de vérifier la conduite du projet et son résultat.

Toutes ces règles ou il faut définir, afficher et respecter... et bien... ce sont des règles, pas des bonnes pratiques.

Une bonne pratique pour ce que j'en comprend, c'est une espèce de règle informel qui recoupe des usages partagés, volontairement ou non.

Toutes ces règles là (BP 10, 31, 75 et 100) me semble plus là pour répondre à un problème de mesure propre à Temesis que de rationaliser une vraie pratique professionnel.

Si à une époque on a parlé de la limite de taille des contenu alternatif des images, c'est parce qu'il y avait une contrainte technique forte et que ça faisait sens de la respecter... a tel point que tout les développeurs de sites s'y sont plus ou moins tenu, d'où l'apparition d'une bonne pratique.

Là, on est vraiment dans le cas ou on va se mettre des contraintes là ou il n'y en à pas. C'est déjà assez dur comme ça de faire des sites qui tiennent la route, s'en qu'en plus on s'invente des obstacles qui n'existe pas.

Qu'est-ce qui pousse comme ça à limiter la longueur des textes ? Lutter contre un abus de SEO ? on serait peut être plus inspiré de chercher du coté des bonnes pratiques de rédaction Web à ce moment là. non ? A la décharge du SEO, en général, les experts sur ce sujet n'aime pas trop les textes à rallonge qui diluent les mots clés et préfèrent des expressions bien ciblées, surtout sur les libellé de lien.

Répondre à ce commentaire

Élie Sloïm - 08/11/2009 17:31 (3 réponse(s))

Attention à ne pas mettre toutes les Bp dans le même sac.

Concernant les titres et le poids des pages, nous parlons vraiment de critères qualité Web. Pour les longueurs de libellés, faut voir.

Je veux bien entendre l'argument qu'un libellé de lien de 500 caractères ne TE pose aucun problème. Moi, ça me gène, je déteste les liens sous forme de bloc de plusieurs lignes, mais admettons que celle-ci saute.

Je comprendrais que tu ne veuilles pas de toutes ces BP, mais le but du jeu est de trouver une solution ou une formulation.

Pour les titres et surtout le poids des pages, nous n'extrairons pas ces exigences des bonnes pratiques Opquast sous prétexte qu'elle relèveraient de la gestion de projet, tout simplement parce que c'est faux, en tous cas, pas plus que TOUTES les autres bonnes pratiques. Si l'indicatif téléphonique international est indiqué, c'est de la gestion de projet, c'est dans le cahier des charges, c'est fait suite à une recette, un audit, etc...

Pour revenir au principe de définir des limites et de les afficher :
Va te promener sur une page de 2Mo avec un téléphone mobile en 3g, et tu verras qu'on parle vraiment de qualité.
Si avec la formulation actuelle un administrateur décide d'afficher sur son site qu'il a choisi 2 Mo de taille maximum, il faudra qu'il l'affiche et l'assume, au risque de passer pour un incompétent. Je voudrais te voir marquer une énormité comme ça sur ton site ou dans un fichier à la racine. Même pas cap.

En tous cas, pas question de les supprimer purement et simplement, et encore moins de les mettre toutes dans le même sac.

Répondre à ce commentaire

Élie Sloïm - 08/11/2009 17:38 (0 réponse(s))

Un autre point important : le problème de mesure n'est pas propre à Temesis. Nous avons tous besoin de pouvoir faire un audit (interne ou externe) qui nous permettrait de détecter ce genre d'erreur. Le fait que ce soit automatique ou pas n'a aucune importance.

Enfin, de toute façon, il va falloir qu'on trouve une autre approche, parce que là, de toute façon, vu comment on est parti, on aura rien sur les poids de pages, sur les titres, sur les URL, enfin, bref, un référentiel de charlots.

Répondre à ce commentaire

Jérémie P. - 08/11/2009 21:24 (1 réponse(s))

Alors là, je suis bien embêter. Il faudrait que je fasse une grande réponse, mais je pense que je vais passer à coté de pas mal de chose. Je ne suis pas assez à l'aise par écrit pour expliquer ce qui me pose un problème ici. Je vais tenter une réponse mais ce sera sans doute partiel, et je ne suis pas sur que ça éclaire plus le problème !

Je n'ai pas dit que ça ne me poser aucun problème de voir des libellé de liens trop long ou des pages d'un poids scandaleux (mais ne me met pas au défie de justifier un poids maxi de 2mo par page... un peu de vidéo et la question est réglé ;)
Je suis même plutôt d'accord pour dire qu'il faut arriver à trouver un consensus sur le sujet ou un moyen d'arriver à ménager la chèvre et le choux entre des pages de 100Ko et des pages de 600Ko.

Non, ce qui me gène ce ont les BP du type "je définie, j'affiche, je respecte" Je trouve que c'est une façon un peu facile d'évacuer un problème. A ce tarif là, pourquoi toutes les BP ne sont-elles pas rédigée de cette façon, au moins comme ça, on ne se prend pas la tête à définir des BP, on laisse le boulot à tout les concepteurs de sites, qui n'en feront qu'a leur tête puisque "du moment que c'est écrit, c'est permis, même si c'est une énormité" et le problème sera entier... on aura une qualité définie sur la base de critère propre et pas sur la base de critères communs. C'est un processus qualité tout à fait valable, mais alors, j'ai l'impression qu'on passe à coté de ce qu'on essaye de faire ici.

Puisque sur ces sujets, il n'y a pas de contraintes techniques claires qui poussent à un comportement, ne pourrions nous envisager un sondage pour voir qu'elle est la meilleur taille, poids, valeur pour ce type de BP ?

plus spécifiquement sur cette BP 100, je crois qu'il faut l'écarter et cela pour deux raisons : 1 - il y a déjà une certains nombre de BP qui sont discutées autour des liens (en particulier la 101 et la 102) qui couvre plus ou moins indirectement cette question, donc, ce passer de cette BP ne génère pas une zone d'ombre qualitative. 2 - La direction que prend HTML5 nous invite à faire preuve de circonspection sur ce point et il me semble nécessaire de prendre le temps d'attendre à moins de vouloir ce retrouver avec une BP qui n'en sera finalement peut-être pas une.

Pour les autres BP sur le même modèle, je vais aller mettre mon grain de sel la-bas ;)

Répondre à ce commentaire

Fabrice Bonny - 08/11/2009 21:59 (0 réponse(s))

Un tel sondage n'est aucunement envisageable pour des tas de raisons. Imaginons que l'on définisse une limite. Suivant le serveur et la connexion, le temps de chargement peut énormément varier, y compris dans le temps. J'irai encore plus loin en disant que si le poids de la page est dû à des images, le chargement semblera rapide et je pourrai commencer à lire en attendant le chargement.

En clair, certaines BP comme celle-ci sont là pour définir un cadre aidant à trouver les réponses propres à chaque cas.

Pour finir, de nombreux sites ont trouvé une solution intéressante concernant les URL en utilisant des raccourcis comme font tiny ou bitly. Microsoft utilise ce genre d'URL en /jump/un_identifiant_unique. Je parle bien sûr de la BP sur la longueur des URL, pas de celle-ci mais l'idée est la même. Personne n'a attendu Opquast pour identifier les problèmes et trouver des solutions créatives.

Répondre à ce commentaire

Nicolas Hoizey - 09/11/2009 10:32 (0 réponse(s))

Un lien sur un ensemble d'éléments comme ce sera possible en HTML5 me choque moins qu'un même lien répété sur une image, son titre, et sa description, comme l'on voit parfois.

Du coup, c'est clair que limiter la taille du libellé du lien est difficile.

Mais la discussion dérive et devient plus générale sur les BP, il faudrait peut-être stopper, et nettoyer pour ne conserver que ce qui concerne la BP 100...

Répondre à ce commentaire

Commenter cette bonne pratique