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

Ideas & Features
21

Thank you all for the really insightful and deep discussion. I’ll try to highlight our thoughts about View/Docs in Fibery and how it will fit together in the future. Note that this is not a plan yet, just intentions.

Documents (usual or block)

Initially, when we started design Fibery, we paid less attention to documents. We were focused on flexible domain and work management, but quite quickly discovered that documents are essential. Here we had two options:

  1. Implement usual text documents (like Google Doc)
  2. Go for Blocks approach (like Notion, Coda and new Wordpress)

Both approaches have benefits and problems. Documents In Fibery are part of Types in general, so we decided to go with usual text and implemented rich edit field based on ProseMirror.

Looking back I think this was a mistake, since blocks approach is more flexible and would give us more power in terms of Entity View composition.

Blocks

Now we are thinking about Blocks addition into Entity View. Technically it should be possible to compose Entity View using any kind of Blocks (Table with related entities, Chart, native Fields, text, images, transclusions, etc). It means Block should be a first-class thing in Fibery. You may transclude or refer blocks, comment on blocks, have emoji for blocks, re-arrange them, etc.

There are many unknowns:

  • How fast Entity View will operate if there will be 20-100 blocks?
  • How it will affect Fibery complexity (conceptually)?
  • How to make transclusions usable and useful?
  • What will happen if people will add dozens of blocks with rich edit text?
  • How to marry blocks with rich edit fields like Description? In fact there will be no Description field anymore, so how to handle this via API/integrations? Should we allow Named Blocks?

As you see, there are many conceptual and technical problems. I have a feeling that they are solvable.

Is it important and when you’ll do it?

I think it is very important and to be honest this is the last missing piece in Fibery to provide unmatched flexibility (well, + automatic rules, but they are in progress).

However, this project is a very challenging and will demand a team of 2-4 developers for ~4-6 months. So far we are working on things with more dense feedback (search, sharing, etc). But I do hope will get back to this problem in 2-3 months, so in the best case it will be delivered in the end of 2021.

Our sensing of the situation may change and we may start working on it sooner, but from what we hear this is not a top problem with Fibery adoption.

5 Likes
22

Thanks Michael, that is very encouraging! I know it must be a big project, so I don’t expect it soon. But just knowing that Fibery is planning to head in this direction is exciting to me.

1 Like
24

Yes great point here Chris (sorry just catching up to some older posts I wanted to weigh in on…).

I think you and @rothnic , if I’m not mistaken, have been advocating for more unification of functionality around all of the “items” we have in Fibery. If so, this is a big ask of mine. I think all off this list:

  • Views
  • Apps
  • Types
  • Whiteboards
  • Comments (this is one seldom discussed, but of increased relevance to my team)

Had essentially most of the functionality in Entities. So you could:

  • reference one with another (via comments if they won’t all have Rich Text available)
  • Assign any of them.
  • Have use of a Date Extension where it would make sense

As for Docs, I have come to think that Docs could really just be another Type. I can’t see any particular benefit using an actual Doc over an individual Entity, other than aesthetically losing the border around the Rich Text box. But the existence of Docs as yet another item in Fibery - which is currently unevolved since you can’t reference them, comment in them, etc. - complicates my use. My sentiment here is partially influenced by Notion and how Docs and Entities are basically interchangeable, which I think works great in Notion. You simply choose do you have a “page” - a “doc” in Fibery - by simply clicking “return” when you create one, or if you have an Fibery equivalent “entity” - if you decide to add a new Page to an existing db. Notion falls down badly in the areas of Views, relations, Hierarchy view, etc. but in the case of Doc. vs. Entity I think it shows how interchangeable those can be, and Fibery is perfectly equipped to handle this because you can create such a powerful doc with an Entity. Try doing that in Wrike or ClickUp!

And I want to add that I really hope Comments become first-class citizens and get into this discussion, too. I have had several instances when I wanted to quote a comment around Fibery as liberally as I can now quote/reference an Entity. There are unanswered Comments that need to be referenced in various types of Entities to make sure they are documented - this is just one use case.

Clubhouse.io does a great job here - each Comment has its own ID, and this is a real help in referencing them across that app.

Thanks guys!

3 Likes