#2461 Feature: unify connector shape and style with approach used for main map elements
Connectors are one of the more useful features of Freeplane, compared to map frameworks which lack such support. However, currently the feature can be awkward to use, because its design is incongruent with the design for other map elements, those that comprise the node heirarchy.
Wisely, Freeplane allows that nodes can be added or modified without the user being distracted by visual considerations of each node. The user determines node core and details, as well as the location in the heirarchy, and the application determines the physical features such as position and style information. The user normally changes style information for an entire style rather than individual map elements, therby enforcing a uniform appearance across the map and eliminating the need to manually change each tree element.
Currently, an opposite approach is used for connectors. Shape, location, and other style information is determined for each connector manually. If the location of either node changes, then the user must rework any manual changes to the connector shape. The mechanism for changing the shape using control points is currently awkard and cumbersome, often frustrating. Meanwhile, color and line style are changed necessarily for only one connector at a time. In some cases, a user may choose a variety of styles, each to represent a different logical significance of the connector. In such cases, control over individual connectors is useful. More generally, however, changes will be wanted to propagate to multiple connectors already defined, if not all of them.
Following the approach used for basic map elements, the application would automatically determine the shape and position of the connectors, based on the position of the nodes, and allow other style information to be changed at a style level rather than necessarily at the level of individual connectors. This approach advances productivity from the user standpoint by separating the user's concern of providing a logical structure for the map from the application's concern of displaying the structure in a way that is legible, and comformant to overall stylization decisions. Such a separation concerns is a central feature of the mind map paradigm, which allows the user to express logical relations among concepts, without ongoing distraction from formatting considerations.
Generally you are right.
However, I do not know how you use connectors and how many users make use of them.
Could you share more about your use cases and maybe some of your mind maps?
If you can give me specific questions, then I can try to address them.
I am not able to share content information for ongoing projects, unfortunately.
At the moment, I am confused about why "use cases" would be an issue, in light of the previous discussion. The task of the application, as discussed, is to allow the user to expess the logical relation between concepts, and to create a visual presentation that represents these relations. The user is concerned with building a structure to express, for example, that "chocolate cake is a type of dessert", whereas the application is concerned with how to draw a curve that neither occludes or is occluded by other visual elements?
My confusion is that if someone showed a map, for example, of popular dessert types, would it add any clarity to the question of how to improve the application?
I have seen no maps extensively using connectors before. And I woudl like to learn about different use cases to inspire and motivate myself for doing development work. Therefore describing your use cases you can contribute to the project. If you can not share your maps you could probably describe the area and particularly why you need connectors and which relations are modelled using connectors on your maps.
This information is probably not relevant for implementing the feature, it is about just to make me feel better.
Thank you for the clarification. I understand your concerns.
Broadly, I think, the connectors are useful because the constraint that every node has exactly one parent (except root and floating nodes, haivng none), is too restrictive for helping humans express conceptual relationships to the fullest extent. Concepts used by humans, such as those represented by nodes in a map, are related in complex ways. The particular relation between two concepts is itself a concept, much as I am not related to my mother in the same way that I am realated to my tooth brush. I am a concept, my mother is a concept, my toothbrush is a concept, as so too parentage is a concept, owership of personal items is a concept, and dental hygiene is concept.
A related consideration is that when we structure a map, starting by defining a few children of the root, then building the various subtrees from these children, we are imposing a way of relating the concepts to each other that is not intrinsic to the concepts themselves, but rather an artifact of our choice of emphasizing a single aspect of their relationships. Any existing map, even one that in its current form is useful and accurate, is generally possible to imagine having a different structure, containing mostly the same nodes, also being useful and accurate, and expressing mostly the same essential information. Such a change to map is analagous to making minor changes to the order of scenes in a movie. As long as the causal relation between events is preserved, the same story can be told through more than a single unique sequence of scenes. The effect of this observation is that pairs of nodes in a map have useful and relevant relations not fully represented in the primary tree structure of the map.
Concretely, a few use cases that should be meaningful to a general audience, can be imagined:
I will finally note that among the commercial mind map packages is one called TheBrain. This framework generalizes many of the core mind-map features, trying to provide a higher level of flexibility. In recent versions, from what I read, the tree restriction is relaxed, making the map into a directed graph, not necessarily a tree. The application aims to allow the user to discover new ways of understanding the relationships among nodes, by generating a view of the map with an arbitrary node chosen as the root for that view. The application achieves this result, I assume, by searching for descendents of the chosen root node, creating a tree as a subgraph of the original map. Whether this approach is broadly useful is an interesting and open question. Whether such an adapation is in the near future of Freeplane is obviously doubtful. However, the observation that these features are being developed strongly suggests that the tree constraints originally considered essential to the understanding of the mind map, may ultimately limit the full capabilities of the medium from the evolving demands of users. Regardless, the plain observation that nodes can be related in various ways beyond the kind defined for the parent-child relation appears to be increasingly uncontroversial.
Last edit: brainchild 2018-12-28
I am thinking about a more transparent and effective way to indentify the high impact feature requests. Could you please contribute to discussion https://sourceforge.net/p/freeplane/discussion/758437/thread/e42c4d169c/ ?
Hi Dimitry, what about this feature? Do you think to develop it? Eventually if in doubt I give it a +1. Thanks.
KR
SFPC
My description of use, to give you an idea.
I use Freeplane to extract concepts of a text when reading, and mainly to design theoretical work. Like articles, conferences, my thesis (some with several thousand nodes), the structure of a course I am going to give, main themes of a coming meeting, structure of a webpage. Sometimes I use them to resume what somebody is saying. As you see, I use it mainly for concepts, and there are diverse form of relations between ideas, and their format possibilites are agreat help.
I use connectors to:
- Link diverse nodes over the map, and the colour and shape of the connector tells me about the kind of relation (while sistematizing ideas, logical ones, like "A= consequence of B", or in a conference secuencial ones, like "after talking of this, go to that", "remember to mention that we saw this before")
- to connect one concept with several parts of the map. I use a free-floating node and pull it to different nodes, and the colour indicates the main concept.
I attach two cases as example of use (from my phd... they aren't usually that big).
Well, I would certainly like the possibility of including one ore more kinds into a template. Actually, one would be enough (more I would adapt).
Anyway, thanks a lot, really a lot, for your programm. It is part of my daily thinking :)
andres
Last edit: Andres Leon-Geyer 2020-07-08
Revewing Andres's examples, I realize that it is hard to imagine any general approach for such connectors to be rendered cleanly enough that they would provide information about the relationships without intrusion into the legibility.
A possible approach, which might also make implementation much simpler, is to avoid literally drawing a connector between topics as they appear in the tree, but rather to render a connected topic nearby, with some kind of distinctive appearance, such a faded coloration. Thus, we might imagine a topic T2, connected to some topic T1, that looks roughly like a child to T1 in the tree, but that cannot by edited directly, and is shown separate from the actual children. Clicking on the representation of the connected topic T2 would cause the dispaly to jump to the position in the tree of T2, where a similar display of the original topic T1 appears in a similar sort of relationship to T2 as did T2 to T1 in the position in the tree of T1.
(In such form of visualization, managing the connection feels like jumping through a portal, as in fantasy or science-fiction literature. Near to the portal entrancc we only see the nearest feaures of the sde beyond the jump.)
Seeing the connected topics together might reinforce the understanding of connctions as a relationship similar to one of parent and child, but that is completely reciprocal.
I have started working on it