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 22111
Dec 22, 2013 at 05:56 PM
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.
Posted by jimspoon
Dec 23, 2013 at 10:48 AM
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.
Posted by 22111
Dec 23, 2013 at 02:35 PM
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).
Posted by Pierre Paul Landry
Dec 23, 2013 at 07:53 PM
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
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.