Comment fields and inline comments to be entities with fields (comments database)

Ideas & Features
1

Collaboration is heavily dependent on the commenting system. As I see now, Fibery is not yet very focused on collaboration, more on data structure. There are in a few days already a number of my posts about UX and end user workflow issues.

The comment field is currently not a database entity type with fields. Neither are the richt text inline comments. Both comment field and rich text inline comments are currently resulting in isolated items that cannot be organized in a way that I find useful for a team.

What I suggest is to make all comments (fields and inline) fieldable entities. This would allow for a similar configurability as normal database entities. It would allow for lists and tables etc.

2

related: Please make Whiteboard/Form/etc just fields, not isolated artefacts - #3 by Yuri_BC

3

Comments in entities is a table in a database (and a separate Entity Type) under the hood, but it is not exposed. We are considering making it first-class entity in fact.

5 Likes
4

What do you mean by “first-class entity”.
Is there any update on this one? There could be huge potential in exposing the comments database. Or even better, allowing admins to create and link their own comments data base.

Potential:
Linking comments to LinkedIn API and chat with prospects directly in Fibery with a Chat within the entity. This would have to mean changing the “Author” of comments to “Person” which is linked to another “People” database. But this could have really interesting implications.

Basically adding another “Chat” view to the list of views, which I see is sort of being done with Threads. (But is still limited to connecting to the predefined comments database)

1 Like
5

Comments are not stored in the same way as entities in other fully-fledged databases are

6

Is there any update on this?

I find the inline/richtext “resolution-comments” rather useful even if they are currently only available for entities’ description:

However it would be nice to expose those separately, akin to displaying regular comment counts. Preferably with Open vs. Resolved states so we can streamline pending “Mini-Tasks” or information into top-level table views etc.

Exposing the last true modification date on per-“property” level would also be awesome. I run time-based, hourly automations rendering last global modification basically useless vs. true human interactions or modifications.

► This would further leverage sorting by genuine recent activity or leveraging more practical and statistical/performance “KPI”'s as well.

Currently I have to consider/test relating a separate, dedicated timebased db to avoid system-based modification-dates and I’m not even sure if it’s feasible. Any relation will probably update the parent/main as well. :F

► The inline-comments do not seem to globally count/trigger towards the regular “comment” column or datatype from my current tests either.

The number of comments, reso-comments, open-vs-resolved + entity/property-based modification dates would bring huge benefits even without using any sort of feeds/highlights, aggregations… right there in the actual main workdata or tables.

Without it to the user the “comment-number” is somewhat less indicative as it does not relate to activity/modification date nor to any pending/open inline-comment “minitasks” or to-be-read info. Especially when the comment numbers rise; They are usually a mix of doc/research/info AND genuine priority info or minitasks.

If this were implemented we could have separate, extra-columns or coloring/sorting for pending reso-comments or other sorts of modification-date based logic - so end-users know “oh, has some files, generic comments, but actually some open minitasks or read-info” - I should certainly look at those.

► Ideally the mini-tasks, i.e. reso-comments could be set to an AND vs OR option to a dict/list where each destined recipient has to “checkmark” to confirm reading, task-resolution etc. individually; Controlling if a reso-comment can be resolved by an individual, or has to be resolved by all mention-recipients. ► We also use reso-comments to announce/resolve new/interesting documentation entries etc. for example.

2 Likes
7

These are all very good suggestions, thanks!

What I expect, is that at some point the fibery team will build a new Comments feature on top of the HighLights feature, since the highlights are already first-class entities.

I think Fibery 2.0 introduces the highlights as a new a new fundamental framework to build key Fibery features on, and comments will be very likely part of that. I’m interested to hear about that.

1 Like