How are Tinderbox's map cards grouped by prototype?

I created three color prototypes:

How Do I automatically group the same prototype card? Like this

How to do it?

I don’t believe there is such. How for instance, can the app know in which order the colours should sort or that you want a grid 2 columns wide as opposed to 3 or &, etc.? I don’t note that to argue against the need, but surface the hidden assumptions.

So, what is there at present?

Map layouts will use the $OutlineOrder, when per container (i.e. map) map may be modified by $Sort and $SortAlso (see more on sort).

So if I take this set of notes (note the outline ordering):

And sort to grid:

I get the items in $OutlineOrder. I think the number of columns used is set internally by the app based on the number of items and/or available visible screen space in the map pane.

But, if I set the map’s $Sort to ‘Prototype’, i.e. each note’s $Prototype, and apply clean-up to grid again we get this:

Same grid size but the notes are now arranged (permanently moved in $OutlineOrder) sorted by prototype. The prototypes are sorted in A-Z order (blue/green/red) and within the grouping the pre-existing outline ordering is used. So b2/b3/b1 as per the previous grab above. If $SortAlso were set to ‘Name’ (i.e. using $Name), and we run grid again we get:

Of course you could set $SortAlso to some other attribute value, even a user attribute holding a specific order you wish to maintain. Indeed, I suspect you’ve used $Color as a proxy of prototypes as I have here for clarity. But you could be sorting on any (attribute) criteria, $Prototype or otherwise

Bear in mind:

  • grid clean-up works on changing $Xpos/$Ypos, i.e. the {x,y} position on the map and doesn’t affect $OutlineOrder.
  • $Sort and $SortAlso change a note’s $OutlineOrder. That doesn’t show in the map but it does affect outline view (in case that matters). Also, removing a sort (i.e. setting $Sort to no value) has no change beyond the sort not being re-applied. IOW, you can’t reverse back to a previous sort (unless you capture the ordering in a user attribute and re-sort on that).
  • The sort (i.e. $Sort and $SortAlso settings) must be applied to the Map’s container and not to the notes on the map. This is why in my demo (file below) I’m not using the root-level map. There you’d have to set the doc default for $Sort which would sort not only the root map, but all maps in the doc as they inherit the default. In truth, unless just messing around or sketching, I’d advise always doing serious map work in a container.

So far, so good… But to me the next reply might be either/both:

  • “Fine but I don’t want to alter the outline order”. Then you’re limited to what the grid cleanup alone can do.
  • “Fine, but I want a different ordering of prototypes”. OK, it’s a bit more work but here’s a solution. Add a Number-type prototype $MapSort and for each prototype set a number. Then use that as the sort, instead of $Prototype.

Here’s what the latter look like if I set my red prototype to $MapSort 1, blue to 2 and green to 3. Previously the sort on $Prototype gave us order blue/green/red. But sorting on $MapSort and $Name then cleaning to grid:

Whilst I don’t think your starting goal is necessarily achievable in the fashion stated, I do think you can get close to it.

If i’ve misunderstood the question, apologies and please clarify what I’ve missed. :slight_smile:

Oh, and here’s the doc I used for the test, in case it helps: MapSort-demo.tbx (175.3 KB)

†. You can select notes and drag them into a container in map view, or in Outline add a note above (in outline order) the notes to be demoted, select all the latter and hit tab. Note that adornments can only be drag-moved in map view as they can’t be seen in other views. Regardless, all existing {x,y} map positions are lost as the items are drawn in ew positions on the new map. It’s a know limitation - another reason to start map work in a container from outset!

2 Likes

After I downloaded your tbx file, I quickly understood the sorting of outline and $MapSort. I think it solved the problem of sorting and sorting tasks!

Thank you very much for your kind help!

Unfortunately, why can’t map be grouped?

What do you mean by group? Don’t overlook smart adornments.

Here, building off the last demo, i’ve added a smart adornment with the query $Prototype=="green", which has this effect on the last illustrated (above) map:

If I select all the notes again and clean up to grid, this is the result:

So if you wanted to ‘group’ (Tinderbox has no such notion) the three different prototypes differently, then try 3 smart adornments, one per prototype. Smart adornments layout their matching notes in the same manner and you can’t turn off their clean-up (read the article I linked above). You can turn off their query letting you move matches, but re-enabling it to refresh matches will re-arrange notes on the adornment: that’s just how it is.

A good general learning point is the way Tinderbox works as a toolbox rather than a utility. In the latter , to do task X, you look for the ‘do X’ button. you get the result likely with few choices: you get the result but possibly not in the way you wanted. In the toolbox approach, there is in most cases no ‘do X’ button. Rather you figure out what doing X implies (see above with ‘grouping’ vs. smart adornments’) then build the task using the tools in the box. In the same way an Erector Set (AmE) or Meccano (BrE) doesn’t have a crane in the box: rather, it has the parts to make one.

If the response if that’s too much effort the other option is more the utility and accepting their solution is as close as you’ll get. Embraced, you get to make the crane you wanted. Plus, it can be improved over time and re-used as much as you want.

The selection of tools and the potential tasks are many-fold so its not always obvious what you need. that’s one of the things this forum can help with, as here. :slight_smile:

2 Likes