Tinderbox Forum

Struggling with Tinderbox and a suggestion

I agree and I am tinkering with the idea of making videos as I’m finding my way with Tinderbox.

Another question:

Using Tinderbox, I’m building a series of notes that take into account the history of electricity, communications and so on. I have people like (my great hero) Faraday in there, as a note, along with people like Clerk Maxwell and so on.

Looking back in time, I see that many of the early scientists, physicists, chemists etc wore more than one hat. So, what I would like to do is, when I devote a note to one of the greats, is label them (mathematician, physicist, astronomer etc). Now, many of these folk could be labelled as, say, a mathematician, a physicist and an astronomer. Even Newton was a bit of a alchemist as well as many other things.

So, I looked at making some kind of check box system where I could tick the boxes, physicist, astronomer and so on for each individual.

The idea is that, I could then search on astronomers, or mathematicians and even alchemists!

I’m looking at ways to do this in Tinderbox and wondered about an attribute for each discipline but I can’t see how I can put a series of checkboxes (as attributes) into each note. I notice there is a checkbox attribute but I am not sure how I could have more than one checkbox attribute in each note and then, how would I label it. I wondered about tags also.

I’m sure this is another one of those tasks which experienced users can do without thinking.

I’m taking careful notes when I find out how things work in Tinderbox (mainly because of a terrible memory) and I’ll continue to tinker with the idea of a video.


Oh, absolutely.

I would guess a lot of folks might not ‘get’ the point of attributes, since most note-taking apps don’t support them. And none to the extent Tinderbox does. So, I think of them like this: when I do hand-written notes, I’m always drawing links between notes, and side notes, and dates, and other bits. In the handwriting world, these are attributes. There are other metaphors describing ‘attribute’ – and I think it’s a good idea for anyone to eventually imagine how attributes relate to their notes and how the added information of attributes can enrich their note taking.

Of course, as Mark B. says, “everything is an attribute” – including tile and text.


Well, you could create user attributes for each of these disciplines. For example a $Physicist attribute, and and Alchemist** attribute, and so on. (I am using the common way of formally discussing attributes by prefixing their name with **.) Here’s a screen shot:

By making this custom attribute a “boolean” (it can be true or false, and nothing else) you get something that is a checkbox in the KeyAttribute list for a note. And you can add this attribute as a KeyAttribute for your prototype(s).

Maybe however you’re wondering why have all those checkboxes. Instead of a boolean attribute, you could create a set attribute. A set can have multiple values, separated by semicolons. So you could create a set attribute $OtherInterests and assign multiple side-interests to a note about a person.

So that’s two options – here’s how they look side by side. I wouldn’t do both in the same document, but you can mix and match.

Side note: personally, I prefer boolean / checkbox attributes over sets – but it doesn’t matter.

I think you’d be best off using a Set-type attribute. Sets are list that automatically de-dupe, i.e. each note can only hold one entry for that value. IOW, someone can be an 'physicist and ‘astronomer’ but neither of those more than once. In a List-type, the term ‘physicist’ could occur twice. Thus, in non-techie terms a Set is a de-duping List although both are ‘lists’, i.e. attribute that allow more than one discrete value per note. By contrast, a String attribute allows one value.

So if you set an attribute with the value ‘physicist’, depending on the data type the result is:

  • String: “physicist”
  • Set: “physicist”
  • List: “physicist”

Now set the value to ‘astronomer’ and the result is

  • String: “astronomer”
  • Set: “physicist;astronomer”
  • List: “physicist;astronomer”

The ‘;’ in the set and List is how this is displayed in Key attributes - the semi-colon is the value delimiter. Now is we set the value ‘physicist’ again we get:

  • String: “physicist”
  • Set: “physicist;astronomer”
  • List: “physicist;astronomer;physicist”

Note how the Set de-dupes the result.

To follow onto @PaulWalters’s excellent suggestions, here is a little more about the way that set attributes work, and how they might apply in your case – including through the magic of the Attribute Browser view.

Suppose you create a file where, among other things, you’re listing various prominent figures by their names. You then create a new set-type attribute called (for instance) Roles, where you will enter as many or as few identities as you’d like for each person:

Then as you add each new person to the list, you can add as many or few Roles as you’d like. For instance, Leonardo might have three and Newton four:

Within the grammar of the program, values in set-style attributes are separated by semicolons, as in “Painter; Polymath.” (Idiosyncratic spelling for “Mathematician” – sorry, was doing this in a rush.)

In the Outline view, shown above, I’ve added a column (via the View/Use Columns menu choice), so that I see each person’s roles next to his name. But if I use the Attribute Browser, I can see the people grouped instead by roles:

This very simple example, which took me less than three minutes to put together door-to-door, gives an idea of the open-ended configurability of things. You can have attributes for just about anything you want; you can display them in different colors and arrangements and sorting schemes; etc. But, crucially, you can start with something as simple as this and then build up.

Update Weirdly, probably because I was typing this entry at the same time, I didn’t see @mwra’s careful explanation of set-type attributes, immediately above, until just now. His explanation is obviously useful and right on the nature of sets in TB.


One strategy that has helped me to learn the mechanics of Tinderbox is to use it for things that have a clear objective. Like the other day, I was comparing some software packages. I dragged links to their home pages into Tinderbox to make notes for them. I know that price is a concern, so I made an attribute for that, and could easily compare them with attribute browser. I read the home pages and took notes on the things that interested me most, and any concerns I had… which helped me get a better understanding of the features that I wanted or needed. I made attributes to represent those features, and again was able to compare them in attribute browser. Agents helped me find the software packages that had all the features that I wanted, or ones that I hadn’t gotten answers on yet. Demoing the software helped me fill in the details.

Decision-making is just one use case where I find Tinderbox helpful… but it illustrates the concept of having a clear objective in mind. There’s an end-state to my Tinderbox usage in that scenario.

The example also demonstrates the incremental formalization concept discussed in The Tinderbox Way. When first getting started, I wrote my thoughts into the note $Text. After doing that a few times, I noticed patterns emerging – specifically, features that I wanted in the software. When I noticed those patterns, I added a bit more structure – the attributes. And finally agents are another form of structure that helped me visualize the information better.

Crucially, I was able to archive that document and not think about it again. If the software I purchased ends up a disappointment, I can always revisit my original notes. But I don’t have to spend any more time thinking about “how do I use this software effectively?” I had an objective, I accomplished it, and now it’s time to move on to the next thing.

That’s been my experience with it… I hope it helps others.


Good example, @pat.

Tinderbox sits in my dock. Clicking it and starting a new document is as reflexive as picking up a blank sheet of paper and a pen. I would guess 90% of my documents have the intent of what @pat describes above. The other 10% are longer-term hefty analyses or writing projects.

For small, purposeful projects,I have several templates stored in ~/Library/Application Support/Tinderbox/favorites – and I use these as starting points by picking one from Tinderbox > File > Open Favorites. For example, I have a starting-point template for task planning, another one for journaling. In these I’ve defined some standard attributes, agents, and export templates that I know I’ll need every time I do task planning or journaling.

That’s interesting… because it’s not that way for me. For whatever reason, I have this idea in my head that a Tinderbox file is “heavy”. I realize it takes almost no space on disk of course, so that’s not it. I’m not really sure where the idea comes from.

I think it has to do with the fact that I almost always save Tinderbox files in some folder, rather than in a DEVONthink database. And the more I use DEVONthink (7 years and counting), the more I hate saving things to a folder. I LOVE my DEVONthink databases… in particular how I can get a link to a record that always works, no matter where I move the record (as long as it stays in DEVONthink).

The idea of having a hundred Tinderbox files in a folder gives me anxiety… but I have no problem doing the same in DEVONthink. So, I know what I need to do :slight_smile:

Tinderbox as fast-and-easy as paper is a powerful metaphor…

1 Like

Oh, well. I have a lot of Tinderbox starting-point docs defined in DEVONthink’s ~/Library/Application Support/DEVONthink Pro Office/templates.noindex folder also – and I can get to starting points using Data > New from Template… in DEVONthink.

I store or index most Tinderbox documents in DEVONthink. So if I start one outside of DEVONthink it is always saved in a folder that is indexed in DEVONthink. And in DEVONthink it’s super easy to suck indexed documents into the database.

Got’cha coming and going :smile:


Nice yeah I think I’ve avoided TB documents in DT because it throws off the “see also” big time… and they can show up in search results a lot more than I’d like (there are a lot of words in that XML markup!). Though I just did a little test, and it doesn’t seem to be happening anymore… I wonder if DEVONtech changed how they index XML for “see also” purposes.

Anyway, there’s no harm in making a Tinderbox-specific database where I can archive those files… and I can put them in my main database to see what happens to “see also” / search, and move them out just as easily.

Thanks for the New from Template tip :slight_smile:

1 Like

I’ve struggled with Tinderbox for years. I’ve quit a few times but over the long run I’ve kept at it. I do think it’s possible to create an introductory course that could set new users on more fulfilling path (and sell more licenses) but who is going to pay for it? The economics of Tinderbox, as far as I can tell, don’t support hiring a contractor, and a volunteer effort would require an enormous commitment of time and energy.

So I’ve bowed to that reality and I carry on year by year, taking three steps forward for every two steps back.

You know what would really help, though? If someone was kind enough to put together a very basic beginner’s guide to Tinderbox coding’s vocabulary, logic, symbols, and syntax, all located in one easy to find place. I believe that would save newbies a lot of pain and bring a lot more people into the Tinderbox community.

1 Like

How about Getting Started With Tinderbox?

The Help menu includes two good tutorials “Getting Started with Tinderbox” and “Actions and Dashboards”, both in PDF form. Once open in Preview you can save them to disk to read in slow time without the app open if needs be.

Also, and though I’m not suggesting it’s written as a guide, rather a reference, but do look aTbRef does cover the above. A few starter places in it:

Edit: sorry for unintended duplication - I see @eastgate posted whilst i was replying.

Much as I have beat the drum for the value of learning this software in a case-by-case way, as opposed to the normal systematic approach most of us would instinctively take, it’s worth noting that the links above do provide quite a lot of top-down system view (especially Concepts) and extensive reference material. “Getting Started” also has a lot of illustrations with both conceptual-and-practical info.

In my own case, now that I feel I understand the general “feel” of the program, my usual approach is: figure out what I’d like to do in a certain case, try to do it, and then look in the reference charts (“List of action codes” / “Date format”) if I need to tweak the exact syntax. Or ask here.


Thank you everybody.

1 Like

I also recommend Stephen Zeoli’s video series on Tinderbox


Totally agree with this point. aTbRef is great for people who have a sufficient understanding of TB. It is an invaluable reference once one has a basic grip of the app. But, it is not the right place to start to learn TB. The “how” parts are missing.

Don’t try to learn TB from aTBRef!
aTBRef is a reference; not a textbook.

What helped me to get started with TB was primarily the “Getting started” guide. Then, some of the videos and Mark’s tutorials (he had somewhere…I don’t know where they are now: ); and Mark’s (and, recently Paul’s) replies in the forum. I have asked all my trivial questions. I always get wonderful replies.

So, for the beginners, please don’t hesitate to ask even the seemingly “trivial” questions.

1 Like

Some of them are here


Though last published before Tinderbox 6, the concepts are still fresh and useful, IMO.

Depends on how one learns, I suppose – most of what I know about Tinderbox came from aTbRef.

1 Like

Indeed! Also:

And some more I’m sure I’m forgetting at the moment. Update: and many are collected here: http://eastgate.com/Tinderbox/Screencasts.html


Just speaking personally, this is almost exactly what I was looking for:

Thanks for the advice, especially the nudge to go a little deeper into TBRef

1 Like