Is it possible to do proper outlining?

[Nobodo]

I see a lot of talk here about ActionOutline, and how it is a near perfect outlining tool.

What is it that ActionOutline does that RightNote does not do as well if not better?

I have a license for RightNote and use it for a lot of outlining tasks. At one point I compared it to ActionOutline and really didn't see anything that AO did better or easier. With both of them it is extremely easy to work in the tree, creating and modifying an outline quickly by just using a keyboard. When you look beyond that simple functionality, RN seems leagues beyond AO in functionality and on top of that it is cheaper.

What is the advantage of AO over RN, in 3000 words or less?

Thanks,
Mark.

[schferk]

UR 5's out, congratulations. It's a major release, wow.

ActionOutline is a quite inferior outliner, does not do a lot of things, a**h*** factor is 100 p.c. - no response to customers' questions (be them mine or third party ones') - didn't check if they are Russians in GB or just Russians in Russia, with a GB p.o. box... and it's overpriced, yep.

Thing is, it's leightweight, it's neat (as soon as you hide every one of the multiple toolbars), and it's got some fine ideas; doing 200 or more headings / subheadings (= items) with ActionOutline for a rather short paper will be a matter of (ok, 3-digit) minutes.

I said it, each item is ONE KEY ONLY if you want it that way (plus the chars forming the title itself), i.e. you do NOT press "enter" for "new sibling" (cf. UR - outrageaous), then type the title, then press "enter" again to close the title, then press "enter" anew, to enter the next title, and so on, but you press "enter" just for the very first title in a row, then, between any more items (of the same indentation), you just press DownArrow.

OK, "Dn" isn't handy for a key when you type lots of text, but then, as said, I do heavy scripting, so when in the tree, my # key = between my abc keys and the "enter" key, does "Dn"; when in the text (= editor pane), the same key does... no, not "#", but a $ sign - in fact, I'm writing on, physically, German keyboard layout, with Swiss-French key sw layout.

Commercially available macro tools normally do not offer such "deep scope", but with script tools, you can delve into control identification, not being stopped at window identification, hence my use of a lot of different assignments for the same keys, not only in different programs, but depending on the very pane that has focus at any given moment.

UR users could do the same, for spectacular benefit, and also, they could take full advantage of version 5's 200 favorites (= which would give you, at your request, 200 separate trees within your very big tree (=big db) - just script an additional menu to access any one of them by 2 to 3 key pressings (key 1 = open menu, key 2 = either open an important subtree = "simili-file", or open a sub-menu, key 3 in this case, open a file within that sub-menu).

Many of my "macros" don't do anything but cover up the multiple voids in ActionOutline's functionality, but e.g., as soon as you'll be willing to accept a conglomerate of different bits on your screen, instead of (missing) in-built functions of your main prog, it's easy to have multiple menus on-the-fly, additional panes for history (script tools can "read" the current file name from captions, write them into arrays...), etc.

Thus, my very special ActionOutline version is a dream for text editing, items being "sorted" half-automatically (i.e. the current item is selected of course, 1 key will bring an input dialog, in this I will enter 1 or 2 (or even 3) characters, after 2 sec, the input dialog will close (= which will save me pressing the "enter" key, so for most moves, I just have to press 2 keys only), and then that (very tiny) script will put the selected item under the heading identified by my 1-2-3 characters I've just entered... and will collapse the corresponding subtree, before reverting focus to the item under the one I've just moved.

For "clearing" your daily input, such a half-automatic processing is absolutely necessary since how would you find the time to process 100, 200 or more new items coming into your system each day? So my system is "processing items into cascading inboxes", whilst in a big db system like UR (= different from my 500-plus different files system), you could even try to build up a system that shuffles your input directly into the "final" inboxes, i.e. into the respective ones of 200 inboxes, each of your 200 sub-trees having its own.

And back to editing: Similar macros do half-automatic processing of bits of texts, into other items, with or without automatic add-on of "signatures" - just imagine big, external (= third-party) texts from which you'll have to cite, or that serve your purpose of plundering them, for building up your own texts, let's say "secured" pdf's.

You de-secure them (there are web-services for that), you put them into one big item, and then, you select passages, press a key, get a dialog, enter some 1-2-3 characters there, and have those passages moved (or just copied, with or without an automatic process note there, for your helping in remembering that you stole that passage already, when you next pillage that text)... to (the end of the text of) any of some 2 or 3 dozen of "receptive items" / "recipients" (as said, with or without credentials for their common source).

And so on ad infinitum, whatever you like, whatever will make you avoid heavy arrow key use (which would also imply moving focus from text to tree first, then arrow keys, then reverting to text there for doing the insert, then going back to tree, the arrow keys again, and going back to text pane and to where you had been there, finally), let alone mouse strain (in fact, I could script the same for drag'n'drop, but I avoid mouse use whenever possible: I'm a WordStar man).

Thus, you must understand that I'd never pretend ActionOutline were a "good" outliner in itself, it's just the (neat) text processing shell, in which the real "work" is done by various scripts of various length (including, e.g., the use of various text expander libraries, the same abbreviations triggering different words within different contexts (languages and there, subject) - again, it's scope, but in macro and micro variety, as above).

Any other "primitive" outliner would do for me, as ActionOutline does for the moment, and it's important that it doesn't come into my way, that it doesn't hinder my scripts in any way. Cf. UR: That waiting, about 2 to 4 seconds (and much longer, for really big items), after leaving a UR item after having changed just a bloody comma within it, would outrageously slow down my "distribution" macro (= seconds' wait after cutting in item 1, then again wait on leaving item 2, after having copied / inserted there, before focus could revert to item 1), as it has slowed down my manual editing work with UR last year, whilst in ActionOutline, or in any other "editor" allowing for just leaving an item, a file, a chapter, whatever, then for re-entering it, or entering any other, having done some editing or not, you are able to do slick editing work indeed (be it by macros or by hand).

Of course, my "scripting overlay on rudimentary sw" presents the disadvantage of lesser looks: I'd have much preferred to have in-built functionality in any such outliner, instead of looking on a "heavily working screen", and that's why I tried - in vain - to educate (yes, sorry, that's what it was) the people behind askSam, then MyInfo, then UltraRecall, in (real, not only graphic-wise) GUI optimization, and I shared some ideas with some outliner software customers in their dedicated forum.

Since most programmers do their thing, though - a paramount example is MS who with multi-billions of dollars don't do anything good; please have a look into the article AND the comments at

http://wanderingstan.com/2008-02-01/..._outlook_sucks

I'll never have anything worthwile if I continue to beg and to explain, for better - but unfruitful - begging, hence my renewed interest in ActionOutline, not for its (missing) "strengths", but for it total unintrusiveness with what I'm going to do.

[schferk]

So it's a good thing to explain here that my scripting approach has TWO elements, one, explained before, being the making available of a file superstructure, i.e. providing that "super-tree" kinook has refused here a year ago or so - again, UR, now much better indeed with 200 favorites, should at the very least consider to leave the original tree unchanged, in tab 1, whenever you display / expand sub-trees (= displayed "hoisted", and the parents of which are "favorites") in other tabs: That would make a BIG step in the right direction.

And element two being the choice of a rather shallow outliner, just what's available on the market, even from Russians who's responsiveness is "less than zero", but ActionOutline letting me "script on it where I need it", without it interfering with my scripting work.

In fact, ActionOutline has so little inherent quality on its own, except for the fact that it's perfectly insignificant and unintrusive - but which is a quality in itself, in some contexts - that some day, I might again rebuilt another outliner, not with MS Allen's stuff again, but from components: a tree component, which will also provide for many additional list panes (remember I currently use a file manager as one of these, and which is in fact the real heart or brain of my system), a text editor, a menu component... and scripting, in-between.

But when I say, unintrusive, well, ActionOutline does NOT allow for "full row select", whilst UltraRecall does. What's the difference? As explained elsewhere, in my own outliner, late Nineties, mouse clicks and mouse right clicks acted differently, depending on the horizontal position the mouse was clicked within any list, my program calculating these positions in percentages of the current full width of that given list / pane: first 20 p.c., last 15 p.c., and all the middle space.

If you never had the chance to trial such a system, you'd be afraid, oh, what's when I click on the border 20/21 p.c., or on the 84/85 p.c. limit? First, the programmer can leave some per cent without reaction, triggering functions from 1 to 15, from 25 to 80, from 90 to 100, but that's not even necessary: The user will only click, within the first part, around 10 p.c., for the last part, around 95 p.c., and for the "normal" commands, in a large part around the centre.

But it's even possible - I tried, and it worked smoothly - to cut the line in four parts, instead of three : near the beginning, near the end, first half, second half. All this, with ActionOutline, where you must click within the text of an item to make it react, is not possible, so I'll have to use weird devious means in order to do the same here (virtual grid overlay, i.e. your script measuring the control's current width, then calculating your click's percentage point, then sending the command you want to trigger (but must read the list's entry, without triggering the "normal" command there - but then, I'm not so mouse-centered anymore as I had been in my time...).

You see, ActionOutline isn't but a dummy for me. As a standalone applic, it's worthless in my opinion, as is any other such rudimentary outliner on the market.

On the other hand, with programs like UltraRecall, most of highly valuable work has already been done, and just SOME more efforts would be needed to make them really outstanding and highly useful suddenly, but these additional efforts ain't applied since the market wouldn't honor them.

Or so their developers think, falsely extrapolating from the only relative success of half-baked simili-solutions to "predictable" fails of real ones.

Back to ActionOutline and other lightweight / basic outliners. As said, I'm approaching my 600 files, heavily sorted / grouped / cloned within projects and other referential material's bunches. It's in THIS fact you must seek for the core part of my concept.

Because, after having made a 20 years' voyage thru outlining in every which kind, including writing one of the very finest outliners of its time then, conceptually-wise, I've come finally back to that concept 99 (?) p.c. of all pc users apply: The concept of separate files, grouped then (hopefully) into various contexts (I know that for most people, that's a flat file tree, without clones, hence their interest in tagging utilities for complicating things - for them, these tag tools rather "sort things out" then).

[schferk]

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.

[schferk]

Let me try:

[schferk]

And yes, my shallow dummy ITEMS system to do separator lines within flat outline hierarchies, and my shallow dummy FILES system to introduce separator lines into any file system (= grouping on the deepest level of your file system, instead of having "too long lists there" or making some further hierarchy level), displayed by any file commander of your choice, can perfectly be extended to shallow dummy FOLDERS, suddenly grouping, same-level, all your relevant folders on any higher / intermediate level (by this sparing you many such intermediate folder levels) in your file system in general. Just avoid scrolling, i.e. introduce intermediate folder levels whenever your lists get really too voluminous, but for 30, 40 folders, just as for 30, 40 files within a folder, grouping them by smart naming AND by divider lines, is the way to go.

(Let me clarify: When I say, "displayed by any file commander of your choice", I'm not speaking of divider lines in the comment attribute of such folders and files, since most file commanders ain't able to display that attribute. On the other hand, you can easily give smart NAMES to such dummy folders / files (as you would do to such dummy items, within your outliner), e.g. real folders abblahblah, bablahblahblah, and, in-between, a dummy folder named abz---------- for separating them, and such a system is universally applyable indeed.)

Hold it flat, but hold it clearly arranged at the same time. That applies to items, to files, and to folders, hence smart naming and separator lines in every one of these three cascading systems. You'll search a lot less then, and you'll think better than you thought in the past: It's really all about mental representation of originally "too much stuff", which, when ordered as flat as posssible / reasonable, will suddenly become much more "available" to your thinking, to your consideration, than it had been before - which is the secret behind my flat-hierarchy system. "Design" at its best is for a purpose, then.

[schferk]

Sorry, I left out an important point: It's not only macro scope (applic / window identification) and micro scope (control / pane identification), but of course, you can - as I do - use global variables in order to identify task context. Thus, it's possible to have e.g. 3 neighboring keys (e.g. Num1/2/3) trigger some related commands within a certain "job" you do repeatedly, and when finished, you toggle that variable to its default state = to its normal behavior (= in our example, Num1/2/3 would again trigger the numbers 1/2/3, and with the same keys (= which should be very accessible on the keyboard (I said it before, ergonomics is everything in computing), i.e. Num 1/2/3, Num0, Num Del, or even the arrow keys if not needed within that special task context), and you can do a pop-up menu with 3 or 4 such different contexts = variable values, on top of the default value = default behavior, for that same key group. And in order to know what's the current state of such key groups or single keys, you could have a little color bits, overlayed on the caption bar of your main window. The same goes for different expander assignments: Overlayed upon your main caption bar (= right side, just left of the minimize/maximize/close buttons) could appear little characters like "DL" for "German Legal" or "FG" for "French General" - or nothing when your expander value is zero for "no expansion".

Another thing: I said it, other files (e.g. .xls, .mindmanger, etc., or even .doc files to be exchanged with third parties of for printing purposes) than those of your main applic (in my case, .ao) could easily be integrated into such a system. In my opinion, this would NOT be a good idea for "external files", i.e. all these things you collect from external sources. So what to do with those? I did this: In my d: drive, there's the folder 1 for MY files, i.e. it's about 600 times d:\1\xyz.ao, and some other. I then replicated my FILE structure (explained above) into a corresponding FOLDER structure, within a general folder d:\2\, i.e. in that "2" folder, many times bigger than the "1" folder in DHH space, there are sub-folders named A, B, C...Z, replicating my A, B, C...Z stuff within the "1" folder, in theory (and within a corporate environment).

In practice, I did away with the "2" thing, but simply replicated my A...Z as first-level folders, i.e. I really have d:\1\, and then d:\A\ ... d:\Z\.

Within those, I EXACTLY replicated the FILE structure of the corresponding character as a FOLDER structure, i.e. my "d:1\K.." super-group has got 13 (.ao) FILES, thus my d:\K\ has got 13 FOLDERS, named exactly as the 13 .ao files within d:1\K.. files range (remember I said that within a corporate environment, those "K..." files within d:\1\ would be within a real folder "K" there, whereas I alone can perfectly manage 600 or 1,200 files within only one flat folder "1", without the need of real sub-folders here): Thus, my super-groups in "1" become folders, and my (.ao) files become sub-folders. (Whilst additional .pdf or other files within "1" do NOT correspond to their own sub-folder within those folders, of course.)

Why? Remember, my .ao files are CONTAINERS, for all sort of homogeneous material, e.g. koc.ao for my notes (or imported clips of external notes, with their references) on clipboard managers and memory tools. Then, there will perhaps be some 20 or 25 such clipboard managers = .exe files I'll have downloaded. Thus, I need a corresponding container for all these .exe files (and perhaps some .pdf files for downloaded manuals, or even some .htm files for downloaded web pages when those were too complicated to be downloaded bit by bit into .ao items - downloadings bits of texts, .jpg's and tables = partial screenshots in .png format ain't indicated but when those ain't too many single bits, and if the work implied is worthwile, for a subject matter that's important to you).

Now, you can easily do a script that creates such a corresponding sub-folder anytime you create a new outline, or, within UltraRecall, a new "principal sub-tree"; this goes even for renaming or moving such a new outline / "principal sub-tree" (well, that would be a little bit more complicated). And, much more important, you could create a script that for any proceedings within your outlining structure (be them separate outlines as in my case or a "whole big one" as in UltraRecall), would display the corresponding sub-folder to any .ao file or UR-principal-sub-tree/"favorite" within a second pane of the same file manager that displays your current outline files already (besides a self-contained system as is UR, you'd need an additional pane (= refused by kinook last year, but I wouldn't predict their future stance on it, once they get the the ideas behind such a system: as said, the very first such self-contained system on the market, WITH integrated super-structure, would ROAR (winner takes it all, they say)), by script tool, and just one pane within your file manager, precisely to display the correponding sub-folder within the corresponding "related" folder there (i.e. not "d:\1" but e.g. "d:\K\S\").

Yes, I've read your rumblings about UltraRecall 5, here and in the outliner customers forum, and to my great amusement if I dare say. Well, I've been silenced there (= collective stoning, Iran's everywhere), for not being concise enough, but then, have a look at the very first line of my June contribs here: weren't I concise enough: wouldn't you say you just repeated in many more words what I was first to say? (Or could my irony there have been lost on some of yours again?!)

Whatever, they discuss "integration of file M into their respective outliners" - oh boy! YEARS ago, I did some trying in that direction, and indeed, having just ONE system, for your notes / clips, AND for your files (what about mails, then, makes it three systems, as things are today...), would seem a real fine offering. But then, I've got dozens of thousands of such files (and which is the reason the description of my file system above, when not purely theoretical anymore, is a little bit "should be like this", but cannot pretend it's in its final and optimal state yet), and even if your outliner offers any automatism to "import" these myriads of files (which is not the case anywhere today, to my knowledge), how would you ever be able to LEAVE such a system (in case developing staff is "hit by a bus", as people are (or pretend to be) afraid everywhere, and not speaking of wanting to leave for any other reason, and there might be some).

Thus, my stance is, do replication of systems as described above, do as much automating as possible for replication / synching, but don't try to over-integrate: On any screen broader than 1280x1024, you easily can display your items' list, your text / contents field / pane (which when too broad will make text unreadable anyway), your "siblings pane" (= your super-group, cf. the screenshot above; be it a pane within your outliner (as it should be in UR) or a pane of your file manager (as in my case) - up to here no problem with a 1280x1024 scree either -, and then, a second pane showing the list of external files, corresponding to your current outline.

Attentive readers will have noted that my white paper isn't coherent in one respect, and indeed, I'd said, hold it flat, do super-groups divided by separator lines, instead of multiplication of folders / subfolders, and now I say, do a corresponding sub-folder for external stuff, for any outline in your outline system or "favorite" (= corresponding to such a separate outline) in UR. As you will have recognized, I do my thinking partly in writing, and hence my correction above. Yes, my advice goes perfectly for your "thinking stuff", i.e. for your outlined things: I've trialled my own system for some 6 months or more now, and it works "like a charm", as they say. But for external stuff, my idea to divide long lists of files (= super-groups) into groups, by divider lines, holding perfectly, and my idea to do the same with long lists of folders holding also (and coming handy for various occasions), I must recognize that for external stuff, a system with lots of subfolders is the way to go.

Just make them correspond to your outline: 1 subfolder, 1 outline (or in UR, "principal sub-tree") = on that deepest, that core level of your folder system. It's on the intermediate level that you will AUTOMATICALLY adopt a flattened-out structure for your folders if you apply my system "1 key (= d:\1\A...Z\ and d:\A\ ... d:\Z\) 1 folder" and "1 outline (= d:\1\kxyz.ao) 1 folder" since this leaves you with super-groups on the intermediate level: super-groups of files within "d:\1", and super-groups of folders (= instead of two or more intermediate LEVELS of folders!) within a "d:\K\HereSuperGroupOfFoldersOfTheDeepestLevelOnly ".

So, I needed to straighten these things out for myself, at the same time clarifying my in such incoherent explanations. Now, we can proceed with replication and synching of our external stuff, according to our internal materials, "flattening it out in the middle", but on before the deepest level, when there's an outline, there'll be a corresponding sub-folder, and within that sub-folder, flatten it out again, just as in your multiple outlines (be they technically separated or just "favorites" in UltraRecall).

(BTW, I do a daily backup of my d:\1\ folder, a weekly backup of my d:\ drive, and a monthly backup / reinstall of my c:\ drive, but that's another subject not belonging here.)