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.
I’m in favor of as much collapse capability as possible. I would definitely like to see this added to lists, but also indent added to checkbox type, and collapse there as well.
I was wondering if there would be a way of inserting blocks through markdown templates? I am particularly interested in view blocks and the ability to specify some presets (database, columns, filters, sorting) and passing certain parameters at creation time. I see this being very useful for inserting custom views into newly created entities.
I totally understand this explanation and design decision and know this is a massive task with multiple goals.
However, I do still wonder how you are planning to address the issue of block references and transclusion. I think this is the major advantage of every paragraph/heading/bullet/image/etc. is a block approach that roam/innos/other tools use, where you are able to arbitrarily and any point in the future reference a deeply nested set of text or lists without having to first break it up:
I also don’t understand how the proposed breaking up would actually work and what the ramifications are. For example, how do you break out a subset of items in the third layer of a bulleted list without all the bullets getting indented back. It also seems like a lot of effort to just be able to reference those few bullets in another piece of text. From a UI perspective, I am afraid that this would also be quite ugly as there would be texts and lists broken up in all sorts of ways. I am also afraid of what this break-up process does to existing links.
I believe transclusion and block references should be one of the important outcome of this massive effort around blocks. Even if you can’t do it right now, I think it is important to have the foundation to achieve it in the future.
I agree that there are some big unknown questions here.
Personally for now I am less concerned about having low-level blocks, but I’d love to be able to “quote”/reference specific sections of text really easily, like we can here in Discourse. I’ve said it before, but I think it is questionable whether it’s better to have a system that always operates on referencing of whole blocks, vs. one where you can simply select what you want to reference (with e.g. drag-select of text). Related previous discussions:
While transclusion is a pretty generic mechanism, we’d like to focus on a few specific scenarios (at least, for now). Here are a couple of examples:
Writing explorable docs for curious readers
Connecting customer feedback to work
In most of these cases, the transcluded Blocks are large and uninterrupted. Unlike Roam’s, our editor doesn’t lean towards hierarchical structures — thus, we don’t feel the pressure to support deep transclusions right from the start.
Anyway, this is more of a theory at the moment — we’ll see how it goes in the private alpha/beta.
Real example of blocks usage (with real data) in a Strategic Initiative entity.
It has some specs, List of Features, Roadmap and Board with marketing tasks.
UI is very rough, we will polish everything in January and add comments threads here as well.
This is looking really cool. I’d love to see an “Embed Iframe” type block. A really big gap at the moment is the ability to embed something like a Figma design in Fibery.
Yes, I second some attention being paid to “embeds”. Lots of other tools get a lot of “shallow” but still quite valuable “integration” out of this approach, even to the point of being able to iFrame editable Google Sheets docs into pages, etc. I commonly see Miro and Figma also in this context.
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. 
