During meetings / Brainstorming I prefer outline view allowing me to quickly nest information quickly. I want to interact with the same outline in Map View but all my nested information becomes a container (obviously) and there’s too much clicking on map view to reach information.
I create an agent which allows me to see all notes from a given meeting in a flat view
I’d like to re-create the outline hierarchy but not understanding the correcting sorting required using outline order/depth/sibling order
I’ve been playing with XPOS - YPOS position to also re-create the outline hierarchy in Map View (however close) , but still not getting the right combination.
Besides tree view , is agent the way to go or I should research other functionality ?
It is VERY hard to go in both directions, i.e. keep a map view in sync with the outline or outline view in sync with the map. I’ve found you can kinda do one or the other but not both. The action code of the notes conflicts with each other. Agents aren’t effective, as you’re doing with aliases and any work you do will be reset if/when the agent reruns and reproduces the agents. Also, @TomD and I kinda got outline view to vertically layout or horizontally layout in map view with a step, but what we’ve achieved thus far is experimental at best and not very reliable.
Long story short, from my view this is HARD. I’ve already put in a number of cycles on this. If you figure it out, let me now.
I understand this need, and have often wanted the ability to work within map view without having to step into child containers and back out. The problem is that map view is n-dimensional — from a view perspective — and what we want is a way to effectively flatten the views to a single dimension while simultaneously preserving all n dimensions. You get this to a degree in that in map view containers present a limited view of their next dimension. The limitation is that you can only see (not edit) the child container’s notes (though not it’s links). One approach might be to have child containers behave like adornments (“container adornments) — including arbitrary nesting of container adornments and regular adornments, but all acting as if they were members of the same map view. This could possibly be a new type of map view (flattened map view). The objective would be to have the flattened map view preserve the nesting of the corresponding outline view while allowing editing of the entire outline in a single non-nested map view. Of course the would certainly constitute a née feature request, one that ultimately may prove to be intractable.
Flatttened view comes up from time to time, but it’s harder than imagined because, as so often in the mind’s eye. we elide details that get in the way. Consider {x,y} position for one. As we flatten one or more items may wish to occupy the same space. so we move them, but which one holds the desired position and why. We move the others, but there are notes in the way. Do these notes move further out or do the first ones go beyond them. At the end, do you have a meaningful map? Likely not, as many things now aren’t we here they should be in their own discrete map. And so on.
Structurally, Treemap gives a collapse but generally is sub-par visually unless you are looking at relative values (i.e. the relative area of the note boxes)
Thanks you @satikusala@mwra@rtalexander for your feedback on this. It has helped me to take a happier decision to stop tinkering with TB to achieve this. I was really going in circles.
Currently I’m using Prototypes with bolder colours /attributes to differentiate between levels of hierarchy. That allows me to bring sort of flatten map in 1 view.
Can XPOS YPOS values be automated using above to bring above flat/hierarchy onto map view?
Another take on this goes back to the metadata aspect. If your outline notes (e.g. containers) seed values into the note _with the intent of aiding map view use— you might have a way forward.
As you’ve noted, it is easy to get bogged down in this. But, I think an answer is to turn the problem around i.e.
Why can’t map view just plot my whole outline.
What metadata (attribute values) might I add that makes it feasible to map my outline in a single map view. Tip: as likely this means an agent, avoid attributes that intrinsic (IOW, original and aliases can have different values for the same attribute).
You are of course right under the assumption that a flattened map view is an alternative view of a map. But if you consider the flattened map view to be a separate and distinct view of an outline, combined with its own state (e.g, flattenedXPos), then interactions with the standard map view could be avoided. That is, there would have to be independence between the two kind of map views.
(It’s now clear that the name ‘flattened map view’ was poorly chosen by me as it collides with the abstractions and assumptions of regular map view.)
For me, using map view is of limited value as the eliding of a container’s cause unnatural and arbitrary context switches which tends to interrupt my flow of thought. Also, for me, map view tends to hide essential information, often forcing me to switch back and forth with outline mode, again causing unnatural context switches.
The reality is that map view and outline view are not equivalent in terms of the semantics they represent. Of course there are some direct correlations — the children of every container in an outline defines the subject matter for a map view of the container. But the local context of the container in the outline is not present in the map view of the container. One has to switch from the map view to the outline view to access the container’s local context.
I wrote this series of notes way back in v4 but I think it still holds true: Outline vs. Map Interface
The key take-away is that outline order ($OutlineOrder) in the map is reflected in the map z-order (i.e. front-to-back stacking order) and of itself has no effect on {x,y} placement. Now, it may be that if a container is populated outside map view that the notes on first map inspection are listed in a row in outline order left to right. But, that is essentially a by-product of ensuring notes added outside a map don’t all end up overlapping one another.
Although it needs use of links (i.e. hierarchy is not automatically mapped) I do think hyperbolic view is a good tool here though it is currently hampered by visual filters for link types and the ability to scope how far from focus point the graph extends†.
†. I’d acknowledge that in a very interlinked graph, ‘N links from here’ might be more complex to report than the user assumes and/or doesn’t return quite what they imagined.
I’ve kickstarted the process and would like some tip here to proceed. I’ve got the prototype ready which allows me to distinguish between the Outline header and notes. I’ve kept things simple for learning purpose and created only single outline structure and notes. See TBX and screenshot
Going by @mwra beloved incremental formalisation approach. I’ve agreed upon a manual approach using stamps.
The Z-order and the color at least makes it easier to select the relevant items from the map. Plan currently is to select the (flat parent) OUTLINE Items + Children on the map. Drag them to some place , apply stamp to change the YPOS of the selected notes , keeping XPOS the same to align them vertically.
I can’t figure which parameters to use to align them below (flat parent) Outline Item. Flat Parents.tbx (103.3 KB)
Inside a find() the ‘this’ or ‘current’ note is the note being evaluated. If we want to reach outside the query to the note running the code we need to use the ‘that’ designator.
In very loose terms ‘that’ is to find() as ‘agent’ is to an agent’s query or action.
No, the right side is an ‘offset reference’ to the value of $Xpos but for a different note. However, we don’t know the exact name/path of that note and it changes with use. what we are saying is:
_set this note’s Xpos to the Xpos value of a note that is the first sibling of this note.
In truth, the latter code might be weak as if there were to be several containers with several children, more than one note might be matched. So we might need a query like (not tested):
Note the use again of the ‘that’ designator. The first query term asks “do we both have the same parent container” and then we know only one note can be our first sibling.
Offset references use a $Path or $Name and find() returns a list of paths. Unlike an agent query, find() doesn’t de-dupe its results so if you think aliases may get found add a last query term &$IsAlias==false thus ensuring only original notes are matched.
I like MindMap views and use often MindManager or NovaMind. The best way to make and analyze in mindmap view is to create multilevel structured outline in Tinderbox, polish the document. Then export as .opml file, import it into maindmapping software, rearrange topics, save as .opml, import into Tinderbox and finish the document.
