Yes thatās exactly our use case. For team occasions, it doesnāt matter. But in our wiki for clients we link to other wikis and there itās quite disturbing.
2 Likes
Agree here. I think collapsing and expanding is nice when needed.
e.g., we put the comment section at the top of some of our entity types (specific entity types we work in are comment heavy or we want context quickly, so having them at the top makes things easier). For long-running chats, having collapsible and expandable comments would be nice since we still want to see other related entities and references below, without comment section taking up the whole screen and pushing down other items (like rich text fields, lookups, related entities, references, etc).
Initial thoughts are that embedded comments UI should show last 3-5 comments and can be expandable or allow users to select the default view (previewed or expanded). Furthermore, I think the ability to open them in side-panel is also nice so that comments can be read while reviewing entity, rather than āeither-orā.
I think this is a great idea and I can only imagine other potential scenarios this unlocks (e.g. AI automation on entity comments, filtering, lookups, maybe adding other fields to the āThreadsā type).
The only concern (for myself, maybe not for others) at first glance is ensuring comment/thread type is differentiated well from other types in places like Search and References. Example: In the preview of threads that @mdubakov provided when Channel āDailyā was referenced, I noticed the entity badge is āDā. There should be some sort of indicator or icon that reflects that it is a channel and of thread type/feature, and not just a random entity.
I think Threads has the ability to be a great addition, but Iād hate for it to get lost within all of the other views and types (if itās meant to foster meaningful interaction, influence use and compete with a dedicated chat app like Slack, it should stand out as a core feature of Fibery spaces and entities, not just another database).
3 Likes
This, exactly this! On the one hand I love the potential that āThreadsā would be ājust another databaseā under the hood, and thus perhaps more powerful/flexible (e.g. being able to run automations on its contents, summarize with AI, auto-create tasks even, or create Fibery Reports to analyze it, etc.). But I think there is already too little meaningful differentiation between some aspects of Fibery (by design as itās a āLego boxā) and this one seems more critical to make clearly different.
As someone who hates Slack, especially its use in situations where a ālighterā solution would be better, I would love having Threads in Fibery. But the question of course is how many people would actually use it and would its long-term development and maintenance be worth it. The experiment is fantastic to see, and the progress shown here from Fibery team after discussion is amazing, the quick iteration is 
. But will such a feature be worth long-term maintenance and improvement for Fibery? I guess that depends on how you scope it (and how much effort is involved in maintaining it). My hope is that it can be a āgood enoughā feature (that is surprisingly good!), with Slack for heavier users and thus without falling into scope creep, etc. to drag down the dev team on maintaining it. A ājust good enoughā chat-like feature integrated with Fibery could be brilliant.
That said, the question is how you get people to use it instead of Slack (or if you even want that, and if not, who are the target users?). Others have tried before you, and adoption seems low (Quip, ClickUp, probably more). Iām rooting for you, Slack is a fragmenting, stress-making disease IMHO! But people are addicted to it, soā¦ itās a challenge. 
3 Likes
Yeah, we understand all challenges, that is why we wanted to keep scope minimal and just replace few use cases, like discussions around Fibery entities (features, tasks, etc) and some generic channels like Daily.
Note that Thread View is just a view, so it is possible to create Thread View for Feature, for Product, for Task, for anything. In my demo I created a special Database that I called Channel, but there are no restrictions.
Actually, we donāt want to spend more than 2 additional weeks on that and that is why I said that it is unlikely we will release it in public. But weāll seeā¦
4 Likes
Do release it in public if maintenance for it can be light (due to small feature set for this area/function)! Then you can really see whether and how people actually make use of it. 
6 Likes
Release as an experimental feature and gather feedback. Thread View is a very interesting feature. 
4 Likes
Jep, this is it!! Donāt get rid of collapsing, itās much cleaner that way.
Now when will this be released?! We have experimental enabled but are not seeing this yet.
Also I like the threads idea (but only with unread notifications). I can imagine we might eventually not have to use Slack anymore. The less tools the better.
2 Likes
I agree as well that it should be released. Love the idea and am sure weāll adopt it. @mdubakov
1 Like
Hmm, Iām considering using this thread function to replace all Standup meeting or even personal tracking habits instead of each entities for each days, which means I replace feed view to thread view. Should I do that ? and what the difference between them in personal usecase, not collaborate ?
Feed view displays the contents of rich text fields.
Thread view displays the contents of comments.
2 Likes
Guys, is it possible to keep new comments in the same record window instead of opening a sidebar? Also, it will be useful to have a setting if we always want to show all comments.
1 Like
It is coming in tomorrows release.
Also, it will be useful to have a setting if we always want to show all comments.
Here we will not change anything so far. What do you mean here? Show only X latest comments setting?
2 Likes
The ai filtering sounds amazing! Iāve been sending lots of loom feedback on grid column āchallengesā ā great theyāre getting resolved.
Weāve fixed (I hope) nested comments in todayās release
2 Likes
I was very excited to try this but also quite disappointed when I saw that you did not add collapsable replies. I REALLY want it to be like this:
Please!! It will become a UI nightmare for us if this wonāt be implemented.
Also it seems like we cannot disable it in experimental settings anymore? I donāt want to enable this as of now without collapsable replies.
We are going to add collapsing as a part of Resolved Comments feature. Indeed it is not possible to disable it, but in old comments there was no collapsing as well.
5 Likes
Just wanted to add on to my other post here that Iād love to have the ability to have the replies to comments not pre-collapsed. Being able to scroll down a page and see all the converstation, without grabbing the mouse and clicking to open up the nested replies, is a big time saver that Iām already missingā¦please consider adding this as a preference in settings!
Thank you!
2 Likes
Another option for how to handle many comments, could be: default to showing only new comments that you havenāt yet seen, with a button to reveal the entire thread.
3 Likes