Forum Posts Feed
What outliners should be able to do (on inherent features and interoparability)
< Next Topic | Back to topic list | Previous Topic >
Posted by Fredy
Aug 12, 2012 at 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.
Posted by Fredy
Aug 12, 2012 at 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.
Posted by Fredy
Aug 12, 2012 at 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.
Posted by Fredy
Aug 12, 2012 at 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.)
Posted by Fredy
Aug 12, 2012 at 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. ...)