There's no flow between the OS and application UI in most instances.
I think because we're so used being able to catalog, measure, categorize and sort our various files and directory structures, manipulate them programmatically, have our browsers or operating systems identify a particular leaf by reference or just by searching for some of the micro-structure within it (usually words) etc. etc. we tend to overlook the organicess of how a data collection grows and opt instead of producing analytics measuring it. It'd be like trying to describe a tree with tables of vector statistics about the angle and length of branch sections - it's valid in certain ways, but doesn't give you a good sense of the tree's shape or structure. It's as if we've developed a sort of techno-myopia towards the shape of our own output and activities, and approach everything by dissecting it into slices and then ranking them by various criteria.
Microsoft Bob is probably the most infamous example. An early-dot-com-era roommate worked at Xerox PARC which had its own spatial 3D file manager / management interface. There were three principle problems:
- It severely taxed the limits of available consumer hardware at the time.
- It was confusing as hell.
- It didn't solve any real-world problem(s), and made numerous others worse.
Though in fairness it did somewhat resember Doom / Castle Wolfenstein....
File or document management shouldn't be the most intensive process your computer does, it should be one of the least intensive, saving processing power for Real Work, and not being resource-starved when you actually need to use it.
The organisation(s) that seem most useful are lists, lists of lists (hierarchies), tag-based systems, or search-based systems. (The fact that file-based search remains primitive in most system is its own small wonder of modern computing, though yes, the situation is slightly improved over, say, 30 years ago.)
I think part of what made 3d and other very visual file managers so bad (or at best, very slow like Treemappers) is the effort to render everything accurately at once, which is bound to be slow across terabyte scales.
Maybe we would be better off exploring Voronoi/blob/fisheye network diagrams for representing context, with the size indicating the number of files nested within. The Carrot2 search engine implements a variation of this idea which is sometimes very useful for topic exploration.
I've had a fair bit of experience with large book archives (university libraries), and have a pretty good sense of what "a million books" looks like (a large on-campus multi-storey building might house 1--5 million books). There's a physical progression, from the words on a page (~250 typewritten, about 500 typeset), to pages in a chapter, chapters in a book, books on a shelf, bookcase, aisle, library floor, building, campus, etc.
A well-organised library gives structure to navigating that space, logically, metaphorically, and literally. And there's a lot of hard work that goes into that organisation.
Simply tossing a 3-D overlay onto a file manager ... isn't that. And most of the projects I've encountered either don't realise that, or don't give that fact its due.
For that matter, the concepts of search and locality (as in, works near each other) have entirely different manifestations online and in a physical archive. Shelf-reading is still one of my favourite pastimes.
So - for example - instead of folders you'd see the same list of popular/recent/alphabetised projects in every app.
And you could link project collections into super-projects with links and/or copies of specific data and working environments.
The nested filing cabinet + aliases metaphor is old and never really worked all that well anyway, but we're stuck with it because it was easy to implement back when all of this was first designed and computers were a thousand times slower.
Saving a file in Excel now is a huge hassle. They WANT me to save to one location in my OneDrive folder, but I hardly ever want it there.
Modern computers are trying to move away from the concept of a “desktop” or filesystem, and instead you open up the file you want from within the program that you use to open it. It would be like you have all your cds in a big jukebox that you can select from, or all your documents in a big binder, or something like that. They become isolated within the devices you use to read them.
It may be better for some people, but that is not how I like to organize things. Particularly when I want to move something from one device to another.
Luckily I have the kind of memory to put things somewhere and then know where to look a year or more later, but in the last year or two I've noticed that I'm using the quick access (ie your 20 or 30 most recent files) in a very similar matter to a stack in assembler. Also a lot of my busiest folders are sorted by date rather than filename because I depend heavily on the contextual memory when I learned things.
You can copy and paste paths between file manager and Open/Save file dialog in most instances.
Directory Opus (a file manager for Windows) somehow extends most Windows file pickers so Ctrl+G moves the file picker to whatever folder Directory Opus has open. I still feel a twinge of satisfaction every time this lets me skip re-traversing my file tree. I don't think it does anything for a Qt file picker though.
Metaphors for everyday actions don’t need to be about forcing the real world into the computer world. A lot of the ways of thinking feel like they are one and the same.
Another example, for me, off the top of my head: rummaging with find and grep but then scanning the output with less feels identical to hunting for red 4x1 Lego blocks or M8 nylon locking nuts.
To me, working in a new unsaved document feels uncomfortable. The idea that your Word window would already have an underlying file in the correct folder is reassuring. You can smash Ctrl+S all you need.
I'll often use touch just that way, in part because I can also apply standard features / functions in the process, particularly a datestamp:
touch <mnemonic-$(datestamp)>
datestamp () { date +%Y%m%d; }