The option to show block references on the graphview

To have more comprehensive view of connections between deferent part of the document.

yes, literally local graph for blocks.

1 Like

and I think it will be efficient will zoom in option to the blocks.

Since the fundamental unit of logseq is blocks it makes sense to show block connections in graph rather than pages. I have very few pages with nested blocks and sub blocks which which link together to form a huge web. But sadly if you look at the graph view it is just a few nodes barely any connections

The reason I use blocks instead of pages is that blocks allow to me create hierarchy easily with sub blocks and also to create new connections with block ref. Whereas it is harder to create heirarchy with pages

What do you guys think?

Absolutely agree, a block based graph would be perfect and makes so much more sense for Logseq rather than just pages.

I totally agree, I also think blocks should be better supported in some cases. It’s a lot more natural to link blocks to each other than pages.

i like it.

And the block has block title (ref: term/block title ), I think it’s better to search block title when use (()).

I just use block as content card and pages as topic tags.

1 Like

For me,the main value of logseq is the concept of block (at the most primitive level an irreducible complete thought).

The graph and the other part of logseq must emphasis the powerful idea of atomic levels and its neurological connections.

I believe logseq has a great opportunity to be a leader in the ‘block’,‘sentence’,‘bullet’,‘node’,‘thought’ manipulation.

We are intoxicated with the ‘cut and paste’ style,which only make us puppets and accumulators of notes,and the false feeling that directories,folders,files can make us more knowledgeable.

The conclusion is easy, the priority of logseq must be the block,and all the thinking about how to improve it ,must be around the atomic concept, without that in focus,it will be lost in the forest of many apps that doesn’t have a distinctive competitive advantage.

2 Likes

Wouldn’t this require every block to have a title though? That would create a lot of ‘friction’ when creating a block.

I love the original poster’s idea, but I would be worried about the point @OrangeBoy brought up. Perhaps relying on the nearest parental headings in a page as the ‘title’ for a given block might work?

…Or better yet, maybe some type of dynamic level of title, relative to the ‘depth’ of the page/heading/block? Wow, hard to wrap one’s brain around, could see it descending into chaos potentially pretty quick…but would be incredibly powerful if there was a way to make it work.

Since the initial question block references have been expanded and you can already see the number of links (9,5,2, etc), and inline see what those links are.

Combined with folding it is now fairly easy to see how many and what links exist. Imho having this graphically adds very little, what use-case would it serve?

Well, suppose Page A contains Block α and Page B refers α somewhere. It’s obviously there is a kind of relationship between A and B, which current graph fails to display.

I don’t mean to turn page-based graph to block-based graph, instead, I think that if Page B refers Page A’s blocks, then there ought to be a line between Page A and B in the graph.

1 Like

Totally agreed. For me as a new user it was quite confusing that after adding a lot of block references, my graph did barely show any connections.
And using a new page instead of a new block only to create a page reference that is shown in the graph does not seem like a good alternative to me.

Maybe we could have a switch for that as well, so you can turn on and off different kinds of nodes and also different kinds of connections/references.

1 Like