Is something being 40 years old make it bad? Humans naturally like to put things in hierarchies. It is a very well understood concept by everyone.
1) A list of most-recently-seen documents. Each application would have its own list of documents it had seen, and there would be a per-user list for documents from all apps. Documents are added to the lists when they're created, opened, downloaded, etc. There is no limit on number of documents in the list, and the list is searchable. Some modern applications have primitive equivalents, but not as the primary document-opening interface.
2) Give each list a search box, with results as a flat list of extracted metadata. Honestly, just clone the current standard web search engine UI and use that. A search box is the closest computers have come to being user-friendly, and is certainly nicer than dropping the user into a file manager.
---
Example: Firefox's "recent documents" list would be a combination of browser history and downloads panel. To open a file you just downloaded, find it in either Firefox's list, or the global list, and click/tap it. To open a web page you just created in a text editor, you would click/tap it in the global documents list and indicate that Firefox should handle it (e.g. with an Android-style app selector).
Keep existing file-management API calls as they are, and don't tie them into the document system. I don't want a game to add a new document entry for every .so or .png it loads. Application developers can decide how best to represent their document in terms of low-level filesystem objects (a directory, a flat text file, a binary blob, whatever fits the document best).
So: God at the top, then the king, then the barons/lords/etc until you get to the peasants at the bottom. Easy to understand.
Or: shopping centre at the top, then different floors in the shopping centre, then various shops, then aisles in the shop, then vaguely demarcated lengths of aisle, then shelves, then individual items on shelves. Fine.
But: a folder at the top, then more folders in that folder, and further folders in those folders? And all those folders look the same (only the names are different. Actually, sometimes the names are the same as well). That is a bit confusing for most people.
Also consider menus. A menu bar across the top, with a single level of drop down menus underneath? Easy peasy. A start button with a pop up menu, that contains more pop up menus, that contain still more pop up menus? Disorienting. Microsoft thought the only thing holding back deep hierarchical menus was mouse control, so when they refined that for Windows 95 they went crazy with menus inside menus inside menus. Mistake. They've been trying to flatten and differentiate different levels of the start menu ever since.
Meanwhile, programmers need to be good at abstraction, so have no problem with undifferentiated folders within folders within folders.
Yet the first thing anyone does when they're looking for something is to Google it, not go to Yahoo's front page, look for the relevant category, find a suitable sub-category, ad nauseam. There's a reason search won that battle.
No it is not.
So if you have a magical medium where information can be abstracted behind any means of retrieval, you give the apes what they want: their bananas in a pile, instead of in tiny, head-scratch-inducing drawers.
I observed two different distinct species - one will just dump everything into the desktop (or the My Documents) folder. The other will place all of their files in subdirectories, or sub-sub directories, in a very organized manner. If you look at their real life organization techniques, it would very likely be the same.
Not very well, which is why so much time is spent trying to avoid increasing navigation depth and reducing the amount of views to minimum.
> They can find a food item in a menu or in the supermarket.
First time I see a menu that's comparable to a filesystem tree I'm going to burst out in laughter and think it's a gimmick. A supermarket is closer to an art statement about inherent chaos of modern lives than to anything hierarchical.
Yes, there are hierarchical systems, the big one being a common management structure (which works eh), and administrative subdivision of countries (hint: people almost never actually traverse that tree, they always go directly for a specific entity in it. Also, they routinely get lost in it). They're a bother and used when they can't be avoided, or when nobody bothered to work on something better. Or when you need to sort a bunch of numbers or something. The reason for avoidance being, besides the low transparency, complex data maps into trees really poorly.
That's not the case for computer documents.
Barely. Perhaps you never read the complaints people have about webpage navigation, or noticed that almost no user understands hierarchical URLs.
You know what the top Google searches are? Stuff like "fb", "facebook", "twitter" etc. Because people cannot even understand they can write the URL on the address bar or remember it.
>They can find a food item in a menu or in the supermarket.
You kidding me? People can barely find stuff in the supermarket, and only after searching and scanning with their eyes the shelves. For items they haven't bought in a while, they have to check the sings over every isle, or ask a supermarket employee.
Really bad example.
E.g., first I want to find all files tagged with "code", then I want to find all files tagged with "current project". Then I get a list of all files in a current project and possible tags I could look for (e.g., it will show many are also tagged with "java" or with "C++" so I can add those tags to my search).
The problem is historically (that is, until recently) these kind of queries have been prohibitively expensive in both space and time: there's time complexity of doing a boolean query on the index, there's the space complexity of storing the index amenable to those queries both on memory and in-disk. This is difficult to in the context of legacy desktop machines (think minimal requirements to run Windows XP: 256mb of RAM, 5400 rpm disk, pentium III cpu) that were prevalent until just a few years ago.
Instead, the solution chosen is the same solution that folks building distributed "NoSQL" databases or sharded SQL database setup go for: group all related data into a few rows (in this case directories) and treat the data as hierarchical (a return to pre-RDBMS era).
Today if your working set fits in main memory (which is most probably the case for even the biggest data collections on most people's personal desktops), there's no longer a performance related reason to use a single-node (non-partitioned) "NoSQL"-style setup (there may be other reasons to, e.g., wanting to have a more flexible schema, saving time, wanting to scale out later, etc...)
I suspect the real reason we haven't done this with file systems is due to legacy: I have data organized into files and folders going back to ~1998 that I do not want to lose and can't afford to tag manually.
The support from my theory comes from the fact that the first systems to embrace non-hierarchical file system have been legacy-free devices where important storage (for 99% of the people out there...) is either on the SIM card (addresses), in the cloud (mail) or is de-facto tagged and has to be copied over in any case (photos which have EXIF tags and are stored in photo album apps or cloud services).
The same has also been happening on the other end of the spectrum: e.g., large scale distributed storage system for much similar reasons (i.e., they are the first of their kind, so there was a "license" to build these systems in a legacy-free fashion).
tl;dr Hierarchical storage is a non-functional requirement. Functional requirement is being able to do complex exact queries.
The opposite should feel weird to you. The notion that files belong in some kind of tree structure. It's just an artificial implementation we came up with, more Platonic than realistic.
A file doesn't belong in some "node" in a "tree". It belongs to multiple nodes all around the tree, including "nodes" that only make sense for that one only.
A tree hierarchy FS doesn't reflect that (except if you go crazy with symbolic links). And then it doesn't scale with lots of tags, or tens of thousands of files.
A tagging/metadata system is a far better way to manage those files, and closer to they way we think (associating attributes with objects, remembering based on keywords, etc).