This subject is so crucial that I have opened a separate topic for it. I'll try to reiterate what I think that FreeMind is. FreeMind can be succintly described using just three words: hierarchy, folding and extreme ease of use. This is what makes FreeMind different from other programs. FreeMind does not always deliver on the promise of being easy to use, but that should be fixed.
The suggestion to extend FreeMind to handle graphs removes the two defining words: hierarchy and folding, and replaces them by another word: graph. General graph is not a hierarchy, and in informatics, trees are studied quite separately, and for good reasons.
The real trouble is that in the context of graphs, the concept of folding becomes unclear. When I try to fold a particular node, what should happen? This issue remains unresolved even with dag. A suggestion to let user mark the area to be folded is unclear. Ok, let's get user to group nodes into the groups to be folded. This way, I have achieved some kind of folding of level 1. But how do I proceed to level 2? I have to force user to create group of groups. This process extended, user has to do a lot of work himself. Without digging any further, I assume that it is not difficult to show that the concept of folding is closely connected with the concept of hierarchy. Another thouble is dragging and dropping. If try to drop a node to another one, what should happen with the relations? Should they be broken?
As soon as the folding becomes expensive for me in terms of steps to do and things to think about, I am dropping the application, I am not interested.
Let us now follow another line of reasoing. If we are talking about graph, what does FreeMind better than JGraphpad or Dia? Why would anyone want to bother himself with extending FreeMind, when these programs are already there, and probably more stable, with much more rich functionality? My tentative answer is: we've got folding, we can get by without graphs, we are glad someone does the layout for us, and our application is very simple. Namely, we don't have to position the boxes ourself, and we don't have to think about how to connect them, and how to make the connections not cross one another. The task of not having connections cross one another is not solvable already with dags.
And third, let us now show some examples of hierarchies, which are hardly ever dags or general trees. Among these are folders of file systems when we forget about links, hieararchy of placeholders in your flat including shelves, boxes and folders, tree menus of applications, books consisting of chapters, sections and subsections, physical entities consisting of their parts, basic organizational structures of enterprises, classification of species etc. I would say that this has something to do with the operator *to belong* and with *order*. If I try to keep order in things, be it essays, tasks or documents, I must be able to answer the question: where does this belong? With dag, I am already unable to answer, because something can belong to two places.
I will allow myself yet to conscisely repeat what Christian has already posted:
1) The majority of mind maps I have used and seen the last years only exist on paper, and I did not feel the need to leave the tree, apart from cross links. Even the inventor of mind maps has only tree-maps on his homepage.
2) Freemind consists of the three main ingredients: structure, folding and auto position.
3) Generalising the structure means that the other two ingredients can no longer be part of the DAG-view.
3.1) In general it is not possible to fold a node inside of a DAG, imagine: A -> B,C. B-> D, C-> D, how to fold B?
3.2) In praxis it is not possible for FreeMind to know, which positions the nodes in a DAG should have.
3.3) Imagine implementing the method "cut" for copy and paste. Should it cut the node D in the example above? How many variants exist of "cut" then?
To conclude, I don't have anything against applications allowing you to work with graphs, it's just that I would like to have an application working with trees only, and this application is FreeMind.
I would also like to keep a simple tree-based version of FreeMind. A graph-based version (GraphMind?) could be done as a separate development, but I would like to continue developing the tree-based version.
The current tree-based FreeMind meets the needs of a large subset of our user community. I would like to improve the usability in a number of areas, and possibly (in the future) add the ability to join nodes -- which will require an extension to the file format.
I actually stumbled on FreeMind when looking for a tool that provides a graph rather than a tree interface. I found something similar called Compendium, but it's still not exactly what I want.
I think it would be beneficial to use JGraph as a GUI for FreeMind for networking applications. That is, people networking where you want to store a framework of your contacts and how you met them. You might want to store weak and strong links and have some sort of weighting on the edges and such. That is what I was originally looking for. Does anyone know of any mind mapping tools that provide the graph interface?
I agree that the tree is the way to stay with FreeMind. Thea ease of use, and not having to mess with sizing nodes and drawing connectors is great. I certainly wouldn't bother with electronic mindmaps if I had to draw them with tools such as JGraph (which are better for drawing pictures in my opinion).
However, I do think it would be valuable to be able to have the following features:
1) Multiple root nodes in one map.
2) Relations between nodes.
(2) would give a lot of the functionality of graphs while retaining the tree structure. Relations could be in the form of icons like the red arrow used for links, but the links could take focus and centre on a linked node within the same (or other) mind map.
Alternatively, links could be displayed as dashed arrows to another node, but I think this would be too expensive in terms of routing algorithms, algorithms to handle appearence if nodes are collapsed etc.
The link approach seems a good solution, and would be fairly easy to implement. The addition of a unique ID for each node in a map, and the addition of multiple links per node shouldn't be too hard to implement (especially if there is the ability to 'Copy Node ID' in the context menu.) in a basic form until it is worked out the best way to do link to a node graphically (for example by setting the display mode to a new mode 'link' allowing no editing actions, and returning to the previous node with the linked node's ID on a double click)
Just some thoughts anyway!
OK. Ignore the last post - it seems that this has already been discussed in a different post. My apologies...