The GRID system for frictionless Zettelkasten Organisation

tjex

Hello all,

A seriously long time lurker (3+ years) turned member here.

Through that time lurking, I've gained incredibly valuable insight for working with Zettelkasten, avoided many pitfalls and had the apprehension of working with the system reduced significantly.

Many thanks to Sascha, Christian, and those who regularly frequent these forums for providing that valuable information. This forum is a cave full of treasures.

...

So I'm finally posting with what I hope is useful for someone else, as it has been for me; a formalised system for organising a Zettelkasten, that takes a very critical look at categorisation, folders and tags. The driving concern being reducing "cognitive friction" when creating and writing notes.

I've moved through many of the different recommendations on here for structuring a digital Zettelkasten workflow as well as other formalised systems (namely PARA, Jonny Decimal, ACCESS, Bryan Jenks' approach and of course Luhmann's fundamentals).

As mentioned, the system I've arrived at was developed with the fundamental requirement of enabling a workflow that is as frictionless as possible; meaning the system gets our of your way when writing, but is still effective when it comes to recalling, managing and processing notes later down the track (i.e., when the decisions you make regarding organisation pay off).

By happenstance, the system could be attributed the acronym 'GRID', thus, The GRID System for Frictionless Zettelkasten Organisation.

I hope the system might find a way to enhancing your workflows as a base standard, however, any feedback, questions or critique on the system (or its documentation) is appreciated with severe eagerness! (If you're a Github user, you can also do so in the form of an issue on my website's repo)

I'm also starting my masters thesis (near Bielefeld as it happens!) in the area of Zettelkasten. It's concerned with developing a UI tool specific for workflows that follow the Zettelkasten method. It will be usable in addition, and outside of, whatever program you use for Zettelkasten writing. Any feedback will no doubt also help me scale that hurdle in some way, and will therefore be doubly appreciated!

Otherwise, all the best and happy zettling!

Phil

Dead link, my friend.

tjex

Thanks!

I changed the url of the page 30 mins ago or so, but it's working for me. I'd say whatever server of Githubs CDN is serving you hasn't had its cache updated yet.

For the interested, you can just visit https://tjex.net/blog/ and click on the post from there.

Andy

Thanks for sharing your (current version of your) personal note-system specification! The note-system meta-researchers will throw it on the pile of evidence for the proposition that people naturally try to enact typed distinctions in their notes!

ctietze

That's a long overview, thanks for sharing, and welcome aboard!

Since you're familiar with the forums and the players, I want to cut short all introduction of my beliefs and positions and go right to a very narrow question: why did you consider these 4 folders (plus the overarching root folder) at all?

Not: why did you pick the 4 G,R,I,D ones, you explain their use well. But why folders at all?

---

I'm motivated to ask because I did have reference notes that formed to something else over the years. That's when I abandoned categorizing notes (in the note title, with "R" for reference just like you, btw)

msteffens

Thanks for the clearly written write-up. I especially like your notes about "file naming" which I think are spot on.

That said, I was also going to question the use of folders. Can your notes be really separated that cleanly into these four folders? What if a reference defines a "glossary" term, or when a glossary term later gets fundamentally based on a reference? Or what if a complex reference later requires its own index note(s)?

If desired, why not simply use tags to indicate glossary, reference, index & diary notes? These could be combined when needed. Then, if it helps, create smart folders for each of these tags to collect notes of the respective type.

But my biggest issue lies with your assessment of topic tags which I strongly disagree with. Personally, I think it‘s a common misunderstanding to expect searches for a single tag to always result in a manageable list of notes. Tags identify a group membership (and as such can define a search context), but they are not necessarily meant to directly identify individual notes. If filtering for a single tag just returns a few notes, that’s fine of course. But if a tag group contains too many notes, then just continue narrowing down the results list by adding additional search terms or tags. If you want to refer to the resulting list again, then create a saved search or (likely better) create a structure note from it.

My impression is that we often blame overtagging or topic tags to be the issue when it’s often our processes/tools that could help us more to better handle it. In my view, approaches like searchable tag lists, tag autocompletion, tag suggestions (e.g. of similar/related/co-occurring tags) could overcome the tag-related issues you mention.

andang76

I've read your presentation.

I find many similar things with my structure.

The main difference is that I don't use id for filenames, filenames are the note titles and I strongly apply the principle "Note titles are like APIs" taken from Matuschak (beeing a software engineer, this concept is very evocative for me).

Actualy I don't give a lot of importance to a folder structure, I have few folders by broad area of interest (Developing, Photography, KMS, ...) and all notes of all types go to the same folder by area. But I also could live with a single folder, the actual system it's a mere legacy habit...
(I maintain only a by-project folder system for my Work Area, in that area project separation is usfeul but I dont' apply zettelkasten here)
I think your folder organization could be better for my use than others; If I had to change I surely I would prefer this kind of organization (few type-based generic folders) than a system like the well know Jonhny decimal, PARA, and so on.

Works for me, the already cited principles of very-few folders, a limited use of tags and not used for subjects, the great importance of Index Notes and use of links for subject-linking.
I have something like the Glossary Notes, I call them Wiki Notes but do almost the same thing, represents concepts, facts, descriptions. They are some kinds of "pivots" around which ideas, principles and other "more similar to zettels" things gravitate.

About the Index Notes, I would like to know your approach making them. Do you use an "essential style" (an index note is a mere list of links, at most in distinct sections) without any context text, or your index notes are a mixture of texts and links, with the text that give the links a context?
I very like and I often use this second (not always). My "Zettelkasten note", for example, is practically an hybrid between your glossary note and an index note. A general concept note tend to develop this form in my system, often is not a simple list of link, it has at least the general intro of the subject or sub-subject and a short draft of the main concepts (that are developed in linked notes).

I like your system, for me "is good" but I'm biased, because is similar to mine :-)

GeoEng51

@msteffens said:

But my biggest issue lies with your assessment of topic tags which I strongly disagree with. Personally, I think it‘s a common misunderstanding to expect searches for a single tag to always result in a manageable list of notes. Tags identify a group membership (and as such can define a search context), but they are not necessarily meant to directly identify individual notes. If filtering for a single tag just returns a few notes, that’s fine of course. But if a tag group contains too many notes, then just continue narrowing down the results list by adding additional search terms or tags. If you want to refer to the resulting list again, then create a saved search or (likely better) create a structure note from it.

I agree with this point. As discussed elsewhere, you can make tags more specific or you can add other tags and then search on a combination thereof.

tjex

Happy to see some affirmations and also some disagreements with questions! Thanks.

@ctietze said:
why did you pick the 4 G,R,I,D ones, you explain their use well. But why folders at all?

Technical and UI context

I see these folders as containing the absolute bare essential 'objects' that together construct a knowledge generation technology. They each have a defined function, and keeping them ordered as such helps in two ways.

First and foremost is the technical advantages of a directory structure. It reduces the need for querying tags to define the role that a note has. This is particularly useful when working programmatically with a vault via scripts, the CLI or other programs like KeyboardMaestro which are all going to see the vault as a directory structure on your computer. This contributes strongly to future proofing the vault, and also accounts for mislabeled or completely forgotten tags.

I use [regular markdown links](file/path) to help future proof my vault. But this has the added function of communicating to me what the note is without having to open or query it.

This helps my mind stay in its flow as decision making becomes very easy:

[destruction by chickenization](fm8x) is in the root folder. I know it's an elaborated idea.

[destruction by chickenization](r/fm8x) is in the reference folder. I know its a reference of some sort.

[destruction by chickenization](g/fm8x) tells me immediately that I'm linking to a glossary term.

Despite the same natural language in the sentence, I can easily choose to follow or not based on what information I want to obtain at that moment: do I want more clarity on the term, do I want more context on the term or do I want related ideas based on the term?

Intention and Contextual Stability

Folders also re-enforce the 'function' of a note, which helps keep the intention clear when writing the note. I've found the importance of this pays off when editing the note later on. If the 'function' of a note can be changed on a whim from 'glossary' to 'reference' to 'index' to '...?', and edited in future as such, then arriving at that note from a link created long ago could easily yield in a confusion of context, this will break flow and creative cognitive friction.

tjex

@msteffens said:
Can your notes be really separated that cleanly into these four folders? What if a reference defines a "glossary" term, or when a glossary term later gets fundamentally based on a reference? Or what if a complex reference later requires its own index note(s)?

a glossary term later gets fundamentally based on a reference?

In this case (by which I think you're meaning that the entire note takes it's cues from a singular reference (perhaps a concept from a particular philosopher, from a particular book), then the content of the note is still presented factually, but a clear piece of information directs you to the actual reference note for whichever reference the glossary note was otherwise going to become, for example at the top of the note; "This note is fundamentally based on the definitions sourced from [[this book]]".

This means that the glossary term maintains its strength as a mini-index, where you can include and reference links to various notes of value on the term as well.

And the reference note maintains its strength as an index of links to notes that were made with strong intention of linking that specific reference material to another note or context.

Merging these two functions into one note would water down these strengths, which would be unnecessary as both can exist at the same time and be linked together (which itself increases the visibility of both of those notes in your vault).

What if a reference defines a "glossary" term?

I don't see how this is possible. Can you provide an example?
By 'reference' I mean the output of another individual (or potentially machine).
A glossary term is a bare representation of a term (like in a dictionary), defined only by its meaning.

Or what if a complex reference later requires its own index note(s)?

Again, I'm not clear on how a reference later needs its own index note?
If the reference note becomes dense with outgoing links, then great! That is in a sense an index; an index of spawned or connected ideas.

But my biggest issue lies with your assessment of topic tags which I strongly disagree with.

I understand the use case for tags and that they can be used to create a more fine tuned search capability, but the fundamental concept behind the 'GRID' system is to have as little cognitive friction as possible when writing notes.

But if a tag group contains too many notes, then just continue narrowing down the results list by adding additional search terms or tags.
...
My impression is that we often blame overtagging or topic tags to be the issue when it’s often our processes/tools that could help us more to better handle it.

These two statements more or less define the problem at hand. With this tagging approach, whenever creating a note, we need to think about which tags, how many tags, whether the tag exists (yes, autocompletion helps) and if not whether we should add another (which reduces the filtering power of all other tags).

This process also creates a reliance on tags as a way of finding material but it isn't effective.

The combination of these two aspects, invalidates their usefulness for me. Removing such a tagging system helps maintain focus on the content and the execution of creating effective, meaningful links.

Instead, as written I use structure notes to group valuable notes on a topic.

If I really struggle to find something, I use ripgrep. Grepping becomes much more powerful when you can point it at a folder to work on too 😉

I'm sure I took reference notes on this topic = rg 'chickenization' ./r

tjex

@andang76 said:
About the Index Notes, I would like to know your approach making them. Do you use an "essential style" (an index note is a mere list of links, at most in distinct sections) without any context text, or your index notes are a mixture of texts and links, with the text that give the links a context?

Basically exactly like you say.

Here is one I have:

---
title: zettelkasten
date: 2023-12-28
id: 512g
tags: [index]
aliases:
---

# zettelkasten

This Zettelkasten is organised using the [GRID system for Zettelkasten organisation](../ocul).

Reference Notes:

- [Tinderbox Meetup - A discussion with Sönke Ahrens](../r/ti9b)
- [Zettelkasten Method](../g/dkun)
- [Field Report 4 - Six months using a Zettelkasten to write a thesis](../r/dpj8)

Creating Notes:

- [creating meaningful links between notes](../ma31)
- [Implementing Luhmens Zettelkasten](../3iwt)
- [layers of evidence](../r/mulf)

Cognition:

- [thinking with something or thinking within something](../ncfq) 
- [Every hard thing you do is a multiplier on the sum of the rest of your knowledge](../gh0w)
- [how the zettelkasten system promotes creative thinking](../t5v3)

ctietze

@tjex Allow me to reiterate my question, "why folders at all": your reply went into technical details (how) but did not tell as much about the motivation (why), so maybe we misunderstood each other there.

This part has something like a reason embedded in it:

Despite the same natural language in the sentence, I can easily choose to follow or not based on what information I want to obtain at that moment: do I want more clarity on the term, do I want more context on the term or do I want related ideas based on the term?

That probably not the only reason, but the only one you mentioned thus far: clarity of the link context.

Like the cited-by-you Andy Matuschak writes:

It’s often not enough to say “X is related to Y”: better to say “X goes into more detail about Y in the context of Z.”

Your example: folders r/ and g/ are used to disambiguate otherwise same-sounding links and enhance/improve these edge labels.

In that case I'd argue that [destruction by chickenization](...) no matter what comes in the parens doesn't do a good job at "labelling the edge", then.

Supporting claim: the tool you use to disambiguate (folders) could be replaced with another disambiguation tool: using different link anchor texts, aka edge labels. E.g. "John McFly goes into detail on the history on destruction by chickenization" is a much less ambigous label.

So what I gathered is that you use folders to annotate links, but to the question "Why folders at all?", the answer "Because I want more precise links" isn't self-evident.

Is there anything else that prompted you to group stuff in folders? Any pain points you had?

tjex

@ctietze said:
@tjex Allow me to reiterate my question, "why folders at all": your reply went into technical details (how)

Hmm apologies. The technical details weren't supposed to read as instructions of how to do it, but more to point out the value of having folders when working with the vault outside of a Zettelkasten app. E.g., running scripts in the vault, accessing files via regular finder / CLI.

In Obsidian, which I used to use, folders were common variables within the functionality of plugins. In zk, the tool I now use, it also leverages folder organisation for different functions.

Finder on Mac also has folder actions, script editor, etc. They require folders to operate in.

In that case I'd argue that [destruction by chickenization](...) no matter what comes in the parens doesn't do a good job at "labelling the edge", then.

In my own experience, this has very often offered enough extra information to enhance my understanding of the notes context. That's a lot of value gained for me given all that is required is the note being placed in a folder during creation.

If the notes ever get published (like Andy Matuschak) or dealt with in some similar way, folders will offer a much simpler way to handle obfuscation (don't want to publish my diaries) than operating on tags. This is even more so important if whatever system we use doesn't work with YAML frontmatter or whichever metadata system we've committed to (i.e., future proofing).

Supporting claim: the tool you use to disambiguate (folders) could be replaced with another disambiguation tool: using different link anchor texts, aka edge labels. E.g. "John McFly goes into detail on the history on destruction by chickenization" is a much less ambigous label.

I'm understanding here that you mean to use the entire sentence as a link? I only do this when absolutely necessary. But I instead prefer "John Mcfly goes into detail on the history on [destruction by chickenization](g/file) in his article, [chickens - a destructive force](r/file)"

Then I get both links and also maintain the natural titles of both notes, which aids in my recall when making links while writing.

Is there anything else that prompted you to group stuff in folders? Any pain points you had?

My main pain points I had with folders over the years was the battle of managing over-categorisation. I used to have folders in my glossary folder for example, like 'companies' and 'people'. The decision making got in the way of writing. Having no folders meant no organisation on the file system, which outside of the Zettelkasten app can be very inconvenient.

What it comes down to is that at that level of organisation (GRID folders), I find there is measurable advantages on a system level, which aids in future proofing the vault (working with the files outside of a Zettelkasten app, or being able to move to other apps more easily) and link context, without any reduction in "openness", usability of the system or increase in cognitive friction (I've never had an issue to decide whether to place a note in G, R, I, or D folders).

So that was the ideal balance point. Best of both worlds.

ctietze

Thank you for the explanation!

Having no folders meant no organisation on the file system, which outside of the Zettelkasten app can be very inconvenient.

Things like that are where the 'money' in a discussion like this is, I think. That's a pain point. And also an insight into your use.

The technical details weren't supposed to read as instructions of how to do it, but more to point out the value of having folders when working with the vault outside of a Zettelkasten app. E.g., running scripts in the vault, accessing files via regular finder / CLI.

So you also value making scripting easier, and found folders to help there. 👍

I'll stop being obnoxious now

tjex

@ctietze said:
Thank you for the explanation!

I'll stop being obnoxious now

Was by no means interpreted as such! This kind of deep critique is precisely what helps.

Many thanks

Andy

@tjex: I noticed a small detail in your blog post that I was going to pass over in silence as irrelevant to your interests, but I decided it may be worth mentioning here for the sake of completeness: In the section on tags you mention two common types of tags. There is an important type of tag that you omit: tagging with an epistemologically relevant discourse schema or discourse ontology. (There are probably other terms for this; Joel Chan calls a note system that uses such a schema a discourse graph.) IBIS and Chan's more recent QCE are two similar examples of this. A tag in such a schema indicates a type of discourse element such as: issue/question, claim/position, pro or con argument, evidence, concept, method, etc. These types facilitate argumentation in a note system for research and help specify the level of atomicity/granularity that such a system should have. You seem to have no use for such a schema, but I would say it is an important type of tag in general for people who want it.

By the way, I also use a few folders in my note system, for the same reasons you gave to Christian above.

tjex

Hey @Andy . Super cool, I hadn't come across this before.

I agree, that it doesn't align well with the goal of a frictionless system, as there could easily be many crossovers between tag decision making: questions, positions, arguments, evidence (for or against), are difficult to define given that any note can become context to any other note in the future, in which case the meaning of the note's current tags could become confusing.

But I definitely see the value of it for people heavily involved in scientific research within a singular or select few fields.

The three layers of evidence approach reminds me of this too. The process section shows the relationship is at its clearest.

Which then makes me wonder if this QCE system even requires tagging? It seems like all the work is done by following a process and linking heavily and purposefully (linking to all question notes that the observation note relates to for example)

'question' and 'position' tags could be nice, as it's easy to distinguish between them. But since I'm apposed to topical tags, filtering by those tags wouldn't bring much. Instead I would opt for a 'questions' section in an index note, and list some interesting questions I have on that topic.

They could provide a useful jumping in point to help with mental blocks, i.e, 'open a random note tagged question', but I'm not sure how well this would scale. For that to remain useful, topical tags would be required: 'open a random note tagged question and topic'.
But that's then a trade off between filtering functionality and tag management versus cognitive friction when writing and focussing on strong linking.

Got me thinking. Thanks

Andy

@tjex said (on the topic of a discourse schema):

it doesn't align well with the goal of a frictionless system, as there could easily be many crossovers between tag decision making: questions, positions, arguments, evidence (for or against), are difficult to define given that any note can become context to any other note in the future, in which case the meaning of the note's current tags could become confusing.

The point of a simple discourse schema is to add a little friction to increase the future usefulness of the note system (as I will describe a little more below), but a schema also adds constraints, so that not any note can become context to any other note in the future. In standard IBIS, for example, by the rules of the schema you can't directly link a claim/position to another claim/position. You have to think of an intermediate question to connect them. (Also, IBIS includes link types, if only a link type that is implied by a note type: by creating a note of a certain type that links to another note, you are creating a link of a certain type.) In a well-designed schema, such semantic constraints preserve the meaning of each note type in context. You wouldn't have to use the schema for every note in your note system, but notes that use the schema are bound by the constraints.

Which then makes me wonder if this QCE system even requires tagging? It seems like all the work is done by following a process and linking heavily and purposefully (linking to all question notes that the observation note relates to for example)

No, it doesn't require tagging; you could just keep the schema in mind as you work, which you have to do anyway if you want to use a schema. But by tagging the notes, you will have zero friction when trying to understand the logic of the notes later, insofar as the note types are visually salient (if you have a software system that can visually mark notes by tag, e.g. with color and/or an icon—if not, you could add the discourse type to the start of the filename with a letter). The visually salient note types help your future self rapidly understand the logic of the notes, and helps other people rapidly understand the logic of the notes if your note system is public: for an example of the latter, see the "open hypertext notebook" of Joel Chan & friends at Scaling Synthesis which uses QCE with all links colored by note type of the link target (although it is not a very well organized example).

(By the way, when I said "you" above, it is the "impersonal you", not a reference to @tjex, who doesn't seem to have a use for any of this. It's just a conceptual explanation, not advice.)

tjex

@Andy Alright, nice.

In standard IBIS, for example, by the rules of the schema you can't directly link a claim/position to another claim/position. You have to think of an intermediate question to connect them.

This is a nice constraint, I like that a lot. From this I can also see the value in visual salience.