I am interested in increasing the size of an original note based on the number of times I click or open a note as a proxy for my attention I pay a note. From a note structure perspective, I tend to keep my notes relatively flat in a folder (/Data) in order to visualize them more holistically in map view. Has anyone done something similar? I believe there are 2 attributes I can use: $ReadCount and/or $SelectionCount
I am getting stuck in how to incrementally and proportionally increase the size of an original note based on the increased number of time a note has been read or selected.
First, we probably do want limits, as Mark Anderson suggests.
Second, you might not want this to scale linearly. Something read 10 times is a quite different from something read 3 times, but something read 100 times is not very different from something read 93 times. So, Iād think about using log($SelectionCount).
Even this is a bit too extreme for my taste, so I might go for (say) log(2+$SelectionCount). For example:
Thank you to everyone for each of your valuable insights. This is going to be an interesting self experiment to explore my own question in evaluating how I value my own notes over time.
As was stated in the previous link, noted in my original question: āI think a āvalueā that becomes some kind of weighted ratio between attributes (# of links, # of reads, # of children, time from last modified etc) could make a great āvalueā.ā (so true)
Where am I am now?
I am now thinking, this āvalueā might be better as its own Key Attribute displayed in a display expression or use a range of this value to assign/represent its visual map property instead. In this example, an upper limit may be less important but still perhaps necessary.
Anyway, lets talk about the upper limit.
what is the upper limit ? (Great point MarkA)
Well the maximum might be the same, though likely not unless you want square notes and text scaling aligns well with icon size (Iāve not tested the latter). So, we can define three number-type attributes $MaxWidth, $MaxHeight, $MaxTextSize. Add a note to hold the assigned values of these āUpper Limitsā (other notes will reference this to fetch the max values). Set the three new attributes as KA in this note and assign your desired upper value. Now the above code could could be run like this:
Busy now so above is not tested. But the intent is the 3 attributes (height/width/text) can keep scaling until they exceed the limit. If you wanted to make sure the limit was never exceeded, yoād need another test, for example:
In each case the nesting is for clarity - the code will function if you remove the line breaks and indentation. Also, if you use a prototype for the notes using this code and make an edict in āUpper Limitsā set prototypeās limit attributes, these inherit, so simplifying the code:
Thank you MarkA for the detailed explanation AND code example. MUCH appreciated! It really helps me understand and apply the concept of āmax limitsā when I think of coding. Its an important concept I had not been using or even thinking about using in the past.
Interesting:
āAdd a note to hold the assigned values of these āUpper Limitsā (other notes will reference this to fetch the max values). Set the three new attributes as KA in this note and assign your desired upper value.ā
Question:
Would this be āconfiguration notesā MarkB refers to in the āThe Tinderbox Wayā ? (This will be the first time I will be applying this, great!)
I do wonder about this and how well it works. I tinkered around with trying to use $ReadCount and $SelectionCount a while back and found them less useful than I thought. This is not disparage the concept above or the appās affordance of these attributes. Rather, I found that counts didnāt quite work as Iād imagined.
Interestingly, testing now, it seems $ReadCount sits obstinately at zero. I think this is because it used to track (IIRC) when you opened a note window in the old (pre-v6) app. $SelectionCount was added in v4.5.0 (see) though I donāt recall why. $ReadCount was probably added at the same time, certainly after v4.2.5 (the cut-off for the first aTbRef (see). Aha, found as note $seq 1551 in the old appās Release Notes TBX. It states:
Two new, read-only numeric attributes, SelectionCount and ReadCount, track the number of times that a note has ever been selected and the number of times it has been opened in a text window.
These attribute could be useful for answering questions like,
āWhich references have I checked most often?ā
or
āWhich note inside Goals have I read least recently?ā
I also found an old email stating that $SelectionCount is intrinsic but $ReadCount is not. This makes sense as an alias can have its own selection count, but opening a text window (pre-v6) opens the same (text) object whether called from an original or an alias. As selecting a note in v6+ also shows the selected notes text āwindowā in the text pane, $ReadCount is essentially moribund (yes - Iāve tested, opening a stand-alone text window in v8 does not increment $ReadCount.
The problem I encountered is that it is far too easy to select a note by accident. A selection can occur in in any view/tab and, for example, using the arrow key to move up or down an outline counts as a selection as the cursor indexes through any given note. Selecting a note to move it on the map adds to $SelectionCount. By comparison, my intuited concept was the attribute stored the number of times Iād deliberately selected/viewed that noteāwhich is not what is recorded.
I donāt blame the app. It canāt guess why a note is selected, only that it has been. Thus the exercise further above using $SelectionCount to size notes may prove less fruitful than imagined.
I believe so. Actually, given that we are using a specific (user) attribute, you could just set the value in the āDefaultā box in the Document Inspectorās User tab and then all notes inherit the value without needing the other methods I mentioned. But if for some reason you wanted a different max value (for the same attribute, e.g. $MaxWidth) in different areas such as different maps, that you would want to use two discrete configuration notes.
Separately, do consider the effect of lots of notes all running this re-sizing as a rule. The bigger your map(s) the more notes are constantly re-sizing themselves. Given my point in my previous replay about accidental vs. deliberate selection each time you ātouchā a note it will re-size. I canāt find my old experiments in this area (they were back in the old app anyway). But, as I recall, I found the āaccidentalā selections made the metric less useful than Iād imagined. But, donāt let me put you off.
In Storyspace you could use the OnVisit method to update the note appearance each time itās visited.
$ReadCount is no longer supported and will be removed. (In earlier Tinderbox versions, you had to open a separate text window to see the noteās text, and so $ReadCount and $SelectionCount were distinct.)
Iām not sure the performance problem that worries Mark Anderson will be an issue. Were it to be, we could avoid that by adding an $OnSelection method. But letās not borrow trouble before it comes to us; itās quite possible that (a) performance will be fine in practice, and (b) we might want to do this differently anyway.
Oh ā and by the way: if youāre increasing both the height and the width of the note, you probably want the area of the note to be proportional to the $SelectionCount! So
$Height=sqrt($SelectionCount)
and similarly for $Width! Iād still be inclined to use sqrt(log(2+$SelectionCount))