Page 2 of 4

Re: Clones in Freeplane.

PostPosted: Mon Feb 03, 2014 3:19 pm
by pilominco
I think clones are a bad idea. The reason is that their logic y fuzzy. In fact, phylosophially, any categories are always mutually exclusive. That is how concepts work in real life: big-small, black-white, etcetera. When third options are permited reason, inteligene itself gets lost. This is deeper than it looks like. Graphs, versus trees, are undetermined because hey incorporate different criteria depending on which line is connecting nodes. In a tree, the criteria is unique: allways distince oposition between brothers. The proof is clear: How would you print such a map in the linear form that is typicall of a word processor? Repeating the cloned nodes, or rather showing them only the first time they appear? The problem with all this is that you are thinking about how to present info, not about the real way of organizing it. If you have different criteria for a node you are failling to organize. You are failing to make a decision about the way you look at the world. That is against the true sense of inteligence. So.... this whole thing would radically modify the spirit of the program. This whole thing could end up weakening the program in a fatal way. A tree is for dividing things once and once again in a consistent manner. If you divide in different ways a the bottom line you are making the world confusing. Also, navigation would be a mess... Which parent do we have to choose when we go backwards? Logically it has no sense. I am concerned about the future of the whole project if this idea starts confusing everything in the program!

Re: Clones in Freeplane.

PostPosted: Mon Feb 03, 2014 11:05 pm
by andressf
Cloned nodes may seem to have important and interesting appliations since, in general terms, they would allow the user to replicate clusters of information, their organization and functionalities in different places of a map, i.e. under different contexts (since the same information can imply different meanings, depending on the nature of the branche they are inserted into, their siblings, ert.); besides, it is thought that such replication could allow a lot of time and effort savings. But, I think this very general appearence may also become a strong limitation to the usefulness of cloning if the clone becomes a mere, dull replica without allowing any difference in at least some of its elements.

But, to see these possibilities and limitations in more concrete terms, with examples, it is necessary, I think, first to agree the terms of the concepts we are talking about, because I think there is much confusion in the understandig of concepts such as cloning, mirroring, multiple parents, conceptual map, network structure. These concepts are often conceived as more or less equivalents, or closely related to each other, or the one conducting to the other(s). The problem is that such misunderstanding hinders the visualization of the possibilities and specially of the limitations of cloning. I think that a much better approach to the so-called cloning is (for the reasons I give below) to develop synchronized nodes.
The exposition of the mentioned aspects needs a certain degree of detail and I adopt exclusively a user standpoint without considering the implictions of cloning in terms of programming. My exposition below can be have resulted in a very tedious story. Apologies beforehand.

1) The first common mistake is, imho, the identification of cloning with the creation of nodes with multiple parents. I think that, graphically (i.e. visually), this is not necessarily true.
On the screen, which is the canvas where the map is dessigned and the space which the user is visually confronted to, a clone has graphically a different parent than the original (i.e. the cloned) node, and this fact gives a different meaning to the twin nodes, since the meaning of a piece of information (the node and all its annexes, parent and sub-children, etc.) is given, in most relevant cases, not only by the node itself but also by its environment, context or place in the structure. For the user thus it absolutely does not matter whether in the machine, in the program, the cloned and the clone nodes are logically only one and the same node: that a node has multiple parents would be true for the user only when those multiple parent nodes are graphically linked to the same child (be it by edges or other kind of graphical link); otherwise for the user there would be no n--->1 relationship.

To explain it by an example, I take here the one showed by Topicscape in this article:
(referred to by danielk159 in a previous entry of this thread). In that example, there is a root node ("computer security") with children ("network", "hardware", "software"). Each of def these children are in turn a parent of the same unique two children ("defences", "vulnerabilities"). Besides, all the hierarchical relationships are represented graphically by edges. We have thus a visual, graphic structure of network relationships: one 1--->n relationship from the root to the parents , from the parents to the children n--->n relationships. Here thus, there is a clear, visual case of children with multiple parents.

But next, by cloning the two children, each parent is represented graphically with two children (so that "network" has two children, "defences" and "vulnerability"; "hardware" also has two additional "defences" and "vulnerability" children; and the same for "software"). Now, in place of two children there are thus 6 children, each parent and its children conforming a different unit, isolated from the other similar units. OK; it is an example of the applicability of cloning. But, wait; let's look a bit further into it.

I had said that, commonly, cloning is identified with the creation of nodes with multiple parents. Taking Topicscape's example we can see how this identification is misleading: in that example, indeed, cloning has resulted not in children with multiple parents, but in parents with multiple children. Exactly the opposite of the common conception! In other words, Topicscape application of cloning has resulted in this example in the transformation not of a tree into a network, but of a network into a tree! For its developer, however, contrary to the perception of the user, there are not 6 but only two children.

It could be alleged that since the user has to manipulate only two children in order to replicate any change, also for the user the cloning results, in the Topicscape example, in children with multiple parents. But then, this assessment would badly violate one of the (useful) foundations of mindmapping: that the relationships must be explicit, visual, by graphical edges, connectors and so on, and by the position within the structure of the tree. There are of course other sorts of relationships in a map, so as those given by hyperlinks; but these are auxiliary objects, objects that may or not exist in a map and their existence may not even produce a visual structure (We could have, for instance multiple floating nodes in the screen each with a hyperlink (not connectors) to each of the other floating nodes, so that they become a "virtual", not visual network, map, etc. The user would consider at first sight, intuitively, that in this case no connection exist between the floating nodes)

Cloned nodes are thus not necessarily nodes with multiple parents but rather replica nodes that may or may not have multiple parents. For the user to intuitively handle cloned nodes as children of multiple parents, the map should show that structure graphically, so that multiple edges go from each of the multiple parents to each of the single cloned children. Otherwise, from the standpunt of the user, we would not be in pressence of children with multiple parents.

2) Another common mistake is the identification of cloning with the transformation of a map into a network, and thus that, somehow, by developing a cloning feature, Freeplane would become a tool for analysis, development, planing, projection, etc., etc., of network relationships instead of tree relationships so as described by a "mere" map.

To begin with, a map is a network (a visual network) with specific characteristics. As such, it is not inferior or less complete than a network with full inter-connections n<--->n. It is simply sometning different, thus with its own domain of applications many of which could not be handled by a fully inter-connected network. Exm.: a user made a research on certain topics. This researcher used so well maps, as flow charts, pictures and network structures to try to identify the relationships between different concepts, and to write about and represent the preliminary pieces of findings. But then, this researcher had to make reports and expose the advances and final results of the research. For this, Freeplane (and Scrivener) were used in order to structure the report and the presentation, since in both cases it is the most natural thing to apply an outline structure. It would have been something crazy if the researcher had intended to use a fully inter-connected network to represent the structure of the reports and expositions. And the same is valid for To Do tasks, financial reports and their calculations, organizational schemes, etc., etc. (What would one think of somebody who tries to represent a balance sheet or to plan a daily agenda in the form of a fully inter-connected network? or, as we will see below, to do that with a concept map?)

Maybe there could be a fully interconnected network design program that could also produce map networks. Whether in its mapping function such program would be as efficient and powerful as a specialized good mindmapping program, so as Freeplane, is something very doubtful. Besides, this would imply not the transformation of Freeplane, but simply the development of another very different program, in parallel to Freeplane (even it they could seem not to be two very different programs),.

I think Freeplane should not waste its time trying to become a fully interconnected network design program. Whether Freeplane developers want to (or should) develop an additional, a Freeplane 2 (a fully inter-connected network design program), that is a very different matter. In any case, it would be, I think, not better nor inferior to the current Freeplane: it would simply be a very different program, with different applications and maybe some interconnections to exploit the same data.

3) Another misconception is that clone nodes are a step in the transformation of Freeplane into a conceptual-mapping program, and that conceptual-mapping, being tuperior to mindmapping, is the right direction Freeplane should take (ergo, that the most important new features should aim in that direction).

Since conceptual mapping is, in very general terms, a fully interconnected network design program, the same observations I made to the use of such networks (in item 2 above) are valid in this case: concept-mapping is not better nor inferior to mindmapping: it is something different and therefore they have different applications.

Concept-mapping is a very special form of a fully interconnected network program. In such kind of mapping the important point is not simply to show that an object (a concept) has multiple relations and that some or all of the objects (concepts) of a set are somehow more or less mutually related. Instead, the most important point is the relationships themselves, the explicitation of the nature of each relationship in the form of a proposition. That is something that is absolutely not necessary per se in a mindmap but just the contrary: in a mindmap it may or not be important to show graphically what the relationship represented by an edge between two nodes is; it suffice to know and make explicit, that a relationship exists.

But there is more in it: besides being made explicit, the concept-mapping relationship between objects, the proposition, must be a movement, an action, i.e. it must be a verb or a verbal statement, as for instance, “be”, “is x of”, “has”, “has to”, etc., so that we would have, for instance: John “is the son of” Peter; John “has” a dog; New York “is in” USA, a table “is made of” wood. Unfortunately, many (maybe most) people use a concept-map as a simple way to construct a fully inter-connected network with (when they have been explicited) very poorly formulated and not articulated propositions, without respecting the basic rules that lead to a conceptually well designed concept-map. And, constructing a well designed map may become a very difficult and time demading task, something that is on the opposite side of a mind map, where the rule is that there are (almost) no rules.

I think that Freeplane should not waste its time trying to become a concept-mapping program. Besides, as Dimitry says in a previous entry of this thread, floating nodes can be used to design a concept-map. In this sense, it is good to remember that in such Freeplane concept-map, labels can be attached to connectors, so that a label can be used to formulate the proposition between two concepts (floating nodes). But, if somebody wants to work full concept mapping, better to go to cmap tools, an excellent concept mapping program. Maybe with more time and resources, it could be considered to look for a good integration between these two programs (but this is valid also for Freeplane in relation to many other programs).

4) I mentioned that, instead of (replica) cloning, it could be considered the development of node synchronization. The big problem is that synchronization is very demanding in terms of programming (I can only suspect the difficulties, sinceI am not a developer or programmer).

The synchronization would offer the possibility of choosing the elements of a node (and its branches) that would be synchronized, with the exception of some basic elements of the structure (core, details, notes, edges, styles) that would be necessarily synchronized while making sure that the uniqueness of the synchronized nodes remain. This would allow a lot more and more relevant applications than cloning by simple replication. For example, if I have a central map with a child branch “Industry” showing the industrial branches of USA (as children of the “Industry”node) with, besides, their structure in terms of volume or value of production, etc. in attributes, I could then use the same basic branches to explain the structure of the industrial branches of a specific region in volume, value or even another characteristic using ad-hoc calculations with the Freeplane's Formula. module. And this could be made explicit if, besides, I would insert connectors with labels (each connector pointing back to its origin node).

If there is no degree of freedom allowing certain variables to differ between cloned nodes, maintaining the uniqueness of the (partially) cloned nodes, the applicability of cloned nodes decreases notoriously. The limited applicability would often produce only dull applications. For instance, the meaning that the position of a node or branch within a map confers to a node will we obliterated: it would even be possible to place a cloned node as child of a parent with no relation at all with the parent and with no element that would allow to discern the reason or meaning of such bizarre localization. In the case of the Topicscape's example mentioned above, we see that the “network”, “hardware” and “software” nodes have all “defences” and “vulnerabilities” as cloned nodes. But, what does this mean? that the same kind of defences are needed by networks, hardware and software? and also that the same kind of vulnerabilities are present in all those three matters? Should not the defences and vulnerabilities be prolonged with branches containing nodes differentiated at least by different labels? But, would simple cloning (replica à la Freemind) allow to make this adjustments? I do not think so. And, besides, you do not need to be a computer scientist of mathematician to state such a shallow conclusion as that all three those elements (“network”, “hardware” and “software”) need/have defences and present vulnerabilities, and you do not need to demonstrate that using, besides, a mindmap or network. It could be alleged that this is simply a didactical example of cloning. However, it is a very good example that show, unintendedly, the limits and dullnesses of simply cloning, i.e. of cloning as simple replica, so as up to now happens with cloning in Freemind (in Freemind I couldn't even find a warning in case I deleted a cloned node, and it is not possible to see the cloned node that would be deleted in a very big map with nodes that are outside the visible space of the screen).

The question is again, obviously, whether the time and resources allow to design a feature making possible synchronized nodes.

5) A last misconception I would like to mention is the identification of cloning with mirroring. They are not the same and one example should suffice to show the difference: with mirroring I could build a sort of fishbone map (two main mirrored and in parallel branches), but not with simple cloning (replica). And, I suppose, mirroring would be more demanding in terms of programming effort. Besides, the same limitations are replica cloning could arise.

6) Cloning nodes even as simple replica may have important applications. But the applications are not a lot and besides they do not offer real creative possibilities, due to the factors mentioned above. These applications are rather passive. They are related to the need to access and show exactly the same information in different places. I think hyperlinks between nodes and maps provide a good alternative in most cases other those dull applications as in the Topicscape's example. On the contrary, synchronization with choices (as mentioned above) could allow a really wide range of creative applications since the original node could in many cases act as a basic template allowing entire families of many similar though different copied (synchronized) nodes and branches (something alike to taylor-made massa production).

Cloning is trendy. Cyborgs, cloned sheeps, etc. are in the mode. So, many people, even without fully understanding the implications, would be impressed by hearing that Freeplane can also clone nodes, maps, etc.


P.S. I have just read the preceding entry by pilominco ( ) and an entry in another thread ( )warning about the dangers of cloning. I am mostly in agreement with those arguments. But I think those arguments are true for the simple replica cloning, so as in Freemind. On the contrary, synchronizing certain elements of nodes could be very useful and the dangers of replica cloning would disappear since each synchronize node would keep a unique parent and position within the map.

Re: Clones in Freeplane.

PostPosted: Tue Feb 04, 2014 8:21 am
by dpolivaev
Andres, thank you for your detailed thoughts. I still have two questions.

1. You have right, writing about node clones I actually meant that nodes should share some content. I thought that folding state, the connectors are not shared and that the node hyperlinks relates to just one node in the resulting tree, so each visually independent node has its own ID. All other elements including child nodes and node attributes should be shared (which is just the most effective form of replication I know :) ) . After your post I asked myself if other separation of shared position dependent content should be considered, for instance whether attributes, node details and notes should be shared or not and whether it should be done configurable or just use the same rules for all nodes sharing the content. Here I would like to get your ideas and also use cases and ideas from other interested folks.

2. Actually freeplane mind maps can be considered graphs right now due to connectors and hyperlinks making the maps a kind of linked hyper text. Yes it can be asked whether visual duplication of content in the map is still needed.

By the way, I can not follow the arguments telling clones are dangerous because of no visual indicators as such visual indicators could be easily added. Also nobody would be forced to used the clones or shared content, they are just an option.


Re: Clones in Freeplane.

PostPosted: Wed Feb 05, 2014 12:18 pm
by iainkewley

Clones will make our lives herea lot easier. We use a 7000 node map with several hundred users to explore data In a hierarchical way. They often get to the same information via different paths, cloning will mean we can give our users what they want, without us having to manually duplicate


Re: Clones in Freeplane.

PostPosted: Wed Feb 05, 2014 6:10 pm
by dpolivaev
Please help me to define how exactly the clones should work. Currently I think that cloned should share everything except for folding state and incoming connectors and links which always refer to a special position. It were however possible allow to split information contained in the node in cloned and position specific part. Is someone interested in that?

Regards, Dimitry

Re: Clones in Freeplane.

PostPosted: Wed Feb 05, 2014 9:38 pm
by andressf
After your post I asked myself if other separation of shared position dependent content should be considered, for instance whether attributes, node details and notes should be shared or not and whether it should be done configurable or just use the same rules for all nodes sharing the content.

Would it be possible, in terms of programming, to let the user make the choice of the content to be cloned? I mean, could it be cloning made configurable so as when configuring a filter, or when configuring the variables of the format, calendar and attributes in the format panel)?

1) I will try, below, to give some examples of possible applications of cloning. But first, to answer your questions in a previous entry, I would like to mention that I also am of the idea that inline hyperlinks practically eliminate the need for visual multiplication of clones within the same map, and that such hyperlinks, on the other side, offer a much safer centralization and uniqueness of data, and great flexibility with the layout of the nodes: the inline hyperlinks can be placed overall in one or many nodes, details, notes and attributes; they can even link with hundreds of other maps and their specific nodes, and these other maps and nodes can also link back to the original (besides, Freeplane has already a tool to alleviates this task: the link anchors); and the visual representation of inline hyperlinks can be easily made much more attractive since it is possible to replace the hyperlink with ad-hoc characters, fonts, colors, phrases, etc. I think, however, that there will always be people and situations that could make use of cloning as in Freemind, cloning by simple synchronized reproduction with as result a repetitive visual multiplication. But, if the cloning with variable configuration which I am asking about could be implemented, it could also satisfy those needs, without blocking the need for a greater flexibility.

2) There could be many applications for flexible cloning: taylor-made reproduction of nodes could be applied to reproduce, while adapting to their specific environment, all sorts of structures, catalogues, inventories, plans, TO-DOs, agendas, pieces of text, etc., etc. For instance:
- The quantitative distribution of industries in a country and in each of its regions. In this case, we would have a template whose attributes would specify different quantities and % for each industry.
- The same could be done to represent the polls in an election (president, governor, etc.) for each party in the country and the regio (there will be 0s, of course).
- Also, for planning catalogues: a map showing the same models of cars, or computers, clothes, etc., for the different stores of an enterprise, specifying different prices and discounts, etc.
- The structure of the staff (of a part of it) in the different localizations of a company
- A comparative map describing different wage levels for the same positions in different industries, companies, etc.
- The inventories for the different factories of a company (again, in attributes, different quantities, quality indicators, monthly consumption, etc., etc.).
- The repetitive tasks to carry according to a plan within an organization, but specified by unit of the organization.
- The repetitive tasks to perform during the different phases of an investment project, or a research project, etc., but at different times, locations, etc.
- The register of the same daily (weekly, monthly, etc.) routines (in a school, company, church, batallion, etc.), at different dates, locations, etc.
- The same for other activities in sports, training, etc.: the same activities, but for different persons, groups, etc.
- Since attributes can carry formulas, the possibilities of cloned nodes with different calculations are enorm (for instance, most of the suggested in the examples above)
It would also help, in this case, to explore alternative calculations, sorts of equations, etc., etc.
- etc., etc. examples (sorry, I get a bit tired).

3) As it is easy to be seen, all these variations could be possible by changing (i.e. selecting) only a few variables: essentially, those that can be represented in attributes and in labels (in connectors) Now, if there were the possibility of selecting more variables that the implied in these examples, cloning would offer really an enormous number of possibilities. Imagine that when cloning, for instance in those mentioned examples, we could have the possibility to adapt these variable and a couple of others so as some text, LaTex scripts, etc., while keeping, though, the rest of the basic (and other) structures of the nodes (and its children).

4) If it would not be possible (due to demands of effort, time, resources, technical viability, etc.) that the user could determine the variables that would be cloned (i.e. the variables that not would be cloned) then maybe it could exist an intermediate way, a more limited flexibility when cloning, so as (if I have well understood) Dimitry seem to have been thinking about: fix beforehand what those variables will be. and, in this case, let the community decide (suggest, etc.) what should be cloned (i.e. what should not be cloned, the free variables: maybe attritutes, some container's content, ...?)

5) Maybe an FP preview implementing a first version of the cloning feature could help a lot to discern what is or not possible and stimulate the users to visualize possible applications. And I think that a cloning feature with at least some of the characteristics mentioned above for the two alternatives (i.e. flexible or less flexible, depending on the mix of elements that the user could be allowed to choose, discarding cloning as it is now in Freemind) would be so great that it wouldn't matter so much if more time is necessary for it to be developed.

Re: Clones in Freeplane.

PostPosted: Wed Feb 05, 2014 9:57 pm
by dpolivaev
2) There could be many applications for flexible cloning: taylor-made reproduction of nodes could be applied to reproduce, while adapting to their specific environment, all sorts of structures, catalogs, inventories, plans, TO-DOs, agendas, pieces of text, etc., etc.
I would like to accent the difference between a template which is used as initial value and can be changed later in any way and a clone where all changes of shared element and the node structure are propagated to all replications. I have not seen why it is necessary to replicate changes in some variables during allowing to change other values independently. I have also not understood why the same node structure would be necessary for e.g. different products in catalogs.

Maybe an FP preview implementing a first version of the cloning feature could help a lot to discern what is or not possible and stimulate the users to visualize possible applications.
May be, let me try it.


Re: Clones in Freeplane.

PostPosted: Wed Feb 05, 2014 11:40 pm
by andressf
you are right in accentuate the difference between a template and a clone (or I would say, between using a templates and cloning). It should be clear from the context of the passages where I used it in my notes that I actually am in agreement with what you say.
The necessity to replicate some elements (variables) of the nodes while allowing other elements to change has no other aim that trying to reproduce clones that are not completely identical. Just the example of the catalogues should allow this to be seen: many enterprises offer a basic assortiment of products, but due to the variety of the demand according to the different markets (localization, age, income, etc.) those enterprises use a marketing strategy based on exactly the same models (some with minor physical changes) but with different names, prices, dates of presentation, etc. This is often to be seen for instance in Europe, where you find exactly the same computers in neighbour countries but with different names, prices, date and period of sales, marges of discount, etc. Cloning nodes containing the same images of these models, could allow, for the map to be useful, to specify this differences while maintaining all the rest of characteristics synchronized: if a change in a non variable characteristic (i.e. not allowed to change locally but only centrally) takes place (for instance color changes or some peripherals are not any more included in the offer), then all the branches (stores) would reflect automatically the changes while allowing to readjust locally (i.e. without cloning) some other aspects (discount marges, period of sales, etc.)

To speak clearly: cloning in the way Freemind does, even with certain adjustments to avoid the dangers of deleting nodes inadvertently, etc., seems to me fireworks. I have not been able to find an application that could not be much better implemented with Freeplane hyperlinks than with Freemind clones.

Re: Clones in Freeplane.

PostPosted: Thu Feb 06, 2014 10:04 am
by pilominco
I have been thinking about the clone nodes and I am starting to understand them better. Let's see. First of all, I believe that at a fundamental level the tree of the map will keep being the same. In this structure all nodes will keep having a single parent. This is very important. I am not a programer, just another user, but that does not mean I don't use scripts. And those scripts need to navigate the tree in a consistent manner. And that means a single parent for any node. Any other solution would be a mess. For example: ¿How would we avoid repeating the actions of a certain script if branches attach to exotic and unexpected places?
But this won't happen for a very good reason: What I have come to guess that Dimitry has in mind is not a change in the traditional underlying tree, but a change in the way the info is PRESENTED. A node clone would not be a repetition of the information, and it would not be several parents per node. It would just be a visual effect. Like special effects in a movie. The so called cloned node would just be a new VISUALISATION, placed somewhere else, far away from the true REAL node and it's true REAL non “cloned” branch. This is why I think it is logically similar to the connectors we already have. The difference is that we will be able to navigate this alternative view in the same view we navigate normal branches, which is not something that connectors are able to do nowadays. The cloned branch, of course, will be dynamic and not static, meaning that any changes done in the cloned branch will be stored in the real branch.
This also means that when a script navigates the tree, it will go through the real branch, in the proper place, and ignore the cloned view. In this sense, the cloned view is NOT a real part of the tree. It is just a window on reality, not reality itself. This way, we can keep all Freeplane virtues, and still add this new functionality that some people are demanding. A couple of things though:
First, I don't think cloned nodes is the right terminology. In fact, the new nodes are not real. They are virtual. Like an hologram. Like a view on reality, but not reality itself. The thing with the usual meaning of the term 'clones' is that both individuals are equally real, whereas here in Freeplane we have one real node and one virtual one. So, my suggestion is to call the new feature VIRTUAL NODES. This way anyone can rest assured the fundamental structure of the tree remains safe and coherent. I believe virtual nodes is a clearer and more exact terminology.
Second, I think the virtual nodes should be visually represented in a different way than normal ones. Maybe through a different line style for the branches or the edges of the node. One should know it when you find yourself working in a mere representation of a node that in truth belongs somewhere else.
Third, I must say that this feature will ultimately prove to be less useful than their advocates believe. The real node will still belong to the real branch in a well determined position for logical reasons. When you use a virtual node to attach it somewhere else, you are trying to change it's meaning to make it say something slightly different. But structure means something about reality in any Freeplane map, and the real node belongs to a certain real parent for a good reason. This means that virtual nodes will inevitably also be somewhat paranoid. They will never truly fit in the new virtual position. They will always be outcasts. Things that are trying to become what they are not. This circumstance won't necessarily be a catastrophe for the users that want this feature. They probably can stand this. They only need to access paranoid nodes more easily, from different places, and they don't really need univocal meaning for the nodes. I guess they have the right to view things like that. Obviously, I have been calling virtual nodes what others call mirroring
Conclusion, then. We can make navigation easier for some people with this virtual nodes, and still preserve the perfectly structured underlying tree. And Volker says it wouldn't be a terrible mess from the point of view of the developers. So, once you understand this proposal of virtual nodes better, it is probably not that dangerous. But still, it will never be that useful, because in a system where position in the tree structure is a fundamental part of the information stored, things can't really have different positions. My prediction, thus, is that this feature will in time prove to be not very useful, and used rather scarcely. But I have to admit it will be a flashy and appealing fancy option at the beginning. And, furthermore, if it doesn't ruin what we already have, and it can satisfy some people, let's go for it. The more happy people we get on board, the stronger our program becomes. And it looks like we still have to fight competition back. Other programs are full of flashy things. To preserve our serious functionality we probably have to also match those flashy effects.
Any way, sorry Volker, Dimitry and Andressf. I have jumped into this issue not to bother anyone but rather to fight for the product. We all try to give back to the project whatever we can because we are so grateful for it existence. We will remain committed to it's well being and longevity. :-)

One more thing: What Andressf calls a conceptual-mapping program would, in my opinion, be very inferior to Freeplane. Mainly because in Freeplane you show and hide detail through folding. That makes for a movement, diving or surfacing in complexity, that is absolutely decisive here. You can not fold and unfold a diagram of a network, because the folding would reach back to you, through the connecting loop, an the whole diagram would collapse. That means a “conceptual-mapping” program totally lacks the “different degrees of detail functionality” that we so much enjoy in Freeplane. Our program is unparalleled in this, whereas there is a ton of other products that can do diagrams with no limitation. Their lack of limitation is also their weakness, and the reason why they feel so dumb compared to Freeplane. This is why any mention of the possibility of Freeplane implementing real loops, as for networks, hugely scares me. If such a thing ever happens, that day would be an Armageddon. People should understand that they can use Freeplane as a project management tool, and in many other ways. Actually, people use spread sheets as databases or word processors. But Freeplane is an information classification tool. It is like a futuristic and much smarter database. There aren't many good programs that can do that. In fact, there is just one. Maybe two, if you consider Freemind a different thing (which it isn't). We absolutelly need Freeplane to be itself. There is no alternative that can stand even remotelly close to it. I would very much appreciate if people that come from very different perspectives could adapt the program to their needs without indulging into the temptation to kidnap it's nature. No networks and drawing, please! Clasification is not circular! I beg you about this!

Re: Clones in Freeplane.

PostPosted: Thu Feb 06, 2014 10:11 am
by pilominco
I thing clonning should be a view. I wouldn't hide some of the details, like properties or formatting. Like you said before, in the new view I would keep ANY and EVERY THING except for things that strictly relate to placing, like connectors. It would keep things simple and consistent. The problem is that if in the new view, what I call VIRTUAL NODES, you start modifying things, then you don't really have a clone, but a new born entity, different, specific. And, once again, we would be blurring the data model: this new things would not exactaly be the old things. Do we want to complicate the world with things that are kind of the same but no totally the same? Please: Clones or not clones, but not something in the middle. I strongly feel the right paradigm is VIEWS. With this new view, everything is clear and simple. The underlying data model would remain the same, and the funcionality request would be met: easy navigation to a certain branch through different paths. That is all we realy need. Please, don't have the “clonned” or “virtual node” chage some part of it's information compared to the original one. That would lead to confusion! Thanks for your time and attention.