ZEP-24 : Refonte et enrichissement des notifications

Situation actuelle

Aujourd'hui, il est possible de recevoir des notifications pour les événements suivants :

• nouveau message sur le forum dans un sujet suivi (via le bouton "suivre" ou parce qu'on y a posté)
• nouveau commentaire sur un article qu'on a commenté
• nouveau commentaire sur un tutoriel qu'on a commenté

Rien ne permet de distinguer ces trois types de notifications. De plus, il est actuellement impossible de suivre les commentaires d'un tuto/article manuellement (sans avoir posté donc). Impossible également d'arrêter d'être notifié pour les commentaires d'un tuto/article.

Proposition

L'idée serait de repenser les notifications pour en faire un module à part, qui soit plus complet et plus souple qu'actuellement.

Types de notification

Pour commencer, 11 types de notifications sont proposées :

• [forum] nouveau message dans un sujet suivi
• [forum] nouveau sujet dans un forum suivi
• [forum] nouveau sujet créé avec un tag suivi
• [article] nouveau commentaire dans un article suivi
• [article] mise à jour d'un article dont on est co-auteur (version hors-ligne)
• [tutoriel] mise à jour d'un tutoriel dont on est co-auteur (version hors-ligne)
• [tutoriel] nouveau commentaire dans un tutoriel suivi
• [tutoriel] mise à jour d'un tutoriel suivi
• [tutoriel] nouvelle demande d'aide pour un tuto (avec possibilité de n'être notifié que pour les tutos qui demandent un graphiste par exemple, ou un correcteur.
• [validation] nouveau tuto/article en validation (avec filtre par catégorie/tag)
• [général] ping d'un user dans un commentaire/post du forum (-> sans doute à implémenter séparément)

Dans le futur, d'autres types de notifications pourraient être créées, par exemple concernant les futures tribunes libres.

Chaque type de notification pourra être reçue via le header (par défaut) et/ou via email (à activer). Le comportement pourra être défini par l'utilisateur de manière générale (via une page de paramètres dans le profil), et de manière plus fine pour chaque sujet/tuto/etc. suivi.

[Forum] Nouveau message dans un sujet suivi

Même fonctionnement qu'actuellement

-> mène au premier message non lu

[Forum] Nouveau sujet créé dans un forum suivi

L'abonnement à un forum (exemple, le forum "Dev zone") se ferait sur la page d'accueil du forum en question, via un bouton "Suivre ce forum" dans la sidebar. Désabonnement de la même manière

-> Mène au premier message du sujet, à charge pour l'utilisateur de suivre ou pas ce sujet (s'il ne décide pas explicitement de suivre le sujet, soit via le bouton "suivre" soit en répondant, il ne sera plus notifié à propos de celui-ci).

[Forum] Nouveau sujet créé avec un tag suivi

L'abonnement se ferait sur la page du forum reprenant les sujets ayant ce tag (ex : tag "zep"), toujours via un bouton dans la sidebar. Désabonnement de la même manière.

-> Mène au premier message du sujet, à charge pour l'utilisateur de suivre ou pas ce sujet (s'il ne décide pas le sujet explicitement, soit via le bouton "suivre" soit en répondant, il ne sera plus notifié à propos de celui-ci).

[Article/tuto] Nouveau commentaire dans un article/tuto suivi

Abonnement via un bouton "Suivre les commentaires de cet article/ce tutoriel" dans la sidebar sur la page de l'article/les différentes pages du tutoriel, ou lorsque l'on poste un commentaire. Désabonnement via un bouton dans la sidebar

-> Mène au premier message non-lu

[Tutoriel]Mise à jour

Notification si le tutoriel est mis à jour

-> Mène à la page d'accueil du tutoriel ? A un quelconque outil de diff ?

Abonnement via un bouton "Suivre ce tutoriel" dans la sidebar, désabonnement de la même manière.

Je n'ai pas jugé utile d'avoir la même chose pour les article, étant donné qu'un article est moins susceptible d'être complété au fur et à mesure. Il est cependant possible que suite à la ZEP 12, l'implémentation de ce type de notification pour les tutoriel la rendent de facto disponible pour les articles.

[Tutoriel] Nouvelle demande d'aide

Abonnement via un bouton dans la sidebar, désabonnemnt de la même manière. Eventuellement avec pop-up pour choisir le type de demande d'aide dont on veut être notifié.

-> Mène au tutoriel en question

[Validation] Nouveau tuto/article en validation

Abonnement et désabonnement via un bouton dans la sidebar. Si filtré par tag -> abonnement/désabonnement pour le tag.

-> Mène au tutoriel/article en question

[Général] Ping d'un user

Un message sur le forum contenant "@@<pseudo>" ("@@" ou autre chose, à définir, une discussion a déjà eu lieu à ce sujet mais où ?) envoie une notification au membre <pseudo>.

-> Mène au message contenant le ping

A prévoir en plus

• une section dans le profil pour gérer les notifs (ou du moins certains types de notifs)
• une éventuelle distinction visuelle des différents types de notifs (couleurs ? icones ? les deux ? autre ?)
• un filtre par type de notifs sur la page "Toutes mes notifications"
• la gestion des notifs via l'API
• plus de d'infos qu'actuellement dans les emails de notifications

Les grosses questions à se poser

Répondu dans le topic, liste mise à jour.

Oui, ça fera l'objet d'une ZEP secondaire/à part

Oui

Pour chaque type de notif : - notif dans le header ? - notif par email ?

L'API sera intégrée directement pendant le développement de la ZEP.

Ahh depuis le temps que j'attendais cette ZEP !

Pour les quelques questions je dirait :

Oui.

Non.

Avec un un truc comme par exemple @MachinChose. Je ne crois pas qu'une ZEP dédiée soit nécessaire.

Oui.

Les notifs lors du ping principalement, parce que pour ce qui est sujet/whatever il peut s'en désabonner comme il veut.

Voilà, c'était mon petit retour !

Les différents types de notifications proposés sont-ils intéressants ? Y a-t-il d'autres chose qu'il serait bien d'ajouter ?

Oui, c'est intéressant. J'ajouterais, si c'est faisable, une notification pour les nouveautés dans les demandes d'aide (cf. ZEP-03).

Comment introduire les ping vers les utilisateurs ? Faut-il une ZEP dédié à ça ?

La partie notification serait assez simple à implémenter, je pense, c'est plutôt la partie qui permettrait de détecter la présence d'un ping — et surtout sa validité — dans un texte qui serait plus compliquée. Donc une ZEP à part ne ferait pas forcément de mal.

Faut-il faire la différence entre "Suivre un tutoriel/article" (ie les mises à jour) et "Suivre les commentaires d'un tutoriel/article" ?

Oui. Clairement.

Qu'est-ce que l'utilisateur doit pouvoir gérer exactement via sa page de profil concernant les notifications ?

Je dirais, une liste des notifications auxquelles il est inscrit, par catégorie, la possibilité de se désinscrire d'une ou de toutes directement depuis cette interface, la possibilité d'activer/désactiver l'inscription à un type de notifications.

Pour ce dernier point, je m'explique. Pour les notifs ZEP-03 ou les notifs ping, il s'agirait de dire si on veut recevoir ce genre de notifs ou non. Pour les autres types (nouveautés sur un contenu donné), il s'agirait d'activer ou désactiver l'inscription automatique aux notifications quand on écrit un message/commentaire dans cette catégorie de contenu.

Oui, c'est intéressant. J'ajouterais, si c'est faisable, une notification pour les nouveautés dans les demandes d'aide (cf. ZEP-03).

un flux rss serait clairement plus adapté non?

Pour les mentions, la discussion se trouve ici : https://github.com/zestedesavoir/zds-site/issues/688

Je pense que le plus interessant à court terme est de faire en sorte qu'on puisse créer des types de notifs facilement, et de les distinguer visuellement. L'histoire du ping a des implications qui font qu'il vaudrait mieux le mettre hors de cette zep (ça implique de toucher au markdown, de modifier l'éditeur, etc.). Une autre façon de voir les ping, plus facile à implémenter, serait de permettre le signalement à un membre particulier : que le bouton signaler permettent de selectionner un membre particulier plutot que le staff.

D'ailleurs cette zep pourrait être l'occasion de fusionner les notifs avec les signalements. C'est finalement la même chose, juste une catégorie différente de notification.

La différence entre une notif et un signalement c'est qu'un signalement est envoyé à un groupe d'utilisateurs et une fois traité par un membre de ce groupe peu disparaitre pour l'ensemble du groupe alors qu'une notif est envoyée individuellement et est gérée par chaque membre.

J'irais même plus loin en fusionnant les notifications, les conversations privées et les signalements. L'API me fait réfléchir à l'application Android que je développerais derrière et cette fusion que je propose me séduit de plus en plus.

Bah ça reste pareil. Toute notif est envoyé à un groupe de personnes (toutes celle qui suivent un sujet pour celles de nouveaux messages, toutes les personnes dans un MP, etc.) et toute notif à une condition de supression (quand j'ai lu le message pour le forum ou MP, quand quelqu'un a résolu l'alerte, etc.). Ça reste exactement pareil : un événement à indiquer à un groupe de personnes avec une condition pour la virer de la liste rapide. Cette condition dépend du type de la notification mais basiquement c'est le même mecanisme qui est en jeux. Apres si vous voulez que toutes ces notifs et alertes soient présentés dans des groupes différents de la topbar, pourquoi pas, mais je ne vois pas de raisons qu'elles soient gérés différement coté technique.

Je ne suis pas convaincu Sinon à ce compte là un message forum c'est la même chose qu'un article.

Bon après c'est peu être moi qui raisonne mal, mais une alerte ce n'est pas la même chose qu'une notification. Une alerte il y a un émetteur, avec un motif et un message attaché. Tandis qu'une notification c'est simplement un destinataire et un lien vers l'élément ayant déclencher cette notification.

De la même manière il faut garder un historique des alertes, alors qu'au niveau des notifications rien n'empêche de supprimer une notification vue d'il y a un mois.

De mon point de vue ce qui pourrai être fait c'est qu'une alerte déclenche une notification pour les membres du staff.

La source : Dans tous les cas, tu seras d'accord pour dire qu'une conversation privée, une notification (comme nous l'entendons aujourd'hui) et un signalement te notifient qu'il y a du nouveau contenu à consulter.

Si nous sommes d'accord là dessus et si nous restons dans cette esprit d'être notifié de quelque chose, nous pourrions être notifié que nous avons reçu un nouveau message dans une conversation, qu'il y a eu un nouveau signalement, un nouveau message sur un forum que tu suis, un nouveau sujet dans un forum que tu suis, etc. Tu es notifié de plusieurs choses.

Ce que propose Kje n'est pas de dire qu'un signalement égale une notification mais qu'il verrait bien un "centre de notifications" qui regrouperait tous les différents types de notifications. Du moins, c'est comme ça que je le vois et je pense que c'est vraiment une bonne idée !

Nous sommes bien d'accord, et je trouve également que c'est une bonne idée.

Simplement que j'y vois deux parties distincte. Il y a le contenu (l'alerte) et la notification en elle même.

Là où j'ai tiqué c'est quand j'ai vu Kje parlé de "fusionner", je crois que le système d'alerte doit générer une notification lorsqu'une alerte est envoyée et non pas une fusion des deux systèmes.

Quand je parle de fusion, je parle niveau code dans le backend. Pour la question de comment s'est présenté à l'utilisateur, je m'en fout totalement et techniquement c'est le job de l'ergonome ou, a defaut, du dev front.

À noter, cette issue qui traîne sur GitHub depuis mi-septembre et qui est en lien direct avec notre affaire : https://github.com/zestedesavoir/zds-site/issues/1319

Hello

J'ajouterais, si c'est faisable, une notification pour les nouveautés dans les demandes d'aide (cf. ZEP-03).

Pourquoi pas. Avec possibilité de n'être notifié que pour certains types de demande (que les tutos qui cherchent un correcteur par exemple)

Comment introduire les ping vers les utilisateurs ? Faut-il une ZEP dédié à ça ?

La partie notification serait assez simple à implémenter, je pense, c'est plutôt la partie qui permettrait de détecter la présence d'un ping — et surtout sa validité — dans un texte qui serait plus compliquée. Donc une ZEP à part ne ferait pas forcément de mal.

Faut-il faire la différence entre "Suivre un tutoriel/article" (ie les mises à jour) et "Suivre les commentaires d'un tutoriel/article" ?

Oui. Clairement.

Je pense aussi, et Bat' aussi, je mets le 1er post à jour en fonction de ça. Si y a une levée de boucliers (peu probable) il sera toujours temps de changer d'avis.

Pour les autres types (nouveautés sur un contenu donné), il s'agirait d'activer ou désactiver l'inscription automatique aux notifications quand on écrit un message/commentaire dans cette catégorie de contenu.

J'avais pas pensé à cette possibilité, ça peut être intéressant.

un flux rss serait clairement plus adapté non?

On peut aussi utiliser un flux RSS pour les nouveaux sujets dans les forums qui nous intéressent. Certains préfèreront ça, d'autres seront contents d'avoir une petite notif. Perso, je n'utilise jamais les flux RSS, c'est vraiment pas un réflexe.

[…] J'irais même plus loin en fusionnant les notifications, les conversations privées et les signalements.

J'y ai pensé pendant que je rédigeais la ZEP puis j'ai pas proposé, je me suis dit que c'était trop révolutionnaire. Je suis d'accord avec le principe. Tout ça, au final, ça utilise des notifications, même si pour l'instant c'est pas considéré comme tel. Après, rien n'empêche de garder effectivement les 3 menus séparés côté front si c'est plus clair pour les utilisateurs.

EDIT : j'attends encore quelques temps au cas où y a d'autres avis qui iraient contre cette idée. Sinon je mettrais la ZEP à jour pour inclure ça aussi.

Concernant les mentions, je pense qu'effectivement, ça devra faire l'objet d'un développement séparé. De toute façon, le principal dans cette ZEP c'est de garder à l'esprit qu'il faut pouvoir ajouter facilement d'autres types de notifications, d'éléments déclencheurs, etc. Si c'est implémenté correctement, la partie notification des ping sera simple.

Idée supplémentaire : un valido pourrait demander à recevoir une notif quand un tuto arrive en validation, éventuellement avec filtre sur les catégories.

Top ! Merci, je savais bien que j'avais vu ça quelque part !

À noter, cette issue qui traîne sur GitHub depuis mi-septembre et qui est en lien direct avec notre affaire : https://github.com/zestedesavoir/zds-site/issues/1319

Yep, c'est même en voulant résoudre cette issue que j'ai remarqué à quel point les notifications avaient été codées un peu à l'arrache (pas du tout pareil quand il s'agit d'une notif forum que quand c'est une notif pour les commentaires d'un article).

Ca va sans doute être un gros chantier et faudra de la réflexion en amont mais je suis convaincue que ça peut donner un truc top tout ça

Peut-être inclure une option pour recevoir une notif en cas de commentaire pour l'auteur d'un tuto/article (directement sur la page de création du tuto/article) ?

Autre petite suggestion. Je ne sais pas vraiment si ça rendre dans le cadre de la ZEP, mais bon, je propose, ne sait-on jamais !

Avec cette refonte des notifs, on pourrait en profiter pour ajaxifier la chose, non ? Vu que certains développeurs ont déjà commencer à rajouter du Ajax un peu partout on pourrait continuer sur cette voie !

Si ça se fait, autant y aller directement avec les websockets je pense.

Bonne idée mais attention, faut faire rentrer ça dans une ZEP un peu plus costaud parce que, fonctionnellement, il faut faire un "pont" entre websockets et API REST qui sera certainement utilisé plus tard.

En gros, on n'a pas envie d'avoir un chemin de websocket par chemin REST (on va TOUT mettre dans la même websocket, c'est assez coûteux à ouvrir). Du coup, d'un modèle : "Une requête <-> une ressource" on passe à un modèle "Je m'inscris à une ressource <-> je reçois des updates".

L'approche naïve pour faire ça : intercaler un "serveur ws" entre le client et le serveur actuel. Qui, lui, fait du polling et push les modifs quand il y en a. C'est moche mais ça fonctionne généralement bien.

S'il faut servir les modifs directement dans une websocket il faut vraiment faire une spec' de comment on souhaite que les clients s'authentifient (passent leur token par wss), et plus généralement, comment ils indiquent les ressources auxquelles ils souhaitent souscrire, etc.

Je pense que de toute façon, une API est nécessaire pour les notifs, donc autant partir là-dessus, et à mon avis il y aura un chantier général sur "comment on sert les ressources de l'API via pub/sub de façon générique". Mais là il serait intéressant de faire un truc générique qui puisse servir partout (et qu'on n'utilisera pas forcément partout).

PS : pourquoi je dis qu'il faut une API REST ? Parce qu'à l'initialisation (démarrage du client) on préférera qu'il récupère les modifs par API, puis, pendant qu'il est connecté, reçoive les updates à travers la websocket. Ca me semble être le mode de fonctionnement le plus simple. J'ai toujours procédé de la sorte :

1/ on tacle le problème de servir des ressources à des clients distants (API)

2/ on repose là-dessus pour faire du temps-réel (polling API)

3/ quand on a un système sain et fonctionnel, on se pose la question des perfs (un client mobile qui fait du polling c'est coûteux pour lui) et là on passe aux websockets.

J'ignore si ça s'intègre à la ZEP, mais il pourrait être intéressant d'être informé en temps réel de la parution d'un nouveau message dans le sujet sur lequel on est en train de poster.

Le côté temps-réel risque de rendre les choses un peu compliquées.