[Cahier des charges] Compteur de vues pour les sorties

Oui, mais pour cela il faut préparer un cahier des charges ! Quelles fonctionnalités, où et comment, visibles par qui…

ça me parait assez simple, il faudrait un compteur « minimal » qui indique le nombre de visites pour une sortie donnée. (la visibilité pourrait être réservée à l’auteur de la sortie, je ne me souviens plus si le vote était très clair sur ce dernier point)
Si possible éviter les robots (est ce possible ?)
De mon point de vue si une même personne consulte plusieurs fois la même sortie ça montre un intérêt accru pour la sortie et cela devrait être comptabilisé.
Mais cela montre le problème de ce cahier des charges : je ne suis pas mandaté pour de telles décisions aussi spécifiques.
D’un autre coté on peut pas (il me semble) relancer la machine du double vote (deux chambres sur C2C) pour régler chacun de ces petits détails.
Ne peut on pas faire faire confiance aux développeurs pour qu’ils règlent ces specs en se basant sur leur bon sens et leur pragmatisme ?
Un compteur de vues pour les sorties qu’ils pourraient implémenter en un temps raisonnable sans y consacrer leur vie 24-7 ?
J’imagine que ce message ne vaut pas pour cahier des charges et que vous attendez quelque chose de plus structuré mais pourriez vous en préciser le format ?

C’est ce que disent tous ceux qui n’ont jamais eu à coder une appli utilisée par des humains… :roll_eyes:

1 Like

Non, non, non !
Je n’ai jamais dit que c’était simple à implémenter.
Je disais que le cahier des charges était simple.
Je suis reconnaissant envers ceux qui consacrent bénévolement leur temps à la maintenance de C2C et je n’ai jamais voulu leur manquer de respect !
(je suis prof d’info en Lycée et je mesure humblement la charge et la complexité de votre travail)

Bonne nouvelle. Ne serait il pas possible de faire un partenariat entre votre lycée et C2C pour faire évoluer le développement du site?

Nous sommes à la recherche de partenariat avec des écoles d’info. Avez vous des pistes?

1 Like

Et moi je te repète que le cahier des charges pour la moindre fonction qui s’intègrera dans un existant et devra être utilisée par des humains « lambda » est tout sauf simple et rapide à écrire… Quand le CDC parait simple et rapide à écrire c’est juste qu’en réalité le dev va devoir se taper la réécriture réelle tout seul dans son coin pendant le projet…

Je t’en veux pas c’est une vision courante même de ceux qui ne mésestiment pas du tout le travail de dev derrière. Mais à un moment si on ne cherche pas le petite bête au CDC ça va grogner aux premières utilisations (pas forcément par celui qui aura écrit le CDC d’ailleurs, mais les autres, ceux qui avaient une autre vision du truc).

Si tu es prof d’info en lycée il y a un truc qu’on m’a jamais appris mais qui aurait été bénéfique et serait bénéfique à tous tes élèves qui seront un jour clients/donneurs d’ordre à des devs: le developpeur a un coût (ici c’est la disponibilité et l’usure des bénévoles qui font le boulot mais c’est la même chose) et tout ce qui ne relève pas de leur expertise devrait être géré avant => effets de bords, questions de philosophie de l’appli, cas d’usages et règles de fonctionnement… Si on le fait et qu’on le met dans un CDC c’est plus simple pour le dev, mais ça montre que l’écriture du CDC n’est pas simple…

1 Like

Mais je comprends très bien tout ça, l’écriture du Cahier des charges est un des écueils principaux que je rencontre avec mes élèves.
Je disais juste qu’il y a eu un (deux) vote pour ou contre le compteur de vue pour les sorties et que le oui l’a emporté.
J’ai organisé le sondage, ça ne fait pas de moi un prescripteur du réglage des détails.
Mon point de vue : faites au plus simple.

Est ce qu’il y a eu un cahier des charges pour le compteur de vues des articles du forum ?
Dans l’affirmative on pourrait s’en inspirer si cela vous convenait.

Le problème c’est que les développeurs ne seront pas forcément des utilisateurs/contributeurs du site, donc question bon sens et pragmatisme on peut avoir de tout et n’importe quoi non ?

2 Likes

Il n’y a pas que les specs : Le code qui est derrière les forums est différents de celui qui est derrière le topoguide. Les forums sont bâtis sur discourse, et peut-être la possibilité de compteurs était déjà là, ou simple à implémenter.

2 Likes

En complément : sur le forum, la seule partie qui ne vient pas avec Discourse, c’est le menu à gauche, tout le reste ce n’est que du paramétrage de l’outil Discource.

2 Likes

Sympa pour eux…
En l’occurrence le CDC me paraît tout fait je ne vois vraiment pas ce qui manque à quelques détails près qu’on peut discuter directement avec les développeurs.

C’est juste pour dire que s’il faut faire un choix, je ne penserais peut-être pas comme toi ni comme un autre, y’a rien de péjoratif là-dedans.

Entre une expression « express » d’un besoin (on veut un compteur de vues) et la réalisation (codage bête et méchant), on peut trouver une bonne dizaine de façon d’y arriver (avec moins de résultats différents au niveau visuel).

Tu te proposes donc pour répondre aux développeurs quand ils auront des questions (pas d’ordre technique, je parle juste de fonctionnel) ?
De mon côté, je sais que si je dois attendre un retour de quelqu’un pour avancer dans mon travail (plusieurs heures/jour d’attente pour quelques minutes/heures de travail entre chaque question), ça ne me motive pas vraiment.

2 Likes

Non mais serieux il reste quoi comme détail à régler?
Au niveau visuel oui. Un développeur nous propose différentes solutions, dit sa préférence et on valide.
Je rate peut-être des trucs.

Exact, quelques propositions :

  1. Si possible on évite les bots
  2. Si possible visible uniquement pour les participants à la sortie
  3. A priori pas de like
  4. Si possible uniquement pour la consultation d’une sortie, pas à chaque fois qu’on consulte une photo de la sortie
  5. Une même IP ne compte pas deux fois dans les mêmes 24h
  6. Valeur max du compteur : 2^32 - 1 ?
  7. Au niveau visuel je trouve très bien ce qui apparaît sur le premier message des threads du forum, en plus simple.
1 Like

Si ça te paraît si clair, on te laisse 5 minutes pour le rédiger proprement.

@tchae, pas besoin de refaire des votes pour le détail, il suffit de le proposer et de laisser chacun commenter et proposer des améliorations.

Est ce que le ‹ détail › ci-dessus vous convient ?

Oui. La réponse était « privé »

En gros seulement le chiffre du milieu (1,6 k sur l’exemple ci-dessous)?
Capture

C’est ce qui ressort du vote

Bonjour
Pour avancer sur ce point, il faut créer un cahier des charges fonctionnel :
Post en WIKI ci-dessous pour le créer ensemble :

Cahier des charges fonctionnel

Objectif du projet

L’objectif de ce projet est de permettre d’avoir un compteur de vue par sortie, visible ou non par choix du ou des auteur(s) de la sortie.

  • Dans le document sortie, un compteur de vue affiche le nombre d’affichage de la sortie
  • une case à cocher en bas du formulaire de saisie de sortie, mentionnant « Désactiver le compteur de vues », avec valeur par défaut à non (situé à coté de la case actuelle pour autoriser ou non les commentaires)
  • Comme pour le reste des documents sortie, seul un membre de la sortie (ou un modo) peut changer la valeur de ce champ.
  • si le compteur de vue est désactivé, alors le nombre de vue n’est visible que par les personnes associées à la sortie.

Cahier des charges technique

Charabia technique

API

Rajouter dans tous les documents (1) :

  • view_count un champ numérique (integer), valeur par défaut à zero est rajouté auz document. Il s’agit d’une méta donnée, et non pas d’un champ versionné (un changement de sa valeur ne doit pas creer une nouvelle version en base du document). Ce champ est remonté dans tous les services exposant des documents.

Rajouter dans les document sorties :

  • enable_view_count un champ booléan, par défaut à true. Ce champ est versionné, comme les autre champs du document. Comme pour les autres champ des sorties, il n’est modifiable que par les personnes rattachées à la sortie (ou les modos). Si enable_view_count est à false, alors view_count est remplacé par null dans le service qui expose la sortie.

A chaque requete du document, view_count est incrémenté. Il existe deux exclusion pour ne pas incrémenter :

  • Si l’utilisateur est un robot
  • si l’utilisateur a un user agent dans une liste donnée (pour exlure par exemple le google bot)

point important : l’incrementation est bufferisé, afin de ne pas surcharger la base de donnée. Les APIs stockent la valeur à incrementer, et tous les N minutes, vont vider le buffer pour mettre à jour les documents en base.

Note 1: c’est aussi simple techniquement de le mettre pour tous les docs, donc autant l’avoir pour tout le monde.

UI

Assez évident, voir partie fonctionnelle

2 Likes

Ça me paraîtrait vraiment dommage de limiter le décompte aux seuls utilisateurs connectés, ce qui donnerait une fausse idée de la fréquentation de C2C. Et si l’idée c’est de motiver les gens à rentrer des sorties, alors il serait préférable de ne pas limiter la vue du nombre d’affichages aux seuls utilisateurs connectés (qui sont déjà a priori proches de C2C)

Je suis d’accord, une vue reste une vue, qu’elle soit fait par une personne connectée ou non.

Dans le meme sens, l’option de cacher ou pas le nombre de vue doit s’appliquer à tout le monde : il suffit de quelques secondes pour se creer un compte, il n’y a donc fonctionnellement pas trop de sens de le laisser visible uniquement pour les personnes connectées, et ca rajoute de la complexité technique.

Je modifie dans ces sens.

3 Likes