Flat Zettelkasten - misguided advice?

pat

The conventional wisdom of Zettelkasten is that it should be non-hierarchical. I am starting to think that it's well-intentioned, but misguided. In particular, it conflates storage and presentation. That is, you can have hierarchical storage, and still allow for non-hierarchical presentation.

For example, you can have the following file structure:

But still have the following view of it:

(okay you can't actually have that view of it since it's from The Archive, which doesn't read from subfolders... but it's theoretically possible )

The command-line difference here is ls *.md vs find . -name "*.md".

So I'm wondering: is there any practical reason for insisting on flat file structure? I believe that non-hierarchical navigation is a useful option. But I don't think it should be imposed on the storage structure - and in fact there are very practical reasons to organize files hierarchically, while still navigating them non-hierarchically.

zk_1000

is there any practical reason for insisting on flat file structure?

simplicity is one. You are separating a storage solution from the note archive. It is not misguided, you are still following ZKM on top of it. To me, only a few of those subfolder have proven to be useful in the long run. For many the line became blurry and eventually, meaningless. It started with notes which i created in one folder which later should belong to another. After a while i didn't care anymore. There is practically no cost in giving it a try, since you can revert it anytime later with a simple mv *.md ..

pat

It’s not hard to try - it just doesn’t work with The Archive. Unless I’m missing a setting somewhere?

ctietze

In the beta, we treated subdirectories as if they didn't exist and basically did what you propose (to some extent, at least), but then you need another app that can do the same in the future, so we decided to favor portability aka software-agnosticism over keeping this.

You could argue that ls **/*.md | grep "where is my stuff" is simple enough for tech-savvy people, and thus there's maximum portability of treating directory hierarchies as flat, but that's not the kind of audience that was our concern there

pat

Makes sense

r1tger

I think tagging will sort of allow you to do this, if you think as a tag as a subfolder. You won't get nesting of tags, but you can have a single note in multiple "subfolders" by adding a tag to multiple notes.

Will

Maybe @r1tger is on to something.

Tag Map

#rootTag1
    #rootTag1 #level1
        #rootTag1 #level1 #sublevel1
        #rootTag1 #level1 #sublevel2
    #rootTag1 #level2
        #rootTag1 #level2 #sublevel1
        #rootTag1 #level2 #sublevel2
#rootTag2
    #rootTag2 #level1
        #rootTag2 #level1 #sublevel1
        #rootTag2 #level1 #sublevel2
    #rootTag2 #level2
        #rootTag2 #level2 #sublevel1
        #rootTag2 #level2 #sublevel2

(Substitute your structure into the root, levels, and sublevels.)

Tagging is a dedicated query and grouping scheme. This characteristic might be twisted into service.

This may even have some advantages over the folder paradigm. Like "a single note in multiple "subfolders" by adding a tag."

There is the disadvantage of the difficulty of visualizing a tag map instead of a folder map. Maybe some schematic here would help?

pat

Yeah, and I definitely appreciate being able to organize my content in multiple ways.

I suppose I wasn't upfront about my intentions with this question: I like The Archive as a browser and editor, and so I keep project notes in my archive folder. If it supported recursively finding notes, then I could start to move project notes into their own folders but still retain the flat view of them.

NiranS

I think the answer is -- it depends. Is the data defined by well demarcated categories or are the distinctions more nebulous. I also think tags and organizational notes/maps of contents provide more structure for a Zettelkasten collection. The reasoning behind a flat structure is to remove the friction of categorization and allowing structure to emerge when exploring a field.

My work notes are technical and extremely categorized. They are kept in Devonthink and siloed with folders and tags. When I am referencing material, I want answers very quickly for my technical questions.The beauty of Devonthink though is that it will find "similar" documents even across databases, so there is some serendipity.

Notes that I want to think about, develop and by their nature are a little more nebulous to categorize live in the Archive/Zettelkasten.

Will

@NiranS beautiful dog. What's her name?

I agree that serendipity is great. I feel that this is something to be cultivated and as you say, "The beauty of Devonthink though is that it will find "similar" documents even across databases, so there is some serendipity."

I'd think that reciprocal serendipity could be set up when in The Archive using Devonthink's x-url-callback scheme by adding a search for x-devonthink-item://whatyouarelookingfor. The Archive supports inbound from Devonthink with an x-url-callback thearchive://search/whatyouarelookingfor.

jandamm

In my opinion it is very valuable to just create a new note and don't have to think where to put it.
If you apply some sorting you have to sort everything otherwise it's harder to find a note which should be in a subfolder but isn't there.
Of course you can add some kind of an inbox folder but this adds even more complexity.

pat

You can put notes in the top-level and then move them later. Having a folder structure doesn’t force you to make a new decision. Sensible defaults allow the same fast workflow but allow for another level of organization.

pat

@ctietze said:
In the beta, we treated subdirectories as if they didn't exist and basically did what you propose (to some extent, at least), but then you need another app that can do the same in the future, so we decided to favor portability aka software-agnosticism over keeping this.

Is there any reason this couldn't be an option? Default it to off, but give me a checkbox that recurses subdirs in my notes dir?

ctietze

The current justification is a mix of 'avoid feature creep' and 'don't increase maintenance cost'.

1. We wouldn't know if it's enforcing good or bad habits, and would need to experiment before adding this back in to avoid just adding one more thing and then another and then another until the app gets weird.
2. Plus there's still stuff on the roadmap that's 'officially' deemed important, so adding this would require time investment incurring opportunity cost, and then also require ongoing maintenance and testing, potentially slowing down the progress of the roadmap items further.

---

Let me illustrate the consequences of this particular change, listing files in sub-directories, with an example: displaying inline images.

Resolving relative paths to image files in the Markdown editor is simple with a one-directory policy. The path media/image.png is resolved against the note directory, which is also the directory path for any note you can see.

But once you introduce subfolders, moving notes between these sub-folders requires attention to detail: does moving a note require changing all relative paths in the note to keep file references working? When you move the note into a subfolder, the image file reference needs to become ../media/image.png to get to the main directory first and then into the media directory. Or is this the user's job so we don't mess around with their notes?

Does the app's displaying of search results needs to be re-designed to show the folders so users see the directory hierarchy? Probably yes, because if it's a flat list like now means it's hiding subfolders. That's a disconnect between the hierarchical file system representation and the flat search results list. That means you wouldn't see that you need to write relative paths to include images differently. Imagine you are editing a note in the relative path projects/phd/overview.txt and all images are in media/, then you need to know that this overview.txt note is 2 levels deep so you can write ../../media/image.png to reference an image properly. Or you need a new interface to do this on behalf of the user, hiding the file system details instead of requiring to type relative paths. -- All of this is weeks or months of work to create a proper solution around the admittedly simple "include sub-directories when listing all files" command. The file listing is the trivial part. Making everything work with that is the hard stuff

Doesn't mean it's never going to come back, and I'm keeping track of requests like this for further discussion, but it's not likely we will reconsider this in the near future.

pat

Thank you for sharing that... it makes a lot of sense, and I now have a more informed opinion of why to prefer a flat file hierarchy