Do you see this only for channels where threads have been recently enabled and the client hasn’t refreshed yet since that change? Or also in cases where you’ve refreshed already once since threads have been enabled?
I think we saw something like this not too long ago and fixed it.
Maybe it’s resurfaced? If you update to the latest version of tests-passed now, do you still see the issue?
All our chat channels have been recently enabled.
And I am not sure when or how the users refreshed their browsers. Might be a good idea to force a complete refresh from the system every time an update was installed or the admin changed system parameters?
I don’t know about your users, but I know of the users we have and asking them to refresh might end up with the question whether that is something to eat or not.
Going to install the to the latest version now and ask my test users to watch. Thanks for getting back to me.
Hello! I really like that answering to a comment immediately generates a new thread
I would suggest to assume that a new comment is an answer to the immediately previous comment. It’s the most common occurrence in a conversation. It’s natural for people to use “answer to” for a comment which is already up in the conversation, but when people want to answer to the immediately previous comment, they don’t use it. From the second a person starts writing in this situation I would assume they want to answer to the immediately previous comment and generate a thread (this will work even if new comments appear so the person do not haves to delete and rewrite). So when people start typing, a line above will say “Answering to (…)”, and if they don’t want to do that, they can clic an “x” right next to that text. This will streamline the process and help to keep the channel clean IMO.
I’m pleased to see that others are taking chat seriously enough to preserve it. It is great that we can now obtain CSV of our chat. It would be even better if this task could be handled automatically as an admin setting. However, it is a step forward.
The impetus and the framing of “chat” has been that it is ephemeral and not worthy of permanent storage. Perhaps it is seen as a way to sidestep the burden of including “chit-chat” in the database? Whatever the original motivations were, it is apparent that people want to preserve the chatter and steps are being made to allow admins to do that.
I’m very pleased by the progress and look forward to it being fully preserved.
I’ll preface what I’m saying by acknowledging something that’s a bit of a truism for anyone who consumes chat-style communication - chat is highly subjective and finding the “right” solution is practically impossible if you’re picking one of the many options.
I tend to put chat threading into two categories: sub-spaces and inline.
Platforms that follow the sub-space format create “pockets” when someone replies to a message and all replies are kept in this pocket, out of view unless someone clicks to join it. People are often familiar with this from Slack and is how I’d classify the solution built into Discourse’s chat feature.
Inline replies keep all responses in the main chat thread and point to the antecedent through a link/anchor. There are two variations on this - with and without quoted text. An example with quoted text would be Discord (which uses an excerpt rather than the full quote) or Messages on Apple devices. Discord used to have unquoted inline replies before switching to their current format. The other example of unquoted inline replies is the Chat feature on Stack Exchange / Stack Overflow.
Both are valid and they have their uses and they each sort of “solve” the problems the other creates
- I find that sub-space pockets…
- + can be a great way to contain a lateral line of thought or allow for deep-dives into a topic without distracting from the main discussion
- + keeps these tangents neat and easy to follow but the
- - pockets can be easily missed, particularly if replies are created long after the chat has moved on to other topics
- - more important to ensure you’re pinging anyone who needs to see the offshoots.
- The reverse is true with inline chat…
- - because everything is inline, it can be easy to derail chat by going off on tangents
- - can be confusing to follow multiple lines of discussion simultaneously
- + since everything is inline, you can’t miss anything that’s happening in a sub-space.
- + users don’t have to think too hard about making sure replies ping specific people.
As a Slack and Discord user for several years, I’d argue that the “right” solution is probably the one no dev wants to hear - have both. I’ve found the biggest determiners (for me) of which I prefer are:
- How many people are involved in the chat or how busy it is.
- If I’m chatting with one person or there’s not much activity, all I want is inline replies. Even with 2-3 other people, I don’t need sub-spaces. I can’t tell you how many times I’ve been annoyed by Slack’s DMs using sub-spaces when between two people.
- If I’m in a space with lots of participants and messages being thrown around rapidly, it becomes much more difficult to follow inline conversations, particularly when people are being fast and loose with actually using the reply feature.
- How much I want to/need to see everything.
- If I’m in a supporting role in a Slack Channel, sub-spaces declutter channels so I can just skim quickly.
- If I’m in a space where missing something buried in a thread would be bad, I prefer inline replies. FOMO is real, friends!
- How “deep” a thread gets.
- Channels that tend to have a question followed by dozens or even hundreds of responses should be in sub-spaces.
- Channels that tend to have very few responses per message usually work better inline.
- Who I am/what I’m used to.
- I know a person who created a Slack script to remove sub-spaces because they dislike them so much.
- I know people who sternly insist their teams use sub-space threads in their Slack channel every time and get mildly grumpy when they’re not used.
All this is to say there’s not a one-size-fits-all (or even most) solution. I went in search of this meta post specifically because I was in a 1-1 chat on another Discourse instance and was surprised to see the choice of threading and really wished I could avoid threads.
Some ideas if you want to consider offering both options:
- Consider a user setting to allow someone to choose either globally or per-chat, which style they prefer.
- Take into account the number of users in a chat space, message frequency, and average reply depth when determining which form to use “automagically” - for example, use inline until replies in a chain hit some number or a user indicates “convert replies to a thread”.
- Consider the “I’m creating a new reply thread to something from yesterday/last week” situation and whether it makes sense to indicate the reply (or allow responders to post the reply inline, as Slack does).
I think what you have is fine but I’d love to see Discourse consider blurring the barrier between these two distinct methodologies as you move forward with the feature.
Thanks a lot for that well thought out and constructive line of thinking.
We really hear you and most of the points have crossed our minds at minimum a couple of times. I’m fairly confident that as chat is maturing and being picked up more, this issue will be addressed at some point in the near(ish) future.
I think that this could be nicely solved by showing inline excerpts of all threads up to a certain limit. So if there are few comments they will be all readable, and if there are more, some will be readable inline which already gives a quick idea of the conversation at a glance (and the user can enter the sub-space if interested).