Is it possible to do proper outlining?

[quant]

"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]

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]

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]

<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]

Originally Posted by Nobodo

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]

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]

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]

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

[Nobodo]

Originally Posted by schferk

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.

schferk,
I can assure you that calling you 'scherk' instead of 'schferk' was an accident and not intended as an insult. If I had actually intended to be insulting it would have been something more like 'schjerk', but since nothing intentionally insulting like that was done hopefully you can see it was a typo.

I'm sorry if you have read the kinook forum so much that people's suggestions in the forum category set aside for suggestions are becoming repetitive.

I would guess in a perfect forum world there would be an organizational system so efficient that all postings which might possibly be related to the RICHED32.DLL would all go under a single thread titled something like "Please post your reason here why Microsoft's riched32.dll should be left for Microsoft apps to use and not reused as a free rich text editor in this application". I suppose that thread might contain a lot of different reasons, but it could also be that people would be afraid to post in that thread because they might have mistakenly organized their posting incorrectly, and then the whole organizational system would just break down.

Anyway, I did not see a thread describing the same problem and asking about a future resolution to the problem. If there does happen to be one, I missed it. But one thing is absolutely certain - this thread has been so derailed that it really might as well not have existed in the first place. So much for organization.

Thanks,
Mark.

[schferk]

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.