I concur with @JFallows’ excellent suggestions. If still getting your head around prototypes and inheritance, see my page of demos - here. Those marked for v6 should be fine for v8. Most pertinent are those on Inheritance in Tinderbox and how to set prototypes.
One slight divergence from the above is that I generally let Tinderbox create its default containers for prototypes/template/composite as needed for that document (which happens if you add such features via the File menu). As Tinderbox creates those a root level I tend to leave them there rather than move them. Either way, I think a key useful move is to put all your notes/data/content - i.e. the ‘real’ information, under a single root container as @JFallows explains above.
There’s no one ‘right’ way to learn which bits of the app are of use to you. However, I think understanding Tinderbox’s inheritance and prototypes help make a lot of other things, such as Key Attributes, make more sense when used.
Tinderbox’s power is as an exploratory tool, which lets you add formalisation (structure) as you uncover it or find a need. Unlike a utility app it doesn’t do just one thing - it’s a toolbox. Unlike a database, you don’t have to define every field (attribute) you may need before you start. You’ll see other folk here talking about using other features and doing things unrelated to your project. This is normal and to be expected. Very few people need to use every tool in this box.
The temptation is to experiment in your main work file but this tends to pile up cruft and at a point in one’s Tinderbox experience that it’s harder to spot and clean out. This is why you’ll see experienced users here recommending you try new ideas/techniques in a small test file. That way, you can figure out what you need, implement that cleanly in your real work file(s) and throw away the messy test document.
Also, until you know your way around the app, more ‘data’ is not always a help. Generally for tests it helps to have minimal test data so you can see errors if they occur. For task with agent queries or query based actions like
if(), you want an intended match, an intended non-match and in some cases a likely false-positive match and likely false-negative match; with just 4 notes you cover all bases on a logic front. Of course the more complex the query (e.g. multiple query terms), you may need more notes to cover all variants of those 4 cases point the underlying point still holds true.
Sorry for the long post, I’m just about to start travelling to Hof for the Hypertext 2019 Conference, so may be away from the forum for a short while.