Forum Posts Feed
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 Pierre Paul Landry
Dec 24, 2013 at 01:54 AM
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
Posted by 22111
Dec 25, 2013 at 02:36 PM
“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. ;-)
Posted by Pierre Paul Landry
Jan 28, 2014 at 05:35 PM
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 !
Posted by 22111
Jan 29, 2014 at 02:40 PM
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.
Posted by 22111
Jan 29, 2014 at 03:03 PM
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).