View Single Post
  #18  
Old 11-27-2012, 12:38 PM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
(...)

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

Last edited by schferk; 11-27-2012 at 07:51 PM.
Reply With Quote