All good points as always. To some of them:
I think you are not comparing apples to apples here, as in Roam the Views you have are sparingly implemented, and more like Whiteboard I’d argue in Fibery. In Fibery, in order to get certain breakdown of Data, like looking at different groupings like I mentioned in my example, you can’t achieve this aside from with a View. I have already 100 + views in Fibery and growing quickly, because they’re all needed. In Roam, all pieces that I think you’d compare to comments, docs, Views, Types, Apps are Pages, and thus can be linked to and fully manipulated.
I think the same is true for Notion. You are right, you would have very similar functionality with an embedded view in Notion in a page, than with your suggestion re: Embedded views in an Entity. The problem for me is, in Notion it’s much easier for me to manipulate those Pages with the views, much more freely. Key: You don’t need a Type first and all the associated overhead to make such a view. So when I create a linkable view in Notion, I make a db inside a Page, and link to the Page. Because as you point out, backlinks don’t work on Db’s. But that’s about all Notion’s missing, and I think it’s a minimal workaround to just house that db in a page named the same and you get the same effect. You get the ability I’m talking about to add more data, too - like subpages if you want to point your team to procedures in how to deal with Consultants, or Credit Cards, to keep with my example. In Fibery to do the same, I need 7 types (since I happen to have Vendors grouped in 7 multi-select Categories). You and I have chatted a lot about “Entity view Proliferation of Fields,” and unless we get Polymorphic, with each Type, you are stuck with more proliferation in Fibery. Did you see the Product Team blog post today and that set up? Michael once advised in the community that they thought teams would be OK with 15 - 20 types. There is no way I can get the same company-wide granularity I can achieve with Notion limiting to that few types. Apparently Fibery itself hasn’t come close, either! If fact, when in the post Michael said:
I get nervous when I see that Fibery itself, after 2.5 years of use, has now that much redundant data.
That might seem like a tangent, but I could easily see creating extra Types and Entities for something like internal dev teams, which I can’t represent well in a View because they are unlinkable right now. But in reality, all I have to do to represent a team is have a single-select called “Team,” in my User Type. Then create a view filtering for that. But I need to be able to link to, mention, refer to the team, build some metadata, etc. So for now, the only way to do that is create yet another Type, “Team.” and start to link that to the Users on the team to accomplish this. A lot of Overhead.
In closing this time around, I think it’s interesting to think if the Fibery team did build out more linking and meta capability in Views. Because that would give Fibery actually a superior set up to Notion, as you’d lose the Notion overhead, however small I’m claiming it is, of having to create a page to create the ability to link to a DB. I just am not sure what the problem is in being able to do more with Views. And I feel like there is a lot of upside. And in reality this is a feature that would live in tandem with your great request of Embedded Views, which I could see myself making use of a lot, for example to show inside a Sprint Entity a Kanban Board of work. But I think we are talking about two separate needs, and I hope the team will consider mine in some format as it would really help avoid workarounds that I fear will start to resemble Fibery Technical Debt.
Thanks again as always!