Key insight. One annoying thing in many workflows is different programs and file environments (GUI or CLI) bein gout of sync with the patterns of the work I'm doing; why (I ask myself) am I having to traverse the same routes around my directory tree like a squirrel carrying nuts and and berries back and forth?
There's no flow between the OS and application UI in most instances.
You're welcome, I'm sure. I'm lucky enough to have a decent size yard and I spend a lot of time trying to see things from the perspective of the animal and plant life that inhabits it. A lot of our information problems (imho) come from too much detail of specificity at the wrong scale. You don't look at a tree as a collection of leaves, or draw one by cataloguing all their sizes. Likewise a tree rarely grows as a pure function of its DNA-encoded phyllotaxis patterns, but rather a combination of those and the variations of its environment - soil composition,w ater, other roots, helper fungi, sunlight, prevailing winds, and local animal life. It's truly amazing to watch the interactions between different plants and trees over a period of years.
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.
That goal has been stated and sought repeatedly, usually with poor results.
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.)
Oh yes, I remember being impressed by its awfulness. by comparison Clippy was...not terrible.
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.
Render lag and lossyness is part of it, but there's more.
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.
What you really want a lot of the time is New for Project (...based on template, or based on copy) with support for projects built into the OS and applications.
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.
Sort of… it is the idea of having a bunch of files that are multiple types located in an organized space. E.g. in your home office you may have papers, but also notebooks, envelopes, cds, etc; whatever you find is useful for storing information. You have them organized on your desk in a way that works well for you. If you need a tool to read one (like a cd will need a cd player) you bring the item to the tool in order to use it.
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.
I've gone to a very document-heavy workflow over the last few years. I still program but a lot of what I do is about collecting and curating documents and data on people and organizations and then synthesizing that information in various ways, sorta like business intelligence. So I have maybe 20-30k documents/media and maybe ~100 top- and second-level folders that I access regularly.
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.
Sure, it's just a pity there's no kind of shared context, such that if the last 8 or 10 operations were in a particular folder, a new operation with a similar document type might default to looking there.
On Windows, there is a shortcut to recent folders on the left panel. Also, in most open/save dialogs the file name field has a history pop-up list with full paths. You pick one, delete just file name, hit Enter and jump to it's folder.
> There's no flow between the OS and application UI 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.
There's no flow between the OS and application UI in most instances.