//

Defending Complex Folder Hierarchies against Karl Voit's Critique

"Don't Do Complex Folder Hierarchies - They Don't Work and This Is Why and What to Do Instead" by Karl Voit
https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/

So I did the whole thing again. Requirements analysis, data analysis resulting in a new concept. Much better than the one before. Re-ordering many items from the old hierarchy to a new, better one is tedious.
After multiple iterations doing this, I realized the large amount of effort which was invested for just the next temporary "solution". This had to stop.

Hierarchy is necessary for expressiveness, but infinitely tedious in implementation and maintenance. The solution is just-in-time (JIT) refactoring, which the Textmind algorithm implements.

Learning about Inbox Zero for email management, I got rid of my hierarchy there. It was a rewarding experience, not having to move emails into more or less fitting sub-folder.

Email shouldn't be organized into a hierarchy. It's a database. If one has a hierarchical personal knowledge base, then it can refer to emails from its hierarchy explicitly and implicitly, and the emails are sufficiently discoverable using the dedicated email interface, with no additional manual organization.

File management concepts and navigation-based retrieval was my research domain.
research shows that the average person will end up with one hundred thousand files, 440,000 emails and 120,000 digital photographs.
The problem with this that when you order anything using one concept you are not ordering them in infinite concepts minus one.

The point of PKM is to be individualized. Which is why ordering should be an intuitive blend of all major systems the user feels are relevant. The resultant ambiguity is fine because it forces the user to engage with the content and think about its essential structure. Since refactoring is JIT, this is productive to think about.

Unfortunately, you can not put real-life items in a totally strict hierarchy without logical conflicts. Whatever structure you're coming up with, I can easily construct endless examples where its uniqueness fails.

Which is why refactoring is JIT, so that the current task resolves ambiguity to one best choice. Worst-case, one adds a link if an atom absolutely needs to exist in two locations, but this is rare.

Sometimes it is hard to recognize that you're not going to find the item in this sub-hierarchy. You have to go through a number of locations until you realize that you followed the wrong sub-hierarchy. This is lost effort and often leads to the wrong conclusion that the file you're looking for does not exist here. This is the worst case scenario for every retrieval task.

Not if refactoring is JIT. Then it is productive engagement: Understanding one's prior schema and if necessary updating it. Lots of tacit info is succinctly presented this way.

For example when you save an image from your birthday party you most likely choose a directory related to your birthday event. When retrieving, you're probably looking for an image of aunt Sally. That is a totally different context and chances are that you don't look for the perfectly nice photograph of aunt Sally in the directory of your birthday because in this particular situation, you forgot that she was attending the party.

Images lend themselves to tagging, unlike plain text. Facebook is a good tool for the above use case thanks to its crowd and automated tagging.

All relevant studies show that for file retrieval on the local computer system or local network, navigation is chosen over search in the absolute majority of cases.
My recommendation is that you follow the same rationale that librarians did centuries ago. Don't spend much effort in organizing the files. Follow a very flat hierarchy concept and invest your effort in advanced retrieval methods instead.

Incorrect. Librarians do general knowledge management (GKM), not PKM. The point of the latter is customization for depth. Otherwise it is redundant with GKM. One's GKM should be contributions to collaborative platforms such as InfoGalactic.

Instead of curating a directory structure, you should curate a controlled vocabulary of tags.

Much harder to maintain than a hierarchy. A hierarchy is basically tags with inheritance and less typing. Also a bad solution for plain text, which is inherently more malleable than files.

Tags are good for binary files, and I think git-annex is the correct foundational tool to manage them. Git-annex also supports multiple hierarchies via branches.

Publish At: Author:Cyberthal

Read more posts by this author

Github
comments powered by Disqus