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.
3 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.
2 Likes
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.
2 Likes
I will add my +1 to this. The idea of blocks as fundamental unit of logseq is nobrainer. And as soon as we already making backlinks inside blocks, it makes total sense to use it with a graphview.
This is the way I start using logseq and I thought this is expected behaviour, until find out it’s not and googling for a workround bring me here.
I even use ‘Atomatic linker’ plugin to build these relationships between pages.
So if some block have backlinks to A, B and С — all these pages should be connected at graph view.
Dear developers, please help to bring this to life!
2 Likes
And the graph view as an optional template for a query output format.
1 Like
Can you elaborate on that? Is there a way to edit some kind of file in logseq to change the visualisations as described above?
I think not, unless it is directly editing the source code. My comment was probably out of place. I was imagining a graph visualization as the output of a query, as an option that would exist in the aqueries, choosing the visualization as an output format template.
1 Like
I think eventually we’ll need to integrate the search with the graph view. Searching, filtering, and visualization should be decoupled, so that a text search could be re-used to display the results as a graph.
This would let the user pick what to show, maybe we want to show all block references, only certain references, use different colors etc.
Not my area, but there has been a lot of work on graph search and visualization, e.g. here: https://towardsdatascience.com/building-a-graph-data-pipeline-with-zeppelin-spark-and-neo4j-8b6b83f4fb70)
We could even have a graph view like this to explore hierarchies:
1 Like
This happens to align very closely with Ted Nelson’s early Xanadu vision of how hypertext should work.
1 Like