More informative clustering of in the graph view

I would assume most are interested in seeing which nodes are connected to each other — to identify clusters of notes that are your potential blogposts, articles, etc. Right now the graph view does not really allow you to see any clusters or trails. It would be great to change the graph view mode in such a way that connected nodes attract each other, while disconnected repel each other.

2 Likes

I think it already tries to do this, but it is just really hard to achieve in two-dimensional space.

I often see a notes in the middle of a cluster that has no connections to that cluster. Why? Because it is connected to other notes on either side of the cluster. Which are in turn positioned to optimise proximity to their own connections.

I guess you could take that errant note, in the middle of an unrelated cluster, and push it far enough in any direction until it leaves that cluster. But then it will likely end up in another unrelated cluster, or else have absurdly long connections back to the notes that are putting it in the ‘wrong’ place.

It is a tough one! I have been thinking about it too, as I agree it is not ideal. But short of a higher dimensional (eg 3D) graph, I don’t know how it could be done.

@tobyp you can do it in a 2D way, but it is really hard. The only good implementation I’ve seen of it is the work done by Quid, who specialize in text-based data analysis. Maybe someday there will be a plugin!

Visual clustering is one of the basic features of graph visualizations. I do not know what are the Obsidian’s limitations, but something like what I describe can be done with D3. Here is an example: https://codepen.io/smlo/pen/JdMOej

Here is another example: https://observablehq.com/@d3/force-directed-graph. And there are plenty others.

1 Like

It is interesting to think about.

For scenarios where someone prefers order over efficiency, there could be a slider to control layout between the two.

On one extreme, it could all but disallow overlapping connections by any means necessary, no matter how funky the layout.

On the other extreme, it could tightly pack connections, while allowing tangles galore.

The kicker would be to have custom tools for cleanup where on a node by node basis you could change this order/efficiency value.

I also imagine there could be countless additional tools to be had. I may be missing the point, and don’t want to imply I don’t love it as is.

We are talking perfect world.

I think that basic clustering as in the examples that I provided will be a good start — and probably quite sufficient. It is always easier and faster to develop that core functionality (the 20/80 rule) than to finish all the bells and whistles.