What outliners should be able to do (on inherent features and interoparability)
Started by Fredy
on 8/12/2012
Fredy
8/12/2012 10:13 am
Preliminaries
As we all know, the Kant professor advocated two things before leaving: ConnectedText (CT) and AutoHotkey (AHK). The irony is, many use CT know whilst there's no further mentioning of AHK.
In 2011, I was on a commercial macro tool, with all its limitations. In 2012, I'm on AHK now, and the possibilities are tenfold, but there are limits, and those helped me to see clear on the "What an outliner should be able to do at the very least" subject.
When I'm speaking of outliners, I'm speaking of the 2- and 3-pane variety only (I'm not interested in the notion that "only 1-pane outliners are real outliners - that might be true, but then donate us with a term for the 2/3-pane things, and I'll never speak of outliners anymore).
I said, we had paper stacks (with sort sheets / slips, and also with tiny "favorite" slips (clipped or glued, what do you call them) 30 years ago, and from many outliners today, 30 years later, we basically get electronic search on top of that, nothing more, whilst alternative views on your material - a thing that was possible with paper but only if you didn't sleep anymore or had two or more secretaries - would be a strict minimum, given the easiness for a computer to do so AND the extreme usefulness of this for anybody using such sw. And I said, in the ActionOutline review on cnet, that a non-fleeing search results table was the strictest minimum to such an alternative view (while there are others, better ones, and best would be to have several of such alternative views concurrently).
Bill (MadAboutDana), I agree with you that there might be other "basic" features an outliner might have.
One day in 2011 (= I on my macro tool, not on AHK yet), in the UltraRecall forum, I asked for SEVERAL text expanding resolve files (UR has got, from its MS editor like other MS products, text expanding, but only from one such file, i.e. you don't have alternative vocabularies at your disposal, for several languages, for several subject contexts, etc. - just one for all) - no answer, and I even wrote a macro that would have exchanged that only resolve file by others, but you had to close down and reopen UR in order for that, so it was a dead-end.
Tranglos in the donationcoder forum said, on editors, he uses several ones of them, concurrently (like me), and thus he doesn't use any in-built language-specific expanding features, etc. within those editors, but he uses AHK for text expanding instead, since that allows to script the text expansion, etc. once, and then use it in any such editor he might use at any time - btw it goes without saying that AHK allows for "general scope" (application) AND for "deep scope" (the "control" having focus in any such application) AND for multiple such "expansion tables" - the possibilities are almost endless, from that.
Combine my unfulfilled wish in the UR forum with Tranglos' using his overlayed script language on several applications, and you'll get two things:
- Perhaps the usual outliners' approach "one thing does it all" is a fault-in-thinking from start on (and indeed it is, I developed this during the last months in the UR forum).
- Clearly distinguish between what an application NEEDS TO DO ITSELF, and what it SHOULD ALLOW to do, by external means.
As we all know, the Kant professor advocated two things before leaving: ConnectedText (CT) and AutoHotkey (AHK). The irony is, many use CT know whilst there's no further mentioning of AHK.
In 2011, I was on a commercial macro tool, with all its limitations. In 2012, I'm on AHK now, and the possibilities are tenfold, but there are limits, and those helped me to see clear on the "What an outliner should be able to do at the very least" subject.
When I'm speaking of outliners, I'm speaking of the 2- and 3-pane variety only (I'm not interested in the notion that "only 1-pane outliners are real outliners - that might be true, but then donate us with a term for the 2/3-pane things, and I'll never speak of outliners anymore).
I said, we had paper stacks (with sort sheets / slips, and also with tiny "favorite" slips (clipped or glued, what do you call them) 30 years ago, and from many outliners today, 30 years later, we basically get electronic search on top of that, nothing more, whilst alternative views on your material - a thing that was possible with paper but only if you didn't sleep anymore or had two or more secretaries - would be a strict minimum, given the easiness for a computer to do so AND the extreme usefulness of this for anybody using such sw. And I said, in the ActionOutline review on cnet, that a non-fleeing search results table was the strictest minimum to such an alternative view (while there are others, better ones, and best would be to have several of such alternative views concurrently).
Bill (MadAboutDana), I agree with you that there might be other "basic" features an outliner might have.
One day in 2011 (= I on my macro tool, not on AHK yet), in the UltraRecall forum, I asked for SEVERAL text expanding resolve files (UR has got, from its MS editor like other MS products, text expanding, but only from one such file, i.e. you don't have alternative vocabularies at your disposal, for several languages, for several subject contexts, etc. - just one for all) - no answer, and I even wrote a macro that would have exchanged that only resolve file by others, but you had to close down and reopen UR in order for that, so it was a dead-end.
Tranglos in the donationcoder forum said, on editors, he uses several ones of them, concurrently (like me), and thus he doesn't use any in-built language-specific expanding features, etc. within those editors, but he uses AHK for text expanding instead, since that allows to script the text expansion, etc. once, and then use it in any such editor he might use at any time - btw it goes without saying that AHK allows for "general scope" (application) AND for "deep scope" (the "control" having focus in any such application) AND for multiple such "expansion tables" - the possibilities are almost endless, from that.
Combine my unfulfilled wish in the UR forum with Tranglos' using his overlayed script language on several applications, and you'll get two things:
- Perhaps the usual outliners' approach "one thing does it all" is a fault-in-thinking from start on (and indeed it is, I developed this during the last months in the UR forum).
- Clearly distinguish between what an application NEEDS TO DO ITSELF, and what it SHOULD ALLOW to do, by external means.
Fredy
8/12/2012 10:26 am
Hold it as simple as it gets
As we all have rather different wishes, the problem any developer who wants to fulfill them all is that he's bound to develop bloatware, and most of us say we don't want bloatware. It even comes to negating wishes of other users in the specific forums, "no, that wish is not important, and we don't want bloatware here" - which is to say that this "I want this, another one wants another feature" is dividing the user base of a given application into rivals for their specific wishes that seem to exclude one another.
As I'm developing here, that's another case of faulty thinking: Just bear in mind an application can ALLOW FOR a feature, without that feature being programmed into that specific application. Thus, those outliners (or any other sw group) must offer the possibility to add on an add-on (cf. the endless stream of Outlook add-ons / add-ins), be it commercial, be it just another (more or less elaborate) script, and in order for such a system to function well, the developer must, in interaction with the users of his program, make available the necessary interfaces for those specific wishes where the majority of users don't need that feature but where some of them / the power users / some specific uses for that specific program need them.
As we all have rather different wishes, the problem any developer who wants to fulfill them all is that he's bound to develop bloatware, and most of us say we don't want bloatware. It even comes to negating wishes of other users in the specific forums, "no, that wish is not important, and we don't want bloatware here" - which is to say that this "I want this, another one wants another feature" is dividing the user base of a given application into rivals for their specific wishes that seem to exclude one another.
As I'm developing here, that's another case of faulty thinking: Just bear in mind an application can ALLOW FOR a feature, without that feature being programmed into that specific application. Thus, those outliners (or any other sw group) must offer the possibility to add on an add-on (cf. the endless stream of Outlook add-ons / add-ins), be it commercial, be it just another (more or less elaborate) script, and in order for such a system to function well, the developer must, in interaction with the users of his program, make available the necessary interfaces for those specific wishes where the majority of users don't need that feature but where some of them / the power users / some specific uses for that specific program need them.
Fredy
8/12/2012 10:48 am
Do externally, do internally?
On the other hand, there are functions that should be done internally since doing them externally would not be possible, and here we are at the core of our question "what should an outliner be able to do". These "alternative views", for example, perhaps you could do them externally if the interfaces I spoke of were multiple and if you had very elaborate programming at your hands - but would this be reasonable, for an "important" feature at least? Of course not. (And for an unimportant feature, there would be no programmer to do the sophisticated work asked for.)
But for many editing tasks, for shuffling around things, within your outliner or between external progs (= e.g. your browser) and your outliner, lots of (rather simple) scripts would be readily available, i.e. enthousiast users would script them and put them into a section of the corresponding forum, and scripts in textform would be ready for any adaptation by other users, also to be shared - yes, we're speaking of a REAL community here, and such a things is perfectly possible, I did share things, a certain Felix did share things (askSam, then MyInfo), and remember Flo, on the askSam forum, anyone?
Of course, with "doing things externally", there is a problem is you do NOT have such interface points: there is a lot of "your screen doing things" before your eyes here, which isn't beautiful, but it's very simple in the end: It's easy for a developer to make available a "dont refresh screen display" function, and a "refresh screen" to end this, and this way, even external macros run much more smoothly even to your eyes.
Anyway, you have got that problem that scripts = external macros, once triggered, normally run independently from any internal proceedings, which is to say, your script "doesn't know where the internal processing is at" at any given time, so you must insert lots of (often unnecessary, but sometimes not even sufficient, hence the need to further mostly unnecessary elongation of your macro steps) "sleep" / "delay" steps, or visual checks, i.e. your script must contain lots of "check points" where further proceeding will depend on the state of screen controls - which means you cannot revert to "hide screen updating" since controls that don't appear on screen cannot be checked for their state (? perhaps they can, in the end).
Which is to say, external scripting does indeed multiply your possibilities with any program, even without such special interfaces, but it's not totally reliable (even with checks and "sleeps"), and it's rather ugly then.
On the other hand, there are functions that should be done internally since doing them externally would not be possible, and here we are at the core of our question "what should an outliner be able to do". These "alternative views", for example, perhaps you could do them externally if the interfaces I spoke of were multiple and if you had very elaborate programming at your hands - but would this be reasonable, for an "important" feature at least? Of course not. (And for an unimportant feature, there would be no programmer to do the sophisticated work asked for.)
But for many editing tasks, for shuffling around things, within your outliner or between external progs (= e.g. your browser) and your outliner, lots of (rather simple) scripts would be readily available, i.e. enthousiast users would script them and put them into a section of the corresponding forum, and scripts in textform would be ready for any adaptation by other users, also to be shared - yes, we're speaking of a REAL community here, and such a things is perfectly possible, I did share things, a certain Felix did share things (askSam, then MyInfo), and remember Flo, on the askSam forum, anyone?
Of course, with "doing things externally", there is a problem is you do NOT have such interface points: there is a lot of "your screen doing things" before your eyes here, which isn't beautiful, but it's very simple in the end: It's easy for a developer to make available a "dont refresh screen display" function, and a "refresh screen" to end this, and this way, even external macros run much more smoothly even to your eyes.
Anyway, you have got that problem that scripts = external macros, once triggered, normally run independently from any internal proceedings, which is to say, your script "doesn't know where the internal processing is at" at any given time, so you must insert lots of (often unnecessary, but sometimes not even sufficient, hence the need to further mostly unnecessary elongation of your macro steps) "sleep" / "delay" steps, or visual checks, i.e. your script must contain lots of "check points" where further proceeding will depend on the state of screen controls - which means you cannot revert to "hide screen updating" since controls that don't appear on screen cannot be checked for their state (? perhaps they can, in the end).
Which is to say, external scripting does indeed multiply your possibilities with any program, even without such special interfaces, but it's not totally reliable (even with checks and "sleeps"), and it's rather ugly then.
Fredy
8/12/2012 11:03 am
What about an internal macro function?
So, it becomes evident that what's needed, in the very first place, when you "hold your basic program simple", is an internal macro function. Here, we've got another variety of the "what, that's all after 30 years of personal computing?" phenomenon: 30 years ago (or perhaps "only" 27, 26 years ago), many programs came invariably WITH such internal macro functions, whilst MOST programs today, cheap or expensive, come WITHOUT such a function: This appears to be extremely crazy on first sight, but refer to what I said on the subject of the "users accept almost everything today" vs. "developers think, given the users they got, that it's good enough as it is" interdependence, and you see clearly now: Developers just decided that given the fact that most users are debrained (? décervelés), the programming of a macro functionality was pearls before sw***.
On the other hand, MS is one of the very few devopers that supply their sw's with such macro functionality, and see what their market share is!
Thus, not only that "alternative view" (see above and below) seems to be an absolute MUST-HAVE of any acceptable outliner, but built-in macro-functionality is another one - admit you'd never thought of that, in this context! On a traditional "wish list" for such programs, it would have been on 30th or 60th position, "for specialists", when in fact, such functionality, in the very first place, could do away with many such wishes on such a wish list, from position (about) 5 to (sign for endless): just a little bit of scripting, and your wish is fulfilled! (And the above-mentioned problems with external scripts would not occur with internal ones if - IF - the macro function is programmed as it should be.)
So, it becomes evident that what's needed, in the very first place, when you "hold your basic program simple", is an internal macro function. Here, we've got another variety of the "what, that's all after 30 years of personal computing?" phenomenon: 30 years ago (or perhaps "only" 27, 26 years ago), many programs came invariably WITH such internal macro functions, whilst MOST programs today, cheap or expensive, come WITHOUT such a function: This appears to be extremely crazy on first sight, but refer to what I said on the subject of the "users accept almost everything today" vs. "developers think, given the users they got, that it's good enough as it is" interdependence, and you see clearly now: Developers just decided that given the fact that most users are debrained (? décervelés), the programming of a macro functionality was pearls before sw***.
On the other hand, MS is one of the very few devopers that supply their sw's with such macro functionality, and see what their market share is!
Thus, not only that "alternative view" (see above and below) seems to be an absolute MUST-HAVE of any acceptable outliner, but built-in macro-functionality is another one - admit you'd never thought of that, in this context! On a traditional "wish list" for such programs, it would have been on 30th or 60th position, "for specialists", when in fact, such functionality, in the very first place, could do away with many such wishes on such a wish list, from position (about) 5 to (sign for endless): just a little bit of scripting, and your wish is fulfilled! (And the above-mentioned problems with external scripts would not occur with internal ones if - IF - the macro function is programmed as it should be.)
Fredy
8/12/2012 11:34 am
What's needed, internally, then?
This being said, I come back to the "needed basics", positions (perhaps) 2 to 5 - the discussion is open, I don't want to impose any "this function is internally needed, that one is not" onto everyone, all the less so since up to now, I didn't really think about specifics here.
Just let me say, the macro function must be within those basic, NEEDED functions, and some alternative view also - why the latter? I said it above, I want to clarify now: With internal macros (if they are available), you can do lots of things, and many (rather simple, each one) functions should be available, in order to build such helpful macros (again, there should be a forum, where users would suggest new (simple) functions, in order to make available, in a second step, macros that would become much more sophisticated functions: "missing links" if you want, to build upon).
And the "alternative view" functions would be within those "most important functions", a good search function (not vanishing hit table being the most important and most basic thing, to be supported by other means of alternative views) - why internally?
Because some very important functionality simply cannot be done with "internal", let alone external, scripting, and it goes without saying that if you have important functionality the users (or some power users "working for" the corresponding community) cannot create with the means they've got (incl. interfaces), the developer himself must create that functionality, or at the very least functions that, combined, will enable external "programmers" / scripters to realize such functionality. (It goes without saying that a clever making available of smart interface points will be useful for transferring much of the necessary programming work from the developer to volonteers.)
Thus, whenever building a wish list, distinguish between a "could we do it ourselves, in case with a litttle help from the developer (necessary interface, necessary component function), or is it a function that must come with the prog itself, since any "overlay" would be impossible or simply too primitive at best?
A last word: That tiny subgroup of outliner users is kind of an "elite" within that vast market of text processing (or whatever you call it), and so the practical implications of what I say here are perfectly doable. We would have had such a scheme with askSam if the developers had any of their brio left they had amply shown in their younger days (but the whole business was under the thumb of the marketing chief who finally overtook the whole thing, and see what AS is today) - and any such scheme would be perfectly possible with any outliner where such an "interactive development" was wished for by the (capable) developers.
(And yes, there are some more or less aborted open projects, Chandler et al. ...)
This being said, I come back to the "needed basics", positions (perhaps) 2 to 5 - the discussion is open, I don't want to impose any "this function is internally needed, that one is not" onto everyone, all the less so since up to now, I didn't really think about specifics here.
Just let me say, the macro function must be within those basic, NEEDED functions, and some alternative view also - why the latter? I said it above, I want to clarify now: With internal macros (if they are available), you can do lots of things, and many (rather simple, each one) functions should be available, in order to build such helpful macros (again, there should be a forum, where users would suggest new (simple) functions, in order to make available, in a second step, macros that would become much more sophisticated functions: "missing links" if you want, to build upon).
And the "alternative view" functions would be within those "most important functions", a good search function (not vanishing hit table being the most important and most basic thing, to be supported by other means of alternative views) - why internally?
Because some very important functionality simply cannot be done with "internal", let alone external, scripting, and it goes without saying that if you have important functionality the users (or some power users "working for" the corresponding community) cannot create with the means they've got (incl. interfaces), the developer himself must create that functionality, or at the very least functions that, combined, will enable external "programmers" / scripters to realize such functionality. (It goes without saying that a clever making available of smart interface points will be useful for transferring much of the necessary programming work from the developer to volonteers.)
Thus, whenever building a wish list, distinguish between a "could we do it ourselves, in case with a litttle help from the developer (necessary interface, necessary component function), or is it a function that must come with the prog itself, since any "overlay" would be impossible or simply too primitive at best?
A last word: That tiny subgroup of outliner users is kind of an "elite" within that vast market of text processing (or whatever you call it), and so the practical implications of what I say here are perfectly doable. We would have had such a scheme with askSam if the developers had any of their brio left they had amply shown in their younger days (but the whole business was under the thumb of the marketing chief who finally overtook the whole thing, and see what AS is today) - and any such scheme would be perfectly possible with any outliner where such an "interactive development" was wished for by the (capable) developers.
(And yes, there are some more or less aborted open projects, Chandler et al. ...)
Stephen Zeoli
8/12/2012 12:21 pm
From Fredy:
I call them free-form, hierarchical databases... however, that's an awkward phrase and I don't expect it to be adopted by anyone else. What if we call them InfoTrees?
SZ
When I’m speaking of outliners, I’m speaking of the 2- and 3-pane variety only (I’m not interested in the notion that “only 1-pane outliners are real outliners - that might be true, but then donate us with a term for the 2/3-pane things, and I’ll never speak of outliners anymore).
I call them free-form, hierarchical databases... however, that's an awkward phrase and I don't expect it to be adopted by anyone else. What if we call them InfoTrees?
SZ
jimspoon
8/12/2012 1:33 pm
Regarding Scriptability -
A fellow with the handle "Slangmgh" (in China) has written "Ecco Extension" which is sort of a wrapper for the venerable Ecco Pro. It really is remarkable how far it extends the interface and capabilities of the original Ecco Pro. It is very scriptable - here is a part of the description -
"Enhanced Auto-Assign Rule(Regexp/Cumulative function/Depends relationship/LUA Script/JavaScript/Python/Perl/VBScript/Ruby)"
The users in the ecco_pro@yahoogroups.com group swear by it.
For a reasonably-sized outline - I think Ecco is unbeatable. As a "personal information database" - for me it fails because it can handle only 65K total items, and only 16K items in any one data field, and in practice the error messages start popping up when you're around 10,000 items in any one field.
I have not gotten very far into scripting Ecco, because (1) I haven't wanted to invest the time needed to learn it, given the limitations on the total number of items; and (2) the documentation is Chinglish and hard to decipher.
Also re scriptability - Infoqube has got Visual Basic built into it in some way, but I have not tried it out - again for lack of time.
jim
A fellow with the handle "Slangmgh" (in China) has written "Ecco Extension" which is sort of a wrapper for the venerable Ecco Pro. It really is remarkable how far it extends the interface and capabilities of the original Ecco Pro. It is very scriptable - here is a part of the description -
"Enhanced Auto-Assign Rule(Regexp/Cumulative function/Depends relationship/LUA Script/JavaScript/Python/Perl/VBScript/Ruby)"
The users in the ecco_pro@yahoogroups.com group swear by it.
For a reasonably-sized outline - I think Ecco is unbeatable. As a "personal information database" - for me it fails because it can handle only 65K total items, and only 16K items in any one data field, and in practice the error messages start popping up when you're around 10,000 items in any one field.
I have not gotten very far into scripting Ecco, because (1) I haven't wanted to invest the time needed to learn it, given the limitations on the total number of items; and (2) the documentation is Chinglish and hard to decipher.
Also re scriptability - Infoqube has got Visual Basic built into it in some way, but I have not tried it out - again for lack of time.
jim
Fredy
8/12/2012 6:48 pm
Stephen, an acceptable term for more-than-1 pane outliners would distinguish those from the 1-pane variety, "info-tree" unfortunately doesn't do that; we must search further. And, I don't try to invalidate 1-pane outliners, it's just that I, personally, never went warm with them: I continue to be lost in hyperspace in them as I'm lost in broad texts within text processors (there were many of them in the eighties / nineties, as we old men know), whilst in the 2-3 pane variety, my mind functions well.
Stephen, the immediately above explains why I didn't get to any valid knowledge of Ecco, all the more so since I never succeeded with installing Ecco. When I tried to install those bits that can be found within the web, years after Ecco was discontinued, it invariably crashed. So I was happy that at least I didn't fetch a virus, and went on.
Re Infoqube, I was put off by marketing quirks, and in fact the developer doesn't seem to have real interest in marketing his program for individual use. Last time I checked the site was as sparse as it ever had been, the prog was in (free) beta as it ever had been, and it's said he does marked it for corporations (with, in view of what I said here in the last days, is exactly the strategy a developer of such a program should apply) - and here in this forum, he exclusively participated in the form, "no, InfoQube CAN do what you're asking for", in threads no mention was made of InfoQube, which is to say had he constantly, "manually" monitored this forum, but participated only in order to tout his prog. (An even more exclusively marketing-only participation briefly showed up here in the second part of 2011 from somebody else who often had rather childish ways of speaking here but who, I said that once, did ask lots of right questions on his own site, at the same time.)
So I avoided Infoqube for the wrong reasons I must admit, and your double info, on Ecco and on Infoqube, is of high interest. I wasn't aware of these details up to now, and again, I developed ideas as "new", out from not knowing others had had the very same ideas before me. This being said, there was another reason I wasn't interested in InfoQube: It seemed to be a "complete" prog that aimed at "doing it all", whilst in the meanwhile, I had been looking out for a hybrid system where with only a basic outliner (2-pane), and scripting, I could supply myself for the missing functions - but you are right in reminding us that there's no such dichotomy as "very basic outliner here, with lots of scripting", vs. "rather elaborate outliner there, with no scripting", but that it's perfectly possible and reasonable to do lots of additional scripting on top of an outliner that's rather "complete" in itself to start with.
I must also say that I'm into about 600 distinct outlines at this moment, and many more to come (extensive explanations within the UR forum), after having left UR in late 2011 (but without leaving its forum), with the file system being my "3rd pane" = in fact, the very first, "project" pane of my conglomerate, which further reduced my interest in "self-contained" systems; I had explained in length why, as I saw, and see, it, raw 2-pane outliners ain't enough. In short, I always wanted a THREE-pane outliner, without there being any productive one on the market, so I had tried to argument 2-pane developers (AS, MI, UR, and briefly The Brain) into creating one, then created one of my own, with the file system as very first one of the three.
And since this was, and is, so, I wasn't so fond anymore of database-based outliners in general (MI, UR, IQ, etc.) since I thought, and think, that if you do a hybrid system, with hundreds of distinct files, these files should perhaps not be distinct databases, but of more simple architecture. But we're here into the specifics of my very personal system I adopted in late 2011 and developed / refined, and in which the absence of an "alternative view" on my material is that missing functionality I cannot overcome with any possible scripting, hence my theoretical developments.
But all this being said, I acknowledge that your mention of IQ is of the highest interest within this context. (Perhaps Ecco not so much, from a pratical pov: You can run electric shocks thru a dead body, but will that revive it? Perhaps I'm undervaluing those efforts, and Ecco in the very first place.)
In fact, when I was interested into "complete outliners", i.e. up to a year ago, more or less, I wasn't that much interested into IQ, in the end, because I was afraid, Pierre Paul wouldn't listen to my suggestions; Petko (MI) wasn't too gifted for high-brow functionality I was afraid, and kinook (UR) simply wasn't interested in anything, people in his forum outright tell "he's got a communication problem" which I thought wasn't nice, but in the end, with their version 5, they seem to prove to their loyal (!) customer base they ain't interested in much more development whatsoever, hence my developments on "desktop going cloud" in that forum lately, and here - I try to understand, and I seem to have understood some bits on what's globally going on with that incredible shift taking place at this very moment. (And IQ doesn't seem to have been adopted by many people here; in fact, there had been some discussion years ago, and then, less and less so - thus I deducted, without really knowing it, that in spite of its excellence in sheer number of functions - it seemed to "have it all" -, its overall attractiveness seemed to be very limited.)
All this being said, I'm thankful for your hint re IQ, it'll be worthwile to have a look, interfaces-wise and in general...
( You see, Pierre Paul seemed / seems to be a very smart guy, and voilà he's the one to deliver some very important prerequisites nobody else is even thinking of - that's not mere coincidence of course.)
Stephen, the immediately above explains why I didn't get to any valid knowledge of Ecco, all the more so since I never succeeded with installing Ecco. When I tried to install those bits that can be found within the web, years after Ecco was discontinued, it invariably crashed. So I was happy that at least I didn't fetch a virus, and went on.
Re Infoqube, I was put off by marketing quirks, and in fact the developer doesn't seem to have real interest in marketing his program for individual use. Last time I checked the site was as sparse as it ever had been, the prog was in (free) beta as it ever had been, and it's said he does marked it for corporations (with, in view of what I said here in the last days, is exactly the strategy a developer of such a program should apply) - and here in this forum, he exclusively participated in the form, "no, InfoQube CAN do what you're asking for", in threads no mention was made of InfoQube, which is to say had he constantly, "manually" monitored this forum, but participated only in order to tout his prog. (An even more exclusively marketing-only participation briefly showed up here in the second part of 2011 from somebody else who often had rather childish ways of speaking here but who, I said that once, did ask lots of right questions on his own site, at the same time.)
So I avoided Infoqube for the wrong reasons I must admit, and your double info, on Ecco and on Infoqube, is of high interest. I wasn't aware of these details up to now, and again, I developed ideas as "new", out from not knowing others had had the very same ideas before me. This being said, there was another reason I wasn't interested in InfoQube: It seemed to be a "complete" prog that aimed at "doing it all", whilst in the meanwhile, I had been looking out for a hybrid system where with only a basic outliner (2-pane), and scripting, I could supply myself for the missing functions - but you are right in reminding us that there's no such dichotomy as "very basic outliner here, with lots of scripting", vs. "rather elaborate outliner there, with no scripting", but that it's perfectly possible and reasonable to do lots of additional scripting on top of an outliner that's rather "complete" in itself to start with.
I must also say that I'm into about 600 distinct outlines at this moment, and many more to come (extensive explanations within the UR forum), after having left UR in late 2011 (but without leaving its forum), with the file system being my "3rd pane" = in fact, the very first, "project" pane of my conglomerate, which further reduced my interest in "self-contained" systems; I had explained in length why, as I saw, and see, it, raw 2-pane outliners ain't enough. In short, I always wanted a THREE-pane outliner, without there being any productive one on the market, so I had tried to argument 2-pane developers (AS, MI, UR, and briefly The Brain) into creating one, then created one of my own, with the file system as very first one of the three.
And since this was, and is, so, I wasn't so fond anymore of database-based outliners in general (MI, UR, IQ, etc.) since I thought, and think, that if you do a hybrid system, with hundreds of distinct files, these files should perhaps not be distinct databases, but of more simple architecture. But we're here into the specifics of my very personal system I adopted in late 2011 and developed / refined, and in which the absence of an "alternative view" on my material is that missing functionality I cannot overcome with any possible scripting, hence my theoretical developments.
But all this being said, I acknowledge that your mention of IQ is of the highest interest within this context. (Perhaps Ecco not so much, from a pratical pov: You can run electric shocks thru a dead body, but will that revive it? Perhaps I'm undervaluing those efforts, and Ecco in the very first place.)
In fact, when I was interested into "complete outliners", i.e. up to a year ago, more or less, I wasn't that much interested into IQ, in the end, because I was afraid, Pierre Paul wouldn't listen to my suggestions; Petko (MI) wasn't too gifted for high-brow functionality I was afraid, and kinook (UR) simply wasn't interested in anything, people in his forum outright tell "he's got a communication problem" which I thought wasn't nice, but in the end, with their version 5, they seem to prove to their loyal (!) customer base they ain't interested in much more development whatsoever, hence my developments on "desktop going cloud" in that forum lately, and here - I try to understand, and I seem to have understood some bits on what's globally going on with that incredible shift taking place at this very moment. (And IQ doesn't seem to have been adopted by many people here; in fact, there had been some discussion years ago, and then, less and less so - thus I deducted, without really knowing it, that in spite of its excellence in sheer number of functions - it seemed to "have it all" -, its overall attractiveness seemed to be very limited.)
All this being said, I'm thankful for your hint re IQ, it'll be worthwile to have a look, interfaces-wise and in general...
( You see, Pierre Paul seemed / seems to be a very smart guy, and voilà he's the one to deliver some very important prerequisites nobody else is even thinking of - that's not mere coincidence of course.)
Fredy
8/12/2012 7:07 pm
Edit : "shift" : "paradigm shift" they call it. It's indeed revolutionary, and whilst in the UR forum, I preached against it, knowing that we cannot stop it, I know hold that at least we should battle against that other paradigm shift within: As I explained in the UR forum, there is a very evident impoverishment, function-wise, going along with this shift to the cloud: Desktop applics ain't transferred to the cloud 1:1, but being stripped of two thirds or more of their former (desktop) functionality, and even years later, "nothing" is done for them to regain their ancient functionality (similarly, have a look at the last version of AS DOS, then its first Windows version, and even the last version 7.1 - it never regained "programmability" it once had). It's this too basic functionality of cloud services now and that seems to be universally accepted that bothers me most here (cf. Surfulater going cloud, cf. Alec, Daly expressing their fears; cf. Evernote stripped to its bones and more popular than ever at the same time) - this much too low good enough quality going with the cloud transfer is what really worries me - so, when I so much (over)valued desktop applics (see my UR postings), it was again partly for the wrong reasons: Yes, why not going cloudwise, but preserve quality standards notwithstanding!
But they don't do it, which is the real problem. Have a look at that donationcoder "comparative editors review". First, the guy says, unicode was a csqn, then he compares lots of new editors, ALL of them far inferior to any of a dozen or so of ancient editors he doesn't even mention, and all of which don't do unicode correctly, that's right - but at the same time, all their superior functionality is "considered nonexisting", all those high-brow pieces of sw, having set highest standards, simply don't count anymore for their lack of unicode-compliancy, and giving way to a "best editor comparison" where only lessers ones compete with one another - and that very same phenomenon we're witnessing at this very moment with all these desktop applics going cloud (or being buried altogether). End of ranting.
But they don't do it, which is the real problem. Have a look at that donationcoder "comparative editors review". First, the guy says, unicode was a csqn, then he compares lots of new editors, ALL of them far inferior to any of a dozen or so of ancient editors he doesn't even mention, and all of which don't do unicode correctly, that's right - but at the same time, all their superior functionality is "considered nonexisting", all those high-brow pieces of sw, having set highest standards, simply don't count anymore for their lack of unicode-compliancy, and giving way to a "best editor comparison" where only lessers ones compete with one another - and that very same phenomenon we're witnessing at this very moment with all these desktop applics going cloud (or being buried altogether). End of ranting.