Hey, always great to get your feedback!
And yes of course I support fully your excellent request around Embed Views in Rich text, but the distinction I’m trying to make is that your solution is still at the Entity level.
So if I have a Type called “Vendor,” and I want to do a lot with groups of Vendors, like Credit vs. Marketing Networks, two types of vendors which are largely different, other than the commonality that I pay them both. If I am going to try to do this with any Entity-based solution, I have to have an Entity for each of these “groups” that I’m representing with my single-select. My point is I don’t want to set up 7 new types when the single-select should be sufficient.
***As a related point to my comment re: Grouping Types, even if I created those 7 Types, I’d like to be able to go back “up” the hierarchy and group them all as “Vendors,” and the only way to do that now is to create an artificial field with the default value “Vendor” and then make sure all these Types have that filled out, which is an odd workaround I don’t have to do in Notion if I want to do the same thing - I just create a Page that I can do all sorts of things with and link each of those Type’s DB’s to…
But getting back to the point, the Views are of big value to me and I’d like to be able to build them liberally, and then refer to them because they represent things you can’t do with just an Entity. Is this clearer now?
The fact is right now I would be happy in Views with just linking picking up a back-reference like on Entities. If other metadata like Description, etc. is too hard to implement, then I could wait on that. But without any additional way to characterize a View such as a tag, date created, activity stream, etc., you won’t be able to emulate Notion. And I for one would very much like to see the history of Views - when they are created, who created them, etc. as that is useful to my use case.
And I will go so far as to say that in fact by NOT being able to relate to everything yet in Fibery, I feel there is a limitation that other tools that do allow this have gotten past. In reality, relating to “everything” is also a huge part of Roam, and not just Notion. Without the ability to reference everything, we are not fully able to work in the full networked thinking approach which I am a big advocate of. I continue to hope that Fibery will become the go-to tool for this approach as far as work management, as those two tools are flawed in this role. But we need everything in Fibery linkable two-ways. So if I want to point my team to an App, or Type, in a document about how to use Fibery, I can’t link to either. That’s a drawback.
Currently in Fibery, some things are linkable with no back references, like Docs and Views, while others, like Apps, Types, and Comments (which is also a legit “entity” for linking - Clubhouse.io allows this, we used it, and it was very useful). These are all key pieces of Fibery. Without full linking, we’re at risk of more limited functionality in the end, along the lines of say ClickUp, where at least you can see the reciprocal link to Docs, something you can’t do in Fibery because if you link to a Doc, you don’t see any reference in the Doc itself.
I fully hope that Fibery doesn’t stop the linking at just the Entity/Doc/View level, as this would be a huge disappointment of the promise of full linking inside Fibery to everything that exists within, just like you can do with Notion.