Legitimate use of the Windows "Documents" folder in programs

Question

Anyone who likes their Documents folder to contain only things they place there knows that the standard Documents folder is completely unsuitable for this task. Every program seems to want to put its settings, data, or something equally irrelevant into the Documents folder, despite the fact that there are folders specifically for this job¹.

So that this doesn't sound empty, take my personal "Documents" folder as an example. I don't ever use it, in that I never, under any circumstances, save anything into this folder myself. And yet, it contains 46 folders and 3 files at the top level, for a total of 800 files in 500 folders. That's 190 MB of "documents" I didn't create. Obviously any actual documents would immediately get lost in this mess.

My question is: can anything be done to improve the situation sufficiently to make "Documents" useful again, say over the next 5 years? Can programmers be somehow educated en-masse not to use it as a dumping ground? Could the OS start reporting some "fake" location hidden under AppData through the existing APIs, while only allowing Explorer and the various Open/Save dialogs to know where the "real" Documents folder resides? Or are any attempts completely futile or even unnecessary?

---

¹For the record, here's a quick summary of the various standard directories that should be used instead of "Documents":

• RoamingAppData for user-specific data and settings. This is the directory to use for user-specific non-temporary data. Anything placed here will be available on any machine that a given user logs on to in networks where this is configured. Do not place large files here though, because they slow down login/logout in such environments.
• LocalAppData for user-and-machine-specific data and settings. This data differs for every user and every machine. This is also where very large user-specific data should be placed.
• ProgramData for machine-specific data and settings. These are the same regardless of which user is logged on, and will not roam to other machines in a network.
• GetTempPath for all files that may be wiped without loss of data when not in use. This is also the place for things like caches, because like temporary data, a cache does not need to be backed up. Place your huge cache here and you'll save your user some backup trouble.

"Documents" itself should only ever be used if the user specified it manually by entering a path or selecting it in a Save dialog. That is the only time it is ever appropriate to save stuff in "Documents".

Answer 1

There would need to be some visible incentive. For example, if users had to provide permission to save in the Documents folder (at install time), programmers would want to avoid triggering that scary dialog.

Once you have the incentive, people will naturally stumble upon documentation like "Save machine-specific program data in ProgramData" while trying to solve it.

Actually, a lot of problems could be solved by a nice permissions framework...

Answer 2

My question is: can anything be done to improve the situation sufficiently to make "Documents" useful again, say over the next 5 years?

In theory, something could be done. In theory Microsoft could:

• Come up with a better place to put user setting files (in the process, recognizing that a lot of applications have valid reasons to put settings in files).
• Add this to the standard Windows application developer guidelines. (I assume such guidelines do exist.)
• Make a big thing about applications conformance to the guidelines, e.g. via some kind of certification or by creating and publishing conformance scorecards. "Naming and shaming" could work wonders ...

It must be said that Apple has traditionally been much more proactive with this kind of thing. And it shows in the quality of the stuff that runs on their platforms.

Answer 3

I think you answer the question in that it boils down to programmer education. I don't know enough about the Windows API and if storing stuff in Documents is particularly easy, but if not then applications shouldn't pollute it. I think it comes down to having a per-user known location where data can reside. For the sort of data you talk about, Mac OS X uses the ~/Library folder, though some apps still stick things under Documents. Maybe something similar should (does?) exist for Windows.

Personally, I keep my Documents on a same-titled folder under my Dropbox root, which does add an extra level of work for me, but saves me from the problem you've raised.

Answer 4

Though I understand you want to engage in a discussion about getting developers to stop doing this, it might wind up becoming one of those things like taskbar notification icons which couldn't be stopped so Microsoft just swept them under the rug.

I have previously blogged about the Documents folder, likening it to moving out of a bad neighborhood. As a user, I came up with a bunch of hacks for trying to clean it up on my own. I would mark all of the uninvited folders as "hidden" which would make them disappear from Explorer. I would create symbolic links for Visual Studio 2005, 2008, 2010 folders into a common "Visual Studio" folder, etc.

But even with PowerShell scripts to automate it, I got sick of doing it on every new machine I used. Fortunately, in Windows 7 there's another option that works pretty well for me.

Since Windows 7 tends to default to the "Documents" library as opposed to the Documents folder. I've simply removed the %userprofile%\documents folder from this library and instead added my Dropbox folder. So now open/save dialogs default to this location and when I click Start -> Documents, it takes me to my Dropbox.

Ultimately, I'd love to see some kind of basic certification for apps similar to the iOS App Store guidelines. But they can't even get driver manufacturers to sign their drivers...

Answer 5

Solution:
1. Right Click 'Documents' folder and select the 'location' tab.
2. Change the 'Documents' location to some other place I choose 'C:\Admin\Configs' (once this is done, all applications, writing to 'documents' should be sent off to C:\Admin\Configs instead.

But this solves only half the problem, the next step should be pretty obvious.

1. Create a new folder in 'C:\User\\Documentation'

You should be able then to add that directory to the libraries and delete the old one, I deliberately set a different folder name in 'C:\User\**Documentation**' because I wanted to ensure nothing could just hard path to that folder.

Should the folder 'documents' appear again in your C:\User\ because of the above fact, simply right click the folder and make it an invisible folder.

Answer 6

I think the long-term strategy should be to stop storing anything other than documents in files. System data, especially settings, should be stored in storage systems that resemble a database more than a file system. Bonus points if that database can be easily and automatically synched with a service on the web, so you effectively have one set of settings irrespective of how many computers you use and where.

I don’t know much about the history of file systems, but it seems to me that it was realised pretty early on that system and executable files are a fundamentally different “thing” than documents. So those got stowed away in a special folder (then called directory) like C:\DOS and the user was basically in control of the rest of the drive.

Nobody really predicted how much more complex and unmanageable systems would become over the years and what a mess this would make. I think it is time to rethink the technology from the grounds up and leverage the synergy of the cloud. Bonus points if a workable open-source solution takes off before a company does it :)

Answer 7

Even if some program still store some data in Documents, I think most store their data in AppData instead, so they're already going in the right direction imho, however there isn't much users can do: each program is responsible for what it does.

Answer 8

Storing settings in a text file is a catch-all cross-platform solution.

Unless developers were to create a cross-platform settings database standard, I think most of us will keep using text files dumped to the user directory.

Those of us who are smart will create different settings interfaces for systems which allow specialized settings storage engines (such as the Windows Registry).