> Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
That is an inherent weakness of mobile OS's and prevents them from competing with traditional computers in workplaces. It works as long as you never want to do anything complicated with your computer, but most people working in offices needs the organization offered by a file system, not to mention how crippling this would be to use as a development environment.
We have systems, but they don’t need to be “files”.
On development environments: we manage all our code under version control, our IDE index all the sources and most of us navigate by pretty unusual ways. I guess we would be fine without any direct access to the fs as long as we had a layer that gave back streams of files we look for and a way to commit changes to git. For a lot of devs I think everything is already abstracted by their IDE.
A lot of people work the same. For instance navigating exclusively through links sent to them, their office app’s “recent documents” and the “open” dialogue with the folder they stored all their docs and might not completely understand where it is exactly (except if it’s straight their “Desktop” folder). I think a ton of adults get by with that on their everyday job.
I’m still largely pro-file-systems, but your comment made me think. Here’s some loose thoughts, just to get into the problem space.
I navigate my codebase at work primarily using the name of the entity I’m aiming to inspect or work on next (e.g. “Popup” or “uiEventStream”)
- usually using fuzzy search. This matches by file ame, but feasibly could operate by entity symbolic name to the same effect
- increasingly using VSCode’s “find references”, which already operates by entity name (at least that’s now the UI appears)
However.. I also use the file tree, because important and meaningful application structure is encoded in the tree. The tree (and its node namez) gives me sections of the app, collections of entity types, and hints how they’re connected. This is invaluable. It helps new colleagues learn the application structure and it helps old hands get to what they want faster. It forms a “silent” background context against which all entity-based decisions get made.
The structure could be encoded as tags, with all the files dumped in a single directory. I have yet to see a tagging interface work as well for tag hierarchies as a directory tree works.
Tag hierarchies are a specialised use, or extension of generalised tags. Tagging systems typically emphasise (through UI and explanatory notes) the unstructured approach. Structure and unstructure are basically opposed so making a single UI work for both seems problematic. Educating users, most of whom wont use the word “taxonomy” in daily life, how to use a tool supporting a model with an almost inherent self-contraction seems like a mammoth task.
To add to that, there is IMO a renaissance of “fuzzy” navigation, with macos’ quick search (the Sherlock/quicksilver clone), and tools like Obsidian spreading the model of moving to apps and file by a set of partial keywords.
I agree with you that a tree structure is important, the same way people still look at trees to navigate pages on most sites, going through categories, sub-categories etc.. More and more the tree is just dissociated with the actual representation, the same ways urls don’t exactly match the site structure on so many sites.
I’d imagine the tags would have some hierarchical relations if we were to use tags exclusively.
Many programming languages have a tagging system for that: namespaces, packages, etc.
Often they have a close mapping to filesystem, but with IDE support that isn't strictly needed. (In reality however it currently is, as the filesystem is the language agnostic common interface between version control system, IDE, etc.)
That is an inherent weakness of mobile OS's and prevents them from competing with traditional computers in workplaces. It works as long as you never want to do anything complicated with your computer, but most people working in offices needs the organization offered by a file system, not to mention how crippling this would be to use as a development environment.