I understand the desire for further simplification, but Logseq’s current approach has its own advantages.
I use pages as the equivalent of folder-tags, that is, the …
… for each and every block.
New content is always added as blocks in the most relevant page, and then referenced elsewhere. This creates a node-edge system, where pages are the nodes and their content the edges, which works exceptionally well (that is, better than everything else I’ve tried) for me. The viability of this node-edge system relies on clear distinction between pages and blocks.
Links to pages are actually quite common in my workflow. An example:
[[Pineapple]] is a [tropical]([[the tropics]]) [[fruit]].
This block resides in the page (node) pineapple. As an edge, the block connects the nodespineapple, the tropics and fruit. Retrieval of this block is possible through any one of the three nodes.
The name of each node is a noun/object. Edges denote connections among multiple nodes. This creates a web, not a tree. Whether this method of note-taking makes sense depends on your purpose.
Of course there are ways to specify, and differentiate between, different types of blocks. But why waste time and energy on this when we already have a nice, intuitive implementation?
And as @alex0 has pointed out, an all-block implementation could result in issues with, or confusion about, inheritance. With pages as distinct entities from blocks, inheritance is clear-cut and intuitive.
All-blocks might be better than pages-and-blocks for you. For some others it’s worse.
Yes, the block-only approach can perfectly emulate any other system (since it doesn’t dictate any overarching structure or logic).
In order to accommodate this alternative workflow I talk about, which I see as much more flexible and natural (not to mention it’s the most natural choice for a db-based app, which logseq will soon become).
Between two systems, one that favours a certain approach, and another that allows implementing any approach, I’ll always prefer the latter.
Note that, in theory I can emulate my desired block-only workflow within logseq’s current page/block logic, simply by using a single page for my entire graph. I never did it because I assume this would lead to performance issues, considering all of that would live in a single .md file.
Clicking on the tag #book simply opens up that block, which you can use for whatever you want, such as describing what a book is. And at the bottom of that block (when zoomed into it), you also see all references to it.
(The system is much more versatile than that. You can tag any block with any other block if you want.)
Just use {{embed [[page]]}} in a page to embed all the other page and then use this CSS to make them look like blocks and collapse them just like blocks:
You are saying that it can be implemented, and others are explaining why it should not be. For obvious reasons, that one can do something does not mean they should do that.
the structure: block - tag - page, can offer layers of information, some small word can stay in a block, some big words can grow into a page, thus can build up something bigger, something normal, like a single building vs a community.
and a community offers the convenience of biggness … the similar blocks can stay together easily.
and also in concern of connectivity of blocks, if we say all blocks in journal pages to be tagged, those blocks in a page will not have to all tagged, as they are under the same roof ( tag, page), they enjoy a sense of connectivity by default, and some of them are free of tags, this is also mind of efficiency of tags.
if every thing flattened into blocks, at the same level, then all of them have to be tagged, and sometimes, a cluster of blocks have to share the same tags, if conjure them together into a bigger block, then the block is another form of page (in the shape of block), and might it be messy as well.
That’s a good reasoning, @baiwj . But, as @BBob will say again and again, the same thing could be done with blocks-only. Is as easy as create yourself that special blocks (the communities) using uppercase letters, for example. Or an emoji at the start of the block.
The initial proposal of this topic is asking for simplicity and freedom.
The actual structure (pages-blocks) is fine. But the all-blocks in a DB version is even better because is more flexible. And it’s proved again and again by succesful outliners like Workflowy or Tana.
None of them use references to tag blocks and their children, right? To my knowledge only Roam Research and Logseq do and they both have the concept of pages.
Anyway, wouldn’t it be better if we had the following option to treat specific blocks as pages?
