Les conversations significatives ont lieu lorsque chaque personne dans la pièce a entendu les pensées des autres, et une chronologie plate et linéaire a toujours été le meilleur moyen de rendre cela possible sur Discourse. Mais le format plat ne convient pas à toutes les communautés. Dans les forums plus vastes et plus dynamiques, des milliers de réponses sur une seule chronologie rendent impossible pour quiconque de suivre. C’est pourquoi nous expérimentons prudemment cette année une vue de réponses entièrement imbriquée, et nous pensons qu’elle convient parfaitement aux communautés qui ont dépassé le format plat.
Ce qui a commencé comme un plugin expérimental est devenu un projet intégré directement dans Discourse. Voici un aperçu de ce à quoi ressemble un sujet imbriqué pour le moment :
Les paramètres du site pour activer cette fonctionnalité sont disponibles dans l’interface d’administration. Accédez à la section « Réponses imbriquées » pour contrôler la fonctionnalité, les modes de tri par défaut, la profondeur maximale, et plus encore.
Feuille de route
Au moment de la rédaction de cet article, les réponses imbriquées en sont à leurs débuts. La feuille de route n’est pas encore entièrement définie. Voici quelques éléments que nous savons que nous allons mettre en œuvre :
Une meilleure expérience mobile
Repenser la chronologie des sujets pour la vue imbriquée. Pour le moment, il n’y a pas de chronologie dans les sujets lorsque le mode de réponses imbriquées est actif.
Ajouter au moins un nouveau mode de tri pour les messages avec décroissance selon l’âge, similaire à notre mode « Populaire » pour les listes de sujets.
Limitations
Lorsque l’imbriquation est activée pour une catégorie, les sujets existants restent en mode plat. Chaque sujet peut être basculé individuellement via la clé d’administration, mais il n’existe actuellement aucun moyen de convertir une catégorie existante en mode imbriqué.
Nous apprécions vos retours
Nous avons besoin de vos retours et de votre expérience d’utilisation de cette fonctionnalité pour orienter son développement. Si cela semble correspondre à votre communauté, essayez-la et dites-nous ce que vous et vos utilisateurs en pensez !
OMG OUI. Excellent timing aussi. Je migre ce soir un forum vers un nouveau serveur avec 2 conteneurs, et j’ai hâte de basculer celui-ci vers le nouveau quand la saison régulière et nos pools sportifs commenceront dans quelques semaines. Ce devrait aussi être un bon cas d’utilisation pour tester.
C’est super cool d’avoir les options de discussions plates et intégrées — merci pour cela @markvanlan et l’équipe.
Ce devrait être amusant de voir ce que ça casse aussi
Juste pour noter : lorsqu’il y a de nouvelles réponses dans plusieurs branches de l’arborescence, il semble que la vue en fil unique ne m’en ait montré qu’une à la fois. J’ai dû revenir plusieurs fois, le nombre de non-lus diminuant d’un à chaque fois.
D’accord, je ne suis pas sûr que le basculement en masse soit réalisable pour des catégories contenant des dizaines de milliers de sujets. Les tâches de conversion par lots de Rails pourraient-elles être une option ?
Et est-ce réversible ? Peut-on convertir un sujet threadé en un sujet plat ?
Oui, je suis d’accord avec vous. C’est une limitation pour l’instant, et nous continuerons absolument à y réfléchir.
La principale raison pour laquelle j’ai choisi de ne pas convertir les sujets historiques d’une catégorie lorsque cette option est activée, c’est que les utilisateurs sont susceptibles d’interagir différemment. En mode linéaire, les différents boutons Répondre ont moins d’importance. Le message s’ajoute tout en bas du sujet. Je ne suis pas sûr que les utilisateurs appuient toujours intentionnellement sur le “bon” bouton, celui qui correspondrait à la vue imbriquée.
En gros, je crains que les administrateurs n’activent cette option pour les sujets historiques et que la conversation devienne soudainement illisible. Nous continuerons à y réfléchir. Le changement le plus simple auquel je puisse penser est d’afficher une fenêtre modale lorsque le paramètre de catégorie est basculé, demandant : “Voulez-vous appliquer cela aux sujets existants ?”
J’ai toujours pensé que les libellés « Répondre » pourraient être plus spécifiques — alors il y a quelque temps, j’ai utilisé du CSS personnalisé pour ajouter du contexte :
/* ajouter du texte au bouton Répondre pour le message original (aka Sujet) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Ajouter ce contenu après Répondre
content: " à ce Sujet";
}
}
}
}
/* ajouter du texte au bouton Répondre pour tous les messages suivants (je les appelle commentaires) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Ajouter ce contenu après Répondre
content: " à ce commentaire";
}
}
}
}
/* ajouter du texte au bouton bleu Répondre (au Sujet) apparaissant à la fin de la page */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Ajouter ce contenu après Répondre
content: " au Sujet principal";
}
}
}
}
Le problème avec cette solution est qu’elle ne sera pas traduite dans l’interface utilisateur pour les membres ayant une langue autre que l’anglais dans leurs préférences
Cela suggère-t-il qu’il faudrait d’abord le tester dans nos communautés de manière isolée, avant que nous ne lancions la conversion de tous les sujets existants ?
Cela fonctionnerait, à condition que cela prenne en charge des dizaines de milliers de sujets.
Mais il faudrait bien préciser qu’il n’y a pas de retour en arrière possible après cela
Cette fonctionnalité sera-t-elle implémentée d’abord ici sur Meta, ou sur https://try.discourse.org afin que nous puissions la tester en dehors de nos environnements de production ?
Si c’était ma communauté, je le testerais d’abord de manière isolée. D’un autre côté, vous obtiendriez des retours plus précieux plus rapidement en l’activant pour l’ensemble de votre communauté . Blagues à part, je pense que tester de manière isolée est probablement judicieux, mais il n’y a pas de migration de données destructrice ici. Cela peut être activé et désactivé en toute sécurité. Aucune décision que vous prendrez ici ne vous bloquera dans l’une ou l’autre direction.
Je suppose que j’ai en quelque sorte répondu accidentellement à cette partie ! Activer l’imbrication crée simplement un enregistrement nested_topic pour chaque sujet dans la base de données et lance un travail pour calculer les comptes de réponses le long de l’arbre d’ascendance. Désactiver l’imbrication supprime cet enregistrement nested_topic et vous revenez à un système plat, sans problème.
Y a-t-il une raison pour laquelle cela ne peut être activé ou désactivé que par le personnel et non par les utilisateurs normaux ? Lorsque j’ai vu que cela arrivait sur Meta, je pensais qu’il aurait été ajouté au menu des types de publication, mais l’interrupteur est caché derrière l’icône de clé à molette du personnel.
Je ne suis pas sûr d’avoir un cas d’usage spécifique, je pensais simplement que cela aurait été mis en œuvre de la même manière que le vote sur les publications.
Nous ne souhaitons pas que ce soit une décision ou une préférence de l’utilisateur. C’est aux administrateurs de décider comment leur site doit fonctionner. Les deux paradigmes sont très différents et les utilisateurs ne devraient pas interagir de manière si différente sur le même contenu. C’est du moins notre pensée actuelle.
Les blocs publicitaires ne fonctionnent pas bien dans cette structure, et la conversion des sujets provoque souvent un bug où les éléments de l’écran disparaissent et seul le titre peut être modifié.
Super fonctionnalité ! Cependant Je suis plus curieux au sujet du tri Top / Nouveau / Ancien que de la disposition imbriquée elle-même. J’ai déjà implémenté des contrôles de tri similaires dans mon application mobile (un client Discourse) et j’aimerais beaucoup prendre en charge cela nativement plutôt que de recourir à ma méthode actuelle, bien qu’elle fonctionne comme je le montre ci-dessous.
En examinant le code source, je vois que GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} renvoie le sujet en vue imbriquée trié selon le mode choisi. Ma question : y a-t-il un intérêt à exposer uniquement le tri via l’endpoint existant /t/{slug}/{topic_id}.json (par exemple ?sort=top) afin que les clients en vue plate puissent également en bénéficier ?
Si le tri était disponible en vue plate, les clients tiers pourraient opter pour cette fonctionnalité sans adopter le modèle de rendu en vue imbriquée.
Je comprends que la structure des données de la vue imbriquée (messages racines + enfants chargés à la demande) est ce qui rend le tri côté serveur réalisable, et que la vue plate utilise une pagination différente. Si un tri complet en vue plate n’est pas réaliste pour des raisons de performance, même un paramètre optionnel ?sort=top&limit=N suffirait pour alimenter une vue « points forts ».
. Blagues à part, je pense que tester de manière isolée est probablement judicieux, mais il n’y a pas de migration de données destructrice ici. Cela peut être activé et désactivé en toute sécurité. Aucune décision que vous prendrez ici ne vous bloquera dans l’une ou l’autre direction.
