Flattening a map

There’s an idea/feature request that I’ve pondered now and then, but may be worth putting out there now given this thread. Given my very limited coding experience I’m not sure how feasible it would be, but here goes:
Could there be a way to turn on or off the affordance whereby a note is “swallowed” when put on top of another note? Ie the second note would become a container as usual but wouldn’t LOOK like a container graphically. My first thought was devising some built in attribute, say, $ActLikeAdornment that set to True, well, makes a container behave like an adornment – although this would only make sense given a small number of sibling levels in the note/container.
I haven’t fully thought through how this might work via a rule or some such (perhaps even a function?) But the advantage there is that it might be able to be parameterized, such that the user could define which and how many sibling levels they wanted visible (ie "flattened) at a given time in the “as-if” adornment.
In any case this, if feasible, would mitigate some of the representational challenges associated with map view and container windows. The huge question, of course, is whether it could facilitate the visualization of links between containers, ie at least partly combine the affordances of map view and hyperbolic view. My sense is that this might be very tricky, but, again, I thought I’d put it out there.
I’m going to try to join the meet up now and see if this makes any sense to people.

[This was raised in this thread:Basic set up questions for Map project but is moved here to avoid thread drift]

This used to come up very regularly in early Tinderbox days, before the range of views was added. It has never been taken forward as the edge cases are problematic. It can’t be assumed a document is never more than 2 levels deep. If the first two layers are collapsed, how do we know the now-‘flattened’-to-adornment contains container(s). As the levels are collapsed and items on different levels are found to have the same (or close) {x,y} position, how is the new map made clear.

The user may say, “I don’t care, I won’t make a doc like that”, but users still make mistakes and the app would need to know what to do when faced with such challenges.

If you need to flatten nested maps, have you properly considered using treemap view? That flattens one or more nested maps. People often use a Tinderbox map as if it were a drawing tool like Visio or OmniGraffle, which it isn’t. The look is convergent but starts from a different place. As the link thread shows, the more a map view is used as a static infovis drawing tool, generally the more it results in actions that make much of Tinderbox wider toolset harder to use.

There is no right or wrong here and the above is not to push back against the idea. But the idea is definitely a more complex issue than ‘just’ flattening containers into adornments. :slight_smile:

Lovely meeting everyone just now. Yeah, I totally get it re the complications. It sounds like filtering a hyperbolic view would be a lot less cumbersome than, for instance, trying to parameterize/ be able to specify the sibling levels of the faux adornment. As you note, there’s always likely to be a tension between an “all at once” graphical representation and the manipulability / comprehensibility /analyzability of the data. The OP might best be able to present their findings via a series, slideshow of differently filtered hyperbolic views.

1 Like

One approach to this “flattening” idea would be to draw the entire interior map of the container in the container viewport, scaling it so the whole thing fits.

This is not without some difficulties in itself. If a container holds a large map, the notes will be tiny. They might be hard to select, or to see. Drawing them will be a performance issue, and drawing the links won’t be easy. But that could be done.

However, imagine that these containers, which hold ~20 notes, had 2 or 3 links to each note. That’s about 60 links, crowded into a fairly small space!

Of course, you could make the container larger — even much larger. But then you have screen real-estate issues.

That sounds nice. I would note that part of the desire for flattening is wanting to see link-lines between child and parent, i.e. from current map to child map, but I don’t think this is possible even with an expanded viewport.

It’s an interesting problem. Treemap does flatten, as does chart view, but again the links aren’t drawn and the views become, respectively, very crowded and very large. For my own use I’m doing fine so far as is, but I’m inspired to help Roma catch the bad guys!