Show Posts
1
General Software Discussion / Re: RightNote Revisited / Review (in lieu of a RN forum)
« on: September 02, 2024, 11:17 AM »
Greetings,
I discovered this thread yesterday, by googling RightNote review. I have tried out / compared somewhat three such (desktop) programs, MyInfo, UltraRecall, and RightNote, especially with regards to their respective search functionality, and couldn't confirm some info from above, about the latter, but I may be mistaken. It's said there that RN Pro comes with more extensive search than its lesser versions, and it's true that there is some "Global Search Dialog" then, but that seems to be without extended search functionality in the end.
Here's my comparison:
Global search-and-replace:
Nowhere, and you can't do it by sql either since that would only edit the plain text data (which isn't there but for the full-text-search), then being overwritten by the unchanged, formatted data next time you display the items in question. So, the only way to do it is to run a macro, doing the necessary changes one item by one.
Tree order preservation for the finds:
Nowhere, even if you name the items accordingly to the alphabet, or number them, be that naturally (1, 2, 3...10, 11...) or with leading zeroes (001, 002... 100, 101...): Differences within the respective indentation level will cause mixing the tree order up into anything else (eg abc, or by some attribute value, even first sort, secondary sort, in MI (by so-called Perspectives) and UR (by choosing the columns to be displayed, then selecting their sort order), but tree order preservation is impossible to obtain, and in RN I haven't even found any user-determined order for the display of the search results.
MI tree filter (in other words, Search with tree order preservation):
Has tree filtering, so you can, for example, put a "tag" into the item title, then filter by that tag, for example xyz, x being the tag signal character, y being the tag category, and z being the value for the tag. Unfortunately, no AND or OR for this tree filter are possible (I haven't tried NOT), which seriously invalidates this functionality which otherwise would be of high interest. UR and RN don't have anything of this sort.
Display of the find in its context:
None in UR, and even worse, you must choose if you want to be able to edit the found items, without the search results list vanishing in-between, or if you want the found search terms to be highlighted in the found items, not both at the same time, so in practice, at least for items with text of some length, you scroll a lot, and either can then do some editing, or you must trigger a secondary, . MI optionally shows about 4 words before, and 4 words after the search term, but in many cases, this isn't enough, so that you will still have to look up the find in the item, where it's highlighted in spite of your possibility to directly edit it, but as in UR, it implies lots of manual scrolling in the end, when technically, it would be possible to have the software scroll automatically to the first find when the content pane gets focus. RN is the only one of the three which lets you choose some real vicinity of the find, so that if you set the settings (even separate before and after the term) accordingly, you avoid having to look up the find within the original context, just for deciding if it's pertinent or not, in most cases.
Boolean search in regular search (by search bar):
All three rely on Sqlite, so you would assume they have good Boolean search since that's easy to obtain with sql selects, but no.
RN is worst, even in Pro (if I'm not mistaken, after thorough search for better functionality) it's just "all terms", "either term", and "phrase", so either AND, or OR, no combination, and I have difficulty to understand how can some Sqlite-backed PIM be that bad, so please tell me if I have missed anything here, since the combination of real find-context and at least not totally unacceptable, basic Boolean search, as in MI and UR, would make RN the best choice of the three, for many so-called work-flows.
In regular search, MI and UR are very similar: They both just offer AND over OR, since that's Sqlite's operator precedence in the absence of grouping, and in fact, neither MI nor UR allow for grouping here, or rather, you're free to try to group search elements with parentheses, but both then simply discard them internally, instead of taking them into account, and neither of them offers a toggle to switch the precedence (as does Everything for example). It goes without saying that for allowing parentheses, they would simply not discard them before further processing, as they do today, and for a user toggle, some lines of codes would suffice for putting the necessary parentheses around any OR groups.
So, both offer the combination AND and OR here, but since they force AND over OR, many real life searches will have to be written in a totally unacceptable way, since their ORs will be needed for synonyms of your main search term, in combination with some (one or two) other search terms, here's an explative example:
regular search with OR over AND (implicit grouping, impossible in MI and UR):
dog OR breed1 OR breed2 OR breed3 OR breed4 AND dangerous OR aggressive
or even shortened, space = OR, according to their current space = AND:
dog breed1 breed2 breed3 breed4 AND dangerous aggressive
regular search with explicit grouping (impossible in MI and UR):
( dog OR breed1 OR breed2 OR breed3 OR breed4 ) AND ( dangerous OR aggressive )
regular search currently forced upon you in MI and UR:
dog dangerous OR dog aggressive OR breed1 dangerous OR breed1 aggressive OR breed2 dangerous OR breed2 aggressive OR breed3 dangerous OR breed3 aggressive OR breed4 dangerous OR breed4 aggressive
... and note that I even left out the numerous ANDs, which are not needed in current MI and UR indeed, and imagine the necessary search string in the current MI or UR search bar if I had AND ( dangerous OR aggressive OR hazardous ) instead.
Better Boolean search by "Advanced Search" grid (UR) or "Perspectives" (MI):
In UR, you can do real Boolean search in that grid, but only within that grid, so you will have to manually fiddle with the values within that grid, and if you try to avoid that by combing a (stored) grid with your input in the search bar, you will discover that the developer did not design it as
(whole search bar input as row0 of grid input)
AND/OR (grid-row1)
AND/OR (grid-row2)
etc
but as
(whole search bar input) AND/OR (whole grid input as a block)
which will make impossible your intended search more often than not, and again, you will have to fiddle with the grid, even for the flexible part of your search string.
And in MI, those "Perspectives" may also offer real Boolean search, again with fiddling with values to be set in a prefigured data set, instead of simply entering them - or their flexible part then - into the search bar; a combination, as in UR, may be possible here, and possibly with similar limitations.
For some of my work, I value the immediate vicinity display in RN (in theory, up to 100 words before and after, while it's not possible to set "the whole sentence" though) high enough to live with the very simplistic Boolean search, currently possible in MI's and UR's search bar, but "all terms" or "either term" or "phrase" simply is too basic for me by all means, thus my question if I have overlooked some better search, which, above to posts above, RN even had had years ago.
Thank you!
I discovered this thread yesterday, by googling RightNote review. I have tried out / compared somewhat three such (desktop) programs, MyInfo, UltraRecall, and RightNote, especially with regards to their respective search functionality, and couldn't confirm some info from above, about the latter, but I may be mistaken. It's said there that RN Pro comes with more extensive search than its lesser versions, and it's true that there is some "Global Search Dialog" then, but that seems to be without extended search functionality in the end.
Here's my comparison:
Global search-and-replace:
Nowhere, and you can't do it by sql either since that would only edit the plain text data (which isn't there but for the full-text-search), then being overwritten by the unchanged, formatted data next time you display the items in question. So, the only way to do it is to run a macro, doing the necessary changes one item by one.
Tree order preservation for the finds:
Nowhere, even if you name the items accordingly to the alphabet, or number them, be that naturally (1, 2, 3...10, 11...) or with leading zeroes (001, 002... 100, 101...): Differences within the respective indentation level will cause mixing the tree order up into anything else (eg abc, or by some attribute value, even first sort, secondary sort, in MI (by so-called Perspectives) and UR (by choosing the columns to be displayed, then selecting their sort order), but tree order preservation is impossible to obtain, and in RN I haven't even found any user-determined order for the display of the search results.
MI tree filter (in other words, Search with tree order preservation):
Has tree filtering, so you can, for example, put a "tag" into the item title, then filter by that tag, for example xyz, x being the tag signal character, y being the tag category, and z being the value for the tag. Unfortunately, no AND or OR for this tree filter are possible (I haven't tried NOT), which seriously invalidates this functionality which otherwise would be of high interest. UR and RN don't have anything of this sort.
Display of the find in its context:
None in UR, and even worse, you must choose if you want to be able to edit the found items, without the search results list vanishing in-between, or if you want the found search terms to be highlighted in the found items, not both at the same time, so in practice, at least for items with text of some length, you scroll a lot, and either can then do some editing, or you must trigger a secondary, . MI optionally shows about 4 words before, and 4 words after the search term, but in many cases, this isn't enough, so that you will still have to look up the find in the item, where it's highlighted in spite of your possibility to directly edit it, but as in UR, it implies lots of manual scrolling in the end, when technically, it would be possible to have the software scroll automatically to the first find when the content pane gets focus. RN is the only one of the three which lets you choose some real vicinity of the find, so that if you set the settings (even separate before and after the term) accordingly, you avoid having to look up the find within the original context, just for deciding if it's pertinent or not, in most cases.
Boolean search in regular search (by search bar):
All three rely on Sqlite, so you would assume they have good Boolean search since that's easy to obtain with sql selects, but no.
RN is worst, even in Pro (if I'm not mistaken, after thorough search for better functionality) it's just "all terms", "either term", and "phrase", so either AND, or OR, no combination, and I have difficulty to understand how can some Sqlite-backed PIM be that bad, so please tell me if I have missed anything here, since the combination of real find-context and at least not totally unacceptable, basic Boolean search, as in MI and UR, would make RN the best choice of the three, for many so-called work-flows.
In regular search, MI and UR are very similar: They both just offer AND over OR, since that's Sqlite's operator precedence in the absence of grouping, and in fact, neither MI nor UR allow for grouping here, or rather, you're free to try to group search elements with parentheses, but both then simply discard them internally, instead of taking them into account, and neither of them offers a toggle to switch the precedence (as does Everything for example). It goes without saying that for allowing parentheses, they would simply not discard them before further processing, as they do today, and for a user toggle, some lines of codes would suffice for putting the necessary parentheses around any OR groups.
So, both offer the combination AND and OR here, but since they force AND over OR, many real life searches will have to be written in a totally unacceptable way, since their ORs will be needed for synonyms of your main search term, in combination with some (one or two) other search terms, here's an explative example:
regular search with OR over AND (implicit grouping, impossible in MI and UR):
dog OR breed1 OR breed2 OR breed3 OR breed4 AND dangerous OR aggressive
or even shortened, space = OR, according to their current space = AND:
dog breed1 breed2 breed3 breed4 AND dangerous aggressive
regular search with explicit grouping (impossible in MI and UR):
( dog OR breed1 OR breed2 OR breed3 OR breed4 ) AND ( dangerous OR aggressive )
regular search currently forced upon you in MI and UR:
dog dangerous OR dog aggressive OR breed1 dangerous OR breed1 aggressive OR breed2 dangerous OR breed2 aggressive OR breed3 dangerous OR breed3 aggressive OR breed4 dangerous OR breed4 aggressive
... and note that I even left out the numerous ANDs, which are not needed in current MI and UR indeed, and imagine the necessary search string in the current MI or UR search bar if I had AND ( dangerous OR aggressive OR hazardous ) instead.
Better Boolean search by "Advanced Search" grid (UR) or "Perspectives" (MI):
In UR, you can do real Boolean search in that grid, but only within that grid, so you will have to manually fiddle with the values within that grid, and if you try to avoid that by combing a (stored) grid with your input in the search bar, you will discover that the developer did not design it as
(whole search bar input as row0 of grid input)
AND/OR (grid-row1)
AND/OR (grid-row2)
etc
but as
(whole search bar input) AND/OR (whole grid input as a block)
which will make impossible your intended search more often than not, and again, you will have to fiddle with the grid, even for the flexible part of your search string.
And in MI, those "Perspectives" may also offer real Boolean search, again with fiddling with values to be set in a prefigured data set, instead of simply entering them - or their flexible part then - into the search bar; a combination, as in UR, may be possible here, and possibly with similar limitations.
For some of my work, I value the immediate vicinity display in RN (in theory, up to 100 words before and after, while it's not possible to set "the whole sentence" though) high enough to live with the very simplistic Boolean search, currently possible in MI's and UR's search bar, but "all terms" or "either term" or "phrase" simply is too basic for me by all means, thus my question if I have overlooked some better search, which, above to posts above, RN even had had years ago.
Thank you!