Tinderbox Forum

Increasing the size of note (proportionally) based on an attribute(s)?


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.

Thanks in advance

ps…I found this link and comments from Paul really helpful and insigtful. Measure the improving 'value' of a note

Font scaling sounds ugly. Why not use colour, e.g via varying $Color? Or a $Pattern, or basically anything but the the font?

The problem you face is $ReadCount only goes upwards - but what is the upper limit?

If you are happy to set the upper limit, then you have an answer. Otherwise, I see an eye-searing future ahead.

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:

$Width = 3 * log(2+$SelectionCount);
$Height=3 * log(2+$SelectionCount);
$MapTextSize=100 * log(2+$SelectionCount)


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)

Taking MarkB’s example:
$Width = 3 * log(2+$SelectionCount);
$Height=3 * log(2+$SelectionCount);
$MapTextSize=100 * log(2+$SelectionCount)

Question: How would I use an upper limit lets say with MarkB example above?
Range operator? If statement?


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:

if($Width<$MaxWidth("Upper Limits")){
   $Width = 3 * log(2+$SelectionCount);
if($Height<$MaxHeight("Upper Limits")){
   $Height= 3 * log(2+$SelectionCount);
if($MapTextSize<$MaxTextSize("Upper Limits")){
   $MapTextSize=100 * log(2+$SelectionCount);

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:

if($Width<$MaxWidth("Upper Limits")){
   $Width = 3 * log(2+$SelectionCount);
   if($Width>$MaxWidth("Upper Limits")){
      $Width=$MaxWidth("Upper Limits");

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:

   $Width = 3 * log(2+$SelectionCount);

I’m not sure if there’s some ternary expression to condense this logic.

Anyway, I’m not sure if this a quixotic task - I’ll post that in a separate reply.

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.

“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.”

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!)

Thanks again

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?”


“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. :slight_smile:

1 Like

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


and similarly for $Width! I’d still be inclined to use sqrt(log(2+$SelectionCount))

1 Like