[Cahier des charges] Compteur de vues pour les sorties

#13

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.

#14

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
#15

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.

#16

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

#17

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

#18

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
[Besoin d'aide] Rédaction de mini cahiers des charges
#19

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

#21

Merci @CharlesB !
Cette fonctionnalité est donc prête à être développée par des gentils développeurs : https://github.com/c2corg/c2c_ui/issues/2648 :slight_smile:

1 Like
#22

Et donc ?

#23

Et donc, il faut de gentils développeurs pour développer.
Tu te proposes ?

1 Like
#24

En début d’année, nous avons demandé à 2 développeurs de travailler sur cette fonctionnalité, via le mécénat de compétences. Malheureusement ils n’ont pas pu aller au bout du développement. Surtout qu’en cours de route, nos développeurs (qui connaissent bien mieux le code c2c que ces nouveaux développeurs externes et plutôt débutants) ont alerté sur le fait que cette fonctionnalité n’est pas si simple qu’il n’y parait, et si c’est mal fait, ça peut mettre le site à genoux.

Donc il va falloir attendre qu’un développeur compétent ait le temps de développer cette fonctionnalité. S’il y en a parmi vous, n’hésitez pas à vous proposer (pour cette fonctionnalité… ou une autre).

3 Likes
#25

Hello :slight_smile: !

Je commence à regarder un peu ce sujet pour potentiellement commencer le développement de cette fonctionnalité et j’aimerais savoir :

Qu’en est-il de ce compteur pour les documents archivés ? Est-ce que l’idée est d’avoir un seul compteur « global » par document et donc d’avoir le nombre total de vues depuis la création de la première version du document jusqu’à la dernière (et donc afficher la valeur de ce compteur uniquement sur la dernière version du document)

Merci!

4 Likes
#26

Oui, il faut que le compteur inclue toutes les vues de toutes les versions d’un document donné.

Merci à toi !

3 Likes
#27

Merci !!

1 Like
#28

Merci et bon courage!

1 Like
#29

reHello!
J’aimerais savoir s’il faut incrémenter le compteur de vues dans le cas où un utilisateur visionne une version antérieure du document ?
Merci d’avance :slight_smile:
(Et merci pour vos messages d’encouragement !)

#30

Merci beaucoup de faire les choses aussi sérieusement!
Personnellement je ne vois pas de raison pour laquelle il ne devrait pas y avoir incrémentation. Mais j’aurais surtout tendance à dire: l’enjeu étant faible (il s’agit d’un cas quasiment inexistant), fais au plus simple pour toi et pour le code

2 Likes
#32

Idem.
Et même, le top serait de ne compter qu’une seule vue par compte. Si un membre regarde 20 fois une sortie en 2 mois (surtout après la création, pour voir les nouvelles photos et nouveaux commentaires), il faudrait que ça ne compte qu’une seule vue. Car juste quand l’auteur de la sortie fait 15 modifs pour la peaufiner, ça crée 15 vues.
Mais bien sûr c’est bien plus lourd, on ne va pas mettre ça en place.

L’inconvénient de compter les vues des anciennes versions, c’est que pour un document qui a 100 versions, si les robots lisent les anciennes version (ils ne devraient pas mais certains le font quand même), ça crée 100 vues bidons régulièrement.

2 Likes
#33

Bonjour,

Quand on consulte une ancienne version, souvent on en consulte d’autres s’il y en a, puis on revient à l’actuelle. Ce serait à mon avis une mauvaise chose de compter une vue de plus pour chacune de ces recherches et comparaisons sur d’anciennes versions. Le plus simple est peut-être de ne pas compter du tout les vues sur les anciennes versions.

Bernard

1 Like
#35

En effet, c’est une utilisation possible de l’utilisation du nb de vues.
Perso je l’utiliserai surtout pour estimer le risque de l’ « effet internet » les jours suivant la publication d’une sortie en ski. Si la sortie est vue par 10 personnes, il y a peu de risque, par contre si c’est par 200 personnes, c’est plus risqué. Mais pour cela il faut que le compteur compte le nb de visiteurs de la page et non le nb de visites.
Edit : le compteur ne sera visible que par l’auteur de la sortie, donc mon utilisation n’est pas possible.