I often find myself looking for a particular node on the graph. I wish there was an option to filter the graph as you type. Filtering could use the foreground/background graph display mode: the filtered nodes are displayed in the foreground, and the rest of the nodes are displayed faded in the background.
There could be an additional search field specifically for finding nodes on the graph.
From what I read here, it sounds like many of us would like the graph view to become a configurable map rather than just a graph. With a map, all these aspects can be assigned a meaning and so would be presented consistently each time the map is viewed.
Location in X and Y direction based on distance from some concept or tag.
Color of the nodes.
Size and shape of the nodes.
Those all sound like what we expect to find when looking at a map.
Map View – Fixed view, like a constellation in the sky. This creates a sense of familiarity because the “skymarks” have a fixed possition.
Random View – This is useful because every time you open the graph you see different juxtapositions, hence possible connections you can make between nodes.
Node-Centered View – You could designate a node as the center of the graph, so all other nodes would be displayed in relation to it. There would be two structures, one within the other: nodes connected with the central node (directly or indirectly) form the inner structure; nodes not connected with the inner node form the outer structure.
All of them could be useful / fun to use. And there could be others I haven’t thought of.
By that, I mean operations that select nodes on the graph, where the selected nodes are displayed in the foreground, and the rest of the graph is faded in the background.
Random node selection is an example of one such operation. But there are others as well.
For instance, let’s say you want to select on the graph all nodes with a particular tag. Imagine if you could do this from the tag pane. With an option activated, clicking on a tag in the tag pane would select on the graph all nodes with that tag.
I’d suggested a while ago a minimap option for the graph:
What if the minimap view appeared in the local graph area when viewing the big graph?
So you’d see the big graph, and in the right sidebar, you’d see the minimap: a representation of the big graph faded in the background, and only the nodes visible on-screen on the big graph displayed in the foreground within a rectangle proportional to the screen. If you zoomed in/out the big graph, the size of the rectangle would decrease/increase on the minimap.
Subtraction Filtering – When you search for something on the graph, the graph is filtered to show only the nodes that meet the search criteria. This is the default.
Selection Filtering – The nodes that meet the search criteria are displayed in the foreground while the rest of the graph is faded in the background. It’s beautiful to be able to see the graph in the background, as context.
There could be an option to use both at the same time: you could make the visible graph smaller with subtraction filtering, and bring a set of nodes to the foreground with selection filtering.
Foreground/Background Mode: Some notes are visible in the foreground, and the rest of the graph is faded in the background – visually similar to the current action of hovering the cursor over a graph node.
I’d love such a mode of visualizing the graph. I’ve been thinking of possible ways to implement it. Here’s one:
There are two search fields:
filtering search – filters the graph (the current search field)
fading search – fades the graph; when you search for something, those nodes are visible in the foreground, and the rest of the nodes are faded.
The two searches would work in tandem. You could filter the big graph, and then fade all but a selection of nodes from the filtered graph.
I think what you’re proposing might be the solution that I was looking for: how to visualize a complex and customizable historical chronology.
I’m researching a topic in global history and the nature of my job requires that I maintain awareness over a variety of events that occur simultaneously in different parts of the world. With Obsidian I was able to find two solutions to this challenge:
Nested Tags, for example: #Year/XIX/1871; #Year/XIX/1872; #Year/XIX/1873; or #Year/XVIII/1788; #Year/XVIII/1789; #Year/XVIII/1790 and so on
Event-notes, for example: 1701_War of the Spanish Succession_1714; 1713_Peace of Utrecht_1715; 1756_Seven Years War_1763; and so on
I like this system because it allows me to have two types of chronology, one in the tag list and another in the “Event-notes” folder that is ordered by year.
Now, if I could customize the graph view as you are proposing, I would have a very interesting upgrade to my chronology. I could finally create a timeline with the year- tags placed side by side and the Event-notes connecting to them in the surroundings. Event-notes could still have a force of approximation according to links and back-links, but the most relevant force of approximation would be the chronology line connected with the tags. Your “foreground- background” proposal would also solve the problem of event notes overlapping in years that are crammed with events.
When you access the big graph, the local graph area is empty. It would be beautiful to be able to select nodes on the big graph (so without opening them) and for them to be displayed in the local graph.
There could be a global and a local filter for the local graph.
Let’s say you want a particular page to have a different filter than the default. There could be an option to add an override search field – which would appear on top of the default search field. Whenever you want to return to the default, you could close or disable the override.
By filtered links I mean links that temporarily apply a search filter to the local graph on the linked page when visiting the link.
Normal Link: [[link|name]] - Takes you to the page.
Filtered Link: [[link|name|local graph search query]] - Takes you to the page, and the local graph is temporarily filtered with the search query.
Functionally, a temporary search field could appear on top of the existing search fields. That filter would visible only on that specific instance of the page. When that instance of the page is closed, the filter would disappear with it (so the temporary filter would be active only when you open the page from the filtered link).
This means you could have two instances of the same page with different filters applied.
The idea is to be able to easily access the settings for the local graph from the global graph and vice versa.
While thinking about how to achieve this, an idea struck me. In the video game Diablo 3, when you hover over an item, you are shown how it compares to the item you have equipped, as a side-by-side window.
Something similar in flavor could work for Obsidian as well. There could be an option that opens the local graph menu from the global graph and vice versa. The two menus would be displayed side by side, something like this:
There could be an option to “synchronize” them, thus mirroring the actions from one to the other. So if you, say, open the Groups in one, you also open the Groups in the other. If you modify a setting in one, you also modify it in the other.
There could also be an option to copy all the settings of one to the other.
I’m very interested in User Experience (UX). A tool I like to use is what I call NOA (Number Of Actions) – the number of actions it takes to perform an operation. The more actions it takes, the more friction is created.
For instance, I’d like to be able to quickly change graph filters with complex queries to view the graph from multiple perspectives. Right now, it takes so many actions, so the friction is so high, that I rarely change views.
One possible solution:
Think of the legend of a map. One notable characteristic of the legend is that it’s always visible. Imagine if the legend of a map was functional, that is, if it allowed you to show or hide certain features on the map. These would be 1-action operations.
Something similar could work for the graph view. There could be a customizable legend-like section where you could add the operations you perform most often (maybe with drag-and-drop from the Graph Settings), which would allow you to perform them in 1 action.