Tinderbox Forum

Common Tasks: How can I be sure this note will show up later when it's valuable?

The recent discussion of Roam made me think that it could be interesting to take a step up in abstraction and collect some community practices for common problems one might want to solve.

Here’s one that’s been on my mind lately: after I create this note in my research notebook / zettelkasten / journal / etc., how can I insure that it will return to my attention when I’d like to see it again?

To be clear, my intent isn’t to say Tinderbox isn’t good at this and new features need to be made–in fact, exactly the opposite. I think there are a number of interesting ways to address this problem and I’m hoping to hear about some clever ones here.

Obviously, there’s no way for Tinderbox to know what might make a note interesting or valuable to me at some future time, and in fact, I don’t always know this either! So the ambiguity is part of the trouble.

The first strategy I can think of here is links. I just started using these in a large notebook file a few years ago and I think I could probably do a better job of utilizing them, especially in map view.

This brings me to a second strategy: map placement. Group related notes together. Honestly, this has been my most used and appreciated strategy. Easy to regroup when refactoring, easy to see relationships, easy enough to cmd-click all the notes and see their text together.

However, this doesn’t scale, and combined with links, can lead to a messy view that no longer imparts much meaning at a glance. At this point, maybe roadmap or browse links can be useful, but I’ve not used these features thus far.

Next up, agents and metadata. Tag the note, add a citation field, look for keywords in the text, etc. Works really well in the attribute browser. However, this strategy is subject to all the criticisms of tagging–that the taxonomy grows stale or gets out of control, etc. etc.

I can sort of see the appeal of Roam’s presentation of links & potentially related notes at the bottom of every screen, but I wonder how that approach will scale too as users get years worth of data in there and the “related” notes starts to get unwieldy, or certain notes become hubs and have too many links.

Recently another user made a series of feature requests that are really compelling to me on this front, including:

  • quick note history for bouncing back to recently seen notes
  • record of notes viewed frequently together. If you haven’t looked at this note in a year, but the last time you did, you also looked at note x and y within 5 minutes, display that relationship somehow. This seems really cool.

Overall, I think there’s probably a lot more wisdom in the community than these meager strategies. What have you got? Please share and discuss!

Metadata (i.e. attributes) and not just $Tags. Tinderbox is wonderful at incremental structure - whether literal (outline, map layouts) or in an informational sense. In an age of AI, ML, NLP, etc., and ‘just googling’ for answers, we’re getting over-prone to expecting our software to know the answer.

Whether you’re a visual person and encoding metadata into visual attributes or happier with abstraction into more general attributes, I think this pays off. Looking back on time assisting this community, I think there is often over-focus on process (because we’re habituated to apps that have one/few ‘correct’ processes). Emphasis goes on tidy maps, ornate workflow and an obsession with everything being available anywhere, anytime.

Lost in all that activity is the data itself. Just as an ‘everything bucket’ like Evernote or DEVONthink will become a mess if not reviewed, I think the same hold for ones Tinderbox notes. The app allows for capturing emergent structure but it doesn’t do it for you. The ‘how’ of that latter task is rather dependent on the individual.

For long term documents in Tinderbox, and for research/projects, I’ve learned that attributes are as useful as text ($Text) - often more so. Looking at some of my larger projects, more data is in attributes than in $Text. Why? Because it is easier to engage with the information. If all tasks become a regex trawl of text things become cumbersome.

That isn’t to eschew note text. Indeed, the starting material might be quotes, or close-reading notes on source texts. But, extracting from and metadata-enriching that text is a way to make sure, as the thread asks, that the “note will show up later when it’s valuable.”.

My 2¢!


I suspect this is an ancient problem for dedicated note-takers regardless of the medium. Partly depends on defining the circumstances of “when I’d like to see it again”. “Again”, because that
note is somehow “related” to this note. Or because there is a temporal, or event-based, or semantic, or semiotic “relationship”.

Personally, I find “links” are a fragile way of relating notes – too many links can render the relationships the links are intended to represent so dense that they are difficult to work with.

I find it is best to combine careful gardening, performed as I create notes, with discovery. “Gardening” in the sense of providing a context for each new note – with attributes (mainly user attributes).

Luhmann’s ID scheme was his form of gardening, that worked very well because he carefully kept to his discipline for each card he wrote. I laugh at advice many bloggers give to “dump all your ideas into a bunch of notes” or “your mind is not meant to store things”. Well, when you dump a bunch of ideas (or make a bunch of notes without going back to ensure they are correctly tagged or flagged or attributed, or whatever the method is, then. you have a bag of useless notes. And, minds are great for storing things – cognitive schemes that you revisit and relate to the physical notes you made – ideas that keep you wanting to take more notes on a topic. But, I’m digressing.

Even meticulous gardening cannot anticipate the future. The most common case is realizing that this thread of notes has by unanticipated circumstances become relevant to that thread of notes. This is where discovery comes to play: “search” on keywords or concept words in a note that had not previously be flagged in an attribute; or agents of greater or lesser complexity to look for semantic threads that hadn’t been instantiated with links as the note collection grew.

And, finally, I think the best overall practice – somewhat in the discovery mode – is to simply sit back regularly and read the notebook or notes collection in Tinderbox or whatever. This doesn’t require any technology and is often the most pleasant way to serendipitously come across connections one hadn’t thought of before. Then, when discovered, return to gardening to make sure the next time the connection will be more obvious.


Amen! One thing I have learned all too slowly is that no software can replicate the effect of sitting attentively and somewhat anxiously with my notes and my thoughts. It is all too easy to try sewing an ever-better net rather than tossing it in the water and actually catching a fish.

I began to get much more out of Tinderbox when I began letting my documents stay “messy” – notes with similar names, the same text occurring in more than one note, attributes that used to be important but aren’t used now. It’s OK not to fix everything or hone my system for some general use case that may occur in the future. I’ve found that trying to create long-lasting structures distracts from the work of creating a structure that will be useful now, for solving whatever task I have at hand. The structure that lasts is the one that emerges from solving concrete problems, one after the other.

For finding the right note at the right time, I use “all of the above” – attributes, tags, text, links, adornments. Even the sometimes-on, sometimes-way-off “related notes” suggestions of Evernote and Devonthink. Yet after years working with these tools I have never found a software substitute for the free-associative process of contemplating some notes and seeing what thoughts and recollections they spark.

That said,

I agree. I know there are workarounds but a straightforward History would be useful, precisely because one’s most recent trail is a handy map of one’s latest conscious and unconscious thoughts.



In my dashboards, I often have repeater notes that display the names of notes just to call them to my attention. Common examples are:

  • A list of the most-recently modified notes in DRAFTS
  • A list of notes tagged with TK (a shorthand for “find this fact or name!”)
  • A random note from DRAFTS that is more than 6 months old
  • The name of one character

This comes at the topic from an odd angle, but it’s the system I unintentionally found myself with that is working for me right now: it involves the Finder and many small TBX files.

I’ve made many failed efforts to create “The TBX to Rule Them All” over the last few years always with the idea that if I could come up with a system that would hold all my notes, I’d connect them and, nirvana. It never works, and over time these failures have slowly populated the filing system I use in the Finder with many (often small) TBX docs (some are a single map with less than a dozen notes).

Because I have a stable filing system for the Finder that places teaching resources chronologically and research materials roughly alphabetically, these TBX documents aren’t lost and aren’t sitting alone in an overly specified folder. Instead, they share folders with dozens of variously relevant files and I’m constantly stumbling over them as I look for other things. If I see a TBX file and the title makes it seem relevant, I take a look at what’s inside and copy out useful material for whatever I’m working on. If I do find useful material, I’ll often drop a new note or two in the file I’ve stumbled upon or write a quick “cf. [current project name]” so I have a trace of what connection just played out for when I stumble across the file next time. It’s messy and low-tech but I wound up following a chain of references across three small TBX files this past weekend and found some good info as I did.

None of this is to downplay the tools internal to TBX mentioned already: I use the range, especially links. It’s just to say that in a weird and unexpected way, TBX also makes my older notes accessible by making it easy to stash them away in small pockets in the file system hierarchies I use for everything else too.


Very good approach. Thank you for posting.

Since .tbx document are plain text (XML) and Spotlight knows what is inside them – unless the folder is excluded in Spotlight’s Privacy settings – then $Name and other attribute values are discoverable with Spotlight in Finder, or Alfred, LaunchBar, or whatever flavor of search you want to use. A related approach is to keep all Tinderbox documents in (or indexed by) DEVONthink – and use smart groups or other search features in DEVONthink keep track of what you want to keep track of, or find notes for you.

(I would guess that an adept such as @trewr could invent a script that indexes a folder of Tinderbox files by name, or other attribute.)

1 Like

I would personally write an XQuery expression to do that – one of the keys strengths of XQ is that you can define its queries either over a single document or over whole sets of files. (Folder-fulls, for example).

TBX files, as regularly structured XML, lend themselves to quite focused and specific cross-file queries of that kind.


If anyone wants to give a few examples of what general type of searches they might want to do, I can sketch a Tinderbox example (perhaps this weekend) and put it up on Github.

In the meanwhile there’s an old project (below) which has some overlap, it shows one way of running an XQuery over all the OPML files in a specific folder, and generating a lightly formatted report:

JavaScript XQuery demo in here:

1 Like

This is an interesting thread touching on several points. I agree that the everything bucket that magically finds what is interesting misunderstands the role of one’s own thought, development and divination in using information.

I have more than one everything bucket (unfortunately) and I use them via search or sometimes by automatic similarity calculations–I’m thinking of Devonthink which does this particularly well. Other times I search a directory structure in the file system using Foxtrot which allows me to find related files fast. For this reason, I also sometimes drop text files in relevant places. For me, this is just information search and retrieval. A bit dumb, but necessary.

I find I use Tinderbox sometimes to accomplish a particular task. For example: research some decision, organise that research, make the decision. There, freeform note creation, metadata, and iterative revision all work well.

Another example of a particular task on which I am working is a translation. There I want to achieve a high level of consistency in the way I layout the many, many pieces of my project. Here the tools for imposing uniform properties throughout a multi-level structure are unique to Tinderbox, as far as I can tell.

A third particular task would be preparing to write a report or similar.

I call these particular tasks because it makes sense to say that I’ve finished them, i.e. when they’re done. I may yet refer back to them but no more work is likely to be done.

There is another activity where I want Tinderbox to be my tool of choice, but I’ve not yet managed to get it quite to do what I want. In this case, I want to think about ideas I have noted down in varying detail, thinking about their similarity, their inter-relations, and what kinds of bigger pictures (of ideas) they can produce. The difficulties are latent in the OP’s comments. Here, there is no terminal point in the work. It is like gardening, though I think the word cultivation is even closer to what I mean. Perhaps like Paul, I use links sparingly, mainly for coarse or gross inter-relations, rather than fine-grained ones. (Using fine-grained inter-relations has seemed to me to require too many link types to be useful.) The relations of containment are easily modeled in Tinderbox and easily surveyed. The relationship of shared properties are also well modeled in Tinderbox and filtering, sorting and associating on these properties is straightforward.

Both containment and shared properties are very definite relations insofar as one thing either does or does not contain another; it has the property or not. What I would like to capture are somewhat indefinite properties. For example, these notes are somewhat related, while these notes here are also related, only less so. You could group these together on one way of thinking, but not on another. Spatial layouts are very good for this, a point that comes out well in one of the chapters in the Tinderbox Way (because it is not just spatial proximity that informs, but also geometrical relations like forming lines, orthogonals, means, shapes). The map view is good for this, although most of it is invisible elsewhere.

I could put what I am trying to do by saying the thinking I want to do is creating conceptual maps. Crucially, I want to put the same concepts into different maps so as to conceptualise them differently. Or put another way, I want to spatially map the same notes in more than one way. Or put a third way, I want to create (think about) different, possible, indefinite relations between notes. A kind of example from system design might be different layers of analysis/conceptualisation, such as 4+1 for those who know it. Or you might want to distinguish a phenomenon at the neurological layer, from the psychological, from the logical, from the social. Sometimes you want to put the same concepts into different inter-relations depending on the layer at which you’re working.

The crucial thing is to retain the results of this thinking, i.e. these sets of assignments [NB plural] of indefinite relations between notes, so that they can be cultivated (gardened) again later for more thinking.

I mention conceptual maps and you say, perhaps, why not use a mind mapper like MindNode? I have and do, but they are perspicuous only for little $Name/s or snippets, like manipulating the tips of icebergs. What draws me to Tinderbox is that with Tinderbox you can have the rest of the iceberg (viz. the large amount underwater) in the $Text of a note, itself infinitely revisable. And a mind mapper constrains you from augmenting with Tinderbox’s containment and attributes features.

One question for others: how, if at all, do you try to represent/record/use indefinite relations between notes?

Now the reason I said that Tinderbox does not quite do what I want is that I have found no way to maintain multiple spatial inter-relations of the same notes, while also permitting the $Text of those notes to be revisable. That is, I can take a set of notes and copy/paste them into another container and then organise them, but then amendments to the $Text are not shared with all copies. Or, I can create a set of aliases for notes, then re-arrange them. That solves the $Text revision problem, but precludes containment relations. (I have done some experiments with automatically propagating $Text revisions from a golden container of notes to all the known derivative copies, but this is very fiddly to set up and inhibits editing a derivative $Text directly.)

It is for this reason that I–and one or two others–have sought so-called replicants of notes, namely a way for the same note to be accessible from more than one “place” in a Tinderbox document. However, Mark B rightly notes there may be some complications. And I have the sense that perhaps this kind of work for which I find Tinderbox is not quite ideal is not work that many people are doing or want to do.

At any rate, I hope the length at which I set out this kind of work/thinking might spark something valuable for others.


User attributes. Most apps offer a single tag bucket (which Tinderbox generally imports as $Tags). But doing so collapses the granularity of your nuanced tagging and forces everything into regex-type search. Even if you stick with a general $Tags bucket of terms, adding themed user metadata helps a lot at the analytical stage, opening up things like use of Attribute Browser and Crosstabs views and allowing better export (for projects that span several apps/processes).

For non-link-based work, don’t overlook the distance() operator which offers a means to find closer/further items in a map.

Also, while new to many of us, the hyperbolic view offers an link-dependent view of notes that is independent of containment and the outline hierarchy.

Sticking within the bounds of current features, you could experiment with storing different maps as discrete sets of X/Y co-ordinates (using user attributes). OK, you won’t be able to implement more than one map at a time but by cycling different values you can ‘refresh’ a map to give a different layout depending on which set of co-ordinates you load to $Xpos/$Ypos.

Yes, this is exactly the kind of work that I find challenging but rewarding. Notes that span multiple discrete projects, ideas that are not associated with any particular project (yet?), etc. If I created a note many years ago about an issue that might be relevant today, how can that note be brought to my attention, or how can I be reminded to go looking for it?

Spatial layouts work well here, until the space gets too cluttered or widespread.

Your post shows you’ve been thinking and working more carefully than I on these problems–considering aliases vs. copies vs. master records. I’ve generally run into: “I’d like this note to exist in more than one place at once but that’s not possible and I’m not sure that’s actually what I really want anyway” and kind of given up.

However, I’m optimistic new features under proposal (like new roadmap views) might ease navigation between widespread or cluttered maps, provided links are used well. I’m starting to think it may be valuable to experiment more carefully with link features, especially link actions(so that if I create a link of a type, notes get a certain prototype or some other action fires), and the linkTo action code (maybe it’s possible to programmatically create some links that I can then render visible or invisible on the map to decrease the clutter, but still access via the roadmap or via agents).

1 Like

Grab a bunch of aliases — an agent will do this for you — and make a second map. Or a third!

That’s right Mark, except you lose the children and any links.

This is what I do now. In fact, following a hint from @PaulWalters, I have a canonical container with all the notes I want to work with, and then Tinderbox replicates those as aliases to the containers where I am doing my mapping. It means that if I add a new note to the canonical container, I get copies in all my derivative containers.

That’s very interesting, Mark, thank you. In effect, it would allow me to take a “snapshot” of an arrangement and record that. I can see that that would be easy. Then I’d need to have a way to “roll back” to a snapshot. That would require a bit more care to implement, but it could be worth it if it were sufficiently general. It would be a step up from one of my current solutions which is simply screenshots.

The ability to copy and paste notes between maps now may make it easier to take clumps of notes from different TB files and then think with them. I tend to keep my TB files relatively small if they have a lot of metadata. The reason is that there is at least a geometric expansion in the requirement to have and maintain metadata as the number of notes increases. In other words, with relatively few notes focused in one area, the superstructure of metadata is fairly small because the differences between notes are fewer. With more notes, the superstructure balloons.

Link actions are very cool. I’m using them at the moment to assign a particular prototype to the target of the link according to the type of the link. Then I have smart adornments that grab the notes by prototype. It means that the targets of the links I make are gathered spatially according to their types. Since I’m often making links and targets in outline view, I can do this and still get a visually clear map when I switch to map view.

1 Like

Yes. As you can see there’s a degree of set-up needed from the actual user in terms of new user attributes and the action code to populate them and switch between them. Indeed, you could have different link types too, noting that link visibility is toggled at document scope. So if showing scenario #3 you might hide link types for other scenarios, set $Xpos & $Ypos to the stored values for scenario #3, etc. I’d agree it’s all a bit baroque, but it can be done, should the need be there.

It does avoid going down the rabbit hole of aliases &/vs. replicants. In a broad toolbox like Tinderbox we also need to think in the round about the effect of such a new feature like replicants on the many other uses of the app; one simply can’t assume the effect is only positive. At outset, the focus is always on the job at hand—which is not always a good thing.

Not, I should note, that I’m antipathetic to replicants. However, years of documenting the breadth of Tinderbox makes me see they would be a decidedly non-trivial addition to an app people like to label hard to learn.

I have a few thoughts on this spurred on by a few things:

  1. Readwise a service that sends a daily email of 5 kindle highlights. I probably won’t keep it after the trial, but I’ve enjoyed seeing past highlights and then transferring them into tinderbox. Here is a screen shot from an email.
click for a screen shot of Readwise

  1. When I used OmniFocus there was a review feature. You could set an interval on how often you would review a project.

  2. Anki a flash card app that uses spaced repetition to learn material.

Here is an idea:

Create attributes

  1. Review number
  2. Review Date
  3. Mark Reviewed.

When you add a review number it calculates the review date. You might choose to review an important note once a week while others you might review it less frequently.

A agent picks up what notes to review. When you are done reviewing you stamp them reviewed which resets the date.