Keyboard navigation in tree hampered by including items above current item

[Spliff]

Applications with treeviews or listviews generally come with a quicksearch, i.e. when that pane has the focus, the user enters one or several characters, and the underlying code selects the first first entry starting with that character(s).

a) Some such applications start that "search" from the currently-selected item - if the user wants to start it "from top", they have first to press {home} to "go" there.

b) Others present an option to the user, e.g. FreeCommander's : Settings - Quick search - Start quick search from top Yes/No (by checkbox); problem is, they don't also offer that toggle by shortcut, and so, for many such navigational needs, the setting is set to the "wrong" option, whilst changing that setting is very unwieldy.

c) Only very few applications start that "quicksearch" from top - since that's, and by far, the worst solution of them all -, and very unfortunately, UR is among them.

The implications of this policy are dramatic: Let's imagine you "quicksearch", in level 1, for some "a", and let's imagine that - from top: and for level 1, that's even the most practical way to implement it - will even select then the level1 entry asomething.

Then, you expand that entry, since your real "target" is on level 2 or even level 3 (I know about "favorites", but I'm speaking of general navigational tasks here, to a multitude of target items, constantly changing):

Here, ANY, EVERY user would want their next navigational character entry to "stay" within the now "current" level, i.e. their "b" should select the "next" bsomething, and that's the first "hit" within the siblings "children" = level 2, of that, now expanded, level 1 "a" hit -

Or then, if that's not a flat list, since one or some of the "children" on level 3 is / are also visible (i.e. some of the level 2 siblings is expanded, the first "b" hit there should be selected:

i.e. that's the decision between
- strictly next sibling (= same level), and
- next entry (regardless of possible further "indentation").

Neither is possible in UR if there is a "hit" above all those, nearest to the root item (level 1), and it's obvious that there is no UR user who doesn't encounter this a problem, again and again, multiple times a day, or then, they will already have shifted to not trigger that "quicksearch" anymore in such situations (i.e. except in level 1, and hoping level 1 is more or less collapsed.

(I also know about Options - Trees - "Collapse sibs when expanding or going to an item" but that might not be what most users want, since it has lots of other, allegedly unwanted, implications.)

Thus, the minimum solution to the aforementioned problems would be solution a) = start the "quicksearch" at the currently selected item -

But obviously, a MUCH better solution would be b) = toggle between "from top" vs "from current item" (available by shortcut), together with the second alternative = down the tree, regardless of level -

(Since the obviously very best solution, b) and with first alternative (for then the option "from current") = "stay within the current siblings" (i.e. if current is level 1, next hit will be in level 1, too, regardless of possible expansions, ditto for level 2, and so on) might imply considerable coding work? That ideal solution would even be optimized if a simple expansion (i.e. "rightarrow" on the current item) would automatically (if there are children of course) trigger a "downarrow" after expansion, since then, the then-current item would be the first (or only) "child", and the "stay while quicksearch" would automatically search these siblings, without (!) the user having to do "right then down" every time, in order to start further "quicksearches", just the "right" would be sufficient, for every level the user travels down in the hierarchy.)

As said, the current "always from top", with no choice for an alternative, is the worst imaginable implementation of "quicksearch"; please consider.

[Spliff]

To best clarify that:

Your tree (with level):

source
some (1)
_a (1)
_something (1)
_b (1)
_d (1) (is expanded)
____b (2)
____a (2)
____c (2)
_asome (1)
_etc (1)

You are at b (1)
You press a
You want to go to asome (1) but you get to a (1)

If UR AT LEAST replaced "quicksearch from top" by "quicksearch from current",
in this situation you would get to a (2); you can only prevent that by closing d (1),

BUT at least, if you do NOT do that, you would FIRST get a (a), and with a SECOND "a", you would get to asome (1) which is your intended target...

whilst with UR's current "from top only", you would get STUCK (!!!) at a (1), and then you have to manually navigate, by up/down-arrow, OR you would have to enter more characters, in order to get to the "right" item, and that complicates your task considerably, since you will never know HOW MANY further characters you will have to enter, in order to "get it right".

This should be corrected as soon as possible, it's obviously a functionality NOT ON PAR with UR's otherwise systematically superior functionality, compared with its "competitors" (which, for most of them, "compete" rather poorly).

(

As for "optimized" solutions, but which cannot be asked for, since they ask for lots of coding I suppose:

Again, you are at b (1), with d (1) expanded (as above). Again, you want to go to asome (1). Ideally, UR's quicksearch would stay in level 1, and go there, NOT to a (2) (whilst currently it's stuck on a (1), which is unacceptable)...

and for going to a (2) (remember, d (1) is expanded, you would instead enter "d", for going to d (1), and after half of a second or so, you would enter "a", in order to go to a (2): done...

and, if d (1) was NOT expanded, similarly: you would enter (d), in order to go to d (1), but UR would check d (1) is not expanded, so it would automatically expand it...

AND it would automatically select its first child (if then, you want to create another d (1) child, you would just have to do another sibling (in this case: for a (2)) instead), and your then "a" input - again STAYING within the current level (2 now), would get you to a (2), as intended.

STAYING within the current level, AND automatically* expandig the "target", AND then automatically selecting the first item "within" (i.e. the first child item of) that target...

WILL (would) enable users to create perfect personal information management systems...

*= whilst this automatic (!) expanding of any "quicksearch" target should be "by option only", ideally even "just for levels 1, 2, perhaps 3" - by user-setting:

Since this paradigm implies that the user WILL install a perfect navigational, i.e. ontological, system, with any a-z and 1-0 character occurring just ONCE on any level, and that obviously is just realistic for levels 1, 2, and perhaps 3, depending on the application of the respective user to their information management...

With near 400,000 items in all in my case, and daily adding between 70 and 120 new items, I can confirm that some "application" to "the way you work" is necessary for big data compounds, if you don't want to get totally lost.

)

Hence:

- Strict minimum: "Quicksearch" "from current item", the tree down (including further-down, expanded levels)

- Ideal(ly): "Quicksearch" "from current item" (i.e. so long as above), but only, and in ALL levels (!), WITHIN the current level ...

and additionally - but only in levels 1, 2... (by user-setting, ideally specific to the db in question, not application-wide) - with automatic expanding of any such "found target" (plus selecting its very first child item, in order to facilitate further "drilling down" as before).

P.S. I had also checked those several "register zips", in order to find a possible setting switch for "quicksearch (whatever you call it) from "from start i.e. from source item" to "from current item", but nada. Please add those necessary, 4 or 5 (?) lines of code to make that optional-general switch available, Kyle!

[kinook]

I'm surprised that keyboard navigation in the tree would be relied on that heavily, and it hasn't come up before, but in the latest download (v6.2.0.6), the keyboard behavior of the tree control used in UR is now exposed via a registry setting (CharSearchMode), and defaults to matching on the next item down the tree (8 => CHARSEARCH_ALLCHARSWRAP2) before matching on items above the current item in the tree (3 => CHARSEARCH_ALLCHARS2).

See https://www.kinook.com/Forum/showthread.php?t=5097 => CharSearchMode for more details.

[Spliff]

OMG!

Fantastic work, Kyle, on the weekend, wow! MUCH more than "just 4-5 lines of code", obviously!

(There's a glitch with the "hidden" sets, please see below.)

I made up a little table, for the user better determining what they will prefer, will try with spaces (since tabs would very probably not work; see below).

In different situations, users would like to switch between different sets; perhaps not between all of them, but perhaps between 2, so perhaps, with an upgrade (!=update), it might be possible to switch, by shortcut (toggle?) between (pre-set) two of them?

(Currently, any switch is by registry, so the user has to close down UR (before or after doing the reg change), then re-open UR, but that's without problems:
Win-key, then enter "reg" (always (!) without the ""), enter
there: ^f for "Search", then "Computer\HKEY_CURRENT_USER\SOFTWARE\Kinook Software\Ultra Recall\Options" enter
Then double-click on the hit ("Options" key (, left pane; not on the the key-value ("type", "data"), and in the dialog which opens by that, simply change the numeric value (the necessary "Base: Hex" is already preselected, you enter the number as any digit, e.g. "6").)

Your idea to INCLUDE HIDDEN items (by option) is SPECTACULAR, I've never seen that!

AND you're right to pre-select "8" as default, since that's what most users would expect, from their experience with almost all other software as well as from what they would intuitively select for themselves.

Also, the LOOP when not-successful is more or less expected by users, whilst in (flat) file manager lists, "you" will then quickly be "where you want to go", in many situations, i.e. at the intended hit above (!) the starting-position...

whilst in an outliner tree, strictly technical "looping from above", in many situation, has a very unwanted (!) effect: It throws the user OUT of their "immediate work space", bringing up some "hit" "way off", somewhere several levels above in case, and there, in some totally different area, i.e. this loop then will have totally aleatoric effects.

Thus, the user will be well advised to do "vicinity searches", i.e. starting from current-position, and when they are not sure the target is below that position (since they might have it before their eyes, then no problem), to do such searches then by starting with {leftarrow}, in order to start the search from there.

(I don't know if it would be difficult, technically, thus code-wise, to start any "necessary" loop (i.e. just the loop in case) then from the immediate parent of the item from which the quicksearch had been started? If that's quite easily feasible, I suppose every (!) would then prefer that behavior of 5, 6, 7, 8, over the loop jumping to the source item again.)

Even as it is now, "8" for me is an INCREDIBLE RELIEF, thank you so much, Kyle, I'm eagerly awaiting the next upgrade, two years between seems to be "good for everybody", I think. ;-)

As said / implied, 0/1, 5 and especially 7 (i.e. 8, but including hidden items), if you can bring it to work with not too much fuss, will be a spectacular USP: Already your transclusion implementation is without par, users can then work on any of the (even multiple) occurrences of that cloned, whole sub-tree in case,

they just need to know that when they do manual rearrangements of the child items, etc. within that subtree, they are well-advised to press Shift-F5 afterwards (and in any case before closing the db...), and if they do, there will not be any unwanted "surprises"...

(Perhaps you could automate that "Tree - Refresh All" for taking place "behind the scenes" whenever the user leaves (the current occurrence of) that cloned subtree? Since it might be that users "tried out" that fantastic feature of UR's, then did not the "Refresh", and wen re-opening their db, they discovered their changes had been discarded, then (and by that) erroneously presuming that transclusion (called "linking") in UR wasn't "reliable", when in fact, it perfectly is!)

So, UR is really unique in its power, and even finding hidden items by quicksearch would make it even more outstanding...

This then also includes looping, e.g. (and that's systematic) you have
asome
bsome
csome
which all are parents to subtrees, and all three are collapsed, but before, a had been expanded, b and c not yet.

(I'm certain with this, you know already where the problem lies... ;-) , but to explain for fellow users

You "are at" b, and you enter "xy" (with "7", as said), and in c, there is some xysome, so c should be expanded, and its child item xysome should be selected.

But since c had not been expanded yet, it stays collapsed, and a is expanded, and its xysome is selected; ditto even if xysome is also in b itself (remember "we are" at (collapsed) b when we search for xy): So in this case, even when the intended hit is a direct child item of b, it's not found, but here again, after loop, xy in a found (since a had been expanded before); I also tried with clone items, and it's the same behavior.

All this is "systematic" behavior of "7" and "5", which I then also tried out for this, whilst I admit that I suspect 1 and 0 behave the same way, without having them tried.

Since (also from what you recently said) I suppose that everything which is shown in the Data Explorer, is loaded into work memory (and stays in it for the whole work session (??? So, might it work reliably at least for many hours the same day, for subtrees having (!) been expanded at least once that day? - alleging there is enough work memory (in my case 16gb), so that UR might not be driven to de-load some data again, for space reasons? But it might de-load data after some time, automatically, even within the same session, and even if there is enough work memory?!), but obviously not beyond...

If UR's memory management is predictable after all, i.e. if it does NOT automatically de-load data but if there is not enough space for it (which will not occur then in my scenario and many other users'), the "find even hidden items" sets (0, 1, 5, 7), I would probably stay with "7", since I could expand levels 1 (manually or by macro, according to the situation, and then collapse the whole tree again by UR's shortkey: Tree - Collapse), and that would then also load all items on level 2 (!) into memory, and then, from level 1, all collapsed or some subtrees expanded, as may be determined by my work situation, I would have quicksearch access to everything on level 2, and this would make possible enormously fast navigation, especially for "FILING" from inboxes!!!

So, please, do not take away those sets 0,1, 5, 7, now we (very probably) know why they work as they do, instead of working as we all might have expected beforehand: obviously, they are not "useless", but can come very handy, at least on the (higher-up) tree levels for which the user will have memorized the (main) item names / name-starts.

So, this arises the question if your next upgrade could possibly introduce another command (available by shortcut), or even a setting, specific per db and stored with the db, "pre-load (beyond level 1 also) level 2 into memory upon loading the db"...? This might probably not be too complicated, I suppose? ;-)

It's always a big regret when a BRILLIANT idea gets up the chimney, because some well-hidden (!) precondition isn't met in practice, so we should cling to that chance of quicksearch even finding hidden items, at least for our "very important targets", or then also for use in subtrees deeper-down, here and there; of course "7" e.g. will there then have some really unpredictable behavior, since we wouldn't necessarily be able to memorize what will have been expanded, and what has not been, down there.

But users who then find out they can't live with 7, are free to go back to 8 (e.g.) anytime...! ;-)

(And, as said, looping should, if easily feasible and after some upgrade, remain "somewhere in the vicinity": a restart from the immediate-parent of the unsuccessful search's start-item seems the ideal way to do that, since "drill-down", instead of "going up in the air".)

___________one-char_____one-or-more-chars

children:
just/even____vis/hid______visible/hidden

FROM:
SOURCE:
children:_____4 / 0_______3 / 1

CURRENT:
children:_____6 / 5_______8 / 7

disable: 2

[kinook]

It actually was a few lines of code to implement, because it's leveraging the functionality of the tree component itself. But changing the functionality isn't really possible because it is not code that we have access to.

For performance reasons, UR does lazy load unexpanded nodes, which is why keyboard navigation into collapsed items with children only works if those items have been expanded during the session. One option to alleviate this would be to use Tree | Expand All (to expand and load all sub-nodes), then Collapse All, in a node that you want to navigate around in via the keyboard.

UR does not unload data from the tree, but it does reload the entire tree from the DB (again, only unexpanded nodes) on Refresh All, hoist/unhoist, certain move operations, etc.).

BTW, there were more than 6 updates in the last 2 years.

[Spliff]

Thank you so much again, Kyle, anyway, even if it wasn't so much of work, since the effect of what you have done is spectacular, for us now having a quicksearch - for quick navigation, and for filing - that (optionally) starts at the current entry, instead of (if we didn't want to, or could not, enter rather long, very specific strings) getting us stuck way "above" our intended target item(s); now, with "8" e.g., we can enter "e", for going so "esome", then enter {right}, in order to expand its child items, enter "f", and get to that child item "fsome" -

which before was impossible: navigating to some subtree, and then trying to select something "in there", by quicksearch, threw you back to something way above that intended target, or you had to enter 4, 5 chars instead of just 1 or 2.

Since this "quicksearch" works "depth over breadth":

a (here you are when pressing "e")
b
c (is expanded)
__a
__b
__c
__d
__e (this level-2-item will be selected...)
d
e (...and not this level-1-item),

it's obvious that for general use, 6 is preferable to 5, and 8 to 7, since (for 6 and 8 then), the user has a way of forcing quicksearch to select the target items they really want to navigate to, collapsing vs re-expanding the parent(s), so if we can't toggle between 2 preset settings (but that might be possible with an upgrade?), the even numbers should indeed serve us better than the odd ones, but anyway:

It's correct that if you trigger "Tree - Expand all", while source item is selected, you will load the whole tree into memory, but do that for for a tree with 50,000 items, and you'll see that for big data sets, that's devoid of any interest ; on the other hand, for a tree of 300 items in all, that might be something worthwhile, though, especially if you had put some ("ToDo", or other) "tags" at the start of some of your items, and prefer to work on them directly from tree, instead of from search results.

So for big data sets, I wrote an AHK macro, but which is very simple and thus should be "translatable" to almost any macro tool a user might deploy on their applications, if that tool comes with pausing (necessary) and with looping (not even necessary since instead, the user could just copy the contains of the loop, then paste them e.g. 50 times "in a row", and would be done for any UR db of theirs in which level 1 hasn't got more than 50 entries - and otherwise, we know that when in tree pane, tree being collapsed, ^a will show the needed number in the status bar.

; you trigger this macro when "in UR"
sendevent, ^1 ; go to tree (to be sure you won't create havoc)
sleep, 200 ; (milliseconds)
sendevent, +^t ; or what your shortcut for shift-control-t for Tree - Collapse Tree may be
sleep, 1200
sendevent, {end} ; last tree element
sleep, 200

loop, 45 ; that's a good number for my level-1, and unneeded iterations will just take a little while but won't do any harm
{
sendevent, {right} ; this expands the item if there are child-items, does nothing otherwise
sleep, 200 ; *
sendevent, {up}
sleep, 200
}

sleep, 1000
sendevent, +^t ; or your shortcut: collapse tree again : this takes much less time than to do it 1-by-1 in the loop, and also: have them (i.e. the multiple "level 2") stay expanded for some seconds might "help" UR to successfully load all of them into work-memory:
; *= if you wanted to collapse them 1-by-1 here, with sendevent, {left}, you would have to insert a much longer "sleep" (or "wait" or whatever your macro tools calls that), and with dozens of items, that would add up to some considerable macro running time - and that's why I do it from the last item up to the first one btw

Thank you so much again, Kyle: Even today, UR has become so much more "usable" (it had become so exhausting in the end, having to navigate principally with {up} and {down})!

And I had spoken of (paid) upgrades then, not of updates... ;-)