Really disappointed for this and want to add a huge +1 for it, perhaps we need a new separate request? One of the reasons I am not in Notion vs. being here in Fibery is that Notion also doesn’t index comments in search. @Oshyan and I have talked about a lot how Fibery is weak in the collaborative areas such as notifications, etc. We use comments a ton, as it’s a great way for us to try to reduce use of Slack and Email, and accomplish the huge goal of a team using just one tool for all its needs. So not to be able to look around in search for a comment of yours in the past continues to be a huge limitation, really sad this wasn’t in the full text release!
In fact, we often use Comments over Rich Text to even build out Entities. This is because:
Comments show by whom and when something was written
you can have a sort of dialog back-and-forth in comments, which is very helpful for collaboration. Using inline comments is much less useful as you can’t see the comments easily at a glance, they disappear if resolved, etc. We could really use however Threaded Comments
All of the better tools I’ve used index comments, so I’m really hoping this won’t be long before you guys do so, too. I can’t imagine not having comments indexed and trying to continue to go all in with Fibery.
I agree that it would be ideal for comments to be included in full text search. I imagine my need for this is not as great as yours, but I definitely echo the fact that comments are a key part of building out Doc and Entity text and contents because of attribution, explanation, etc. The new Activity view helps a lot with this for Entities, but not yet available for Docs. And even there, as you’ve noted, you can’t comment on why you’ve done something, so comments remain important. I do think however that the need for searching within comments is, for me at least, less than the need for searching elsewhere in full text. So for me it’s “nice to have but not vital”. Regardless I do imagine some people will be surprised and frustrated by the lack of comment indexing at some point, if it remains that way…
Thanks for another well-thought through post @Oshyan!
I don’t want to speak for you, but from what we’ve discussed the last many months, I think you are using Fibery a bit differently than a typical Dev Team, or highly collaborative team that is relying on it for hard-core work management, as I am trying to do. Comments are an essential part of what we do in Fibery. In fact, I will say that the rudimentary Slack integration, and the fact that it includes the actual comment directly into Slack, is a life-saver until better notifications come out. Without this, I’m not sure we could manage in Fibery. Comments leave a lot to be desired right now, but they are good enough for us. So I really do hope when Search advances we will get comments indexed. In fact, there is a lot of other stuff that it would be good to see in search. In a communication with Notion, their support expressed to me that they intend to index:
“…database property content (such as selects, text prop content, etc.), comments, mentions, hyperlinked content, URLs, anything in attachments, or embeds.”
Ultimately as a Fibery instance grows I think we’ll need a powerful search of that caliber.
Finally, I do want to say that the fact that @mdubakov and team had the foresight to include in the very first iteration of Search the ability to search by public ID was a real bonus. We use this all the time! Some tools don’t even have ID’s. So kudos to you guys for including that at the very beginning iteration of Search. Oh, and that the default results are by Last Visited also has been very, very useful. So I want to give you guys credit for doing some good stuff in search, even though I am desperate to get comments indexed!
Yes, that’s generally correct. I only intended to speak to my own needs and experience. Sometimes I feel like I can speak to a more broad perspective, but I certainly recognize my use is not typical here. Then again we have a pretty wide variety of users, at least judging by the active forum participants.
That would be great, for sure! I’ll believe it when I see it from Notion though. I also think full text search in embeds is an interesting challenge to tackle, but maybe a lot to promise. In Fibery I definitely want to see db properties, and ideally indexable attachments (PDFs at the least). Comments, as we’ve discussed, would be nice.
The rest to me would be icing on the cake, and to be honest probably not that often useful for me. I’d be curious if anyone here could make a real case for the effort-to-benefit ratio of indexing that content for search, actually. “Hyperlinked content”? That’s hugely vague and could be a massive thing to deal with, unless I’m overthinking what they’re promising.
The way I imagine Fibery handling that kind of thing in the future is with a web clipper and transclusions/quotes from the remote site. So the user takes on the responsibility of quoting the relevant text from a linked site, and that is indexed. That seems quite reasonable and doable. Indexing the entire page that is linked to though?
Anyway, this is getting a bit off topic, hah. To bring it back around I’ll just say that I agree with your fundamental premise:
And this connects to a point I’ve made before, here or perhaps elsewhere: when you have a tool that aims to combine multiple tools into one, you immediately increase the need for data management, search, and organization functions simply by virtue of the fact that you have what was once in multiple tools (thus creating de facto distinctions and search domains) now in one tool. You don’t want to lose functionality in the merging, so you actually need search that is ideally at least the combination of the search capability of all the tools being brought together. Greater consolidation demands better capability in certain key areas in the unified system in order to match the benefits of the tools being replaced.
I want to echo the request on being able to extend search to other fields. I think the Fibery team is think about this and have the right ingredients for it given that you already are able to filter entity type. That should then allow you to choose from a type’s fields and easily build your query from there (see discussion here)