Hi Guys,
I believe you are getting onto the subject that has been frequently discussed: A way to reduce the number of fields that show when you have a plethora of Relations to a Type - to put it in more simple terms (which I hope I did!).
Here is one of the better previous convos on the subject, with @Polina_Zenevich in fact weighing in:
@Oshyan, when you mention here:
and touch on Notion, I think that is one of the biggest flaws of Notion, solved only somewhat by Fibery until there is a solution for handling unused Fields. Notion has the negative of a hugely long page when you add relations, which becomes redundant when you add a Linked Database, which in fact you need to do to get a lot of the benefit in Notion.
If Fibery could solve 1) the situation with unused Fields that must at the moment exist when you create a relation, and 2) more ability for “Collections” (that’s the proper term for the many-to-many groupings in an Entity’s details area) to behave like Subtables - for example inline edit - then there is a real benefit over Notion here. This is something that would really help me with my use of Fibery and the whole UX of your app.
And I can’t comment here without thinking of our old friend Polymorphic Relations, since their existence vastly reduces the need for so many fields. And again @Oshyan in that post, you said Conditional Fields would be helpful here. Very true, too! I have many instances when I have a dropdown that if I select one value, I’d like to have a related dropdown field that would either 1) only show up if that value is chosen, or 2) show some filtered options based on the value in the first dropdown. I believe Coda can handle the latter scenario with Formula Filters, so perhaps that’s something Fibery might get sooner than later?
Hope that’s a useful contribution guys!