acorn
acorn copied to clipboard
lightningrodlabs
Arrow navigation should remember where you came from
In most modern text editors, when you use arrow keys to move, say, from the end of a longer line down to a shorter line, and then back up to the longer line, the cursor goes back to where you were when you first moved down; it doesn't move you directly above the end of the shorter line.
This is a more ergonomic experience that I think most people are used to, and the same applies to the tree: if you move from a child to the parent, when you move back down again, you should return to the same child you came from, not the leftmost child. This should apply to entire chains, so that I can traverse the tree from bottom to top and back to the bottom, returning to the leaf I originally started from, all by pressing up up up up up down down down down.
This should also apply in the opposite direction once multiple parents are implemented.
@kbonnici this would be an eventual 'advanced' version of the keyboard navigation
by the way @maackle we are working on bringing back keyboard navigation in the next minor release. we had to disable it temporarily when we built multiple parents
So, personal opinion: the new arrow navigation modal in 6.1.0 when encountering multiple options, is not an improvement. I would actually rather the leftmost item be selected with no modal, than to have this modal pop up.
Why? Because if the leftmost item were just selected, then I could just press Right some number of times until I get the card I want. With the modal, instead I have to press Down to get the card I want, the same number of times I would have had to press Right. The only difference is whether I'm pressing Right or Down. The modal just rotates everything 90 degrees clockwise, which seems unnecessary.
Perhaps this could be togglable in the preferences section.
Personally I do like the change but you do make a good point.
we've heard this a few times now so we'll bump up this implementation. We will target building it in as a Preference to use or not use, and have Michael's proposed option in there as one.
I'm just going to re-open, simply because the initial proposal hasn't been fulfilled yet.
new question about keyboard navigation, would you prefer: a. it navigates to the left most child first b. it navigates to the center-most (arbitrary-picking left-middle for even numbers) child, allowing you to go left or right from there.
We figure that center most would be the fastest in most cases.
I believe it should work as close as possible to how a text editor operates. It's just a matter of mapping the concept of a grid of characters on lines, to a tree of cards.
I would think that when you move to a level of the tree with multiple cards, the focus should go to the card with the smallest horizontal offset from the card you came from (which is not always the centermost, depending on layout).
Take this layout for instance. I would think going down from the highlighted card would take me to "Holochain can validate...". But left-center would be the one to the left of that. And leftmost would cause a drastic pan of my screen to take me to that far-left outlier "There is a built-in...". As close as possible to "down" is the aim.
I also still think it would be a nice touch to have some memory of the path taken when traversing up and down, just like a text editor, though it's definitely more complicated to think of how to map this into a sparse tree instead of a dense grid of characters. I think the rule would be something like "if focused on a card which is rightmost on its level, when navigating up or down to another level with multiple cards laid out right of the card I came from, override the usual rule, and instead go to the last card I was on last time I visited this row". (As well as the symmetrical other rule, replacing "right" with "left")
This accounts for the fact that you lose information when navigating from a horizontally longer row to a shorter one. The analogy to text editors would be illustrated by this example, which you can paste into any editor and try out:
1234
12345678
123456
If I put the cursor at the end of the 8 on the second line, when I go up and down, the cursor will always come back to after the 8, even though it was much further to the left on the line above. Similarly if I put it after the 6 on the last line, the cursor always jumps back as close to this horizontal position as possible, given the length of the line.
The rule might actually be something like, when navigating from a longer row to a shorter one, remember the horizontal position I came from, and always go the card closest to that position. Probably lots of edge cases on that though, given different layouts, and I understand if you don't want to take this on!
I do hope that tree editing can become as intuitive and ergonomic as text editing!
Whatever you do my hope is that arrow navigation is more about navigating the layout, not the tree structure. The tree structure is abstract and has no inherent notion of directionality. The layout is what defines up and down, left and right, and that's what the arrows should be oriented towards. Hence my request to not think of "centermost" but rather "horizontally closest".
(With the additional restriction that going up or down should never take you to a separate sub-tree! So it is more like a traversal of the layout but constrained by the structure)
"As close as possible to "down" is the aim." I am in agreement with you on that. It was said by @zippy that left-most made sense, but @zippy I'd really like to hear if you're committed to that, or if Michael's and my suggestions are mind-changing for you.
the navigation path having a 'memory' when navigating the map makes a lot of sense. we could have this as a default behaviour, but of course as mentioned, the behaviour option could be toggled in Preferences. @Connoropolous let me know if that could work
