ZEP-21 : Refonte de l'interface des messages privés

Pourquoi revoir l'interface des messages privés (MP) ?

Aujourd'hui il n'existe qu'une seule "boite" de réception où sont stocker ses messages privés. Ce n'est pas très pratique lorsque l'on a de nombreux messages privés : un système de tri s'impose.

Les changements

Ajout de différents dossiers

Le plus gros changement apporté serait l'ajout de différents dossiers dans lesquels il est possible de stocker ses messages privés. Il serait possible de déplacer des messages vers un dossier pour pouvoir facilement les retrouver. En cas de suppression d'un dossier, l'utilisateur se verrait proposer 2 options :

• supprimer les messages privés contenus dedans ;
• les déplacer dans un autre dossier.

Les dossiers auraient une position pour pouvoir les ordonner dans le menu. Il n'existe qu'un seul niveau de dossier (pas de sous dossier, KISS).

Une première maquette ressemblerait à ceci :

Recherche dans ses MP

La recherche de telle ou telle information cachée dans un message est parfois pratique et actuellement impossible. L'idée serait d'implémenter une recherche assez simple avec la possibilité de spécifier :

• un ou plusieurs dossiers ;
• un ou plusieurs auteurs ;
• une recherche dans le titre et/ou la description uniquement ;
• spécifique un fourchette de dates (ex : du jour A ou jour B ou depuis le jour C).

Des brouillons

Encore une fonctionnalité qui manque : les brouillons. Exactement comme les MP normaux sauf qu'ils ne sont pas envoyés et qu'on peut les modifier une infinité de fois.

Des messages pour l'ajout ou le départ d'un membre du MP

Aujourd'hui on ne sait pas quand un membre est ajouté à la conversation ou lorsque l'un part de la conversation. L'idée serait de simplement mettre un message comme la maquette ci dessous.

Pour la réalisation technique, on ajouterai juste 1 champ à notre modèle par défaut : action. L'idée est de créer un message normal mais qui contient ce champ action remplis que si une telle action est faite (je vois les actions suivantes : QUITE, ADD ou ADD BY etDELETE ou DELETE BY. Ainsi on a a pas besoin de coder un modèle en plus car la majorité des informations sont déjà présentes.

Autoriser un staff participant à un MP à ajouter des membres

L'idée a été suggéré par plusieurs membres du staff c'est pourquoi ça semble assez utile. Un membre staff aurait donc les droits de gestion des membres d'un message privé.

Marquer un mp comme non-lu

Très simple à mettre en place et pourtant si pratique.

Lier certains messages à un contenu

Actuellement une action sur un contenu (publication, mise à jour, etc) = un nouveau sujet. C'est vite pénible et on se retrouve avec des dizaines de pages dans ses MP.

Un nouveau champ serait ajouté pour lier un contenu à un sujet MP afin d'avoir toutes les informations sur le même sujet.

Un système de tags

Des tags automatiques

Les tags seraient automatiquement ajouté lors de ma création d'un MP et l'utilisateur n'a aucun pouvoir dessus. Il peut simplement les voir et donc filtrer ses messages avec.

Les tags concerneraient une action spécifique qu'un utilisateur a fait et qui a entraînée ce MP (ex : demande d'aide via la ZEP-3, ajout à un tuto, publication d'un tuto, etc). Il y aurait donc un tag par action spécifique, ces actions étant à définir.

Des tags manuels

Un utilisateur a la possibilité d'ajouter des tags sur ces MP afin de les classifier. Ces tags sont personnels.

Sélection multiple

La refonte des MP en profiterai pour dynamiser les actions sur les MP avec notamment la possibilité de sélection multiple pour des actions

Implémentation proposée

Le code des MP serait en même temps entièrement revu dans le but de faciliter l'implémentation de l'API concernant les MP. Le travail pourrait même être fait en parallèle.

Première étape : différents dossier

Cela comprend la possibilité de créer, modifier et supprimer les dossier ainsi que de déplacer des message privés dans ces dossiers.

Seconde étape : actions sur les messages privés

Cela comprend toutes les autre améliorations proposées (ajout de participant, message lors d'un ajout ou d'un départ, etc).

Conclusion

Merci d'avoir pris le temps de lire tout ça, toutes les remarques et suggestions sont les bienvenues.

Historique

Version 1

http://paste.awesom.eu/rLMT

Création de la ZEP

Version 2

http://paste.awesom.eu/CQXX

• Suppression des catégories pour les dossiers.
• Éclaircissements sur l'API.
• Proposition d'un système de tag (merci @pierre_24).
• Ajout de la proposition de @pierre_24 sur la réécriture du code qui gère les destinataires.
• Ajout de la proposition de poupou9779 sur la sélection multiple.
• Spécification techniques pour les messages spéciaux lors du départ ou de l'arrivé d'un membre dans la conversation.

Version 3

• ajout d'une précision sur le fait qu'il n'y a pas de sous-dossier
• ajout d'une partie « Lier certains messages à un contenu »
• mise à jour de la partie sur les tags
• ajout d'un partie « marquer un mp non-lu » (merci Thunderseb)

Perso je suis 100% pour. Je n'ai pas le temps de détailler mais quelques remarques :

• j'ai pas trop compris le but des catégories mais je pense que c'est superflu, au moins en v1
• Je ne suis pas surs que faire l'API au passage soit tres pertinent (double de travail) sachant que celle-ci n'est pas encore spécifié cependant il me semble pertinent de prendre en compte son existence : en profiter pour ré-écrire le module pour qu'il soit facile de lui accoler une API, comme fait pour les tutos dans une autres zep.

J'aime beaucoup les idées, et voici mes remarques :

• J'ai peur que "catégorie" et "dossiers" ne reviennent un peu au même. Je trouverai ceci dit logique que ces "catégories" en question reviennent au même que les "tags" du forum (et puisse être ajouté de même, directement dans le titre). Ainsi, on standardiserait les titres de certains MP (exemple : "ajout comme auteur d'un tuto", "validation d'un tuto", …) en leur donnant des tags spécifiques qui permettrait de s'y retrouver ou de les éliminer le cas échéant (pourquoi pas aussi un "tag" par tuto ?). Je trouverai ça sur-puissant, mais c'est peut-être ce que tu sous-entend par "catégories".
• Autrement dit, les "dossiers" seraient selon moi un classement fait par l'user, tandis que les tags seraient pour les messages de services "imposé à l'utilisateur" (ce qui justifierai la co-existance des deux systèmes).
• Pourquoi ne pas en profiter pour réécrire le code qui gère les destinatires ?

• Je soutiens la remarque de Kje disant que l'implémentation de l'API n'est pas une fin en soit et qu'autant faire du code un maximum propre, mais pas forcément API-ready : c'est se lancer deux défis à la fois et ça risque de casser.

Excellente initiative !

Pour ce qui est des catégories, ce serait probablement trop contraignant : il est préférable de permettre au membre d'organiser sa boîte à sa guise, avec ses propres dossiers.

Par contre, un système de tags comme l'explique pierre serait très intéressant pour trier et rechercher. On aurait des tags par défaut pour les messages officiels mais le destinataire pourrait en outre ajouter des tags aux messages reçus : en plus de les ranger grossièrement dans des dossiers, cela lui permettrait de décrire plus ou moins chaque message et, d'une part d'accélérer les recherches dans un dossier, d'autre part de permettre les recherches du genre "tous les messages estampillés "intime" dans tous les dossiers". Est-il judicieux de permettre à l'expéditeur d'ajouter des tags ? Je ne pense pas puisque qu'après tout c'est ma boîte et donc moi qui décide comme l'organiser.

Salut,

1. Ajout de différents dossiers : Une fonctionnalité qui était disponible sur le feu SdZ et qui manque cruellement maintenant.
2. Des dossiers par catégorie : J'aimerais bien être maitre de mes dossiers. Je ne suis pas du tout convaincu par ces dossiers catégories.
3. Recherche dans ses MP : Pourquoi pas mais je suppose que tu ne comptes pas utiliser solr ?
4. Des brouillons : J'en ai jamais eu l'utilité mais l'idée est très sympa !
5. Des messages pour l'ajout ou le départ d'un membre du MP : A voir comment l'implémenté mais l'idée est sympa. 6 Autoriser un staff participant à un MP à ajouter des membres : +1000.

Pour l'API, je dis banco gustavi. Si tu veux, je me charge d'écrire la spécification de l'API dans cette ZEP ou une ZEP fille et je bosserais avec toi dessus. Comme tu veux. Je pense que les MPs est un bon module à intégrer à l'API avant les forums.

Je passe juste pour dire que je soutiens l'utilisation de l'user Un caribou dans tes exemples et captures d'ecran

_{Et que j'approuve tout mes VDD au passage et encourage de tout mes sabots cette ZEP !}

Merci à tous pour vos retours. Je vais donc apporter les modifications suivantes ce soir si personne n'y voit d'objection :

• Suppression des catégories pour les dossiers, ça semble inutile et je ne pense pas avoir été bien compris là dessus (l'utilisateur crée lui même ses catégories dans lesquelles il range ses dossier).
• Éclaircissements sur l'API : le but est de travailler sur une ZEP fille en même temps pour voir si on répond comme il faut aux exigences de l'API. Dans ce cas on facilitera la mise en place de l'API des MP mais on la codera une fois cette ZEP terminée.
• Proposition d'un système de tag (merci @pierre_24) : des tags spéciaux pour les MP liés au fonctionnement du site (validation, etc) mais également au contenu (tuto-<id>-<slug> ?). Ça permettrai de chercher plus facilement du contenu. Une question de pose : un utilisateur peut-il mettre des tags ? Votre avis là dessus m'intéresse !
• Ajout de la proposition de @pierre_24 sur la réécriture du code qui gère les destinataires

L'idée est de créer un message normal mais qui contient un champ spécial qui n'est remplis que si une telle action est faite (je vois les actions suivantes : QUITE, ADD ou ADD BY (qui nécessite un champ spécial pour l'utilisateur qui l'a ajouté, ça permet plus de clarté et de transparence) et DELETE ou DELETE BY (idem). Ainsi on a a pas besoin de coder un modèle en plus car la majorité des informations sont déjà présentes.

Éclaircissements sur l'API : le but est de travailler sur une ZEP fille en même temps pour voir si on répond comme il faut aux exigences de l'API. Dans ce cas on facilitera la mise en place de l'API des MP mais on la codera une fois cette ZEP terminée.

Comme ça, ça me va

(merci @pierre_24)

Mais de rien

Une question de pose : un utilisateur peut-il mettre des tags ? Votre avis là dessus m'intéresse !

Je suis sensible à l'argument de "Vayel" disant que "Je ne pense pas puisque qu'après tout c'est ma boîte et donc moi qui décide comme l'organiser". Par ailleurs, ça soulève pour moi d'autres questions qu'il va être intéressant de débattre :

• Est ce que tout les participants d'un MP on le "droit" de voir les tags, ou est ce que c'est personnel (ma réponse : ça me semblerai logique que ce soit personnel)
• Est ce que pour les MP à plusieurs participants, chacun à le droit de mettre ces tags comme il le souhaite ? (ma réponse: oui, ça semblerai logique, mais c'est peut-être plus tordu coté implémentation).

De là, j'aurais tendance à dire que non, il ne serait pas judicieux que l'expéditeur puisse ajouter des tags de lui-même (à part le cas des "message de service"), mais que l'édition se ferai à posteriori.

En ce qui me concerne, l'ajout de tags serait personnel et dans l'unique fin de faciliter la recherche dans nos messages.

Côté implémentation, j'ignore comment c'est fait à l'heure actuelle, mais la base pourrait s'organiser ainsi :

• Table : messages

Contient tous les messages privés de tout le monde, avec auteur, date, contenu…

• Table : conversations

Ensembles de lignes (participants, messages, autre).

• Table : boîtes privées

Ensemble de lignes (membre, conversation, dossier, tags, autre)

Enfin peut-être que le système actuel est déjà très bien, ce n'est qu'une idée en l'air.

@Vayel: actuelement, c'est déjà comme ça que ça se passe, donc une table PrivateTopic (ta table "message") et une table PrivatePost (ta table "conversation"). Dans la logique, il "suffirait" d'ajouter une table PrivateDirectory et une table PrivateTag:)

Éclaircissements sur l'API : le but est de travailler sur une ZEP fille en même temps pour voir si on répond comme il faut aux exigences de l'API. Dans ce cas on facilitera la mise en place de l'API des MP mais on la codera une fois cette ZEP terminée.

Si tu veux, je peux me charger de sa création dans la journée.

L'idée est de créer un message normal mais qui contient un champ spécial qui n'est remplis que si une telle action est faite (je vois les actions suivantes : QUITE, ADD ou ADD BY (qui nécessite un champ spécial pour l'utilisateur qui l'a ajouté, ça permet plus de clarté et de transparence) et DELETE ou DELETE BY (idem). Ainsi on a a pas besoin de coder un modèle en plus car la majorité des informations sont déjà présentes.

Je ne vois pas exactement la finalité mais l'idée générale me semble bonne donc pourquoi pas.

Je ne vois pas exactement la finalité mais l'idée générale me semble bonne donc pourquoi pas.

Ne pas avoir à faire une table spéciale et des requêtes alambiquées pour faire ça

Salut, je reposte ici ce que j'avais posté en dehors de la ZEP (que je n'avais pas vue shame on me) :

Mis à jour !

Ça serait cool de ne pas laisser cette ZEP prendre la poussière, car les améliorations qu'elle propose sont assez cool !

J'ai une petite suggestion qui m'est venu ce soir en lisant mes MPs. Ne serait-il pas possible de créer des dossiers automatique en fonction des features du site ? Je pense notamment aux MPs qui préviennent d'une faute dans un tutoriel. On pourrait facilement imaginer que ces MP aillent automatique dans un dossier prévu à cet effet. Je conçois que cette fonctionnalité sera plus utile aux gens qui ont beaucoup de tutos/articles publiés, mais bon !

Petite mise à jour là dessus ! Aller on me déterre tout ça

Une ZEP vraiment nécessaire .

(+ la possibilité de marquer un MP comme non-lu serait bien).

C'est rajouté, merci

(+ la possibilité de marquer un MP comme non-lu serait bien).

C'est quoi le comportement attendu par rapport à la règle qui dit "une fois qu'au moins 1 participant a lu un message, il est impossible d'éditer les nouveaux messages" ?

Alors c'est pas lu mais répondu donc ça ne pose pas de souci normalement.

Au temps pour moi, j'étais persuadé que le comportement était identique à celui des sujets publics.