Nov 9, 2023 / 🎤 Thread View (experimental), Grid View improvements

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 :heart: If we can keep using it, we can delete our old solutions and avoid clutter in the workspace.

1 Like

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.

5 Likes

Awesome :star_struck::star_struck:

1 Like

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:

Detecting User Comments

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:

  • Create formula field on the Topics database called “User Comment Count”
  • Add this formula to it: Comments.Filter(Length(Author.Name) > 0).Count()
  • Add rule with a trigger on that field like this:

Detecting Keywords in Comments

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?

Another Example

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:

2 Likes

@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 :slight_smile:

I’m excited for the direction all this is going and I know the Fibery team is in favor of much of this stuff!

5 Likes

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!

3 Likes

I fully agree.

I just want to warn everyone that trying to upgrade or improve on the current comments system :skull: 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:

  • Introduce a new Discussion View, enabling entities from any database to be displayed and used as comments.
  • Entities used as comments in the Discussion View can display and use their database fields (e.g., status, priority) for specific workflows.
  • This would allow cross-referencing of entities used as comments across a workspace.

Benefits: Enhances communication flexibility, reduces external tool reliance, and aligns with modern AI-supported workflows.

2 Likes

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.