UR and mind map software

[schferk]

Miscellanea

I

In order to make this perfectly clear, I do NOT advocate putting your reference material into any mm sw (you can read such crazy advice in the web); remember they say "if all you have got is a hammer, all your problems appear to be nails" (or something like that); the problem is twofold: mm sw is unsuited for reference material; on the other hand, IMS' are not exactly unsuited for planning, idea finding, etc., but there might be better tools to do that.

II

That Gyronix do NOT allow you downloading any (15 day) trial sw with a disposable mail account but manually check for the validity of your data - the reason why I never trialled that thing. But now, I found a download address that functions direct, without giving them your info first:

http://www.gyronix.com/fulldownloads.php

The "Results Manager" there is expensive and does NOT seem to do what I want (?), it manages multiple pages, but it seems to be sorts of a data-pushing tool for serving a "dashboard" - will perhaps have a look, but it seems more to be a PM thing (and an ugly one for that) - as said above, and as with MM as a depository for stored data, many people out there try to convince you to use MM for just everything, and of course for PM, and the RM seems to be the thing that would help you in doing that (badly).

As for the "DecisionMill 3", well, version 2 seems to have been at 50 bucks, whilst v. 3 is 290 bucks or such... (but since I know now how to download all this stuff, why not trialling?)

Whilst I'm positive of scripting for my IMS, to tell the truth, I don't know at this point how to do the respective macros for MM (should search for the MM "programming" reference or such) - so after all, I'll perhaps run GyroQ in parallel with my similar AHK macros for the IMS. And here's the good new:

At this time, you can buy (standard = "essential") GyroQ for about about 16 bucks (9 English pounds plus vat, to be precise, which is a steal), incl. vat (instead of 29 bucks plus vat), here:

http://www.murge.com/products/mindMa...oq/pricing.asp

The only quirk here is, payment by google (!) is mandatory (so I will have to create a google account just for that, then forget about that account and delete all possible cookies and such).

III

And finally, there also is "Mind Map Navigator", for about 50 bucks (for MM 7 and 8 which don't have a native outline, but for just 9 or 11 bucks for MM 9 and later, which DO have these native outlines), and which does an outline... but from ALL open MM maps - could become convoluted? If I want 1,800 items in a row, I use my IMS, right?

But then, it also searches over all open MM maps, and gives a result table - which makes me wonder if there is a viable possibility to have neat and quick results with this when you do a global search for "tags" within the items (meaning at the end of the "title" or of the "text" which, remember, is technically the same here in MM items), perhaps in the form .ap .xt or #2 #tp or whatever.

Remember here that you need an external search tool like dtsearch if you want to do the same with several db's in UR, e.g., so this way of pseudo-3-dimensionality would perhaps be acceptable, especially in light of the fact that here you could have such functionality with multiple maps, whereas Power Markers (external or now native in MM) will always force you to build up a monster map and then handle that; connected, multiple maps are so much neater, and so I have high hopes in "MMNforMM" before having trialled it at least (and no need for illegal continuous use of defunct trial sw either).

P.S. Looking forward to use GyroQ, will be a joy I'm sure! And will result in even lower fuss in your way of putting down your ideas, meaning that you'll put it there even when, for the fuss of switching to your IMS and back, you would probably not save an idea "too little to justify the effort" - which means, the barrier is lowered, and hence your "flow" is increased... even for the better ideas. What I mean is, the more it is easy to store even minor ideas, i.e. EVERY possible idea, the more likely it will become that even the better ideas will come much more easy.

[schferk]

SORRY for having mislead you (and new insight into TheBrain).

Forget my musings about mm "big-maps", about Power Markers, and about MM 11 being worth its price in view of it having Poma integrated; as I already said, any "real clone" solution that's not going trans-maps is worthless, too.

In fact, I didn't try big-maps, I only imagined them, in order to become Poma (or MM 11's integrated Poma) a workable work-around - forget it.

When you imagine big-maps containing 1, 2, 3 dozen of "virtual maps", don't fall into my misconception to imagine them as big concept maps / cognitive maps, with their perhaps 1, 2, 3 dozen of planitary sub-system: I had those pictures in my mind, also PB/TB, so my mistake to explain to you that your level 1 items could replace my level 0 items - in the mm tools I know, they can NOT.

In fact, in an mm (correct me if I'm wrong), only the one 0 level item then gets radial children, whilst any level from 1 down gets children not in the carpet, but in the rug direction, i.e. you'll get the W/O kind of descendants, left-to right or right-to left, there's NO multiple sun systems.

But we convened, if I dare say, that mm's idea / main advantage is RADIAL representation of factors, points, details (and I said that this works so well, might be so because such graphics trigger similar "physically working maps" in our brain tissue), hence of NOT representing them in a false sequence, as in sequential text or in W/O diagrams ("false" not meaning that for programmational top-down developments (but form them only), W/O would be wrong) -

and then, if it were otherwise, millions of people out there would use b-liner, whilst in fact (or from what Mindjet say), millions of people out there use MM alone (as said, they have numerous advantageous university licenses, making MM free for such students, and that greatly helps in creating the real big numers - but fact is, plenty of corporations use MM alone, whilst b-liner doesn't even has got the necessary money to debug for the bugs you bring to their attention).

This meaning, no way to do a big-map in MM or elsewhere, since your poor sw (Poma, Poma integrated into MM 2012 and 11) will then be able to list those items sharing this attribute, but you won't have virtual mm maps to work in, it's just 20 or so of W/O diagrams, not 20 or so mm maps.

This meaning, very clearly, MJ bought the WRONG add-in: Yes, the prettier one, but not a functional one - any mm map becoming big enough to make "necessary" such (one-map-only) add-ins as Poma, are misconceptions in themselves, to begin with!

In other words, BREAK DOWN mm maps, again and again and again, and THEN they will become most useful for you!

...

[schferk]

(...)

Sideline: PB, now TB, PRESERVES the "multiple suns" with their respective orbital systems (whilst the mm big-map does NOT do that, as we've come to see). I'm very sure now that it's THIS factor which is behind the not-neglectable interest that TB has met with the general public - so I'm all the more so astonished that this usp does not seem to have been communicated before, neither by them, not by their followers (I've read much of their material and much of what has in been said in their forum, but preservation of (more or less) radial representation when looking at virtual sub-maps there has never come by - did I miss the corresponding parts?).

But it occurs to me that the free version of TB doesn't offer some graphic representationional alternatives on the micro level that the pro version offers indeed, which seems to strongly indicate that the developers of TB know exactly where their usp is, even though they don't to seem be eager to communicate it - as for their propaganda, they do their monster maps, again and again, in full, i.e. present you with chaos, when in fact, it's the cutting down (and what you see then) that might be the real - potential - advantage of their product.

In fact, TB is NOT that good, in my experience, at separating those "virtual micro maps", AND at displaying them in a really good way (and stable, i.e. next time you show that micro-map, it should look exactly the same, without your needing to do manual tweaking for that: the other big advantage of mm tools!). I must say that in my past trialling TB, I had not turned my attention to this - also because I never had a big-map there to trial on (!), since unfortunately, they are clearly NOT interested in getting new customers (that would of course need bring their existing material with them, i.e. would need to import it into their future TB monster-map) - even their reactions to askings for better import facilitites clearly show this.

My overall impression with TB is, they did NOT yet resolve the problem how to do interconnections (no, not even in TB 7, where they made another try at this), and they did NOT resolve the problem how to "list" those "micro-maps" for immediate access of them: Of course, TB allows for having ANY item as the level-0 item of such a micro-map, but it's exactly this "too much plasticicity" that makes TB a PERMANENTLY UNSTABLE representation of your material and of your problems to solve.

A better TB way would be to have (why not by a "PM" tree?!) standard "lists of views" (that must remain stable!), and into which you could enter any such item, becoming such a "view" = a stable micro-map.

These micro-maps must show links to other parts / other micro-maps / or simply to the TB "cloud" (meaning "somewhere" within the TB monster-map), as non-introding nodes working as links, but without everything "behind" those, and it would be a very good idea to have those links automatically showing, near them and in a minor font, their (perhaps multiple) "parents" (and why not making those clickable, too?) - but beware, it would be ONE such item, visible on the screen, and then any additional info of that "out-link" (= out of the current stable micro-map) as (rather minuscule) info as you'd have in "commentaries" and such in mm tools, i.e. further possible link "offers" by TB should be non-intrusive (whilst, if I'm not mistaken, TB currently shows such "further links" as additional, normal items, together with the respective connect lines, and this, of course, unacceptably bloats your present "stable micro-map".

In other words, as long as such "micro-maps" are not automatically graphically rendered in order to emulate their counterparts in mm, i.e. separate micro-maps there, but are just raw subsets of a monster-map, with "out-links going anywhere", users are well advised to stay with their collection of mm maps instead - and problably with their collection of MM maps, MM allowing for MNforMM, whilst most other mm sw don't have such integration as a work-around for not having native trans-map listing by attributes (let alone trans-map cloning).

(I know TB has rather good searching, but that cannot help, they're not allowed to rely on search, in order to do better conceptual work. It goes without saying that what I've got in mind, is perfect 3-dimensionality, too: Why not have such "stable micro-maps" with DIFFERENT sets of items, belonging there, in one scenario, and with some items considered as "outlinks-only", whilst in another map, and with the same "paren", what was "outlink-only" in the first map, becomes the legitimate content of the micro-map in question, whilst other items / sub-branches are cut out, not leaving but the outlink alone. Automation of such functionality (= by attributes, etc.) would be more than difficult, but that's not even necessary here:

For the time being, just make the TB developers introduce semi-automated functionality for "clipping" such branches, and for "pulling-up" others, in order to first (manually, but quickly) "make" your respective micro-map, AND then, for "storing" these, so that whenever you go to such a map, it will be presented in the form you've shaped it into - and that would also imply a durable spatial representation. Then, whenever you add something "possibly relevant" to such "solid micro-maps", rather easy, technically: Every new element that's a child of a "legitimate element" in the respective map, it'll be shown, and every new child of something that's represented as an outlink only, in a given map, it'll not shown here, of course.)

People who will really have followed what I've presented here, will know by now that I consider all those "collapsing ways" (= cutting at the bottom = "hiding the details") of "presenting things in manageable sets" as a minor way that's only useful for some uses, whilst I advocate, for real working, the opposite way, which is "clipping above", i.e. showing all detail (except when they get too lengthy and might be put into external files, external "items", or just "note fields"), but then, have multiple, easily accessible, and easily "creatable" sets of such detailed views - and I advocate much better semi-automatics for your assembling disparate items into new such sub-sets (and then, their quick manual trimming (or even enlarging in order to pull in more items)). As I said elsewhere, TB is at least trying a litttle bit, but not trying enough here, and worse, they don't seem to be "open" for advice / collaboration. And as said elsewhere, there is AI, for one, but also, we should try to enhance not only artifical enhancement of HUMAN intelligence. TB as it is would be a good start, but there's a lot work to be done.

And remember, all what I've said here, is about the planning / synthesizing and the analyzing work: I do NOT consider TB a possible total-reference-and-archive db, just as I don't consider mm tools such a thing: UR is perfect for this.

(Also, allow a short clarification: that German organization advisor I spoke of, in reality, she advocates THREE sets of data (I'm pastiching here): that "thinking data" above, then "reference data" by what she understands something like data which has often to be looked up", and then, the bulk, the archive(d) data (I'm writing from memory so cannot claim to portray her system correctly here). I never was fond of such 3-part systems since at any moment, a lot of "archive" data is - or should be!!! - reference material, hence the 2-data-set system I'm after: "Work" - and then links to "material", be it material that you consult three times an hour, or just once in two years - of course, there would be differences in accessibility... besides, which could be half-automatted, the system bringing material you often need, "nearer" to you, whilst withdrawing, step by step, accessibility-wise, material you don't need as often (any more) - but this a totally new subject, complicating things another time.)

Off-topic: Another new info for me: Copernicus wasn't first, a certain "Aristarchus of Samos" being the man (or even somebody else, gone with History) - cf. wikipedia unter "heliocentrism": tremendously fascinating article there!).

TB users are invited to link here, from their forum.

As for me, I now will try to make that "MNforMM" working for me, since my intuition to preserve my multiple micro-maps was right, as I've shown here. MJ would be well-advised to have some thinking in the directions broached above.

MM users are thus invited to link here, from their forum, too.




EDIT : Re GyroQ
Sorry, I had made a mistake in my reading the Essential vs. Prof. comparison table. My wishful thinking misleading my vision: Creating your own codes being the last of the "essential" checks. Now, checking again before buying, I see it's the first of the "prof." checks. In view of the numerous deficiencies of this tool (cf. above), the most important being that 20-codes limit for either version, I think I better do it within AHK, incl. instant access to my about 40 or so different maps from anywhere (impossible by GyroQ means anyway), at this time (and fast getting more). Even 29 pounds plus vat would have been a steal if it did what I want it to do, but not with only half of that, and then that risible 20-targets-only limit. Whilst AHK has accustomed me to not having any more limits to accept in what I'm doing, scripting-wise, and since MM allows for external scripting, the respective commands for docking new elements onto given level-1 items within one map must be listed somewhere, and then why not having a standard level-1 item "Inbox" in EVERY one of my MM maps, and send new ideas directly to those (provided they're not immediate-action ToDo's, of course).

[schferk]

GyroQ Update :

For non-programmers, it's impossible to access internal MM commands (whilst for programmers, there are ways). On the other hand, GyroQ (Prof only, "Essential" is worthless, so we speak about 49 bucks plus VAT here, but it's more than worth it) opens up a whole ecosystem around MM, by its integrated GyroActivator which is nothing other than a little macro language giving access to many internal MM commands you otherwise couldn't access by your own non-programming means, and which then can be triggered by the GryroQ dialog, or, in a much smoother way, by any (commercial or free) external macro / scripting tool (that you use for all your things anyway) that is able (that's the only, easy condition there) to do "launch program" commands.

In other words, you launch the little GyroQ scripts by your macro tool, e.g. AHK (or even text expander tools), where you assign kb shortcuts or special trigger words to commands like

PathOfGyroQ.exe "NameOfYourGyroQScript"

That's all. So you buy GyroQ Prof in order to get the underlying GyroActivator macro language, and then, you'll be able to do anything of what I said I'd like to do above, and much more, and it's up to you if you additionally use the "native" use of GyroQ, i.e. its above-described dialog on a regular basis, here and there, or even not at all.

You can download an about 90-page pdf that explains it all:

https://gyronix.zendesk.com/attachme...2-Help-Eng.pdf

But then, even better, under the url

http://www.activityowner.com

you'll get a splendid collection of scripts, tools, advice and help for that whole ecosystem that the developer has constructed around his GyroQ, and his ResultsManager (that costs a whopping 285 bucks plus VAT), but then, even what you'll find here around GyroQ, i.e. without having to buy the RM, is outstanding, incl. the (free) Outlinker tool, for connecting MM to MS Outlook, see also

www.outlinker.com

(Btw, I see there that armsys (who's also very active in this forum these days) has been knowning this GyroQ MM ecosystem for years, but then, I admit that it's only up to any person and his own decision, if he's going to share his knowledge that's clearly in the general interest, like I do, or if he's prefers to withheld any knowledge to himself, participating in fori in order to get even more info for himself, and more or less exclusively so. As said, I don't dare say the latter stance is criticizable in any way, even when I obviously have never shared it.)

So, it seems that MM, with the help of GyroQ Prof., could perhaps be made into a very smart DOUBLE use of being dashboard-AND-idea-collection system for UR, the former by means of UR's outstanding feature (in fact, there ain't so much competitors that make this available to you) of allowing deep links, and even for the latter, UR's deep linking feature would be very helpful it seems to me, whenever you just collect ideas within MM (i.e. avoid mixing-up of idea collection and dashboarding, with multiple linking), but have systematically a link from the source item of these MM idea maps to the corresponding (and mostly rather high-or intermediate-level there) UR items.

I'll certainly share my findings about smart interconnection between MM and UR, as I will have possibly found them in some weeks or some months, and this independently from the fact that there obviously are long-time MM-GyroQ-UR users (neither of which I am) who technically could have shared their respective smart hints, from their thorough experience with such a combination, years ago.

Anyway, it seems to me that a smartly devised MM-UR-Outlook (with a little help by Gyronix, thru 49 bucks) interactive workflow, being it within a small network or being it single-user only, clearly must have the utmost potential for your productivity; it would then be time that UR did a little homework to be on par within such an extraordinary combi.

(In theory, the same could be done with other such mm tools, but then, the missing link would be a tool like GyroQ - which clearly shows the exceptional benefits of a (marketing-leader) sw around which there has been developed an ecosystem of its own (similar to Word, Excel, Outlook, Access, sql db's, etc.).

[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.

[schferk]

Short update:

Nick Duffill, the man behind ResultsManager, GyroQ and the command list behind GyroQ, GyroActivator, is highly professional, really interested in what he's doing, and a kind guy on top of that (so there's a difference with kinook here, in style at least).

Unfortunately, with GyroQ you are not actually buying a "GyroActivator MM ready-made macro language" or such, since command sequences built with these commands tend to be unreliable: GyroQ is one, handy thing, but don't try to do too much with those macro commands that come with it, you'd lose your time as I did.

This being said, RM is top-notch and not programmed with those (and more) "GA" commands, but it uses the MM API, so here you are to expect reliable, trustworthy functionality - at 295 bucks plus vat it's just too expensive for individual use.

People trying to use MM/MJ for project / administration work... well, I'm not too sure that it's a really good idea here, since the core functionality of any current mm sw is just sub-standard, and so, the overhead of brilliant sw like Duffill's is considerable (as said, update sessions of many minutes 2 times a day, instead of real-time synching of any element in any open map in the network).

But there is that real advantage that mm, for planning and deciding, is unequalled. And then there is the prob that at some time, ideas become "actionables", and within your "actionables", you'll create further ideas, so the alternative of "doing the thinking within the mm sw, and then pouring it all to more PM-suitable sw like UR or such" is not a viable one, since you'd create chaos between your PM elements within the mm sw, and those within the PM sw. (Cf. current MM/MJ - MS Project integration which is strictly one-way!)

As for an intermediate measure, in order to avoid to have spread your "ToDo's" over dozens of maps, you could do a simple AHK (or other external) macro in the form of:

- assign an "action" symbol to the mm topic / element / item (e.g. a symbol for "Phone", for "Today", for "Look up", etc., idem for delegations)

- copy the item

- open your dashboard map (you also can do this with several dashboards, for several main projects; the important point here being, you'll have dozens of maps (each containing a more-or-less "self-contained" micro-subject of your overall project(s)): so don't get a dozen dashboards, on top of these!)

- select the central topic there (here a hint of mine: in MM, this would be the undocumented command control-home!)

- select the respective branch, for "Phone", "Look up", etc. - in MM, this is a real prob (you could do a search, but what a visual fuss that would be!): I solved the problem this way: downarrow (= starting from the selected central topic), then a given amount of "downarrow" repetitions (= the macro "knows", e.g., that the fourth such "downarrow" will reach out for the "Look up" branch (you'll shuffle these main branches around, so that your most frequent target will be only one "downarrow" away))

- do a control-v

- revert back to your original map (by alt-leftarrow, or, unnecessary, by using an AHK variable fed before)

So, this "solution" is far from elegant, and far from being "both-ways", but it solves the main problem of them all: To get all your "actionables" from your dozens of maps into 1, 2 or 3 dashboards to process them from.

From this, you can refine your macro, e.g. by putting the name of the original map into a variable, then by pouring the content of that variable, within the dashboard, into a label attached to that copy (= not clone, unfortunately, as we all know) within the dashboard. Or, much simpler, just add that info to the copy's text: original text: "Blahblahblah", from map "Thisandthat", would become, in the dashboard: "Blahblahblah (from Thisandthat)".

Also, you could refine your macro by changing the original symbol, i.e. the original item would have an icon "x", but that icon would mean, "is to be processed that way, but hasn't yet been processed that way", and the moment you copy it into the dashboard, its icon would be changed to icon "y", meaning the same kind of processing, e.g. "Look up", but also, "has been put into the corresponding dashboard"; this would be a good idea if a map remains within the planning stage for a while, with lots of changes being made, before you then only enter its "actionables" into the respective dashboard.

This is all one-way, meaning when the dashboard "ToDo" has been done, there is no indication of this within the original map, and it goes without saying that technically, a macro backwards would indeed be possible, by going to the respective map (which, remember, we'll have notified with "from Thisandthat" within the copied item in the dashboard), then searching for the corresponding item there (meaning for (unchanged!) text in that item, and then deleting the item, or just changing the symbol, the background color or whatever.

But what a fuss! There isn't any better proof for what I say: Inter-map clones are way overdue! (And I explained above how to realize them on the technical level.)

If it weren't for the superiority of idea finding by mm maps, I would never advocate such a hybrid system; in other words, it's really worth all these unwanted probs... whilst a cloning feature would indeed be tremendously welcome.

If I was allowed just one advice, it'd be:


Separate your thinking / planning / "decisional" (and together with your ToDo) stuff from your "material".


And this would be valid for 100 k of "material" items, or for just 5,000 of them. What you don't bring forward, will be safely buried, most of the time, and any amount of tagging will be of not much help.

Hope we'll get an "integrated hybrid system" instead of all these manual manipulations between incompatible sw's, some day.

[schferk]

A necessary correction of my above macro:

a)

I do all my maps in the all-directional style, but not clockwise (as MM does then automatically), but (by rearranging topics) left from top to down, then right from top to down. Now the arrow keys don't function in any "topic order" way (= creation order, or "re-numbered" order), but just as you see these topics, i.e. if another topic, in the map you see, is beneath your current topic, you'll get to it by pressing the down arrow, etc. The same goes for repeated arrow key pressing when there are (not only main, but) second-level topics: arrow key pressing will get there, instead of just travelling within the main topics.

Now for the dashboards. Here, such an all-directional ordering would create a situation where your macro wouldn't "know" how to get to a specific main topic (that will become the "parent" of your to-be-pasted actionable). So, branch style will be "to the right", and then, any new main topic will be placed under the previous one (with manual rearrangement by control-alt-up/down-arrow).

Now, for selecting your target, you select the central topic (0 level), then do ONE right-arrow, which gets you to the first main topic (1 level), and then, you do the necessary amount of DOWN arrows, in order to get to your target main topic (and then paste as "child").

b)

As said above, most other possible tries to get to your target main topic would cause much more visual and procedural fuss (e.g. opening of the search pane, etc.), but then, you CAN apply another method:

- select the central topic
- control-f
- entry #3
- return
= This will search for #3 within your dashboard map; note you'll get into trouble here if any of your imported copies will also be "coded" with that #3, and note you can't but search for such text codes, not for symbols. On the other hand, "symbol 3" in your "working maps" could be equivalent to "textcode #3" in your dashboard, so technically, it's perfectly possible to have, in your macro, such a transposition table, i.e. not a transposition table "how many down arrow key pressings", but a case structure for what #x to be searched for.
- escape ( to close the find dialog, not to be mixed-up with the search field, for more advanced searching)
- return (in order to revert focus from the text of the target topic back to the target topic itself!)
- control-v

c)

Quite handy in such a scheme is the fact that your copies will bear a symbol, whilst your target main topics will bear the same symbol. So, if any copy has been placed beneath the wrong target main topic, its symbol will clearly show the misplacement of the copied topic - the same as with color coding within a range of lever files and such.

d)

In many cases, you'll probably muse if you are to copy just ONE sub-topic to your dashboard, or if you better copy a whole sub-structure to your dashboard, where there are two or more such "actionables" within the perhaps 3, 4, 5, 6 subtopics there (and where the "parent" topic itself isn't an "actionable").

Do it whenever it makes sense: Do it when these "actionables" within this little structure are similar, i.e. all coded "3" or perhaps 2 "3" and 1 "4", the "4" being similar to the "3" category: The "wrong" symbol here will show that the one "4" subtopic there doesn't really "belong" to the "3" actionables in your dashboard, but it will be near the neighbouring "4" structure, so it seems that this will be absolutely acceptable.

Even with non-neighboring codes, this could be an alternative to not copying the whole sub-structure (= 5 or 6 such sub-topics held together by their common parent / great-parent) but only the 3 or 4 different actionables there, each separately: Especially if your dashboard doesn't get too convoluted: These dashboards are about practicability, not about 100 p.c. correct taxonomy. Of course, the different actionables here should be clearly distinguished by their respective symbols, in order for such a "slightly displaced" actionable not getting "lost" resp. "forgotten".

ad b)

As hinted at above, ONE macro processing a dozen or so different symbols, by checking a repetitive if / else if structure (in AHK, or a "conditions" structure in other scripting languages), would be MUCH more practical than 12 different and very similar macros, for 12 different "action" symbols, and this means your macro would be triggered by F7, e.g., and then you'd press any of your a...z keys once in order to tell the macro which symbol is to be placed within the current topic - and this will also determine the respective target topic in the dashboard.

The same will apply (cf. my post above) when you "distribute" pre-coded topics in your working maps, i.e. when they bear some provisional symbol (= "has to BE copied to ..."): This symbol will be replaced by the definite symbol (= "has BEEN copied to ..."), and further processing as usual. This means, if you work this way, with pre-coding instead of copying at once, early in the planning stage, your macro should contain a first command "delete any existing symbol first" - in MM that would be control-0.

As you see, such an external macro is easy and reliable (your dashboards should always be loaded, of course, but if they are not, AHK provides for the respective wait command in order for them to be loaded first, instead of getting macros running wild), even if it's external, as said, just put upon MM or another mm sw, instead of being "burnt" into it. Advantage here: You only need to know ONE scripting language, for ALL your needs, and you won't have to learn a new macro language for every application you try to domesticate to your needs.

EDIT:

As for the two-key macro triggering, it goes without saying that for copying to action topics you need again and again, you could assign just ONE-key macros to these commands you need more frequently; here, F7 with then a...z, but F8...F12 for one-key copying, and / or why not F7 and F8 for copying with then groups of a...z targets, but just F7 and F8 for frequent, standard target, whenever after the F7 or F8 key pressing, there is NO such a...z key pressing within a second (AHK allows for such time frames without any problem, whilst in AI, that would be much more complicated, but is also possible, with a gui construction). Variant: F7 and F8 with no further key pressing within 600 ms = your must-used target assignments, F7 and F8 two times in a row within 600 ms = two more very frequently used targets, and F7 plus a...z within 600 ms = further targets: This way, at least 4 targets are very handy, and that should be all you need most of the time. It goes without saying, that here, the scope would be within MM, but that on a much more general level, you could have such shortkeys with scope UR, e.g., in order to copy - just an idea - the title, and the very first paragraph of the content, of your current UR item into such an MM (or any other) dashboard. (Also, for pre-determined targets within your UR structure, for clippings, those same F7 / F8 keys working in a similar way when your current scope is your browser. As I said before, the functionally-similar (but technically necessarily totally different) assignment of the same keys, within different scopes, is the key to good macro programming: The same keys, in different applics, will have similar effect.

The AHK command that ensures your macros not running amok, is, here, winwait("Ultra Recall - NameOfYourTargetItem"), so any possible response time from UR will not become a technical problem - it just remains a psychological one. And, as said before, internal macros would possibly be able to work without all these unwanted screen updates, whilst our external macros do lots of screen flashing: they are effective, but they ain't beautiful - and they need much more time than internal macros would ask for: another big argument for better in-built functionality of the applics we buy.

[schferk]

Another idea.

You know CRM sw; you (rather successfully) try to replicate most of its functionality within a system like UR (= you can sort / search by multiple criteria, Boolean search, and hit "tables" (lists, at least), with coding, lots of data interpretations are possible in UR).

Now for the advocates of "Have your customers / prospects handy by mm maps" (One-page methos, etc.) - it's evident that for analysis of your customer / prospects base, mm is near worthless; on the other hand, when in important / decisive contact with a customer / prospect, it's evident that even standardized and more or less "encoded" data isn't that obvious: Within your UR data about him, there'll be lots of text, flurrying in front of your eyes, and after the conversation, chances are you'll have overlooked important details.

Now what about a macro building up a standardized "customer map" for him (= MM in your second screen, UR would remain visible in your main screen), almost in real time

(make it the first 10 or 15 sec. (= slow comp) of an important phone call you receive from him, let alone a biz call on his premises (where the same macro would build up such a map but which you'd then edit / refine manually, and probably print out)),

from your standardized customer data in UR? It'd create a new map, and from your UR paragraphs (= form), beginning with £a=texttexttext, £b=somemoretext, etc., it'd build up main topics, under which it'd put the further paragraphs als children, or even putting further text, within a given £c section, into MM notes, leaving only the very first 150 or so characters within the corresponding sub-topic.

You'd have standard sections, as said, and if a standard section is empty, the correponding MM topic wouldn't even be created, but if there are important elements to consider, they would be literally thrown into your face, with red symbols, yellow background color and whatever, and this is especially useful when it will not have been yourself who took the complaint of this customer, last time, but a collegue of yours: Here, an almost-instantly appearing "red sign" in an MM map would be of tremendous help, instead of getting (or not), within the depths of your text commentswithin UR, to this info only after 60 sec., and after your customer did plenty of rant on you, during which you desparately will have tried to find the corresponding details he's ranting about again.

Getting to the same info, within UR, would mean frantic scrolling (and would suppose perfect, bling-bling formatting anyway that's often not present), or even more frantic shifting back and forth within 3 or 4 sub-items in UR with respect to this customer. (You try to find the details, while your customer checks you don't hear him but with one ear - most of your attention being absorbed by your trying to get to the decisive info in your text.)

And even when there were NO such probs between your company and your customer, even when it's all just trying to satisfy him in the best possible way: As soon as you ain't the only contact for your (possible) customers any more, or just get too many of customers / prospects to deal with, such an INSTANT INFO upon what preoccupies the person on the phone, would not be extremely handy, but would leave a perfect impression on the customer/prospect, re your professionalism - he'll be really impressed (not if you spoke together yesterday, but if your collegue - or even yourself - discussed the matter 3 weeks ago: he'll think, wow, my prob is always present in this guy's mind, it would be advantageous for me to buy from him, instead of some of his competitors! - instant availability of the CORE info means, for your customer, he's constantly in your mind (even when he's not).

And since you know all this, your own stance here will be very easy, no searching around for the core info, you're safe you'll get it instantly... and this will relax you in a spectacular way that will communicate to your caller, again reinforcing his impression of your incomparable competence (btw, the same applies to any other element of your business knowledge: easy access, easy going, perfect proof of competence).

Now for the macro, it could even further this strategy by building up the really important main topics first, i.e. not by the order of standard-encoded text paragraphs in your UR file, but searching first for any non-standard, "currently important" coding, and thus, you will be able to read these current core elements of your customer relationship as soon as your macro starts to build up the corresponding map, even when the completion of this construction effort in front of your eyes will take 15 seconds.

As you see here, the only delay being, how much time will it take to display the "main" item of the customer/prospect in question, within sw like UR, AS or such this will be very quick, and whenever possible, have another routine (also possible by macros) to fetch the phone number of your caller from within your phone system, in order to display the corresponding UR page almost instantly - and then, the building up of the corresponding MM map could even have been automatically started!

Now for some seemingly coding prob: One collegue put the "current prob" code into the UR text, some day, i.e. a ££ anywhere in the corresponding paragraph. Now it's a customer of longer date, so there are let's say 4 or 5 such "££" within the text - what's the "current" one, then? (And remember, trying to force your collaborators, or even to force yourself, to administer such codes, would be a hopeless venture: no time for that, and error-prone as hell on top of that.)

No problem, though: Whenever such codes are put into your UR text, the corresponding little macro will also enter the date of creation of that code. And of course, the map-building macro then would SORT these "current prob" codes, by date, and start to build up the map with the REAL current such prob paragraph, and then only add less recent "current prob" text passages, by creating "child" topics, or even by putting such probs into notes, e.g. when they are older than 6 months and are coded in the normal way, i.e. there would be codes like "prob forever" that wouldn't be buried this way even years after the fact - and if ever they get less important, why not change the triple £££ into the ordinary double ££, in order to make these ancient probs fade with time?

Similarly, your map-building macro would fetch data from your accounting sw, e.g., in order to have the recent command history of this particular customer (without having these numbers to be stored both in your accounting system and in your UR system), and similar for any relevant data concerning your customers and prospects: a certain standardization, by coding ordered paragraphs, but also "free encoding", i.e. codes wherever pleases you, and triggering the building-up of your respective info map (incl. Excel extracts, etc. - it's just about the power of your hardware and about its response times, there are no sw / programming probs whatsoever in all this).

As you can see here, efficient IM is MORE than just creating db's - but on the other hand, solid db's, as UR's, are the best possible way to store your raw data, from which then you'll get your graphical representations for instant - and that implies: pondered - access when your customer calls: data without perfect, instant orientation is not instant-access data, even if it's all on your screen without delay.

So, this post, at the end of the day is just another example of what I advocate above: Separate your "decisional" data from the depths of your raw data - and whenever possible, automate this process: but it's obvious that CRM is a field of predilection for such automatation: it's easy, from the moment on you think about the details applying to your business.

Most people dream of integrated solutions like SAP, but will never have them available; but that makes them overlook what home-made, easily affordable smart hybrid solutions can offer them, and in the field described, it'd be a quantum leap.