Additional problems:
I
One of the big advantages in my experience of "mind-map" sw
- IN THE FUTURE, I'LL DO "mm" for "mind-map" (rights to "mind-map": Tony Buzan) and "MM" for "Mind Manager" (commercial product by Mindjet) -
is the consistent graphical representation of the material, i.e. you add branches, you manually move branches, but apart from that, every time you re-open a map, the branches will be at the same location they were when you last had worked / mused upon your map.
TheBrain does NOT seem to have such a consistent graphical representation of branches and their sub-branches, or at least, there is much fiddling with several "views" in order to at least have ALL sub-branches of a given branch / node displayed together, to begin with, and about re-arranging branches as in MM, well, I never got to it, and it seems impossible (must say that my last thorough trials with TB were with the last major version).
II
See I, and additional prob: I can NOT work with (meaning: all the advantages of mm's I have liste do NOT work for me if I accept) the "original" distribution of branches, in mm's, clockwise, i.e. those progs do the branches 1 h, 3 h, 6 h (here, most progs fill up the right side first, then go "after" 6 h - I'm not speaking of the order, which is always preserved by your doing the sibling for a given item, but the graphical distribution on the screen, order preserved, I'm speaking here), 9 h, with additional sibling branches being put between.
So, I in my MM, I manually rearrange my nodes by the system 11 h, 9 h, 7 h, 1 h, then 3 h, 5 h, meaning I go down on the left side, then I go down on the right side, just as if I would fill up two pages, left, right, one after the other, by writing.
Now, I didn't search yet for a mm prog where I could do this by option, automatically, but that's not the real prob here, because of the consistency of the graphical representation in MM and in most / all mm's.
But as soon as you get to automatic transfer / "traduction" of your data between IMS and mm, or if you get to a mm component within your IMS, this "how the data is automatically distributed on the screen (and on paper)" prob will enter the scene and probably make useless any such automatic "dual data representation" worthless for more than one, either because it does it "the usual way" - I'd be out, then, or because it does it my way, which could mean many traditional user of mm's will find it unusable, them having always left the graphical representation of their data within their mm on default = clockwise.
Hence, the necessity to do some "research" first in order to know HOW mm users do it - it could be that many of them would like to do it as I do, once they will have started to manually re-arrange their branches, but without having done so up to know, and perhaps my assumption is wishful thinking only.
So, this uncertainty is another big obstacle to any such implementation (be it interconnection, be it implementing an internal component).
III
Clones. The more I work with mm's (in MM 8.2, as said), the more I miss clones, i.e. items / branches being on several maps simultaneously, and updated from anywhere - of course, we have got here the same problem as with UR and every other IMS: The updating must affect even clones being situated in NON-OPEN maps or databases, which means that in every (?) current IMS, there isn't but cloning of items / sub-trees within the CURRENT db, at best.
Sideline: Why do I need clones in my maps, when otherwise defending use of clones, within the IMS, just for special branches / db's there, i.e. prospects by area, by potential, etc., or (for an author) the personnel of his drama, by themes and by scenes, and such uses?
Because I started to get get out all my things related to planning, to todoing, to deciding, etc., from the depths of my IMS and into the mm map system, and of course, within THIS frame of thinking, clones are an absolute necessity.
In other words, the traditional problem "car assurance in car or in assurance" isn't a real problem, since a simple link will do here, from the side the car ass. is not, to the side where you put the car ass., so there would probably be car, with a link to ass., and ass, incl. car ass. - the same applies to any such "reference data" prob, and even less so, not even links would be necessary, most of the time, just item "car", then first child "assurance SEE assurance" (as link or not) (and other such), then a divider line, and elsewhere the item "assurance", then first child "incl. car assurance", then a divider line, and the "car assurance" further down anywhere within this block of perhaps dozens of children for various assurances.
But as said, within your "planning world", it's totally otherwise: there, multiple cloning is a necessity - but today's mm sw's do NOT offer them, it seems.
A citation from MM:
https://community.mindjet.com/mindje...parents-1bk5vg
"Because the current maps are just hierarchical constructs, it is impossible to represent situations, where a child branch has many parents. Of course we can create additional relations, but this is definitely not the same." = seems to be an official statement from Mindjet.
Then the poster goes on with asking for clones, and he gets a "3 people like this idea", for a post 10 months old and tagged "MM 2012".
Which means that not even MM does have clones, with a 6- or 7-digit number of users (= in many corporations, and because of cheap university licenses) - this is a disaster.
And then, OF COURSE it is perfectly possible to have clones, inter-db-wise, inter-file-wise, as it is possible to have search over multiple db's (UR's missing inter-db-search, anyone?): You just maintain a little db with references, and containing the respective data, and for any opening of such a map, this db is checked for any changes that might have occured within this map = within the cloned branches in this map, in the meanwhile; then, these changes are worked into the map in question, before its being displayed.
The alternative solution would be to update any such map with clones being altered within a current map, by the prog opening the other map in the background, without displaying it, and doing the necessary change immediately, then save the other map again; the information which other maps contain which clones of clones within the current map, would be present in any such map containing clones, anyway.
Sorry for being rather technical, but currently, there seems to be NOT ONE really perfect IMS, so my "work" of imagining such a system must rely, in big parts, upon just imagination even of the intermediate steps to get to such perfect sw - I'd greatly prefer to have existing sw available that came nearer the desirable "end result", instead of constantly even having to imagine the necessary intermediate solutions - that would greatly enhance the precision of what I could say.
Hence my constant begging for realizing at least some intermediate steps to a perfect IMS, for my imagining further enhancements to become more focused.
Anyway, my next step will be to have a further look at mm sw and probably get the one that first will come out with clones, even if these clones are only possible in some "grouped maps" environment where all these maps must be opened together, each time. My MM maps just are about 35 kb each, so there would not be any problem to open even 100 such maps at the same time (but I hope that they could be grouped within a tree structure, since having 100 tabs wouldn't be a realistic solution here).
As smart readers will have understood, my dual way, MM plus IMS, being just another try to have get to that "super level" that is absent from any existing IMS, in order to work within that "super level", and NOT work within my referential data bulk.
This is a problem we ALL have, all the more so my astonishment that so few people see the prob here.
There have been some books, from a German woman, who has been defending strict discrimination of "work files" and "reference files", between your physical lever files and so on, some years ago. The problem, of course, being, that much stuff is reference AND working material at the same time, and additional prob is, this intersection is plastic, and moving all the time. In theory, computer power should / MUST finally bring a viable solution to this permanent problem THAT EATS UP, for everyone, for every corporation, lotsa working time and effort that could both be much better deployed on real tasks bringing "revenue" (be it commercial or scientific)), so it's revolting that there is no solution yet. And worse, that there is no developer out there who's available for doing some good work here, in order to leave the pack and become vanguard for a time, then get BIG revenue.
The first IMS that will really work, would grasp big markets, very big ones. It's a pity.