Is it possible to do proper outlining?

[schferk]

Then, of course, you'll have the problem of list width. In my case, the with of the name attribute of files is just 1 or 2 cm, since I adopted that mnemonic file naming system consisting of 1 to 5 characters only (each character having a mnemonic systematic "virtual subfolders" meaning and with the latest character only to be the first character of the item's / file's " virtual individual title" (= which as such doesn't even exist), plus possible prefixes, but then, if I've got a cloned file "abc.xyz.ao" file, and only the characters "abc.xyz" are visible, very well for me, and even if only the characters "abc.xy" are visible, that's okay with me, since in every instance, within the "comment" attribute, I RESOLVE that cryptic, mnemonic title, and as said, I choose my files from there, except for some standard files I open again and again and whose cryptic names I've since long memorized. Example: File name is cfb.ao, entry within the - rather broad - "comment" field will be the resulution of that code, i.e. "C IM Backup, Recovery, etc." ("C" stands for "Computer" and "IM" stands for "Information Management", since I've got these denominations dozens of times within my system, but other terms are generally resolved in full characters).

Which is to say, an imported, long file name, with a short prefix, will still be a rather long file name, that's not easily squeezed into such 1-2 cm column width! And so, there's two solutions to this problem, mentioned above: Either your system (= natively, or by your own scripting capabilities) will put the "resolution" for the prefix, and then the original file name, into the comment attribute of the file, and by this, at least a good part of the complete file name of your imported file will be readable within the attribute column of your system - or you do TWO such file lists, side by side, the first one being your above-described main file system, and the one farther to the right of your (wide) screen being a "parallel" such file (and folder) system for imported, third-party files.

You could even hold these two bunches of differently treated / displayed files within the same folder / the folder / subfolders system, by filtering, within list one, by your own suffixes (.ao, .xls, etc.), and within list two, by EXLUDING exactly these suffixes of your own files, both lists being sorted alphabetically, but with list 1 having a narrow name column but a large comment column, list 2 having a broad name column and perhaps an invisible comment column (but which you'll need anyway in order to store (but not necessarily to display!) ToDo codes like #, £, the yen sign, or combinations such as £1, £2, #a, #z, or whatever).

Re interaction main program / outlining program and file commander / file management, it should of course be possible to do renaming of an original file that propagates to any clones of it, and renaming of clones that propagate to the original and any other clone, and the same goes for propagation of text changes within the comment field of any such an element, be it the clone, one of several clones or the original; in part, these problems and theirs solutions depend on the kind of your individual cloning technology (which depends both on the outlining program you use, and on the Windows version you rely upon. These problems could be resolved by scripting, instead of manual maintenance, but the main problem (addressable by scripting also if necessary in the end) is to avoid to perpetuate the current need for "having to think about it" any time you do any changes whatsoever to any of your files (and be it just additional cloning, let alone renaming a clone, i.e. the prefix part of it, which should indeed be perfectly devoid of problems but isn't for now).

Off-topic and re physical storage of sentences: Underlying global and double problem is both to assure scalability into spheres of amounts of data comparing to Google's db's, and to finally get rid with that conceptional data storage chaos that at this time every developer solutions in his own, perfectly chaotic way, i.e. up to now, there's no standardized concept for (mainly) text data storage but in most applications, there's the text storage in its "natural way" from your writing, and then there's nothing but superposed on that a second overlayed system for referencing, but only for recencing various parts of these "naturally stored" text chunks, i.e. text is mainly stored in "text files" (of various technical realizations, e.g. record fields within records of a UR db) where various text bits are stored consecutively but which could as "naturally" belong into various / multiple / myriads of other contexts, whilst only some of these are, but then by various forms of referential realizations, also put within some of those possible other contexts (e.g. cloned items, cloned paragraphs, cloned paragraphs / items you later on wish they were just copies not clones (!) or even aggregates of a "cloned part" and an "info part" showing which way the cloning mechanism (by way of changing the original) affects these clones (but which would be used in their original form, besides that information need, etc., etc., and, the other way round, "further developed clones" where the original part would be recognizable but which would allow for variations, and variations not propagated backwards to the original (which is a big risk with UR's clones, by the way).

As a third, again different mechanism, such a heteroclite system is often overlayed by a "real reference" mechanism, for outbound links, or for internal links but to items, whilst the second system described above is only for paragraphs - and so on and on and on, making a chaos for text storage, most texts stored in a physical sequential order as you wrote them, having bits of text in link bodies and whatever, spread out over the whole data heaps. The same often applies to db's storing pictures, pdf's and even other (html or whatever) data into the db itself, instead of just linking to the original files stored within any folder external to the db file, or to special auxiliary folders / db's / parts of the main db in which such a systems stores non-textual data.

Hence the interest of separation, and and for all, of text storage and text presentation, and with today's pc's, there's no need whatsoever anymore to not deciding to store a text chunk presented within an item's text field, and consisting of perhaps 100 sentences, within 100 different records of a monster db, from which your application routine, by reading no text file / text record but a list of (in this example) 100 reference addresses, will restore the connected text: each item record would then contain a bunch of links only, be they to sentences, pictures, jpg's, web addresses, mails (!), or whatever.

Specialists and people a little bit interested in technology will know what delta copying is, and whilst for web synching services (like Dropbox and many more) this dividing of monster files (of perhaps 4 GB) into (perhaps 1,000) chunks (of perhaps 4 MB each) and then copying (and integrating into the target file) of just those parts of the monster files that have been altered in any way, all but one (?) of the "consumer" sync programs (and including the overpriced SyncBack Prof and ViceVersa Prof) do NOT do this delta copying; MS Outlook does create such monster files, these ".pst" files, and many of them get corrupted, here and then, and it's not by coincidence that tools that promise to repair such corrupted .pst files, are sold for (often much) more money than the Outlook program is sold itself (even if you buy it separately from MS "Office"). But then, most experts agree that the MS programming style (cf. Word's outlining function, being so bad it nourished a whole outlining industry) is certainly not to be imitated, so it cannot reasonably be put forward that creating monster files containing data, instead of just reference addresses, is of any value - whereas the sheer multiplication of (possibly as standardized as possible) files is industry standard today and will be there forever.

[schferk]

More details of such an interoperability system Outliner (or whatever) -To-Elaborate File Commander

For the time being, in my system, if I switch between files in and from within my main system (.ao files), the selected entry within the external list (= file commander) is not updated. Of course, there is a macro that will determine the current file name (= in AO), then look it up within the big list there (= file commander), then select that entry, for further processing (in order to then apply, e.g., the corresponding routines for altering the "comment" attribute of this current file, e.g. the general comment edit routine (for manual editing) or for (automatically) inserting a specific ToDo code or for (again automatically!) deleting such a ToDo code, but then, it would of course be much more elegant for the (always visible) file list to have selected the current file (on condition that the current file IS somewhere in that list; if not, at least it would be elegant to de-select any list item that would have been selected before, being the current item then, but not being the current item anymore - remember you can change files within AO (or any other main program you use) itself, by this causing - if there isn't an automated routine intercepting and processing such changes accordingly - de-synchronization (or is it called asynchronization) of the current item in your main program and the selected item in your file commander window. It goes without saying that all such interoperability functionality should be triggered by an extension of such a file commander, even allowing for choosing your own main program at your will.

For the time being, in UR, you cannot (easily) distinguish the "natural" (= original, main) parentage / fathering of a "clone" (= in fact the "original item") from any more (= real) clones of that item, let alone any changing of that status (= sometimes, it could become handy to make the original entry a clone, but mark the clone / one of the clones as the "original"), whilst both in my one-big-file system 15 years ago and in my file-system system today, the original items (then) / files (today) are clearly distinguished from their clones. Since in almost any cases, there is a "natural position" for any item, and then there could be (often multiple) "adoptive positions" for them (e.g., a law disposition, then being cloned into a lot of legal cases, and believe me, it's the same thing for almost every imaginable item / file: As with a child (boy/girl), there's only one real family "from which it comes from", and then, he / she will perhaps marry a few times, have children with several fathers / mothers, i.e. create several new families of its own, and even, in RARE cases, will (in-between, that is) be adopted by another family, it's "original original" family becoming secondary, as will once be these marriage families (hence the need to be able to change a clone into an original, the original becoming (just) a(nother) clone) - whilst UR's NOT doing the difference here will "sometimes" (i.e. rather ofter, in my experience) cause a rebirth of that old "lost in hyperspace" phenomenon; in fact, during the months a used (= did a paying trial of) UR, this not-distinguishing between originals and clones had been the most important factor in my leaving clones out of my working space, after some initial (and rather unfruitful) tries.

If you do as many brackets as I do - oops, that wouldn't be easy to find -, you could try to format those bits in italics, instead of enclosing them in brackets - of course, that wouldn't be possible in posts as this one (but in your own blog, in web site texts, in printed texts, in .pdf's...).

Whilst for every outliner applic appearing on bitsdujour, there's invariably the question, can it search imported pdf files?, on that all-encompassing outlinerthing.com, people currently relate their problems with pdf annotations / comments / pdf text passage yellow highlightings (if you want to check out, the search term would be "docear"), and that's simply another bit of proof (if any such was considered necessary) that all these concepts to import external files into an outliner software (and make 'em searchable or not, afterwards), is the bad approach, and I insist on my (ultimate but not necessarily to be realized today or tomorrow) concept of clearing your main applic from ALL possible content (including even text contents, that is): Specialized applics for processing different file formats, but the very best possible applics then, and with perfect integration, please!

With import of web pages, it's exactly the same thing: It's not the (sometimes slow, sometimes buggy) import of web pages into UR that would be a problem, but trying to import web pages altogether, in the very first place, that should be subject to discussion! (And it's not I trying to develuate UR here: In many a forum in the www people relate their dissatisfaction with UR's web pages capabilities and sometimes even say that this is their reason for not doing their stuff within UR (anymore): It's evident that they've left or avoid UR for very bad reasons.)

As stated before and elsewhere, I only import text passages (in plain text) from web pages (but often I format the most important parts of these excerpts in bold, afterwards, in my target prog), and some pictures only (i.e. containing graphs / numbers), and tables (= as rectangle (= not full screen but minimal) screen captures, as I import Adobe Flash texts or other bits I cannot import as text / graphics). As for pdf's, I download them as they are, then import important passages into my main prog (and, in case of need, do some de-securizing of these, and if they are really scrambled, I revert to screen captures of important passages, again) - it's all about standardization of content, as it is for everybody else, and importing whole web pages, with or without ad / Flash blockers applied, is certainly not the best way to do things if you want to avoid clutter (both in your electronic staff as well's in your head) to a max in further processing (of any sort) of any imported material. (And for forensic use, importing web pages into UR or any other outliner isn't the best way to hedge your interests either.)

(Fellow forum contributors suspecting me of cluttering this thread with off-topic material should be aware that there's Google out there, referencing anything, and producing a helluva of hits to this forum, and I insist upon stating that if I consider UR not good enough for me, I truly consider it the best current self-contained (!) outliner out for the moment, even if I'm quite unhappy with the factual unresponsiveness of its developers. Yes, I truly believe that if even minor outliners can buy / rent a third-party component as their editor, UR / kinook should NOT rely on the gratis MS piece of sh**, and without its users having to do a collection to pay for such a decent editor, but then, within UR you can do a lot of things you wouldn't be able to do with lesser contenders, and they are legion. (This last paragraph was written in order to hopefully prevent censorship again.)

[schferk]

Integration with Search / Tag Tools, etc.

Problem with tag tools is they all (= all of them I know that is, but I searched fervently) have their own proprietary tagging system, no integration with file commanders, and especially make no use of the Windows system's comment attribute for storing tags (which technically would be perfectly possible, and then, the (very big) interest of the tag tool could be that it would standardize the processed of attributing, finding / filtering by, renaming of and any other processing of these tags. If they used that comment attribute, even integration with file commanders would not be necessary, since the tool itself would display such comment elements (and hopefully would let you filter by several of them at the same time, and furthermore, by Boolean search).

As it is, they use their proprietary databases for tagging, which is unacceptable by means of "not storing your metadata in any other system than the file system itself", and which presents the (big) additional problem (which is not inherent to their choice but they simply don't see any necessity for it, having made that choice to stay proprietary, in order to rely upon Windows metadata) that they don't display the comment attribute in their hits (from searching, from filtering), hence the interest of (absent) integration with a file commander that would display them.

As it is, then, any naming conventions you want to do, you could do them in the file names, and within the file names only, which by then would necessarily become rather long; remember that within my very short naming system (which for understanding relies on permanent display of the "resolved" name within the comment field), I easily can filter not only by single code chars (if they are allowed within Windows filenames, but then, I place those within the comment attribute anyway, in order to avoid problems with file clones), but also by specific code characters on specific positions, i.e. not only for "a" or for "a*", but also for "?a*", for "?a?" or for "?a??" (which is all very helpful for searching for specific subgroups), and all this also for display grouped two or more such specific subgroups concurrently within my list window. (As said before, all this could easily be done within a tagging system offering Boolean searches, but as there don't seem to be but proprietary tagging systems out there, any system relying upon the file system's attributes itself seems to be safe to me.

Problem with search tools searching specifically for file names (and possible folder names) is again possible integration with file commanders (in order to display the comment attribute which no such tool of my knowledge display on its own), but not one such search tool I've found does offer such integration. (E.g., there would be "Everything" (free), "Ava Find" (ridiculously priced at 40$), and so on, and it's similar with "Listary" (free/20$) which "integrates" into various file commanders but presents its own hit list then, devoid of any comment attribute (of course - this being said, Listary not having Boolean search = combinations of search terms, but heaving RegEx, it could be put to fruitful use of some of the alternative ways of filtering for specific files discussed before).)

Thus, again, as with the tag tools, you'll have to rely upon your possible naming conventions within the file names itself, which will make them rather long (= not only for your own understanding, that is, but also for distinguishing them from imported web files, etc., and their aleatorically containing such "encodings", producing false hits (search / filter results), a risk greatly enhanced by using short "codes" (but you could always try a system with "#axyz#" and then searching / filtering for "#?x??#" or something in order to avoid mixing up your (and in case of imported files, additional) naming conventions / encodings with similar naming bits being present within those imported files' "normal" filenames.

It goes without saying that the disappearance of "Virtual Disk" / "Virtual Folder" (the same people were behind those programs, may they have been buggy or not), instead of their refining and further development, is catastrophic in view of the fact that in spite of them being abadonware, even "as is" they cannot be got anywhere, and be it just for evaluation purposes (in fact there's just a worthless crippled "trial" version to be found), and that they were without any contender (if searching in vain for such a contender for DAYS authorizes me to make such a statement; I know some file managers have some sort of virtual folders (and as almost always, Directory Opus have got the best realization of such a thing, here again), but then, try to use those for real workflow, doing dozens if not hundreds of virtual folders / possible contexts for standard material, and let me predict you'll quickly realize that not a single one of them is of real practical value for you either - I tried hard, believe me).

I also found a single open dialog enhancer that displays subgroups of files together with their attributes by option, but it was really buggy, and from kind request on its bugs and faults to the developer, I just got some blahblah, hence my final turning to file commanders together with scripting.

Here, you can of course (if you've got a large enough screen (resolution)) display TWO panes of your file commander concurrently, one displaying groups of files (= projects, contexts, reference material, etc., = virtual "virtual folders" (if you can attain a mental representation of such a thing), and the other one displaying a ToDo list (or whatever), and if you need a third one of such list (i.e. having two monitors at your disposal), e.g. for external material (that you would like to separate from your "own" things, as discussed above, but with synchroneous (= possible by scripting) displaying of the same groups / contexts / whatever), and if your file commander doesn't allow for more than 2 simultaneous panes, try to install a paid version AND the trial version of the same program (in order to have easy access to every one such of the 3 or 4 panes for your scripts), or have two / several concurrently running instances of your file commander (which will need some more technical understanding in writing your scripts correctly addressing any such pane there).

[schferk]

Proper Outlining Is Fast Outlining in the Tree

(or The Final Rebuke to Asking for In-Outlining)

Off-topic: Sorry for having mislead you, Directory Opus does NOT offer 3 panes for lists but only if you use the 3rd one as a display pane (for photos, graphics, etc.). And in fact, it's only (?) Q-Dir that offers 3 regular panes but then, it uses the Windows Explorer in every one of them, or something derived from that nuisance, so I cleared that program rather soon since I couldn't bear its GUI, even though I would very much like to have a 3-pane file commander (as I have my 3-pane outliner now) since for distributing lots of files into several different folders (and not only into ONE second folder), having shortkeys for such distribution to more than one second pane would be great (but perhaps there are different shortkeys that could be assigned to different target TABS in some other file commanders, then - I know you can do it with the mouse, but do it with thousands of files, with a mouse, and you'll need a doctor).

There is a psychological aspect in Mark's asking for outlines within items. Please let me explain.

I remember some of these "MindMap (trademark of Tony Buzan) graphic outliners that has a special "get your ideas as fast as possible on the screen" mode, be it called "Brainstom Mode" or whatever - that's for overcoming problems the normal functioniong of the program is posing you (may I say, har, har?).

If you've already got many thousands of items in your monster db file, would you be willing to do another 500 or so, just for a little paper of, say, 40 pages? Of course not, you'd (consciously or inconsciously) have the fear to totally clutter your db with too many, too tiny bits. Hence the ubiquitous asking for outlining within single items. (And where do you put the limits between your two different "systems"? Chapter-wise? You'd have some, say 8 chapters for your 40 pages, then, i.e. 8 items, and 500 in-outliner headings / sub-headings within those 8 items? And here and then, you add an item, instead of your former in-outliner headings the higher heading of which gets more important, or the other way round, you delete an item, making it a (rather high-level) heading within your some of your existing in-outlines? And so on, ad infinitum. BTW, the ubiquitous asking for one-pane outliners is and always has been there in order to JUST have these "in-outlines" of various levels, i.e. to do away with this frontier "will it be an item with a sub-outline under it, or will it be some heading within another item's in-outline?

All this because your usual outliner (MI, UR) does neither facilitate your creating new items, nor jumping from one to the other, especially after having done some editing.

Unfortunately, UR is the worst program here since on not-so-fast comps (= old comps, or just netbooks / slates where the criteria are light weight and long battery autonomy, not processing power), and as I have mentioned in this forum before, not only it hinders your ways, keys-wise as on every comp (but which can be overcome by better and external macro key assignments), but it makes you WAIT after creating a new item, and after editing any item.

But where's the big advantage of outlining? It's to have your skeleton, and your bit you wanna edit / reflect upon - and ONLY that one, and, in the best of cases, that one in its entirety (i.e. if your bits ain't too long, it's just that bit you'll see on the screen, and all of that bit: perfect, considering the outline (= the tree) is just a tab away, or even better, your focus IS within the tree, you scroll thru the tree, instead of scrolling texts...) -, before your eyes. If you revert to in-outlining, you deliberately give up outlining's advantages:

Again and as in any "text processor", you'll have TOO MUCH on the screen, i.e. the last lines of a previous bit (= text under heading or subheading), and the next heading / subheading, together with its text.

And, ironically, at the same time, and again as in any "text processor", you'll have TOO FEW elements on your screen for not getting lost within your "big chapter" or whatever, and you'll have to do a lot of scrolling, not to avoid that effect, but just to not getting completely overwhelmed by it.

Oh, I know that you could minimize that effect by doing, as the developer, an additional subroutine catching any in-outline heading / sub-heading on the fly and presenting it in just another pane, between the tree and the in-outline, in order for you to click on those there, in order for that heading / subheading being scrolled to the first line of your in-outline pane. But then, developers are lazy, there's no such elaborate in-outline headings display currently in any contender to my knowledge, and besides, kinook thinks there are lots of panes within UR as it gets, so they rather will refrain from doing elaborate coding work in order for give you one more.

Thus, all you'll get, at the very best, here or elsewhere, is in-outline as you know it, the primitive way, the way that takes away from you any advantage an outliner might have over a "text processor". If you really need this feature, look elsewhere, look at Word with some of its numerous add-ins, and you'll get better in-outlining than you'll ever have within a real outliner anywhere.

So, in-outlining is then for masochists who love to get lost within (and in spite of) continuous, heavy scrolling efforts - that should be totally unnecessary in the first place.

Outlining is about neatness; in-outlines scramble that neatness. But you're right, Mark, in asking for a better way to do proper outlining... which can be done on the tree level.

Sorry for being a theoretician of outlining pushing the nerves of some people, but as you can clearly see, there are enough practical implications of my dogmatic views to make it worthwile for any smart power user to comply to them.

So the real problem is the psychological one: It should be possible to do 500 new items within an outline, in order to conceive just 40 printed pages. And for this becoming reality, two conditions must be met: It must be technically feasible, with greatest EASE for you; have a look at something like AO, creating, naming, editing multiple items simply cannot be realized in any easier way than here; and do SEPARATE outlines, do just one single outline for your 40 pages.

As soon as you're willing to do this, having 500 items in a single outline just for 40 or 60 pages, it'll be a tremendous relief, for everyone who currently, for the creation of every single additional item, is (consciously or inconsciously) asking himself, is that new item really necessary, or is it too much clutter, considering I got 50k of items already?

Of course, my advice isn't worthwile but within outliners that offer adequate exporting, i.e. export all your 500 bits in one flow, into your beloved MS Word. (With some scripting within that target prog (and with opting for numbering your items in the export), you'll even be able to automatically and correctly format your 500 bits' headings / subheadings with given Word formats (i.e. make Word check for the headings' numbers' length = indent level).

Believe me, it's a totally new user experience, to simply spread a 40 page text on to hundreds of different items.

(And remember, you'll have to type in every which one heading / subheading anyway, be it in the tree or within the text: my offering doesn't ask for any more effort than you'll currently have to apply.)

Enjoy.

[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).