Okay. Suppose that this month I write an article about the copper indium gallium diselenide phase diagram (CIGS, for short. It’s used in advanced solar cells.) In connection with that article, I accumulate notes from interviews, notes from technical papers, and “new” notes based on my own analysis.
Then, six months from now, I want to write a longer report about advanced solar cells, and want to refer back to my notes from the article on CIGS.
So there are a couple of questions:
What’s the best way to structure the notes in the first place, when I create them? Tagging seems like the obvious answer, but is there a way to automatically tag notes as they’re created? Tagging has never worked for me because of the data entry involved, and because tags are useless unless you use them consistently. So does Tinderbox have anything like Scrivener’s keyword display, or some other way to see which tags/keywords have already been used?
In the best of all possible worlds, retrieval would be through something as smart as DTP’s AI. I’d be able to pull up more recent notes and ask the database for “things like this.” Alternatively, I’d start by finding all notes related to CIGS, and then manipulating them/further refining the search to figure out which ones are relevant to the new project. How?
And finally, a meta-question. I don’t want to turn the Scrivener forum into a Tinderbox support forum (and thank you to our host for indulging this thread this far…), but I’ve really been somewhat lost in the Tinderbox support areas. Is there a mechanism by which I can say here is a sample note file, and this is what I’m trying to accomplish, and get fairly precise guidance? Because while the Tinderbox wiki provides an enormous amount of information, I’d really rather not have to teach myself a programming language in order to accomplish this kind of task.
For someone who wants to learn how to survive the shallow end of Tinderbox first, would Eastgate’s related offering, Twig, serve as a good beginner’s course?
It would probably help. Twig has a nice note-finder-builder front end that makes searching a little easier. It dispenses with several views, but maintains the outline and map views, which to my thinking are the most important. It’s main drawback, as I see it, is its limited export capabilities.
Create a user attribute called “Tags” or whatever you want to call it. Make it of type “set”. A “set” attribute can have a whole number of different values, as many as you like. You separate them by semicolons. In this case you’ll be using CIGS as one of the tags. (A notes Tags could be, for example, <CIGS;dogfood;Martians;cucumber>.
You can then create a prototype, which is just an ordinary note with various attributes which are set as you please. It’s like a template document in Scrivener, but much more powerful. You can turn any note into a prototype by selecting it, hitting , then checking the Prototype box. Let’s call this one *CIGS. (Many of us preface prototype names with * or, say Proto-, just to make them easier to find)
For the CIGS notes, you can drop them all into a container (which is just a note that contains other notes) whose On Add… box says <$Prototype = “*CIGSnote”>. Anything you drop into that container (or add as children to it in the Outline view) takes *CIGSnote as its template. Anything you do to *CIGSnote will be reflected in those notes which have it as their parent. So if you set *CIGSnote to have the tag “CIGS” anything which uses it as prototype will have that tag.
If you set a “Key Attribute” to be Tags, you’ll always be able to see what tags a note has. And there’s a drop-down menu by that field which automatically populates with tags as you create them on the fly.
The crucial thing about Tinderbox is that phrase “on the fly”. It’s the exact opposite of a database app. You can start off with completely unstructured information and structure it as you go. Your file is one big XML file so you will eventually take a performance hit but I’ve not got there yet. (Huge complex files will take a little longer to load, but once loaden, you’re away).
Window>Similar Notes. Though there’s some overlap here with DevonThink. If you want notes you’ve tagged with CIGS, just set up an Agent to look for them. Note>Create Agent, then set the agent (which will collect ALIASES of all the notes that meet its criteria) to do whatever you like – move them, turn them bright red (<$Color = “bright red”>), whatever.
Agents can be quite complicated. Start slowly and work up. A useful compendium, oddly, is Help>Release Notes. EVERYTHING is in there.
Of course that’s only one way of doing it. Another would be to make a “Stamp” whose action was <$Tags = +“CIGS”> which will ADD the tag to the Tags attribute of whatever note you apply it to.
I agree the Tinderbox support materials are a bit widely=disseminated. It’s worth spending a few $ on Mark Bernstein’s The Tinderbox Way, which is a super overview of how the thing works and the bet mindset for getting the most out of it. And whenever I’ve hit a brick wall I’ve just emailed (tinderbox AT eastgate DOT com) and Mark has got back within an hour or two. But I tend to reserve that for major problems.
The one thing I have found with Tinderbox is it’s one of those things which really does repay constant use. If you keep your chops in, it’s like a musical instrument – it becomes an extension of yourself. If you only fish it out once in a blue moon, you find you’ve slipped back down the curve again each time.
The other thing is that it is, in a sense, a programming language, albeit at a very high level. Perhaps better to call it an “environment”. Once you grok the crucial things – notes, prototypes, agents and rules – and how they interact, everything, of course, becomes much easier.
Oh - and linking to DevonThink source notes is easy. Just set your Tinderbox default “key attributes” – the ones you see at the top of the Text View – to include URL.
(1) Select the note in DevonThink.
(2) Right-click on the note and Copy Item Link or ctrl-alt-cmd-c
(3) Paste that into the URL attribute of the relevant Tinderbox note.
Then you can open the DevonThink original just byt clicking on the URL button in the Tinderbox note. (It would be nice if DevonThink sent its item and its x-link via drag-and-drop but it doesn’t at the moment.)
I hope this is of some help. Like everything else computish, it looks much more complex & impenetrable than it is.
(3)
I didn’t know the Similar Notes feature even existed, and it’s amazingly useful. (Bangs head against wall.) I think it may be new since I first started trying to make sense of Tinderbox.
I’ve read the Tinderbox Way. It was helpful, but at least the version I have (2006) has fallen rather far behind what the interface actually looks like now.
You’re absolutely right about how Tinderbox repays constant use. Unfortunately, there’s only so much time available to devote to a tool that – at my current level of understanding – creates more problems than it solves.
A vicious circle… I was lucky in that I had a l-o-n-g deadline for the project I first used Tinderbox on. Not something I’d learn in a scramble, I think. But one of the other posters on this thread said “Keep a map window open and use it as a jotter” and I think that’s a fine idea. Get used to The Beast’s presence in your lair and it will slowly be tamed…
Interesting to see that I’m not the only one who struggled with Tinderbox.
Just over a month ago I went looking for software that could help me with writing. Over a weekend, I downloaded trial versions of Scrivener, Curio, and Tinderbox.
Scrivener and Curio both came with excellent documentation, and a tutorial project so that you could be learning the app at the same time as actually running it. And both had a full, clear manual I could refer to when I needed more info. In short, however much I needed to learn, I could see a clear path through the forest and felt confident I could become reasonably proficient, reasonably quickly.
I bought Scrivener and I’ll be buying Curio when its 60-day trial finally expires.
My experience with Tinderbox was very different. Yes, there’s documentation, and yes, there’s an introductory file, but to me, it felt less like a piece of software I could use out of the box, and more like an invitation to a computer programming hobby, with no indication of how much time and effort I’d have to invest to get usable results. But I wasn’t looking for a new hobby. I was looking for something to help with my existing ones.
Of course, the reason Tinderbox is harder to learn could just be down to its power, but to me that’s an argument for more documentation/tutorial material, not less.
Believe me, I’m not trying to bash Tinderbox. I’m sure it’s a really useful product, but it certainly feels as though the developers have fallen at the final hurdle - showing us how to use it. I’d actually love to buy it (with or without the discount), but software junky though I am, even I can’t justify its purchase at the moment. A real pity.
It’s not my intention to convince anyone they should buy Tinderbox; I want to make this clear up front.
However, it is a really remarkable application and I just want to make sure that anyone giving up on Tinderbox have a good idea about what it is they are abandoning. If you haven’t seen them already, I have a series of posts about Tinderbox on my blog. You can access an index of these here:
Nor ours, but we agree - it’s a great application, and we were really happy to be able to offer our users $90 off a well-established, popular and fantastic Mac application. I’ll be moving this thread to the “Software by Other Folk” forum soon, but I’ll leave it here temporarily.
Just a note to say thanks to Brookter, et al, for your thoughtful and considered responses. I’ve learned a lot–including the fact that my feelings and fears about TB are shared by many. There’s another forum on Tinderbox here: https://forum.literatureandlatte.com/t/tinderbox/572/1 , in which many current ex-users of Tinderbox express similar sentiments. But these are always countered by enough comments from current ex-ex-users who have chosen to try it again that I have decided to bite the bullet and do likewise. (Plus, I’m a sucker for a sale, and I’ve been intrigued by TB since first experimenting with it.) Wish me luck–I actually have some ideas I’m going to try to sort out on it.
Just a quick point: it’s possible (but of course, not straightforward) to import tags from Devonthink documents into Tinderbox notes, along with an automatic back reference to the DTP document. (NB: I only use if for text documents and it only produces plain text notes in Tinderbox)
I do it by hacking the ‘Listing…’ script from the Scripts/Export menus to add the tags, enclosed by & and the DTP link by & . I also insert ‘@@@’ before each new document in the listing.
You use the script on selected documents, then drag and drop the resulting file from Finder into Tinderbox, creating a single note. You then use the ‘Notes/Explode’ command, Break at Paragraph, Delimiter set to @@@ (and delete delimiter checked) and Title set to First Paragraph.
This will create new notes, one per DTP document. You then run a couple of agents, which parse the notes text to strip out the tags and DTP link and put them into user-defined attributes.
(NB: RSS doesn’t show the code properly, but it’s OK in the forum itself)
The relevant code for tags is:
(in the Agent ‘Query’ field)
Text((<tg>)(.+)(</tg>))
(in the Agent ‘Action’ field)
Tags = $2
And for DTP links:
(in the Agent ‘Query’ field)
Text((<ln>)(.+)(</ln>))
(in the Agent ‘Action’ field)
URL = $2
Yes, it’s a very clunky procedure, but it works after its own fashion.
Given how much easier DTP is to work with for collecting, maintaining and classifying documents, I don’t think I’d be tempted to do any more than the graphical manipulation and outlining of selected documents in Tinderbox for a specific project (rather than trying to look back through old Tinderbox documents to use it as an notes archive). Although I haven’t done this yet, you can export your finished projects back into DTP (as well as onwards to Scrivener) for such archive purposes.
If you want any more details on the DTP > TBX flow, let me know (as long as you promise not to laugh at how bad my applescripting skills are…)
First, you have the two or three pages of notes that I take while actually conducting an interview. That’s a primary source document and lives forever in DevonThink Pro, no question.
My interest in Tinderbox has to do with a different kind of note: the one or two sentences that I scribble on an index card and shuffle around as I’m developing an article or chapter. The as-yet-unrealized fantasy is that doing this shuffling in Tinderbox, instead of on paper, will allow me to look at “cards” for previous projects, with an eye to finding the telling detail or interesting anecdote that may not have fit in the previous project, or that might provide a conceptual link between the old project and the new one.
That’s exactly what the Tinderbox and Twig map views have in mind. Here’s a detail of a map for a fictitious legal investigation, written to demonstrate some of these techniques to lawyers and their investigative assistants. Of course, much the same techniques are useful when concocting fiction.
Fair enough… I thought you could use something similar to my suggestion to combine the two forms of notes in Tinderbox, otherwise you’re balancing two not-quite-complete views on the data. This may not be a problem for you.
By the way, in case you weren’t aware, you can also copy and paste any text (from DTP or elsewhere of course) into a map or outline in Tinderbox and it will create a note with the title and content both set to the copied text. You can then attach a prototype it and tag the note as Michael suggests. In fact, if you select the CIGS container before pasting, it will add the new note as a sub-note to that container and add the prototype and tag automatically.
Generally speaking, I’ve found that it’s easier to leave the primary source materials in DTP, and do most of my organizing and writing without referring to them. I check facts and sources toward the end – and for that reason my notecards need to have source information – but I’m a much better writer than most of the sources I use. I don’t need to cut and paste big chunks of direct quotation so much as to paraphrase into my own words.
I don’t want to make this a TB support forum, but I am curious: If you drag a bunch of notes into a container to get the prototype attributes, will they retain those attributes if you then drag them out of that container?
Yes, as far as I know (meaning, there may be specific scenarios when it doesn’t (e.g for certain attributes), but that this is the expected normal behaviour). Of course, if you were to move it to another container whose OnAdd action was also to change those same attributes, then that would be different.
[However, I think there is also a way to override that and make sure that an attribute is only set automatically once: I can’t bring it to mind just at the moment, but it’s something like $Color |= blue, (i.e. use |= instead of just = ) which only changes the attribute if it’s not already been set.]
Yup, attributes once changed (either by you specifically, or some routine in the Tb file) are sticky.
The way it works is like this, where items lower on the list take precedence:
Document defaults
Prototype settings
Note settings
So if an OnAdd changes the colour of a note that was already defined by a prototype, the modified colour will be sticky no matter where you drag it (unless, as David points out, you change it again either directly or indirectly). Meanwhile anything else the prototype defines will remain inherited by the note, and anything not declared by the prototype will use the document defaults (which can be set in the System tab of the Attributes palette).
To reset attributes so that they use a setting from higher in the precedence chain, you can either use QuickStamp and the Default button, likewise in the note info palette, or procedurally by setting the attribute to “$Color=;” in an OnAdd or other similar place. This is useful if you have an agent setting a special badge, say a high priority badge. When the item ceases to be high priority, you can reset its $Badge attribute back to default and it will revert to whatever the prototype uses, or nothing which is the system default.
System defaults are a good concept to learn. You can do a lot of global customisation to a Tb document there, and since all notes use this order of precedence to determine their attributes, anything not set to something via prototypes or the note itself will instantly change throughout the document. Likewise a prototype change will impact all notes that do not specifically declare an exception.
The |= operation is indeed what you want if your OnAdd should be “polite” about changing things. This simply checks for whether or not the note itself has an exception. If it does, the assignment does not happen. If it is inheriting in any way, the OnAdd will set an exception for the note.
Same goes for Rules and Stamps and all that, too. OnAdd is just being used as an example here.
One final note, and that is that this chain of precedence works for prototypes, too. Prototypes assigned to other prototypes will inherit their values, or create exceptions, but to notes assigned to secondary prototype, all of these exceptions will appear as level 2 inheritance. Chaining together prototypes of a kind is a valuable way of working. I like to have one note called “Prototypes” which is a container for prototypes, but all prototypes I create are assigned to the Prototypes note. This way I can globally change all attributes of all notes using prototypes from this one note—so long as there are no exceptions in the downstream of course. It’s a way of having a secondary “system default”.
