[Bug] Le temps calculé calcule n'importe quoi

En haut de mon dernier article publié s’affiche ceci :

Temps de lecture estimé : 4 heures et 15 minutes

Or, même en prenant en compte les codes sources, il y a 21 788 SEC (signes espaces comprises), soit un quart d’heure de lecture maximum.

Je n’ai pas regardé si j’étais le seul à avoir ce problème.

C’est un vieil article que j’ai oublié pendant plus d’un an avant de l’envoyer en publication, si ça peut aider.

Même avec les 4000 lignes de Kotlin ? 15 minutes ? Rien que ce code fait bien plus de 20000 caractères non ?

Ha, le copier/coller a zappé le code en secret.

Ça nous amène à près de 180 000 SEC, donc deux heures grand max.

Donc :

1. Le temps calculé est quand même très étrange,
2. Ne devrait-on pas en exclure les blocs de code ?

En fait ça dépend du contexte, typiquement dans un cours de programmation le lecteur doit lire les codes. Idéalement, il faudrait pouvoir choisir d’enlever certaines parties de l’estimation.

Ou tout simplement que l’auteur puisse lui meme indiquer uneduréeê.

Je dirai fausse bonne idée. Donner le bon temps, c’est tout sauf facile, et je ne pense pas que l’auteur soit le plus à même de le faire : il connaît trop bien son sujet. Quand au validateur (qui devra vérifier que la durée est cohérente si l’auteur la rentre lui-même), le temps qu’il passe à la relecture n’est pas représentatif. Ça va finir en pifométrie, une situation guère meilleure que celle-ci, pour plus de travail manuel.

Les balises secrets pourraient être enlevées du temps de lecture.

Non plus, pareil, dans un tuto il peut y avoir des solutions d’exercices dans une balise secret, solutions devant être lues. Tout retrait sur la base de l’avis de quelqu’un serait arbitraire. Le seul truc qui me paraît plausible c’est de permettre aux auteurs de retirer certains morceaux du compte.

Comment un programme peut donner un temps si l’auteur ou un validateur ne serait lui même pas le calculer ? Après on peut mettre :

Temps recommandé : XXX minutes

Saisir un temps personnalisé : ... minutes

Comment un programme peut donner un temps si l’auteur ou un validateur ne serait lui même pas le calculer ?

Probablement de la même façon que les programmes sont meilleurs que des humains pour tout un tas de tâches, tout particulièrement lorsqu’il s’agit de quantifier quelque chose.

Je vois personnellement pas l’intérêt de ce "temps de lecture" de toute façon (on lit pas un tuto de la même façon qu’un roman de gare, le temps significatif est celui passé à comprendre les notions), alors si on doit s’en occuper en tant qu’auteur ou validateur, ce serait du travail en plus pour un truc pas très intéressant au final.

Clairement les codes et secrets devraient être pondérés non ? On ne lit pas un code de la même façon que du texte. Et autant la durée nécessaire à la lecture d’un texte peut varier un peu en fonction de la complexité du texte, autant pour du code ça peut varier du tout au tout ! Si je lis du Java, je vais avoir tendance à vite enlever le « bruit » introduit par l’aspect cérémonieux du langage, autant si je lis une fonction tail-recursive en Haskell, il va me falloir beaucoup plus de temps pour le comprendre.

Peut-être que donner une fourchette (ex : « entre 15 et 35 minutes ») serait déjà plus adapté. Ou peut être qu’au lieu de faire saisir à l’utilisateur une durée, on peut lui demander de saisir une complexité, ou un facteur de pondération pour les balises code et secret ?

Ou peut être qu’au lieu de faire saisir à l’utilisateur une durée, on peut lui demander de saisir une complexité, ou un facteur de pondération pour les balises code et secret ?

Machine à gaz en vue ! Sérieusement, qu’on corrige ça, OK, mais n’ajoutons pas une revue manuelle, sans quoi ça va prendre trop de temps pour quelque chose de pas hyper important. On a déjà des auteurs qui oubliaient de mettre des catégories ou de choisir une licence (maintenant, il faut le faire pour créer un contenu donc plus de problème), mais on a encore régulièrement des oublis de miniature. Ne rajoutez pas encore de la complexité à la création. Tout système a des faux positifs et faux négatif, la question est ici :

Aura-t-on plus de contenu mal estimé en excluant les balises secrets ou en les incluant ?

Parce que le problème ici n’est pas le code, mais le gros tas de texte dans la balise secret. Balise qui sert à ça, entre autre : éviter de remplir la page avec des informations souvent dispensables. Donc, si on les inclut, ça pose le problème montré ici, et si on les exclut, ça risque de diminuer le temps compté pour les autres utilisations de la balise (correction d’exercice ? je ne vois pas d’autre utilisation légitime contenant une quantité significative de texte). À voir quel "faux" on préfère.

Au-delà de ça, je rappelle que même en comptant le code en secret comme du texte, le résultat n’a aucun sens.

Pendant que j’y pense, afficher 18 ou 42 minutes n’a pas de sens. Je propose d’arrondir au 15 minutes les plus proches si moins d’une heure, avec un minimum de 5, et à la demi-heure ensuite (5 min, 15, 30, 45, 1h, 1h30, 2h…), ou un truc du genre.

Donc, si on les inclut, ça pose le problème montré ici, et si on les exclut, ça risque de diminuer le temps compté pour les autres utilisations de la balise (correction d’exercice ? je ne vois pas d’autre utilisation légitime contenant une quantité significative de texte). À voir quel "faux" on préfère.

Bah justement, je te propose de laisser le choix à celui qui sait, le rédacteur, de le definir, en disant « non, ne le compte pas dans le temps de lecture, ça n’a pas d’interet (Donc coeff 0) ». Libre à tous de trouver une valeur par défaut correcte.

Franchement, je vois pas en quoi c’est une « usine à gaz » vraiment pas. Ça peut être nécessaire ou pas, adapté ou pas, avoir un ratio gain-galère négatif, carrément, mais qualifier crier à l’usine à gaz pour un bête coeff de pondération, facultatif ça me parait extrême un peu, non ? Ok pour le KISS mais on peut chercher des solutions peut être quand même sans s’en faire rabrouer 🥺

Désolé, je ne voulais pas te rabrouer ou être agressif. Je vais présenter les choses autrement :

Le boulot de l’auteur, c’est de faire un joli texte tout bien comme il faut. Donc juste, pédagogique, sans faute d’orthographe, sourcé… La validation rajoute de la lourdeur mais a pour but d’aider à ce que ces objectifs soient atteints. Tout le reste, c’est du « bruit », dans le sens où c’est potentiellement nécessaire, mais ça sort de la vraie tache de l’auteur. Ce bruit, c’est aussi bien les confusions entre partie et section (en cours de résolution), le fait de mettre une catégorie, etc. On nous dit régulièrement que notre interface est trop chargée, et qu’il y a déjà beaucoup de choses à faire, tant d’un point de vue du texte que de ce qu’il y a autour.

Tu proposes de rajouter autre chose. Même si c’est simple, mais si c’est un petit rien (du genre une case à cocher dans un coin des paramètres du tuto), ça revient en fait à rajouter encore un truc ici. En tant qu’auteur aussi bien en tant que validateur, je dis que c’est une mauvaise idée. Ajouter une case à une interface déjà trop chargée, ou une revue manuelle à un processus qui en compte déjà beaucoup, ça craint (concrètement, lors de ma dernière validation, j’ai signalé l’absence de miniature, de catégorie et une licence non changée, sûrement parce que l’auteur ne savait pas qu’on pouvait, c’est un problème que l’on rencontre vraiment ; donc j’ai dû vérifier tout ça, et en y repensant, j’ai oublié les tags…).

On a déjà quelque chose de trop complexe, n’en rajoutons pas.

Je ne vois pas l’intérêt d’arrondir sur une base de 5

On est capable d’appliquer un temps de calcul différent pour le code ?

A combien passe-t-il sans le code ?

Je ne vois pas l’intérêt d’arrondir sur une base de 5

Parce que t’as l’air un peu con quand t’affiche une valeur aussi précise que 47 minutes ou 2h19 alors que :

• C’est une estimation et ça dépend donc du lecteur.
• Sur certains types de contenu ça ne correspond pas du tout au temps réel de lecture.

La première raison étant, à mon sens, ce qui fait perdre le plus de crédibilité à une estimation d’une telle précision.

C’est un peu comme les chiffres significatifs en physique, tu vois. T’as l’air un peu con si tu donnes 18 décimales à une masse mesurée avec une balance de cuisine.

C’est un peu comme les chiffres significatifs en physique, tu vois. T’as l’air un peu con si tu donnes 18 décimales à une masse mesurée avec une balance de cuisine.

Je ne vois pas le lien de ton exemple, ici il n’est pas question de rajouter 18 nombres mais de remplacer 8 9 1 2 par 0 et 3 4 6 7 par 5. Je ne vois pas pourquoi c’est nécessaire de remplacer par 0 et 5, ça revient au même. Et ça rendra cette estimation encore moins précise.

@A-312 : précis ne veut pas dire juste. L’idée ici est que le calcul est tellement approximatif et dépendant de plein de facteurs qu’on n’est pas capable de sortir un temps qui soit significatif à la minute près. Donc plutôt que de prétendre qu’on est capable de faire la différence entre un tuto lu en 11 minutes et un tuto lu en 18, on peut plutôt indiquer qu’ils seront lu en environ 15 minutes.

Tu proposes de rajouter autre chose. Même si c’est simple, mais si c’est un petit rien (du genre une case à cocher dans un coin des paramètres du tuto), ça revient en fait à rajouter encore un truc ici. En tant qu’auteur aussi bien en tant que validateur, je dis que c’est une mauvaise idée. Ajouter une case à une interface déjà trop chargée, ou une revue manuelle à un processus qui en compte déjà beaucoup, ça craint

Bah, en fait c’est pas vraiment ce que je propose 😔

Je propose qu’en face de chaque élément spécial (image, code, secret, math, etc. etc.) l’auteur puisse spécifier un attribut qui correspond à un coeff de pondération (en gros "ça prend du temps à lire" ou "c’est purement illustratif, ça ne rentre pas en compte dans le temps de lecture").

Désolé, je veux pas m’accrocher trop au sujet, (parce que probablement que le ratio gain-galère est pourri, et qu’il ne faut pas le faire), mais ça me semble important de préciser mon idée car visiblement tu l’as mal interprétée : je ne souhaite alourdir aucune UX, vraiment. Pas de case à cocher rien.

Par contre, les utilisateurs avancés pourraient écrire un truc genre

```java(0.01)
public static void main(String... args) {
  // some comment that nobody reads anyway, bla bla bla
}

Juste un simple attribut avec une valeur par défaut qui en l’état serait "1" d’après ce qui a l’air d’être mentionné dans ce thread, donc 0 surcharge côté UX.

Bon par contre, ça surcharge sans doute le parsing du markdown, et complexifie (certainement trop) l’algorithme de calcul du temps de lecture, et risque (éventuellement ?) d’accoucher de cas marginaux parfaitement foireux. Aussi, ça s’éloigne du MD standard, donc ce n’est vraisemblablement pas souhaitable.

Mais ça a l’avantage de fonctionner pour tout élément dans la page (y compris les images hein : ajouter un gros graphique ou une carte dans un article, ça augmente le temps de lecture, ajouter une jolie illustration, non) mais à condition de trouver une syntaxe qui fonctionne partout, c’est pas gagné.

Désolé, je n’insiste pas plus que cela, et sans doute que mon message d’origine n’était pas clair, d’où la confusion, mais là, clairement, tu réponds complètement à côté de ce que je propose 😞 (EDIT : mais c’est de ma faute, cf. ci-dessous).

EDIT : en relisant mon message original, je parle de "faire saisir un coefficient de pondération pour les balises codes et secret" et c’est pas du tout clair, mea culpa. Mon idée était plutôt : "permettre de saisir un coefficient de pondération en face de chaque balise code ou secret". J’aurais dû me relire attentivement.