One Big Tinderbox Document?

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.

—Kirby.

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…

3 Likes

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.
4 Likes