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.
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.
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.
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.
Totally agree. I am more used to bullet lists because of roam but would definitely like to be able to indent and fold any type of block (e.g. pictures, embeds, views, tables … ). I actually find it very distracting (likely my OCD) that I can’t currently indent text and images in fibery, unless it is in a bulleted list!
Innos seems to also use headings hierarchy in addition to indenting to organize blocks for folding which I think would be a good thing to keep going forward.
I hope the team is able to consider these use pattern because I think with this approach, fibery would be positioned in an interesting way against the other tools in this space. It would have a very robust structured data system (one of the best already) but would also allow creation of very flexible freeform unstructured blocks of data that can be used across the system. I feel notion and coda are trying to do this but (in my opinion) don’t do any of it really well. I would rather wait for a more complete block implementation than have to live with an implementation that has limitations baked in.
I think fibery’s investment on the unstructured data side would make a very powerful tool for companies & organizations in terms of knowledge retention. If the team is able to use the same system to track structured data (that you need for business processes) as well as keep their unstructured notes/thoughts/ideas with rich linkages and integration, then you are going to be losing a lot less when someone eventually moves on. We try to use forms, wikis, reports to consolidate information, but I know from experience that some really great things never make it into these official documents but live in people’s notebooks, emails and journals. However, even when you are able to retain email archives, receive someone’s old notebooks or even digital journals, you are unlikely to be able to find what you need. But with a tightly integrated system, you are better positioned to discover this information.
In general I agree with all this, and I hope someone from the team will elaborate soon and I’ll stop speculating. But in the meantime I can imagine that perhaps the level of functionality they have planned for these “meta blocks” is demanding (from a resource/performance perspective at the least), and that this approach (larger blocks) seemed like the best leverage point. I.e. the best place to devote their dev time for maximum impact for the most users. Fine-grained block functions are great, but are they necessary to, as the Fibery team puts it, “generate insight”? I dunno. I suppose that’s exactly what they’re exploring.
It also seems reasonable to consider that adding smaller block capabilities over time may be easier than trying to create a Notion-level block editor up front, or at least adding such functions may be an option later. So we may well get there eventually.
As an idea for what that road might look like, I can imagine that eventually these “uber block” functions (react, per-block history, etc.) might perhaps become something you can add to any block, so as to avoid all blocks being “heavy” with functionality and unnecessary data. Maybe in addition (or instead), a Group Blocks function would be added, and Groups would have these “meta” capabilities.
Anyway, it’s interesting to think about how things might work, but some clarity from Michael or others on the team is probably more valuable.
It was a deliberate decision to not move into low-level blocks. We have a feeling that it will not bring enough benefits, but will take much more time to implement. We are strive for semantics block more, but you can create quite small blocks as well, nothing prevents it (however, there are no levels (yet)).
I don’t know how well this approach will work in fact, we’ll release something and see how it goes. We’re trying to solve many problems here, most of them caused by our customers feedback, like mix Views and Text, create Dashboards, better commenting and references.
To solve granularity problem, we will make block split easy, so if you discover than some part of a text is a separate thought, you select it and create a new block with a shortcut or a single click.