View Single Post
  #20  
Old 08-16-2021, 05:59 AM
Spliff Spliff is online now
Registered User
 
Join Date: 04-07-2021
Posts: 74
(See my post immediately before this one.)

I understand that the systematisation of "Scope - current database" vs. "Scope - all databases (if current database is the current one when next closing UR), within the code and within the menus, would make necessary lots of recoding, but perhaps, a list(s) page in the help file could clarify this?


When I spoke of my new, and systematized, column choice, above, in the Child Items / Search Results pane, I in fact spoke of "Item Title" only now, since, unfortunately, I had come to the conclusion, for my and very probably also general use, that the "Parent title" column, in practice, is of very limited use: When you have multiple search results, then the indication of the "Parent title", more or less deep-down within the tree hierarchy, most of the time will not help you for identifying the sub-tree / sub-area / whatever real sub-part of the tree the search result is in.

Instead, I would like to suggest the introduction of a column - which would thus be to introduced into the database table as well - "area" or the like, and which would retrieve the first level just below the database's source level.

According to the user's database(s') split-up, this information would be more or less helpful indeed; I have databases with just a low 4-digit number of items, and then (very few) others with about 50,000 items, but even in the latter, there are some 50, 60, 80 first-level "areas", and whilst in this situation, the above-mentioned new column information would not be too precise indeed, it at least would clearly indicate the "area" the search result comes from / is located in, and that would be tenfold the usefulness of the current "parent item title" column in / for most use cases; if your database isn't but 2,000 items, e.g., then, of course, this "area" info may be very precise indeed.

Such a new column = record field for every item would obviously serve to facilitate the browsing thru numerous search results, as also would, e.g., the extensive use of user-defined keywords, but the user-side(d) introduction and maintenance of the latter would be a very high work load indeed; being able to identify the "area" within the database in question, for each search result, would greatly facilitate the user-side(d) "weighting" of any search result, even in the absence of some "AI", judging, instead of the user, about the alleged relevance of every search result, when on the other hand the introduction of other search terms, in combination with the "main" search term, could unwillingly exclude very well "wanted" / expected search results indeed.

I advance this from some 6, 7 months+ of practical experience with a comfortable 6-digits number of items in UR, now spread over more than 20 databases, so I'm absolutely sure of the usefulness of such an additional "column", and generally speaking, any searching is about including ALL possibly relevant search results, BUT then also about fast discarding irrelevant search results from the lot.

Such an "area" column, i.e., for each item, the ID of the (technically,) second-level (primal) ancestor item, and its resolve into the corresponding title of that ancestor in the columns displayed to the user, would obviously work very differently than the "Limit search to the selected item" option in the search dialogue, since the latter only would display items which are items of a SINGLE such sub-tree of any indentation level, up to the "area" (level 2) in case, and to make real use of that, the user will be forced to create deep sub-hierarchies, whilst minimizing the "areas" number, i.e. the number of level-2 items (directly under the source item) in each database, or then to make several such "focused" searches, for several such ancestor items / sub-trees, in a row, and without the possibility to gather the finds.

If, on the other hand, the user can make a general search within the database, but then gets the indication of the "area", for each item, (s)he will be able to quickly decide which ones of the possibly dozens (or more of) items found by the search will be relevant to their task at hand, and without (!) the risk of discarding "valid" search results, a risk that would prevail by trying to better "focus" the search by adding additional search terms which should also be present within the items' title or text; in this respect, it should be remembered that UR's search does not allow, and understandibly so since this would largely increase the index, not speaking of the necessary coding, to include only, or then exclude, items of which the parents or ancestors of any level contain, in their titles (!), specific search terms, which would certainly be an ideal solution to this very general problem not limited to UR.

Again, it must be noted that the suggestions would not produce similar results to the aforementioned "Limit the search..." option, but would produce a much broader data set, from ALL relevant "areas", not just from ONE, as that option does, BUT with, more or less precise, indication of the "areas" they come from, thus allowing the user to spread their data "horizontally" in a way, holding the respective hierarchies quite flat, and getting relevant search results in spite of that, whilst the current, option solution to "focus" the search scope, forced them, in fact, in consequence, to create very deep hierarchies, by minimizing the number of level-2 items in each database; at the same time, and in consequence again, this leads to "combination" of data within the same "area" (or then, one or several indentation levels deeper) which should be held distinct, i.e. as child items of different parent items.

This conceptional problem can be greatly (!) reduced by making available, in the search results, of at least the corresponding "area" title (level-2 item title text), whilst the indication of the respective deepest-down parent, instead of the highest-up parent just below the source item, as done currently, most of the time, will not bear any relevant information.

Last edited by Spliff; 08-16-2021 at 10:31 AM. Reason: Clarification of the "area" problem
Reply With Quote