Search results problems

[Spliff]

The Good

Navigation within the search results (SR) enables the user to edit the respective contents in the Content Pane, without the SR vanish; this is indeed the very best feature of the SR.

(Also, users can preset individual sorts for different search results, which obviously is helpful for "recently viewed" and the like.)


The Bad

UR's SR seems to be the only competitor in its field which has seem to be unable, insofar, to also provide a (flat) tree preserving structure. I very much hope this can be corrected someday!


The Ugly

The pretty thing first: When I (rarely) DEL(ete) a search result, the current SR are preserved, just the deleted item vanishes. So it's proven the SR CAN be more or less preserved, after changes in the SR.

Now the ugly thing 1 (this might be more or less unavoidable?): When I cut a search result (^x), then select a new target = parent for it in the tree ("Data Explorer"), and do the respective ^v = paste, the SR vanishes, and is replaced by the (totally unwanted) children list of the new parent of the moved entry.

Now if I my SR constitue some sort of "inbox" or whatever you wanna call it = some dozens, or even some HUNDREDS of elements, to be DISTRIBUTED into the tree, this behavior is utterly AWFUL, since I then have to trigger the same "search" again, and I get the same SR as before, with hundreds of entries, just without the moved one(s), BUT at LIST START, NOT at the position in the list where I had been before.

And now ugly thing 2, and here, I seriously think you could easily DO something about it: When I select an item in the SR, then do "Tree - Link/MoveTo" (I have a shortcut of course (Alt-l) but don't know what the original = default shortcut is, doesn't matter), paying attention that that dialog is set to Move, not to Link (of course), then select the target = new parent in that dialog...

then the SR vanish, too!

And that, obviously, would not be necessary: The "OK" in that dialog closes the dialog, and the SR should be preserved:

a) in its previous form if necessary, so that it would be up to the user to remember that some elements = search results are not at their indicated position anymore

b) or as a) but with their icon greyed out (! could be an elegant and quite very little demanding solution, code-wise) ; both in a) and b), the user would then refresh their search = SR "here and there", but could move, this way, dozens of elements = search results to their respective new positions, AND with = while preserving their own visual "location" within the SR, i.e. could "work in bulk".

c) or then, as above for the DEL, you (partly here!) "refresh" the SR, just deleting the elements from their previous location, but without inserting them at their respective new location, i.e. without re-building the tree; here again, the user would, after some dozen of moves, "refresh" the SR, if needed, by re-triggering the search

d) you rebuild the tree, i.e. you refresh the tree, with the moved item(s) now at their correct new position, but you would "locate" and preserve the previous user position, i.e. would NOT present the refreshed tree at its beginning (as a new search would force the user): if the deleted item had been at position 365 in the SR, pos 365 in the SR would also be the selected item after the SR refresh.

For all a) to d), it would NOT be necessary to also refresh the tree ("Data Explorer"); this would automatically be done whenever the user LEAVES the SR / Alt-l environment, and when the Data Explorer gets focus again.

ANYTHING out of a) to d) would be perfectly acceptable, just the current situation is not. So please DO something about it, and dont take the possible "difficulties" of the implementation of d) as a pretext to not implement anyone of the solutions a), b) or c) either.

This is really overdue; pc use should SMOOTH the "workflow", instead of BREAKING it after every single step!

If I have overlooked some "trick" to move multiple results from SR "in a row", one after the other, and without losing the SR in-between, please tell me!

[kinook]

Option c) was implemented in the latest download (6.3.0.9).

[Spliff]

Fantastic! Thank you so much!

This is a wise solution, since the user, in this situation, considers the SR as a "to do list" to be worked on, so that any "disappearance" from the SR equals "done", the "done with" elements in the SR, having disappeared, not even being a "visual nuisance" anymore, and, as said, the user doesn't expect more complete "update" of the SR than that; they will simply do that whenever they feel an "update" (= new search) will be useful.

Obviously, this perfect (sic!) solution arises the question of how you could possibly amend the target list ("Tree - Link/Move To") since currently, this list seems a little bit "aleatoric" in its "collapse-expand" state, but experience with that list (I have just used it for linking, never for moving or copying) will show in what way the current tree representation in this target list could be "bettered" (if needed).

I'm so glad about this that I'll share my "tree system" soon (in which linking with that pane functions perfectly already, albeit me navigating in that target pane "blindly", so I have high hopes that for "distribution" (= moving new elements) it will also be very functional already, even in its current, visually a little bit "chaotic", state!).


EDIT after some hours:

First of all, please have some wonderful holiday around Christmas and the New Year, and consider anything I might write here before 2024 as "to be considered then, certainly not now"! (The preservation of the Data Explorer tree, while the item, moved from the TT, simply disappears, is simply wonderful!)