C'est une solution qui ajoute de la complexité : je n'ai pas envie d'être obligé de vérifier l'historique des messages avant d'y répondre, c'est ingérable.
À l'usage, pour utiliser cela sur les autres sites aussi, je confirme que c'est très utile. La variable d'ajustement pourrait aussi être le délai de grâce. Sur certains sites, ce délai est de trois jours. C'est très pratique pour relire ses commentaires à tête reposée et sous un autre angle. Je pense que ce n'est qu'après 24 heures de délai au moins (et une bonne nuit de sommeil) qu'on peut vraiment reconsidérer ses propos avec l'œil d'un « lecteur » et non d'un « relecteur ».
Quel pourcentage de messages ont "besoin" d'être édités ? A comparer avec la complexité engendrée.
Paradoxalement, c'est justement le fait que ce pourcentage soit faible qui va rendre la chose gérable (et d'un autre côté, si tout le monde sollicitait en permanence les modérateurs pour modifier tous les messages du site, alors ça justifierait aussi la mise en place de cette facilité).
Personnellement, j'ai aussi implémenté cette fonction dans le micro site web que j'ai fait pour l'association de mon quartier (avec les messages privés dont je parle dans un autre commentaire). Je fais cela « à la Git », c'est-à-dire que je remplace entièrement un commentaire par un autre même si la modification est minime, ce qui veut dire qu'en ce sens, l'opération n'est pas différente de poster un nouveau commentaire. Et comme mon éditeur est naturellement fait pour faire une prévisualisation (qui elle, n'est pas remise en cause), alors je n'ai besoin de pratiquement aucun code supplémentaire pour reprendre un commentaire existant.
Dans un premier lieu, seule la date de dernière édition est discrètement signalée dans une note en bas du commentaire, et le fait que l'opération soit courante mais pas fréquente fait que cela attire automatiquement l'œil du lecteur quand c'est le cas. Ensuite, les anciens commentaires sont toujours dans la base. Ils sont juste déréférencés parce que le dernier en date remplace toujours le précédent. Donc, au point de vue code, ça ne pose aucun problème.
Ensuite, il me suffit d'une simple table à deux colonnes pour faire un chaînage parent→enfant pour remonter l'historique des modifications. Ça resterait déjà tout-à-fait exploitable si la totalité des commentaires des 15 dernières années avaient un CV long comme le bras (cas des pages Wikipédia, par exemple), mais sur un forum des discussions. Ça va effectivement concerner peut-être 3 à 5 pourcent des commentaires, dont la majorité n'auront qu'une seule modification.
Donc en résumé — POUR l'AVOIR FAIT — je confirme que c'est relativement facile. :)
Un argument que j'aime bien : ne pas avoir de possibilité d'édition incite à réfléchir correctement. Je trouve que ça donne des discussions qui sont de meilleur niveau.
Mouais mais non. Ça, ça n'est vrai que jusqu'à un certain niveau. Ensuite, au bout d'un moment, ça fatigue l'utilisateur, surtout quand il s'agit d'une régression. Prévenir les gens pour qu'ils ne fassent pas de faux pas, c'est une bonne chose, s'arranger pour que, techniquement, ils ne puissent pas en faire, c'est encore mieux.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 5.
À l'usage, pour utiliser cela sur les autres sites aussi, je confirme que c'est très utile. La variable d'ajustement pourrait aussi être le délai de grâce. Sur certains sites, ce délai est de trois jours. C'est très pratique pour relire ses commentaires à tête reposée et sous un autre angle. Je pense que ce n'est qu'après 24 heures de délai au moins (et une bonne nuit de sommeil) qu'on peut vraiment reconsidérer ses propos avec l'œil d'un « lecteur » et non d'un « relecteur ».
Paradoxalement, c'est justement le fait que ce pourcentage soit faible qui va rendre la chose gérable (et d'un autre côté, si tout le monde sollicitait en permanence les modérateurs pour modifier tous les messages du site, alors ça justifierait aussi la mise en place de cette facilité).
Personnellement, j'ai aussi implémenté cette fonction dans le micro site web que j'ai fait pour l'association de mon quartier (avec les messages privés dont je parle dans un autre commentaire). Je fais cela « à la Git », c'est-à-dire que je remplace entièrement un commentaire par un autre même si la modification est minime, ce qui veut dire qu'en ce sens, l'opération n'est pas différente de poster un nouveau commentaire. Et comme mon éditeur est naturellement fait pour faire une prévisualisation (qui elle, n'est pas remise en cause), alors je n'ai besoin de pratiquement aucun code supplémentaire pour reprendre un commentaire existant.
Dans un premier lieu, seule la date de dernière édition est discrètement signalée dans une note en bas du commentaire, et le fait que l'opération soit courante mais pas fréquente fait que cela attire automatiquement l'œil du lecteur quand c'est le cas. Ensuite, les anciens commentaires sont toujours dans la base. Ils sont juste déréférencés parce que le dernier en date remplace toujours le précédent. Donc, au point de vue code, ça ne pose aucun problème.
Ensuite, il me suffit d'une simple table à deux colonnes pour faire un chaînage parent→enfant pour remonter l'historique des modifications. Ça resterait déjà tout-à-fait exploitable si la totalité des commentaires des 15 dernières années avaient un CV long comme le bras (cas des pages Wikipédia, par exemple), mais sur un forum des discussions. Ça va effectivement concerner peut-être 3 à 5 pourcent des commentaires, dont la majorité n'auront qu'une seule modification.
Donc en résumé — POUR l'AVOIR FAIT — je confirme que c'est relativement facile. :)
Mouais mais non. Ça, ça n'est vrai que jusqu'à un certain niveau. Ensuite, au bout d'un moment, ça fatigue l'utilisateur, surtout quand il s'agit d'une régression. Prévenir les gens pour qu'ils ne fassent pas de faux pas, c'est une bonne chose, s'arranger pour que, techniquement, ils ne puissent pas en faire, c'est encore mieux.