I don’t believe anything different can be done with the Roadmap, at this time.
IIRC, having the view follow focus, as per the the Inspector has been raised so is on the ‘stack’ of feature requests but there’s no harm in raising it directly with Eastgate so they can gauge interest (there are always more requests that resource to make them).
Thank you for the clarification: I will follow your suggestion and will contact Eastgate directly about it.
The new hyperbolic view, which is still in development might be an answer to this issue. Essentially it is a visualisation of the document’s link network, eliding the hierarchy of the underlying outline.
I had indeed found this view mentioned in aTbRef, but no other details were provided other than it’s currently in Beta testing; I wondered what that view was, so thank you for the additional information. From your words, that view would be particularly useful for my work; I would be excited to test it, but I am sure I don’t qualify as Beta tester…
This next idea wants careful use, but you could make and name your own custom colours; they could even be the same colour as existing one. IOW, you could make a new colour that is the same visual colour as, for instance, ‘bright red’ but you might call your ‘point-two’ (I’d suggest not using numbers ). Now, the note would remain the same visual colour as above but is you use those new colour instead of the existing ones your AB view grouping would list groups like ‘point-two’ rather than ‘bright-red’. Whether you use different colour shades for these groups or simply use same colour but different name I leave as an exercise for the reader.
Thank you for the creative suggestion, which I have implemented in the attached file (“Latin Normalized Relative Note Order”; please see also the screenshot “Latin Normalized Relative Note Order - Attribute Browser View”) by adding new colors that have the same hex code as “white”, “poppy”, “orange”, “bright red”, “red” and “warm gray dark”, but that I called “albus”, “flavus”, “luteus”, “ruber”, “sanguineus” and “umbrosus”. I had to be creative with the name of the colors (e.g., I used “luteus” for “orange” as opposed to “aurantium”), and I used Latin to distinguish it from the language of the software (English) and to be politically correct (no-one speaks or writes in Latin on a daily basis anymore, so no-one can feel excluded by my choice). I realize the general usefulness of my implementation is questionable, and that to some it may seem nothing more than an exercise of wit, but I find it more useful than the original, so thank you for the inspiration.
Binning results by color is sometimes difficult to interpret unless the meaning of each color is immediately obvious. In this case I could imagine putting the file aside for awhile then coming back to it and not remembering what those colors denote. If I were doing this, I wouldn’t bin the results by color, I would do it by the word or phrase that denotes what that color means.
That red, orange, yellow and white visualize increasing quantities is immediately obvious to me (the black/red/orange/yellow/white and the black/blue/green/yellow/white are the two most commonly used look-up tables assigned to images to visualize signal levels, so they are engrained in my brain), but again I realize the general usefulness of that color scheme is questionable. Most important, however, your suggestion catalyzed the crystallization of why I had been feeling as if something was missing from the principle underlying the Relative Note Order.
I now think I have addressed this incompleteness in the attached file (“Latin Normalized Relative Note Order”; please see also the screenshot “Latin Normalized Relative Note Order - Map View”) by creating a new Attribute: the $NormalizedRelativeNoteOrder, which, by dividing the notes’ $RelativeNoteOrder by the $GreatestRelativeNoteOrder in the note network (calculated only in the Reference note “Greatest Relative Note Order”, to which the Prototype then refers), makes the Normalized Relative Note Order an absolute quantity, independent of the size and complexity of the note network, and therefore directly comparable across note networks of different size and complexity. Further, the $Normalized RelativeNoteOrder eliminates the need to define network-specific Relative Note Order intervals to which assign different colors. Instead, now, for all note networks, one can divide the 0-to-1 interval of the Normalized Relative Note Order into whatever quantities they find most informative and assign different colors to them, confident that these quantities will have the same meaning across networks: e.g., in any note network, an interval of 0.8-1.0 will always collect those notes with a Relative Note Order in the top 20% of the Relative Note Order. In my example, I have divided the 0-to-1 interval of the Normalized Relative Note Order into equal 20% intervals, but the intervals could be made smaller to increase resolution, or resolution could be specifically increased in a particularly informative part of the interval of the Normalized Relative Note Order; e.g., to increase resolution in the lower part of the interval: 0-0.05, 0.05-0.15, 0.15-0.30, 0.30-0.50, 0.50-0.75, 0.75-1 (but one could be much more sophisticated than that and use, for example, a Fibonacci series).
Once again, I thank you for your continuous patience, encouragement and support; I hope that in the (distant) future I will be able to help others as you helped me.
Latin Normalized Relative Note Order.tbx (70.7 KB)