I don’t know if this is how I want the next generation of file interactivity to work.
I think I’d like a future where most files are “tagged” instead of put in a specific path, then files are displayed using “virtual folders” which are really just filters, so a file can appear in multiple locations.
For example, the same file should appear under /invoices/all and clients/jim/invoices .
Should we bolt an AI to our existing file system that is doomed to always unorganise itself? Mmm, not sure. Plain text search of file systems (on Mac/Win) is already ubiquitously slow for example, and I don’t trust it to make up for the shortcoming of a 1:1 relationship between file and path.
I like that approach of tagging files to create meaningful filtering and organization a lot. How many times did I fail to find what I was looking for in a file tree only because I was off by one branch at one part of my pathing, when the file would have been "fine" being available in both paths...
In a knowledge base approach that also mean that information should not be bound to a file but available through tagging and references to a lot more workspaces / subjects.
Ex : a technical documentation that would be filled with all the relevant code extracts / third party documentation / custom notes available in the knowledge base, automatically fetched based on the tags and information entered in the tech stack or the header of the documentation.
Comments
I don’t know if this is how I want the next generation of file interactivity to work.
I think I’d like a future where most files are “tagged” instead of put in a specific path, then files are displayed using “virtual folders” which are really just filters, so a file can appear in multiple locations.
For example, the same file should appear under /invoices/all and clients/jim/invoices .
Should we bolt an AI to our existing file system that is doomed to always unorganise itself? Mmm, not sure. Plain text search of file systems (on Mac/Win) is already ubiquitously slow for example, and I don’t trust it to make up for the shortcoming of a 1:1 relationship between file and path.
I like that approach of tagging files to create meaningful filtering and organization a lot. How many times did I fail to find what I was looking for in a file tree only because I was off by one branch at one part of my pathing, when the file would have been "fine" being available in both paths...
In a knowledge base approach that also mean that information should not be bound to a file but available through tagging and references to a lot more workspaces / subjects.
Ex : a technical documentation that would be filled with all the relevant code extracts / third party documentation / custom notes available in the knowledge base, automatically fetched based on the tags and information entered in the tech stack or the header of the documentation.