One main issue I keep on having with Fibery, is that it has Documents which are not entities, don’t have fields, and are therefore lack all the ways entities are managed and listed in Fibery.
Looking at any other app that evolved from wiki or note-taking to a more relationship based and fieldabel type of collaboration system (like Notion, Drupal etc) the documents or pages are made more generic items that are fieldable entities.
I like to hear from the designers of Fibery (like @mdubakov) specifically why they decide to persist on Document to be so minimalistic and still have a prominent place in the Fibery ecosystem. As I suggested in another post I would just decide to not continue using Documents in Fibery, but simple allow users to create a generic page entity which has much more features already built in being en entity.
The only feature I see documents at this point have benefit over entities, is that they can be nested hierarchically in each other. This however, is the most wanted feature I like to see in all entities, and the most missing. I remember @mdubakov a few weeks ago ask users what would be their most wanted functionality that is still missing. For me, that is this hierarchical nesting of entities of the same type. That would immediately allow the current ‘Documents’ in Fibery to be obsolete and that would make Fibery much less confusing and more simple.
Apart from that, I consider Fibery promising and when the UX issues, relationship properties, and the above issue are resolved, it definately will stand out from other apps. Thank you!
I’d definitely be interested to hear what other community members think about Documents.
I understand that they lack the ability to add fields, but if you were to add a field to a single document, would you expect that field to be available for all documents?
Given that a Document can at any point be converted to an entity, it seems reasonable to me that they function well as a holder of unstructured information, which can, if necessary become part of a structure.
With database self-relations being possible (and displayable using smart folders) I wonder what you think is missing?
We are currently creating a Wiki inside Fibery for our customers. So that the user has all needed information in their own workspace.
We’ve created a document database so that we can create an overview of applicable Wiki’s per space.
Example: in ‘Customer & leads’ only show the Wiki articles that are applicable for that space.
We also rather use the document database because we then can turn off references. Because that’s not always helpful for a customer. We don’t have that option in documents.
My conclusion: sometimes it can be helpful to put documents in a database. So that you have more flexibility if you would like to create views/filters etc.
For SOP’s we also rather use databases so we can provide extra meta data (such as owner, last time updated, etc.)
What is the issue if you can create a database for documents?
In my opinion you can have best of both worlds:
Use documents when you think that’s helpful for your use case
Create documents as entities when that’s more helpful for your use case
With the latest update user will not notice much differences.
That’s possible, we use that a lot. And therefor it doesn’t really matter if you use documents as is, or in a ‘document database’
Both can show nested. Since you can create a smart folder or a list for documents when you rather have them in a database.
Example of nested self related themes
Just click on the icon next to + sign Will work in list views and smart folders.
