View Single Post
  #7  
Old 11-09-2012, 11:28 AM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
Allow for some more musings about UltraRecall and the competition.

I

a)

One aspect is, UR allows for "putting all your stuff into one main applic, or reference it from there", which means, you search for pdf's and such - but which stay external instead of blowing up your UR database endlessly - from within UR, which means, from exactly that context within your UR "tree" where those external file "belong", let's call this "from their most natural context" - it's all about "having your stuff grouped together", of course, the basic problem of any IM.

b)

The other alternative has been described by me here, working from the file system, and having your "trees" there, as well as your "external" stuff; you group your stuff within your folder / subfolder system, including your "working machine" prime applic, and you'll have (an) external search tool(s) in order to find things, in your "external" stuff (pdf, Word, Excel, MindManager files, whatever), as well as in the files - multiple here, not one big one - of your main applic.

The disadvantage here is that your external search tools don't give you your search results fine-grained to the "item" as do the internal search facilities within alternative a, which can be cumbersome. On the other hand, with my current inferior main applic AO, I get, from one external (and free) search tool any search item within its respective context, even with accented characters (if I bother to input them in the 4 special chars form that the tool demands for such special chars - a little bit ridiculous but can be automated by a tiny AHK scriipt), and there are even two file managers (both German, both paid, both I own anyway) that allow for finding search terms with special chars by entering them the strict normal way (but they only give the file name, not the context). The first-mentioned special tool even allows for Boolean search (limited in the free version, anything you like in the paid version).

The same facts apply for external searching within UR files, but of course, here you don't need external search tools except for searching different UR files at the same time, but given that UR searches are index-driven, you better employ an AHK script for doing consecutive internal UR searches within your different UR files, instead of waiting a minute or so for the results of your external tools. So, the instant-avalability of your UR search results is another advantage of a system like UR over an IM file system set-up relying on external search tools that often don't deliver immediate search results for the special files of your main applic - for your "external" files like pdf, Excel, etc., the problem is much lesser since the standard (indexing) search tools index these files with no problems.

c)

Within both above-mentioned systems - reference your external files within your main applic or cut up even your main applic into multiple files -, you'll get problem where to store the external files, i.e. all in one big folder, or fine-grained within a folder-substructure, perhaps with several levels of subordination. The "one big folder" quickly becomes un-manageable from itself, and any occurence of not immediate referencing of such a file within your main application will result in a more or less "LOST" such file, i.e. accessible, by chance, by searching, but not accessible anymore by taxonomic means, i.e. by browsing a file structure or by browsing the corresponding context within your main applic.

d)

So many users, at some time, get away from the "one big folder" for external / referenced files, and try to double a structure of subordination within their main applic (big outliner file or multiple outliner files) AND in their file system. Both solutions amount to almost incredible sync problems, since in your main applic, you always shuffle around things, and rightly so, it's MEANT FOR BEING PLASTIC, that's why it enhances your thinking.

Thus, I don't have to tell you that any 1.1 doubling effort between your "storage machine" and your file structure for referenced files is bound to fail within minutes, if you ever try to establish such a duplicity, and any effort in trying to automate this is bound to fail, too, not for technical reasons, i.e. because your scripting capabilities perhaps are stretched to their limits, but for the simple reason that even if you try to sync these structures, more or less automatized, you won't overcome the problem that your external files, most of the time, will span MORE than just one fine-grained item / group of items within your main applic - because these external files are RESULTS of your work, so automatically spanning several such "think / detail / material" clusters in your main applic = "work machine", or because they are IMPORTS, and of course, the respective authors of these had thought and written in other contexts and context clusters, as you do, within your "writing machine".

e)

Thus, do NOT try do store such external files in multiple instances in order to overcome the problem detailed above, since having TEN OR MORE such .lnk files or whatever (the Windows system offering more than one technical solutions to the cloning problem) of an external file would be as mad, as having 10 or so clones of an item of a subtree within your main applic (the seemingly ONLY exception to this statement would be to clone specific subtrees of legal material or previous projects, to NEW "cases" or projects, in order to serve as a a QUARRY there, within your main applic, and your external files, but even then, you would not use clones, but COPIES!). And as for the synching of external files or clones or copies of them whenever you move an item or regroup a bunch of items within your "workspace", don't even think of it: Technically, of course, all this would be possible, but it would take 90 p.c. of your time to sync your things, there wouldn't be any time left in order to PRODUCE, or even to gather, some material.

From this point of view, it's simply dumb to ask for better means of synching on a fine-grained level, and the solution lies within manual synching, but on an intermediate level, and to have indicators there which say, "attention, if you move this, have a look into the respective file folder structure".

...
Reply With Quote