When I’ve been frustrated with Tinderbox in the past, people have advised me to start small, with a relatively tractable project and specific questions. So here I am. This is, at some level, a “toy” project, requiring not much more organization than scribbling on a napkin. From tiny acorns, etc.
I have a couple of dozen notes, drawn from research materials for an article I’m working on. I captured technical papers in Devonthink, took notes using Scrivener, and have now imported those notes into Tinderbox. If Tinderbox didn’t exist, the next step would be to review them, jot the key ideas down in a Scapple board, and shuffle them around until I had the beginnings of an outline for the article.
Tinderbox’s Map View seems like the obvious analog to that process. It’s appealing in part because it doesn’t require wading into agents and attributes, but on the other hand if I’m not going to use Tinderbox’s key features, why am I here? What would you all suggest?
Here is what I would do, with the stipulation that use of this program is highly idiosyncratic and personalized, which is the strength of the software.
I would create a prototype for each of the ideas or notes you want to enter into the program. Let’s call that prototype Entries (or Notes or Ideas or whatever). [See note below]
I would create a couple of User attributes – and make them “Key Attributes” for that prototype. (So that the entries you create will all have those attributes.) For instance: Source, if there are variety of sources you want to keep track of. (Like: “Smith interview” “Bailyn book” “Atlantic article” etc. ) And Theme – the ideas by which you want to classify each of the notes or entries. (Like, “We are all doomed,” or “Doom, chances of” or “Actually there’s hope” and so on. These can be single words or phrases. I’ll save for later the diff between making these “Set” or “String” attributes. Important to note that you can assign multiple values to any one item.) Or Section – like “Intro,” “Conclusion,” “Part One,” “TBD” etc. Or Heat Factor – “Hot,” “Medium,” “Marginal,” etc.
It’s important to realize that these are just about infinitely adjustable. You can add an attribute if you think it might be useful; delete it if it’s not; change its phrasing and values; and so on.
I would go to Outline view, and use Add Columns. Then, as you enter each note, you can see, spreadsheet style, ways to add these various categorizing details.
Then – the real payoff from my POV – I would go to the Attribute Browser, and be able to see the information grouped by any of the criteria you’ve entered. There is a long string you can read, here, with lots of screen shots of what this looks like.
There are people who use Map view to organize / link ideas and views. I use the Map view occasionally, for large-scale planning – but for categorizing ideas and laying out articles and books, I find the Attribute Browser a complete godsend,
Next steps, over to you!
[Note about prototypes: I’d create a container/ top-level outline entry called something like “Ideas” or “Entries” or “Data”. Then I would create an “Action” for that container, to make sure that every new item that you create there will have the desired prototype. Eg, the Action would be something like $Prototype="Ideas" ]
I created the notes by dragging Scrivener documents into Tinderbox and exploding them. Tinderbox very helpfully created an ExplodedNotes prototype for me, and put the fragments into explodednotes containers. I created Source and Theme Attributes, and made them Key Attributes for this prototype. The explodednotes containers duly inherited them. Success!
But the individual fragment notes did not, and do not seem to have any prototype assigned. I can figure out how to assign the prototype to an individual note, but not how to bulk-assign it to multiple notes at once. Is this a job for the “Entries” container that @JFallows suggested?
This is all in the basic-cookbook stage, but a few steps to try.
The first screenshot shows a simple way of organization a data file. I always do so with two top-level outline categories/containers: DATA, and SYSTEM. DATA has all the actual “substance” info. SYSTEM has all the plumbing of the file – prototypes and the like.
You’ll see that “Parent Container,” which I have selected, has something shown as an Action setting. What this means is that any note you enter within this container / folder / level of the hierarchy, will have a specific action applied to it. As shown, the action is assigning the relevant prototype. The “First child entry” etc will have that prototype assigned.
Again, everything entered in “Parent Container” will have the “*Entries” prototype. (I put * at the start of all prototype names, as a cue.)
The second screen shot shows the way you can add attributes to this prototype – and once you’ve added them to the prototype, they appear in all the notes that share that prototype. The arrows go from the attributes, to the prototype and also notes sharing that prototype.
I think if you prowl around trying the simplest things – how do I create an attribute? How do I create a prototype? How do I get the prototype automatically assigned to new notes – you’ll have the learning-by-doing breakthrough.
The “Action” box accepts any action code, and the action code to use to assign a prototype (as it would be in an agent) is:
$Prototype="protoNote"
“protoNote” is just an example – use the prototype name that exists in your file. (If you don’t have a prototype, create it before using Explode.) The action box offers to autocomplete prototype names, or you can type it.
Once the note is exploded, all the child notes of “Exploded Notes” will have the prototype you assigned in the action box of the Explode pop-over.
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 collect() or 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.
There are some great suggestions here already but I have a suggestion that comes from a different angle.
You write:
I take this to mean that you already have a process that makes sense to you and that allows you to do your work. My suggestion would be to consider using Tinderbox maps simply as a scrapple replacement for this article without looking for added value (but all the while experimenting with the suggestions above as you work).
Once you are done with this article the pay-off will begin. The TBX you’ve made will continue to be “live” in a way a Scrapple doc likely isn’t. You can then use the same TBX for the next related article. My guess is that it’s at this point that the ability of TBX to make legible complicated connections between materials will become clearer. You’ll also likely begin to see how your notes on your subject could take on a shape of their own and that this shape may be (very?) different from how you might organize parts of your notes into an article or some other specific “work.”
In my own experience, it’s at this point where the organization of my notes pulls apart from the organization of what I want to do with my notes in a particular moment that TBX has proven useful. (I think of TBX less as a step in the process of making a thing than about figuring out and understanding the thing I’m going to make something about. This means my TBX files are usually a mess and change continually. But that mess is usually pretty useful.)
Thank you all for your helpful suggestions. Managing Attributes effectively – which means making good use of Prototypes and inheritance – seems to me to be somewhat critical to whatever value Tinderbox might add beyond other tools, so that’s where I’m starting.
Does anyone know if it’s possible to extend the trial beyond the 30 note limit? When I hit the trial limit in my past experimentation with Tinderbox I reverted to an older version for which I had a license, but that version is now back level enough to be a source of frustration in itself.
I know that Mark Bernstein is traveling, but suggest in any case writing him at Eastgate with your request, since licensing and funds are handled offline.
I don’t know the answer to that, or any other commercial questions.
One man’s opinion: An extended “trial” is not going to tell you much beyond what you know already, or what you can guess and glean from this series of detailed comments and suggestions. The software is extremely powerful, continually evolving and being upgraded, but gradual in revealing the ways in which its powers suit each individual’s tastes and needs.
I recognize that it is significantly more expensive than many other apps. But for me, over the past dozen years, it’s been very significantly worth the annual upgrade costs. (You can use any given version forever, but to get updated releases, you need a current subscription.)
I’m saying that I don’t think a “trial” is going to be revealing, one way or another. Getting the current version is an investment/leap-of-faith, which at least for me has been highly worthwhile.
I created a note in Scrivener, called Smith2019 to denote an interview with Mr. Smith. I import that note into Tinderbox and assign “Smith2019” as the Source attribute.
a) If I explode the note, will the fragments inherit that attribute?
b) If I need to change it later, or if I forget to assign it in the first place, what’s the easiest way to assign it for multiple notes at once.
As far as I know, the tutorial limit is fixed to 30 new notes, but all app function as are available. I’m not sure if agent aliases count as new notes (my hunch is that they aren’t). However, I believe you can open existing documents with 30 notes so you can look at larger docs. As suggested above, I’d email Eastgate about this. I think Mark gets here to Hof tonight so will probably catch email tomorrow (Europe Tuesday), if not before.
Not automatically, but the tools exists to do this. Why not ‘just’ automatically? Remember this is a ‘toolbox’ thus used in many different ways. That means some assembly is (deliberately) required for some processes but to the betterment of your eventual workflow.
Here is one way to do this. One the Explode dialog, set the ‘Action’ box to this code:
This sets the OnAdd action applied to each newly-exploded note. These are created in a ‘exploded notes’ folder under the source. So, the new notes are grand-children of the note being exploded.
There is no one right way. If only a few notes, you could select them all and use quickstamp (which only changes one attribute at a time, or use a stamp. Or you could use and agent action, or a rule, or etc…
Is there a way to glue pieces of an exploded note back together or, more generally, to merge two notes? Apparently numbered lists confuse the exploder.
Is there a way to combine the AttributeBrowser and Map functions?
Specifically, I now have a bunch of notes with assigned Source and Theme attributes scattered around in a Map view. I’d like to be able – without otherwise changing the map – to temporarily highlight all of the notes derived from a particular Source. I know I can do permanent color changes with an Agent, but that’s not what I’m looking for in this case.
As the problem arises from the Explode, let’s deal with that first. By default, Explode splits on text paragraphs, i.e. every line break. A list item is a paragraph, albeit differently formatted in rich text. The issue here is you are assuming how Explode works. Without more information, e.g. sample text, it’s harder to give more information.
‘Merging’? I think the way I would do this is to make a stamp with the code:
$Text = $Text + "\n" + $Text(nextSibling);
Now:
Select the note into which you want to merge the bullet notes.
Run the above stamp.
Check the original note’s text.
If merged correctly, delete the merged note, and reselect the original note.
Repeat the above process until all the bullets are merged into the correct note.
Assumption: the default Explode settings are used for the initial explode.
Selections in Attribute Browser tabs are not reflected in a Map view tab in the same doc (for valid reasons not germane here).
Selection is not controlled by action code, so there is thus no command for what you want. A sensible approach might be to make and agent, query-scoped to the that map, whose agent sets some visible parameter that might act as a visible. Change the agent action to remove the additional visual markers.
So this is less a selection issue than a visual filter. I sense this is probably a feature request to make of Eastgate, but I’ll leave that to you as you need to articulate the nuances. Feature requests can’t be made here as this is a user-to-user forum. Email your request direct to Eastgate.
Notice too that, if you select a group of notes, the text of those notes will appear together in the text pane. You can copy the combined text and paste that into a new note, if you like.
No problem. If you are comfortable with regular expressions, they make Explode a lot more flexible. If you control the generation of the source text, consider putting a string like ‘#####’ between each source note - i.e. a string that won’t turn up in the source text and which you can use as a marker for Explode.
Okay. After some fun with the Import and Explode commands, I have a bunch of Scrivener notes broken down into a larger number of Tinderbox notes. I’ve clustered the notes together by theme, using the Map view, then drawn an Adornment underneath each cluster. I used QuickStamps to assign the appropriate Theme attribute to all the notes on each Adornment.
(Presumably there’s a way to do this with Agents, but I didn’t want to take the time to figure it out. Adding an OnAdd Action to an Adornment doesn’t work if you put the Adornment under existing notes rather than dragging notes to an existing Adornment.)
(Why am I doing this “backwards?” Because the Themes emerge from the notes, not the other way around. I don’t know what the Themes are until after I cluster the notes together.)
Assigning Themes let me use the Attribute Browser to look at each cluster in more detail. So the next step would be to rearrange the notes in each Theme so that they’re in something like the order I’ll use in the article. But rearranging notes doesn’t seem to be possible in the Attribute Browser?
Am I missing something? I figured out how to make a composite RTF document from all the notes in a Theme, which means I can move back to Scrivener at this point if necessary. (Much more easily than the last time I tried Tinderbox, so I’m a happy camper.) But is it really necessary?
Is it possible to turn an Adornment into a Container? Or to put all the notes with a single Theme into a Container? Because I know how to rearrange things in Outline view.
