Hi guys,
What are the chances that you will keep this feature in production? We use it on a daily basis and we really like it If we can keep using it, we can delete our old solutions and avoid clutter in the workspace.
Hi guys,
What are the chances that you will keep this feature in production? We use it on a daily basis and we really like it If we can keep using it, we can delete our old solutions and avoid clutter in the workspace.
We have no intention to kill Thread View, our data shows that it is relatively popular as experimental feature, but I am not sure when we will make it real feature in a product as well, since it demands polishing.
Awesome
I did some experimenting with it, mainly thinking it would be interesting if you could build bots or AI agents through automations. I thought it also might be interesting if you could interact with the objects across the databases. Overall, I found it possible, but fairly cumbersome.
Main limitations I ran into:
It is a little tricky to avoid creating an infinite loop where your bot responds to a message, then the bots response gets seen as a comment that it then tries to respond to itself. For a bot, you typically want to trigger off keywords in comments from users, and this just takes a bit of work at the moment.
Here is how I detected user comments:
Comments.Filter(Length(Author.Name) > 0).Count()
Here you either get into custom scripts or complicated comment templates with embedded code within the template. I found that I really needed to use custom scripts because I donât want to add a comment if the keyword isnât detected in the comment. So, using the âAdd Commentâ action with a template doesnât work for this use case. Here is a simple proof of concept to detect the command /capitalize items to capitalize
, then return the capitalized text.
const fibery = context.getService('fibery');
// javascripts missing capitalize function
function capitalizeArray(arr) {
return arr.map(function (str) {
return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
});
}
// returns any values after a given command string
function extractCommands(command, inputString) {
// Split the string by command
var splitArray = inputString.split(command);
// Check if there is text after command
if (splitArray.length < 2) {
return []; // No text after command
}
// Split the text after command by spaces and filter out empty strings
return splitArray[1].trim().split(/\s+/).filter(Boolean);
}
for (const entity of args.currentEntities) {
// get the comments associated with the topic
const entityWithComments = await fibery.getEntityById(entity.type, entity.id, ['Comments']);
const allComments = entityWithComments['Comments'];
// get the text from the latest comment
const latestComment = allComments[allComments.length - 1];
const doc = await fibery.getDocumentContent(latestComment['Document Secret'], 'md')
// check if any commands were mentioned to process
const commands = extractCommands('/capitalize', doc)
// add comment with the response if we had a command
if (commands.length > 0) {
const comment = 'Capitalized: ' + capitalizeArray(commands).join(' ')
await fibery.addComment(entity.type, entity.id, comment, '', 'md')
}
}
This works, but I do get an error which I think is about not having a user id to reference. Adding comments through the âAdd Commentâ action seems to produce the same output. Is there not a System user or something along those lines?
Here is an example of using the comment template to reference the same entity that the comment is being added to as a proof of concept adding a reference. The topic name is âDealsâ in this case. Both automations are active at this point:
@Illusory another insightful post, and as is often the case I agree with what you are saying! As another long-time user who primarily leverages comments in Fibery (we no longer use Slack, and in fact have basically eliminated internal Emails by setting up Fibery a certain wayâŚ), I think there are some even better ways comments can evolve to emulate Slack/Email/DMâs and give a team a full way to communicate around a companyâs work and context better than anything out thereâŚ
So with Threads, Iâm also not seeing a real movement forward here, similar to I think what you are saying. We already liberally use commenting in entities to communicate around them, so having the ability to essentially pin those comments to the left panel isnât particularly useful. Iâm basically reiterating what you are saying here:
I think this could be solved if Comments evolved into another type of item in Fibery, you could call them âconversationsâ letâs say. I talked about this here (including a quote from @mdubakov about Fibery replacing Slack):
Iâd really like to see the ability for each comment to also live in Fibery on its own. Have a public ID, the works. We are constantly trying to respond to comments in one entity from comments in another entity - which is very useful because frequently you need to refer back to something in a related context. This feature could help with that, would be amazing if we could get it one day:
And this is all stuff I really ,100% back that would be a ton of help:
And you mentioned mobile as wellâŚrealizing the undertaking it is, for commenting and quick communication, itâs a must, so Iâll link to that yet again
Iâm excited for the direction all this is going and I know the Fibery team is in favor of much of this stuff!
So it took a while but my team has turned on Thread View to solve a growing issue we are having, and I have high hopes!
The Problem: We are working on a massive initiative and have started to run into more complex structures and ways we communicate around them within this period of time that this initiative has come front-and-center. There are a lot of abstractions - things that arenât easily turned into typical db items like âtasksâ or âresources,â but things that are concepts, overlapping areas of the business, etc. We handle this stuff pretty well in Fibery with an array of creative dbâs, such as âoccurrencesâ which mark big moments when we might change direction. The benefit of Fibery is you can use these dbâs anyway you want, where in other tools you canât get this abstract with your âwork itemsâ which are typically rigid.
This leads to the question of our free-flowing discussions in the business, which will take place in Slack, text, Email. As the complexity of what we are working on right now grows, we are seeing that much of what we discuss in real-time in these typical tools is hard to replicate by updating work in Fibery with entity creation, and comment and referencing those.
So it appears that Threads may be a great solution to try to emulate the free-flow of chat or email, but get at our fingertips the ability to reference every item we are talking about, many of which are tracked in Fibery. As a point of product development and feedback, we experimented around with Tana and the way it lets you create a Supertag that you donât have to define during its creation - that is helpful to limit friction when chatting or texting ânaturally.â Tana however is way too limited to actually manage our work, and most of what weâd make a Supertag we handle in Fibery. I have high hopes that threads will solve a great deal of our current need!
I would like to make one more plug for a few ideas that I think could really help workflow that are very closely related to Threads, since one of the benefits of Threads is you can look in the reference area of an entity and see what was discussed about it. If this could be put into chronological order with straight comments on the entity, youâd get a great history at-a-glance, w/out having to scan all the way down an entityâs page. This request is Merge Comments and References in one common Stream for better flow.
I think Threads also point out how useful it could be if comment lived as real nodes that could be referenced, quoted, etc as well, given that with the use of Threads they take on more independence. Here are some requests around this functionality:
Refer to Comments, and Public IDâs for Comments
And it would be great if you could easily refer to a comment around Fibery, especially now with Threads we will be doing even more commenting in Fibery! One way to do this is the way Discourse handles it in this forum. Right now in order to quote a comment, the only workaround we have is to either make a screenshot of the comment, then reference the entity as well, so the recipient can find the original comment easily, or try to use the âquoteâ formatting, but that will break the context of the full comment in which the quote is included because you canât easily use the âsoftâ return (âshiftâ + âreturnâ) when using those quotes because what you write above the quotes wonât come through in the reference unless itâs part of the quote itself, and thus in the reference the user canât see the whole comment. (this might be solved with the evolution of Show in Reference Highlights Referenced Entity more clearly)
Thanks for listening!
I fully agree.
I just want to warn everyone that trying to upgrade or improve on the current comments system is bound to fail - its not an integrated solution. I donât want the Fibery team to apply a quick fix to the current comments system. Just trash it as soon as possible, sorry for anyone now feeling rugpulled. But my view is also related to Fibery becoming a more social platform, where communication is more fluent and well integrated.
Better rebuild it as follows and it will be easier to maintain:
Issue: The current comment system is outdated and not well integrated in the database and relation-based model of Fibery. This limits use of comments incredibly, including hindering its use in effective collaboration for AI-driven workflows like agentic discussions and pipelines.
Solution:
Benefits: Enhances communication flexibility, reduces external tool reliance, and aligns with modern AI-supported workflows.
It sounds intriguing, but Iâm not sure I understand what you mean when you write âenabling entities ⌠to be displayed and used as commentsâ or when you write âcross-referencing of entities used as commentsâ
Is âDiscussion Viewâ something close to a mashup of feed view and thread view? Where each âcardâ in the feed shows a specific entityâs comment threads? Or is each âcardâ a single thread (with potentially multiple cards per entity)?
Alternatively, I wonder if there could be improvements achieved by enhancing the functionality of #mentions?
At the moment, in any comment (or any rich text field or document) it is possible to #mention an entity. The entity will be displayed (with certain fields showing, depending on the configuration). At the moment the choice of fields to show is the same for all entities of the same type, no matter where the mention is occurring.
What if the choice of fields to be displayed were more flexible (perhaps uniquely definable for each mention) or if it were even possible to embed a custom entity view?
Would this be helpful, or is that just a tangential problem to be solved?
Maybe this discussion is related to (should be moved to?) this thread:
?
This seems to be similar to the âcomments as a databaseâ suggestion, if Iâm understanding correctly. My main issue with this is the behavior of relation fields. It is not conducive to the flow of conversation that users expect. People expect to fine a comment section, click in the message box (or click âreplyâ), type their comment, then press enter. A relation field would some view (say âlistâ) that does not match user expectations. The only way this seems acceptable is if the comments database is somehow baked in to the workplace and thus receives a special field with its own UI instead of the standard relations field.
At the end of the day, comments are a database, even in Fibery, just not a user-made one. They are shown as a to-many relation in automations.
I agree that if done in this way, it needs just as good UX, but I donât think having them as a user-made database will hinder UX in any way if built correctly.
It would need to be a feed view with non-editable text unless a user pressed on the edit button. As currently done in comments. An additional reaction field. And then the part that would be the most different is the âReply to commentâ, this would probably need to be two databases. One with comments, and one with sub-comments. This behaviour of opening a text field would be unique to the discussion view, instead of opening a popup for input, it would open right under the parent entity for input. I donât see why changing the underlying database to be a user-made database would affect the UX. Maybe Iâm missing something though? @Michael_Ichter? Could it not look and feel the exact same way but be a user-made database? Then we could even add attributes to comments like assignee, etc. The comments UX is the most clean way of data input at the moment (especially for rich text, looking at you, feed view), but its limited to comments unfortunately.
Ohh and one feature needed for this to work correctly is to have âstrong relationsâ where the related one-to-many relations are deleted and restored together. As this is the way comments currently work: On delete setting/strong relations for relation settings
I have a hard time picturing this with my current understanding of relation views. Iâll look more into this when I have time.