Firstly, some context.
I’ve been a power-user of Logseq (if there is such a thing) for a while now and I cannot conceive of a world where I would have to “live” without it (or without something computationally equivalent).
It is a daily, almost hourly dependency and, yet, I feel I have barely scratch the surface of what I can do with it and/or of what I can get back from it.
However, maybe because of this intensive use, some things started creeping up, little by little, to a point that I cannot ignore them anymore and thus, need to be addressed.
Don’t get me wrong, if thoroughly pressed to say 10 random things about Logseq, 9 will be in the Positives column, against only 1 on the other, less agreeably, side.
In the spirit of trying to make it 10 out of 10, for my sake, but not only, I feel obliged (in a way) to present my case(s) of how and why Logseq could/should evolve. Some things are structural and, seemingly, by design and those I have to respect, even if in strong disagreement.
That leaves the others, the ones that I feel are not set in stone and that could benefit from feedback based in continuous – and heavy – use.
I’ll start with the first (the others, which’ll deem not less important, will be addressed, hopefully, in future posts) combines 2 problems and solve them both, in one fell swoop.
They initially, and for a while, appeared to me as two, discrete, entities until the day their convergence became so obvious that the solution quickly ensued.
I’m talking about:
Logseq doesn’t have an anchor link functionality (presently and to my knowledge). This is understandable because Logseq is not a mature product, yet.
But since the (Logseq) UI is HTML, implementing it should not be a stretch. This would/could/should be (very very) useful to jump freely around a page (especially in those pages that continue below the fold – and I have quite a few of those).
Also, in one of my use cases, I sometimes have an index-type page, where I explicitly link many related pages and/or blocks, alphabetically sorted and grouped by first letter. The ability to jump to any letter is really a must in those.
Right now, in Logseq, left-clicking in the block dot and left-clicking on a block reference elicits the same behavior: that same block is presented, alone, replacing the current view. This never made sense to me. Since day 1.
I tried (hard) to accommodate to this but my brain doesn’t want to hear about it… What do I (it) expects to happen, in each case? Well clicking the block dot seems a natural mapping: like you are singling out the entire block. So, no problem there.
The problem is when I left-click a (any) block reference I (it) expect to actually jump to the location of that block. This (expected) behavior seems so obvious to me that I (still) get genuinely surprised when I go into the zoomed, isolated block (instead of “physically” jumping to that block).
Coincidentally enough, want I expect here already happens somewhere else. To see this please try searching for something that will bring a block (denoted with a B) as a result. Now, if you click on it, you’ll directly go to that block, or better, to the position of that block, inside its parent page.
This is what should also happen when clicking a block reference. Exactly the same behavior. No lost context, no lost positional/relative sense (the place of a block and what is around it is also valuable information, otherwise lost with the current functionality).
And, the zooming/isolation of a block would still available – from the original block. To go to block zoom/isolation from a block reference would cost an extra click (which is a small price to pay for a much needed functionality). Even if most people prefers the current way I dare to venture that there are enough people that would like it to change – and so this could be a settings switch, allowing each user to choose his/hers desired behavior.
Better still. If you carefully see, the solution I presented for the 2nd problem also solves the first one!
For me this is all about consistency/congruency (thusly unburdening the brain from having to differentiate between these behaviors). In that same spirit I’ll share how I (usually) link pages and blocks.
Linking Page (the normal way):
[[Fancy Page Name]]
Alternative (using an alias):
[Fancy Page Alias]([[Fancy Page Name]])
which renders as
[[Fancy Page Alias]]
Linking Block (my normal way):
[((Fancy Block Alias))](((621e464a-8170-4b07-8f91-7fccf76225a4)))
which renders as
((Fancy Block Alias))
This results in much more clear links – even if I sometimes use the normal block link (in some cases):
((621e464a-8170-4b07-8f91-7fccf76225a4))
Thank you kindly.
PS:
After writing this I’ve found the following, related, post:
I still decided to keep mine because I feel it makes a stronger and more comprehensive case for change and its implications.