Is it possible to do proper outlining?

[schferk]

1)

Because it's so beautiful, here, for your contemplation:

http://www.outlinersoftware.com/topics/viewt/3984/

TreeProjects 2.5 adds database encryption

Posted by Ian Goldsmid
May 3, 2012 at 09:20 PM
Since Treeprojects is quite similar to Kinook’s Ultra Recall - and their development has stopped - would you be able to develop an import process for .URD databases?

Posted by Daly de Gagne
May 4, 2012 at 01:30 AM
Ian, when you say Ultra Recall development has stopped, do you mean the company simply hasn’t added any features for a while - or can an inference be drawn from what you say that Kinook is having problems?

Posted by Ian Goldsmid
May 4, 2012 at 03:51 AM
I’m certain Kinook is a thriving company - other than that everyone on the planet has “problems” - so I’ve no idea what you are talking about really.

[So, complete retraction just 6 and a half hours afterwards, and pretending the inquirer is doing the calomny. Black's white, white's black. Must be working very successfully in the political field, that smart guy.]

2)

Some additional details for my white paper in order for avoiding misunderstandings:

Comments are mainly for systematic content description (working with multiple tabs, I need file names be as short as possible), and for various ToDo codings ("filter by..."), but all project / context groupings are done by file names, making heavy use of "clones", in the form of "ab.ao", "ak.ao", "ake.ao", together with "a.kl.ao" (= a clone of "kl.ao") or even "ake.klc.ao" and "ake.plo.ao" (= clones, respectively, of "klc.ao" and "plo.ao") - this way, clones are grouped within their immediate multiple contexts, in alphabetically-sorted sub-groups of the whole thing, whilst I rely, for any choosing of such outlines, on reading the "comment" text.

Separator lines are done similarly, they are appropriately named clones of an original divider line which is nothing more than an empty file with a sequence of dashes within the comment attribute.

As explained in another context above, there is no good search functionality in my system, but within a corporate context, such a thing wouldn't be any difficult to implement, it's just a matter of money to pay for the programming. In my system - used by one man (whilst in a collaborative environment, searching would indeed be of much more predominant necessity) - I discovered that my fractionizing of information into self-contained, correctly-described (= within the comment attribute) chunks allows for doing without frequent global searching, and it's not more than once a day, here and there, that I'm really in need of this. Well, for these exceptional needs of mine, there's a cheap third party application that not only allows for global searching my .ao files, but which also delivers correct results for terms containing European characters (if I enter them in the transcribed form AO internally processes them). Such a search (= of the whole, 2 GB bunch) takes about 200 seconds, but even delivers a table with the multiple contexts of the hits within each "hit" outline, which allows for my selecting the "right" .ao file then, in which I then must do a new search for the same term in order to finally get to the "hit" item. So this is cumbersome, but since it's of rare necessity, it's a quirk acceptable to me.

Within the above-mentioned cloned-outlines system relying on the file system, it's perfectly envisionable to integrate all sorts of other files than just outline files, especially .pdf files and .xml files (or whatever you need within your projects and various reference compartments), belonging to such projects, and I started to integrate such files into my system indeed, all the more so since it's possible to do multiple filtering at the same time, i.e. sometimes you want to have a clear view of just your "own" files, i.e. those you created by your own means (even if they also contain, perhaps a lot of, (fractions of) external content), and sometimes, you want to have "complete projects" to work an, an which indeed contain and related real third-party files, as downloaded .pdf's, etc.

As for scripting and integration, an important aspect is to do the scripting in a way that you can access (self-written) commands / routines doing processing within the file system (i.e. working upon your file commander or otherwise), from WITHIN your "real" application, i.e. in my case mainly AO, but also from within other applics (e.g. Excel) where you'd have any need to access your file management routines from; any necessary "switching" to a file commander or any other intermediate device, beforehand, would interrupt your workflow indeed.

And of course, these "simili-global commands" (= similar but not necessarily identical functionality, depending on your starting point applic) would be triggered by the same shortkeys, hence the interest of having a "new deal" for your numeric keypad, but this supposes that within other applics than Excel and your electronic tape calculator, you would NOT need to enter digits all day long. I also experimented with additional keyboards; there, the problem is you've got a full keyboard, with arrow keys and with a numeric keypad, so the additional keyboard (make it a tiny one, some 30 or 40 keys, not 100 or so) is far away from your a-z keys, or you must place it for your left hand, and in my experience, that was really awkward. It's far better to use your right (= your principal; for lefthanders it's all the other way round but perfectly similar then) hand for commanding your information system, willing to enter SOME digits (i.e. outside of heavy calculating and table processing) by the keys above your normal keyboard, all the more so since I discovered that within Excel, I need far less of such immediate access to my information system, allowing my normal using of the numeric keyboard for just entering digits there.

If you do a lot of data processing within Excel - which I discovered as being a much smarter way than trying to squeeze the attributes fields of an outliner (UR, MI) into a simili-spreadsheet (as I had tried to no real avail before, as many here always do) -, you could even use another system variable within your scripting system, in order to have your numeric keypad ready for number crunching, in Excel, WHEN you do number crunching there, but to have it do all sorts of more elaborate things at your will whenever just doing data analysing within that ubiquitous (and rightly so loved by everbody) program.

In the late Eighties (= transition period from proprietary systems to general computer use in secretarial work), you could buy a lot of elaborate keyboards, with a lot of additional F keys, and often distributed = really accessible in a smart way, whilst today, the problem, as mentioned, with additional keys being their distance from your normal a-z keys, hence the interest of a better re-use of your (integrated) numeric keypad whenever possible.

(And to Mark, your "scherk" I translated by "a smart way to insinuate "jerk"", but that was not a mandatory reading of perhaps just a typo...)

[Jon Polish]

I have read your postings and have tried to follow your train of thought and references. You obviously have thoughts to contribute, but could you please be concise? I am sure your references are lost on most readers due to obscurity, idiosyncratic application, or because the reader must be familiar with your previous posts (here and in other forums). To start, I would edit these out. Jabs at other posters or at Kinook are uncalled for, especially since we are "guests" on Kinook's forum. This does not mean that we should not be critical (I have pressed issues on several occasions), but snide comments are, in my opinion, not helpful.

Jon

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