Is it possible to do proper outlining?

[schferk]

What about Mail, then ?

Above, I've been describing a "complete" and scaleable system of IM, but "complete" only if you discard the email problem, and you cannot, of course: you MUST find a solution for that problem.

In UR, Outlook processing seems to be outstanding (I'm arguing from help files / forum knowledge only here - but no Outlook 2010 64bit possible? perhaps now... - and does UR automatically import these mails into the corresponding UR subfolders, AND into an inbox in UR, so that they could be user-treated within UR and be within their right place there all the same? Perhaps, by "searching" for "newest entries"; smoothness of moving them would remain to be seen, and then, would synching back with Outlook create the corresponding new folders / subfolders within Outlook? I'm speaking of refining your Outllook folders more and more, automatically, whilst the actual work of refining would be done within UR),

whereas processing of mails coming from other mail clients is lots of manual fiddling and cannot be considered helpful in any way, there would be a lot of false (since manual) attributions (since any manual synching of two "file" systems would be "hell" AND would be prone to lots of errors, as anybody can confirm who ever tried to synch manually lots of folders / files (back in DOS days where no such sync tools were / seemed to be available to the masses - Norton Commander presumably had a "compare view" incl. sub-folders, but from the beginning on? Anyway, I remember lots of hard work, with bad results altogether).

I own Outlook (French 2003 version, from a package I bought), but what I hate more than anything elseabout it is its .pst file and possible problems with it, hence my preference for Thunderbird.

Yes, you could use UR or some outher IM tool to process and manage your mails, but when leaving that tool for some, these mails (=these copies of them) will be lost, and in your Thunderbird (or whatever) db, they will all be as a bunch of many thousand (or more), indistiguishable but by searching, since it's simply impossible to synch them there, with your UR versions of them, by hand, and for years (this meaning you'll have necessarily ever-growing inboxes within Thunderbird or your mail client of your choice, doing any classifying work in UR (or any other IM tool for that).

Hence the utmost interest of UR's Outlook synching capabilities indeed - but which force Outlook upon you even if you hate MS in general and Outlook in particular.

My "separate files" approach quite naturally led me to Everdesk; they have multiple versions, drowning some versions here, creating some others there; I know of Standard, Optima, Google, Mail, and perhaps there are others. Fact is, their site persistently refuses to load into my IE8 (and I threw out Chrome / Opera / Safari after 10 minutes respectively, Firefox after 2 hours). From what I know from third parties, Everdesk puts emails into separate files, maintains a commun file structure for your files and your mails...

Seems to be very smart at first sight, but then, remember what I said above re 5,000 .doc files: What about 20k (or more) of separate Everdesk mails, after some years, then? Wouldn't be smart at all, all things considered! It's quite the contrary, as your notes, some 20, 50, 120, 500, belonging together, should be put into the same technical entity, i.e. an outline for your casual contexts on this subject, another one for those on another subject... and mails from and to a certain big customer, into that customer's outline.

And, of course, your mails should NOT be separated from your notes and other bits, but should be integrated into these same outlines, subject-wise. (People who want their mails within a separate body could simply replicate their outlining structure within their mail client and leave all mails therein, and indeed, almost everybody who doesn't use an information manager / pim does exactly do this, having no other solutions at their disposal, except for exotic ones as Everdesk provides.)

This being said, and seeing what UR does with respect to Outlook, I see another great strength of UR here that for many a user will certainly be a reason to never leave UR.

Of course, I'd prefer such integration within AO, and with Thunderbird, not Outlook, but I'll never get that. Which means, I'm contemplating just another pane on my screen, showing me, by scripting, the according subfolder within my Thunderbird program, for every .ao file I'd bring to focus - in order, of course, to leave my mails there, (manually) synching only created, renamed, or moved folders (or manually moving mails when in my file system I deleted a folder and must create one or two new containers in order to not orphanize my corresponding mails).

There's another aspect in all this, the legal aspect. Even a one-man show like mine must comply to legal dispositions, and in Germany, for example, tax authorities are tremendously strict about your "commercial correspondence", incl. your mails, and from all I know about it, it seems unacceptable (and thus reprimandable) for them to just have your mail in something like UR. On the other hand, systematic filing of your files within UR, whilst preserving all these same files in unordered state (or let's say, in chronological order) within your mail client, will and must be fine even for these high-level paranoids.

If there are better mail solutions, please share them with us; the same goes for any further insight into UR and Outlook. BTW, I did NOT find any respective installation numbers for Outlook or for Thunderbird; Outlook storing your mails into a relational db, it would be a dream to have just ONE such db, for your notes and stuff, AND for your original Outlook (or Thunderbird or whatever) mails... a dream that'll never come true, of course.

For me, it'll be .ao / .xls, etc., it'll be secondary files within a parallel structure (= as before, but synchronized now), and it'll be Thunderbird with that very same structure: Must write a script replicating my 600 .ao files as a Thunderbird folder structure!

And I'll have to go for buying me a wider screen now.

EDIT: All things considered, having a legally valid collection of chronologically ordered mails (= in and out) within your mail client, 1 subfolder per month, 12 such subfolders per higher subfolder for each year, and systematically copying any such mail from there, first into an inbox within your IM system (= whatever that IM system might be), and systematizing mails ONLY FROM THERE, i.e. classifying them into the respective folders, would, on one hand, mean you deliberately renounce on the "advantages" that so-called "rules" within your mail client would otherwise provide, but on the other hand, this way of doings things would greatly simplify your mail work, since these "rules" can't reasonably be synched with any other thing, and will certainly interfere with any other task here, i.e. any "rule" system will be opaque, not evident, unvariably forgetten by yourself in lesser or greater parts, in short: Will trigger unexpected results, would be another such classification system that'd be never in synch with your more evident processings, be they scripted or partly manually-driven or whatever.

SUCH a system - chronologic divisions within the mail client, systematic filing within your IM system - will certainly be far more straightforward than any other offering, incl. two-way synch between UR and Outlook (and there would NOT be needed any reference from the mail client into the IM system - from the IM system, you would see any time where the "original" mail will be within your mail client's chronological structure, and if EVER (= not probable at all, no plausible scenario for that except for the tax authorities, cf. below) you need to verify such an "original's" "final place" within your systematic structure... well, as for the tax guys: let'em search!

Such a system, then, will free you from any synch needs between mail client and IM structure (= 1 big UR file, 1k of tiny .ao files, whatever), and the only scripting / programming "difficulty" (and that's not a big one, hence my quotes) will be your enabling to write new mails within your IM structure, and trigger then their sending from within the mail client (= remember, no systematic filing in that structure needed, just "put it into the current months in and out folder").

Even with a dumb macro, you could realize such a thing, and even within a dumb program like ActionOutline: have multiple clipboards (cf. my previous postings), write within your IM system, put the different field contents, automatically, into the different fields of your mail client, trigger "send".

In short, maintaining THREE synchronuous structures would be ridiculous when TWO such structures largely suffice, and having your mails in chronological order wouldn't harm either, and be it only for obligeing to legal dispositions.

Voilà : It seems this would be a valid system - and it helps if you swear by UltraRecall, preferring any other mail client over Outlook though.

[schferk]

Since I was asked for a review of ActionOutline here, please refer to:

http://download.cnet.com/ActionOutli...6_4-45005.html

And yes, I can be very nasty when treated like pure sh**... without even reverting to the slightest lie.

EDIT: I wish to add that in my 8th or 10th mail to them I announced my retaliation to come if that also remained answered, which it did... and I check my spam mail box regularly... So, they asked for it in every possible way.

[schferk]

For those UR users having checked that link already, please note in the meanwhile I buried their "network" version, too (with a special mention of UltraRecall there - I know whom to treat well).

[schferk]

Just a short rectification of my stance that proper outlining is outlining, whilst "inlining", i.e. additional outlining within specific items, is to be avoided at all cost.

As I explained in the meanwhile in the outliner forum, I'm not so sure of this - perhaps false - dichotomy anymore,

and whilst I'm strictly against dedicated one-pane outliners, because of their inability to store your working material (it's no coincidence that the one rather successful "one-pane" outliner, Bonsai, really is a hybrid outliner that in fact does offer a special - but badly realized - "content" field for every item),

I now prone EDIT: defend (prôner is French), again, what I had even realized in my own IMS, 15 years ago, a double function that does not offer "real", multi-level outlining within items, but which offers conversion of ONE-level "outlining" within items

(= by (at wish, even automatically numbered) headings or just bold-formatted single lines after blank lines and above other lines not separated by a blank line (= "smart collection of what is to become a separate item")

( EDIT 3 : To give a precise description: As a "heading", the sw would identify any text line that is first in the text field or beneath a blank line, and that is followed by a LONGER line, but with the exception of several lines beginning with a "-" or something like that; such lines would be counted as "text"; as "text" would be identified any lines, including blank lines (= several paragraphs in a row), up to the next "heading", or up to the EOF. The bold formatting would be automatted for IMPORTING such headings plus text into a text body, from separate items (= downwards), but it wouldn't play a role in identifying the headings for EXPORTING into tree items (= upwards). It goes without saying that this system is intended to automate this upwards shuffling, WITHOUT relying on any pre-figured "paragraph formats" or such since these are absent from most editors used in outliners and such - so it's rather "primitive", not MS Word "class", but it works very well. It also goes without saying that any IMS that indeed uses "paragraph formats" (which is not the case currently for UR), would rely upon (upwards), and provide (downwards) "header" formats, instead of just boldfacing those lines (downwards). Another clarification: Those "headings" are identified mainly because they are immediately (!) followed by a longer line, whilst several paragraphs following each other, except for the above-mentioned exception of lists, are separated by blank lines: so, a rather short paragraph within a sequence of paragraphs (under the same heading) will NOT disturb this identification scheme, that would only fail in rare cases with a heading and then a first paragraph even shorter than the heading. So, in the end, you could even discard the "followed by a longer line" part, just identify by preceding blank lines, vs. two "paragraphs" immediately following each other: Then, the first one is a heading if it's preceded by a blank line or is the very first paragraph in the editor field. And lists would be identified by its lines (= 2 or more consecutive paragraphs without blank lines between them) beginning with the same special char, whatever that special char might be. Simple. )

into separate "siblings" = common children of the current item, and vice versa, meaning a function that shuffles any children of a given item as text paragraphs into that item, the former items' titles becoming bold (and, at wish, numbered) headings above such text paragraphs.

I do NOT think that real outlining within items might be of use, but indeed, translation of sub-items into (single or multiple) paragraphs of their former parent item should be possible, as well as translation of paragraphs text amounts within an item, into separate items whenever you'll realize that these become too much "developed" as to logically remaining within such a single item becoming convoluted, and of course, this double transition, both ways, should be automatted, as described above.

As for further outlining, I think that anytime you'll realize that you'd "need" even second-level outlining within your item, you'd simply transfer your first-level outlining there into such separate child items, and your further headings within these siblings will become your "second-level" outlining there, and so on ad libitum, i.e. any further outlining except for just one level within given items should be realized by further indentation within the tree, but in order to have a plastic system, without the need of much manual fuss whenever you realize your separate items are too short and / or too similar in order to remain separate items, or that your text becomes too voluminous in order to stay together within one item, transition both ways should be facilitated by automatic processing by your IMS - and since I programmed it myself at that time, let me assure you that from a technical pov, nothing could be more easy to implement in a sw like UR, both ways.

EDIT 2 : It just occured to me that such a "bottom-up writing" might be ideal for people who prefer UR and such for "stuff storage", but who've been clinging to other means (one-page outliner, text processors like MS Word, etc.) for redaction work, for "writing":

In fact, write within the one-level "outlining space" of any item, develop thoughts there, take advantage of your "flow" there, not bothering with separation into different items. Then, run the "distribute into siblings" command - takes a sec or so -, and continue to develop sub-thoughts in any such sibling, again to the point of "needing" distribution into different siblings, and so on: This doesn't hinder you at all to create additional such siblings, uncles, nephews, whomever, being left empty at the given moment, and in order for them to contain data later.

This way, you'll have got the best of both worlds, 1-pane and 2-pane at the same time, and there'll be no need whatsoever anymore to split up your writing into two different applics, with all those problems such a setting brings with itself, meaning the import from your "writing" applic into your "storage" applic will perhaps be flawless, but what about exported parts that need "revisiting", is re-import into your 1-pane outliner really easy? Which means you'll invariable end up, in such settings, with writing concurrently in both applics, creating total chaos in the overlapping and clashing of these different (multiple) parts.

All these problems are perfectly avoidable by the described original writing within your UR items, together with isolating any "rather devoped part" into separate items, and doing any interactive editing within these different UR items, providing perfect plasticity in both directions whenever needed, from connected text to tree and back to text body.