I

Stephen, in your thread "Submitted for your consideration" you expand on outliners = single-pane outliners vs. the other variety which should be given multi-worded names containing some "information" component anwhere and that nobody could ever remember of.

I've got bad news for you. Let's see what outliners were originally. Pupils', students', researchers' headings collections, WITHOUT any material = "content", may it be pre-existing or only coming later. So, the "real" outline is our tree, within a 2-pane outliner.

I explained lots of things in the UR forum, just search for "proper outlining", and you quickly will see a thread with about 1,800 views at this time; in the second part of it I explained my current IM system, but in the first part, I explained how your material should be distributed between tree and content pane - that's highly instructive stuff if I may say so (if I hadn't written one of the "best" (but unstable) outliners out there, I wouldn't be as preposterous as that, but my findings come from years of intimacy by the inside, not just by oberservance and touching from the outside).

I tried the 1-pane variety, and I was subjected to the "lost in neighborspace" phenomenon, bad joke since there are hyperspace and neighborhood, but you see what I mean, even within a "closed hyperspace", I was lost; outlines are exactly there to prevent this. And what should it contain, the outline? Any (even minor) sub-heading, in order to fulfill its guidance task. And that's what I explained to the op there in the UR forum who had precisely asked for "proper outlining", meaning inlining, for him. So I explained why he was mistaken, and gave all necessary details.

I am not criticising your need - and your enthousiasm with - the 1-pane variety, but your claim that it's the pure one, is ostensibly erroneous, since your variety mixes up the outline and the material, which was never done within the original idea - on the contrary, you were asked to have your outline on one sheet of paper and doing your development on the other (where it was finally mixed up with the headings = replicated outline items, but as a result only, not for construction purposes), whilst "our" variety holds them apart, clearly presenting the outline that is NOT mixed-up with the content, except when we trigger the "export" function, where finally the outline and the development (or material) will be mixed up for presentation, publication, whatever = "the result line".

Thus, it's our variety that remains faithful to the original idea - here the outline, independently visible from the "whole" stuff, and there, the content, together with its subheading (in good outliners; I abhorr the 2-pane variety NOT replicating the subheading = item title above the content pane = one of UR's many design flaws that kinook's unable to acknowledge).

Of course, I'm not entirely honest here since I pretend our variety is faithful to the original whilst in fact, it diverts from it in another but equally important way: Whilst preserving the outline at any given moment - what "your" variety does not; you can't access it by intermittance -, it doesn't preserve the material in its entirety, in one pane - what your variety does, sacrifying... the outline!

So, in the end, our variety is not better, it's just different, but the same goes for yours.

II

So from this intermediate result, we are at a par, concerning the rights to the name. And yes, I could now say, since our variety preserves the continuous presence of the outline at least - but reconstitutes the whole package in print or export only; besides, this missing functionality has been discussed in this forum here and then -, we have the better rights to the name. An additional argument would be, yours might be "inliners", then, and not even the term is so ridiculous as it might seem at first sight, since "outlining" (I'm not a native speaker as we know) is something like "put the headings separate, independently of the final mix of headings plus material", so, OUT of that total body. Whilst in your variety, these "outlined" headings, as a separate block, stay INSIDE the total block. So, this "inline" vs. "outline" hasn't got the meaning yet I want to give to it, but it's evident my creation isn't absurd either, in "outline", "outlining", etc., yes, there IS a spatial connotation, too.

I'm not saying the 1-pane variety isn't "outliners" anymore, but my objective was to prove that the 2- and 3-pane variety have at least the same rights to the term "outliner" as has got the 1-pane variety, and if one variety had "lesser" rights, it would have been the 1-pane variety. ("We" preserve constant accessibility of the outline, "you" don't.)

III

There seems to be a little resurrection of the - otherwise almost defunct - 1-pane variety in smartphone apps; that's amusing.

IV

I hope people are aware the 1-pane variety is nothing else but another flavor of a folding editor, with all the limitations of that functional design. And I hope people are aware you can do heavy programming in the 2- and 3-pane variety of outliners; I do, and I'll develop on it another time.

Here, let me just say that every language has its "comment line code", be it "," or "//" or whatever, and in your outliner, you make simply begin all your headings and subheadings with this special character, as well as any comments within the body text / within the contents pane; you script the "total (plain text) export" of your file (= tree, with interwoven body) into a file you then compile: Programming with a text file or several text files, but only as intermediate file to compile: No editor needed. And you'll get all the formatting you want, you'll get all the atomizing that you want (but not more than is reasonable), and if you want, you can use 10 levels of indentations in some very fractionized subtree, or just 2 levels of indentations in an "easy" part of your tree. Programming from within an editor is the best thing that was ever invented, and is much better than using Warnier/Orr diagrams (that technically leave a lot to be desired), for example. No need for pseudo-code (as in W/O diagrams), just put the real code into the body (incl. some little structure on the very deepest level only), but leave any "real" structure (= "designed" structure, in opposition of just "technical" structure, i.e. some if's, conditions and such on the deepest level, without any further elements deeper down except for the most immediate ones) out of the content, but place it, as "commentaries", into the "outline".

For if's, else's, conditions, you need intermediate items, with subitems:

NOT

a
b
if c

BUT

a
b
c? (intermediate item; only by introducing these you will get forced logic instead of a succession of disparate steps)
--yes:
----blabla
--no
----d? (as above: it's all about FORCING LOGIC)
------d=1:
--------
------d=2:
--------
------d=3:
--------
------else:
----------
And so on, for perhaps thousands of items and millions of lines within the body, in big programs; ditto for many components, i.e. a-b-c is not necessarily a sequence; just introduce as many first-level "source" items as you'll need for as many of concurrent program structures you'll deploy. (And of course, only partial recompilation of such sub-programs is perfectly possible by proper scripting, e.g. "export" a first-level item = recompiles the whole substructure of that item only.

It goes without saying that you'll do heavy use of "collapse all", then "expand this item's children", but there is not a single other way you can bring "law and order" into programming that even could come near.

(W/O realizations are awful (B-liner is awful), but they opened op my mind to REALLY structured programming.)

But all this belongs into another thread and a B-liner review.

Fredi wrote:

And so on, for perhaps thousands of items and millions of lines within the body, in big programs;
ditto for many components, i.e. a-b-c is not necessarily a sequence; just introduce as many first-level
“source” items as you’ll need for as many of concurrent program structures you’ll deploy.

Where do you do this? In a dedicated IDE or a programmer's editor? Or in a classic editor that organises syntax? I recall an outliner called Leo http://webpages.charter.net/edreamleo/front.html which is aimed at programmers.

For me writing in a simple editor and being able to mark the structure as I go along by comments could be ideal, but I can't think of a program that can do this, with the exception of Sense which uses keyboard shortcuts rather than markup.

Fredy,

This is largely a matter of semantics. You claim your "true outliner" is the tree pane in a two-pane outliner. Fine. That means the whole piece of software, content and all, is NOT an outliner... at least by your very definition... just the tree-pane is. In most cases, the tree-pane in a two-pane outliner is not nearly as flexible and easily editable as a good single-pane outliner (admittedly, there are not many of those).

As you point out, the origin of the outline is a focus on the structure and logic of the topics. That's what a one-pane outliner forces you to do.

I believe, however, that a one-pane outliner with inline text makes for a better writing environment, because it treats your project as a single document, not as a collection of documents. The problem with my approach is there is no application that does a good job of it. If you were to read my article about GrandView, you'd see what I'm talking about. GrandView allowed you to keep the content separate, as you prefer, but also allowed you to see it inline, giving you the best of both worlds.

I don't really understand how a two-pane outliner helps you to be more oriented in your "neighborspace" than you would be in a one-pane outline.

I'm actually not in charge of what people call their software, so if you want to call two-pane outliners true outliners, I honestly have no objection.

Steve Z.

Short Answer:

Steve, I tend to believe that you are right, and that for writing, outliners(1) / Word are better suited than outliners(2/3). What's needed then, is a good outliner(3), with good inline capabilities, incl. shifting around outlining levels between tree and content in both directions.

Detailed Answer:

(don't read, don't complain!)

I

Steve, you're perfectly right, 2-/3-pane outliners are outliner-driven working environments, and I perfectly see your point here: I extrapolate from the core element to the whole, you say the whole is something else than its core element, and should hence be named otherwise; indeed, people doing this on paper, in "ancient" times (or in school, today - given they don't work on slates, yet), do their outlines, PLUS their text, and do not call the whole an outline. On the other hand, we must distinguish between "outline" and "outliner", and an "outliner" would be a technical system creating "outlines" (among others, i.e. the text body, and perhaps further lists). I see this playfully, not the way hardliners see the world and its functioning, and I would be very happy to leave the term of "outliners" to the 1-pane variety if somebody came up with a short, crunchy name for our thing.

II

The irony here is that I've adopted outliners(2) after adopting askSam (with on-the-fly outlines by "fields" you choose, one of the greatest ideas in IM ever, but not developed further (problems: their system ignores but the very first entry in any given multi-entries field, and ditto for any but the very first of multiple identically-named fields, so both ways it leaves out any alternative "tag" of several tags an item might have - this limitation might appear minor to a non-AS-user when in fact it cripples the whole system: those "fields" in AS are THERE for containing many such "tags", and there is simply no way to have an alternative look on your material but by search hit table, not by tree building, and finally, this tree building takes ages when you've got too many items, i.e. for big databases, there is the indexed "professional" version, but the processing of the on-the-fly tree building does NOT seem to be enhanced by that indexing (for search) in any way) - had AS built on this finest feature of that sw, AND had they done away with innumerable bugs, it would be the very best IM system under several thousand dollars I'm aware of - hence my anger about it being laid into the hands of the marketing director who year after year didn't do but marketing speak to all those loyal customers complaining in their forum about the bugs, etc. - whilst real development had come to a halt years ago.

So, tree-wise, LOTS of better things than exist today, could be done, but this is rather demanding, programming-wise. But I spoke of irony. Well, the irony is that I came to AS then to outliners(2), after having realized - I spoke of it here a year ago - another IM system that was NOT an outliner in the strict sense of this term, not 1/2/3-pane: I didn't use 3rd party components but had to do which what I was technically capable of, within ToolBook's programming language, and so I did multiple cascading panes containing just ONE level within the tree, i.e. siblings (and additional panes for multiple parents, multiple cousins, etc.), and my multi-mouse click system (detailed here and in MI and UR fori) then assured that with l/r/d-clicks on the first fourth, middle or end of an entry there, the sub-items of that entry were shown in the same, the "next" (in a row 1-4), any particular of given 1-4 (by menu and also available by Shift/Alt/Control-Click), or a "standard" pane, etc., and similarly for the parents of any item in such a list ("parent" meaning "natural" parent, but if there were also "adoptive" parents, a little menu popped up); items having sub-items were automatically marked up with a special sign indicating that.

This was an incredible "flee flow" of many different clusters, and navigation was made easy by automatic coloring the background of the panes / item lists, and I even had toggles (state indicated by colors (bright vs. washed-out versions of the same color indicating other things) to assure that a normal "Enter" pressing would show the "children" in this or that pane (and of course, two sets of fields for two items at the same time; many "record fields" = a flat database with superimposed "tree"). As said before, because of instability of the programming language (not of my program), i.e. bad memory administration, I couldn't get it stable above some 6,000 items - I'm in the 6-digit numbers now...

I had programmed an internal tree, i.e. each item had exactly ONE natural parent, and I had routines checking for this (no deletion of an item having "natural" children; similar for renaming, similar for transfer of "natural parenthood" (= not "adoptive parenthood") to another parent, and in these, I had routines preventing recursion (recursion was allowed for "adoptive" things, but never for "natural" things.

I had also programmed an export tree, i.e. for export into Word (6.0!), the programme built up a (partial) tree from everywhere, but similar to AS' trees described above, and since tree building implies non-recursiveness, this automatic tree-building on export only included (= by definition) "natural" parentage.

So the irony here is, finally, that in the system I realized, a virtual tree was always there, was automatically maintained thru any given process, as a special, strictly hierarchical structure among many others, "associative" - I relied very heavily on clones, there, since I was so much in love with my own creation, so I couldn't put things into too many different contexts / virtual collections, or so I believed then! -, AND a tree structure for export... but on screen, I never saw any real tree in my own thing!

On the other hand, in my tree-free display system, I very well HAD alternative, underlying tree structures, i.e. from my "adoptive parents", I could trigger alternative tree structures, although flattened-out as in the principal tree structure based on "natural" parentage. So, anybody will easily get that AS' virtual tree structure, years later (from AS 6.0 on), had ultimate power on me, and you also will understand that with today's outliners2, I'm angry that their developers don't do alternative tree structures (it seems that in CT, there should be possible such a thing, with lots of manual work to get to it, not in any way at least semi-automatized if I'm right).

When I'm speaking of 4 "normal" panes in my system (= for 4 consecutive "indent" levels or perhaps for 2 different sub-trees, each with 2 "indent" levels, or whatever), I leave the special PM pane out, i.e. the very top pane "deciding" which "sub-trees" will then be shown in pane 1 - thus, I HAVE HAD, in the late Nineties, such a complete system, WITH PM, WITH clones, even WITH automatic adding amounts of items in their parent items (had a "recaculate" function for it; cf. B-liner) - and it was hoisting in perfection, without me being aware of the term...

So, when I did all this 15 years ago, with ToolBook, I cannot believe my eyes when I see how real programmers do in 2012 with all what's at their disposal today, e.g. components. In view of this, MI has done "lots more", with its tags, than UR has done, but lately, neither of them seem to do much...

(From the description of my system, programmers will deduct there was an incredible workload in my system since any rename, any move, etc. triggered endless checkings and updates of lists in recordfields of often many, many other items; on the other hand, all these routines could easily adopt to a real database...)

III

So, with all I want from such an IM system, how could I ever think an outliner(1) will do even 20 p.c. of what I'm asking for? And, as said, I never made that strict discrimination between "writing" and "stuff / material".

You ask, how can I be better "positioned" (my term) in my environment, when writing, then I'd be in continuous writing (my assumption, you said in an outliner(1)). You say, outliners(2) make a "collection of documents".

It's a good question, and a "false" assumption (ok, ok, semantics encore, technically you're right - but conception-wise, these are not "documents", no "aggregation of stuff" but "atomization of stuff"). In that UR thread (first part of "proper outlining"), I explained why it's reasonable to fractionize your material for some dozen of pages, into perhaps 200 items (of course, you need hoisting or different files). So, I do NOT see such items as "documents", just as "bits", quite as in the "margin numbers" in legal textbooks - 1 margin number, 1 bit of text - and I even devised a cross-referencing system allowing for cross-referencing these bits in writing, but for publication purposes! Which means, whenever I move such a bit (= item), the reference to that moved target will stay the same, and before publication, you run a routine that will update all these references. In other words, "scripting from the outside", I simply cannot implement a real system here, doing the updates on-the-fly, but at least, you can use special codes that are then "normalized" when your work is finished (afterwards, you could do more codes, for additions, etc., but there would be some manual adjusting - or more scripting needed, which is to say, better run the "normalizing routine" onto a "publication copy", and continue any further text editing within your original text body where all references are in their original "chaotic" way).

In 2011, I asked UR for such a system, built into UR - not even got an answer from them. Where's the interest of such a system? Well, let's have a look upon the most advanced of such reference systems, in MI. There, you can do something which is not possible in competing systems: You can reference a paragraph!

Here, we are in agreement, if you got perfect paragraph referencing, you don't need fractionizing your text into separate bits of text so desparately!

But this paragraph referencing in MI is for your screen work only: Try to export any such functionality into an export format for publication: You'll fail, nothing is provided here!

And that's why we need, if we use such an IM system for ultimate publication purposes, one of two things:

- A system, hopefully built into the IM system, that is automatically updated when you work, or at the very least, that is "normalized" when you finish your work for publication. OR

- Here, anybody{>23} can do this, a system that just does codes into the text body, then, upon pre-publication work, will be translated, by a dtp sw, into real references TargetExample{

Alec, if I misunderstood your question, reformulate. As I understood it, I can answer as follows:

In any outliner(2/3), I structure all my stuff as I would do in a W/O diagram, or you can even do the same within a program like MindManager, or even within a W/O diagram (but not with B-liner, but perhaps with MindApp, same developer). Problem with B-liner is, you only have 80 or 100 chars for "footnotes" for each item, whilst you need a real "note" field, for doing the "real code", i.e. the routines - no need to bring the W/O system to excessive details, you can perfectly do routines, with 4, or with 80 lines, as compact "notes": W/O diagrams are good for the overall structure, but if you find yourself with thousands of W/O items (even distributed on many sub-diagrams), I think you did "too much", especially so since W/O isn't real code but pseudocode, so trying to follow with W/O into the "body" level of a program seems a lot of unnecessary work to me. Structure: tree / W/O; routines: "notes".

Then, you will have the structure within the tree, be it a vertical outliner's tree, a horizontal W/O tree to the right, or the horizontal "mindmap" tree (also to the right) within MindManager or your Mind... what's it called again. The important detail is, it should allow for plain-text export as is possible in most outliners, with all headings / subheadings / nodes of any indentation level immediately followed by the corresponding "note", i.e. not "notes export" separately (and that's why I don't know if the W/O diagrams in MindApp will do; I spoke to B-liner's daughter (I think), and she said B-liner will NOT be enhanced in any way in the near future, so if MindApp doesn't allow for this way of export, any automatted W/O diagram will not be available).

Then, this complete plain text export will, by scripting / macro, straight go into a text file, like a text file you would have created with an editor, but WITHOUT any editor use! Yes, I tout editor use, for other things, but not for programming!

Thus, you'll have a plain text file (whilst in your outliner, in MindManager, or something, you will have formatted text, just as it pleases you there in order to better structure your program (components), and, again by scripting / macro, you'll compile it.

From your "production tool" (outliner, mind map sw, whatever), you will "export", as said, but need not export the whole thing, each time. If you have a big application in one such file, you'll first select your "main topic" / "source topic", do your trigger command, and several seconds later, your target program will be compiled anew - no switching to any editor or such needed, just export into file, then compiling.

And if have any fractioned program to develop, either you do it with several outlines / mindmaps / W/O diagrams (if MindApp works as hoped for), or you'll have one central such mindmaps, etc., and do the "export and compile" command from the item in question that is the source item of that separate file or the sub-mindmap or whatever - have the same trigger command trigger the same procedure from any such - original or intermediate - "source item" = source item for the big subtree of that item in question that the "export" command will build up.

When your projects develops, you'll place the initial consecutive A, B, C:

0
-A
-B
-C

under an intermediate "1" and begin an intermediate "2" for a second program component:

0
-1
---A
---B
---C
-2
---A
etc.

Then, you select "source" item 2 and trigger the "export and compile" script / macro.

This is perfectly possible in a network since sw like UR or MM are network-ready, i.e. anybody could trigger such partial recompile commands from within those parts of the "overall tree" being available to him.

If you don't like all items (= items' titles, the nodes in a diagram or the items in an outline tree) beginning with a comment char, you can easily extend your script or set the options in the export function of your design tool in a way that any such heading will be preceded by exactly the comment char of the given programming language; such an automatism will make your diagram / tree even neater in its appearance, whilst it takes the option from you to have a mix of pseudocode and real code in these items, but perhaps it's a good thing to avoid such a mixture in the first place, so in a sub-routine's title, you would write "while a > x", which would automatially be preceded in export by "//" or whatever is needed to comment that line out, and as first line of the "note", you'd replicate this "while a > x", not the least for better understanding the 60 lines or so that'll follow within that "note".

It goes without saying that there are numerous projects in which you would need several programming languages, all with their specific comment chars, so in the end, putting the (adequate) comment char right into the item's title would perhaps be preferable, but then, you'd probably only trigger "export and recompile" for one such component with one programming language, so it would be sufficient to put the adequate code to the respective source item, then having a routine replicating that individual code onto any subsequent ("child") items.

I know that in this scenario you don't have automatted formatting, etc. for your specific programming language(s), but you can do lots with scripting and text expanding, be it for "difficult to remember" commands, be it for 1-key typing of commands very often needed; remember in scripting languages you can use global variables, so it's possible to have just some keys but dozens of such pre-figured commands at your fingertips.

I must make a reservation: My system will not function with programming languages where indentation levels of the code is a constitutive element of the program syntax itself, since my system simply doesn't care about indentation levels of the code, and chances are if you have a look at the straight output, via opening the text file in an editor, it appears horrible to you. But then, you will "never really see" this horrific intermediate output, since any debugging is then done back in your production system (you'll just have a look into what the debugger presents you just in order to identify the place to look into, within that production system).

So much for MY system. Of course, you can optimize it, with more scripting (or just simply by checking more options in the export function), so that the intermediate file, that will then be re-opened by the debugger, will have correct indentation, blank lines, etc.

So, if your question was, how to assure that the debugger will "open" your production system at the "right" line, I'm sorry, that would need LOTS of further scripting. But for me, its perfect for everything I'm doing, and I even put my ancient programming into such a structured system (in order to contemplate, and perhaps to re-use lots of the structure of that code some day).

I particularly savor, except for the extradordinary structurization (which in a collapse editor is not possible to this point, or let's say, not as evident there), the fact that I can freely format my code, which I heavily do, in the tree and in the body.

I concede that better debugging facilities (= without the necessary step of looking up the incriminated lines, then search for them within the production tool) would be very welcome, but then, just compare my system with original W/O:

In W/O, you necessarily do DOUBLE WORK, any change within the graphical represenation must then manually be replicated by hand, within the body (= editor files), and vice versa, which is very time-consuming, very dumb work, and very error-prone. My system isn't perfect, but all is done within ONE production tool, not in two that must endlessly be synched by hand.

(As for automatic synching, of structure AND content - synching just structure would be devoid of sense -, between, let's say, UR and VisualMind, well, I kindly explained the interest of such interoperability to both... and never get an answer from either.)

Fredy wrote:

Steve, I tend to believe that you are right, and that for writing, outliners(1) / Word are better suited
than outliners(2/3). What’s needed then, is a good outliner(3), with good inline capabilities,
incl. shifting around outlining levels between tree and content in both directions.

This is exactly what Sense is for me. I can focus on the writing pane (right) and the structure will be developed in the content explorer (left pane, tree) and switch from one to the other constantly. Admittedly it is not lightning fast --it is a .NET application- but neither am I so it definitely doesn't slow me down.

Can you address the question I asked earlier on about the environment you were referring to in your programming example? Unless you have already somehow in the post above and I failed to comprehend it.

Sorry, our posts were cross-entered. I was referring of course to the post where you replied to Steve.

I will go through your reply to me and see if something is not clear.

All is clear, thanks.

Edit: I do it in my outliner. So I tried export of the tree only to B-liner, to MindManager, and to other such programs. Works like a charm, one-way, but it's not really useful, for one person having done "everything" in outliners(2/3) for many years: doesn't bring me anything new.

On the other hand, such a one-way export of the structure into a graphical representation could be very useful for collaboration, i.e. for discussing structure within a group.

Since most corporations do have MindManager, here's a tip: 1) You paste your exported tree into your main topic; 2) You muse how you could have avoided to have an unwanted intermediate topic as sub-topic of MM's main topic, the original source item; 3) Don't torture your mind anymore, just select the intermediate topic, rightclick and select the command "do away with the (current) topic" (or anything like that, I have the - free but a little bit horrible German-only version I told you last year how to get it); 4) The original source topic disappears, all its sub-topics now being sub-topics of the main topic, and you'll just have to rename that main topic, done.

And no, there is no dedicated W/O sw except the two from varsatek or how they are called. In the beginning of the Eighties, there was another W/O sw, costing exactly 10 Grand - but they offered rental schemes!

Anybody who does not only not like B-liner's GUI (it's terrible! but even they have got a presentation mode), but doesn't like W/O diagrams either, well, the alternative were Nassi/Shneiderman diagrams. In English: Don't like Europe, anymore? Ok, but Syria, then?

But seriously, programmers in corporate environments should consider programming within MM or something similar, collaboration features and presentation features, and the notes fields, make such programs suitable for programming. (I must admit I didn't check if those programs do the necessary "total export", i.e. notes right after the headings. My (old and free) MM version 8 does NOT seem to do it, oops! But newer versions, other makes... or just almost any outliner(2/3) of your choice, and the graphics for presentation purposes.

Crossed again. It's 1 a.m. I thought only our U.S. fellows were awaken this late. This is an addiction, you know... Good night.

Fredy wrote:

But seriously, programmers in corporate
environments should consider programming within MM or something similar,
collaboration features and presentation features, and the notes fields, make such
programs suitable for programming. (I must admit I didn't check if those programs do
the necessary "total export", i.e. notes right after the headings. My (old and free)
MM version 8 does NOT seem to do it, oops! But newer versions, other makes... or just
almost any outliner(2/3) of your choice, and the graphics for presentation
purposes.

One thing I don't get in the above approach, is how you can get syntax highlighting. Any programmer's editor will provide this but I don't think that outliners or mindmappers do, though admittedly it's not a feature I had ever considered while testing outliners. The only exception I know of is Leo, but from my limited knowledge of it is not multi-user.

Fredy wrote:

Anybody who does not only not like B-liner's GUI (it's terrible! but even
they have got a presentation mode), but doesn't like W/O diagrams either, well, the
alternative were Nassi/Shneiderman diagrams. In English: Don't like Europe,
anymore? Ok, but Syria, then?

What's wrong with flow charts, for which a much broader range of software seems to be available? Apparently, anything you can do with Nassi/Shneiderman diagrams, you can do with flow charts http://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram and the latter are much easier to change.