References to Views as a way to emulate Embedded Db's in Notion

Ideas & Features
1

Hi guys,

I would love to see some evolution of Backlinks/Highlights to cover Views. We can reference views now, but the Views themselves do not pick up those via Highlights/References. Views I think are a an under developed, powerful part of Fibery that I’d like to see get more attention as first-class citizens.

As there are quite a few former Notion users in here, and I think Fibery has great chance to grow with Notion converts, these users are likely going to look for the ability to create the equivalent of a Page in Notion that has embedded a view of a DB that is filtered or sorted. You can’t do this to the letter in Fibery, but a lot of this functionality is already there:

  • Views are a way to slice by sorting and Filtering only certain data in a Type, but you don’t get saddled with having to create a new Entity, like you do in Notion because to create this type of “view” you need a Page, ie Entity, in Notion. And thus you have to figure out where to put it, etc.

  • Views are available in “#” command, so you can reference them at will across Fibery - great feature!

The shortcoming I’m finding is without the ability to show the highlight back in the View, and for that matter to have some additional data around a View, like a Rich Text description, or perhaps within an App some sort of tag to differentiate various Views, you can’t get the full benefit.

Here’s how I have been finding myself in need of this:

I have some Types that are hard to break down, so I wind up with many, many values in a single-select to differentiate. One such Type is “Vendor.” I have stuff like “credit,” “Tech,” “Consultants,” etc. Some of these in fact would be best off in subgroups which I could do if we had this feature of Dependent Dropdown.

I can set up a View of my “Credit” vendors by creating one, and filtering for that single-select. But now when I want to refer to that View across Fibery, I can’t really do much in the way of highlights or other useful info to describe about my Vendors. In Notion, I can create a page called “credit vendors,” do stuff like write procedures for how to deal with these Credit Vendors, and with Notion’s new backlinks link, with a reciprocal reference, and get a lot of nice benefit I can’t do right now in Fibery. And I can show the Vendors tagged “Credit” with the filtered embedded linked db function Notion offers.

So I think if we just had some additional attributes around Views, which already have part of this functionality, we’d really leapfrog what you can do in Notion and fill a need in Fibery. This is a need I have on a day to day basis.

Thanks for the consideration!

2 Likes
2

It sounds like you want Views to be more like Entities and I’m not sure I think that’s a good idea. They have a specific, clear, and “clean” purpose that makes their functionality easy to access and work with…

I think basically everything you’re suggesting would actually be solved by the ability to Embed Views in Rich Text, which is also a feature of Notion (and which you basically referenced in your topic title), so I’m confused why you’re making a new request for this, when the other is already accepted as per Michael’s response:

If you had that, then instead of a View to handle your need, you’d use an Entity, which - critically - already has all the functions you’re asking be added to views (as far as I can see), and then simply embed one (or more!) Views into it. Ideally it would work like Notion where each View does not have to have a corresponding position in the left-hand navigation, at least if it is embedded in a page.

Am I right in this, or do I misunderstand your request? I’m just really wary of ending up with way too many ways to do everything, and the team having to do essentially duplicate effort and additional design/UX work. Simply adding the “views in rich text” function would give us so much flexibility to solve a ton of problems like this one, and I think even if it’s not quite a perfect solution for all of them, it’s close enough and has high enough other utility that it may be the better dev time focus vs. trying to add things like backlinks to Views.

1 Like
3

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.

Cheers!

1 Like
4

Quick question: if you could create a link to an App or a Type, where should a user be taken when he/she clicks the link?

5

Chris, astute comment as usual (and I don’t hate you, haha…need to respond to that one but I am a big fan of buttons…). Anyway, you are hitting on another need I have - more definition around those areas. Re: Apps a lot of that we covered here:

I think Types should also have some sort of Homepage. I am onboarding three new people this week, and it’s awkward to explain what a Type is without the ability to have some information around them. And I think we really need a sort of “home” of a Type where you can simply see all the Entities in a Type, period. Now, you have to fall back on the auto-generated default Table, which will actually not “follow” the Type if you move it between Apps, which I do frequently.

So yes, you are hitting on a range of needs around what I’d call “completing” the structure around all the piece of Fibery!

Thanks!

2 Likes
6

This is, in fact, not actually correct, and speaks to the concern I had with your original proposal. For example, you cannot link to the “network view” in Roam. Why? Because it’s… a view. Not an object. Not a “thing”. It is a view of data, with controls for adjusting that view of data, but not necessarily something you treat as data. Same seems to me to be true in Fibery. View’s are… views. They are not holders of unique content or things with entity-type properties of their own. Not to say they absolutely shouldn’t be, just that this is how they have been treated and described so far, I believe.

In Notion you also can’t link to a specific view, as far as I know. You can link to a database, but not a specific view of that DB, unless it’s embedded in a page, in which case you’re linking the page not the “view”, really. At least this is all as I understand it. And in the case of linking to DBs there are no backlinks either, AFAIK.

Anyway, all of that being said, I can see your argument for this, but… I’m still not necessarily confident it’s the right approach. Even though my (next) proposal itself seems like a bit of a workaround. Which is that unlike Views - where I am less confident that they should have e.g. backlinks, etc. - with documents I definitely think we should have a way to view backlinks, and maybe more. And so again going back to the Embed Views in Rich Text feature, you would do what you’re suggesting exactly in the way that Notion currently does: by embedding one of more views in a Document (in Fibery’s case) and using the backlinks function of the doc…

I get though that you seem to be wanting Views to really become kind of a specialized Entity in a way, or at least to get some of the overall functionality of them. I’m still unsure what I think of that, but I definitely see your proposed use case as valuable. Whether your proposed solution is the right way to accomplish it is ultimately something the Fibery team will have to determine. :smiley:

1 Like
7

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:

Image 2020-12-19 at 12.35.12 AM
Image 2020-12-19 at 12.35.12 AM1500×1050 257 KB

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!

2 Likes
8

Mm, very interesting. You might be convincing me.

I’ll close my comments overall with this: I absolutely see and generally agree with the primary issue you pointed out here, and even more so with the “type proliferation” that you eventually focused a bit more on. I certainly see the latter as a bigger issue than not having backlinks in views. But most of all I was really just trying to say that your need is real, but I’m not certain your proposed solution is the best or most congruent way to handle it…

Still, as I said, you are starting to convince me a bit. As long as the UI/UX could be implemented well, it could be an interesting expansion of capability that indeed would be beyond what e.g. Notion has.

All that said, if you read through the “Fibery for Product Teams” article that was posted quite recently, I don’t think this kind of thing is going to be high on the list of things to implement. But it’s still always good to think about and discuss this stuff, and ultimately I hope a solution comes which solves at least some of these issues.

1 Like
9

I wanted to revise this as I had another instance when this could come in handy:

We have certain boards that we are building out, and when we make significant changes, it would be very useful if the maker of the changes could annotate for the team what he/she did to change the board. This would be a piece of cake if you could comment, or reference in another entity, like one used for “Memos,” with a reference to the Board. This way, every person coming into the Board after the changes can easily see what was done.

Without this ability, we are forced to Slack, or otherwise go outside Fibery to communicate what changed on the Board. Additionally, we lose the benefit of traceability, a huge benefit of most of the rest of Fibery, as you can’t keep a lot of what’s changed on a Board. We have many key boards that will evolve with the coming months, and it would be extremely useful to document their changes.

Thanks!

2 Likes
10

Would your latest need described here be actually best met by references to views? If so, what entity would you be referencing it from?

To my mind this need would be better met by the ability to comment on Views themselves, and/or add a comment to a change, like how wikis often work “Describe this change”, which would get added to the activity history (assuming a View will eventually have activity history).

2 Likes
11

Thanks for that!

Re: references to Views: Yes, we frequently refer to views, if I want to talk about my Epics in a Meeting, I’ll reference the table for “Epics.” Views are the only way to reference an entire Type right now - those same Epics are in fact a Type, but there is no way to reference them now.

And re: commenting on Views, yes that would be a great starting point to solve the issue of how to document updates to them. This is even more important in the case of Types. Would really love to be able to comment freely on a Type to document what’s been going on with them. This would be a great way to avoid this issue:

For example, if I want to simply add a new Status to a Type. How do I document what I did to my team? I could use a completely other, new Type I might set up just for this purpose called “Documentation,” and write a new Entity saying “In this Type, I added the new State of “Deployed” to go alongside the state of “Done” to show the absolutely final state of this work” etc. That workaround would be completely unnecessary if could comment in Types, just like in Wikipedia as you suggest this is model after.

Thanks!

1 Like
12

Sounds a bit as though you might find it useful to be able to add comments to the audit log.

I have noticed that the entity activity history includes entries relating to changes to the type (as well as changes to the entity content of course).

Perhaps it could be made so that users could click on (or hover over) the activity log to see any associated comments.

1 Like
13

I hate to say it, but in another example of disorganization here in Discourse, I realized that what we are talking about a bit is already discussed here:

The history of the Type changes looks like it’s planned. However, I’d like to be able to see that right on a Type, so I can see - on the level of the Type - all the changes that have been done. @Chr1sG when you say:

I have noticed that the entity activity history includes entries relating to changes to the type (as well as changes to the entity content of course).

Could you point out where you can see in the existing Activity Log changes to the actual Type? For example, if you add something to a dropdown?

Ultimately I still feel a big need to simply be able to go to a View, Type, or even App, and look at its changes right on that level. And also comment about what you are doing. In a sense you can do this in Notion or Coda, because they embed views, and Types for that matter via individual tables, within pages that you can comment on. Fibery’s fundamental structure is better in that it distinguishes among these items and makes them distinct, but until we can do basic things around ALL the items in Fibery (docs and Whiteboards included), like reference, comment, have history, etc. we are not really where we need to be, I think.

Thanks again!

1 Like
14

Would it be enough for your needs if you could literally just add an item to the Type/Entity/App activity/history as a comment? In other words you have other entries in the history view that are generated by changes, but you can also just make comments in there, and maybe correlate them by date or as a comment on a particular history entry?

I ask partly because it sounds like you might want something a bit more clearly exposed and viewable to the average non-admin.

2 Likes
15

I would really like to see both References and Comments available in everything in Fibery. Right now you can actually reference Docs, views, whiteboards, but none of that reference is picked up in those items. Additionally, of those items, in Docs you can reference other Entities, but in those Entities’ References, you can’t see this. So there are a lot of holes here in having this functionality work across the entire Fibery app.

I have seen frequent need for being able to comment in a view. Here is a Use Case:

I create a new board for my team, and want to write a detailed comment about what I’ve done, so they can understand the board. If I have the ability to comment on the view, I can simply make the view, tag the users in question, and they will get a notification to come see the View, and they can read on the View what I wanted to explain with my detailed comment (How to use the View, what is included, etc). And if I decide to change the View, I can write another detailed comment. This is very similar to the documentation that you’d do in Software Development!

How would I do that right now though in Fibery?

Comment in Slack to those same people to come see the View? In that case, the context is not in Fibery, and I have no documentation in Fibery about that View, why it has fields in a certain way, etc. And if I change the view and want to inform my team about these changes, then what? Another Slack comment? Meanwhile the View is changing and there is no record of the changes in Fibery itself.

I can also create a Type called “Documentation” and then create an Entity, write my notes about my view, then tag that Entity to that team, linking to the View. But this is wasteful and proliferates my Fibery with Type I really shouldn’t need.

If I could simply comment in the View, this whole Use Case is elegantly handled.

And I will add in closing that I don’t think Views, Types, Apps would need anything other than Activity Stream, Comments, and References (which are already happening in the case of Views since they are available with the “#” command).

Thanks again for the continued commentary on this subject, let’s hope the team can at least make Comments and Activity Stream universal across all “things” in Fibery!

2 Likes
16

As I’ve commented before, I’m not personally sure that adding comments to views is the way to go to meet your use case. Not to say I don’t get what you want, I absolutely do. And yes a dedicated feature to handle it would be nice. But… I don’t see it as such a valuable long-term use case that it needs a whole dedicated feature when otherwise commenting on a View doesn’t seem like a frequently needed thing (to me).

Instead I once again think that you could achieve exactly what you want if we had Embed Custom Views into Entity View (or Rich Text). Simply create a Doc that you call whatever you’d call the View or, alternatively, create a Type called “Dashboard Views” or something, with a big Rich Text field that you use to embed views, then write text, comment, tag people, etc. to your heart’s content.

We already know that the embedding feature is planned and will enable a tremendous number of other use cases, now including - as far as I can see - this one. Maybe I’m missing something, but doesn’t it make sense to go that route, even if it’s a little clunkier, given what it seems might be involved in adding a whole new way of interacting with Views?

2 Likes
17

Always great to get your commentary!

So I will add that in the last several weeks I have really been feeling that the most natural way for Fibery to evolve for our use would be for the existing “items” that live in Fibery - Apps, Types, Views, Docs, Entities, Whiteboards - to have some common traits, so they function in harmony. We refer to Views more and more in other Entities. This is because 1) you want to often talk about “Epics,” and since you can link to a View that represents all of them (the default table), it is very natural to do so. I would say this is akin to referring to a Page in Roam when you are composing copy in there. As you know, that is a big piece of Roam: you just write, and use [[ ]] to mention another Page. And in Roam, as in Notion, the Page is the only atomic “item” anyway. But you’re able to very naturally reference important parts of your work this way. You may recall I greatly miss the ability to “group” things in Fibery, via a Folder or more accessible Tagging System than we have now. The most natural way to replicate a Folder for us has been using a View.

Since Views live on their own in Fibery, and Fibery is not set up like Roam or Notion where there is just one atomic element - the Page - in which you can embed sub-elements like tables, whiteboards, etc. I think the embedding solution is unnecessarily burdensome for this Use Case I described, and many more. In the scenario you describe, if I follow correctly, you still have a View in the same sense as they exist now in Fibery, that you are embedding in that Doc or Entity, which you then comment on, etc. The thing is, in Fibery, unlike Roam/Notion, that View lives on its own - you can reference it, you have to build it more comprehensively than in Notion, where you can have one table that you simply toggle different views of with a drop down, etc.

If Fibery did not treat Views as a distinct element, that would be one thing. But the Views are showing up on their own via “#” command; they live in the left menu; you can’t have multiple versions ie different filters or sorts within one View. So the structure we have now in Fibery, as my team uses Fibery more and more, leaves us wanting to be able to have the basic ability to comment on Views, just like you can on Entities. Presumably you’ll be able to comment on Docs and Whiteboards one day, maybe even Apps (so you can document what is going on as an App evolves). So it just follows that Views should have this ability, too.

I will also add that my team used Wrike, which had a concept of a Folder to do a lot of what Views do. We also used ClickUp, which has a List to do what Views do (you can also equate a List in ClickUp to a Type). In each of these other apps, you can freely comment on those items. So obviously those Product folks in those apps felt the need to be able to comment on what is essentially a View in Fibery, because they built the functionality. I used those comments when using those two apps, and now I am feeling a lack of this ability as I try to use Views to meet the same need in Fibery.

Hope that’s helpful, and Cheers!

1 Like
18

You can, actually. The DB context menu lets you copy a link to a view, and it’s reflected in the URL (the v= parameter).

With Notion I have the same type of criticism: its power comes from everything being a page, potentially with context from being in a DB. But then it somewhat squanders that power by views being something special tied to a DB (thus causing headaches when wanting to change views on 100s of linked DBs, each with their own copy of the views (e.g. the daily standup meeting template has a linked db filtered to issues for that meeting)), and templates again being something special tied to a DB, and fields being something special shown before the page body, rather than being laid out in the page body like everything else.

  • every table should have a view that lists views, each view in this list should reference all the linked DBs (that are pages) that have that view (building on the table and reference paradigms).
  • same for templates.
  • fields should be laid out using Notion’s powerful layout functionality.

Removing the exceptions would make the UI simpler and consistent, and would unleash a lot of power that’s already there for the taking. E.g. easy bulk edit of templates, to name one.

I see @B_Sp as making the same type of argument for consistency in Fibery.

3 Likes
19

You don’t think they would also benefit from other extensions? Personally, I’d be happy if Documents supported the Workflow and Assignments extensions as well, just like entities…

2 Likes
20

Interesting, all three of you, @B_Sp , @jean1 , @Chr1sG . You may be convincing me.

I think the bottom line is I see several ways of accomplishing the stated goals, some more seemingly elegant for these purposes than others, but which may either be more costly to develop, or come at some cost to other advantages such as simplicity. A good example of the danger of that is ClickUp. It has a ton of power and I loved that at first, but man does it have a cluttered UI! And I think that is in part because they do try to just cram in every dang feature (while also somehow still being less flexible than Fibery and some others :grinning_face_with_smiling_eyes:).

But I digress. My point is the things you want to accomplish are totally valid, and some of them I want too. I’m just not sure what is most congruent with Fibery’s underlying approach. The more you talk about it the more I’d like to see things actually somehow get even more generalized and flexible. We have the flexibility of Types, and various kinds of Relationships. We have the flexibility of Extensions. We have Fields. We have References and Backlinks and eventually Transclusion. We have Docs (which could really just be a particular configuration of a Type?). We have Views and Charts… All these pieces that have specific functions and roles and places, but could be a bit more “unmoored” from their “anchor” of specific location/relationship/etc., i.e. rigidity.

If we could more freely combine all those things, it would be amazing. If we could have a Chart in a View in a Doc/Type, and a Field in an arbitrary place in a Doc/Rich Text even (i.e. a block-based system, with one of the block types being “field”). If the “Collections” were just a particular type of View, perhaps? If Views could have Comments and Extensions, etc, etc. It would all be really cool.

But how feasible is all that? How much work for the team? How difficult to figure out how to make it all work, nevermind doing the work itself to program it? How much more challenging to document adn communicate to prospective customers and train people, etc? I don’t know. It’s a beautiful vision of the future (and I realize that I’ve probably taken some of what you said and over-extended the idea of flexibility to make my point). For now the question is how best to implement the features you’re asking for within the framework of what Fibery Team envisions for its future, the work they already know they want to do to improve and extend it.

Given all the discussion here I would really love to see their take on all this. There are strong hints of plans for greater flexibility in the future. So what is the plan to get there? I’d love to know, even just in outline or general ideas (from the team).

2 Likes