Voyez-vous cela uniquement pour les canaux où les fils de discussion ont été récemment activés et où le client n’a pas encore été actualisé depuis ce changement ? Ou aussi dans les cas où vous avez déjà actualisé une fois depuis l’activation des fils de discussion ?
Je pense que nous avons vu quelque chose de similaire il n’y a pas si longtemps et que nous l’avons corrigé.
Peut-être est-ce réapparu ? Si vous mettez à jour vers la dernière version de tests-passés maintenant, voyez-vous toujours le problème ?
Tous nos canaux de discussion ont été activés récemment.
Et je ne suis pas sûr quand ou comment les utilisateurs ont actualisé leurs navigateurs. Ne serait-il pas judicieux de forcer une actualisation complète du système à chaque fois qu’une mise à jour a été installée ou que l’administrateur a modifié les paramètres du système ?
Je ne connais pas vos utilisateurs, mais je connais ceux que nous avons et leur demander d’actualiser pourrait se terminer par la question de savoir si c’est quelque chose à manger ou non.
Je vais maintenant installer la dernière version et demander à mes utilisateurs de test de surveiller. Merci de votre retour.
Bonjour ! J’aime beaucoup le fait que répondre à un commentaire génère immédiatement un nouveau fil de discussion
Je suggérerais de supposer qu’un nouveau commentaire est une réponse au commentaire immédiatement précédent. C’est le cas le plus fréquent dans une conversation. Il est naturel pour les gens d’utiliser « répondre à » pour un commentaire qui est déjà en haut de la conversation, mais quand les gens veulent répondre au commentaire immédiatement précédent, ils ne l’utilisent pas. Dès qu’une personne commence à écrire dans cette situation, je supposerais qu’elle veut répondre au commentaire immédiatement précédent et générer un fil de discussion (cela fonctionnera même si de nouveaux commentaires apparaissent, donc la personne n’aura pas à supprimer et réécrire). Ainsi, lorsque les gens commencent à taper, une ligne au-dessus indiquera « Répondre à (…) », et s’ils ne veulent pas le faire, ils peuvent cliquer sur un « x » juste à côté de ce texte. Cela rationalisera le processus et aidera à garder le canal propre selon moi.
Je suis heureux de voir que d’autres prennent le chat au sérieux au point de le préserver. C’est formidable que nous puissions maintenant obtenir un CSV de notre chat. Ce serait encore mieux si cette tâche pouvait être gérée automatiquement comme un paramètre d’administrateur. Cependant, c’est un pas en avant.
L’élan et le cadre du « chat » ont été qu’il est éphémère et ne mérite pas de stockage permanent. Peut-être est-ce considéré comme un moyen de contourner le fardeau d’inclure le « bavardage » dans la base de données ? Quelles qu’aient été les motivations initiales, il est évident que les gens veulent préserver le bavardage et des mesures sont prises pour permettre aux administrateurs de le faire.
Je suis très satisfait des progrès et j’ai hâte qu’il soit entièrement préservé.
Je commencerai par reconnaître quelque chose qui est une lapalissade pour quiconque utilise la communication de type chat : le chat est très subjectif et trouver la solution « juste » est pratiquement impossible si vous choisissez une des nombreuses options.
J’ai tendance à classer le fil de discussion par chat en deux catégories : sous-espaces et en ligne.
Les plateformes qui suivent le format sous-espace créent des « poches » lorsque quelqu’un répond à un message et toutes les réponses sont conservées dans cette poche, hors de vue à moins que quelqu’un ne clique pour y accéder. Les gens connaissent souvent cela de Slack et c’est ainsi que je classerais la solution intégrée à la fonctionnalité de chat de Discourse.
Les réponses en ligne conservent toutes les réponses dans le fil de discussion principal et pointent vers l’antécédent par un lien/une ancre. Il existe deux variantes : avec et sans texte cité. Un exemple avec texte cité serait Discord (qui utilise un extrait plutôt que la citation complète) ou Messages sur les appareils Apple. Discord utilisait auparavant des réponses en ligne non citées avant de passer à son format actuel. L’autre exemple de réponses en ligne non citées est la fonctionnalité de chat sur Stack Exchange / Stack Overflow.
Les deux sont valides et ont leurs utilités, et chacun « résout » en quelque sorte les problèmes que l’autre crée.
Je trouve que les poches de sous-espaces…
+ peuvent être un excellent moyen de contenir une ligne de pensée latérale ou de permettre des approfondissements sur un sujet sans distraire de la discussion principale.
+ maintiennent ces digressions nettes et faciles à suivre, mais les
- poches peuvent être facilement manquées, surtout si les réponses sont créées longtemps après que le chat ait abordé d’autres sujets.
- il est plus important de s’assurer que vous mentionnez toute personne qui a besoin de voir les ramifications.
L’inverse est vrai pour le chat en ligne…
- parce que tout est en ligne, il est facile de dérailler la conversation en s’éloignant des sujets principaux.
- il peut être déroutant de suivre plusieurs lignes de discussion simultanément.
+ puisque tout est en ligne, vous ne pouvez rien manquer de ce qui se passe dans un sous-espace.
+ les utilisateurs n’ont pas à trop réfléchir pour s’assurer que les réponses mentionnent des personnes spécifiques.
En tant qu’utilisateur de Slack et de Discord depuis plusieurs années, je dirais que la solution « juste » est probablement celle que peu de développeurs veulent entendre : avoir les deux. J’ai constaté que les plus grands déterminants (pour moi) de ce que je préfère sont :
Combien de personnes sont impliquées dans le chat ou à quel point il est actif.
Si je discute avec une seule personne ou s’il n’y a pas beaucoup d’activité, tout ce que je veux, ce sont des réponses en ligne. Même avec 2-3 autres personnes, je n’ai pas besoin de sous-espaces. Je ne peux pas vous dire combien de fois j’ai été agacé par les messages directs de Slack utilisant des sous-espaces entre deux personnes.
Si je suis dans un espace avec de nombreux participants et que les messages fusent rapidement, il devient beaucoup plus difficile de suivre les conversations en ligne, surtout lorsque les gens utilisent la fonction de réponse de manière laxiste.
Combien je veux/dois tout voir.
Si je joue un rôle de soutien dans un canal Slack, les sous-espaces désencombrent les canaux afin que je puisse simplement survoler rapidement.
Si je suis dans un espace où manquer quelque chose enfoui dans un fil de discussion serait grave, je préfère les réponses en ligne. La peur de manquer quelque chose est réelle, mes amis !
À quel point un fil de discussion devient « profond ».
Les canaux qui ont tendance à avoir une question suivie de dizaines, voire de centaines de réponses devraient être en sous-espaces.
Les canaux qui ont tendance à avoir très peu de réponses par message fonctionnent généralement mieux en ligne.
Qui je suis / à quoi je suis habitué.
Je connais une personne qui a créé un script Slack pour supprimer les sous-espaces parce qu’elle les déteste tellement.
Je connais des gens qui insistent fermement pour que leurs équipes utilisent systématiquement les fils de sous-espaces dans leur canal Slack et qui deviennent légèrement grincheux lorsqu’ils ne sont pas utilisés.
Tout cela pour dire qu’il n’y a pas de solution unique (ni même pour la plupart). Je suis parti à la recherche de ce méta-post spécifiquement parce que j’étais dans un chat en 1-1 sur une autre instance de Discourse et j’ai été surpris de voir le choix de fils de discussion et j’ai vraiment souhaité pouvoir éviter les fils.
Quelques idées si vous souhaitez proposer les deux options :
Envisagez un paramètre utilisateur pour permettre à quelqu’un de choisir globalement ou par chat, quel style il préfère.
Tenez compte du nombre d’utilisateurs dans un espace de chat, de la fréquence des messages et de la profondeur moyenne des réponses pour déterminer quelle forme utiliser « automatiquement » - par exemple, utilisez l’en ligne jusqu’à ce que les réponses dans une chaîne atteignent un certain nombre ou qu’un utilisateur indique « convertir les réponses en fil de discussion ».
Prenez en compte la situation « Je crée un nouveau fil de discussion en réponse à quelque chose d’hier/la semaine dernière » et s’il est logique d’indiquer la réponse (ou de permettre aux répondants de publier la réponse en ligne, comme le fait Slack).
Je pense que ce que vous avez est bien, mais j’aimerais beaucoup voir Discourse envisager de brouiller la frontière entre ces deux méthodologies distinctes au fur et à mesure que vous développez cette fonctionnalité.
Merci beaucoup pour cette réflexion bien pensée et constructive.
Nous vous entendons vraiment et la plupart des points nous ont traversé l’esprit au moins quelques fois. Je suis assez confiant que, à mesure que le chat mûrit et qu’il est de plus en plus adopté, ce problème sera résolu à un moment donné dans un avenir (plus ou moins) proche.
Je pense que cela pourrait être résolu élégamment en affichant des extraits en ligne de tous les fils jusqu’à une certaine limite. Ainsi, s’il y a peu de commentaires, ils seront tous lisibles, et s’il y en a plus, certains seront lisibles en ligne, ce qui donne déjà une idée rapide de la conversation d’un coup d’œil (et l’utilisateur peut entrer dans l’espace secondaire s’il est intéressé).
Cela s’applique également aux sujets de forum, à mon avis. Je veux voir des extraits des premiers * et des derniers commentaires/réponses au niveau de la liste supérieure pour faciliter la lecture rapide. J’ai construit et expérimenté un système similaire et on pouvait surveiller plusieurs fils à la fois simplement en regardant les quelques réponses les plus récentes se mettre à jour continuellement. (note : ceci était une réponse au message ci-dessus qui a été fusionné dans le message séparé ci-dessous)
Je suppose qu’à un moment donné, les sujets et les fils deviendront le même système de base. C’est surtout une différence d’UX/présentation, non ? Sinon, nous devrons dupliquer bon nombre des mêmes fonctionnalités et capacités pour les deux.
Nous n’avons actuellement aucun projet d’introduire des fils de discussion dans les sujets. Il s’agit d’une fonctionnalité réservée au chat.
Il existe de nombreuses discussions existantes sur l’introduction de réponses filaires si vous souhaitez poursuivre la conversation sur l’une d’entre elles.
Ce que je veux dire, c’est que le chat avec des fils de discussion n’est pas très différent d’un forum avec des sujets. À mesure que de nouvelles fonctionnalités seront introduites dans Discourse, nous voudrons naturellement que beaucoup d’entre elles s’appliquent aux publications du forum et aux publications du chat, ce qui serait plus simple si, en dessous, il s’agissait techniquement du même système de base.
Je soutiens également la convergence, je pense que c’est l’approche la plus robuste à long terme pour tout en général, pour réaliser où les abstractions de fonctionnalités sont les mêmes et ainsi les rendre telles quelles. Par exemple, j’ai proposé une fois d’envisager les tags comme une forme de “méta-catégories”.
Comme cette fonctionnalité est bien établie, je vais clore ce sujet d’annonce.
Si vous rencontrez des problèmes avec cette fonctionnalité, ou si vous avez des suggestions d’améliorations, veuillez créer un nouveau sujet Support, UX ou Feature.
