Lexpage tout court, restons simple
—
Gnoupi
Discussions
Refonte de la messagerie interne
Bonjour,
Il y a certaines choses dans cette v4 qui ont été produites à l'arrache, pour dire de fournir le minimum syndical (et aussi parce que le développement de la v4 n'était pas vraiment prévu, c'est une extension de tests faits pour Django). En particulier, dans la liste des applications concernées, on retrouve la messagerie interne. Je compte faire un bon travail de refactoring de ce coté, car pour l'instant, c'est un peu le bronx... et je compte en profiter pour modifier son comportement, en fonction de vos retours/souhaits. J'ai donc une série de questions à cet effet...
La première concerne le format de la messagerie. On est passé de simples messages avec un seul destinataire et un sujet à une messagerie orientée "conversations" entre plusieurs destinataires. J'aime bien ce format, mais je m'interroge sur l'utilité d'un sujet. Actuellement, on débute une conversation (un thread) en précisant le sujet et les destinataires. On pourrait facilement envisager de ne pas intégrer de sujet, et qu'une conversation n'est identifiée que par les participants (un peu comme sur Facebook, si je ne me trompe pas). L'inconvénient principal est de ne pas pouvoir distinguer deux conversations entre les mêmes personnes. L'intérêt principal est de simplifier la messagerie, et éventuellement de permettre une extension future (à base de websockets) pour discuter en temps réel avec un (ou plusieurs) destinataires. Une sous-question liée au format de la messagerie concerne la définition des participants. Essentiellement pour des raisons techniques, il n'est pas possible pour l'instant d'inviter quelqu'un dans une conversation en cours. Cela présente, je pense, relativement peu d'intérêt dans l'absolu. Si on s'oriente vers cette feature, il faudrait définir ce que le "nouveau" participant peut voir : peut-il consulter les anciens messages de la conversation ou pas ? Et si on peut inviter une personne à rejoindre une discussion, peut-on également quitter une conversation en cours ?
La seconde question concerne l'utilité de distinguer plusieurs "boîtes" où sont stockées les conversations. Pour l'instant, on dispose grosso-modo de 4 possibilités :
* La boîte de réception, avec les conversations non-lues et celles qui sont lues et n'ont pas été bougées,
* La boîte d'archives, contenant les conversations qui sont archivées manuellement par l'utilisateur,
* L'étiquette "préférée" pour les conversations qui doivent être mises en évidence. Je doute de l'utilité de ce type de flag actuellement,
* La boîte des messages supprimés, invisible pour l'utilisateur, et qui contient les conversations qui sont supprimées par un des participants mais pas par tous.
Je me demande s'il est pertinent de conserver l'étiquette "préférée", ainsi que si c'est pertinent de permettre la suppression de conversations. A priori, il y a deux raisons pour lesquelles on peut souhaiter supprimer une conversation : (1) ne pas surcharger la boîte de réception afin de trier les conversations "utiles" des autres et (2) supprimer des preuves compromettantes de votre adultère Tchou. Pour le cas (1), on dispose de l'option d'archivage qui fait exactement la même chose. Pour le cas (2), la preuve reste dans la base de données tant que chaque participant n'a pas lui-même supprimé cette conversation. L'intérêt est donc limité. Je pense donc qu'il est judicieux de conserver un mécanisme de tri (peut-être qu'on peut prévoir davantage de dossiers, ou des dossiers créés par l'utilisateur, mais vu l'usage de la messagerie, je ne suis pas convaincu), mais je pense que la suppression est quelque peu facultative. Tout au plus, je peux prévoir une tâche automatique qui supprime les vieux messages sans participation depuis x jours (90 ?), afin (1) de ne pas surcharger la base de données, (2) faire le nettoyage auquel on peut s'attendre. Principal inconvénient : on ne peut plus se servir de la messagerie pour "stocker" de l'information à long terme.
La troisième question concerne les notifications. Malouk a indiqué qu'il serait intéressant de recevoir une notification par e-mail en cas de nouveaux messages. Je ne veux pas proposer des options "à tout va" liées au compte, donc j'aimerai un système moins intrusif que de systématiquement signaler les nouveaux messages. J'ai en tête une simple tâche automatique qui s'exécute dans le courant de la nuit, et qui signale aux utilisateurs ayant de nouveaux messages qu'il y a des messages en attente. On peut éventuellement augmenter la durée, à une fois par semaine plutôt que chaque jour, pour limiter le "flood". Le principal avantage est d'avoir une esquisse de notifications, sans avoir le principal inconvénient qui consiste à recevoir plein de mails, vu le format des conversations. L'inconvénient majeur est que les notifications ne seront pas faites en temps réel, et qu'il y a donc potentiellement un délai entre la réception du message et l'envoi du mail. Mais ces notifications seraient plutôt à voir comme des "rappels de messages non-lus" pour les personnes passant moins régulièrement, et pour ne pas rater de tels messages, plutôt que d'être prévenu instantanément en cas de nouveaux messages.
Un autre aspect concerne le formatage autorisé des messages. Anciennement, dans la v3, on pouvait utiliser exactement le même formatage que sur le forum, à savoir du bbcode. Avec la v4, et principalement avec le mode "conversation" de la messagerie, j'ai préféré limiter le formatage à des choses simples : support des smiley, et transcription des adresses en liens cliquables. Je ne suis pas convaincu que supporter pleinement le bbcode ou un formatage plus avancé que celui de la v4 soit une bonne idée, essentiellement parce que cette messagerie n'a pas pour vocation de faire des choses "complexes", mais simplement de fournir un mécanisme permettant de discuter entre les personnes inscrites au site.
J'ai déjà quelques préférences au niveau des pistes évoquées, j'en parlerai dans un message ultérieur si ce topic ne fait pas un bide complet
Il y a certaines choses dans cette v4 qui ont été produites à l'arrache, pour dire de fournir le minimum syndical (et aussi parce que le développement de la v4 n'était pas vraiment prévu, c'est une extension de tests faits pour Django). En particulier, dans la liste des applications concernées, on retrouve la messagerie interne. Je compte faire un bon travail de refactoring de ce coté, car pour l'instant, c'est un peu le bronx... et je compte en profiter pour modifier son comportement, en fonction de vos retours/souhaits. J'ai donc une série de questions à cet effet...
La première concerne le format de la messagerie. On est passé de simples messages avec un seul destinataire et un sujet à une messagerie orientée "conversations" entre plusieurs destinataires. J'aime bien ce format, mais je m'interroge sur l'utilité d'un sujet. Actuellement, on débute une conversation (un thread) en précisant le sujet et les destinataires. On pourrait facilement envisager de ne pas intégrer de sujet, et qu'une conversation n'est identifiée que par les participants (un peu comme sur Facebook, si je ne me trompe pas). L'inconvénient principal est de ne pas pouvoir distinguer deux conversations entre les mêmes personnes. L'intérêt principal est de simplifier la messagerie, et éventuellement de permettre une extension future (à base de websockets) pour discuter en temps réel avec un (ou plusieurs) destinataires. Une sous-question liée au format de la messagerie concerne la définition des participants. Essentiellement pour des raisons techniques, il n'est pas possible pour l'instant d'inviter quelqu'un dans une conversation en cours. Cela présente, je pense, relativement peu d'intérêt dans l'absolu. Si on s'oriente vers cette feature, il faudrait définir ce que le "nouveau" participant peut voir : peut-il consulter les anciens messages de la conversation ou pas ? Et si on peut inviter une personne à rejoindre une discussion, peut-on également quitter une conversation en cours ?
La seconde question concerne l'utilité de distinguer plusieurs "boîtes" où sont stockées les conversations. Pour l'instant, on dispose grosso-modo de 4 possibilités :
* La boîte de réception, avec les conversations non-lues et celles qui sont lues et n'ont pas été bougées,
* La boîte d'archives, contenant les conversations qui sont archivées manuellement par l'utilisateur,
* L'étiquette "préférée" pour les conversations qui doivent être mises en évidence. Je doute de l'utilité de ce type de flag actuellement,
* La boîte des messages supprimés, invisible pour l'utilisateur, et qui contient les conversations qui sont supprimées par un des participants mais pas par tous.
Je me demande s'il est pertinent de conserver l'étiquette "préférée", ainsi que si c'est pertinent de permettre la suppression de conversations. A priori, il y a deux raisons pour lesquelles on peut souhaiter supprimer une conversation : (1) ne pas surcharger la boîte de réception afin de trier les conversations "utiles" des autres et (2) supprimer des preuves compromettantes de votre adultère Tchou. Pour le cas (1), on dispose de l'option d'archivage qui fait exactement la même chose. Pour le cas (2), la preuve reste dans la base de données tant que chaque participant n'a pas lui-même supprimé cette conversation. L'intérêt est donc limité. Je pense donc qu'il est judicieux de conserver un mécanisme de tri (peut-être qu'on peut prévoir davantage de dossiers, ou des dossiers créés par l'utilisateur, mais vu l'usage de la messagerie, je ne suis pas convaincu), mais je pense que la suppression est quelque peu facultative. Tout au plus, je peux prévoir une tâche automatique qui supprime les vieux messages sans participation depuis x jours (90 ?), afin (1) de ne pas surcharger la base de données, (2) faire le nettoyage auquel on peut s'attendre. Principal inconvénient : on ne peut plus se servir de la messagerie pour "stocker" de l'information à long terme.
La troisième question concerne les notifications. Malouk a indiqué qu'il serait intéressant de recevoir une notification par e-mail en cas de nouveaux messages. Je ne veux pas proposer des options "à tout va" liées au compte, donc j'aimerai un système moins intrusif que de systématiquement signaler les nouveaux messages. J'ai en tête une simple tâche automatique qui s'exécute dans le courant de la nuit, et qui signale aux utilisateurs ayant de nouveaux messages qu'il y a des messages en attente. On peut éventuellement augmenter la durée, à une fois par semaine plutôt que chaque jour, pour limiter le "flood". Le principal avantage est d'avoir une esquisse de notifications, sans avoir le principal inconvénient qui consiste à recevoir plein de mails, vu le format des conversations. L'inconvénient majeur est que les notifications ne seront pas faites en temps réel, et qu'il y a donc potentiellement un délai entre la réception du message et l'envoi du mail. Mais ces notifications seraient plutôt à voir comme des "rappels de messages non-lus" pour les personnes passant moins régulièrement, et pour ne pas rater de tels messages, plutôt que d'être prévenu instantanément en cas de nouveaux messages.
Un autre aspect concerne le formatage autorisé des messages. Anciennement, dans la v3, on pouvait utiliser exactement le même formatage que sur le forum, à savoir du bbcode. Avec la v4, et principalement avec le mode "conversation" de la messagerie, j'ai préféré limiter le formatage à des choses simples : support des smiley, et transcription des adresses en liens cliquables. Je ne suis pas convaincu que supporter pleinement le bbcode ou un formatage plus avancé que celui de la v4 soit une bonne idée, essentiellement parce que cette messagerie n'a pas pour vocation de faire des choses "complexes", mais simplement de fournir un mécanisme permettant de discuter entre les personnes inscrites au site.
J'ai déjà quelques préférences au niveau des pistes évoquées, j'en parlerai dans un message ultérieur si ce topic ne fait pas un bide complet
Vu le peu d'engouement, j'imagine que je vais faire à ma tête, et dans quelques semaines, on me demandera de tout changer ?
Moi qui n'envoi ni ne reçoit jamais de Lexmails, je me souvenais même plus que ça existait
T'as des grosses stats d'utilisation en nb de messages/jours ?
T'as des grosses stats d'utilisation en nb de messages/jours ?
Je viens de créer un lexmail dans la v3, et l'ID était "23886" ou quelque chose du genre, donc je pense qu'il y a eu un certain usage, même si Twicy a sans doute faussé les stats. Je n'ai pas vraiment d'idée du "succès" de cette feature (j'ai la flemme d'aller checker via phpmyadmin ).
Pour la v4, je pense que c'est relativement limité, et que ça va plutôt concerner des personnes qui se connaissent bien et qui discutent régulièrement, autrement que par Facebook. Je ne crois pas que c'est une fonction indispensable, mais c'est tout de même bien pratique. Actuellement, il y a une quinzaine de conversations impliquant un peu plus de 25 personnes (je n'ai pas les chiffres exact, je me base sur les clés primaires, je veux pas aller voir vos conversations dans phpmyadmin
).
Pour répondre à Tchou > y a un peu de ça, c'est "kewl" de le faire Il y a deux soucis que je dois régler rapidement (notamment sur la gestion des messages non-lus et le cache) et, tant qu'à faire, je voulais en profiter pour peaufiner un peu cette partie. Accessoirement, je dois avoir en tête deux éléments :
- Le premier concerne quelque chose que j'aimerai faire rapidement : des notifications. Actuellement, les notifications sont des "!" rouges dans les menus (nouveau message, billet à valider et draft en attente). J'aimerai centraliser les notifications (ou en tout cas leur gestion) afin de faciliter un peu les choses, et surtout de pouvoir utiliser ce mécanisme, dans l'hypothèse d'un Twicy v4 (anciennement l'information parvenait par Lexmail, je n'ai pas envie de refaire ça). Le système de notification doit permettre de prévenir plusieurs personnes, d'associer des actions et des déclencheurs pour auto-dismiss une notification (par exemple, en cas de billet à valider, les modérateurs doivent avoir la notification mais si l'un d'entre eux valide (ou refuse) le billet, ce n'est pas la peine de laisser la notification chez les autres).
- Le second concerne les conversations au sens large (minichat et conversations "internes"). J'ai bon espoir de pouvoir intégrer quelque chose à base de websocket un jour, et que j'aimerai que les conversations "directes" entre lexpagiens soient directement intégrées dans les conversations internes actuelles.
). Pour la v4, je pense que c'est relativement limité, et que ça va plutôt concerner des personnes qui se connaissent bien et qui discutent régulièrement, autrement que par Facebook. Je ne crois pas que c'est une fonction indispensable, mais c'est tout de même bien pratique. Actuellement, il y a une quinzaine de conversations impliquant un peu plus de 25 personnes (je n'ai pas les chiffres exact, je me base sur les clés primaires, je veux pas aller voir vos conversations dans phpmyadmin
). Pour répondre à Tchou > y a un peu de ça, c'est "kewl" de le faire
Il y a deux soucis que je dois régler rapidement (notamment sur la gestion des messages non-lus et le cache) et, tant qu'à faire, je voulais en profiter pour peaufiner un peu cette partie. Accessoirement, je dois avoir en tête deux éléments : - Le premier concerne quelque chose que j'aimerai faire rapidement : des notifications. Actuellement, les notifications sont des "!" rouges dans les menus (nouveau message, billet à valider et draft en attente). J'aimerai centraliser les notifications (ou en tout cas leur gestion) afin de faciliter un peu les choses, et surtout de pouvoir utiliser ce mécanisme, dans l'hypothèse d'un Twicy v4 (anciennement l'information parvenait par Lexmail, je n'ai pas envie de refaire ça). Le système de notification doit permettre de prévenir plusieurs personnes, d'associer des actions et des déclencheurs pour auto-dismiss une notification (par exemple, en cas de billet à valider, les modérateurs doivent avoir la notification mais si l'un d'entre eux valide (ou refuse) le billet, ce n'est pas la peine de laisser la notification chez les autres).
- Le second concerne les conversations au sens large (minichat et conversations "internes"). J'ai bon espoir de pouvoir intégrer quelque chose à base de websocket un jour, et que j'aimerai que les conversations "directes" entre lexpagiens soient directement intégrées dans les conversations internes actuelles.