This is a major UI change.
Inverse tree view, positioned above zettels
Drop connections panel
Retain backlinks, but dimmed
Lift container width, but only for the inverse tree view.
Refactor
i think it takes too much space but that is really cool :heart_eyes:
I personally like the first tree better (the horizontal one) because it can display more, I'm afraid that long titles can make the vertical tree representation a bit too big
what about displaying the backlink tree on the left (from right to left) and "forward links" on the right (from left to right)? I think we could make use of the blank space on both sides of the zettel, which currently takes less that half of the page horizontally
what about displaying the backlink tree on the left (from right to left)
You mean the 'uplink tree' on the left? I considered that option, but now the current uplink tree should be flipped 90 degrees. I don't know how to do that in HTML/CSS. For this PR, I simply copied the CSS from that codepen :-P
also I think displaying the tree only like 2 or 3 levels deep is enough to get an idea of the surrounding zettels
For my zettelkasten having a full-level uplink tree proved to be quite interesting for me. It is nice always have the full bird's view in context when reading a note. This is one of the reasons why I don't like the previous connections panel anymore.
On the other hand, mandatorily displaying the uplink tree in public zettelkastens, as well as those with simple structure, could be a nuisance. for example, in srid.ca or reddit.zettel.page. So I'm wondering how to solve this problem.
This UI is useful when a zettel is branched off from more than one zettel. Otherwise only a linear path is displayed, which is basically breadcrumbs. Public sites like reddit.zettel.page and haskell.zettel.page are mostly breadcrumb based.
@Nadrieril speaking of the github discussion, I will probably merge the PR with the current design. But we can always improve the UI (the left sidebar thing) later. Actually I can poke at it a bit, but no guarantees.
Note that "down" links are gone (they are in the zettel anyway). I don't find them useful. Though if we implement 'reverse' links, that would have to be displayed somewhere.
I think the problem with the public zettelkasten is that they are used as tiny wikis and not zettelkasten at all
Well, actually, my hope is that haskell.zettel.page gets some of the graph structure eventually. There already are couple of pages that have non-linear backlinks, eg: with the PR design: https://www.srid.ca/tmp/2012406.html
My idea of reverse and sibling links came from a desire to curate the tree view. But the more I think about it the more I think the tree view encourages categories too much. So I'm not so sure they'd be a good idea anymore.
The problem I think is with the word 'category'. Let's use 'theme' instead, for example. I want to change the terminology in this part. "Branching off" is another descriptor to use.
So, in a zettelkasten - you start with individual notes, and over time certain themes emerge. The tree view captures these emergences (graph view would be too open-ended to capture them)
Right, but hierarchies (a hierarchy of themes, for example) is not a problem in themselves; they only become a problem when you pre-define (instead of letting them evolve bottom-up).
It is very useful to have these theme-notes, because they come in handy when you want to think of where to link this new note. Instead of searching all throughout your zettelkasten, you begin search from the theme notes.
Actually I'm not sure I agree with that. What definitely emerges is unsuspected connections. But can themes actually occur that way? I'd be interested in a more concrete example if you have one
In any case we want to make it easy to find relevant notes both from the whole tree view and relative to a given note. Detecting clusters is useful for that, and so is the up-links view
The screenshot I posted in the PR is one example. The "throwing in the towel" psychological behaviour is a part of multiple themes: one is just a project (in which it occured), another is the mindset concept in psychology, and another is a life-pattern I identified (which itself is part of an even larger theme to do with identity)
The themes emerged after the initial few zettels were defined (you don't see these zettels in the screenshot); and when I created the "Throwing in the towel" I was able to go through the zettelkasten and link it to existing themes.
Mindset zettel just describes what I mean by "mindset", and it links to types of mindset (Growth mindset, learning mindset), as well as to specific cases (eg: throwing in the towel) illustrating the same.
There is 'Ikigai' which came in much latter. And there used to be a 'Habit' zettel as well, under Ikigai, but I had to replace it with 'Mindset' (since habits are generally forced, with mindset being more identity-based). All these theme-zettels formed on the basis of the individual journal-zettels which described the day-to-day events in my life.
The 'Ikigai Vortex is dissociation' zettel (higher up) was actually created yesterday, as a result of an insight into the insufficiency of another zettel called 'Ikigai Vortex' (a branch of 'Ikigai'). Being able to look at all this, when looking at the 'throwing in the towel' is what I found to be quite useful; to get a bird's eye view of the whole map.
Yup, and I think it doesn't hurt to have them - as long as the zettel content is visually highlighted more than the context around it (which is why they are in grey background). I wonder why you don't like it. In my zettelkasten, the depth is usually limited (this screenshot showing depth of 6), so I've never had to think about limiting the height of the tree ...
Git pull, then import new references from a RSS feed I'm producing, then git push ^^ That way if I'm reading a thing it's already in a reference zettel so I can link to it from handwritten notes
Interesting tree view, if we were to merge Up / Down into one horizontal tree:
https://codepen.io/igaurav/pen/mMqyoY
https://igauravsehrawat.com/draw-a-horizontal-tree-using-css-pseduo-elements
https://codepen.io/philippkuehn/pen/QbrOaN
Prototyping that last design. It actually looks better. Should call it "backlink tree"
And I think I'll get rid of the "Down" links (they exist in the zettel, in a structured fashion, anyway)
https://github.com/srid/neuron/pull/195
This is a major change, so I suggest folks to give it a try and give feedback.
i think it takes too much space but that is really cool :heart_eyes:
I personally like the first tree better (the horizontal one) because it can display more, I'm afraid that long titles can make the vertical tree representation a bit too big
what about displaying the backlink tree on the left (from right to left) and "forward links" on the right (from left to right)? I think we could make use of the blank space on both sides of the zettel, which currently takes less that half of the page horizontally
also I think displaying the tree only like 2 or 3 levels deep is enough to get an idea of the surrounding zettels
You mean the 'uplink tree' on the left? I considered that option, but now the current uplink tree should be flipped 90 degrees. I don't know how to do that in HTML/CSS. For this PR, I simply copied the CSS from that codepen :-P
Oh, and it should also work on mobile (probably by going to the top/bottom automatically on small screen)
For my zettelkasten having a full-level uplink tree proved to be quite interesting for me. It is nice always have the full bird's view in context when reading a note. This is one of the reasons why I don't like the previous connections panel anymore.
On the other hand, mandatorily displaying the uplink tree in public zettelkastens, as well as those with simple structure, could be a nuisance. for example, in srid.ca or reddit.zettel.page. So I'm wondering how to solve this problem.
This UI is useful when a zettel is branched off from more than one zettel. Otherwise only a linear path is displayed, which is basically breadcrumbs. Public sites like reddit.zettel.page and haskell.zettel.page are mostly breadcrumb based.
Posted a screenshot in the PR
One idea about the 'crowded top' in public sites, is to use JavaScript to automatically scroll the title of the zettel.
I think the problem with the public zettelkasten is that they are used as tiny wikis and not zettelkasten at all
A zettelkasten should be densely linked
So I think the tree view would generally be useful in zettelkasten
@Nadrieril speaking of the github discussion, I will probably merge the PR with the current design. But we can always improve the UI (the left sidebar thing) later. Actually I can poke at it a bit, but no guarantees.
Note that "down" links are gone (they are in the zettel anyway). I don't find them useful. Though if we implement 'reverse' links, that would have to be displayed somewhere.
There is https://codepen.io/igaurav/pen/mMqyoY - but as you can see it stretches too far horizontally.
Well, actually, my hope is that haskell.zettel.page gets some of the graph structure eventually. There already are couple of pages that have non-linear backlinks, eg: with the PR design: https://www.srid.ca/tmp/2012406.html
My idea of reverse and sibling links came from a desire to curate the tree view. But the more I think about it the more I think the tree view encourages categories too much. So I'm not so sure they'd be a good idea anymore.
The problem I think is with the word 'category'. Let's use 'theme' instead, for example. I want to change the terminology in this part. "Branching off" is another descriptor to use.
What I mean is that the tree view might encourage hierarchies
So, in a zettelkasten - you start with individual notes, and over time certain themes emerge. The tree view captures these emergences (graph view would be too open-ended to capture them)
Right, but hierarchies (a hierarchy of themes, for example) is not a problem in themselves; they only become a problem when you pre-define (instead of letting them evolve bottom-up).
It is very useful to have these theme-notes, because they come in handy when you want to think of where to link this new note. Instead of searching all throughout your zettelkasten, you begin search from the theme notes.
Ok, I do agree with that
Actually I'm not sure I agree with that. What definitely emerges is unsuspected connections. But can themes actually occur that way? I'd be interested in a more concrete example if you have one
In any case we want to make it easy to find relevant notes both from the whole tree view and relative to a given note. Detecting clusters is useful for that, and so is the up-links view
The screenshot I posted in the PR is one example. The "throwing in the towel" psychological behaviour is a part of multiple themes: one is just a project (in which it occured), another is the mindset concept in psychology, and another is a life-pattern I identified (which itself is part of an even larger theme to do with identity)
This is not emergent though: you defined the themes and linked from them to the displayed zettel
The themes emerged after the initial few zettels were defined (you don't see these zettels in the screenshot); and when I created the "Throwing in the towel" I was able to go through the zettelkasten and link it to existing themes.
I see. So for example "Mindset" is an index-zettel for the theme?
Mindset zettel just describes what I mean by "mindset", and it links to types of mindset (Growth mindset, learning mindset), as well as to specific cases (eg: throwing in the towel) illustrating the same.
Ok
Thanks for the illustration
There is 'Ikigai' which came in much latter. And there used to be a 'Habit' zettel as well, under Ikigai, but I had to replace it with 'Mindset' (since habits are generally forced, with mindset being more identity-based). All these theme-zettels formed on the basis of the individual journal-zettels which described the day-to-day events in my life.
The 'Ikigai Vortex is dissociation' zettel (higher up) was actually created yesterday, as a result of an insight into the insufficiency of another zettel called 'Ikigai Vortex' (a branch of 'Ikigai'). Being able to look at all this, when looking at the 'throwing in the towel' is what I found to be quite useful; to get a bird's eye view of the whole map.
100% agree that we want to give easy access to the context of a given zettel
Do you think having more than 1 or two levels of backlinks is useful?
Yup, and I think it doesn't hurt to have them - as long as the zettel content is visually highlighted more than the context around it (which is why they are in grey background). I wonder why you don't like it. In my zettelkasten, the depth is usually limited (this screenshot showing depth of 6), so I've never had to think about limiting the height of the tree ...
And if the connection is not with a branching zettel, then you would use
?cfwhich then appears in a list below (the 'More backlinks')I'm not very opposed to anything tbh. I'm mostly trying to think through what would make the most sense
That's great. I'm leaving the PR open for that reason mostly; to see what ideas others have.
Reading through https://notes.andymatuschak.org/z6f6xgGG4NKjkA5NA1kDd46whJh2Gt5rAmfX has given me a really good example of what "densely-linked", "atomic" and "concept-oriented" could mean, so I'm trying to rethink my usage of zettelkasten in that light
Sridhar Ratnakumar said:
Btw, I never understood what "cf" stood for here
https://en.wikipedia.org/w/index.php?title=Cf.&oldid=944527064 (its something I hastily chose to describe a link that that is non-branching; not sure if it is the best term)
Huh, ok
I just pulled master and I like what you did with the backlink graph! It's actually not very obtrusive in practise and convenient
Great! You might want to install https://github.com/srid/neuron/commit/50f0eb9973f9921509c76654d727e45b5dc6b271 as well, as it would include all kinds of errors in z-index.
The current errors are really convenient too! I have neuron on a server and in the background locally, and I never need to look at its output anymore
How do you keep it up to date on the server? Do you do
git pullin a loop?Yep
Git pull, then import new references from a RSS feed I'm producing, then git push ^^ That way if I'm reading a thing it's already in a reference zettel so I can link to it from handwritten notes
I set this up today, I'll see if I find it useful