Best of Both Worlds, Twice - I think this was the missing element to a perfect system: The "one db, one tree" nexus is dead.

Posted by 22111
Dec 24, 2013 at 12:35 AM

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