Replies: 5 comments 11 replies
-
|
Consolidate this with the sidebar tree configuration proposed in #64. See comment: #64 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
I found this thread trying to track down what happened to the z-index in emanote. I definitely agree that neuron's z-index would not scale indefinitely, and that collapsible views could be part of the solution. Thinking a little more aspirationally, maybe this is the opportunity to drop the tree view altogether and figure out some kind of graph visualization since back-links can form non-tree structures. We'd probably incur a frontend dependency to render the graph, but it gives way to a natural collapsing heuristic: hiding/ grouping nodes sharing parents of high out-degree. |
Beta Was this translation helpful? Give feedback.
-
Yes, this is in my mind. Requires #84 first though ... |
Beta Was this translation helpful? Give feedback.
-
|
Glad to see you're already tracking this. Thanks for the link 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I should clarify that the indexed view in its current form -- a static structure of links: be it neuron's folgezettel heterarchy dump, or a collapsible version being proposed here, or the full directory index of emanote in its current form -- is still useful, and should be retained. Dynamic graph view can be provided in addition to it. Only when the graph views satisfies all the use cases of indexed view may the latter be deprecated (otherwise, both should be kept). I think any work on graph view would be in a very early research and exploration phase (I'm pretty new to visualization myself), so I don't know how it will turn out yet. The index view should be a good thing to have in the interim. I do know that I'm not a big fan of Obsidian's graph view, and as @j-steinbach notes below it is not a great index view (just that it looks pretty) ... but perhaps there is a way we can improve on that in an interactive fashion including #147 based interaction so as to provide a way to iteratively 'filter' the graph in real-time based on one's (changing) query view of what notes need to be displayed. All of this sounds like an independent project of its own, and maybe it should be explored in a separate repo first (will require #161). |
Beta Was this translation helpful? Give feedback.
-
|
I believe the big question is: What exactly do we mean by index? Is it to display all notes? To display the important notes? To show an overview over collapsed categories? Also: What is its purpose? Look pretty? Provide a sense of pride and accomplishment by showing how big our notes folder is? Be useful? Let the user look up their notes-folder from the browser? [Side-note: Our index is called "Impulse" -- "Full folgezettel heterarchy of the zettelkasten". What does that mean? Also we got a index.html page, which is user curated.] If we assume our index to be intended as a listing of all notes, then we have the following problem: Our notes folder has no structure. We can't assume structure, and we mustn't enforce structure. It is just a loose pile of notes, spread over a few (possibly none) folders. For example my Zettelkasten (ZK) consists of five folders:
So how do we structure this?
This means that a graph probably is the safest way to visualize the notes. But is a graph an index? In my opinion a graph is a visualization, which --whilst pretty and awesome-- doesn't have much "index" value:
The picture shows a cut-out of my Zettelkasten graph. The real one is 4x bigger and also contains notes without parents and links. I find it hard to identify small notes. The problem with graphs is that they change. In my opionion, an index should show me the most important parents/categories on a single glance, without changing every second day or requiring me to zoom around. This does not mean that I am against graphs. Au contraire!, we definitely need a graph-based visualization. I just think that graphs and indices are different things. |
Beta Was this translation helpful? Give feedback.
-
|
Your mockup reminds me of two things in particular:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is exactly what I meant. Simple to explore, high information-density and an elegant way to handle duplicate entries. (Well, the Federated Wiki Title Network Browser however is a bit too dense on information for my tastes 😄 ) |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to ask whether by now there are any plans to incorporate indexed views á la neuron (or similar, some of the above proposals seem very promising as well) into emanote? Right now, this is the main reason that's holding me back from switching to emanote. Anyway, thank you for your work, @srid ! 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
@dpaetzel No plans so far, but I'm happy to guide others if they want to implement any of it. I can imagine two parts: adding extra route types (if necessary) and adding a 'render' function - which is a pure function taking 'Model' and returning HTML, effectively. Like, for tag index, we have:
|
Beta Was this translation helpful? Give feedback.
-
|
OK, thanks for pointing us in the general direction. When I find the time (though I'm not sure when that may be), I might give it a go. |
Beta Was this translation helpful? Give feedback.
-
|
Note that Emanote now has JSON export; so these views can experimented with offline outside of Emanote before being upstreamed. |
Beta Was this translation helpful? Give feedback.
-
|
I'm beginning to brainstorm over this. If anybody is interested, join the discussion over at Zulip. |
Beta Was this translation helpful? Give feedback.
-
Neuron's index is just a tree of links to all notes. This works on small sized notebooks, but can become intractable on really large ones (and can affect performance adversely; see #66).
One solution to this problem is to auto-collapse sub-trees known to have relatively large number of descendants, and delegate their listing to a dedicated child (or sub) index route. For instance, daily notes stored in "Calendar/" folder could have as much as 300 notes in a year, and if you are using the Zettelkasten for 5 years, that number reaches 1500. It makes no sense to list all daily notes in the index view. We could just automatically collapse the Calendar/ sub-tree in the main index, and then introduce the notion of "sub index" views.
If the index view has the route
/-/index(which is what #49 implements), then any sub-index view for path P will have the route/-/index/$P. For the above Calendar/ folder, the sub-index view will be at/-/index/Calendar. And for nested sub-index views, such as say a specific month of a year, it will be at/-/index/Calendar/2020/07.We can in fact generalize this "indexed" route-tree concept and apply it to hierarchical tags too. So a note tagged with
foo/bar/quxwill be listed in the/-/tags/foo/bar/quxtag index route, with "qux" itself listed in/-/tags/foo/bar(view demo) and so on.Beta Was this translation helpful? Give feedback.
All reactions