Thanks. I think a challenge here, reflecting on my own research, is that it is rarely the same twice. I’ve come, mainly through long use, to understand the ‘toolbox’ aspect of Tinderbox. IOW, it can do what I want, perhaps not exactly in the way I first imagined, but I have to figure out the subset/order of tools to use. As most software offer a reward for correct input/process, we are unwittingly trained to expect a different approach: IOW what it the right button to push, right way to feed the process.
Also, when it comes to text, we are generally over-trained to the paper model (mainly via word processors): start at the top left corner and write a single long narrative. Some apps like Scrivener deliberately subvert that with its outline. Tinderbox takes things further. If we embrace the notion of many small pieces, Tinderbox shines. Reflecting, many threads about previewing, composite note preview, etc., show how deeply ingrained as the ‘norm’ and we push back against any different approach. I’ve pushed through that—I know as being asked/forced to use a word Processor (Word, Google Docs, etc.) leaves me unhappy if the work is anything but short/trivial. I prefer the hypertextual approach: write what I need in modular form, link/arrange as necessary, oultput/render as needed for the task at hand.
The toolbox approach dovetails with understanding of the tools and there I sense you have a head start as your experience of programming (or programmable text editors) means much of the action code operators should not seem too alien.
So perhaps the missing part is some tutorials that open up the interplay between task, tools selection and ‘process’ definition. It definitely helps to read up on what the view/text panes offer before planning what we want to see. Again, questions here often arise because people are working to imagined view/render rather than one the Tinderbox toolbox actually offers. Embracing the latter pays dividends. The genesis of many of the aTbref articles has me been figuring out the reality of the description of a feature in terms of how it works/is user-configured.
Another aspect overlooked, for research/writing is the body text vs metadata (attribute value) balance. If coming from a long-form text perspective, everything is in the narrative perhaps with footnotes and references. But, especially if doing quantitative work† getting a feel for what belongs in $Text as opposed to being extract into attributes, links, etc. (or in both) is another useful aspect of learning the tool.
The forum is, I think useful in this regard. Tinderbox users, often new, arrive with problems and preconceptions. Discussion of the problem and how to approach it often ends up with one of more solutions offered—often as a TBX—and these threads/files, if unwittingly dig into the above. Does the envisaged approach to the task make sense, is the final view/export possible or sensible in Tinderbox but might an alternate route be possible, are the most appropriate tools/views being used, etc.?
It might be that files/discussions in past threads might be a seed for the examples being made.
†. I don’t mean formal qualitative work, with its theatre of ‘method’ (fill in the boxes exactly correctly or else…), but real exploratory qualitative work, measuring emergent knowledge.