I created three color prototypes:
How Do I automatically group the same prototype card? Like this
How to do it?
1 Like
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?
- Cleanup view tab. That can give you a grid layout but doesnât itself deal with order/segmentation.
- Force Directed Layout: 'Dance'. Interesting but not pertinent here.
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. 
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.
2 Likes