View Single Post
  #25  
Old 06-09-2012, 05:22 PM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
But you see, I didn't went back the whole way, I didn't went back to a word processor. The "real thing" in my concept is that I don't use text files, don't use an outliner "to put all in" (anymore), but

USE OUTLINES AS TEXT FILES

i.e. I use multiple, myriads of outlines the exact (optimized) way people would use their multiple and myriads of MS Word files: I simply exchanged the text file concept by a BETTER TEXTFILE concept.

I'll give a real world example. My "K" series is "keyboard, input, etc." (since I don't need all 26 abc chars for different base subjects, I can cut my "C" (computer) subjects into several ranges). k.ao is the base file, input box, various things here. ke(always .ao) is KB (Keyboard, etc.) Expanders, kh is KB Hot Keyboard (a macro program I used before I scripted my things), then there is kk for Keypads (except Preh) and kkp (right, KB Keypads - Preh!). Then, kl = KB Layouts, Keboard, etc., incl. remapping, whilst other macro tools are in k - I see here that up to this time, I've failed to make a dedicated file for them: Should be km (current km becoming kom for KB Other - Mice) for KB Macro Tools, and kh becoming kmh. Then comes a divider line (named klz in order to be automatically be put here). Then, we have km = Mice, and ko = OCR / Scan, koc = KB Other - Clipboard, Memory, then kod = KB Other - Dictating (all sw and hardware mixed up, since separation of these would not make sense). Again, a divider line (= kpz). Then, ksa, ksi and ksw for KB Scripting - AHK, AutoIt, WinTask. And finally, a divider line (kzz), in order to have a divider line between my "K's" and my "L's" (yes, that's all for Lib = books) even when I have a global look on all my files from a to z.

As said before, other (than .ao) files could be integrated in such a system, and sub-folders could be integrated also. Where's the interest of such a file system, with multiple outlines replacing ordinary text files? Let's have a look at the ksa, ksi, ksw range. ksa has got more than 140 items, ksi has got more than 270 items, and ksw has got more than 400 items. (And yes, there isn't any ks file at this moment, so some 3 or 5 items for scripting in general or other scripting tools are in the k file; remember, at any given time, my 13-item (plus 3 divider lines) file list is before my eyes when working within ActionOutline on the subject of computer input.)

Now let's imagine I have my ksa, ksi or ksw stuff in ksa.doc, ksi.doc, ksw.doc: YOU SEE? 400 pages in an MS Word file, with illustrations on top of it? STRAIGHT CHAOS, and just in the tiny subject KB Scripting WinTask.

So you see, that'd be outrageous.

What can I do? Cut up KB Scripting WinTask into about 10 different files, kswa, kswb, kswx, etc.?

Again, that'd be outrageous.

And worse, too much cutting-up here would invariably lead to not knowing anymore where did I put this detail or that?

That's why I preach "make it self-contained, whatever its size": It's not for some philosophic reason, it's just in order to avoid searching!

I need kkp (KB Keypads, etc. - Preh) often, so I cut it out of kk, and kk is called "KB Keypads, etc. (sf. Preh)" (that's French for "except for") - remember I've got these comments before my eyes at any given moment, and from a list of 13 entries (plus 3 divider lines), I can choose without any problem, no need here to do subfolders and all their handling fuss (and their problem that you must open them in order to see what's in them) - just GROUP things, but separate them with divider lines - AVOID unnecessary SUBORDINATION AT ALL COST. (Btw, I can combine display of two or more such super-groups, e.g. can display my K's, my L's and my B's altogether, and in every which order; this being said, most super groups = leading chars combine many more than just 13 files, hence my breaking up them into more than 26 super groups, modern file systems allowing for European chars within (or even as leading chars of) file names.)

Again, 400 items = 400 "chapters" or "pages" or whatever divisions within a single MS Word file, just for my WinTask things? Outrageous, as said.

But within ActionOutline, or within any other simple, basic, rudimentary, primitive outliner, such a 400 item outline, just for one single tool, why not?

I said it before, the degree of internal order within such a file greatly depends on the importance of the subject to me: These scripting things are perfectly neat, with 140, 270 or 400 items (ordered mostly in just up to 3 indentation levels under the root item, mostly only 2), since I regularly need to refer to them. On the other hand, there are 300-item dump outlines where material is together what belongs together, but where I didn't have much time to rearrange things for them being really ordered (= files with 3 or 5 dump items, each containing 100 or so items in order to be ordered when really needed).

Thus, the real value of my system is, I can have hundreds-of-pages text files which are really in order, internally, and without a mountain of work given to that ordering. It's not only the referential value of such documents that is greatly enhanced over corresponding MS Word documents with the same contents, it's also that within an outline, 400 items / "pages" can be ordered (let me estimate roughly) in perhaps a quarter of the time... AND with better results!

Thus, my more or less 600 outlines represent perhaps 4,000 MS Word documents, but within these thousands of .doc files, I'd be completely lost, all the time (just remember the difficulties of not knowing in which of perhaps 10 docs a detail might be, but you must then search 4,000 docs, or select the 10 "possible" docs for searching them - is that technically possible altogether? Yes, you could have naming conventions like mine; yes, you could move them to a special folder, search them there, then move them back -, or have multitudes of false hits, in irrelevant docs, etc., etc.

You see, it would be a false conception to think that I simply replaced docs by outlines: There's no interest in having 4,000 outlines instead of 4,000 MS .doc's. But for such a .doc, there's coming fast a limit where you "see", "it should be cut up, it becomes unmanageable", whilst, at the same time, with an outline, you wouldn't even come NEAR such a psychological limit, and in fact, depending on your subject, you could add much more material to your outline, without it becoming unintelligeable... when 10 or 20 .doc's will have become unmanageable (and be it just BECAUSE of their split-up).

On the other hand, and that's MY great problem with outlines, which I finally didn't escape from but by designing my own system whitepapered here, is that chaos starts the moment you'll put things therein that don't belong there, and the trap is very easy, since, within an outline, even when puttings loads of external things therein, the outline form (if handled expertly) will ensure that chaos will NOT break out there (as would have in a .doc file long ago) - but chaos then will start in your head: Where did I put...?!!!

That's why I pread, make it as long as it gets, but make it self-contained. And that way, you'll easily get to 500 outlines and many more... but when there'd be a mountain of some 5,000 .doc files or many more.

And indeed, multi-file search, for me, has become irrelevant this way, my things are in order, inter-file-wise; it's within the files I must search again and again, but here, search is simple (even when as primitive as in ActionOutline).

Which brings me back to UltraRecall - weren't there things such as multi-file search on the roadmap, for a major release? Anyway:

My advice to UltraRecall users is, have kinook urgently make a single global tree left unchanged by any change you make in neighbour tabs' hoisted trees (representation changes (= partial expands / collapses) within the global tree wouldn't be propagated into hoisted portions of it elsewhere; representation changes there wouldn't affect the curret representation state of the global tree - I know that from the encoder's pov, that's not easy since real changes, both-way, would very well need to be propagated); cut up your material into self-contained sub-trees you hoist in tabs, accessing them from 200 grouped favorites' shortkeys -

and you'll probably have got the best system on the market sf. mine. ;-)


Perhaps an additional note about mnemonics. As this short "K only" example shows, I try to constitute coherent GROUPS within my super groups, and hence the need to often do "weird mnemonics", i.e. I often have to name files, i.e. their subjects, by a less common synonym, or by a denomination within another language (not seen below), or I reshuffle the order of several subjects in the title = file name. In the example here, I "needed" the second "k" for "Keypads", so I put Keyboards not under "kk", but under "kl", doing "Layouts, Keyboards" instead of "Keyboards, Layouts" or just "Keyboards" (my solution here wasn't that incorrect since "kl" contains physical keyboards AND (sw) keyboard layouts). For the same reason, I often insert "unnecessary" intermediate chars; in the current example, look at ksa, ksi, ksw: The second char, "s" for "Scripting", wasn't there in the beginning, but then, the three files, whilst belonging together, were spread over all "K" files, and worse, such splattered files normally do interfere with groups in which they don't belong (in this example, original ka was at beginning, original ki was in the first group into which it didn't belong, and original kw was at the end. So, in order to create homogeneous groups - which are paramount for your mental representation of your material! - I, whilst minimizing keystrokes, am willing anytime to enter additional, intermediate, "unnecessary" chars - that are highly necessary for grouping reasons, though.

Last edited by schferk; 06-09-2012 at 07:40 PM.
Reply With Quote