The display of an entity with none or some of its fields is a good functionality, but it is not contextualizable. This is an important limitation that makes it not very usable. Let’s say that an entity has 10 fields and is represented within 3 different document contexts. In the first context, I only want 2 fields, in the second I want 3 fields, and in the third I want 5 fields. In Fibery, you can choose to display an entity with n fields, for example, and these remain the same for all entities of that type in any document they are displayed in.
Best regards
Diego.
Related:
1 Like
When viewing an entity, what determines the context? Is it the route by which the user has arrived at the entity view?
For example, are you saying that if I open a Task from a timeline view, the fields shown should be different than if I open it from a board view?
If so, this implies that you would need to be able to configure the view for every possible way which you can reach an entity. It sounds like the UX/UI could be quite complicated.
I mainly use Fibery to create knowledge bases for corporate use. Entities represent structured knowledge in fields. Then I use various combinations of the created entities to obtain various types of documents that are integrated within other entities in rich text fields. I use references a lot, but that’s natural in a knowledge base. So it can happen that the “book” entity, represented in a certain context (for example in a glossary entry) where I quote that book, I want to display not only the name field, but also the author field and the subject field (content aspects of the book, what the book is about and who wrote it), while in another context I want to display, besides the name, the location or other similar data (material aspects of the book, where it is located within the library). This need is very frequent, it is impossible that you have not encountered it. How Fibery works today: if I choose for the book entity the name and author fields, these remain for all uses, in all references created in any document. It is limiting to conceive it this way, you have to allow customization at the level of the represented single entity, for each single reference, choose the fields I want. Or provide two options for the creator’s choice: fixed fields for all references once chosen, as it is today, or customized fields at the level of the single reference. I hope I was exhaustive, otherwise I’ll try to produce a concrete example.
1 Like
Thanks for the clarification.
It wasn’t clear to me from your first post that you were referring to entity mentions in rich text.
Judging by his response, I think @Matt_Blais may have also misunderstood your meaning.
Your follow up is very clear, thanks.
I’ve slightly updated the post title for clarity.