Is it possible to do proper outlining? [Archive]

schferk

03-26-2012, 05:28 PM

You must see that on every occasion, somebody beggs for a new editor within UR, or a way to include an external editor within UR, for any which reason, and there are many good ones of them, he's rebuked. It's simply the fact that a good external editor component would cost Kinook about 800 or 1,000 bucks one-time payment, whilst the very old MS editor that comes with UR is free. Thus, I recommend to start a thread "I'm willing to give xyz dollars for Kinook being able to order a new & really good editor, please join in", instead of multiplying the threads in which the multiple faults and innumerable missing functions of the gratis editor are displayed. Just my 2 cents.

P.S.: I've had many problems with the "search" function not finding anything, too, so I decided to better organize my stuff, in order to avoid searching altogether. It's a pity self-contained IM systems cannot get rid of bugs affecting their everyday usefulness. Before doing a search over multiple databases, the search within a single database should function well, it's a minimum, no? Just my 2 cents.

MyInfo, a less elegant but not bad contender, had a function which allowed, by option, for displaying of the three first lines of editor's text for every hit, within a sort of a "hit table": VERY smart since you could standardize some recurrent info within these first three lines, and then decide upon a variety of key info just by looking at the hit table.

They withdrew that function, pretending they would reintroduce it later. Well, that's been more than a year now, and no reintroduction of that fine feature in sight. So, if any businessman did his customer db in MI 5, relying on this feature, then updated his database to MI 6, then saw the feature was gone, then tried to reconvert his db back to 5.0: oops, file format changed...

Even "better", expensive InfoSelect cut off most vital functions, pretending they were accessory... and presumably to hinder people to change horses, for some of them.

askSam dumped their forum altogether, promised an "8 beta"... which is unavailable.

There is a degree of unprofessionality within the development (and un- and non-development) of individual IM sw that makes it very difficult to rely upon these for any business use: individual users ain't nothing more than beggars, and most of the time, our tended hats remain empty.

This being said, people not ready to create their own integrated system out of an outliner and additional sw, are bound to stick to what they have, and then, most are professionals, having good incomes, being able to spend 1,000 bucks on a really good IM system, instead of laying out 19,95 bucks at bitsdujour...

Perhaps it's time some of the offerings got REAL, asking for 1,000 bucks, but DELIVERING.

The current situation, whining for YEARS over bugs that never get really done with, and over missing functions that'll NEVER come, and it's similar anywhere, UR being one of the more serious offerings by immediate comparison, is cabaret.

Have a look at the outliner forum: There, motherless outliner users, many of them coming from UR, are fervently discussing a wiki tool, wikis being for textual presentation, not creation notwithstanding, but they don't even see that basic, so desperate are they. And every one of them could pay 1,000 bucks for REAL sw.

Cabaret, I say. Just my 2 cents.

Nobodo

03-27-2012, 11:59 AM

Thus, I recommend to start a thread "I'm willing to give xyz dollars for Kinook being able to order a new & really good editor, please join in", instead of multiplying the threads in which the multiple faults and innumerable missing functions of the gratis editor are displayed. Just my 2 cents.

So in other words in your opinion nobody should ever ask for updated features in UR, but just live with it as it is unless they are willing to take up a contribution for updates. That is more than a little bit absurd; did you get the software for free? I seem to remember paying for it.

If Kinook comes up with a new version of the software that has a new editor (to stay competitive with other similar products) and also resolves a number of other feature and bug requests, I would gladly pay an upgrade fee as I am sure many others would. But to tell people they need to start a donation thread anytime they ask for a new feature in the software, you are really doing nothing more than trolling, scherk.

schferk

03-29-2012, 08:37 AM

Don't panic, I wasn't asking for CURRENT UR's price increase to 1,200 dollars!

Sorry for not having made it clear by the usual means, \irony off or something, that I switched from irony to serious argumentation within the original article.

Problem of this market is, there isn't enough money in all this, so developers do their work very badly (many examples elsewhere), or, in the case of UR, as a second task, as a pastime, whilst doing serious work with their main offering, and so, individual people longing for using real good IM sw, must live with sub-optimal solutions forever.

Hence my idea that there MIGHT be room for a developer who says, it'll be 1,000 bucks now, but I'll do it really good, no more endless longing for even basic functionality.

I myself was begging for a better editor within UR here, then realized kinook doesn't want to spend the (tiny) money of such a component, and at the end of the day, it's not the editor alone, it's also the db.

Compare with MyInfo (which has other faults UR doesn't have, no misunderstandig here): There, you can edit an item, then go to another item, go to a third one, back to any of the beforementioned: It's good FLOW of work, not hindered by response times of your system.

Perhaps with your comps, even UR works smoothly then, but on my (not top-notch) systems, UR makes me wait for some seconds between these above-mentioned switchings, and THAT was, in the end, the real reason I finally left: For text processing, moving bits of texts, or copying them, or doing some minor editing here, adding a word there, it's simply not the right program because of those response times, for me, whilst MyInfo does it without problems - replacing the gratis editor by a paid one, in UR, would NOT resolve the problem that for writers (of any kind of output and) with "old" comps, UR is not the right sw.

I think many of these marketing probs of outliners are caused by the fact that most corps (where the money is, and where probs are resolved by spending the money it takes) go to collaboration sw anyway, whilst those many, many tiny mom-and-pop entities, 1-man, 1-man-with-part-time-secretary, 3-people, whatever in this range, do with what they get, and didn't see yet that for the value of a weekend-trip, they'd get "incredibly better", potentially.

Hence, the near-impossibility for "small" developers to address that sleeping market, but as soon as one developing corp decided to do some serious offering, and put some marketing money into, and put small collaboration functionality within it, incl. interaction with MS Outlook and so on, just for 1 to 5 users, with 1 user paying 1 grand, up to 5 paying 2 grand and a half, it would be a total success - always given that there would be real enhancement of the work flow of such 1-5 head entities, incl. IM, good text editing features, some CRM, and so on.

Whilst today, they are file managers out there that are more expensive than e.g. UR Prof. is (which, for the innumerable quirks in UR is quite ok, actually).

Let's face it, a lawyer takes 250 bucks the hour, many take more - why should he be entitled to work with an integrated sw system that he values at 20 minutes of his time? And indeed, he doesn't find any such a system, except for more or less mediocre offerings, UR being one of the best of these.

Even if it's a cheap lawyer, "only" charging 150 bucks the hour, why shouldn't he work ONE WHOLE DAY for paying his near-perfect IM system that he gets perfectly all his work done 365 days in a year?

Even for a writer my calculation would be right: Many of them are (well) paid from some university or do have got a main job for their living, so why not pay 1 grand upfront = 3 bucks a day, for the first year, and then 500 bucks a year, or any second year, for top-notch updating?

"Outlining peple", i.e. 1- to several-heads entities needing / working with IM systems, do want to pay less for that system than they pay for their additional MS Word (in which they perhaps do their letters or something) -

and they even succeed in getting sw for that pittance.

Unfortunately, they only get what they pay for, or just only slightly more.

Since on the other side on the table, offerings in that range of payment are made by hobbyists.

(As said before, real hobbyists not being able to do better, or, e.g. in the case of kinook, people having better things to do, for most of their time.)

So much for trolling, boy.

quant

03-29-2012, 03:43 PM

"Thus, I recommend to start a thread "I'm willing to give xyz dollars for Kinook being able to order a new & really good editor, please join in" "

I agree with you, I actually had similar idea just after the credit crunch.
I imagined it would work like this: Kinook or some loyal user would create a fund, i don't know, paypall account or whatever.

Kinook would clearly state the price and time for developing some of the most desirable features, like multi db search $$$$, better editor $$$$ etc.

And users would simply pay to this fund whatever money they would think is right towards the feature they would want Kinook to develop. Once the money for the given feature would reach what Kinook stated, Kinook would develop it within the agreed timeframe and release it, as a free update for anyone who donated towards that feature.

It think it would make the best use of money, which is very scarce in today's market, to develop exatly the features that users demand. It removes the initial investment burden risk from developer, and makes life a bit easier to them.

It's not optimal solution, but I think better than what we have now, ie no real release in a long time, and probably not any in the near future either ...

What do you guys think?

Kinook, what do you think?

Nobodo

03-31-2012, 04:40 AM

Schferk,
I work as a software architect, and have been in IT since 1978 (concentrating on software development for the past 20+ years). I know very well how hard it is to make a profit on a piece of software that you develop and market yourself, having done it myself a few times over the past years. But I also know that to stay competitive in any software market, you have to invest in the future. Stagnation is death to any piece of software because evolution happens very rapidly in this industry.

Using the example that is in this thread which you for some reason hijacked, the cost of an editor to replace the freely distributed MS one is a pittance compared to the cost of the development itself. For example, I pay nearly $4,000 per year for an MSDN subscription to support my software development effort. The annual cost of updates to other software component subscriptions rivals and in some cases exceeds that annually, but has to be done to meet the needs (i.e. demands) of my clients. Without that type of investment, I would be out of contracts in no time at all.

If you are willing to pay $1000 or more for a single license for an outliner that meets your needs (which would obviously have to be developed by a team, not an individual), then it really makes no sense that you are trolling the posts of people asking about the possibility of very reasonably expected updates to a $99 product. Competitive products are in the same price range as UR, and many much less. To be willing to pay $1000 for such a product would mean you must have requirements that are far beyond those of a typical user of an outliner product so perhaps you need to hire somebody to do a personalized software project for you.

Anyway, in an attempt to get this thread back on track, what I am asking for here is a feature that is present in many competing products in the same or lower price range. MyBase (wjjsoft) has this ability, and also several other nifty features such as the extremely desirable feature of an MDI interface so you can view several client windows at the same time. TreeDbNotes has this ability, and is much easier to style notes on the fly than UR could dream of. InfoQube has this ability along with a ton of other unique and amazing features, and has many very devoted followers but only a grand total of 131 people who have paid the $49.95 price for a pre-release license. Perhaps the extremely low pre-release funding of InfoQube can be used as an example of how futile it would be to ask users to donate money for the possibility of features being added to UR. It just is not a working business model.

There are many features of UR that are not in the pieces of software I discussed above. However, many of those features are probably of no use to many users, like me. Some features of UR I like a lot compared to competitive software, but some like the topic of this thread are an extreme frustration likely to drive users away if they keep getting met with closed answers like "That sort of outlining within the UR rich text editor is not supported.".

So for me at least, the question is just are there any plans to update this for the future? The free MS editor is a dead-end, and needs to be replaced. I would gladly pay for an upgrade to UR if this would be done; there are enough things I like about UR that I would rather not abandon it. In spite of that, competitive software is evolving and moving past the currently stagnant UR in many ways. But to propose that users should be willing to donate money in the hopes that a seemingly disenchanted developer would suddenly become inspired to do large amounts of new development is purely cabaret.

Thanks,
Mark.

Nobodo

03-31-2012, 11:27 AM

I just took a look at the roadmap for the development of UR, which was last updated in 2010. I really don't see a lot of features there that are relevant to my use of UR, and those that I do care about are pretty low on the list.

For example, there seems to be a lot of demand in these forums for multi-db search, and I find that very confusing. To me it would be completely useless; multi-db search is something I would never use at all and really do not see how it belongs in this type of software. As a developer, I'm well aware of what a huge amount of development time would be required to implement something like that, in the existing app, especially considering that UR currently opens multiple databases in distinct instances of the application. To top it off, after all the painstaking work to add such a fringe feature, after release it would be sure to be met with tons of complaints from those users who expected it to work differently. In my opinion if a feature like multi-db search should be added at all, it should be a completely separate product that users could purchase in addition to UR.

I think a good strategy would be to get back to basics and add the features to UR that are currently found in competing products and could be relatively easily implemented in UR. I'm willing to bet the current roadmap is way out of touch with the actual desires of the average UR user, but perhaps it does represent the very vocal minority. There are many features of UR that blow away competing software, but there are also many very basic features that are lacking and should be prioritized way above current 'top of the roadmap' items.

Anyway, just my opinion. Each user of an outlining product is going to use it differently and many will have polar opposite desires for the future of the product. I just think the basics need to be hit first.

juergen

03-31-2012, 11:42 AM

<nobodo>
In spite of that, competitive software is evolving and moving past the currently stagnant UR in many ways. But to propose that users should be willing to donate money in the hopes that a seemingly disenchanted developer would suddenly become inspired to do large amounts of new development is purely cabaret.
</nobodo>

I am using various outliners for many years now, supported and supporting some projects and can only second the posts of Nobodo.

It would be nice to read something with content from Kinook. Is it time to move on from here or is it worth it to wait ? It might be time to show some official commitment to keep people on board.

quant

03-31-2012, 12:38 PM

For example, there seems to be a lot of demand in these forums for multi-db search, and I find that very confusing. To me it would be completely useless; multi-db search is something I would never use at all and really do not see how it belongs in this type of software.
same here, but if the idea of paying towards a feature one desires most worked, and there are enough people willing to pay towards it to be developed, then i couldn't care less.

schferk

05-03-2012, 07:32 PM

Hello Mark and quant.

(The "boy" was for your "scherk", but exchange of serious arguments is possible anytime, so:)

Yes, I hijacked this thread, but you did the opposite: You created a new thread for a problem that had been treated in another thread - you didn't add up to that one but authored a new one. I might be considered quite intrusive by many people, but then, if there's a thread to which I can add my additional details, I prefer people NOT having to read those "as they were all new" - might considered paradoxical within an overall view of my various contributions.

You're quite right, 100 bucks' sw has nothing to do with 1,000 bucks sw, but the problem is, there is NO such software that might be considered top-notch within this field, not for 100, and not for a thousand bucks, but you find many offerings within the legal field, within that second price range and above, but then, these are specialised tools that would present many quirks, every day, hampering your workflow, if ever you tried to use them for more general - or let's say, other than legal - uses.

When I "asked" for donations, it was cynicism (born out of disappointment from precisely that arrogant treatance we're entitled to here, and which you mention by saying "an extreme frustration likely to drive users away if they keep getting met with closed answers like "That sort of outlining within the UR rich text editor is not supported."" when in fact UR is a good product that is in need of much developments in order to cope with the 3rd milennium - it's more and more left behind, a you guys state more or less clearly) I KNOW that this is not a viable business venture. But quant WAS serious about it, so there's no reason to ridicule this ("cabaret" - btw, it had been I who introduced that term here, long ago), but then, I did top-notch IM sw in the late nineties, of which I sold FIVE light versions, and many of its details can't even be found today in high-priced products, so I know a little bit about the intricacies of marketing. On the other hand, as we all know, quant is the real UR expert here, and we're all indebted to him for that. All the better if he's not been in our position to market real good sw but with insufficient means. (Spectacular details of my sw then can be found here, in the MyInfo forum and in the outliner sw forum.)

Since I, a non-programmer, built it from a really bad sw language (ToolBook), I had to cope with a 32 k limit of any item's main content field, and even today, that sw language comes with the same 32 k limit (interesting here: Zoot was marketed with such a limit up to 2011, it's only now that they overcame it).

So I went away from my own product, using askSam instead (which I had used earlier, then programming my own thing in order to have something "better" - better in many, many ways, but certainly not in AS' core functionality of fast and complicated search, of course).

It hadn't been but in 2008 - just 4 years - I had been so fed up with AS that I bought the very first and easy outliner I could get hold of, which was ActionOutline: It's not able to "do anything", but creating a sibling, creating a sub, is unbelievably "natural".

I quickly got aware of its multiple shortcomings, so I evaluated "better" outliners; my choice went to MyInfo. In its day (5.07), it presented good searching capabilities, i.e. "search current db", "search open db's", "search all db's". It was buggy, it wasn't that stable, so I had several MI db's - I acknowledge that with UR's stability, you easily can do a monster db, hence the lesser need for trans-db search capability here.

After a time, I considered MI the "lesser" product to UR (two main reasons to that: MI's GUI which I think was really ugly (now with 6.07 it's become just a little bit less so), and the absence of any "super tree", i.e. no way to load multiple "projects": it's always "the whole big stuff" that clutters your screen, and that clutters your mind - be assured my own system, 15 years ago, had been almost incredible in this respect (you would be highly mistaken to infer from my saying that I'm a non-programmer, to any kind of simplemindedness in the realization of that product), so I imported my stuff to UR.

This is my 73rd post here, so some people here at least know that from beginning in, I was stuck with the - excuse me - INCREDIBLE un-intuitiveness of UR, and nobody could pretend I wasn't willing to share good ideas here in order to really improve this product. When I asked for a "recently-viewed items list", I was told there were too many subframes in the UR frame already, and this with 24" screens becoming ubiquitous, and without my having asked for mandatory display of such a list.

Main problem with UR is the monster file. I've got about 90 k of items in my workspace, with several hundred additional items every week. Not having any positive feedback when I asked for a super tree within the UR db here, and not getting any positive answer when I asked to leave at least the very first tab of several one (when hoisting in the prof. version) the way the user wants it to be, which would have made a "super tree" by doing all sorts of cloning there, then you would open just that sub-tree = "project" there you need at that very moment, and perhaps some other, "reference" parts of that primal tree), I was NOT able to do real PM (project management) with UR since whenever you open a (hoisted) subtree in any other tab, this expanding will be reflected within the very first, global tree, which by that can't serve you as a reference point within the chaos anymore.

My departure from UR was delayed by my "discovery" of the possibility to mis-use UR's related items pane as an "intermediate" pane (cf. the "tips and tricks" section here), and I tried to do all my work within that pane, in the middle now, leaving UR's tree as a "super tree" only. But then, the sparse functionality of that related items pane wasn't that suited to do all work there (i.e. no tree, not even a graphically acceptable indication if an item has children or not), so, in the absence of any chances to have some really good PM functionality within UR and within reasonable time

- please understand that the functionality is there, and that I know that: you can do multiple clones of subtrees and create a "perfect" PM system this way, but graphically, it's so terribly cluttered then that I simply cannot cope with such chaos; if you guys hadn't had similar problems on a further-down level of things, you'd never had asked for hoisting, right? -,

I finished by cutting up my UR db's from 1 to 5 to 50 to more than 100... if I remember well, it was quant who incredulously asked how in heaven I could imagine such a collection of UR files to be "working". And indeed, it did NOT work for me. (In my last months with MI, I had done almost the same there, cutting up my db into many db's, hence my "need" for a trans-db search function.)

Within brackets: A search add-on for trans-db search in UR? Well, the big difference is not the additional payment, the big difference is that such an in-built function (cf. MI - but there's no Boolean search in MI, which makes it worthless for my needs) guides you to the very item in which the hit is found, whilst by using an external search tool (and even today, there are several such search tools able to search UR files, and even processing European characters correctly!), you will then have to open your UR db and do a second search within that db in order to identify the corresponding item.

schferk

05-03-2012, 07:32 PM

Another consideration of mine was, how would UR work on a slate, considering my almost 2 GB db? Ok, cut it up into 100 or more db's, so technically it would be feasible... but would it be reasonable? Of course not.

So, as many of yours know - since I related my export adventures here in this forum -, I finally went back to AO, from which I came four years ago.

Now it gets interesting, since at this time, some 6 months after my transition, I've got about 500 AO files; of course, these binary files are much more suited to such file multiplication than single db's: 500 or more UR db's within the same system, when you say, you can't understand why people would have more than a single one? And by the end of the year, I'll certainly have a thousand or so.

I know that out there, there are some advocates of the "single file" theory, preferably within the ASCII format, i.e. without formatting, and they go to great lengths explaining you that outliners just offer something the file system already has on offer for you.

Well, these people are tremendously mistaken. Does anyone imagine you could manage 100 k of single files within a file system, in any manageable way? Storing, yes, but processing? (The advocates of such systems praise various naming conventions by which you then could filter, and yes, they squeeze multiple tags into one single file name, easily...)

In fact, my AO files contain anything from 20 to perhaps 800 items, and if in doubt, I avoid additional sub-levels, inserting separator lines instead: This gives me a good overview of something which "normally" would be an intermediate (but unnecessary) level: Grouping things, clustering things is always preferable to subordinate things (and my cutting up a monster db into up to now 500 single files is another embossing of my underlaying philosophy.

You will observe that I'm here in the vicinity of that old debate "outlining or tagging"?, but than, as with "100 k of single files" vs. "1 monster file with 100 k of items", there's always the right thing to do FAR AWAY from these extremities.

Yes, today I'm against monster files, and I would never come back to them, seeing that their developers are unwillig to supply them with a "super system" that allows for immediate handling of projects, of reference needs, and so on, but continue to force you into their "chaos systems" (cloning and hoisting is very good for a start only, but when you'll have got 2,000 cloned sub-trees, you'll have got an impenetrable jungle, not an information management system of any value anymore).

But this, in no way, will make me desaffect trees, outlines!

I've got two principles in cutting up: Make it self-contained; make it as tiny as possible (and a third one, derived from the two, would then be: and don't bother if one has got only 10 items and another a thousand: don't try to "normalize sizes").

And then, for everything "pm", I use the file system, which offers, as you all know, (sub)directories / (sub)folders, links (= references = "clones"), and, among others, the "comment" attribute.

Then, you have some rather good file commanders, and whilst others can't even display these columns, some of them are able to filter by various "tags", trigger codes, etc., and with an extensive macro / scripting system (and with additional trigger keys, e.g. those of your numeric keyboard, simple, with control, with alt...), you'll realize a really good workflow indeed, and whenever I switch from my browser back to AO (i.e. with all the content I need, within multiple clipboards), my systems brings my back to a screen where AO has three fourths of the screen real estate, whilst a file commander, just showing a simple list of file names together with their "comments", takes the fourth fourth of my screen.

But then, most people out there didn't even replace their Alt-Tab with a simple key, or put their shiftlock key to a better use.

Now compare with my system that's perfectly scaleable, as said before, in both directions: No problems with slate computers, and a big corporation with 10,000 or more staff can rely on such a system easily also.

Nobody can blame me for not having tried with outliners, cf. my contributions for a better MI, than for a better UR - but instead of just complaining, I've got the means to do my own thing. I don't critizise UR for what it is; as said, in ancient times I created my own monster file application. But since I didn't get ANY help or encouragement whatsoever in my tremendous efforts to make other people's monster file applications really good, I stepped back from that concept I today consider obsolete.

It has been today that somebody on the outliner sw forum pretended, in writing, that UR had stopped development, and that brought me here, in order to check for any news on that. There wasn't any, so I seized the opportunity to relate my findings, grosso modo, of these last months without UR now:

I finally got my 3-pane outliner. And you know what? At this very moment, I'm considering begging file commander developers for enhancing their products, since of course my system, as elaborated as it might be in direct comparison with traditional, self contained "outliners" like UR and similar ones, is always a little bit rudimentary as I see it, but even if these file commander developers let me down, as have done outliners' developers, I'll do just more and more scripting, and I'll all get what I need even for the most elaborate standards.

And I even have got divider lines within my file lists there, i.e. I managed to group files within several groups on the same level of subordination, and any combination of data is now available on my fingertips... and ONLY that. I only see those 30 or so outlines I need for my immediate work, and if ever there's missing something, I just do a single further key press, and these parts of my information system get available, too.

I've said it a thousand times within this forum and the other ones: The problem of IM (information management) is not a technical one, but a conceptional one, and not being heard is not necessarily being wrong.

In the outliner sw forum there has been a discussion re granulation of information recently, i.e. how = up to which atomic level information should be cut up (I'd been heavily into these questions 15 years ago, so nothing new for me here). When you, Mark, want to do an outline within an item, it's exactly that problem you're discussing; when MI user (and history prof) "wsp" touts MI (and rightly so) within the outliner sw forum for the former's ability to reference not only items (as UR does) but paragraphs, it's again information granularity he's discussing.

There might be a lot a theoretical possibilities to that, and indeed, on that champ de bataille, I've got my very precise ideas also (just for a start: cut it up into sentences as the atomic level; do 1 sentence 1 line within monster text files (any formatting being encoded by special characters that are resolved accordingly, afterwards); do heavy referencing, cut up the monster text files into as many monster text files as you need for your big corporation... but do all the technical processing on a referential level, processing "atoms", not any more half-way physical combinations, and half-way references to other parts in other physical combinations).

But on a practical, application level, with what we've got today, everybody must search for his individual solution how he will granulate, then re-combine his information bits in order to make them useful for him, and all I can say now, after 6 months' heavy information processing in and out of my new heteroclite, scratch, homemade system:

It works like a charm, and it's the first of my many information systems that does so. But it stands and falls with both components:

Hierarchical systems are a necessity then, provided you hold 'em flat and combine 'em ingeniously.

And yes, kinook could have done this, within UR's borders, not for big corporations, but for all those freelancers and 1 to 5 head business gathering here. But instead, they don't do any super system that would drive UR into another sphere of utility. Cannot help those, but could help myself.

Yes, We Can Do. Individually. Ingeniuosly. Don't be customers, you'd be waiting forever for the manna to come.

schferk

05-04-2012, 06:09 AM

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

05-04-2012, 12:05 PM

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

Nobodo

05-04-2012, 01:52 PM

schferk

05-07-2012, 09:46 AM

Mark, that wasn't any criticism on my part, I was just explaining there isn't but hijacking threads, there's also multiplying them, and yes indeed, there IS another thread asking for outlining within UR items, since i've read such a request here well before 2012, but then, it's not about "who's right and who's wrong", my interest here is conceptual development. Perhaps I should just have said, well, look at the title you gave to your thread (= not "outlining within items?" but "proper outlining?"): Wasn't it inviting for third-party hijacks entering the vessel and shouting, "well, there is indeed, and here's how to do it in a perfect way", i.e. asking for "proper outlining" could not but force me into answering that fundamental question, since - excuse me - I'm just one of that handful of specialists worldwide who are able to answer such a question in A (= not necessarily "the") proper way. So, you really and thoroughly "asked for it", but then, be assured, it's my purpose to present worthwile findings, and not in any way to aggress fellow contributors of this forum, hence my DOUBLE excuse for the "boy" when not one such was expected or asked for. As for obscurity problems, references to material elsewhere can be considered secondary to my purpose here; in fact, my presention is already almost complete, and wading thru it is, while intellectually demanding possibly (let alone that my language is French, not English), worthwile for anybody doing work in the IM industry, and perhaps useful, for some bits of ideas here and there (cf. below), for every UR user wishing to use his UR db to its fullest potential.

Some more details to elaborate on my white paper

I very much hope that UR users will understand that even for using their current UR setting, there's a lot of valuable advice here, so I hope my posts will be useful for UR users that will remain happy UR users, and without mentioning the fact that there's a lot of flat-file discussion to be found (= the above-mentioned 100 k items in 100 k flat files folly) in the Scrivener forum - i.e. they allow for presentation / discussion of alternative ways of IM, not censoring these in spite of the fact that it could lure just some Scrivener users away from the database / integrated sw philosophy away and into a totally different workflow.

I perfectly acknowledge that UR users having taken the decision to do their stuff within the concept of "one db for all" will not leave just because a defactor tells them he's quite happy for having left. In particular, the "joining" of "other" subtrees (= i.e. "standard reference material" for such a project, etc.) to a project's subtree is realizable with my system, and also within UR or another "complete" db. I want to explain that a fundamental part of my system is to do LESS hierarchies, and MORE simultaneous displaying of currently needed elements (items / subtree within a db setting, files within a files setting) within the same (necessarily "hoisted", be it by means of file filtering in my system, or by means of hoisting within a db) "list" (= of items/subtrees, of files), using separator lines to do reasonable grouping, i.e. have one big group for your current project in the true sens of the word (if necessary, further divided into subgroups, with more divider lines), and have another main group for reference material (left unchanged by your processing that current project in question), or more than one such additional "reference material" or "to be considered also" or whatever group of material. This way, you'ld work on a legal case, e.g., and your case = "project" would contain - as a lot more such "projects" would also contain - standard legal material to be considered for the processing of this particular project:

In your "one big file" system, you'd then have a succession of perhaps 15 subtrees (if necessary, divided into 3 or 4 sub-groups perhaps), each containing some more material (but within a subtree that should be as flat as possible, i.e. I try do hold these subtrees (= in my system, separate .ao outline files) just 1 level deep, with, here and there, perhaps, or or two siblings under such an item within that outline, but with perhaps 20 or 30 items = siblings, divided by 4 or 5 divider lines)). And you'd have another group of reference material, where again you would NOT have deep subtrees, but, far more preferential, 10, 20 or 30 rather FLAT subtrees, within a list of 10, 20 or 30 "items", accessible immediately instead of "digging deep and deeper" into multiple deep hierarchies.

I know very well that such deep hierarchies, from a technical point of view, don't represent any problem, but from a "man-machine interaction" point of view, flat hierarchies present the very big advantage to necessitate just ONE mouseclick (or arrow keys then Enter, peu importe) in order to browse multiple aspects there, and just ONE mouseclick (or pressing of a single (!) "back" key) in order to get back to your "main level" (= of that particular project), whilst deep hierarchies present a tremendous nuisance with their (totally unnecessary) additional navigation needs. Even rather tiny screens can display a list of 40 items (=subtrees, separate outline files, whatever) or more, so make sure you take full advantage of this simultaneous display capability! (We perfectly agree, on the other hand, that scrolling needs should be avoided indeed!)

We are presented with a slight problem here, in "all in one" db's as well as in file systems: If we want to "hold it flat", we'll have a much more manegeable work environment for our project then, but before, we must cluster 5 or 8 or a dozen of separate sub-trees (= in your db system) / separate outliner (or other) files (in my files system) together, instead of just copying / cloning one single entry = a single "higher-level" subtree, containing multiple subtrees in its hierarchy - but must we necessarily do this by hand? As said above, as soon as we've got such a FLAT representation of our material on our screen, for project work, both our overall view of our project and our navigational ease are greatly enhanced by our "listing elements" instead of "subordinating elements", so even a one-time effort to manually copy / clone these elements one by one will be worth the effort, considering that afterwards, we'll get multiplied rewards for it, but then, is it really necessary to do so by hand, in the very first place?

So, within a IM db system, it should be possible to select several items (be they singular items or subtree headings), then clone them all together, as siblings, into another position of the "big tree" (= into a specific project / additional context), and within a file system, it should be possible to select several items (= files, be they outline, Excel or whatever files), then create clones of them and put those into a specific context / project, which would be technically done by renaming these newly created clones (= links of various sorts, as the Windows file system allows for; by the way and in correction of a sloppy formulation in a previous post, my "xyz.ao" clones would indeed not be named "abc.xyz.ao" but would bear another suffix, according to your choice of the respective kind of your Windows file clones / references) in a certain standardized way. I acknowledge that for the time being, a program like UR has a big advantage over any file system-bound way of doing these procedures.

Re an element mentioned before: Don't underestimate keyboard accessibility of important commands; my expositions re keyboards / additional keyboards could appear of minor importance; in fact, to have, e.g. navigational, commands right on your fingertips is of far more importance than your possible having to wait, once or twice a day, for a global search result for almost 3 minutes, instead of having it available immediately. It goes without saying that any other additional sw you need to access with your main system, i.e. not only your web browser, but also (in case of, that is,) Excel, a calculator, a (bilingual or unilingual) dictionary, or whatever you need again and again, in your work, should be accessible by just one single key pressing, hence the importance of elaborate key assignment to the numerical keypad (whilst within all these additional programs, the key F12, e.g., could just get you back to your main prog (be it AO, be it UR, be it any other IM system), so there's no need, of course, to make available, by single key, all additional secondary programs from within all these secondary applications).

As for the integration of imported third party files into your system (.htm, .mht, .pdf., etc.), when I said you could integrate them into the same window that displays your main (= in my case, .ao, .pdf and .xls) files, I missed to explain how this could be done. In fact, there are two different system. The first would be integration into your main list, and here, the obvious solution to any possible renaming issue would be to not really rename your third party files, in order to preserve their original names, but to simple add a prefix to their names, with such a prefix being similar to your normal file naming / sorting conventions you might have elaborated for your workflow. E.g., you import an internet file having some 50 characters in its name, e.g. blabla(and much more).mht; you would like to import it into your "axz" context: very simply, you would rename that file "axz.blablabla(and much more).mht - and you're done, your imported file will appear at that position within your file list.

schferk

05-07-2012, 09:47 AM

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

05-08-2012, 08:27 AM

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

05-10-2012, 06:52 AM

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

05-11-2012, 01:04 PM

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

05-23-2012, 10:57 AM

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

06-09-2012, 04:20 PM

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/67_reasons_that_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

06-09-2012, 04:21 PM

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

06-09-2012, 04:22 PM

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

06-09-2012, 05:54 PM

Let me try:

schferk

06-10-2012, 03:40 AM

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

06-13-2012, 03:30 AM

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

schferk

06-13-2012, 06:57 AM

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

07-15-2012, 06:50 AM

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

http://download.cnet.com/ActionOutline/3000-2076_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

07-15-2012, 12:07 PM

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

11-10-2012, 10:43 AM

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.