Thanks so much for this. I will give it a go !
1 Like
Here here!!! It is you obligation to make it your own. Three are three elements to "personal’ knowledge management:
- Method(s)
- Toos(s)
- You
The later being the most critical and irreplaceable and obviously, singularly unique, bu definition as there is only one You!
Sascha Fast has been writing about the Zettelkasten method for over ten years and has his own book on the subject:
The chances of him not having grasped something regarding the method are about nil, I would say! And the post that was linked above was only one in a series going back to 2013:
And there is plenty of debate on the forums of their site:
There are thousands of threads and posts regarding the Zettelkasten method there.
I think Michael Becker is right up to a point with his three elements: but I prefer to see the whole thing as a “system” consisting of person-tools-method-work to be done. There is, I believe, an interaction between the components of the system, and if you change any one of the components, the whole system needs to adapt to adjust to that. (And maybe it is worth observing that, in the view of John Gall, failure is an intrinsic feature of systems: https://en.wikipedia.org/wiki/Systemantics.)
Anyway, if you are going to use a tool like Tinderbox, it would seem counter-intuitive not to exploit the features it offers, and to try instead to use solutions that were developed for another set of tools. For some reason I find myself remembering that in the UK a hammer is sometimes called a “Birmingham screwdriver” 
The claim that Folgezettel (FZ) leads to this friction is just correct on surface level.
- If you depend your ability to assign an ID to a note on going through the branches of FZ you impose that said friction.
- However, the placing is not important. If there are two possibilities to integrate a note you just chose one and then link to the other place.
- Luhmann: “With this technique it is not important where you place a new note. When there are multiple options, you can solve the problem by placing the note wherever you want and create references to capture other possible contexts.”
- Not being important means that it is not creating value to decide how to place a note. If you act on the premise that the placing is not important, the friction is forcing you to engage with an aspect of the method that is not value creating and therefore imposing opportunity costs to you.
- FZ doesn’t force you and can’t force you to make a meaningful connection. There are just two possible ways to branch: Sibling or child. There are more than two possible types of relationships between old notes and new notes. Therefore, FZ is not powerful enough to actually capture the type of connection.
- FZ relationships need to be re-understood when you review them later. It is almost certain that you forget the vast majority of them if you are not working very frequently with your ZK or at least with certain areas of it.
- The FZ structure will grow to a high degree of complexity. If you want to work in a more orderly way with it the amount of necessary work and strain on your working memory will be high.
So, FZ does impose friction. But the assumed benefit of this friction is realized by working with your ZK anyhow:
- If you integrate a note into your ZK diligently, you spent quite some time browsing the already existing link structure of your ZK since it is part of how you navigate your Zettelkasten.
- If you use Structure Notes and integrate a note there, you have the opportunity to integrate the note very specific and meaningful. Meaningful means here: You describe the relationship between the note and the overarching structure explicitly.
- Theoretically, each Structure Notes is one way to access your entire ZK. Imagine a structure note that links to any other note. If you organize the links hierarchically, you created a complete FZ structure on one file. If you create another “total” structure note but make different decisions to place a note, you created a parallel FZ access structure. (Same notes, different FZ relations) The benefit of structure note is that it is malleable. If you are not satisfied by more choices, you can change them. FZ is permanent. You can’t work with FZ. When it’s done, it’s done.
It is not that FZ doesn’t produce any benefits. But there are other techniques and practices that produce more of the same type of benefits and more different benefits.
Practically speaking: Using FZ creates a hierarchical view, mostly on the left side of your screen. The view is hard-coded into the filename or an attribute. Structure notes (as the main alternative) create a view in the center of your screen (in the editor window).
Lüdecke writes for example:
Links or references do not emphasize the relationship between notes (ideas, content). The context of connections usually remains unclear due to arbitrary relationships. source
The very point I am making is that FZ are not providing meaningful context.
Wherever you read about FZ providing context you’ll encounter the claim that FZ does it. But the actual mechanism how it provides the context is either left out or proposed in foggy terms like “relationships of relationships”. (“Relationships of relationships” is, by the way, a technical term of Luhmann’s systems theory.)
Lüdecke is doing exactly that. Just stating that FZ does that.
The general fallacy all proponents are making I am aware of is the following:
- (1) FZ is an effect.
- (2) The effect is beneficial.
- (Therefore) FZ is beneficial.
It is a fallacy because the benefit of the effect needs to be established through the lens of opportunity costs and in isolation. Yes, FZ produces friction, which can be interpreted as “good friction” (eufriction). But to make the claim that this if beneficial, you need to base your claim on a comparison to other habits and techniques.
To give you an illustrating example:
There is not a single healthy nor unhealthy type of food. Is pizza healthy? Not, if you compare it with other options like self-prepared whole food meals. But if you are broke or stranded on an island, having a pizza (or even just a bucket of almost spoiled whipped cream) can be life-saving. This might be a controversial position, but being alive is more healthy than being ended by starvation.
Yet, people make all kinds of claims on the health properties without any contextual reasoning.
The same is true for FZ. The reasoning needs to be dialectic. But it isn’t.
You are making the very point about tags that I make about Folgezettel. 
FZ by themselves do not contain meaningful information since they just can establish that there is a connection but not the nature of the connection itself.
I am sure. In Lüdecke’s article, there is just the claim that FZ does this or that. There is no justification or exploration of the actual how FZ do that.
Other articles you’ll find in the internet lack the above-mentioned dialectic reasoning necessary to make claims on the benefits. (At least as I am aware of.)
The weakness of my position is: Since I am holding my position for a long time (more than a decade) and base it on my iterations of discussions and reasoning, chances are that I am reading selectively. So, if there is any dialectic reasoning about FZ, I am happy to engage with this topic once more.
So, my position is that FZ might be useful but pale in comparison to other techniques.
But if you like it, you like it.
2 Likes
Yup, you’re spot on! Work do be done definitely belongs in the list!!!
1 Like
Sascha,
Thanks for returning to the Great Folgezettel Debate and offering such a detailed exposition of your thinking. And apologies too for taking a while to acknowledge this. I am juggling multiple projects right now.
As I said earlier, I regard this as an experiment, rather than a crusade designed to embody a strongly held prior belief.
But let me take up a couple of issues. Firstly, linking in the Folgezettel method is not as dumb (in the sense of inert) as tagging.
If you look at Luhmann’s practice, he may have said that it doesn’t matter where you put a note, and he may have also meant that in a sense, but that also doesn’t mean that he was inattentive to position. He is just saying that one should not worry about it or be particularly invested in it. If he had not cared at all, he wouldn’t have bothered at all.
In terms of his actual practice, the notes that stem on from each other, sometimes advance an argument, in ways equivalent to paragraphs in a sequential draft. (Often they don’t, of course.) The physicality of his system, small bits of paper that therefore only have a certain amount of space on them, will effectively force this at times. (On a digital system, one can make the notes as long as one likes, but benefits accrue from the atomic nature of small notes. One can isolate individual ideas and arguments more clearly.)
It is also quite possible to use a Folgezettal numbering system while at the same time adding in brief descriptions of what the proposed connection is. (One could of course also do this with any other form of linking from anchors within the text.)
Finally, and this may be the most relevant point for TB users, TB doesn’t excel at search. In Obsidian, Roam, etc. (and Devonthink) it is easy to find related notes and to link them in wiki style. That process is more of a faff in TB, and the search interface is (sorry Mark) really clunky and hard to deploy.
TB also works on the basis of notes having specific containers. One can work with all one’s notes in a single container but that makes maps extremely unwieldy and so some degree of categorisation is inherent in the use of TB, even if it is just in the sense of a higher level container.
I find maps extremely useful with their capacity for spatial organisation, and different note types, which can be coloured and flagged in certain ways, but there is an incompatibility with getting the most out of maps at the same time as following the linking practices you are suggesting. Put simply, if one wants to use maps effectively and gain their benefits, one needs an initial position. (In my view, the hyperbolic view doesn’t really solve this.)
I also suspect that Luhmann must have often worked with his Zettels by pulling a bunch of them out and then sorting through them on a tabletop so that he could see what relationships needed refining. That physicality is similar to TB’s.
You mention in your pizza example, the need to understand context (usage scenarios), and the importance of arbitrating between the different cost-benefit propositions contained with any proposed solution.
There is not a single healthy nor unhealthy type of food. Is pizza healthy? Not, if you compare it with other options like self-prepared whole food meals. But if you are broke or stranded on an island, having a pizza (or even just a bucket of almost spoiled whipped cream) can be life-saving. This might be a controversial position, but being alive is more healthy than being ended by starvation.
Yet, people make all kinds of claims on the health properties without any contextual reasoning.
The same is true for FZ. The reasoning needs to be dialectic. But it isn’t.
The simplest follow on to that is to say: sure!
If I was not relying on maps for complex functions and just working with freeflow notes in a Roam-style application, then I suspect that the case for using Folgezettels would be less promising. But I am using TB, and there are benefits in using maps, costs in not having the note-linking ease of Roam etc., costs for using Folgezettels in any system, and benefits for using Folgezettels in any system.
So, the cost-benefit maths is complex, as is the context. My hunch is that the Folgezettel principles are more useful (maybe uniquely so) when working with TB rather than with other systems.
And also this is not about copying Luhmann or hoping to achieve his prodigious productivity through the means of some version of digital sorcery.
This also runs 180 degrees counter to what I think Martin is suggestion above, that I am intent upon bodging a job by applying a shiny but inappropriate tool. (BTW I am not saying that defensively. 
)
Anyway, if you are going to use a tool like Tinderbox, it would seem counter-intuitive not to exploit the features it offers, and to try instead to use solutions that were developed for another set of tools. For some reason I find myself remembering that in the UK a hammer is sometimes called a “Birmingham screwdriver”
Instead, I am trying to find a specific adaptation that suits my broader needs working within the constraints of the tools I have.
It could be a dead end but I will find out with time. Unless, of course, I find myself stubbornly sticking to the same track as a result of the sunk cost fallacy. Certainly more than possible. 
That is patently not the case. I suspect the ‘problem’ is you are presuming a particular UI/concept of use (perhaps a different you’re more used to). It really is worth spending some time looking at how Tinderbox’s search tools (find, queries, etc.) work and how they are implemented before casually stating search ‘doesn’t excel’. If you’re struggling with search, perhaps share some example problems.
Another misunderstanding and misleading statement. Tinderbox doesn’t require use of containers, with a few exceptions such as things like storing template or agent result. We, as users, may choose to use containers or not but it’s simply untrue to state it is a requirement imposed by the app.
Tinderbox really does repay spending a little time understanding how it works before dismissing it here in the forum because it doesn’t work like [some other app] as it is misleading for other users trying to understnad the app.
Mark. This is unfortunate. I appear to have set a pigeon racing that I did not mean to. And so let me clarify for some clumsiness on my part.
Rather than saying that Tinderbox doesn’t excel in search generally. Let me rephrase that: Tinderbox’s search UI doesn’t work with in the same way as other Zettelkasten orientated note-making apps. i.e. it does not excel in search specifically when doing the kinds of Zettelkasten linking that is being discussed here in this thread. And that doesn’t mean it is bad but just not as good as the other alternatives. I can see I should have used another verb, perhaps.
In those tools, it is easy to locate related notes and to pull them into a note you are working with while still centred on that note. Tinderbox doesn’t handle search in the same way. I often have to do two or three extra steps to review possible connections. It could be there are better ways of using the UI that I have not fully tried or understood. But I have been using it for over ten years.
It is also possible that I am attached to particular patterns and workflows that might make me resistant to things that others are more comfortable with.
In general, and this may be a personal observation irrelevant to others, I experience some unhelpful friction when using the command F search function, which is not the case with Devonthink, as a point of comparison. The UX is different in terms of how search is built.
That all said, TB has an excellent architecture for doing other kinds of search. You can build agents, and do all kinds of other things that are impossible in other programmes.
That is why I am using it so heavily and I am such a fan!
The suggestion that I am “dismissing Tinderbox" couldn’t be further from the truth. And I am surprised that my attempt to explain personal experience was taken that way. Perhaps a function of my clumsiness.
The capacities that Tinderbox has for intricate visual display is something that I find particularly useful and it is something I am trying to stretch the potential of where I can.
On the point about containers, I see what you mean. It doesn’t technically require containers in any absolute sense. But still, it is hard if you are using maps not to organise things within separate maps (containers) because there is a point at which a bigger map becomes unwieldy to use. Again may be a matter out of personal preference.
Hope that helps …
1 Like
This was a monumentally unproductive way to phrase what turns out to be a very minor objection to a tiny detail of the user interface. (I will ignore the silly comment about the search interface being “really clunky” because, if pressing ⌘-F is “hard to deploy”, we might be living on different planets.)
Tinderbox offers (a) fast full-text search, (b) persistent searches with regular expressions, a powerful and flexible query language, and optional actions — and has offered that for 20 years! (c) a link apprentice, (d) fuzzy search based on text embeddings, and (e) search based on neural-network-based extraction of names, entities, and places.
One can work with all one’s notes in a single container but that makes maps extremely unwieldy and so some degree of categorisation is inherent in the use of TB, even if it is just in the sense of a higher level container.
Why is it that the existence of containers is held as a defect of Tinderbox? If you don’t like containers, don’t use them! You don’t see me running around and laughing at, say, Roam, The Brain, and Tana because they don’t have containers. If you have lots of notes and don’t use some sort of elision mechanism, your maps will eventually become unwieldy: this is true of any system, or any conceivable system. Containers are one elision system — one that happens to be rather good. Link horizons (The Brain) are another. (Link horizons were, I believe, first used by Janet Walker in Symbolics Document Examiner.).
I’ve got to run: breakfast to be made, and feathers to unruffle.
3 Likes
Thanks. You elegantly explain this issue: Tinderbox is not optimised for zettelkasten process nor specifically designed for it.
Tinderbox’s Cmd+F find stays nicely out of the way, but once invoked the search bar stays in the view unless you click done. This reflects the fact that not all users need to be using the find feature all the time.
Find searches $Text, $Name and a choice of one user attribute: default selection is $Text and $Name but all 3 options can toggle separately; it also has (toggle-able regex and case-sensitive options in easy reach). It isn’t like DEVONthink search, but nor should we expect it to be. DEVONthink is essentially a repository (an ‘everything bucket’ though that terms is not disparaging in this context). So the sorts of searches we do in DEVONthink are in a very different context.
The way to unpick your problem is to not start out from negative comparisons (it’s not like X). What are you trying to search for (in X or in Tinderbox), i.e. what are you expecting to match? Much of Tinderbox’s depth is in the ability to abstract—by thoughtful use—information either implicit or explicit in a note’s title or $Text. Tool’s like The Archive, which mimic the paper card notions (IOW just one piece of $Text) are forced to embrace the limitations of such a format. This is where understanding can break down as constraint-based choices are assumed to be deliberate design choices rather than best choice in limited context. But it’s not a zero-sum consideration which is why comparing very different designs lead to confusion.
Many of us—probably most humans—place a higher value in what we see literally (so the UI). Thus, if the (think we) understand app A and app B looks different it is—at first sight—worse. But that is a superficial, and likely unintended, analysis. Un helpfully, as an app’s UI can thus stand proxy for the process we effect within it, we falsely assume app A is the correct canonical way to work. That is, I suspect, why the new breed of PKM apps tend to use the same plain text+wiki concept+Markdown as any departure from that—it’s too big risk for developers to use any other metaphor. What’s also forgotten is that useful PKM apps pre-ate this supposed canon.ttbx dates from 2002 (informed by/building on ideas/apps from the 1980s) and TheBrain is from the late 1990s. Sometimes we get sucked into the new. Are one window apps better than the old Mac OS, or is this a case of over venerating the constraints of small/single screen working.
Tinderbox is a far deeper, more featured app than a pure zettelkasten tool. But that should not surprise as the latter is doing a narrow (yet powerful) bounded process—and only that. Making Tinderbox look like a zettelkasten app is a fool’s errand, but only because they start form a different place. Using the zettelkasten method in Tinderbox is tractable but only if not doing so by trying to make a file-less plain text app.
Indeed, zetelkasten—stripped of the magic of the name—essentially means taking thoughtful, limited-scope notes, storing ideas/concepts in a single place, and interlinking freely (but with deliberation). There are lots of ways to do that, but our tendency to confuse UI with process can blind us to alternative—even possibly, better—ways to the same end.
2 Likes
First, I should apologise again to Mark @Eastgate for ruffling feathers. Definitely not what I intended but I can see how that happened in the harsh clarity of the days cold light …
i.e. My fault entirely for not thinking word choice in that paragraph through more carefully.
On the container issue. Thanks for the interesting background:
Just for the record, I have nothing at all against containers: they are ideal in certain workflows. Good containers are often just the thing I need! (And that might go for my posting style on this forum as well. 
)
Mark, @mwra, thanks for this:
I wholeheartedly agree with that.
In fact, the Zettel prototype I am using is only one of various note types all of which do different things within my Tinderbox file and so there is never been an intent on my part to build a pure Zettelkasten implementation in the way that others might have in mind.
The original hypothesis I was trying to advance and the one that led to the reanimation of this thread has probably become lost in the above. And so let me try and end this chapter on a positive note by recalling what that starting point was. It is the specific idea that:
The Folgezettel principle (of stemming and branching notes in set patterns) may confer certain affordances when working with specific note types in TB’s map view. (The benefits are unlikely to apply in the same way in other applications or, indeed, other ways of using Tinderbox.) This placement method gives a note an initial position within a map or (physical desktop), which then allows for a preliminary organisation of notes. Even though this initial placement position has its own value, it is not in any way superior to the use of more free-flowing note-linking. If anything, it is just a starting point for further connection to other notes (i.e. through ziplinks within the text or other methods.)
One could look at this as yin and yang, two different organisational principles working at the same time but at different levels.
Hence my interest in creating some code that might help with finding out experientially how much utility there is in applying this principle. (It may well also be a fools errand but not one that is identical to Mark’s helpful caution in the quote above.)
And thanks again for your patience. There is a point to this, at least I hope so.
All best wishes,
I was just wondering what your research topic was.
The research work I do is in the space between cultural studies, history and psychology. i.e it is pretty broad. I am either working with conceptual schemas or interview transcripts.
This branching and stemming methodology is - at least I suspect it is - useful for me, because on most topics, I am starting with a fair amount of existing knowledge which is already in a useful order. Thus, I can lay that out in an initial pass in a map and access it the next time I need it without having to scratch my head so much or re-transcribing tracks of thought I habitually use. I can then link other notes to this armature in a variety of different ways that is more serendipitous and free flowing - and more like the intra-note linking inherent in both Luhmann’s original process and more recent interpretations of it. I can also create entirely different kinds of maps in different places by using aliases and so I am not constrained by initial placement.
I also do a fair amount of practical writing as well and I have noticed that the stem and branch technique is an effective way of blocking things out quickly, and in a way that is deeper and more effective than simple outlining is (well, for me at least). The main lines of argumentation are trunks, and one can then branch sideways to add in additional inserts or alternating develop other possible structures in parallel.
All these experiments are based on finding new ways of working in Tinderbox and they are pretty idiosyncratic !
How does stem-and-branch differ from the implicit structure of an outline? Or, if you are referring to link-derived trees (i.e a network graph), how does this differ from a hyperbolic view? Is there a reference you can give that underpins stem-and-branch methodology or is it just an ad hoc term?
How does this actually differ from Tinderbox text links? Tinderbox can link note-to-note, text-to-note, note-to-text and text-to-text (though the latter two are less seen—but perhaps only because people don’t read the docs?).
It’s not entirely clear, but it seems that you’d like to be able to insert groups of notes. If so, look at Prototypes 'Bequeathing' Child Notes. Don’t get hung up on the fact the children are based on outline-style nesting as de-nesting is easily achieved with some more action code.
Understood. I just try to prevent as much binding of cognitive performance of the hive. #BorgUnited
I am pretty sure that he wasn’t totally careless. But the same amount of thought is necessary to make any connection. That is what I mean by FZ as a technique and not part of the method. It is one technique to form and ensure connectivity through direct linking. But there are opportunity costs if you have other (better) techniques for that at your disposal.
Any intellectual endeavor is training at least. Good luck. Perhaps, you stumble upon something.