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