I'm a user. I hate file hierarchies. IMO, the ideal interface to a computer's data storage system would have two ways to find a document: 1) A list of most-rec

I'm a user. I hate file hierarchies. IMO, the ideal interface to a computer's data storage system would have two ways to find a document: 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).