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.
Looking at other tools for inspiration is a good idea. For ex. I like how Coda handles this. Just a small feedback by seeing the gif, probably all those little buttons for blocks should be hidden until users hover over them, otherwise the document will look too heavy, kinda like Coda does.
I definitely agree it seems like a good place to start. I’m curious if you have looked into or considered making each larger chunk of content at least feel more granular. One of the nice things about roam, for example, is just the ability to nest and collapse at any level. I think you could have a reasonable balance if anytime you use a nested bulleted list, you could collapse it at any level.
For example, you have a complete block that is Solution and you could collapse or expand the whole thing as-is. However, imagine you added more nested bullets under “(App/Folder…” and “Type is the …” bullets, but only wanted to show it by default how you have it displayed. You could rework it to add more headings, which could support collapsing more within the Solution block, but that is a lot of rework. I think if the rich text block supported converting or treating bulleted lists like Coda’s collapsible lists, it would help a lot in reducing visible noise.