Does anyone have any examples of using $ClusterTerms to manage ‘Dance’?
I’m not quite clear what is supposed to be in attribute – is it a set of expressions such as $ClusterTerms == "pPrototype", or something else?
Use case:
I have a map with characters, events, questions, etc, all linked by different types of links. I want to dance the map but keep the characters reasonably centred, so an adornment + $ClusterTerms seems to be the way to go:
Each adornment that has one or more values of $ClusterTerms attracts notes in which those terms appear in the text. Adornments are otherwise ignored in the simulation. (atbref: Force Directed Layout: ‘Dance’)
Does anyone have any experience using this (or any tips for achieving the same end)?
$ClusterTerms is just a set of strings; if you have an adornment with $ClusterTerms apple; pear; plum; cherry;, it will attract notes that have any of these fruits in that note’s $ClusterTerms.
Each adornment that has one or more values of $ClusterTerms attracts notes in which those terms appear in the text.
$ClusterTerms is a Set-type attribute so no duplicates allowed but it is essentially a list.
For adornments (only) set its $ClusterTerms to hold values of terms in the $Text of any notes on the current map. A ‘term’ essentially applies a word or phrase to test for in $Text.
Thanks. I’d be interested to hear how you get on, as ‘just’ testing this takes some careful set-up of test data (and I’ve been travelling).
In terms of the look of things, my assumption is the adornments don’t move. Not least, we can’t link to/from and adornment and the ‘Dance’ moves linked items. Indeed it is not clear if unlinked or linked but locked (to background) notes are affected.
Thus the $ClusterTerms essentially pins some notes to their adornments—independently of any smart adornment query—whilst other elements move.
IIRC, there was no started specific use case for the $ClusterTerms but I assume that during testing, linked notes on (non-smart) adornments got moved when the opposite was required.
Note that Dance has no undo (else there might be a lot of changes to record), so if experimenting with maps that represent much deliberate work, you might consider working on a copy of the TBX until you feel confident as to how the feature works.
If you, or others using Dance, find aspects unrecorded in my article about the ‘Dance’ feature, do let me know so I can improve it for later readers.
As far as my specific use case is concerned, I think the limitation you pointed out (the ClusterTerm has to be in the target note’s $Text) means that it’s probably not going as useful as I thought it would be, without my kludging it with data in the text.
But I’ll have a play with dummy data and see what I find.
So, might I ask as to the implicit expectation here? If it is about clustering, consider Gaudí view†. If it is above some notes moving but not others, experiment with locking them (see $Lock and Non-editable notes).
I ask as sometimes questions are abandoned simply because the assumed path to completion is not possible. Consideration of the wider context can often offer up different solutions to the same end or alternate ways to resolve the same over-arching task. In context, the fact that we ran out of green ink does not stop us writing in sepia instead, or simply using a pencil to do the writing, or recording ourselves speaking the text we need to preserve. Too close a presumed harnessing of process and result can self-exclude useful alternative solutions.
†. As with Map and Table views, the Gaudí view only shows the children of the current container (in full detail, at least).
The map in question is a brainstorm container, with notes divided into prototypes – pPerson, pQuestion, pTheme, pGroup and so on – with appropriate links between notes.
The map is getting complex, and when I dance it, the less-frequently linked characters (pPersons) can disappear far from the centre. I’d prefer to have all the characters (i.e. the clustering is triggered by $Prototype) closer to the middle of the map for ease of linking – not necessarily fixed in place, but biased towards the ‘centre’ as a way of exercising a little control over the layout, while still allowing the linking to shape the dance for the bulk of the notes.
I read the entry on $ClusterTerms and thought that this may be a way of achieving it, if it could be tied to a prototype that’s all. But my question was more an exploration of what people use this feature for, rather than a burning desire to use it in this case!
The map is getting complex, and when I dance it, the less-frequently linked characters (pPersons) can disappear far from the centre.
Ah: that’s interesting! Normally, one would say that the point of this particular formalism is to let less-linked things be sent out to the periphery, but of course, here you might like a countervailing force.
The core hope of Dancing was to (a) untangle knots where that is possible, and (b) get some sort of legibility in maps to tangled to be read. The second ambition has never been entirely satisfactory in the sort of maps encountered with uninhibited linking. I have some ideas that may help; that’s why I plan to return to the topic.
Another thing that might be interesting would be to place the characters manually, lock them, and then use Dance to arrange the other notes. Stop, and then adjust the placement of the characters, and perhaps dance some more.
I had a quick try with the manual place, lock, then dance round and it looks as though it could be promising. I’ll play with it some more – it’s already better than the ‘pure dance’ approach for my purposes.