Apple tries to fight this by providing ~/Library as a place for applications to put whatever support files they need, but there is still a shit-ton of garbage dumped in ~/Documents by various applications. The fact that ~/Library is hidden by default probably doesn't help make it an attractive place to put all the junk your app generates.
Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.
Genuine curiosity, do I understand it correctly you specifically make a sub-directory under the default ~/Documents directory for the purpose of managing your documents?
I don't find this weird or unusual at all, just different than how I've handled file management on computers since I was a child using the family computer; I did notice the way computers stored program data when I was first learning computers and while I had a vague understanding of how programs worked, the conclusion I came to as a child was "just don't mess with the stuff the OS uses and make your own folders instead."
Usually I have my personal documents in some folder(s) under / or on dedicated drives, separate from the OS/program directories entirely whenever possible, and I treat any pre-existing folder structure as "the OS' and programs' folders" and just don't use them at all (with the exception of ~/Desktop and ~/Downloads which more or less I use normally) I understood early on that developers might make their workspace just about anywhere so I don't particularly care about the system defaults and instead try to keep my data in its own location outside of any system defaults whenever possible. The before-mentioned ~/Desktop and ~/Downloads I treat just as temporary directories for me and fair-game for other processes, so my workflows specifically don't keep any personal or sensitive data in common system directories.
I did not ever specifically do that. If I was starting up a new digital life now I would probably do that. But when I started using OSX, I made a few directories in ~/Documents (before it became apparent that every program under the sun was going to have a chance of shitting something in there, and the vast bulk of what I do lives in one of those directories.
(Actually, it lives in a sub-directory of one of those directories, with a disused organizational scheme lurking around it, but, well, if you want more details on that there's a whole blog post: https://egypt.urnash.com/blog/2019/01/06/how-i-work-file-org... )
Back on the Amiga I had something like four partitions on a then-massive hard drive, one for the OS, and three for My Stuff, which I managed however the hell I pleased. But that's not really an option on a laptop.
Wouldn't it being hidden make it much more attractive? You can put junk it in and users won't complain, and if they do want it you have a help article on your site.
I remember asking a games porter (from Windows to Mac) once why they put savefiles in the Documents folder instead of Library (some older games of theirs did put them there) they replied that because after Mac OS X changed the Library folder to be invisible they had people contacting support being unable to find the savefiles, so they put it in a place where it was visible.
I'd expect the "less attractive" part is for when you do want users to find the data your program creates in general.
That's an interesting use case. I guess there's a class of users who are smart enough to want to manually copy/backup files but not smart enough to know about hidden folders or standard directories. Windows has a similar situation with its hidden AppData directory, and Unix with its hidden dotfiles.
I hadn't given this much thought but now I am disappointed that the people who came up with these standards didn't do more UX research and trial & error with actual users. Perhaps if they paid attention to all the use cases and stakeholder needs it wouldn't be such a mess.
No, because part of the point of all of this is “how do I move my config to other computers, or manage it across multiple computers at once?” Hidden “junk” gets lost, is hard to support, etc.
Even within ~/Library, there is organization. In the lists below, $app is either the application name or the application id (e.g., `lazygit` or `com.foo.bar`).
- ~/Library/Application\ Support/$app - sometimes used for configuration, sometimes used for support data, sometimes for other things entirely (including caches, but that is the wrong place); probably similar to $XDG_DATA_HOME.
- ~/Library/Caches/$app - equivalent to $XDG_CACHE_HOME.
- ~/Library/Logs/$app - no direct equivalent, but ~/.local/var/logs.
- ~/Library/Preferences/$app - mostly $XDG_CONFIG_HOME, but $app in this case could simply be a single plist if that's all you need.
I mostly find myself annoyed when command-line apps use those directories, because it makes shared configurations between Linux and macOS that much harder, even with chezmoi. At the same time, respecting that over the non-native XDG…is what this article is about, no?
Not that the author gives any time to macOS except an ignorant swipe at macOS windowing (you don't like it and you're not used to it; that doesn't make it wrong).
Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.