UR and mind map software

[schferk]

On ResultsManager and integration in general

In some post above, I think I said that RM was "ugly". That's not really true. The really ugly screenshots are right on their introductory page for RM, but squeeze too many different things / several real screenshots into just some "screen" there, and that doesn't seem to be a realistic representation of the thing (see below where in 70 minutes I did not see ANY such cramped & divided screen), so they harm their own marketing interests by seemingly "false representation". (EDIT : In fact I had been mislead by too a tiny and not enlargeable screenshot of theirs, that showed a screen cluttered with FIVE minuscule windows each representing another part of what RM is able of.)

Another thing is that RM makes ample use of the MM subbranch borders which I don't find pretty and which always remind my of ugly address tags for your luggage.

I have visioned a 70 min. "webinar" on RM here

http://www.gyronix.com/webinars/box/gtdsg0210/

and can now say that RM is far from being as "technical" as I had thought (= pulling up number and such), but does "real" PM within MM, but in a very "macro" way, i.e. the developer himself recommends doing the "global update" just two times a day, in the morning and then after lunch, because then, a bunch of macros start, needing their time to complete, and doing a lot of "gathering anew, again and again" and "re-creating all your consolidation stuff from scratch every time" (= I suppose this, no diffamation intended if I'm totally wrong here), so if I'm right (and I seem to be, from the above), MM (and with its lack of native clones, hence the necessity to build up "virtual clones" by just copying and building up the same things, again and again and again, while you wait for this crazy "external macros doing their duty" to come to an end) is, technically-wise, certainly not the PM tool of your choice if doing heavy PM work.

On the other hand, that MM-and-RM combi is able (with the above limitations) to deploy PM even to little groups, let'ts say 5 or 8 people, in a more or less interactive way, with personnalized views for the different group members (but as for real-time updating of consolidations of gathered data, I maintain my doubts, for the time being). So, let's remember UR's network capabilities here, and envision, as I said before, possible MM-UR integration, even for groups / little networks!

As said before, the whole RM tool seems to be a triggered-macro system, but an incredibly sophisticated one, and as such it seems to be no "real native sw" if I dare say, but an enormous (and very complicated and very smart) work-around - but then, you'd wish, at any moment, that all this elaborate functionality it provides, should be natively come from somewhere, meaning the real-time updating of every little bit that should be updated, instead of the seemingly building-up from scratch of the needed dashboards and such, two times a day, and not really knowing the state of your system when it comes to the details, in-between, and it's evident that these probs get worse with every collaborator who's joining the network.

AND, of course, RM is for MM-PM integration only, and there does not seem to be any connectivity to further needs, e.g. having the 100,000 or so data items within your UR db - also made available to anyone in the network, by UR's means, but then, how to administered within that MM PM system? Meaning, there would be a lot of further scripting be needed to be done, by the GyroQ functionality and on top of what RM delivers, with lots of possible problems from the interaction of such threads being triggered from several such external tools, all the more so within a network.

On the other hand, much of the RM functionality could be "mirrored" / replicated by GyroQ scripts, i.e. if there are things that RM does, and you would like your integrated system to do these, GyroQ scripts or a set of such scripts could do this (cf. the incredible MindReader tool constructed from such scripts, and also available for free at the above-mentioned activityowner site - I had just inadvertently left out the mention of their MR above; and another detail: that "how to get out a max of Gyronix products" site is maintained by sombody else, not by Gyronix, well, that's it's an absolutely outstanding resource, I said that before!).

I would have liked to tell you here, even RM is well worth it, but besides from the considerations above, there's another factor that makes me neither wanting to promote it, nor do I have the intention to buy it, at this time. Gyronix has made a formidable effort there, and for what it does, RM (not to be mixed-up with MR) should normally be "worth" the price. BUT: In the cited webinar, the developer 2 or 3 times (i.e. at least at about 48'45" and 55'00") shows and comments functionality in HIS version of RM, which are NOT included in the version he sells!

In fact, he mentions that these are available only to his customers who pay for his consulting services, and on their site, I must read that the consulting services (of the developer himself at least, don't know if there are also less expensive ones) are 700 bucks for 2 hours, see for yourself:

https://gyronix.infusionsoft.com/app...l?productId=59

What would you see if kinook told us that yes, there IS the intermediate consolidation level (that I've been asking for in this forum) in a special version of UR, as is trans-UR-db search and other goodies, but that's special version available only to kinook's consulting biz customers? Well, we all would have left the product, I suppose, and this forum would be dead, right? (For clarification: There is a standard, and a prof. RM, but the developer in the webinar mentions the price, 285 bucks, so this is NOT a misunderstanding on my side, the prof. RM having these features when only the standard version does not: No, he clearly states these feature are for those high-value customers only, and you bet I'd be very unhappy with that if I ever layed out 285 bucks plus vat for the crippled "prof." version.)

So, I think I'll do lots of GyroQ scripting instead, but interactively MM-MM, for - light (and, at this time, 1-person) - "PM", and for MM-UR and such (while having a close eye on the functional point of intersection, i.e. the "distribution" of "what should be done in MM, and what better be done within the UR / bulk info material part of the overall system?". The webinar doesn't address the question of where and how to stock the "material" and how to address it from that RM system, but then, we wouldn't be here in the UR forum if that wasn't the core question in our workflow.

Anyway, there's another aspect to this: Their product "DecisionMill" (297 bucks plus vat) should have been integrated into RM, instead of being sold separately, or, more precisely:

I strongly advocate integration of PM into decision making and vice versa, meaning both should be an integrated, iterative process.

E.g., you often must dive into a lot of detail, i.e. into a lot of "PM" style planning, in order to assez the financial (= inherent costs) and / or technical feasibility of parts of your projects, and so, your decision making depends on the realization = "PM" part, and vice versa: within the PM, there will be lots of alternatives, viable or not, and it's advisable to trigger decision-making techniques re the more important of them at least, since it could save lots of ressources (manpower, money, etc.).

In fact, the absence of both integrated decision-making features and "stuff storage" (or sophisticated linking functionality for the latter) in traditional PM tools is a predominant reason many people do PM in outliners and such, instead of trying to organize themselves within the (more specific, but otherwise twofold insufficiant) functionality of PM or PM-related sw.

[schferk]

armsys asks me in another thread : "Have you actually ever exercised due diligence in experimenting with products before publishing your magnificent manifestos here? For example, for RM, have you actually tested your RM dashboard(s) with topics/tasks embedded in 30 or more respective mission-critical mindmaps?"

I did not even install the trial, and I never pretended to have done so, but I'm VERY interested in replicating that part of its functionality that'd be sensible to have available in order to overcome the problem that no MM prog has got multi-map clones - as has no outlining prog either, btw.

And from what I see, it's perfectly possible to have such rather simple macros, for rather simple functionality, i.e. you might have 50 maps, where many items are "ToDo's", of different kinds. So what to do, in this simple scenario? You work on your topic maps, but you mark items that should be "shuffled up" into the different dashboards - 1 dashboard for 1 kind of "ToDo's", to begin with; also, combinations could be processed, later, with just a little bit additional scripting.

You "mark" them, I say. Well, this has to be done, and undone, fast. MM provides, among many more (but not so simply accessible) ways of marking, two ranges of symbol markers, "priority" 1 to 9, by shift-control-1...9 (the '^0 deleting a marker 1-8 that's there) - but you could use 1,2,3 for priority, and 4 to 9 for any other classification, e.g. Then, there are many more symbol markers that ain't prefigured, but that you assign yourself to ^1...^9 (the ^0 deleting, again) before using them - that gives you 18 such markers for a start, and if that's not enough, you then would add text markers, background colors, or other.

Sideline: As I said before, it's all about macro-driven, external "up-shuffling", i.e. copying these items into your dashboards that will be re-built again and again; in the web, people say that they wait for 45 min. for this being done - which means to me, it's all nothing but a technically primitive (even when highly-complicated, from the programmer's pov) work-around, so I doubt that such a system is really ready to fulfill the task armsys would like it to fulfill; I think real PM should not rely on outdated data the updating of which demands 45 min., with the system closed down for any use during this wait while rebuilding "everything further up" from scratch.

But I seriously think that before we get real clones - updated in real-time -, for less demanding, not too complicated 1-person uses, a macro system integrating multiple MM maps into dashboards could be viable, by lack of a better solution here; as explained, the use of an external applic building up, trans-maps, lists of such marked items, thus aggregating them into a list, by search, is an alternative - and also not real-time - solution, which does not deliver dashboards, but forces you to do the same searches for these (ToDo- and other) markers, again and again - that's why my preference goes to a very simplified and self-written RM system.

Side-line: Whilst for MM, you need an external add-in in order to build up a tree comprising the respective trees of several / multiple maps, it's VM that has got such a trans-map tree view (visible all the time, by option) in-built - but it does NOT seem to me that it will give you item selections there, by markers (will have to check this since that would make it a ready-for-use system, without dashboards, but with a little scripting...

Back to MM: What I've in mind, then, is simply shuffling up of marked items, by macro, into the respective dashboard, and THE MOMENT I MARK THEM. I.e. I wouldn't do '^4, e.g., for a given item within any of my working maps, but would trigger a macro that would do the '^4, but also copy the item into the "dashboard 4" map - this is perfectly possible under condition that you always load all the dashboard maps, so that they are available in memory, for receiving such operations.

On the other hand, whenever I delete a marker (!) of an item in any map, a macro would delete the copy (!) of that item from the respective dashboard map. And, whenever I delete an item (!) from any of the dashboards, a macro would delete the respective marker (!) of the original of that item in the respective map

- well, it's possible that such two-way processing is too complicated or cannot be realized, from lack of a command which would be necessary for this macro to work, within the macro language that GyroQ makes available. Then, I would indeed be in the same situation as the RM users are who need to let build RM up the dashboards, from scratch, once or twice a day: of course, a script to build these dashboards up in a row

(and not bit by bit, in real time, whenever you change a marker or a marked item

(in fact, another macro would be to change the text of the item in the dashboard, when you change the text of a marked item in a work-map; the other way round, again, there might be probs),

by checking every item, for markers, in a non-dashboard map, and then processing it accordingly, doesn't present any technical problem, but of course is awkward by the waiting time it imposes upon the user.

Sideline: Updating dashboard items from changes in "originals" is easy, since the marker of the "original" would identify the respective dashboard map (abstraction being done here from any possible combis, of course, but that could be processed sequentially, one marker a time); the other way round, there could be a prob since there isn't any marker to identify the "original" 's map (= where to look for the item to be updated "downwards", and so, it would be possible that downward-updating is impossible or asks for too much processing power (i.e. e.g. by searching all maps for that item, by content).

You see here that from a technical pov, it's really pc-stone-age processing of data, so let's hope there will be trans-map clones some day: If you have to do such amounts of external scripting for simple commands (remember, if there were clones, any of these items anywhere could be identified / addressed by unique identifier numbers, to begin with), there simply isn't enough internal code that has been done, and that's not good. What I mean is, from a technical pov, there's a tremendous difference between internal functionality and heavy external scripting: 45 min. wait time for updating your data, e.g.

[schferk]

I

In another thread, armsys states, "Apparently you missed the answer to your oft-mentioned RM vs. UR."
Well, I don't think so, and it's not RM vs. UR, it's MM _A_N_D_ UR, but then, MM plus some scripting, be it provided by RM or by macros or your own, and it's about holding it as simple as possible since this external scripting on MM quickly gets outrageously un-handy for the "end user", by blowing-up all those coffee brakes he's forced to get whenever he wants his data updated.

(Sideline: from github.com: "VimOutliner is an outline processor with many of the same features as Grandview, More, Thinktank, Ecco, etc. Features include tree expand/collapse, tree promotion/demotion, level sensitive colors, INTEROUTLINE LINKING, and body text." (my markup) - UR does it, too, as we know - but what about simplifying the process necessary to do such a link? And what about updating such links when necessary?)

So, from a workflow pov, it's evident that anybody should do a max within a good PIM like UR, and a minimum only within additional sw that lacks even basic features, and where this absence then makes necessary (outstanding but bloated, hence the coffee brake) external scripting.

On the other hand, my new ideas for any given prob / area of a given project (and having their own MM map) have tripled, from what I got when I exclusively relied upon my outliner-only setting some months ago: As said before, it seems to be the compactness of items in lists / trees in list form that in outliners PREVENTS, more or less, new ideas coming to you for such a given subtree,

whereas to the same set of existing items, also technically in tree form (only), but spread in all directions, the "de-compacting" effect of non-bloated mm maps works often wonders.

EDIT: If you permit this allegory: It seems that the compactness of items within grouped lists (lists in textform, in outlines) blocks possible new ideas / elements / your associative thinking that makes you find new elements that'd belong here though, whilst the free space - IF there is enough free, white space that is! - within an mm map virtually attracts these new elements virtually FALLING IN PLACE THERE, just like a magnet would attract bits of iron. In order for this happening, you must see the map, hence my 2-screen set-up: Before me, the IMS, and to the left, any MM map to which I need further ideas or new elements helping to resolve the central problem. Btw, the same thing does NOT function, for me, with print-outs: the map must be backlit and seemingly await your entering data - in direct comparison, a print-out, probably because not appearing "a thing in the making" anymore, seems more or less "dead" and "unwilling" to receive new ideas, just as lists (even on screen) do. So there is certainly a big effect "white, backlit space eager to be filled-up in real-time", that cannot be replicated by a print-out, independantly of the frequence of your entering added handwritten data into the original file and print this out anew.

(EDIT STILL) Sideline: The set-up above isn't invariable: Whenever I grasp lots of clippings from the web, into my IMS, that's switched to the left, and in front of me appears my browser. But that browser, normally, toggles with the MM maps in the screen to my left, i.e. I'm working on something in my IMS, in front of my, and the browser is secondary, for looking up things, here and there (just as my other secondary tools are: file manager, calculator, dictionary) - so, secondary screen: default use, any MM map, or other uses whenever I need a screen for any applic; primal screen: IMS, or, whenever I work some time in my browser, browser and IMS are switched. But to tell you the truth, since my two screens get the browser, the IMS and the "current" MM map to hold, and I make frequent use of these secondary tools above and more... next time, I'll see that I get a mini pc (instead of my numerous notebooks), with a THREE-screen graphics card - there's always space on my right, waiting for the third screen ! (I trigger and switch all these with additional keys; if I had to do it by Alt-F4, oh my!)

Btw, such clones would not only be needed in order to replace the currently necessary (RM-style-of) "shuffling items up into the dashboards", but also in order to have cloned items in several of your "second-level maps", i.e. your working maps, one aspect of your projects playing a role in several (just otherwise more or less self-contained) contexts - for me, this seems to be the most urgent thing to implement in mm sw (and I explained above that intermap item cloning is certainly not a technical problem.

Sideline: People in mm-related fori sometimes complain about their NOT finding solutions to problems, etc., within their mm maps, and whenever they describe their maps a little bit, it becomes evident that they have NOT segregated the "difficult parts" there into new and additional "work maps" (the provisional-only term of "work map" indicating the opposition to any kind of "aggregation map" in my terminology), whilst that is the clue in mm:

You cannot expect an mm producing better-than-outlining results when you leave it cluttered and leave it a mess: One matter, one map, in order for mm to become really benefiary! "One matter" consisting of a bunch of little things / details belonging together, of course, and they even SHOULD be kept together, in a group of not more than 30, 40 items (which works for me, perhaps even 60-items maps will work for you, but then, you'd be well advised to also try not-so-crowded maps and see if those will even work better for you then). But as soon as a sub-branch in your little map will become too big, OR PROBLEMATIC !!!, make it an additional, for heaven's sake! If you don't, mm will NOT help you to get better results from your work, than you'd get from an outline.

[schferk]

II

And armsys says there, ""Order" appears 6 times in your above manifesto. IMHO, on the contrary, UR never promotes order per se. UR is an unstructured database, save some basic attributes."
Wrong again. In fact, outliners have been invented to overcome the unstructured db paradigm (= technical realization of piles of paper), promoted e.g. by askSam (but which introduced virtual trees built up on-the-fly, from 6.0 or 6.1 on, and if development had been continued from there, AS would be THE ONE THING today, besides which everything else would pale), and where there is some sort of "order", by the sequence of the sheets of paper = records in the db, but where it's virtually impossible to get some benefit of this order (but where it's extremely hard work to even maintain that order to get even that minute advantage from it, hence "searching" instead of even bothering with the records' / sheets' order.

Outlining, on the other hand - and I've said all this in another forum or even here -, is the electronic way of a) making lists of your sheets, to help you to order them, of b) providing separator sheets (with lists of which sheets lay under the respective separator sheet, and, thanks to the comp power, these lists don't have to be maintained by hand!) in order to make big groups, in order to make these groups manageable, i.e. it cuts up your list of 10,000 items into 100 lists of 100 items, and c) of multiplying this separator sheets into such of several levels - all this has been done, for centuries, with sheets of paper and separator sheets of several color (or paper vs. cardboard, broad paper slips vs. more narrow ones, etc.), or with paper tabs / slips (positioned in more-or-less index-positions, with notes further indexing, etc. - the paper indexes in those lever files some of us always use, are nothing more than a further development of paper slips of all sorts in order to make 10,000 sheets of paper "manageable" even in those pre-comp and pre-lever-files worlds; don't forget, also, cabinet cupboards, with different compartments there being the first level of sorting, and then the paper slips, i.e. the separator sheets, etc. - all these were in use for centuries, and then only came index cards and indexed lever files (where the splitting up into different lever files and the positioning of these onto different shelves are also higher-level groupings / ordering.

Today, with the pc, all this handling and updating has been extremely simplified, also with the pc-generated possibility of duplicating (ok, Xerox was first, but before photocopying, there was hand-written or no copying (if you permit that I leave out the intermediate carbon paper stage) but only SOME of these progs offer cloning, the next step in doc M since it's automatted updating of the copied items.

Now, to advocate that "UR never promotes order per se" is ridiculous, since if you were right, UR today would appear just like AS 1990, when in fact, the CORE idea behind sw of this kind is to put a GROUPING interface upon a flat db (or upon a monster text file), in order to make things accessible NOT only by search (= the db paradigm), but BY CONTEXT (= by ONE of perhaps several possible contexts, i.e., to begin with, and then only come possibly cloning, attributes / tags, or tree-building on-the-fly as in current AS).

So there is a "db" paradigm, and many different db's all compete with their respective sophisticating of search-based functionality; whereas very specialized db's like AS (from 6 on) or UR (from start on) introduce a whole new paradigm: their db's are the data repository only, whereas

IT'S ALL IN THE TREE

and its respective sophistication (seen this way, even AS today is a hybrid, but UR belongs clearly to the it's-all-in-the-tree kind).

Sideline: There has been a discussion spreading from a famous article "outlines might be harmful" or something like that (and pretending that outline use promotes bad, hierarchical thinking, whereas the real thing, the democratic thing, would be wikis (hahaha, written probably by one of those CT advocates that plaster all possible places these last months)). That's rubbish since it supposes the dumbest possible use of outlines, where the user didn't grasp the idea that outlining is far less for subordination and far more for grouping, and then, for grouping of the groupings. Ok, this appears to be "hierarchical" organisation, but it's all about

holding siblings and nephews together,

and disposing of a technical quick-access overlay that holds it all together - why would I always promote, "hold it all as flat as it gets! And when in doubt, use separator lines, instead of another level down there"?

[schferk]

III

So, UR isn't a "db", UR is a very sophisticated IMS, using a db as its data repository. But as said in I, there is a prob: For thinking, for deciding, for organizing, i.e. in the sense of finding solutions to little and big probs, ANY outline-only sw is substandard vàv mm sw, and on the other hand, mm software doesn't even handle inter-file clones, let alone that no existing mm sw seems to be able to work as a viable front-end to a big-data repository (sideline : In the web, you can find testimonials from TB users who say, even monster maps with TB work rather ok, but whenever you try to make extensive use of TB's (substandard anyhow) note fields, see what your db quickly becomes...).

So we have two situations here which gets us the third (and the fourth) one:

- Even if they get better and better (which is not the case at this moment), UR-like IMS's will never provide a real thinking-enhancement, except by integration of an mm component for displaying real subbranches of your tree, or even virtual subbranches of your tree, i.e. any clone (with his children, etc.) within an mm-displayed subtree must be treated, in the mm display, as if all these items were there, at their native position. Also, it must be possible to WORK upon that graphical representation, and any changes you'll make there, should be re-updated down to the tree device - I suppose that this is high-brow programming, but technically, there is no impossibility -

except for the fact that the mm component that allows for complete both-ways synching, will probably have to constructed first; I very much doubt there might be such a component out there at this time: Just compare MM and VM: In MM, there are shortcuts for "move up/down" (= within the siblings, and I use these commands about 60 times an hour!), and many more, whilst in VM, for moving an item, I'll have to use the mouse (and not speaking of the constant crashes here) - so, it's hardly believable that there might be any really sophisticated mm component anywhere, and if it only allows for the most basic functionality, and without reasonable hope to get ever much more than that, it would impair your inspiration, instead of making it proliferate.

- On the other hand, today, even with add-ons, MM is only so-so, whilst its competitors even don't get such add-ons, and even with interfile clones introduced someday somewhere, there is no real hope that any of these mm progs will ever provide stable "material" M for big-data.

- Hence my original idea, one year ago, to trigger interaction between an elaborate outline-style IMS, and a not-too-primitive (and possibly actively-developed, which is not really the case with VM, but of MM and perhaps others) mm sw, where both developers would make available as much of their respective functionality, to the other, whenever possible and sensible interaction is concerned.

- And since the petty jealousies of both IMS and mm developers seem to prevent such collaboration (in spite of the fact that it would be enormously beneficial for both developers, since it would, for the first, overcome the limitations of IMS's AND of mm sw - not speaking of the benefits for the user), my current musings how much interaction could be implemented into an interactive mm-IMS workflow by macro / scripting, and for a beginning, I muse about the possibilities within MM, whilst bearing in mind that in the end, perhaps some of the interaction MM basic-maps with MM aggregating-maps could / should be transferred to the interaction MM with IMS/UR.

But then, you absolutely NEED those basic, "work" maps in an mm sw, but you perhaps don't absolutely need those aggregation maps within the mm part of your workflow: Why not have your material within UR, then the possibility to export to a map - but then, with currently available means, the re-import into UR will be impossible! -, and then, the aggregation back in UR (on a higher level there)?

As said, this latter realization isn't possible with current UR, with current MM, hence my musing about doing (perhaps MUCH) more things within MM than I had initially planned... But then, deep links to the respective UR subtrees at least.

So:

If you want to generate better, more, even very easy-coming, ideas, you use any mm sw (but as stated above, amply shortkey-endowed sw makes much quicker and much more intuitive working than sw that forces you to over-use your mouse), and since manual synching with your data repository would be too error-prone, even if you can afford to employ an additional secretary for that, you must devise some interoperability between the two.

It could never be slick, with just external macros, but it could make better available, in some way, your data repository to your thinking and planning, as if you had two separate systems running apart.

So you see, it's all about the original topic, not about UR VERSUS mm (or UR vs. MM with RM). In my case, 100,000 items providing "content" would make this impossible to begin with. My theme is the optimized interaction of DATA with thinking, and unfortunately, there is nothing out there that even tries the very first steps of such interaction (except, indeed for that CT I abhor) - the reality is, it's even the opposite, and for which the non-integration of DecisionMill and RM, in order to sell them as two separate products, isn't but one of countless examples.

In a perfect world, it'd be kinook that mused about such things, and then telephoned to some mm sw developers. As for me, I cannot buy any such mm sw (I mean the rights, not a licence), just in order to then integrate an IMS into it, but that would be indeed what any mm sw developer should do in order to catch up with MM: Why not imagine an mm sw developer buying the IMS competence, instead of the other way round?

Anyway, I have to do with what is available for me, today, hence my musing about possible macros within MM at least, and then deep links to UR items or a competitor (no way with AO here, but then, a UR that isn't actively developed, hasn't got that much of attraction for me JUST for its deep links...).

One last word: I'm always speaking about 2-screen scenarii here; switching back and forth between UR and MM on the same screen isn't the thing to do - btw, that's the reason why all these pretty tries to introduce mm maps as navigational devices in web pages have been aborted: Either you got space for the navigation, or for the content, but not both. But we're power users here, hence my advice, buy a second screen (used, 30 bucks), and you'll never ever will do without such a set-up except on the road.

[schferk]

Just a short intermediate "result" (in conception, not in macroing):

We have seen from the above that MM does not present much inherent dashboard functionality or such, no clones, no 2-way links either ! Meaning if you outlink to another map, there isn't a link back or such info, "this map has been linked by...(follows list or something)".

We've also seen that external programming / scripting in order to "overcome" these missing functions, do NOT overcome them in real-time, but by "automatted but basically manual" macro processing building up the same things again and again. Worse, MM's competitors don't even have such add-ons to offer such work-arounds at least, but you strictly do without such functionality. (This last "info" is perhaps partly mistaken, there might be mm progs with better functionality, and I would be eager to hear from them.)

On the other hand, we've got some rare PIM's/IMS's that have much better functionality here, especially UR, or even, when you use some very primitive PIM, like AO, you always get the possibility to do your necessary back-and-forth within that.

Sideline: If your IMS doesn't offer links within the tree - which are absolutely necessary for any serious IM -, just do like I've explained here, use codes like .Filename, and have a (preferably AHK, for its strength and easy use) macro that "understands" ".Filename" is a link when you just press Enter with that tree entry being selected (with control-enter and such being alternative ways of opening such files if necessary or handy). (Sideline: Such "home-made links" are perfect if you even want to leave your current applic: contrary to most "native" links, they travel...!)

So, why considering mm maps as possible "Super level", when in fact, MM and other mm sw's don't offer the inherent native functionality that would make such use smooth and slick? Why not do this "very-first-level" M in your IMS, especially if it offers very smart (and even workgroup) functionality here that by "going mm" you'd be deliberately forego?

Which means that, as I said before for any other link, you should have IMS "dashboards", as my around 10 "a, c, d, i, m..." AO files, or as would be your about 10 UR tabs, each blocked to such an "intermediate", very high in the "hierarchy" positioned "a, c, d, i, m..." UR sub-branches. In fact, you should perhaps have a UR file, then just about 10 such "dashboard" entries in the first level, with anything else of your stuff "under" these headings - this also means, UR needs another pane, in the left top corner of the screen, with just some 20 entries at most (considering you would perhaps have other first-level entries, without them being the top entries for the respective bulk of material underneath), and beneath that first-level pane, you'd have your respective tree, so those a, c, d... or for whatever you might expand within their repective material bulks.

Within these a, c, d... UR dashboards, you'd have listed your respective mm maps, as file links, as for any other file link. You'd work within these level-1 UR parts, and you'd work within your respective mm maps in order to generate better ideas than you'd be able to do with all-UR means only, in the same way you'll certainly have a number of Excel, etc. files listed (and accessible from) there.

So there's certainly room for creating better interactivity between multiple (and in parts, overlapping) mm maps, AND links to UR items (in my current case, just to different AO files, no deep links here) there could be very helpful, in order to bring you further "material" (as said above) at your fingertips when doing "map-thinking", "material" in contrast to "considerations" and "details to consider" that all should be placed within your fine-grained mm maps.

And there is the problem how such mm maps, with all their "actionable" details that then should be "linked" in some way to the correspondent parts within your IMS, should actually be linked.

As said, the technical aspect is without problems, most mm applics offering outlinks, and UR offering to receive deep links (another IMS offering these is IM (also db-based, that's perhaps the technical clue in here, and why ordinary PIM's do NOT offer this function)).

But the prob is on the conceptual level: As said above: If you begin to plaster your "thinking maps" with links, the thinking-enhancing effect of such maps will go down to zero.

The real problem here is with "ToDo" processing: Many items in your mm maps remain "consideration items", but many others become ToDo's of all sorts (see above why I do NOT advocate that considerations / decision-making, and ToDo's should be separated into different maps), and if you do decision-making within your maps (what's highly advisable, for their thinking-enhancing), your ToDo's will be in those maps, whilst on the other hand, all the organization is within your IMS' traditional, it's "outlining" / PIM part (here: UR).

It will be fascinating to detect the sensible interoperational functionality here, interoperability NOT meaning "what macros are needed", to begin with, but it's all about, "how to DO this switching between mm and IMS (if all the necessary technical foundations / macros were there already)", from a smooth-and-minimized-effort workflow ideal pov.

At this time, and just for some provisional ideas: I'm musing about MM markers where one macro would set the marker and switch to UR where it would create a new item, together with a backlink (to the map at least; to the MM wouldn't be possible - but then, in UR, why not have a macro that follows the link to the map, AND would then search, within that map, the according item, in order to select it?), or about another macro that would, if there is a marker within MM, go to UR and open the respective sub-tree (be it for material or for ToDo contexts), and even for collaboration: Why not have a macro in MM (!) that triggers the respective delegation or inquiry within a UR workgroup?

And why not the same, triggering even, within the other person's part of UR, a macro that triggers creation of a new ToDo item within his respective MM map? All this is technically possible, and would share two characteristics: It would NOT be about establishing a new, parallel MM macro net, UR here, MM there, but MM would interact with that same person's UR, and the latter would then, whenever sensible, interact within the UR workgroup, in case even going so far as to trigger MM commands within the MM system of that collegue, and all core functionality would be realized by accessing UR's powerful features when in doubt, whilst the MM system would become (and remain) a "think machine", from which the necessary actions might be triggered, and prhaps, in parts, sort of a message board (bear in mind, thoughts there become ToDo's, so it'd be advisable that new ToDo's find their room within these graphics, and not end up within the UR tree, making your ToDo's splattered between MM maps and UR.

So there is some conceptional thinking to be done, with a little help from extensive trial and error.

But it wouldn't be but after such thorough experimentation that you could dare set up the specifications a possible (one-day integrated) UR mm component (or any other integrational feature set, in a possible collaboration UR - existing mm sw) should met.

So in the end, it's multiple MM "working maps" in order to find ideas, and two parallel dashboard systems, the UR dashboards, and the corresponding MM dashboards, and even those "working maps" have ToDo's, so there's chaos in perspective. (You see now why so many people out there try to make MM their unique M system - even if it's not suited to such a task, people live with the accompanying shortcomings in order to avoid hybrid systems.

Hence the very high interest to have an integrated mm module in UR indeed, since any such macros working hence and forth would otherwise mean, not smooth internal processing of an integrated system, but external macros emulating loads of manual manipulations - error-prone, time-consuming...

Whilst internal such functionality would mean, anything is just processed and synched in real time - could become something really smart.

With macroed manipulations as a means of prototyping only.

[schferk]

And yes, I'm aware that the previous post is inconsistent, dashboards with MM, and then in UR, and then in MM again: I'm in the groping stage.


Another thing: You can do legal case building / analyses (or whatever you might call it, I mean checking the facts, the legal dispositions, and to "synch" both, in a way that you come to the resolution of the case) with any outliner (or with b-liner), but I've never been happy with this, because the outlines went too deep (or when I tried to hold them flat, siblings instead of children got in my navigational way).

Today, I made a try within MM, with - as I had advocated above - the (tiny) details not hidden anymore, as with my legal outlines, but clearly visible within the map(s) - yes, for an a little elaborate case, you'll have to split up the main mm map possibly several times. My first reaction: It's a relief! My second discovery: It's much faster than in outlining, possible because of that visibility of the details, instead of just working with headline as in an outliner. (And, of course, MM's ability to shuffle around items / sub-branches with the keyboard, is enormously helpful in this.)

Sideline: I now understand better why the 1-pane outliner NoteMap (development halted, some bugs, might make you lose data as some people say) is marketed within a legal context, even if I abhor 1-pane outliners: The details (= not the sources, but the "executive summary of the sources) must be visible (and in a 1-pane outliner, they are).

I also have no probs with my "hold it flat" doctrine in an mm map, as I had in too flat an outline.

It's fast, smooth legal working within an mm, so even will "dry stuff", your thinking is greatly enhanced (of course, there are ToDo and strategy branches, and such, besides the ones for dissection your §§, and even in these...)

Very encouraging, will certainly do lots of such work within MM!

So, even with stricly logical stuff, the "left-brained" stuff according to Buzan, mm's work tremendously well, again for their graphical ease:

- It's all there (and not hidden behind just headlines)

- and (and this is not given within an outline, even in the 1-pane variety), it's clearly separated (= big prob in outlines, but divider lines then are of big help, except that then, the outline goes even more unbearably long! Or do you turn your 27" screen into portrait mode?!!!),

- AND it's all sufficiently de-compacted so as to allow for pleasant working (= the opposite ruling outlines, causing their one real prob).


And a last point: I overlooked "direct" collaboration, within my tentative development above: In a little network, it should be possible for anyone / certain people to have at their screen the mm maps (as every other files) of a colleague, their collaborators, or of whomever (i.e. with or without access M), these files being stored on a "server" or in a common folder or such. And then, it should be possible to access these "other" mm maps, in real time, and perhaps even when their "owner" (or any other user in the network) works on them, too. And I think as soon as you include such "map-sharing" within your frame of possible concepts, you'll probably get better solutions for "Individual and Collaborative ToDo M", as if by updating processes, be them by real-time-triggered macros or by "basket macros", triggered here and only to work by batch-processing. Here again, macros would serve for prototyping purposes mainly.