Ultra Recall search flaws?

Started by karel on 6/29/2018
karel 6/29/2018 3:30 pm
Hi,

user 22111 complained about problems with Ultra Recall's search (see an excerpt below) in this thread: http://www.outlinersoftware.com/topics/viewt/5136/30

I am on a verge of actually buying UR so I would like to learn more about this if there's somebody who can comment, pls?
My needs are simple (considering I won't get much anyway) - being able to search (incl partial search e.g. *linerSoftw*) in note titles, bodies and attributes/keywords. UR seems to be doing it ok. Where does its search fail, pls?


Thanks in advance for your kind help!

Best regards,

Karel



22111 wrote:
jimspoon wrote: "Infoqube and Ultra Recall are quite slow to sort or
display a grid of thousands of items. I guess the key is to refine my
search so that fewer items are displayed. The underlying database
structure is obviously very different."

I've complained about it elsewhere: UR does not "translate" the search
functionality of its underlying database, SQLite (some other outliners
do also use that since it's free AND it's real good, quite perfect for
this task (desktop, not too much collaborative), entirely, but "shields"
it from you.

And then, this is not new either, its search functionality is the only
element of UR that is not rock-solid; in fact, search results can be
unpredictable, which is one of the reasons I'm not so happy with it
anymore, all the less so since the developer, while eager to de-bug his
program any which way he can, does NOT do anything about UR's search in
spite of the reports about its problems he gets.

Now let's see into this: If we hadn't the tree frontends set upon those
sql databases, but some classic frontend you would have for the bigger
databases and which are often also available for SQLite, you could do
SQL searches, instead, and we all know that here, mainly two, three
factors concur to give you search speed:

First, the repartition of your data within the relational database. Of
course, this is a design decision, here of the UR developer, and you
cannot blame the underlying database for possible data repartition (I'm
not saying you try to do this, I'm just speaking in general); also, one
user needing particular searches often, is "offered" the "general"
database architecture, not something adequate to his needs, as if he had
set up the database himself, according to these.

Then, more or less parented to the first factor, is the maintenance of
indexes, meaning, which possible info is indexed, which is not, and we
recall UR does not offer any options here: Again, it's the standard fare
you'll be served.

And third, we all know that there are often lots of different ways to to
sql searches, very "dumb" ones - let's call them "beginner style", and
then, very smart ones, that often might not be tenfold as fast, but
hundredfold or even faster - or let's say the "beginner style" can be
very, very slow!

Now if you do sql searches, direct, you will "learn" from your response
times, meaning if your search is too slow, you will try to find a better
way to do the "same" search, and here, many web sites and advanced books
on sql will be of big help (if you can justify the buying and reading).

Now back to UR. I strongly suppose its search panes (regular and
"advanced") do translate your search wishes, in the most inflexible,
rigid, "stupid" way possible, into "dumbest" sql search commands, or
let's be nice and say, UR does standardize your sql searches to the
core.

I'm perfectly aware that in such an environment, there are not 51
possibilities, but there would be SOME possibilities at least, but which
would need to be implemented and coded, and you cannot expect this from
UR.

Technically, it's perfectly possible to predict some MORE standard uses
of the database, and to have at least additional indexes built and
maintained by option. Then, it's possible to introduce some more search
search panes, not just "standard" and "advanced", but to have several
"advanced styles", for different, typical tasks, and for which the
translation into sql would be quite different = optimized for the main
elements of your different searches, since of course, it's quite another
task to just combine different key words, or to select/sort by some
attribute, and then only be interested in key words, to give an example.

And then, it also would be perfectly possible to implement "stored
searches"... but for sql searches: Have a search "line" (in fact, since
we're speaking of sql, a search field with perhaps twelve lines) for
entering sql blocks, and have a pane to which you can store, and from
which you can then retrieve both stored searches with theirr content,
and just skeletons, or combinations of real search "terms" and just
empty command parts first to be filled up and/or to be adjusted to any
new search, meaning you will store some dozen such sql searches, grouped
by kind/complexity, and then retrieving one will place it into the
search field, where you will probably want to do adjustments (or even
not, for your most standardized, recurring searches), and then a key
(perhaps a double return) would trigger your "optimized" sql search,
optimized if you took the effort to optimize it.

Such an approach would also eliminate the unpredictability of UR's
current search, since you can be 100 p.c. sure that these bugs don't
come from SQLite, but from UR's "translation services".

And again, we face the old problem that we don't constitute enough of a
"market" in order for developers doing the work, and thus we live with
sub-standards that technically could be easily avoided. We just ain't
worth it.

This reminds me of MindJet: In so many years, with so much money earned,
they weren't able to introduce inter-illustration clones, which for a
mind-mapping system are so necessary though, since the philosophy beind
mind-mapping is certainly not to create monster maps with 5,000 items,
but to discard anything not relevant in a given context to another
context, but since things are interrelated to other contexts, too, this
supposes clones updated in different maps.

In fact, the absence of this feature invalidates the whole concept, but
without them being bothered by such considerations. I say it reminds of
MindJet since some days ago, I got a mail praising the newest version,
now with a better database, of a macro program that tried to update such
things, from the outside, in your MindJet map collection, be it for your
own use of "cartography" of your things, or for collaborative tasks.
This macro program, costing several hundred dollars, is expected to be
run before 9 in the morning, then again around supper, and then perhaps
again in the evening, instead of next morning before work: As said, it
maintains its own database in order to do all this that should be done
from within MindJet's database in real time, from the outside,
"manually", when there is a break in your work.

So this ridicule is proof that our not getting needed functionality has
not too much to do with our being too small a "market", but if we were a
great many (as paying MindJet users are), the return maximization
efforts of the developers/suppliers would assure we didn't get our
needed functionality there either.

Technically, it's almost always possible, and more often than not, it
would be even rather easy to code. Evernote is a good example: It has
certainly got some new, state-of-the-art functionality, so they prove
they are technically able to do a lot of things, and then many "basics",
also needed, have even been eliminated, instead of having been developed
to a higher degree.

Anyway: My starting point was, don't blame the database here, blame
stupid frontends.

Jon Polish 6/29/2018 4:02 pm
My usage is complex. I have found no issues with search. Constructing a complicated search requires some thought and awareness of how and in what order the commands will be executed. Others have commented that some pdf files are not searchable because they are not indexed. If the pdf in question is a non-ocr'ed scan, then it will not be indexed or searched.

UR is a great tool. Don't be put off by its lack of active development. It is a mature product. I wish Kinook was able to implement more of the items in its roadmap, but I would not hesitate to purchase it.

Jon
Jon Polish 6/29/2018 4:11 pm
Not to throw another variable at you, but have you tried CintaNotes? You can edit multiple notes in their own windows. Notes are not organized by trees but through a combination of tags and tabs. Not as robust as UR and it lacks several formatting features, but it is very good.

Jon
Pierre Paul Landry 6/29/2018 4:39 pm
Hi Karel,

InfoQube should be able to do all UR does, have you considered it as an option for your information management needs ?

Pierre Paul Landry
IQ Designer
http://www.infoqube.biz

Jon Polish 6/29/2018 6:17 pm
Yes, Pierre is right. But since you asked about UR's search, I thought I would tell you of my experience.

Jon
tightbeam 6/29/2018 7:38 pm
CintaNotes is an excellent choice and has surprising robustness, especially if your needs are relatively simple and you don't want to struggle with the busy, somewhat dated interface of UltraRecall or the complexity of InfoQube.

karel 6/29/2018 9:36 pm
Hi Pierre,

I certainly have :-) Very potent app, but (sadly for me) not in sync with my particular workflow.
BTW I noticed you use ClearType smoothing on some fonts. Maybe it can be turned off in the options, I didn't check, but in case it cannot, you may want to consider adding that. Just google all the issues some people have with ClearType. It just doesn't work for everyone and for all LCDs.

Best of luck with IQ!
:)
Karel


Pierre Paul Landry wrote:
Hi Karel,

InfoQube should be able to do all UR does, have you considered it as an
option for your information management needs ?

Pierre Paul Landry
IQ Designer
http://www.infoqube.biz

karel 6/29/2018 9:40 pm
Thank you for the tip, Jon. It's a nice app, but sadly for me, just not in sync with my workflow :'(

Best regards,
Karel

Jon Polish wrote:
Not to throw another variable at you, but have you tried CintaNotes? You
can edit multiple notes in their own windows. Notes are not organized by
trees but through a combination of tags and tabs. Not as robust as UR
and it lacks several formatting features, but it is very good.

Jon
Paul J. Miller 6/30/2018 12:26 am
UR is a mature product, little or no development is taking place on it.

Their main concern is with their two other products which are the main earners for the company.

Having said that the search functions of UR are very good and seem stable. They are the model to which other developers should aspire.

If you want to have an effect on the development of a program then you should seek to have an effect on InfoQube which is still under rapid development which means it's trajectory may be altered.


karel 6/30/2018 12:50 am
Thank you for your reassurance about UR's search, Paul :-)
I agree with your opinion about Info Qube's development. I have noticed the author being active on this forum.

Best regards,
Karel
22111 7/1/2018 10:43 pm
@karel

Re Ultra Recall, MyInfo, RightNote

This was several years ago, so I don't remember; I certainly will have given specifics in the UR forum, without them encountering any interest from the developer.

Since you cited me in full: the Mindjet macro tool was/were Gyronix, GyroQ, ResultsManager, and they invited users to run their external macro tool whenever (total, group) work had stopped for some time, some 30 minutes or so, and then that tool, from the outside, not using any API (obviously NOT) made available by MindJet, run thru it all and tried to update it all (i.e. to sync all the de-synched little things within the meantime) - that's what you'd probably call tantalizing. Back to UR:

At the time, I had almost 1 million items in it, and at the time, I was interested in my search problems being resolved - which they weren't -, not in checking if with much less an amount of items, they would possibly not be there anymore, and which might be the case indeed; UR's philosophy is NOT about having several db's concurrently, but to stuff all your material in one monster db, so it should be able to handle it correctly.

As for the sql "laymen user translation", internal processing immensely counts: Since the data, internally, is spread over several tables, in search, i.e. in "select", the sql must do various joins, and/or sub-selects, and there's an infinite way of doing these things, optimization depending on WHICH kind of search you're doing (so a perfect "translator" should try to analyze the search for applying the optimized sql construct to apply to that (probable) kind, and then write the "select" accordingly: sql is about filtering and then ordering sets, which means the data gathering speed greatly depends on where the data to-be-combined is stored in which sub-sets, and even how big those respective lists then are, and how many items you will get from each of those lists from which the sub-sets then are to be combined): all this ideally determines your sql command construction), and there should be some additional indexes just in case (you have to maintain/update all the indexes all the time, even if some of them will just be needed for some kind of search; in the corporate world, the db designers know which kinds of search will be run against the db, PIM designers only can make guesses against/for probabilities).

But these are (in case, considerable) speed problems, whilst with UR, I also encountered problems with left-out items which should have been finds.

Again re speed: All those db's function in a similar way for their hierarchical rendering of data: they use the so-called adjacency list model. For cloning, this works fine, while the path enumeration model is quite cumbersome, but the famous nested sets model is a total nightmare for inserts and moves (and seems to not allow for cloning at all), so it's the adjacency list for almost everyone.

Problem is, tree building with that model becomes quite time-consuming when there's a big tree, and thus, UR clearly has speed problems in general; of course, there are solutions available to that problem but UR doesn't make use of them. On the other hand, except for its search, then (and in the above-described circumstances), it's stable; unfortunately, bolding tree entries is possible but some incredible fuss, whilst on the positive side again, you WILL have a list of "backlinks", with its clones' list, and which is a feature which - rightly so - has been discussed and asked for here in this forum just some days ago.

Except for the inexistant (regular) bolding of tree entries, UR currently is the best offer in those desktop PIMs, MI not only doing clones too badly (see below), but at any occasion I have tried to use it even for some minor, various tasks (i.e. as a lightweight 2-pane outliner just for a list of some 50 or 100 items, from which to select some, according to some criteria), I "succeeded" in crashing it within some minutes, and that on any of my pc's, and also far into its version 6 line, and that, for such a "mature" program, is quite astonishing - I would very much have loved to be able to use it for such minor tasks (since, if it had worked out as expected, it would have been much preferable to the usual (paid or free) SQLite frontends, but not even for such little things, it proved to be stable. And for RN, it doesn't have cloning at all but tries to sell "links" instead.

That is not the same, as you probably know; so I'll cite, further down, my recent bitsdujour comment on RN (just 2 days ago); NO 2 concurrent (content) panes or (tree plus content) panels in RN either, NOR in UR, unfortunately, whilst very well available in MI (just 1 of them editable, but for the majority of use cases, that'll be ok), but what good if the program isn't stable?

When you search "RightNote" in bits, you'll just get their comments including last January; they obviously preferred to silence the new comments from end of June. So here's my commentary from there:

=== RN ON BITS ===
If it's a link, clicking on it would probably take you to the link's target, i.e. would shift the displayed portion of the tree to quite another part of that tree. (Cf. Windows' .lnk files.)

So-called clones, on the other hand, would appear in different contexts, as if they were only listed there, and not also somewhere else, so if you click on those tree items, they just expand (i.e. show their content, and also their so-called child items if there are any), in place. (Cf. Windows' hardlinks.)

A link is technically very simple; the items (since we're speaking of an SQLite db here) have an Id-number which (hopefully) never changes, so the click on the link will just activate the item with that ID, and since you then are in that item's (original and only) context, you even will encounter more or less difficulties to get back to the context from which you activated the link, since in its (as said, original and only) context, that ID probably has no direct backlink to (all) its link(s) targeting to it (cf. UltraRecall's clickable context list for its clones for a "where is this item listed"); here in RN, you would probably need the history in order to get back there.

Additional problems arise when the item in question (i.e. the item in different contexts, or the original and unique item, to which elsewhere you have links to) has child items: In a system using clones, as said above, you click on that item, and it expands, i.e. its child items (of, in case, several hierarchical levels, i.e. another subtree) appear in place.

If you have links instead (as in RN), clicking on that link will always bring you to the item with that specific ID, and which may be the so-called parent item of the one(s), in its subtree, which you really are after, so if you switch forth and back, by activating the link in your context 2 and by activating the history function in the original context, the target context of the link, you then have additional work to do in order to get back to the specific child item in context 1, let alone the specific text position in that child item, which will be lost every time as well.

Since cloning is easy - as is having 2 editable items open at the same time btw, and without any need to save your edits if you switch between them, automatic saving should be done when you switch to some 3rd item, in one of the panels (both could come with a dedicated tree (position), btw), or if you close one of the panels, or upon demand -, once you use a db as the backend for the information manager, it's quite astonishing so many of them come without proper cloning.

In some cases, they offer cloning, but then, if the user makes changes (additions of new items or shifts of items or ) to the subtree (of the cloned item) in one or another context, they don't properly replicate the changes to other contexts (cf. MyInfo, cannot speak about its most recent releases though), which is rather astonishing in view of the fact that for cloning, just the cloned item is to be listed as "child" of different "parents", whilst all its "children" should be gathered "live", whenever they're "needed" (i.e. are to be displayed by the program)*, in whatever context. Of course, with links to a unique target position of that "parent" item, you also avoid such subtree handling problems you might get by a possible weird db setup.

Btw, I find most of the "ideas" how to overcome shortcomings I read about above quite hallucinating.

EDIT: * = To make this perfectly clear: That "cloned" "parent" item has got just ONE ID, not different ones, so all its "children" (of any indentation level / subtree position) refer to their respective "parents" which ultimately, i.e. for the level immediately beneath that "parent" item, refer to that unique ID - which just is registered as child with different "parents", in its turn, so clone management is really simple, and resulting subtree inconsistencies are really hard to implement on purpose. (In the table (ID)-(respective parent(s)), that ID for a cloned item (be it a parent item or not, or be it that it becomes a parent item later on or not, all this doesn't matter at all) just appears several times, in different pairs (always the same ID)-(different parent-item IDs).
=== END OF RN ON BITS ===

So, again, I simply don't know what's the matter with MI; as the citation evokes, even things which, naturally, come without any problem, will get a problem there, and as said there, by leaving out basic db PIM functionality, RN avoids possible problems.

Were it not for the lack of regular tree item bolding (in fact, I never tried if you could assign bolding by some 1-key macro, which might be possible after all), UR is the "winner" here if you leave out IQ which I don't know.

On the other hand, from reading this forum these last years, it's become clear as day that users want to access their data on the road, too, and not only from some Windows slate but from iPads/iPhones and Android devices, and furthermore, even the data on a mobile Windows device would not bring them updated info from their corporation's network / web data storage if they just run some desktop PIM on it, and it's very instructive how much users are willing to give up, functionality-wise, in order to have access to ALL their (i.e. "live") (corporate) data from anywhere, anytime, also including better mail integration than these desktop-by-nature contenders provide;

it's very instructive to see that web applications which otherwise would have been "worth" a mere 30$ for buying, now not only ask for a yearly fee of 100$ for renting them, but that such fees are deemed acceptable by many already.

So at the end of the day within this intermediate time frame, between an age where information gathering was at home and exteriorly (scribbling on paper in the library), but information processing was at home (or in the office, for non-academics), and an age where users ultimatively insist at doing it all wherever they want (very certainly, the availability of academic journals and books by electronic means has accelerated this demand, as a general relief from yesterdays' bookworm fate of academics, not speaking of salesmen here which need immediate access to corporate data indeed), the question is if some user should take the effort of bringing all their material in some another desktop PIM at all, or if it wasn't preferable for them to temporize even further, import, export and re-import of data into something else again not being too easy in the end and more often than not being subject to even partial (and not necessarily easily detected) data loss.

And must I really add that I never ever expected UR to have text-copied and then indexed image (or otherwise "protected") pdf's, or other external documents? (Since hidden from the user, UR duplicates those external files' texts, and then processes them like any other, originally-internal, text, and thus you should reasonably expect any UR-indexed text to appear in your search result if it matches the search, but that's just my opinion.)

/@karel

nathanb 7/2/2018 5:31 am
UR shows backlinks? Maybe I missed that last time I gave it a spin. I shall take another look.

Are you the same cat that was directly comparing Mybase and UR a few days ago as your 'finalists'? Care to share your mybase thoughts?
nathanb 7/2/2018 5:45 am
On UR backlinks:

From www.kinook.com/UltraRecall/Manual

"Notes:

• Internal links are not included in an item's parents as tracked by Ultra Recall."

No but I wish internal links were part part of a target's 'what links to here' section....
22111 7/5/2018 3:25 pm
@karel and whomever it may concern in particular

1) I should have added what I mean by "backlinks" with regards to UR.

As asked for in this forum very recently, "backlinks" are indicators on link targets where the "original position" of the cloned item is displayed. Such a concept implies that there IS such an "original position", as in the NTFS file system, with .lnk files or symlinks, or in my 1996 PIM; the benefit of such a concept being that it's easy then to produce some "output" tree, e.g. for printing, or for export of your material, the "tree building" then only following your "original positions", not "secondary positions": the probable "recursion problem" in this scenario being avoided, and, indeed, in the ontological, primary body of your material, everything (!) should have such a "natural position", and also find it indeed, since at the end of the day, any automobile assurance is, and stays to be, an insurance, the "our automobiles" position just being a secondary, a "functional", but not an ontological one, hence the conceptual mistake in publications like Steinbrecher/Müll-Schnurr: "Prozessorientierte Ablage" (something like "process/project oriented filing"), one piece of material being very probably useful/needed in multiple (project, "case", "client's", whatever) "contexts" (... the notion of "contexts" having unfortunately been blurred by David Allen now).

On the other hand - read again what I wrote above, about the technical implementation of "clones" there, and which are NOT to be compared to NTFS symlinks but to NTFS hardlinks -, the usual PIMs like UR, IQ* or others do NOT use that concept of a "ONE biological parent (in fact, fathers OR mothers but not both)" vs. then "MULTIPLE legal, adoptive, natural, whatever you call them, additional also-so-called "parents" (as before)" but treat all occurrences of one (parent-or-not-(yet)) item as equal "originals".

* = I said I don't know IQ but can say this anyway since its developer said, in this forum, that he isn't concerned with recursion, so I know IQ treats "clones" the usual PIM way. This being said, I'm aware of the fact that JUST the "natural progeny line" isn't the ideal output solution whenever, in some "project" or other individual "process(ing)", you're trying to gather everything which is pertinent to that "case" (or other) in particular, hence the need for establishing "project/case"-specific "natural" hierarchies (i.e. "trees", if you prefer), too, but technically-wise, that's just another db table, including different "weight" or other attributes for the "same" "original" "items" in different "contexts", including, furthermore, different sub-foldering in them, not every "context" (i.e. case, project, whatever you name it) needing the complete offspring of its, co-, generators. (If that's been too abstract, I'm speaking of pre-selections in "cloned" sub-trees, and even of alternative sub-sub-trees according to respective "context".)

Back to UR: As implied by which precedes, it's obvious that PIMs like UR can NOT have "backlinks" since they just have multiple, equal "occurrences", BUT UR comes with a field (I don't remember its name) listing the other occurrences of the item in question, within that same db, and that's really useful since within the entries "also used in" you will (hopefully) also discern the (above-explained) "natural/biological" position of the current item, within the list of its "also used in xyz context" entries; as explained above, those two groups "1-only to possibly-multiple" cannot be visually distinguished by UR since all those occurrences are equal, just as NTFS hardlinks.

2) The bitsdujour "RightNote" link http://www.bitsdujour.com/software/rightnote just gives the history of Q&A up to January, 2018, and then lists 2 irrelevant posts from that RN sale just days ago I've been speaking of above: "Fred User Maybe this has already been asked and answered. Does this work on Mac or iPad? Sunday at 9:11pm Copy Link Like 0 - Rael Bauer HI Fred: No. It is Windows only."

Thus, not only my citation from above was quickly censored by "bits", but they also binned all of those questions and answers - "ideas" (mentioned above) - which RN users dumbly offered in order to overcome the "inexistant second content pane" problem (mentioned above), and to which - rolled out into some a dozen or so "dialogs" forth and back - my citation above was the "final answer" if you allow for that preposterous term.

Considering that "bits", except for insulting content, ONLY censors - and then with no limits indeed - upon request by the software developer in question, you are free to assume that RN's developer HAD HAD CENSORED almost the whole "thread" of his June, 2018, "bits" half-price offering, incl. around 20 or so tries of "innocent people" just helping other users out of the shortcomings of his inferior software.

It's all up to you of course if you now ever even TOUCH the PIM of such a developer, which I would certainly not do even for that reason alone.

Btw, and considering all I've advanced upon the really easy technical implementation of a "cloning" function in a db-driven (!) PIM, be it hard- or then, preferably, symlink-like, offering a db-driven PIM in 2018 without such a function, and ditto (and ditto for the simplicity of implementation) for a missing second content pane... well, that's just missing the slightest respect for your paying customers, as well as seen by RN's "bits" censoring orgy, having binned around 20 or more well-intended (whilst really naïve) "ideas" of paying customers trying to get more customers for the software they use, but well, once you're in some such software, getting (your material) out isn't that easy then, right? And so you're necessarily interested in that tool surviving the next years you'll need it beyond Windows updates, right?

And btw, very smart move of UR of which version 4 didn't survive transition to Windows 10, so existing users who didn't wish to abandon that tool altogether were forced to update to version 5 for that feature alone, and well, there weren't that much other new features indeed... from all what I know, UR was the only piece of software that didn't transition from 7 to 10 at all: you really know some other? And of course, any developer can introduce an artificial halt to their software functioning between 10.0.17134 Build 17134 (the allegedly current one) to any 10.0.18something or whatever them pleases...

/@karel and whomever it may concern in particular

P.S.: My last post here is from around 3 years ago, as 22111, and was met by the majority's wish I'd be to be silenced. Hence, third party's allegations implying otherwise would appear as erroneous.

Jon Polish 7/6/2018 1:42 pm
Karel:

If you are still considering UR, by now I am sure you are confused. Based on what you stated and asked I would encourage you to go with UR. It is a good, solid and comprehensive solution that manages searches well (see my previous comments on UR's search capabilities).

Good luck and have fun.

Jon
karel 7/9/2018 9:04 pm
Thank you all for writing, sorry for not replying, busy. Will get back to the forum later this week. Thank you :)
K