Tinderbox Forum

One Big Tinderbox Document?

I’m of the multiple file approach. As I do a lot of testing, I generally don’t want the kitty-litter of older abandoned experiments cluttering up the current project. Plus, the project rarely have little overlap. In the past I used a ‘starter’ stationery file as the start of projects but do so less now as much of what took a little building per-file is now built-in and rapidly added if needed (as opposed to weeding out potential scaffolding I didn’t now need). The choice of a new file is dependent on the content/purpose rather than the scope or longevity of the project.

I can see the use of a single encompassing day-book or task tracker, for those whose work is more of that pattern. If you’re writing a book, likely you only want one TBX; two books, then it’s a matter of choice. There really is no one-size-fits all rules as to the ‘correct’ number of TBXs.

An edge case is testing new code or layout. For this I advocate small new files with the intention of deletion once the testing is resolved and having implemented the solution in your actual working file(s).

1 Like

I’ve waffled on this many times over the years, and have finally landed on the multiple-document approach.

I work with dozens of projects for dozens of clients. Some are short-term, some have lingered for years. I find that creating a fresh Tinderbox document from my template each time feels good. Like Mark A. said, less kitty-litter. The isolation also seems to help me focus on the task at hand.

There are downsides, though. For example, when I find a clever new trick and apply it to my latest project’s document, none of the existing documents reap the same benefit. I do a lot of copy/pasting of agents, prototypes, etc. I also have to make sure to update my template for next time!

Another downside is not being able to link/find/gather everything all at once. I sometimes miss that but cross-pollination between projects for me is minimal, so it’s not a big problem.

It may depend upon on the types of projects one deals with. For me, using one document per project has turned out to be the best strategy.

1 Like

Some good points. I echo the frustration of finding a fix and then thinking how many other (active) project files would benefit from that. I think it inevitable and offset - for those whose work fits - by keeping discrete work in discrete TBXs. What it has taught me is to be more proactive in maximising use of prototypes and (for export) includes and recursing templates. The method, I mentioned above, of using a new ‘non-keeper’ file can be adapted to an output is a small ‘clean’ demo file. Clean in the sense it uses as little (none if possible) to encapsulate and technique. This makes it easier to use as a technique/code reference for when you want to add that method to a real work file.

Stepping aside from my own work and recalling 10+ years of wiki then forum TB community support, I’d also note that the one/many choice shouldn’t be based on tech skills or engagement with the tool. All too often the most stuck are those trying to do (learn!) everything in one file and creating a hard to fix midden. Using ‘test’ files to understand the technique outside your main file(s) is, I believe, a productivity boost.

So I think it useful to restate the questions as ‘one or many work files?’. Excepting those few who never ever use prototypes, actions or export, I think everyone will benefit from having more than one TBX file as the others may all be tests and experiments. New starters, especially, can get trapped into thinking more files == more complexity when the reverse may be true.

1 Like

I liked the idea of one big document and then decided I needed to streamline things. (I don’t recall why—maybe there was a lot of Agent activity).

I made a duplicate of my Tinderbox document and gave it the suffix ‘Archive’ before deleting things I wasn’t working on in the original document. I have deactivated agents in the archive and from time-to-time I shunt material from the working document into the archive document.

In theory, this means that I only have to search two documents if I ever need to go back and look for something.


Over time I’ve evolved a combined approach. I originally started with the one big document version, which tended over time to accumulate some clutter due to a large number of agents piling up and so on; this did get inefficient in some ways. Some cleanup was eventually done, mostly by deleting a few dozen agents and bells and whistles and reorganizing. I still use this (>5000 notes) daily for a combination of a journal that goes back a number of years, with accumulated notes on books, movies, articles read and so on; I used to add specific dated notes on random topics of interest into the journal using the daily journal note as a container but now I have a separate section using a chronological approach just listing notes (on ideas, newspaper clippings, etc.) under month/year containers (modeled on something I think I saw Dominique Reynaud using). I also have a few major topic areas that have collections, such as a large number of notes on using Tinderbox itself, general career planning ideas and bucket lists, and so on.

But I also use many dedicated larger and smaller documents. One is a general notebook for my writing avocation, which includes sections on the business aspects of editing and publishing, and a sort of working data bank of ideas and project tracking sections on the creative work. I keep a separate document for matters related to my psych practice for memos, copies of email discussions, information on things like test publishers, brainstorming and decision-making notebooks; also a document on using Tinderbox where I save up tips and how-tos which I am gradually organizing into a personalized “user manual.”

Finally, I use a lot of specific project documents for writing or work projects or other things; sometimes you just want to focus your attention on one “mental ecosystem” without distractions. For a current writing project I even have begun two separate documents, one just for writing content in a sort of brain dump way, but the other with preliminary book outlines, notes on book proposal ideas, and “platform building” plans and ideas such as ways to develop classes or research on the topic.

I do like the large, “commonplace book” approach to using a large notebook of journals, thoughts, random reading notes and ideas and aspirations and such. It might not be something I’d probably start now from scratch, but it’s more like an old friend, a slightly cluttered bookstore that you’ve been in so many times you know your way around. I can still find stuff there easily, do ad hoc agents or just searches or tag searches, search for similar notes, look up someone’s name etc, when need be. It also has links to my large, pretty well organized DEVONthink database which itself has 17,000 documents stored, going back many years.

But for a new writing or work project, your enemy is head clutter, and you want to do things to stay as focused as you can. For that, a small, recent, clean document is often best.

[Note - one minor edit for clarity 1/6/17]

1 Like

I use three main Tinderbox notebooks: one is for my daily notes (journal, notes for my blog, work notes, notes for some projects, and so on); one is for my tasks and projects and in this case, Tinderbox is a personal assistant in which I archive tasks and contacts I will have to remember of; one is for my reading notes. When I have to write something, I start by writing down my thoughts into the first notebook. This is the first phase of a work and I use to write using Map view: I often open some windows (cmd + x) in order to write the text of my notes and rearrange my notes in the map. Then, when I have a lot of notes and see emerging some structure, I open a new fresh Tinderbox work file and reorder the whole. If I had to use one big Tinderbox document, it would be for another big project such as a book or an academic work. But as Greg Korgeski said, I do like too the idea of a “commonplace book” where I could gather all my notes.


I use Tinderbox on an 11" MacBook Air primarily, so in effect I feel that I can only use smaller project-centered documents. I do dream of how wonderful it would be to use Tinderbox on a large monitor, where I can spread the Map view widely. I believe my documents would become far more extensive in that circumstance.

1 Like

I had for many years only one file. Then something really went wrong and Mark B helped me thousands when he solved the rather strange issues I had (things like special characters and other annoying things in various subsequent versions of Tinderbox). In fact the file was built over the years from a quite nice Windows application in my former life ((impossible to remember its name, but it was done by some Bulgarian guys, a nice project). When I switched to Mac (because of Tbx) I tried the same policy, but after some time I began having problems with the large file. Curiously I still have legacy parts in my file taht date back to that period. In total I have around 3 K notes.
So now I rather have many smaller files on a MacBook AIr 13". And Sometimes I wanted to have a sort of master file that links to the smaller ones, but it always depends on the place you locate the files on a hard drive, so I abandonned this idea. Since TbX 6 I really never felt at ease with the design of the one View (I am stuck because of system, to version 6).

What system do you use? I believe Tinderbox 7.2 again support macOS 10.9.

Also, big Tinderbox files are probably more viable in Tinderbox 7 than they were in Tinderbox 5 and 6. There are still good reasons to split files for different projects and topics, but some of the penalties incurred by large files are smaller than they used to be.

Hello Mark,

I use Tinderbox 6.2 and I am still on OS X version 10.9.5

The download page of Eastgate says :

Tinderbox runs superbly on all modern Macintosh computers. Tinderbox runs brilliantly on macOS Sierra (10.12), as well as OS X El Capitan (10.11) and Yosemite (10.10). Tinderbox 5.12 is available for OS X 10.6-10.9

I had various issues with space on the hard drive and need to do housekeeping. I have bought Tinderbox 6.6 update already since…July 7, 2016 ! and couldnt install it (in fact apparently there was also an issue with the system at that time, which was solved by Apple).

My fate is to dismantle systems and applications !! :slight_smile:

I’m pretty sure you’ll be able to run Tinderbox 7.2 . Download the demo and give it a try, but DONT replace your current version!

Email me if you need the URL for 6.6.5 again.

FWIW I just bit the bullet on buying a copy, but I made at least thirty documents while evaluating, as my mental model of what Tbx does came slightly closer to reality. It might be coming from software dev, where we build prototypes to throw them away, but I think it’s plain simple mental hygiene to start over afresh when building something new.


If you think of prototypes as like classes – imperfect metaphor, but you get the point – then you might be more comfortable with the concept.

Thanks! I definitely buy into the metaphor… and one of the things I tried out was cascading changes in a hierarchy of prototypes, though admittedly I didn’t immediately see what I’d use it for :slight_smile:

I’m probably just one or two impulsive moments from taking the plunge into Tinderbox. I’ll be starting fresh. I am wondering what people think of splitting the baby in this context: rather than have one TBX document per “project,” I am thinking of setting up one TBX document per “role” I play in life. I have a few “major” roles that make obvious sense to me: I am a husband/father/individual so I’d create a single “Personal/Family” document. I’m an attorney, so I would create at least one “Lawyerin’” document–I often split things up between business development, legal research, and client projects, but I don’t know how much flexibility I would lose if I did that. And finally, I’ve got some nerdy gaming hobbies of the paper & pencil variety that will obviously need its own TBX file.

To me, this seems like the best of both worlds: I have more than one file so I don’t have to contend with a massive, perhaps unwieldy document, but I don’t have so many documents going that they can’t benefit from that cross-pollination and “upgradeability” that others have mentioned in this thread.

For someone who is (very close) to just starting out, does this make sense?

1 Like

It makes sense to organize your notes and documents that way your organize your life.

However you organize your notes today is not a forever thing – you can change your mind and reorganize any time you find a better way.

Neo-firestarter Q:
How do users separate projects within a single Tinderbox document? Is this as simple as having a top-level Note (or Separator) for each Project (or having them all in a top-level or near top-level Note or Separator)?

Is there a table showing the similarities and differences between top-level items and documents?

In pseudo-topology, what are the differences between:
TinderboxProgram ▹ Document ▹ Top-level items A, B, C, D ▹ Children A1, A2, A3 ... ; B1, B2, B3 ...; C1 C2, C3 ... ; ... .
TinderboxProgram ▹ Documents A, B, C, D ▹ Top-level items A1, A2, A3 ... ; B1, B2, B3 ...; C1 C2, C3 ... ; ... .

Are there easy ways to convert a top-level item to a document? to convert a document to a top-level item in another document?

I would love to see “Tinderbox ▹ Documents” be a continuation of the outline contained in each document, with a seamless conversion between document and top-level item.

Hi Paul — thank you for helping me understand Tinderbox. Your text and links are valuable. Stumbling forward then …

Range of the container hierarchy in Tinderbox

The above illustrates what I’m asking about. The structure makes sense to me conceptually (the named content — by personal role — is immaterial to this discussion and is used just for illustration).

Opening a Tinderbox Document in the program Tinderbox is analogous to Focus Viewing a Note in a Document (a/k/a “hoisting”); you see and work with everything inside the container, whether the container is a Document or a Note. All of the top-level Notes in a Document are analogous to all of the Documents that Tinderbox can open. What I’m proposing is that this analogy be made workable. The result would be elegant, slick, and frictionless. The user could have separate Documents, but would be able, via expanding the Focused View all the way (a/k/a “un-hoisting”) the current Document, to have all Documents open with the full functionality of Tinderbox. This would overcome the limitation of having several Documents (the limitation is that with separate Documents global operations are limited to one Document), and make the question posed in this thread irrelevant.

Does it not make sense to extend the range of the container hierarchy in Tinderbox to include all Tinderbox Documents?

That’s why I asked for a chart comparing the properties of Notes (in particular, top-level Notes) and Documents. What is held at the Document level? Can it be moved up to the program level, or down to the top-level item level?

There is meaning inherent in hierarchy

But it’s not and there is. The content of the Note is determined by the user, as is the placement of that Note in the Tinderbox hierarchy. The placement of the Note in the hierarchy gives it meaning. Is it first? In the middle? Last? A child of another Note? A grand-child? Even in the (silly, but useful as a thought-experiment) case of a Document that has only top-level Notes, the order of the Notes (the flat hierarchy) gives each Note meaning that is independent of its content. Structure — any structure — creates meaning. We come to Tinderbox for the very purpose of creating meaningful structures.

… has meaning because the structure establishes a relationship between, for examples, “Grible” and “Pog”, and “Pog” and “Marther” and “Fromak”.

My other comments are off topic of “One Tinderbox document or several?”. I will post them separately.


1 Like

I once put everything into one big document and promptly never went back to it, it was too cluttered. So now I use multiple TBX documents based on project.

I’ve since realised that I was trying to use TBX as DEVONthink. So I now have one large DTP database with Groups that correspond to projects (and one group that contains all my reference material) and am experimenting with putting within each group its TBX document. At the root level of the database, I’ll have my Commonplace document. I’m expecting that DTP’s Table of Contents will provide the overview I need.

When finished, my Documents folder should only contain non-text files: videos, audio and pictures, with links to TBX notes as needed.

Thoughts on this approach?

[Further to this.]

My Commonplace TBX is like the Global Inbox in DTP and is synced with Simplenote to capture my “on the go” thoughts. Once there, copy and paste any Simplenotes into the relevant TBX document. It “should” work…


I agree on all the aspects you describe:

  • I used to put everything in one big sump;
  • I realized that things worked better if I had discrete projects/files – and the incremental-formalization nature of Tinderbox made it easy to spin those off as circumstances dictated;
  • DevonThink is very useful as the great-big-repository;
  • I still have a TB file that is an all-purpose Inbox sump, from which I can re-distribute items as I get around to processing them.