This has been mentioned several times in various posts and requests, but never really seemed to have its own clear feature request, and I think it’s important:
We need the ability to embed arbitrary Views into Rich Text fields anywhere (including Documents). Notion is really the best existing example of this and for the most part it handles this very well. You can embed a view of a database (Type) and filter and sort it as you desire. You can change the view type, card, calendar, list, gallery. And you can also embed as many DB views as you want on a given page.
Since Notion doesn’t have the strong bi-directional and many-to-many relationships of Fibery, their DB embeds are actually kind of poor in comparison to Fibery for some purposes. But for simpler “just for reference” or more free-form type stuff, Notion actually wins. Having both would be best, strong, complex relationship structures when necessary, simple, flexible data views in any rich text field when not.
Also of course in Fibery the embed options should include whiteboards and even docs, basically any “View”.
I think this functionality might partly or entirely address several other requests, too:
I support this request as yet an additional flexibility feature of Fibery.
I will say though that as another seasoned user of Notion - and I agree 100% with what you’re saying @Oshyan in the ease in creating views with linked db’s in Notion, and that for now Notion wins here vs. Fibery - that I think Fibery has a leg up because Entities are not predicated on a ‘Page’ or Rich Text only foundation. To clarify, what I mean is you build an Entity with all the available Fields, which is great. I think Fibery has Notion beat here because Notion’s approach gets exposed, in my opinion, when Pages become db records because you get stuck with the whole forced list of Fields (“Properties” in Notion-speak) and have to create a linked db to see a nice display of those relations. So you are forced into two places where the relations show up - in the top of the Page in the Properties, and in your linked db. Fibery doesn’t force that since you aren’t forced to have a “Page” that has Rich Text imposed as a blank canvas. And you can even have multiple Rich Text fields - each with equal functionality to Notion’s canvas - if you need to, and I’ve made great use of this.
So as a priority I’d like to see more capability in the entire Entity Details/Card view, and not just focus on the Rich Text View. If you do that without addressing the entire Entity view, we are going down the road of Notion. I think this would lead to the need to use Docs in Fibery more than Entities. I think Fibery in fact works best when you don’t use Docs that much, maybe as just a supplement to Entities if you really need to just “write something.” But in most cases you can use a simple Entity to handle all the uses of Docs, but you get the benefit of the metadata that Entities bring.
So if Rich Text gets embeds, but we are left with continued limitations of Entities themselves, I think Fibery will remain limited for a longer time. In the end, the Rich Text field is not the actual Entity.
Hope that’s useful and either way I’d like to see Rich Text embeds down the road!
While I agree that Fibery’s approach is superior to Notion’s in the way you describe (and more), I also see a lot of requests being made here (and I have many more I could make myself, but I’m holding off a bit). Ultimately, despite a lot of flexibility, Fibery will have to make some choices about what is possible and what is not in Entity views. Not everyone will agree with these choices, no matter what.
What’s cool about Embeds in Rich Text is that they have a broad impact and potential utility. Check out Michael Dubakov’s excellent article on how to prioritize features, if you have not already done so. https://uxdesign.cc/use-networks-to-prioritize-features-c08cdaaafb95
So thinking about some of what was discussed there, to my mind Rich Text embeds have a relatively high number of connections between other features that exist (Documents, Types), or that should exist (Dashboards), and potentially lots of connections to Use Cases as well. And in particular here I think it’s the very flexibility that already exists in the Entity views that gives embeds a lot of potential to solve many problems that otherwise require possibly very complex configuration of Entity view.
So for example you can add a View of any specific Entity anywhere in left column of any individual Entity or View of multiple Entities (e.g. Table) just by using an Embed in a Rich Text field. The fact that it’s a Rich Text field is virtually immaterial, the point is it acts more like a “swiss army knife” when rich embeds are possible (like Notion). And Fibery could take it one step further by allowing Embeds to take on Context just like Backlinks do, i.e. the embedded View knows which page(s) it is on, and you can use that to get other useful benefits just like Backlinks.
The alternative is to develop an ability to add arbitrary Collections to any Type without relations, along with ability to add anything else that could be Embedded as its own field type. This grows the list of fields/extensions, perhaps unnecessarily, and requires individual development of each of them. And it still doesn’t allow for the capability of e.g. instantiating a Table view right in your document, which has its own benefits.
The ability to create almost infinitely flexible “dashboards” like Notion has comes directly from the Embed functionality. There is no other good way that I know of to allow such flexible information surfacing and combination in a single view without also increasing complexity of the system and implementation time significantly. And in Fibery it could be even more powerful than in Notion for a number of reasons, some of which I’ve touched on above.
This seems to be close to the polymorphism that has been discussed elsewhere, and that seems to me to be a preferable solution. I note that you specifically state
As an aside, isn’t it the case that ‘embedding views/entities’ is just a way to allow the details of something that can already be #mentioned (view or entity) to become visible at the mentioning level. So you’re basically saving the user having to click-through, right?
Good point Chris. I would also point out that @mdubakov has discussed that he plans to allow 100% configurable the #mention of the other entity, which would be a real move forward on other apps such as Jira that just show a static amount of info of issue ID, name, state. Currently we have that, plus assignee, but if you could configure (I’m guessing here) to add even Rich Text out of an entity, this almost accomplishes embedding.
If you could then pop open those fields, modal-style, without exiting the Entity you’re on, I think you’d eat a great feature that would save clicks and increase visibility across Fibery.
The benefit of doing all this without relations is that it’s even more flexible than Polymorphism might be and it doesn’t create actual relations, so you avoid a “spaghetti” of relation lines in the back-end. Of course polymorphic will have to solve that anyway. But the bottom line is that Notion and a huge number of templates demonstrate pretty clearly why embeds could be very powerful and useful. And in Fibery I think they could be made even more so.
Basically, yes, but describing it that way arguably trivializes it a bit more than it deserves. Again there are a zillion Notion templates that demonstrate the benefit of this, but here are two reasons why this is a non-trivial benefit.
First, we are hoping to see the big menu tree on the left side being solved in some way(s). Rather than needing to have each View be a link in that menu, embedding them in Rich Text (e.g. a Doc) would allow you to have as many views as you want in one place, with a single menu item on the left to access them. All views related to a particular workflow, type of work, etc. could be in a single “view”.
Second, stemming from the above, the logical extension of this is the “dashboard” concept. So for a real estate broker in an agency, for example, each employee could have a view that shows the properties they’re representing and the primary seller contacts for them, along with a view of open potential buyer entities, maybe a comparison graph showing how they’re doing in sales that month vs. others (I’m not a fan of that kind of thing personally, but some real estate agencies have “leader boards” for their brokers IRL), etc. They have at their finger tips all the info they need to work through their sales process that day.
Or imagine you are a startup founder for a complicated software product developed by a small team. You act as product manager, but also deal with revenue and funding, and other things. Many areas of the business are important to you. You want to start your morning getting a clear idea of how the product’s development is progressing, any new sales leads or signups, perhaps new feature requests, and more. All of this data could potentially be tracked in Fibery, and even more so once we have Forms with public input for example (feature request, sales lead, etc.).
So product management review involves looking at task status for the whole team, at a minimum. That’s 1 view, if not more with graphs. Revenue is another view, and you’ll probably have at least 1 chart, maybe several for that. Bug reports is another area with potentially multiple charts, lists, etc. And on it goes.
You can either have a folder with all these views in it and click between them, 5-10 clicks, and losing context between them, or you can have a single page, and if you have columns, all the better. You have your MRR graph in the upper-right, big enough to see changes, but small enough to leave room for your feature/bug list(s) on the left (i.e. table, or kanban); below MRR is a graph of new signups, bug report to fix ratios, staff workloads, etc. So on the right you can see trends in graphs (which you can click on to pop-up full size if needed), on the left you can interact with the work in table or card views, reassign tasks if needed for example, whatever. You have it all in one view. You may need to scroll vertically, but you can dynamically review and reference a wide range of data without changing contexts.
Again, Notion exemplifies a lot of this already. They just don’t have native charts, which makes an even more compelling use case.
All that said, I just realized that Whiteboards could arguably be a good solution to this as well, with the same Embed functionality. They obviate the need for “columns” with totally free layout.
I think I’d be in favor of this, as you describe. Basically “embeds” would be handled as an extension of the existing linking functionality, which already dynamically pulls info and displays it. If that could be configurable, as you say Michael has implied (I haven’t seen where he mentioned that), and if you could surface Rich Text fields as well, and have them display sensibly, then great. That said there would need to be good ways of setting defaults, and/or using templates, or something so that you didn’t have to do a bunch of configuration on every entity/view link each time you used one.
I trust that, with this request and others outlined in detail, they will find a good way to cover a majority of the needs we all have, in time.
Hey @Oshyan , great commentary today I agree with most of what you said and I will reply in due course to that effect!
But since this is a priority of yours, wanted to point out where I’m interpreting @mdubakov’s comments to mean that he and team have plans to build out customization of embedded links to entities, see below:
When he says “we are going to expand it to be fully customizable” that is what gave me hope!
I believe this also may have been discussed in either Twitter or one of the Chronicles, but can’t recall exactly where right now.
I meant it to demonstrate agreement with your intent
That is to say, I would love for #mentions to be able to be more than just a hyperlink to the view/entity being mentioned. The fewer clicks the better!
I didn’t mean to sound like I was downplaying the usefulness.
And it does seem like one way of solving this is to make #mentions capable of surfacing more detail.
However, I think there’s an important point to take into consideration, which you touch on indirectly:
Either an embedded view is one that is unique to the host item (in which case, it would require configuring upon creation) or it is a view that is capable of being embedded in multiple places (in which case, the embedded item - or template - has a life of its own outside the items it is embedded in).
If the first option seems like unnecessary work, the second option seems like what we have already: predefined views which can then be #mentioned anywhere you want.
Anyway, it’s maybe because I like my data to be more structured that I prefer the implementation to be made with polymorphism + enhanced representation/functionality of linked collections.
I’m sure the wise people at fibery will surprise us with an implementation that nobody had thought of and which keeps us all happy
Just adding my two cents - the ability to embed interactive, customizable views into Rich Text fields and Whiteboards (and someday, Dashboards) is my number one feature request.
Example:
My Project type has a related Tasks collection
My Project entity view currently only shows a list of its related Tasks
In the Project entity view somewhere (a Rich Text field), I would like to put a Table view for the related Tasks – for example filtering only Tasks that:
have a “not Final” Workflow State, and
have a “Type” field is not one of [“ADMIN”, “CALLS”]
Interactive: allows editing the tasks in the Table without having to open them
Customizable: allows adjusting the Sort/Filter criteria
Notion.so handles this very well with saved Views, making it super easy to select a saved View or define a new View right there; and all these Views are accessible everywhere – so powerful!
I have a very similar use case as what you describe and would also rate this near the top of my list if not the very top. Right now you really need a separate view that is disconnected from the entity, or you have to use a smart folder, but this can’t always be used because of the limitations you can see I was fighting with here: JIRA Integration Causes Issues with Context Views.
It feels like Notion does this the most intuitive way with the properties and the canvas always being part of an entity. It feels like Coda and Fibery are kind of trying to appease the root needs of their users while specifically trying to avoid giving in to taking the approach Notion took. I think how Notion implemented this is probably its killer feature.
One other thing to mention is that in Coda, even though they don’t support embedding tables/views within a canvas/rich text field in the entity, you can at least convert a lookup field display into a table to achieve something like what you are wanting. For example, the screenshot below shows an example of a meeting entity that has a list of notes that are associated with a topic, which can be designated an action.
I do agree that Custom Views inside Entity View are a very good thing to have. We are thinking heavily about Entity View re-design and keeping in mind this problem. So far I recommend this workaround:
I really, really love this feature because it can save so much time in making sure you have consistent views for each entity, and would serve as a pretty good workaround for me, but there are key limitations that impact the utility of it.
I cannot consistently use it. I don’t understand why in a service that promotes building this graph of inter-related types that so many features require a very specific type of relationship to work. I cannot just model the data without thinking about which features I might not be able to use. This feature needs to think what it is displaying as a group, not a hierarchy for it to be consistently useful. You should be able to group on any entity relationship without worrying about it being a one to many relationship.
There is no reference to the view that it “owns” in a way from the entity. If you just open the “Action Button” entity in a different context or with the sidebar collapsed, you don’t have a way to quickly jump to the “Backlog” view for the “Action Button” entities.
I think this commentary is great, and I would add that I’ve found if you make the wrong decision, you get into a tough spot. Have you tried changing one of your relations from one-to-one to Many-to-One? I still have some of these orphan relations that I can’t find time to go through and manually remap the relations once I change them.
