|
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!
|