We create a new Entity View where per-Type elements (rich-text Fields → Text Blocks, context Lists → View Blocks, etc.) coexist with per-Entity elements (Text/Whiteboard/View Block).
Structured Fields (currently on the right) are left intact for now.
No need to migrate EVERYTHING on the left (Files, Comments, etc.), these things are enough for the first iteration:
Text Block (aka collabdoc, Prose Mirror)
Permissions for native Blocks are a must.
Contributors+ can reorder/add/remove Blocks on a specific Entity straight away. Per-Type configuration for Creators now lives on a separate screen or in a separate mode.
Add a reaction - I have not yet understood this function in outliners. What a profit from her. The main thing is that then all these “reactions” do not “clog” the “Notifications” section.
Regarding the “high-grained” - I agree. PKM uses a smaller block scale, but there is much less information there. If you increase the focus too much, you will quickly “get lost” in a huge number of these blocks.
The only thing is that it will not always be possible to make an adequate transinclusion. Users will have to train themselves to write texts in a certain logical format: atomic and “portable”.
I’m a little hesitant to have too much of a reaction without seeing exactly how this works in practice. The thing I worry about by making the blocks larger elements is just that you might lose the ability to tie them together with supporting text and additional context without having to create new fields.
For example, let’s say that we have a working document that wants to always have the most up-to-date reference of our top 3 initiatives. So, we have an Initiatives type that maybe has a checkbox to say a particular initiative is a top initiative. We also might have an existing list view setup that applies that filter, with the view name of “Top Product Initiatives”.
So, to begin with the document might have an intro paragraph with some kind of statement. You then could add our existing view just below the intro paragraph. A common modification might be to override the view name just within the context of this document, allow the list view to collapse below the heading, hide the heading, or simplify the presentation (fewer columns shown). We might then add some additional text just below the embedded view that lets the reader know where they can submit new Initiative ideas.
So my questions from this use case would be:
Are you developing this so a standalone document can include blocks?
From the OP, I can’t really understand what you are/aren’t considering blocks. It seems like Rich Text fields and maybe Views would be considered blocks, but fields are not? (e.g., Problem in the screenshot is a rich text field, which i understand is essentially a Document. Can a stand-alone document be a block that has blocks in it?)
Is the helper intro text and text after the view in my described use case separate rich text fields? In other words, would we have to add rich text fields each time we want to add a paragraph between two views that have been embedded as blocks?
Are you considering if you’d support features/modifications to the view as I described? Collapsible heading, override heading, hide heading, hide columns, etc while not impacting the original view?
One of the things I really like in Coda is that you can create more of a living document by querying tables and transforming the data to be included in the block in a unique way. I worry a bit that by creating larger chunks of text as blocks, then something like what I show below wouldn’t naturally fit in. Notice the count of open bugs and list of incomplete features are active queries, similar to a view that are being included as-needed into the document.
Yes, sure. A document will consist of blocks. Fallback mode is a single text block (you have it right now)
Block types:
Rich edit text
View (table, timeline, etc)
Chart
Special: Files, Comments?, etc
We are thinking whether usual field can be a block. It is easy to add, but in the first releases most likely it will not be done
Technically in this case you will add 3 blocks: Text - View - Text. There is no need to create rich edit fields, these two text fields will be just blocks. So the flow will be like:
Click + New Block, Add Text block
Write some text
Click + New Block, Add View block.
Customize View as you wish
Click + New block, Add Text block
…
We did not consider it initially, but this is a very good idea, we will explore it in more details. Take a look @antoniokov
This scenario in Fibery will be handled by two Views blocks. So far there is no element to show a formula result, but technically it can be done as a separate Block, or as an extension in Rich Edit field.
As for the “RichEdit text” blocks, there is such a thought (since you are moving to the new block model anyway ) — Add versioning (history) at the block level.
For some reason, Roam Research does not mention this function in its help and does not emphasize it. But in my opinion, it is from the must have series. For those who write long complex texts.
In “RoamResearch” this function is somewhat similar to git: «You decide on your own when and where to add a version».
There is no need for automation, completely manual mode.
I know Michael addressed this, but in case there is remaining confusion, my understanding is that Blocks will be arbitrary units of content/functionality, and will not have to be consistent from entity to entity, thus they do not involve creating “fields”. They are a more “lightweight” solution than formalized Type modifications, i.e. new Fields. Perhaps that is a more direct/succinct answer to the root of your question/concern.
Think of them like blocks in Notion, simply individually manipulatable and addressable pieces of content/functionality, created ad-hoc. It seems like the primary change/improvement vs. existing Rich Text and Doc contents in Fibery will be the individual addressability and manipulation of these Blocks as whole units, rather than simple “free text”. Making them “objects” allows for greater functionality on each one (linking, commenting, reacting, transcluding), while maintaining flexibility and avoiding the complexity and “heaviness” of Fields.
I would also really love to see “in-line calculated values” like Coda and a couple other tools can do. It feels like a very natural and useful extension of the blocks concept you’re working on, and would be necessary for real parity with and ultimately improvement over the Coda examples I referenced in this other discussion:
I suppose it would/could just be another / menu function…
Take a closer look at the mockup, there is a history button on each block already. Assuming the mockup is accurate, it seems they are already planning this.
Yeah, that might have been where I was confused a bit. He said “Problem is a block, Solution is another block.,” which made me think that problem and solution were consistent rich text fields that would exist on each entity of that type.
So yeah, as long as you can add rich text blocks ad-hoc as needed, then that solves my concern.
Ahh, I see, you specifically want named versions. Well, this feature doesn’t exist in Fibery yet, but has been requested. And based on what Michael says below, I suspect that if/when named versions are implemented at all, they will immediately work for Block versions too (if so, great!).
Can you clarify what you mean by “large” text block?
Excellent, that’s exciting news! More and more Fibery looks appropriate for a personal knowledge management system too.
This is where my confusion came in. I’m aware that each rich text field and document is a separate prosemirror document, which allows the fibery team to support collaborative editing, etc without building it out on their own. So, i thought that each rich text block would require a rich text field. However, it sounds like that won’t be required.
So, to answer your question, it sounds like all text and embedded items you add to a rich text block when you click “+ block” would be a single unit of content. You could write a single word or a novel in that block and fibery will treat it as a single chunk of content. Each line of text you write in that rich text area won’t be its own block that you could drag around like roamresearch, notion, coda, etc work. So, if they provide the ability to transclude a block of rich text, then it would be for the whole block of rich text, not a single line.
You can see how that would work based on how my use case was outlined below. No matter how much text you write, the below sequence would be leveraging 3 blocks.
Edit:
Another example would be the first screenshot@mdubakov shared. The problem is one block and solution is another block for a total of 2 blocks. You can go in and add as much text or remove text and it will remain 2 blocks.
Yes, that was my understanding as well. It just seemed like an unnecessary distinction because… you can’t add any Blocks (capital B ) of text within a Rich Text without it being, er… a Block, or part of another existing block. In other words there is no “large text block”; there is the creation of a Block, or there is the adding of content to an existing Block. The distinction has literally nothing to do with the size/length of the text and is in fact quite clear: you add a block with an explicit action. It can either be long or short, but it’s always a block if you make it one.
However, I was wondering if you have considered a more granular block layout similar to what many other tools have adopted (innos.io comes to mind as one the most recent ones) where headings, text paragraphs, individual bullets, views, code blocks, etc. are all individual blocks rather than a single larger block. I know this creates a bit more visual clutter but I believe this provides the most flexibility when it comes to transclusion and block references. You often don’t know what part of the whole you may be trying to reference in the future and having individual items in a nested bulleted list available for reference.
The ability to fold indented items is also something that I really miss in comparison to other tools (particularly roam’s which seems the most mature) and can be really helpful when you are using a rich text area as a presentation/collaboration tool while sharing screens:
I am certain they have considered it. But I too would love to know more specifically why they have chosen not to go that route. I can see some advantages to the larger-blocks approach they’re taking, but I definitely agree that in the specific case of transclusion (and block references in general), more granular is better.
I would say, however, that the “folding” issue is a separate consideration. For example Fibery already supports folding of anything beneath a header, and on multiple levels, e.g. H1 can collapse anything beneath it, including H2, while H2 collapses H3 and other content below it, but not H1. That being said my ideal is for every block to have collapsible contents and children (where children of a block exist, whether in a bullet list or not). “Children” of arbitrary blocks is only possible in systems that allow arbitrary indentation of blocks though, e.g. Notion, Innos, Anytype, which Fibery does not (yet) support.
) — Add versioning (history) at the block level.
:
