Best of Both Worlds, Twice - I think this was the missing element to a perfect system: The "one db, one tree" nexus is dead.
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Dec 21, 2013 at 01:13 PM
Suitability for file management, of course - Chris doesn’t introduce the necessary editing function, some of us don’t do the necessary reviewing before posting. Sorry.
Posted by 22111
Dec 21, 2013 at 05:12 PM
I need to explain two things:
1) Recursion
I did not put entirely correctly above. When I wrote my IMS 15 years ago (I’ve said this before, I didn’t knew then how to construct a tree “component”, today I would buy one, but again not for building up a “complete tree”), I did “cascading siblings lists”, and fields/record fields for “natural parents” (= main parents) and “adoptive parents” (=any other parent = “clone heading”), and of course, any such adoptive parent had its “natural”, but also its “adoptive” children, as children. To this (theoretically infinitely) cascading set of children, I added a “build up tree” function, for printing, and for exporting into Word (97), and here, clones were NOT followed, in order to avoid recursion; this is far from a perfect way of doing it, but a “working way” at least: Whenever a “child” (of any indentation level) occured somewhere, it had to be an “original child” in order for its descendants to be included in the tree the routine built up, and a prerequesite for all this functioning without fault, I had checking routines for item moves which intervened whenever I tried to move an item “under” a new (“natural”) parent, and whenever this would have caused recursion, i.e. even in my whole body of items, possible recursion was avoided early on: Such moves then weren’t possible but under the condition to get a new “natural” parent for that item (and again, checking for that one), whilst the previous “natural” parent was to become an adoptive parent “only”, then.
As said above, most “outliners with clones” do not do anything like this, so it would be of interest to see HOW they avoid recursion, and/or “infinite trees”...! Btw, early versions of MyInfo, after its introducing the cloning feature, did not get the clone’s children with it, to begin with, which is another, quite radical way of avoiding recursion; then they amended this (and put its cloning feature on par with Ultra Recall’s one also for the “user experience”), but it would remain to see which way they “did” it.
Now, my concept of “independent trees” does not entirely avoid recursion, since it would allow “cross-referencing”, which implies introduction of external trees of parts of those into the tree-at-hand, and those parts could contain other references, and so on… and even if you have some checking routine, ulterior changes in referred-to parts of external trees could THEN create recursion: At least for printing / exporting ( to Word, html, pdf…), this must be avoided, i.e. whenever you “physically combine” those references, instead of just refer to them. Of course, you could insert “stoppers” instead: Not integrating the respective children/external subtree, but a single ref item saying”, here, refer to parts xzy of item number 1.4.3 above which would be reproduced here again” (and which would contain itself some more referential parts creating recursion perhaps).
2) The above-described “automatic fetching of relevant files” for your outliner items
I left out how to do this automatically, since within the corresponding tree, there are not even links (that would have to be synched then). In fact, imagine a traditional “file plan” of a big corporation, like in the Fifties, i.e. for physical files. Traditionally, such file plans were numerical, e.g. containing “folders” (file groups) like 1.5.3.2.4. Now I devised a more modern system, ABE, FDGH, but where individual (physical or electronic) files would be named “ABE - blahblah1” and “FDGH - blablablah24894”, whatever. Now, the software/script just considers the “non-comment part” of all this, the “ABE” or “FDGH”, respectively (and since we’re speaking about an abc here, not about digits, most corporations would do perfectly fine with up to 4-character codes, not more: 1 “level” is at least 26 sub-directories, not just 10, and now multiply 26x26x26 and compare with 10x10x10, and you can even have lots of mnemonics here, at least for the “really important stuff”), and for every thing you have in your system, you are free to rename the “comment part”, the part between the code and the file extension, as often as you want (which introduces the possibility to insert ToDo/delegation/etc. codes here) - the whole system is held together by the coding part, those “ABE” and “FDGH” where, of course, “ABE” is a sub-group of “AB”, which is a sub-group of “A”.
And that’s the core part of my system, since it allows for automatic “adjoining relevant documents here”, from anywhere: physical files, special folders, e.g. Outlook folders, ditto for IBM (formerly Lotus) Notes, modern MS mail (Exchange), whatever, and whenever there is no such “totally correct” FDGH” folder there, the corresponding “FDG” folder is “looked up” and displayed, or in an ulterior system, just its content would be displayed within your IMS - and if there is a “FDG” folder in this folder sub-system, and just a “FD” folder in that folder sub-system, those “differently indented” contents will be automatically retrieved from those sources and then combined, and this means, you will have some folders very fine-grained, and others less so, according to your respective needs: no necessity, but always the possibility, to have a folder “FDGH” for just one file, and another folder “FDGK” for another single, or then, you could have 5 files instead in a folder “FDG”.
As said, you can integrate such a system into one IMS, you can prototype it beforehand with a combination of IMS, file commander (a free one like FC will perfectly do here), and with other programs of which you directly access the relevant internal folders by script, e.g. Outlook, but perhaps also for TheBat! or such, and since data is spread over applications, it’s all perfectly scalable, whilst at the same, access rights M and all this can be done within the central, the core application, and then there would a “display component” to visually gather all this - even what today is your “outliner items” could/would come from an external application/db, and just be “fed in” into this visual component, which only “lives by” lists of links and the necessary viewer components. As said, such a system would work for 1 man/woman, or for an administration like the NSA.
And that’s why I don’t advocate “internal search”, but here again, just “internal decision” WHAT is searched, and then an external search component would search anything relevant / provide the results for anything relevant from its central index, and would trigger the routines which “feed” those results to the viewer part. Such a system would also be perfectly safe, since the “clients” would “own nothing”, just make demands, and if the central compound says “yes”, get the results which are deemed to be “deliverable to that destination”.
So what I have in mind is a very “slim”, elegant architecture, in which there are man central “agents” that combine relevant elements, and in a second step, AI should allow for automatic combinations and/or automatic add-ons of further elements to “manual” combinations, too. It goes without saying that the different “seats” in such a system would have quite different “access rights”, and I’m aware there might be corporate sw that “does all this” even today; but since it’s not known you can buy such sw even for 5-seats corporations, at 500$ per seat, there seems to be a market for this. And yes, scanning of documents should be easy, together with easy (automatic/half-automatic) “tagging” of such additions, i.e. the manual entry of the respective “IGHR” code for each such document should not take more than about 5 sec., by selecting them from some restrained list, pre-restrained by sw already.
All this is easy to design and to code; proper collaboration/versioning (which is also needed in such a system) is intellectually much more demanding.
Posted by Cassius
Dec 21, 2013 at 11:39 PM
Brevity, dear 22111, BREVITY!
Posted by jimspoon
Dec 22, 2013 at 05:34 AM
22111, if you’d like to give ecco pro a try, have a look here to see how to have better luck installing it -
http://www.outlinersoftware.com/topics/viewt/4642
The Ecco Pro extension is now located here:
http://groups.yahoo.com/neo/groups/ecco_pro/files/EccoPro%20Extension/
you’d have to sign up for the ecco_pro group to get it. current version 4.6.7.4.
alternatively i’ve uploaded all the files you need here -
https://drive.google.com/folderview?id=0B70vHg-eiSTYeU1YZ0lRdEF0Skk&usp=sharing
I still use Ecco daily, but it’s been a long time goal of mine to switch everything over to Infoqube. The reason is Ecco has limitations on the number of items it can handle. The Ecco Extension helps with some of the limits but there’s a limit of 64K total items and I want to be able to put many more items in my database.
It is still a very useful program, and is still unmatched in some ways.
Posted by 22111
Dec 22, 2013 at 05:27 PM
Pierre Paul, see below.
Jim, thank you very much for the consolidated download link of yours, very useful for getting some INFO on that mythic program at least (even though I don’t intend to put real stuff into it).
I also intend to have another look into IQ (no screenshots showing it’s a 3-pane outliner the way I conceive them), as well as looking again into Zoot.
Thank you, Cassius, for reminding me, I just left out some technical developments that weren’t but in an early stage anyway. (You know, just as a year ago, I’ve not found a solution to the problem how to best cut up info into bits, then semi-automatically recombine it again, yet; some extensive general discussion of this core problem here would help our “industry” enormously.)
Please let me say here that in the end, I just want a “much better, and scalable, 3-pane outliner”, but with dedoubling of the outlining. In fact, 1-pane outliners’ “original idea”, if I dare say, were to “treat one subject”, not two, not 200 or 2,000. Then came 2-pane outliners, and they were originally intended for doing the same, but with a different visual repartition of the “construction info” on the paper, then on the screen.
Then came pc’s, and especially, more power to any such pc use (for this and anything else), and then both users and developers fell into a trap: Since from the purely technical pov, it’s possible to have a monster tree where the 2-pane outliner now contains 2,000 different subjects, with any possible number of items and the conceptional chaos that comes with that, whilst this concept had never been invented to store massive amounts of (and then not even coherent) info: The big mistake here was, yes, it all can be placed within one tree of exploding size, and technically be managed, but you use the SAME tree for navigation within your current subject (as in what you “naturally” would have placed into a 1-pane outliner), AND for that “upper layer” in which you then manage your different subject (and their various interaction).
So the problem here is that today’s 2-pane outliners are used in a way their conceptual construction was not meant for (because conceptually, they are 2 piles of paper: the content sheet to your left, and the content sheets to your right: just as 1-pane, but to be handled concurrently, not consecutively, bot both for “one thing only” that is to be developed).
As you will remember, I tried to get the 3rd pane, the “PM pane”, into MI, then UR, to no avail, both developers never introduced it. I had been put off by existing 3-pane outliners, though, because they (as much as I saw, i.e. my possible bad by overlooking important variants), because of a very important detail many people possibly are not aware of:
My basic 3-pane concept (and I very much hope the IQ concept, too, but not the current Zoot concept I’m afraid of?):
1) Tree 1 for PM, and which only contains references to trees
2) Then, multiple trees which are conceptually “equal” (= equal by sw design, by sw architecture, not at all by “importance” or such)
3) Then, the content of the items in the respective, current 2) item
(That in my concept, 2) and 3) are doubled, for independent 2)‘s or, in 3) for some “sub” of 2) (and then, what’s 3) here, would become 4) and 6), see my original post http://www.outlinersoftware.com/topics/viewt/5198 , is not important here, neither it’s important that in my system, files from the file system would be “mixed up”, in real-time, with those “internal tree items” (cf. what does UR, e.g., except for the fact that they only resynch manually).)
Now for what I know from 3-pane outliners (which are very rare anyway):
1) Tree as above, but NOT for PM, because
2) NOT a tree here, but a flat list only
3) As above 3), the content of the item currently selected in 2)
This is a very important difference; traditional 3-pane outliners do NOT offer independent trees (in 2) held together by sort of a “super-tree” (in 1), but if you try to use a traditional 3-pane outliner “my way”, you lose the outlining function and end up with a PM tree giving access to multiple flat list, and whilst it’s right that I always advocated my “hold hierarchy as flat as possible” philosophy, I certainly never came to outliners in order to give outlining up!
And as we all know, there could/should be a third outline, the “inline” outline, within the above 3), but it is the missing outline in 2), in the traditional 3-pane concept that makes that this concept, traditionally, isn’t but a variant of the 2-pane concept, but not a really new one.
Pierre Paul:
I installed the current IQ, will run for 8 days; most trials permit more, but then, it’s obviously because the Year ends in 8 days, no prob.
I did “new file”; I did “new item”; I did not even see the new item; ditto for a second one. Initial problems even with item creation are blatant with UR, but with IQ it’s much worse.
I don’t need a “grid”; I tried “Projects”, “Journal”, etc. - my 2 newly created items appear nowhere. I see there are different “intros”, nothing concise (hello, Cassius ! ;-) ), lots to read, no hint where to start.
Would you be so kind and to perhaps start a new thread here, in order to give a step-by-step intro what to do in order to have IQ as a 3-pane outliner, with an outliner in the first pane, and then an outliner in the second pane (and then the content for the current item in the second pane within the html content field)? Also, how to create a second outline (= a second entry within the outline in pane 1) if there is any problem to it? And all this in the CURRENT beta, please?
Or did I misunderstood you? Was your hint about “individual outlines within a common db” only (as is with CT), and in your current beta, there is NO succession of two outlines, on “first” AND on “second” “level” (attention, this denomination could be misleading since the first outline in itself should have multiple levels, and that second outline is “second level”, though, in my concept, whilst the “real content” is “third level”, even when in a traditional 2-pane outliner, it would be “10th level” or anything).
It is NOT my intention to “be right” here, it’s just that I spend 30 minutes with your program and do not want to spend 3 hours with it, just to then discover it does NOT fulfill my “new” 3-pane outliner concept - just tell me how to find out if it does.
And please allow for a short remark: Even when I am in one of those “grids”, “To-Do’s” tab, where I have the full menu, and if I here “am” at the last entry, “Have lunch with Mary”, then do “New item”, there is no child, no sibling, no new item within the whole list. Are you aware that from such an experience, most prospects would say, “Ok, I could trial for 8 days, but these 8 minutes have been enough for me, thank you.”?
Again, it’s not a play “who’s the better sw architect” here, but such non-accessibility to sw in a trial situation is strictly unbearable (and immensely harms your potential business).