Rocket.chat: Control the display of thread replies in main channel

Created on 3 Jun 2019  路  21Comments  路  Source: RocketChat/Rocket.Chat

I'm not sure whether Threads are configurable to not display replies in the channel because I'm not an admin. Can somebody elucidate that?

If that is not configurable, I consider Threads to be unusably broken since the main use case for them is to declutter the channel of irrelevant messages.

Since documentation on the website seems to be lagging, I thought I might as well ask here.

Planned threads / discussions

Most helpful comment

Without guarantees :)
.message.collapsed { display: none; }

All 21 comments

~Judging from my test deployment of RC 1.1.x, thread replies are no longer posted to the thread's channel since 1.1.0. Not sure if theres any docs about it.~
Turns out we had custom css enabled on our dev deployment :man_facepalming: It is not fixed.

There is a feature request for this - https://github.com/RocketChat/feature-requests/issues/117

Compact mode (My account -> Preferences -> Messages - View mode) almost does this. It does not show any threaded replies in the main channel view. However, the issue with the mode is that it does not properly indicate the threads on the channel that have new replies.

~Judging from my test deployment of RC 1.1.x, thread replies are no longer posted to the thread's channel since 1.1.0. Not sure if theres any docs about it.~
Turns out we had custom css enabled on our dev deployment 馃う鈥嶁檪 It is not fixed.

Can you share that custom css till this is fixed?
Thanks.

Without guarantees :)
.message.collapsed { display: none; }

We actually want to turn this into a NUMBER and not an ON/OFF options. The idea is that users should be able to choose to see only the first few messages from a thread (default to 3, but 0 would be a valid choice to get the behavior described above).

Good this is now included in the 1.4.0 release. Should probably have had a higher priority.

It's been moved to 2.0.0. I would like to see it implemented soon.

It's been moved to 2.0.0. I would like to see it implemented soon.

Please stop banging on about this, and spamming open.rocket.chat as well. A thumbs up on one of the comments above is all that is needed. No more.

This is Open Source. If you want it fixed faster then you can code it yourself - pull requests with you code are always welcome - or pay someone to do it.

Otherwise please be patient, and let others do the work when they see fit.

We actually want to turn this into a NUMBER and not an ON/OFF options. The idea is that users should be able to choose to see only the first few messages from a thread (default to 3, but 0 would be a valid choice to get the behavior described above).

Why first? Last n/any unread makes much more sense.

Actually it would be nice if that was configurable by on-thread basis by each user. This way you could easily navigate within channel threads, but you can also easily skip any conversation. This is useful for any thread that evolved to be a large conversation.

This is exciting! Just one question: Is this going to be implemented in such a way that a global default could be set? On my install I'd like it to default to hiding all of the thread messages in the channel for all users (current behavior is confusing some of my colleagues less experienced with technology).

Or is this only going to be a per-user preference? If so, what will the default be? 馃

We're using custom CSS from @jakubsemerak's comment for a while and it works fine in limiting noise context. But it has flaws because if older comment gets reply in thread (without mention) most probably noone will see it because there isn't any notification.

Milestone is outdated since there are 2.4 and even 3.0 released... Is it possible to rise priority for this?

Pls, prioritise this task.
When we starts 2 or more threads in chat - it's looks totally insane.

One more thing:
I'd be happy to create some sort of CSS snippet that hides all thread messages in the main thread if that would affect only me - currently, custom CSS-es affect all users and can be applied only from admin panel. But as far as I know, rocket chat doesn't allow users to modify their personal visual experience.
Just to be clear: I wouldn't call that a legitimate solution for the problem above, but it would in quite simple matter fix this (and many other) problems for me. Or actually it would give me tools to fix it myself which is still ok by me.

+1 more thing:
I did not see this aspect discussed yet since most people seem to be annoyed by seeing messages. In my case it's the opposite:

In the version I am currently using the (default) visibility of replies is governed by the "View Mode" setting. If it is set to "compact" they are hidden. This is unfortunate because compact is the one single mode where UI clutter is reduced to something I don't despise looking at. Having to click and look somewhere else than the main list of messages to read replies is really annoying. To put this into context: if I could use an IRC bridge I would - but I cannot.

Thus my humble wish would be for a setting of the reply visibility that is independent from the "View Mode" setting.

@stefanct Yes, it's true that is a subjective topic. Even though I personally would like to hide those messages, I wouldn't do that on global level (via custom CSS), because I know for sure that there are people in our team, who want those messages to be there, or even to be displayed as a normal message.

Therefore leaving that to each person (in best case globally with the ability to override on a per-channel basis) would allow everyone to adjust the experience to their taste.

Having to click and look somewhere else than the main list of messages to read replies is really annoying.

@stefanct As the OP said, if the whole purpose of threads is to keep clutter out of the channel, it seems counter-intuitive to have thread messages always appear in the channel. To me it sounds like you simply do not want the functionality of threads at all? (You can disable them completely in the Rocket.Chat settings)

Anyway, I think Slack solves all of these problems really nicely:

This checkbox appears in the thread while you're typing. By default there's no clutter in the main channel. People can choose to post it in the main channel on a _per-message_ basis. This seems a lot more practical than a global setting:
image

There is also a dedicated place for all threads you're subscribed to in the side bar, making it clear to find new replies in threads you've subscribed to. It lights up like any other channel when there's a new message, so notifications aren't an issue:
image

And you don't really need a notification for a reply in a thread you're not subscribed to. I'd argue that if someone says something in a thread that they need uninvolved people to see, they ought to use pings (or in Slack, they should check the checkbox above).

@blunket you are somewhat correct: i would disable them if i could but you are referring to server settings not client/profile settings, correct? (maybe the instance i am using is too old to have that preference... if so everything's fine). if that's the case this point is kinda mute since the issue is about client-side display preferences.

These threads are a useless and super irritating feature. Every time someone adds a thread it adds a permanent unread counter to the channel and the only way to get rid of this counter is to manually click "not follow" on each thread.

Edit: "folmert unassigned brunosquadros 23 seconds ago" - what?! I didn't do anything.

I'm not sure the main objective of threads would be "not to clutter" in the sense of "show fewer messages in" the channel (at least, given the more recent Discussion capability) but rather to provide context to a reply without having to quote explicitlly the followed-up message (as in Element e.g.) - thus somehow limiting clutter actually.

So, I feel showing/hiding the replies should rather be a viewing-UI, per-user

  • default behaviour (might be covered by the viewing mode paramter in the profile, and I like this idea of a _n_ first and maybe _m_ last replies cap)
  • and per-thread fold/unfold ability,
    than an edit-UI, per-thread choice (or oversight...) of the reply author.
    All the more so because any single user's preference can be different when using differently sized terminals.

Besides, IMHO opening the thread panel (desktop)/screen (mobile) should be the native behaviour when clicking a previous message: etiher view the thread if there are any replies already, or reply in a thread if the initial message is still unanswered. It currently needs popping up the contextual menu > reply in thread button.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

engelgabriel picture engelgabriel  路  3Comments

Buzzele picture Buzzele  路  3Comments

Kiran-Rao picture Kiran-Rao  路  3Comments

ghost picture ghost  路  3Comments

amayer5125 picture amayer5125  路  3Comments