Sidestep first: I've said this before, but to no avail: Whilst MS Word formats level x of your outline this way, level y that way, right as you want to have those, NO outliner of my knowledge does so. Of course, this must not interfere with your own individual formatting, i.e. you should remain able to bold some entries, to underline or italicize others, but nethertheless, the outliner should have standard level formats which you enter as "styles" for those indentation levels, and this could be realized by color or background color (not only dark colors with white font (which would perhaps be ok for levels 1 and 2), but also, e.g., a bleu or chamois background for that line/entry/item if it's level 3 or 4). Such a system would greatly enhance navigation within outliners like UR where you will end up with a 5- or 6-digit number of items within one single database.

Now first subject of the above, just as a reminder: "Mix up" your files, and your outliner entries; no file synching necessary; just links to folders, and then always-up-to-date run-time display of those files in your item list in your outliner, and access as any internal item, via multiple viewers within the same frame; see my post some weeks ago which developed this concept and also a three-frame display for large screens.

And now for again a "best of both worlds" concept which, as the above one, might revolutionize the outliner world - and now imagine those combined...

As you know, there are db-driven outliners, and text-based outliners, hex, xml, proprietary formats of all sorts. As you know, good search, and deep-linking (= links to individual items) only are available for the first kind.

Thus, the first kind seems to be preferable from this "immediate access to anything" pov (incl. easy updates where necessary, i.e. no additional db's that monitor numerous single outliner files, for necessary updates within them) - ONE db.

On the other hand, such a concept bears the above-described problems, you'll get (more or less) "lost" within your 5- or 6-figure number of items, let alone scalability within a corporation or such; the big-tree quickly becomes too big, let alone access rights M - who's entitled to access what? And what about response times?

I should say that I never delved into db expertise; what I know about relational db's, is just what about "everybody" knows about them, so it might be possible that what I'm saying here is not entirely new a concept, but even if it has been realized in a similar way, somewhere, it seems time to apply this concept to outlining... and then, perhaps, it's as completely new as it currently is for me.

The "trick", as I might say, lies in the breaking up that traditional "unit", "one db, one big tree", meaning, why not have one big db (for a start, and then, within a corporate network, this could be easily be scaled into clusters of db's, with some inter-processing between the physical data (physical access) and the logical access sw.

Why not have one big db, then, but 1,000 or more independent trees (and then it becomes so easy to manage access rights, too), which all take their data from the one big db... but with (if needed/wanted) complete search access to "everything" (or to what in your department and/or in your corporate role will thus be available to you).

Since I envision a 3-frame gui anyway (but technically, a 2-tree gui would even suffice here), there will be no problem to have one, but virtual, tree, just for referencing sub-trees, and then there will be those sub-trees (and as indicated some weeks ago, either you will have two sub-trees in frames 2 and 3, or you will have just one such sub-tree in frame 2, but with an additional document from anywhere (that same subtree, external data, or any other item from anywhere - of course, beneath tree 2 there should be another list for quick navigation within such frame-3 content, both just for navigation and for linking to it).

Of course, there should be "interoperability" within two such independent trees within frames 2 and 3 (and both listed in frame 1) - copying, moving, linking/cloning; in a corporate environment, you also could have, e.g., "writing access" to one of these trees, and just "reading access" to another one, or any other form of access, i.e. "new-writing access", but without "editing/deliting access", and so on.

All this is very easy to do, technically, traditional outliners just do "too much", by building up the "whole tree" for the entire db (entire file), instead of there being TWO such tree building-ups, one just for sub-trees (= levels 1 and 2 if you prefer to look at them this way), and then multiple such sub-trees of perhaps 20, 50, 120 items: just the kind of data that today, you stuck into the "intermediate" levels of your "big-tree".

And as these independent sub-trees (but which can be, as said, extensively cross-linked, which is not the case for 1,000 text files or such) are quite shallow/flat (as said, most would not even have 120 items), their building-up would be made by run-time, just from ID lists (in fact, ID arrays, since there would also be needed indentation and formatting info); this way, updates/renames (= anything for which you need "clones") would be very easy here, again to the contrary of a 1,000 xml files system.

Note that with a multi-db system as is possible with MI (since there is not only "search within the db" as in UR and such, but also "search within all loaded db's" and "search within all db's (within the working directory)", search over spread data is quite ok, but the same is not true for inter-db-linking/cloning. You will also note that the concept of hoisting is not as needed as in big-data trees anymore.

Thus, this new paradigm preserves the advantages of the db-based outliner, but does away with the unmanageable big-tree outliner concept. And it'll be scalable to any corporation size, whilst being perfect for one man/woman, too.

22111 wrote:

--------------

so it might be possible that what I’m saying here is not entirely new a concept, but even if it has been realized in a similar way, somewhere, it seems time to apply this concept to outlining… and then, perhaps, it’s as completely new as it currently is for me.

The “trick”, as I might say, lies in the breaking up that traditional “unit”, “one db, one big tree”, meaning, why not have one big db (for a start, and then, within a corporate network, this could be easily be scaled into clusters of db’s, with some inter-processing between the physical data (physical access) and the logical access sw.

Why not have one big db, then, but 1,000 or more independent trees (and then it becomes so easy to manage access rights, too)
--------------

I know of at least 2 applications that are designed from the ground up as you describe: Ecco Pro and my own InfoQube. And yes, IMHO, it is much easier to manage information using a number of "smaller" outlines than a single "huge" one !

Pierre Paul Landry
IQ Designer
http://www.infoqube.biz

The above discussions mixes up two or three different concepts.

First, we have dedicated file managers / file commanders. Here, you chose the directory/folder in your file system (internal hdd or external devices), and will then get a list of what currently is in that directory / folder, those entities can be original files, or links / link files, e.g. .lnk files (XT); I don't know if the most recent Windows links are necessarily files, too; technically, it would be possible to just have link entries in the file system which are not files on their own.

Variant: If you want to gather "project files", i.e. various files from different locations/directories, you create links to them, and which you put then into a new directory named after your "project", and which is a regular Windows folder which can, of course, contain such links / link files, and also original files; you can even rename the links (but not the original files, without breaking the link), or move/copy them to other folders.

Then, there is a variant, present in some of these file commanders, virtual folders. These file managers do not create .lnk files or such but create proprietary databases for files from any folder, from which then they display the db entries within a quite regular "lister", as they would display the content of real folders, and their specificity is that you only see those "virtual folders" from within the file manager from within you will have created those "virtual folders" and their respective "content" (= internal, proprietary "links"/references to real files) - this is all rather basic, and I believe I remember that ordinarly, the entry in the "virtual folder" is not updated together with a rename/move of the original file, but this "breaks the link"; this might not be the case today in every such program, though.

In practice, this concept appears much less productive than it seems to be "on paper"; I tried with every such file commander (not only for some trial days: I own some 5 or 6 paid ones, and then some free ones, too), and it's simply not worth it imo.

Then we have IMS's, outliners or other, which "read" files into their tree, their db, or whatever. Here again, we usually do NOT have a precise real-time "image" of what's in the file system, within a given folder, at any given moment, i.e. there is not, as is in dedicated file managers, an immediate reading of the file system entries, then display of these entries. There has been a little "discussion" in the Ultra Recall forum of you follow the link to the original thread within this recent UR thread: http://www.kinook.com/Forum/showthread.php?t=5219 .

But there again, you must differenciate between "just linking" which in UR's case means creating a link ITEM for this (which is the reason it takes some moments), whilst in fact, you also could imagine just a "list entry" within the tree, and the creation of a link item only then if you need that for entering metadata for that file (the abolition of ADS metadata within NTFS is catastrophic in its consequences for everyone, but then, Mr. Balmer or Ballmer did not do anything intelligent in his entire MS life, except for his own income), so real-time updating this could be speeded-up.

As said before, UR has two ways to do this, just linking (but with creating a link item for any such link, hence it's not that fast here), and another concept, importing the TEXT of that linked file (Word, pdf, some other formats) into its freshly created link item, if you set its setting for that import that way, and in this scenario, you can search the text of the "just-linked" doc from within UR, which in many cases is a very good thing - similar to TheBrain, where also some users use the IMS tool as a reference tool for thousands of pdf's. It goes without saying that in THIS case, importing/reimporting/synching a (big enough) folder to UR "takes hours", as has been said above (recreation of those parts within the UR index).

As I have said before, there would be a lot of synch work, and of maintenance for making this possible (renames/moves of linked files when UR isn't running, e.g.) if you tried to synch files - it's all very much easier when you just LINK to FOLDERS, BUT THEN DISPLAY THEIR CONTENT, this is not mutually exclusive, on the contrary - but such a concept implies that you do your "internal/further" linking within the file system, not within the IMS/outliner, i.e. an optimized UR would fetch the contents of your folder c:\abc every time you "go" to that "folder link item" in UR, and display all its content, incl. any .lnk files in that folder.

Now for what Stephen says about TheBrain - I do not doubt that all this is correct, but we are not informed how exactly TB "does it" (whilst I explained here how UR "does it"), so some further explanation on this would be very helpful.

As implied above (it becomes evident from the thread linked within the linked thread), UR does not do the synching automatically (and doesn't monitor renames, let alone moves), but starts a manual synch by keyboard shortcut, and that's my point:

Whenever an IMS is not able to monitor file system changes, any moment (e.g. by having a little add-on that's running anytime, even when the IMS itself is not running, then synching between this and the IMS whenever the IMS starts to work), you will quickly end up with de-synch, so this should be avoided imo, cf. what I described some weeks ago - it's perfectly possible to INTEGRATE a REAL file commander into your IMS, and that's then quite another thing.

This being said, UR's "manual synch" is not that bad, it's so much better at least that most competitors in which there is no such synch function, but where you would have to update all your links by hand - my current system is to display the respective file folder, in any file commander of my choice, together with the respective outliner folder, i.e. a macro checks if I move between "siblings" and such, in which case no new folder display in the file manager is needed, or if I "change" the respective folder, and then my file commander displays two folders, side by side, which is not technically necessary, but which I did in order to see "how it all works best", also in a possible corp environment:

In the left pane, I show "sibling" files, and current ToDo files, i.e. I apply two or more filters to a folder containing a 4-digit number of "standard" files, and in the right pane, I show "relevant" files, i.e. the file manager displays the respective sub-folder containing files "relevant here" (= original files or .lnk files, I always work within XP), which in my system is "external files", files from the web, downloaded pdf's, and all such (btw, when such a "deep" folder doesn't exist, the macro displays the folder "1-up", or, if that's non-existent, too, an even broader, more "general" folder for that subject, and so on - you certainly get the interest of such a concept for a corporate environment), whilst in the left pane, it's the "self-created files" for the same outliner entry/category.

I divided up those "files to consider here", into two different folder systems, because I think that for "internal files" (= my left pane), you need much more security than for "external files", so why not have them managed by the same macro/script/program routine, but from different physical sources (and as said, my separation into "one big folder, then filter" for "internals", and "deep sub-folder file sub-system" for "externals" is only in order to experiment with both concepts; in the end, you could choose the first, or better, the second one, for both kinds of files); as said, there should be an "end product" where you would not have links for display in a file commander, but real-time display, file-commander-like, in a frame/list within your IMS itself, together with the immediate siblings and links within the outline body; entries from several sources, put together in a breeze, and divided up there by separator lines, e.g. - I call this "natural hoisting", i.e. separation of the tree from your immediate working environment.

Again, it would be of high interest to know exactly how TB does linking/referencing, for single files, and for folders, respectively, in order to see where it currently stands between "regular outliners" and dedicated file commanders, and especially, where might be its possible advantages here over UR.

Pierre Paul, after writing the above (first post), I expected some argument indeed, but coming from a possible ConnectedText advocate, since in CT, there is one big items body, but which is NOT constructed as an outliner, and from which then there can arise multiple outlines (as they say), so I expected the above then not as brand-new as I had presented it (without thinking of CT).

Now this argument comes, but from a different "corner". I have to say I don't know EccoPro at all, since my try to install it, some two years ago, just brought my system down: It's very rare an application give my XT system a blue screen, but in about 10 or 12 years, the Ecco installation succeeded in this.

As for InfoQube, I don't know it well, but from my short trial, I didn't see it follows the above concept, I just saw the similarities with all those "big" outliners that all come from the opposite end of thinking, which is, "gather your stuff into a tree, and when that tree becomes too large, do hoisting, or break it up into several trees" (with MyInfo being the only (?) application which then permits global search over info within these different trees), and there seems to be no such application that currently is able to properly administer such a compound of different trees (which up to now, always means, different tree files).

If I am mistaken here, as far as IQ is concerned, I kindly invite you to describe its conceptual architecture, as I did here, these last weeks, for an IMS that would integrate such concepts and more but which doesn't exist yet.

Perhaps IQ is far more advanced than I currently know and did expect, and this would be exceptionally brilliant, but fact is, nobody here ever mentioned such outstanding characteristics of your IMS here, so I felt save to not suspect them within it (and a similar consideration would apply to Zoot: there, too, I make assumptions of functionality not being there for the unique reason that it's never been mentioned); so some detailed clarification would be more than helpful.

In just some word, my idea above (and which coming from quite another context, already has been realized, by CT, and probably by you) was that from what I see, outliner developers "all" (? so you do not? and that shows in the architecture of your IMS?) apply the idea that there would be a big tree for anything within the db, a tree of 100,000 items if there are 100,000 items in the db, whilst I say (and perhaps you said, before me) that those trees could be stored in one big db, but should be totally independent from each other, and in my concept, there would not even be the possibility, for the use, to combine them all into a bigger tree, whilst technically of course, this would be feasible, in spite of any possible recursion problems (you either create a monster tree, or better, you just follow "natural parentage", not also "step parentage", but of course, that will leave out some info that might be really important here and there.

But then, I just do not see the necessity to build up one big tree from it all, so I don't see the necessity to resolve such recursion problems that only would arise then (= from a practical pov; from a purely technical pov, you could "manage" even lesser trees to be outrageously self-recursive).

Btw, I suppose that ordinary outliner developers do all this "child-driven" design in order to avoid recursion; it's interesting that (from what I remember, I might be mistaken here) all of them who do "clones", then do not distinguish the "original parent" (which should be replaceable, btw, by a new one) from any new "step parent" then. And all this means, in other words, they do the "big" tree, because in programming, that's easier than having independent trees with deep interlinking, and from which then you would build new, virtual trees: Here, without real good programming, you could create broad chaos.

So, in light of what I say here and in the other thread, it would be of high interest to know what IQ really "does", behind the scenes, and if it overcomes some traps ordinary outliner developers avoid by "holding it simple" - much too simple, for me, and if you see it similar to the way I see it, that would be a big step into a new direction from which much better end products could come to the user. If it's already there, in IQ, you hid it well! ;-)

"The above discussion[s] mixes up two or three different concepts." referred to the original thread, of course:

http://www.outlinersoftware.com/topics/viewt/5223/5

in which the possible suitability of The Brain, and of Ultra Recall, was discussed, but without going into the necessary details, there. Sorry for not adjusting my post after shifting it here.

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.

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.

Brevity, dear 22111, BREVITY!

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.

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

Jim, just to have a good laugh, and without implying you might have done anything wrong, in fact I'm 100 p.c. sure of the contrary:

I activate your link, then click on "Downloaden", then get this (yes, in FF, not in Chrome (!), I get continually "tortured" with a language I don't speak, by Google, and the "English" setting does not even hold for my current browsing "session"):

https://drive.google.com/uc?id=0B70vHg-eiSTYYzY5RlIxaURqSmM&export=download

Dit bestand is geïnfecteerd met een virus

Alleen de eigenaar kan geïnfecteerde bestanden downloaden.
© 2013 Google - Help - Privacy & Voorwaarden

Worse, it's impossible to download "notwithstanding", their refusal to let me download the sw is complete.

And worse even, clicking on the pdfs shows them, but in a very special google format not permitting to download the pdf's.


Btw, both EP and IQ seem to rely extensively on "grids", whilst most people wanting the "perfect outliner" will not necessarily want to have such proprietary data storage; I'm aware of possibilities to store "access metadata" this way, but then, many programs are not able to search for "greater/tinyer than" there anyway, let alone calendar data ("before/after that day").

Since we're discussing so many different things here: In my ancient sw, I even had implemented a (very basic but functional) addition function, which means that command added / updated the addition for any value within a "cost" recordfield in all its children (of any indentation level of course) and wrote it into the "cost" recordfield of the parent item from which that function was triggered; of course my intention was to provide some sort of PM functionality, not of the Gantt chart kind, etc., but at least of the "what will be the compound cost of these activities here?" kind, and of course, I had a second such function for adding "processing times".

But my point is, this sw remained "textual", "normal" sw, just with some additional fields not bothering anybody (which also should be made toggles: display them only in sub-trees where there are such fields with content, i.e. where you want to see them (which means there should be a command "show field xyz here and hereunder" available everywhere), whilst both EP and IQ seem to have grids as their "screen-filling" feature, with textual content being relegated to "also available", and if I have such needs, I use Excel or a dedicated db like Access, no? Just my 2cents on that.

22111, sorry about that! Google Drive doesn't seem to be a good tool for simple file sharing - for one thing it wants to convert files to and from Google file formats. Perhaps Dropbox will work better for sharing these Ecco files - here's a link:

https://www.dropbox.com/sh/wgcy1a4m9bjb1o8/j3CMqzSGkx

You're right, Infoqube does display data in grids, but it is possible to use it as a simple single-pane outliner - you can hide the other panes. And you can configure a grid so that there are no columns being displayed but the "Item" column. With Ecco, there is a simple Show/Hide Columns command, so you can hide all columns to get a simple single-pane outliner, and quickly toggle back to a grid-type display.

Infoqube uses the common MS Access file format, so it's fairly easy to get data in and out of IQ in a usable form. Ecco has various export/import formats including CSV.

Thank you so much, Jim, those links work beautifully!

I very much hope to get some hints from Pierre Paul how to use IQ in the manner I have described, but then perhaps, it was again wishful thinking of mine.

Btw, that's the big advantage in MyInfo: Anybody can just download the program, then will start to do real work within less than 5 minutes, and that's so important to get a large user base. Interesting db info, btw, so it's Access for ("impenetrable") IQ; MI's one is called "proprietary" (whatever that could mean), TB one's a Java thing I learned here, EN and UR are SQLite "overlays"...

It would be of interest to further complete this list. Firefox, "anyone" (any such outliner)?

Or then (why not) mySQL or PostgreSQL?

It's interesting nobody ever mentioned FileMaker in such a context (and Access is not ideal from various pov's, but very cheap, i.e. even the 200$ version allows for OEM'ing it into your commercial applics; of course, there is always MS SQL server).

Btw, I spoke about the German Surfulater competitor WebResearch - they got TWO versions for their website repository applic, the regular one being based on Access, and their corporate version being based on MS SQL server - probably, Pierre Paul does this in a similar way - and possibly, transition of code from Access to SQL Server is easy, so that this would come "natural" (but that is speculation only).

22111 wrote:

As for InfoQube, I don't know it well, but from my short trial, I didn't
see it follows the above concept, I just saw the similarities with all
those "big" outliners that all come from the opposite end of thinking,
which is, "gather your stuff into a tree, and when that tree becomes too
large, do hoisting, or break it up into several trees" (with MyInfo
being the only (?) application which then permits global search over
info within these different trees), and there seems to be no such
application that currently is able to properly administer such a
compound of different trees (which up to now, always means, different
tree files).

IQ is build around the concept of items, not around that of a tree. Items are like individuals, they exist, like you and me. They can have parents, and can have children. They are all "identical" and differ only by the values you assign them. (No such thing as a grid item, or a calendar item, etc)
As such, IQ provides many different views (or take) of your data. Some of these views use trees, others not.

But then, I just do not see the necessity to build up one big tree from
it all, so I don't see the necessity to resolve such recursion problems
that only would arise then (= from a practical pov; from a purely
technical pov, you could "manage" even lesser trees to be outrageously
self-recursive).

IQ supports recursion. So item A can be a parent of child B which is a parent of item A.

IQ supports multiple parents which can be freely assigned and unassigned. The concept of "main parent" is only used to display context parents in views that do not support multiple parents (such as tree-grids)

IQ supports many forms of automation. Inheritance, triggers, row equations and column equations (i.e. hierarchy equations, such as sums)

HTH !

Pierre Paul Landry
IQ Designer
http://www.infoqube.biz

"IQ is build around the concept of items, not around that of a tree. (...) Some of these views use trees, others not."

Pierre Paul, that doesn't answer my question how to create an item, or more precisely, why I don't see appear items I think I've just created. But thank you very much for the clarification, so for my "big claim" in the title of this thread, we're back at field 1 - in fact, I had trees in mind, and it suddenly had occured to me that EVERYBODY up to know seems to think that "1 tree - 1 db" is sort of "the law". In CT, items are created in a wiki, in IQ, they are created, if I understand well what you say, either from within a tree or independently from any tree - voilà, those two concepts not applying the "1 tree - 1 db" rule don't necessarily rely on trees to begin with, they are both more "db-like", with trees as additional "goodies" available when the user needs to build up some tree.

In my concept, any item would depend on at least one tree, i.e. even inboxes would be such (flat) "trees", there would not be any part of the program where you could create any item, other than from within SOME tree. Thus, I see that alternative concepts always made a freer use of db's for trees, but any "outliner developer" clings to the "1 tree - 1 db" paradigm.

I stated anyway, some weeks ago, that I consider the developers of CT, IQ, TB and Zoot (alphebetic order here) to be top-notch, so it's no surprise that alternative concepts come from this "corner", and not from the likes of MI/put in your preferred traditional outliner here.

To be very frank, I hope to devise something that will not put off potential users; I try to remain within an outliner concept (I gave the reasons some weeks ago: I think context, and respective order in those contexts, helps with working ON your items, to find additional things "between" those; as I see it, tagging systems (= where the order is aleatoric or alphabetic or chronologuous by creation date or such) cannot "do" this for the user. "Frank" - well, I suppose, perhaps wrongly, that both IQ and CT do not have very big market share; both step away quite far from the traditional outliner concept. My concept, though, for the "user experience", will remain within those borders, just that I would like to reinstate the possibility to do "real outlining" in pane 2 of 3, into 3-pane outliners - but I had to overcome, in order to see how to realize such a thing best, that "1 db - 1 tree" outliner commandment: it's so much fun, but it has got a serious background, it's the "lateral thinking" applied which you'll find here: http://funnyexam.com/answers/popular/14790-yeah-centi and in many other such examples - You and CT did something QUITE different; I had to follow the same thinking steps in order to devise something quite traditional, just much better, but always within the tradition. (And thus, I hope it will not make put off potential users; I think gui questions (intuitive use) are predominant for sw. I want outliner users instinctively feel at home in my "better outliner"; I didn't fee at home neither in CT nor in IQ I must admit.


"IQ supports recursion. So item A can be a parent of child B which is a parent of item A."

I jumped at your term "supports" since recursion is a problem as I see it, and which installs itself without even asking you; it's not something you would have to provide the user. On the contrary, you have to handle it; allowing recursion in a print job, e.g. - oh là là ! I would have to delve into these questions anew, they are quite complicated.


"IQ supports multiple parents which can be freely assigned and unassigned. The concept of “main parent” is only used to display context parents in views that do not support multiple parents (such as tree-grids)"

This reminds me of a very important point in design, too. Readers, please read this citation as a package together with the previous one about recursion. In fact, in my ancient sw, I did (as I said) tree-building for export and for printing by this "main parent" concept, thus avoiding recursion. But then, I'm fully aware this was an easy solution which for many real-life scenarii is NOT valid, since to the contrary, the user would precisely want to follow "alternative streams", alternative data sets (sets of items), so such sw should permit "bifurcation choices" - btw, I spoke of semi-automatic new-tree creation, and here we could have some key to doing that.

So here again, you see that I am willing to strictly obey to the tree paradigm - and it seems to me that my cutting up that body into multiple trees will greatly facilitate recursion avoidance / divergence M, since the "divergence points" become easily identifiable - I said it before, in the end, we should devise some semi-automatism for "this partial context within this task/project, this slightly partial context within that one", and I strongly suppose that we could realize this by allowing "guided step parentage", and here again, we would have to avoid recursion (which is an "industrial accident" when it occurs, not some "advantage" to the user).

Sorry for having taken your "IQ supports recursion." as my starting point for these considerations but in fact, an intelligent tree M will avoid recursion, whilst a wiki / independent items cannot do this. Or then, somebody explain the "recursion advantage" to me, please.

We have to invent "variant support", not "recursion support", if I'm not entirely wrong here. Sorry again.

To explain the concept behind IQ, nothing beats a live discussion. Every new user is entitled to a free 30 minutes phone call to jump start you on using InfoQube.

Please feel free to ask by registering on our community web site and contacting me privately. I'll be more than happy to chat with you.

I can of course try to answer it here, should you prefer, but my time is limited, being busy on a IQ dev. so I can't always promise speedy responses.

Pierre

"but my time is limited"

Thank you very much, Pierre, for your kind offer. But you're aware that as a general offer to everybody, whilst it remaining more than kind, it's not that efficient when it comes to full those about 30 minutes with answering questions that should not even be necessary? Don't try to do videos, which take time to produce and are not really step-by-step instructions for people who then would need to put the steps they see there, on paper first in order to follow those. But bear in mind what somebody not "knowing about" IQ would need to know about IQ within the first minutes he tries to use this program, for very basic work, and then try to do a "first steps" paper for this, which you would place priminently on your page. This would not be about "how to do something similar like the pivot function in Excel", but about what I described above, create a new tree (? list, whatever), then create some items there, and have them as siblings or children, etc., i.e. exactly the task that is so easy in a (non-too-basic) MI, and so much more difficult in UR, and seemingly impossible in IQ. Just bear in mind that people NOT willing to read more than 1 page of text should be able to do the very first steps alone, too, THEN perhaps even counselling by phone would be an extraordinary step to broaden your market share, since I've never heard of such an offer by any of your competitors. But having to explain the most basic basics, again and again, on the phone, is certainly not the best approach here for a developer who's time is limited, no doubt.

As said, when after the "new file(or whatever, since you say it's within the same db)" command, I create a new item then, I don't see that item, and at this point, most "triallers" will close down the beta, without calling. And then, this "grid" is kind of a "service" to those of your customers that "want more", but it's not the perfect display your sw for "beginners", let alone those who come from other outliners, so the default screen should be much more "visually accessible" - to give another example, it's a fact that Zoot's default screen can be changed in quite a spectacular way, but then, nobody understands why its developer insists on presenting Zoot, to prospects, in its traditional visual aspect which certainly makes instantly flee many (if not the majority) of them - and what I see when I first open IQ, is worse than that.

And since I'm honestly trying to help here: Nobody would ever try to look up possible new software from his netbook, from a 800x600 screen, nobody - please believe me here. Providing accessibility for netbook users might be a good thing for sets that have to be continually accessed "from the read", cloud services, mail services - but no one is sitting in a coffeeshop and gets the idea, well, I heard about IQ, let's see what I could do with that. (Vice Versa didn't get that fact either, and some more.)

And finally, why always spread your "material" over several domains, even years after the name change?

And yes, I acknowledge it's a little bit ironic that I, the "hold it as flat as possible" advocate here, kindly invites you to present traditional outlines, to your prospects, not those ugly lists, all the less so spread over 70 p.c. of the screen.

A more traditional (and more pleasant) appearance, please, and then all those "third-dimensional goodies" "under the hood", for advanced users?

Not a single minute spent on making sw "market-conforming" (visual appearance, immediate access to the core functionality even for people not having read the handbook) could ever be lost. ;-)

22111,

Continuing a discussion from here:
http://www.donationcoder.com/forum/index.php?topic=35633.msg347854#msg347854
-------------

- Could we have a (short, schematized, but nethertheless) real-life example of where recursion in IM would really be useful?

In IQ, hierarchy is something that is added to items. It is sometimes shown, sometimes not. Closer to a hyperlink than to a disk folder structure.

Items exist in the database, like you and me exist on this earth. If a parent is deleted, its sub-items are not necessarily deleted. Same for you and me... if your father dies, you don't automatically die with him.

So items exist in the database. At any moment, you may want to show an item as a new child of another item. For whatever reason. Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?

Another example is any good old web page. It may link to sub-pages, and these will typically link back to the main page. A nice convenience and something we don't even think about. The same can be done in IQ.

So, there are at least 2 cases where this is desirable: (1) The hierarchy is deep and (2) To bring a parent close to an item.

Regarding sloppy IM and programming, I believe that IM software should not constrain users.
If recursion is supported, it is certainly not because of laziness, but as a feature. Example of this: IQ support hierarchy equations (i.e. such as value=SUM(children)) and inheritance. Both of these require that recursion be handled correctly to ensure that one does not get into infinite loops !

HTH !

Hello Pierre Paul,

1)

Your web page example is instructive, since it backs MY point I verbalized in DC: Of course, sub-pages have LINKS to the main page (as you write), or to some other "important" pages in the page set (hierarchy most of the time, but not necessarily so), but that's exactly why I mentioned Warnier and what his system does NOT do, and the need for add-ons to a strict hierarchical system, as the Warnier system is: Recursion yes, but WITHIN the elements, not BETWEEN elements, and these "links" then must NOT be followed for building up the hierarchy (or then, be CUT, with some automatic commentary ("here follows again subhierarchy xyz"). That's what I said: You do a STRICT hierarchy, but within that, you do LINKS / clones, but which are "sterile", and this avoids recursion.

More expletive: You have a link to the main page, but if you follow that link, you LEAVE by that the respective sub-hierarchy of that page deep-down from which go went back to the main page, you will NOT want to "combine" the main page (or some other "important" page to which a link from deep-down there brought you), with that page deep-down, you will NOT want to "see" / "declare" that main page or other as a "virtual child" (and then with its children there) of the page deep-down we mentioned first: Such a construct is obviously NOT recursion, but "linking to something other", or in your parable, that granddaughter will NOT "make children" with her grandpa, she will just kiss him on the cheek and present him to some school comrade of hers. "Sterile", as said, NOT bringing the respective children (which in the case of the main page would be the whole tree again, and again... - endless recursion, but even recursion "just one run" is neither wanted nor acceptable), as now common descendance of our item deep-down and the linked main (or other) page.

So you call this linking "A nice convenience", but we totally convene here, it's just "going to something else then", not "integrating" that "different info body, again" into a more precise sub-body of it: Again, I cannot imagine any example where this would be useful, but any such example I could image, I would consider it harmful:

2)

"Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?" - For reasons of clarity, as said there; for the simple reason that the human mind has to think in various, complex ways, but that for it in order to produce reutilizable results, that thinking has to be put in sensible groups of provisional results (which might then re-group otherwise, further on,

or even re-group otherwise, not instead, but for additional contexts, and as I said, I did not yet resolve that architectural prob (and no other seem to have down either, cf. those 3-dimensional graphic data representations that overload the human mind and thus never "made it"; cf. the conceptual primitiveness of "mind managers" which try to overcome that prob, and which would become of high "trial" interest the moment one of them did introduce trans-file cloning);

we're speaking of CLUSTERING (info or thought, and of course, these categories then partly mix up) elements here (or of multiple clustering for different task contexts, as mentioned in the previous, the "prob" paragraph), and this clustering has to be done in some way, whatever the "thinker" / IM wants that way to have: He simply has to decide about "stronger vs. lighter relationships" (as in human parentage, and considering, too, that sentimental relationships often overcome parentage, i.e. somebody "from the outside" would draw that net strictly by level of parentage, whilst somebody "knowing what's going on" in that family would draw the net quite differently - but he would have to draw it in a neat way nevertheless, even if his net neglected the pure technical parentage level and replaced with "mental vicinity" instead).

This is necessary to not overload the human brain, and here again, I dare to remind us it cannot "hold" more than just SOME elements at the same time, hence this need of clustering, in order to empower the human mind to get "some out of it", of your repository of data. Here, recursion is countering clustering and tries to reinstall chaos of too many elements - you simply cannot distribute thoughts/info in too dispersed a way and then hope for being it useful all the same.

Btw, I can "prove" this to some degree by simply reminding us that if I was wrong, ALL our "outlining" and "information collecting" (which is none other than establishing clusters of that info out there we would like to group together, in order to become useful for us, and hopefully get some "new meaning" for us) would be dispensable if our mind was able to "hold it all together", without such clustering: We are free HOW we cluster (and what elements we include there), but we need to do it, for one in order to "have it here", and then, to "have it SHAPED" into a form from which then we can start to "think".

3)

"(1) The hierarchy is deep" - well, why do you think I developed, in length, my considerations about cutting up your "big tree" into (in my case) hundreds of independent sub-trees, which are TAKEN OUT of a common hierarchy? Because data hierarchies are so good (as I explained here in length, too), BUT for "self-contained" clusters only, and yes, I'm aware this "self-containment" must be a little artificial here and here, in order to become realizable. And then, "putting multiple such hierarchies side-by-side", in again clustering them, but NOT by trying to do "spaghetti IM" - which is exactly what you advocate here. My tree hierarchies rarely (or never) exceed 3 indentation levels, but then, for one "project"/"context", I often need 4, 6 or 15 such trees at the same time - but, as said, these are independent of each other, and as I had developed in length here, such a tree could just have 20 items or so - if it's self-contained, splendid, make it a tree of its own... and then, that same tree for some special aspect would appear in perhaps dozens of such "clusters of a higher level",

i.e. I strictly cut down info into the "least common denominator", and then I take these "atomized clusters of the level deeper down" and regroup them, to these "clusters of higher level" - by this I totally avoid all your possible recursion probs, or rather, all those probs your IM concept (and an Ultra Recall big tree concept of 100,000 or more "interwoven" items (= all levels mixed up, "thanks to" the cloning=ubiquitous recursion)) will cause to the USER (' thinking and organizational capabilities).

Btw - and this is the highly interesting part in your concept-as-you-seem-to-have-done-it (but not as you present it here, from your pov that recursion is a gift, not a prob) -, your technical realization (as far as I see it "from the outside") also had wanted to decidedly BREAK UP the "total hierarchy" concept, by my "next step" then seems to be quite superior (since it guarantees total clarity), whilst you did not yet have made that second step of grasping that your "hierarchy isn't mandatory and shouldn't be total" (as though it is in solutions like UR and such) gives "you" (= the user of your system) the chance to REGAIN that same clarity of info organization, and of thought, as mine does (mine of probably best, but I'm open to any criticism of it, and let's remind ourselves that ConnectedText also tries to do some real breakthrough to LEAVE that tree concept, which at the end of the day, is unsuitable to big data, as current realizations show as well as your argumentation on recursion, in direct comparison of what I have presented in my developments here...

and which in part convene with yours and with CT's, the big difference of my concept and these two others being that I don't want "orphaned items", but want "folders"/"clusters" (be them in tree form, or in file folder form, for external files) as an intermediate grouping entity, because here again, I want to reduce clutter, I want, in my personal case, some 1,000 or 1,500 such "trees" and the respective file sub-folders, instead of having to copy with 300,000 single files and outliner entries (= some "plain text advocates" ask for cutting up even info I put in trees because it narrowly belongs together, in thousands and thousands of single .txt files, see below).

4)

Of course, single .txt files advocates hereby resolve the prob of how to access individual, deep-down, much more atomized info from anywhere else, but create the prob of how to group these, i.e. they would probably put 300 such .txt files into some "digl" or "384620" subfolder, where I would do a tree with 300 items

(cf. my developments on ORDERED context of every such item, and also the ease of having some about 3 "parentage" = indentation levels for these 300 items: the first aspect cannot be realized within a folder system, the second aspect would create multiple-sub-folders chaos within such a "digl" sub-folder (creating perhaps some 30 more subfolders there - ok, you could try to realize some of these with hierarchical tagging there: OMG, what a mess: I really think my solution is the very best there is, just compare!)),

and then a corresponding "digl" sub-folder (containing the "digl" tree file or not, no matter if you split it up or not), containing any special (internal or external) file (or a "clone" = link) belonging to that "digl" context/"project".

Of course, in my system, there is also a need for accessing just single items, from other contexts, and not only these "trees" (even if they are cut to their bare bones), and that's why I spoke, in my developments, of db's with just references, and then a technical realization where such items are NOT included into tree files, as a next (and then, perfectly scalable) step, but would be technically independent, as items in db's - all these trees then would be virtual BUT independent nethertheless.

It's all about "preserving" info in a "manageable", "usable" "format", and I think that within a big corporation, some 20,000 or 30,000 INDEPENDENT "compounds", as described by me in this forum, are much more "apt to be handled", than are 10,000,000 single, atomized items; and yes, as said, I acknowledge the task of just "integrating" ONE such item, from perhaps a tree of 100, into another tree/project/context, instead of giving that one a sibling of 99 unwanted items, for 1 that is needed there.

"you don’t automatically die with him." - No, but in my IM world, that "orphan", be it 3 years old or 85, would have to get a new father, before we let the former father die ;-) - in order to not produce an informational chaos with millions of disparate elements (which is also the prob in the CT concept, if we "blow it up" to corporations, and at the end of the day, you won't be able to cope, as an individual, with 10,000 disparate elements, exactly the same way as as a corp would be incapable of coping with 10 million).

5)

"(2) To bring a parent close to an item." - That's exactly what my system delivers, in the utmost possible, neatest way, without mixing up things for that, as your "system" does (= as said, your realization seems to bring good possibilities, whilst it's just your argumentation here that's not on par ;-) - and of course, users of your system would have to be careful, whilst in mine, the system itself would prevent them from making recursion mistakes ).

Also, bear in mind that my system, by splitting "content" into multiple (but, and that's the keyword here, independent) trees, makes any such info, even WITH the respective children, available everywhere, by just "sidecar-ing" that tree wherever it's needed, without it becoming necessary, for that, to create chaos with "not just referencing, but cloning here, together with all its children":

At the end of the day, you could put it this way: My system automatically "cuts" any tree from any child tree, conceptually; let me explain:

Of course, the "ciou - computer - IM - outliners - Ultra Recall" tree is a "child" from the "cio - computer - IM - outliners" tree, but these "trees" with c, then ci, then cio, then ciou, are just "virtual container trees", just LISTING contexts; they do NOT represent "strict hierarchy", as the corresponding headings would do in e.g. a UR tree; they are just "nagivation aids for multiple contexts"; wherever the "cio" tree is referenced to (which is NOT "cloned there", just referenced, in its entirety, with all its links it might have, becoming "sterile" links here). The same would be true for "projects", for project trees, and conceptually they do NOT need to be differentiated from any other context tree, since they function entirely similar - of course, you would have project trees listed elsewhere than "reference material" trees in your "trees of trees", for better navigation, and perhaps even put a project tree, after completion of the project, and just-as-it-is, into the respective "reference section", without any functional difference, neither before, nor after it having become "reference material".

In fact, my system has broken up the big tree structure in two "halfes", if you want to see it that way: Instead of having 6 or 8 indentation levels for things, I introduced 3 or 4 such levels JUST FOR TREES, and then, every such tree will perfectly do with just the remaining 3 or 4 indentation levels that are necessary there, any level "above" having been just "cut off"

( "Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?" - the trick is, it will NOT be present there anymore, but will have been "side-car-ed", as everything else, nor cluttering your data repository anymore, neither impeding your thinking )

, and anything else you ever need here,

IS REFERENCED, BUT REMAINS REFERENCE

- and will not become "father" or anything for anything in your current tree, conceptually, even if for micro-navigational reasons, you present it like such - But that's another reason why I advocate, "hold it flat": this will prevent, more or less, such misleading representations - btw, you could perfectly prevent, technically, any such link to some other tree, from having any "child", even "just visually", and as said, even in the "tree's trees", we're just speaking of links in lists.

I'm perfectly aware of all the limitations of Warnier's system, and my system overcomes any of his, but his system was the total breakthrough all the same, it was a beginning, a start, but before him, programming had become "unserviceable" and "un-further-developpable", and see what we've got since, in programming / sw architecture, with the foundations he laid out for this. So, I'm certainly not arguing "extra" against your saying, "I believe that IM software should not constrain users" - I think I've refuted it. The origins of Warnier's concept put too many constraints on programming, but he had very well to start somewhere! And speaking of origins, it was all about output then (cf. the numerous Kenneth Orr papers on that (far too) special subject) - today, user constrains are far less strict, but constrains there are, and Warnier (and his American counterparts) saved programming from early death. I very much hope it can be seen that for IM, similar principles apply. Btw, big data, information overload, how to copy with the fact that every day now, "they" produce as much "info" (or false info) as is contained in print in the whole Library of Congress, etc., etc., blah, blah - it's all about introducing (and perfecting!) constrains.

7)

"IQ support hierarchy equations" - here again, we convene perfectly (my legacy sw had a "sum-it-up" function, too), but here again, let's not mix up "inclusion" and "recursion"; why not prevent (useless, troublemaking) recursion to begin with, at a very early stage, and then for inclusion tasks, no such additional, special recursion prevention will ever be necessary. Btw, I didn't ask for real-life examples of "where to prevent recursion", I asked for such examples where recursion would be useful (and that means present usefulness my "recursion-less" would be less useful). ;-)

"Inheritance" - a special form of inclusion, here again, recursion would be the ultimate mistake; so you named a second example of where you are aware that recursion has to be avoided, instead of "delivering" ;-)

Again, recursion is a very useful concept for programming at the micro, but not on the macro level, and I honestly don't see any use for it in IM - not even at the micro level. ;-)

_________________

Permit me to repeat my core sentence, and which is the "secret" here:

IS REFERENCED, BUT REMAINS REFERENCE

Or in other words, in IM, the rule goes, have sex, but contracept, and this'll avoid any possible oedipian offspring that might then ruin their mismatched-(as)-parents life.

I perhaps did not make it evident that whilst in all instances, you will FOLLOW those links, "manually", whenever you need to do this, and then have some "sidecar-ed" data bodies, you also could do special "FOLLOW"-links which then build up a compound hierarchy, incl. e.g. summing up (time, money, other) sums. I wrote about these SPECIAL tasks here in this forum some months ago, and here, indeed, there will be needed some checking for possible recursion, but just within the framework of those special "follow automatically" links and what they make available to the "adoptive, temporary" "parent"; technically, this could perhaps be a sub-group of "tree for trees", with some additional functionality for this check. So we convene that such "direct parantage" between different trees should indeed be possible, but for some special needs only, whilst the regular tree would rely on "siblings", not on "children". But a special item "format" "follow-link" is needed; above, I overlooked to mention this variant. But here again, NO need for making available recursion, just, again, the need for its avoidance (when such "follow-links", even in an otherwise recursion-free data repository, suddenly reintroduce that risk).

22111,

I'm more of a practical guy than a "in theory" one. So this discussion is kind of over my head.

IQ is built on the following 15 principles:

1- Items exist in an IQBase (the database engine supports simultaneous multi-users)
2- Items can be assigned any number of values (types: yes/no, text, number and date)
3- Hierarchy is not an intrinsic property of items.
4- Items can have any number of parents and children
5- Items can be made a child of any item except itself
6- Items are not necessarily deleted if a parent is deleted
7- Items are presented in a number of different ways, called views.
8- Some of these views display hierarchy, others not.
9- Currently, the views are: Grids, Search, Calendar, MindMap, Rich Text, Pivot Table and Pivot Charts. Other views are in development
10- Grids can display hierarchy. But users can also opt to display a flat view.
11- All views display items that meet a certain set of criteria, chosen by the users. Criteria typically involve field-values
12- Other applications, such as MS Excel and Word can also be used to view items
13- Changing item field-values can trigger equations and custom code
14- Users can write custom VBScript code
15- Uses can create custom forms which automatically assign field-values to items

Give power and flexibility to users with minimal constraints is IQ's main philosophy for effective information management

Pierre
IQ Designer
http://infoqube.biz

To the casual reader,

The previous post doesn't mention the term of recursion anymore, all the less so why it shoul/could be desirable. But you'll have got the point, as I did,

PPL's product is on the market, mine is not. ;-)

22111 wrote:

The previous post doesn't mention the term of recursion anymore, all the less so why it should/could be desirable

Perhaps not in the strict sense as defined here: http://en.wikipedia.org/wiki/Recursion but Item 5: "Items can be made a child of any item except itself" implies something close to it, no ?

I signed up just so that I could respond to this thread. I've been actively using FreeMind for a couple months and noticed they added cloning (recursion) in version 1.0.0. Of course it has a bug in the stable release, and I don't expect a new build anytime soon!

This encouraged me to really evaluate how I was using the tool anyway; and while I think that it can be improved to add the functionality I'm looking for—it's not even designed to be an outliner... I don't really care for the visual components (styles), as much as structuring ideas without a lot of duplication. I started looking for another tool that would accomplish what I want, and the only thing that may actually come close is your software (InfoQube).

I can tell you understand a lot of concepts that other software is lacking. I don't want to discourage you at all, because I know that you've spent a lot of personal time on this. I'm very thankful for your contributions!!! From a new user perspective though, it is confusing and virtually useless. It has a ton of awesome features, but the UI is overwhelming. The average user is going to want a simple interface to get started with advanced options hidden in structured menus and dialogs.

I'm not suggesting to trash the idea altogether, but if you're open to feedback then please listen. I am looking for an easy way to outline data without having to duplicate it. I want simple tagging (and tag groups). I want to be able to see my tags depending on what node(s) I have selected in the sidebar and a simple search and check box to show all of them. When I select a tag, then I want to see all the items that have that tag. Same for tag groups. If I decide to delete a mirrored node, then I want the option to delete all of it's clones (or just break the clone for that particular instance).

Tag groups will essentially act as a field category, and then the tags themselves will be field values that don't have to be categorized. This will allow me to structure my data so that I can see relations between items, without having to duplicate it and possibly lose focus of my initial idea. E.g. I want to create a parent node of herbal teas, and tag their health benefits... I also want to list their scientific classification in a different structure to see their relationship to each other, which will help me visualize their benefits based on their classification, but in a separate parent. Then I should be able to create a parent called Herbal Teas and clone (mirror) directly to one of the other child nodes from another parent. Otherwise my data is going to lose value if it isn't consistent.

I know that I'm spitting a lot of ideas out here, but I was hoping you'd be willing to evaluate them to see if you might be interested in changing your UI strategy. I think we're on the same page, but without a functional product it isn't very useful for what I (or other users will probably want to accomplish).

PP, "The previous post doesn’t mention the term of recursion anymore, all the less so why it should/could be desirable", technically, you are right, please replace "mention" by "discuss", since that's what I wanted to express, "mention, discussion-wise"; technically, you just LISTED AGAIN the FEATURE, (having listed the feature before), but without adding anything to that listing-the-feature - but I acknowledge that my line blurs the possible discrimination with the latter part of it.

Fact is, your non-avoidance of recursion creates conceptual and "mind" chaos, and you don't see the prob, which is a viable choice of yours, but it's a choice; even a sheet of paper does, by its physical aspect, do some "restrain" (and unfortunately too much restrain) on your thinking, and whilst I try to implement some sort of "constructive restrain" (cf. with "ideal", but non-constructive 3-dimensional "concept maps" and their NIL practical value for working on real-life probs, at least in their current shape), you chose the non-restrained way, as these maps: I acknowledge that choice, but I don't try to follow it, for the above-mentioned aspect of trying to be more constructive than that (and bearing the limitations of "regular people" 's (to who I belong, IQ-wise) functioning-of-thinking, in mind).


Tom, thank you very much for your trying to be constructive, and please forgive me for not being able to discern, at any moment, where you address PP, and where you address me (it starts here, "and the only thing that may actually come close is your software (InfoQube). - I can tell you understand a lot of concepts that other software is lacking. I don’t want to discourage you at all, because I know that you’ve spent a lot of personal time on this. I’m very thankful for your contributions!!!", and then goes on this thrive. If, by chance, you ONLY addressed PP, without addressing me, I kindly ask forgivance for my preposterousness, but then, there's this "but without a functional product" part which seems to address me?).

Also, I've got real comprehension probs with what you try to describe re what you would consider perfect sw for your means and tasks.

Would you please be so kind as to further develop, give details, give some examples how "your perfect sw" would present data? I'd be perfectly willing to consider, rethink, once I understood what you're aiming at (and thus understood where it differed from my previous concepts); as I said before, I KNOW perfectly well that both the outlining concept and the Miller Columns concept (which are quite similar, identical even in their underlying structure) will NOT be useful "deeper down" along the indentation level (that's why I cut the structure up "in the middle", as detailed in this forum, and from my real-experience, I can say that's an incredible relief!),

let alone the prob "how to use alternatively-regrouped sub-groups in different contexts", so I'm totally open to any possible tagging concept overlaying the original tree structure (of which I detailed the superiority here, but as the BASE structure only, and I'm even willing to reconsider that paradigm whenever I* find something equal / more practical / more "complete" (i.e. not having to overlay OTHER structures over a tree structure whilst preserving the ADVANTAGES of a basic tree structure (but not necessarily the tree structure itself).

* = "I" meaning "with the help of my friends", in case, i.e. in some constructive discussion where I'm more than willing to accept (and to acknowledge as being not mine) contributions from other thinkers, let alone THEIR possible "complete new ideas", where I just then could say, well, that's the perfect solution! (And not only in cases where Wikipedia "proves me to have been second" as with those Miller Columns.)

Btw, this sort of PUBLIC disscusion really assures, to any possible contributor of new ideas, that his respective "copyright" (or copyright, without any quotes, after all) will be strictly preserved, the advantage over patents being that possible solutions will possible come from various developers (cf. the pauperization of sw development, for now something about 30 years, for MS "owning too much").

Thus, again, Tom, please be so kind as do develop what you're after, further.


As for FreeMind, I had been pointed to its cloning feature, then checked it, but it's awful; it's intra-file: Some sw house with real, big money (MJ and some 2, 3 others in that sub market) should FINALLY look into creating INTER-file mm clones (which technically are perfectly possible, I wrote on this in the Ultra Recall forum, among others). And of course, let's not mix up cloning / referencing with recursion, but this being said, I'm not here to reveal possible argumentative haziness, but in order to trigger many more good ideas, in common effort, than I'd be able to stumble upon, all alone.


PP, "Another example is any good old web page. It may link to sub-pages, and these will typically link back to the main page. A nice convenience and something we don't even think about. The same can be done in IQ." ( in http://www.donationcoder.com/forum/index.php?topic=35633.25 ). Now, as a prof developper, you should not mix up references with recursion, right? (And yes, if sometimes, technically, they have the same origins, we should look after them being perfectly distinct, even from the technical pov, in order for the lack of distinction not becoming a trap then.) But since you maintain the non-distinction, please allow for my falling back into that "family parable": Yes, having sex with your ancestors might be a "nice convenience", and most three-years-olds would happily enter into it... it's just some time later that big, big probs will present, from such blatant misbehavior on the part of their creator(s) (be it pop or mom) (and to further remain within that pic: the child is OUT of the womb, you see, no (acceptable) means to re-insert even "parts" of it into there (or the other way round - I'm very sorry for the (unintended obscenity here, but IM recursion is obscene)...) So we have to look out for something less destructive ("then intra-family sex"), and without barring the (highly desired) intra-family intimacy. Enough said. To regain the IM world, it's all about "making anything desirable possible, but without creating chaos in your head - just as in the family setting. Your mileage might differ... ;-)

As said, I know outlining is not enough; but it's the best home base, from my experience, we've got at to this point. Thus, we need something really good in order to replace it, or then, lesser but more problable alternative, we'd have to invent something to overlay that base structure: We're in need of a real smart tagging component, and that's why we first have to identify what our ideal (= optimized in their realization / "work flow") tasks will be.

And Tom, you ain't wrong in your perception, from my dispersed writings, it all appears (too) complicated, currently, but I once said, in order to present sw as very easy, streamlined, "perfect", to users, it's a whole lotta piece of programming that's needed behind the scenes. My writing just blur that distinction, but I'm after the purest, simplest sw on earth, from the users' perspective, promised.