View Single Post
  #25  
Old 12-02-2012, 04:02 PM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
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.
Reply With Quote