Why Folders
I’m not going to bore you with what folders are. Okay, maybe a little. They existed before operating systems and computers (what a surprise). The idea is that a folder is a general category that holds items belonging to that category. This folder would then sit in a drawer categorized by a broader, more general category. The folder itself would also have sub-categories, organized by those little tabs. This concept was brought to the operating system, and it makes a lot of sense. They work the same way. However, when it comes to PKM (Personal Knowledge Management) tools, there’s a huge problem… the pitfall of over categorization. “What are my most general folders?” “Should this file be in this folder, or that one? It kind of belongs in both…”
Why They Don’t Make Sense
Our ideas are complex. Complex in the sense that the connections between them are endless. Folders are rigid; they don’t support this system of complex connections. A file must fall into a single folder, while an idea can fall into multiple categories.
Let’s say you just started taking notes. Your files are initially in a flat structure, no folder in sight. Then you decide to get organized. The first thing you have to do is come up with the most general domain or area your files fall into. You settle on Work, Personal, and University. These are the general categories all other categories fall under. You start putting the files into their respective folders, until something stops you. “Hmm, this is a log file. I have logs in all my main general folders. Does this mean I have to create multiple ‘Logs’ folders for each of them?” You do that and then realize you want a single view that shows all your logs for quick access. You can’t do that easily. So, you start using properties. Your work log files will have the property domain, which would be Work, and a subdomain, Logs. Then tags for nuance. This sounds like a better option than having infinite sub-sub-sub-sub domains. Two properties and tags sounds good.
Does this sound INCREDIBLY time-consuming and frustrating?
YES, yes it does. At least to me, it does. So I was thinking, there should be a better way. Why in the world would I have to list down the properties when the folder structure ALREADY describes the file? Personal -> Personal Projects -> Why Folders Suck. The structure already speaks for itself. So why are we forced to add properties to this file, just so we can have some flexibility in this rigid system?
How to Get Rid of It
How folders work in the OS is simple (okay, it’s not REALLY simple, but I’m going to simplify it): you have a folder, and this folder can link to other folders. There you go—a single value that basically decides the connection between them. The root folder will just have no link.
I took this idea into the Obsidian plugin I made (btw i haven’t mentioned it yet but its called Abstract Folder). I realized the folder structure ALREADY describes the categorization of the file. All I need is a single value that makes a connection between one file and another. I wouldn’t even NEED folders, muahaha! And, plus, I can add as many parents as i want! (I later realized there are other use cases for these files, and our entire OS is built around the idea of folders, so getting rid of them would cause problems).
I decided to create that connection using the front matter of MD notes. Easy solution! Now, if I have a file called “why folders suck,” I can link it to a parent “folder” called “personal,” and it would essentially be categorized, kind of. I would be relying on the connections only. No “physical” folders needed at all. But this causes a problem. Some files don’t have front matter. Actually, most files don’t have front matter. Also, if you don’t know what front matter is, on Obsidian it’s basically the YAML properties at the top of notes to list attributes.
There were a few options to fix this issue. But I realized the easiest and best solution would be to just have a unidirectional relationship. A parent can have parents, but it could also have children! So, in the parent file, for example, “Personal Projects,” I would have a property called “children” which lists the children of that file. The folder structure would basically be built by looking at both the parents and children!
A lot of issues solved, a few left. I mentioned the problem of having no folders at all. The entire operating system relies on this system. If you wanted to transfer your files somewhere, or even migrate from Obsidian to another app, everything would be flat. So I fixed this. I created a conversion tool that exports a folder with all the files, based on the connections they have. I also created the conversion tool to do the opposite—from your typical folder structure to the format this plugin uses, which is the idea of having abstract folders. The conversion tool (put simply) just checks the folders and their content, and adds the properties accordingly. If they’re not MD, they would be declared in the parent as children.
I also decided to create other usability features, including:
- Colored indents to distinguish tree view depth (with customization)
- A vertical Miller column view (like the macOS Finder column view, but vertical).
- Workspace groups: You can create different groups to switch between different filters. For example, your work group would only show the children of work.md and todo.md.
- Icons.
- A lot of compatibility features:
- Showing the file format if it’s non-MD.
- Right-click showing the list of menu items, including other plugins.
- Creating notes using right-click, both in an empty area as well as in the context of files (e.g., create a file under this file).
- Aliases.
- Sorting.
- Other stuff I can’t really remember but are minor anyway (minor to conceptualize but not develop…).
The plugin is not all rainbows and sunshine, though. There’s an issue. In the typical folder system, you can have files named the same as long as they belong in different folders. But in a flat structure, you can’t. I had a few options to solve this, like using an ID instead of names, but that would cause other problems. So I just added aliases. You can have a descriptive file name and then add an alias property to describe its visual name, or just use the command that would automatically name the file for you if there’s another named the same.
Now you have these privileges:
- Use the “Folder” as an actual file! You know, just like how notion does. You can note things that are relevant to this general category inside it!
- Create ghost nodes! you can have a parent file called logs, your work, personal and university logs could connect to this as well for to contain them!
- Icons.. you have icons! (Theres other plugins for this, but i added this feature anyways)
- You don’t have to worry about “Not being able to go back” because you can! you can always convert your flat structure to an actual folder structure!
- Hide notes. Oh yes, I had forgotten to mention this. But you can hide entire abstract folders!
- You can also send me money, links in the github repo ;). I should have probably put this all the way up because not everyone would make it down here. But if you did, thanks for reading!
P.S. The plugin is not in the official Obsidian plugin list (the obsidian team takes months to review new plugins), so if you want to use it, go to the repository on github, find latest release (on the right), download these three files: main.js, manifest.js, styles.css. Then go to the folder where your vault is (typically in documents), and show hidden documents. You will see a folder called “.Obsidian” which contains another folder called “Plugin”. Create a folder for the plugin called “abstract-folder” and paste the three files you downloaded into here.
Just a side note, even though I made the plugin myself, I still think you should be cautious about what you download on your computer (It becomes a habit). If you’d like, you could build the plugin yourself by cloning the repo (please follow the policy i have attached)