I’m trying to use the Map view to create notes, add notes to other “container” notes, etc. In effect, create an outline structure with notes and sub-notes, but visually. In fact, I keep trying to do this, release after release, and keep running up against an inability to arrange “sub notes” within a container so they are visible when displaying with other containers, etc.
For example, I’ll create a couple of notes and then realize they’re part of another category represented by a third note. I’ll drag them onto that third note, whereupon they disappear “inside”, hidden from view. I’ll double-click on the new container and try to manually arrange the contained notes so that they’ll be visible when I exit the container, but no luck. I look for ways to snap them to a grid internally to that container. No luck.
What I’m expecting to be able to do and what I’m expecting seems pretty obvious to me. Useful and intuitive, even. But I’m not seeing anyone else with similar questions, so I suspect I’m in the grip of a faulty mental model with respect to Tinderbox. What am I missing, please?
Perhaps you could use adornments instead of container notes? For example, working with @eastgate’s example, you could create an adornment called “Kenmire House” and set Cassie, Trish Parker, and May on that adornment. If you need to query the adornment, you can create a boolean attribute called $IsInKenmireHouse, and then give Kenmire House an $OnAdd action to set $IsInKenmireHouse to true, and an $OnRemove action to set $IsInKenmireHouse to false.
Adornments don’t give you the hierarchical structure that container notes do, and they’re not visible in outline view, but they behave nicer in map view than container notes, in my experience.
Thank you, Mark, I appreciate the careful reply to what must seem a very basic question. Believe it or not, the key difference between the process you illustrate and what I’ve been doing is that (I think) you “pre-sized” the note-that-would-become a container. I haven’t been doing that, but simply dropping one note on another and expecting some form of re-sizing/visibility control to operate. Which is completely unnecessary, if I do as you suggest.
Thank you very much Galen. I have done nothing with adornments so far, and will experiment. I think I’m going to want to preserve the behavior of container/note in the Outline view, but maybe not.
Thank you Paul. I’m guessing I’m going to be wanting to move back and forth between the more freeform and visual map view and the more structured Outline view, but time will tell.
Thank you for taking the time to chime in. I appreciate it!
Thanks Mark. I know this must seem completely obvious, and kinda trivial. I think I’m struggling with some notion that the position of the notes, once they’re in the container, have some dynamic positional relationship to the “borders” of the container. As if I could “line them up” (for example) with the visual top of the container, or the left hand side.
Or, looked at another way, when I’ve clicked into the container and am re-arranging notes within the container with respect to each other (I don’t think I get the benefit of the grid helpers unless I do this) I have no idea where they will appear once I click out again, to the enclosing container.
I’ll keep experimenting (and I ordered your book!).
Yep. I’ve never figured out the relationship between the position when looking at a container from the outside, and when drilling down into it. So if I’m looking at it higher up and drag the contents around, when I double click it to drill into it, the note position isn’t particularly helpful. But when I move that map around and go back up a level, the container no longer shows me what I want.
I think the problem here is the user wants the parent $MapScrollX and $MapScrollY (which control what part of the child map draws in the viewport) to remain constant. IOW, no action of moving scrolling the child map changes the portion seen in the parent viewport. The only changes seen would then be changes to objects visible in the part of the childmap.
Currently (and this seems the behaviour back as far as at least v5) the parent viewport seems to show you the part of the map you were looking at when you navigated up a level. Not tested is what happens if you leave the map by switching to a different/tab view, i.e. leaving the child map by mean other than an upwards map view traversal.
Perhaps consider adding a $MapScrollLock (boolean, default of false) that if set to true locks the scroll position of the container’s viewport so $MapScrollX and $MapScrollY remain fixed until released. A default false retains the status quo for existing use.
Very new user here. Finally have a long weekend to play with TB. The “lost notes” problem has been bothering me and as a result, limiting my use of the Map view. Adding notes or editing locations causes me to “lose” the container view showing notes when I return to the top level of the map. I too, like the structure of containers (vs. using an adornment). Hoping the “scroll lock feature” or another alternative makes it into a future release.
Charlie
The behaviour here is potentially more complex than imagined. I think there is, varying by user, a presumption of what is seen in the parent viewport vs. the map location displayed when drilling down. IOW, the viewport for some is a ‘preview’ or the child map. This may not, however, be the immediate locus of activity when drilling down - or if switching view type in the tab.
The suggestion of a locking viewport scroll does seem to de-clutch the preview (viewport display) from the actual area shown when drilling down.
In the meantime, a rule (or edict) in the parent could update the $MapScrollX and $MapScrollY to the desired values and essentially restore the desired default viewport view. Another approach would be to set the top left child note in each (relevant) map at $Xpos/$Ypos of {0,0} and set its $Lock to true. arrange all other notes as desired in relation ship to that note. Arrange the parent viewport so that the {0,0} note is in the desired position. Note the parent’s $MapScrollX and $MapScrollY and make a stamp to set those values. This stamp can now be used as needed to reset containers where the viewport arrangement is important and to avoid the need for always-on rules.
In doing some further testing of the above solutions, I noticed one unexpected thing. I’d assumed that if $MapScrollX and $MapScrollY were both zero, then the {0,0} point of the child map would be at the centre of the parent notes icon (ignore $TitleHeight).
However a default sized note (3 wide, 1 high) placed at {0,0} on the child map seems to draw such that:
parent $MapScrollX 0 is at child note $Xpos 3
parent $MapScrollY 0 is at child note $Ypos -0.5
Why this should be I’m not sure. However, in a long-lived app like Tinderbox one may assume that the original design assumptions in this area don’t necessarily reflect current users presumptions as to how this should work. I think therefore it warrants some clarification as to what people expect and why whilst being cognisant that not all users use the same view all the time. IOW, it’s not just one person’s viewpoint we ned to resolve.
Reviving this older comment, to agree with it: something that evolved in my use of the program was finding that – for my particular tastes and working style – adornments were usually the easiest and most effective way to get where I wanted, when operating in a map view.
Many aspects of Tinderbox are optimized for outline-style, hierarchical behavior. The Outline view is based on that, obviously, and Chart and Treemap views use variants of a hierarchical display.
The Map view is fundamentally not designed for hierarchical display. What it shows, in its simplest form, is a group of items all at the same outline level, or within the same container. There are a zillion workarounds for this designed-in limitation, via aliases and “view ports” and so on. A set of links can give a one-level representation of a hierarchy. But fundamentally the map view is doing something different from what most outlines are intended to do.
That is why I generally find adornments a useful way to illustrate what I want in a map view. (Obviously each person’s tastes and styles differ.) But here are a couple of resources showing the possibilities:
Mark - I’m trying to use a note as a container for other reading notes. When I drag a reading note into the target container, the reading note disappears into the container, and I can’t locate it on the map when I open up the container (which is ok, because I can see the reading note inside the container in Outline View).
However, if I want to drag the reading note back out onto the map from the Outline, how do I do that?
To promote a child to a sibling of its parent in Outline view (i.e. move it to its parent map) the easiest way is to use [Shift]+[Tab]. this promotes the selected child(ren) to be the next (in outline order) sibling of their parent note.
