There's a huge difference here between Mom, Dad and Uncle Fester using a computer and professional or business users. The first set of users can be either lazy

There's a huge difference here between Mom, Dad and Uncle Fester using a computer and professional or business users. The first set of users can be either lazy or oblivious to the idea of organizing their data --directories or databases, it doesn't matter. It's a pile-o-stuff and they really don't think far beyond that. For this class of users making it super-simple is a good idea. You sort of have to protect them from themselves. I know doctors who have absolutely no clue as to where their stuff is stored and have zero interest in investing fifteen minutes to learn the basics of directory structures and file management. Zero. The second set of users, the pro's and business users --to generalize-- are a different story. Take the case of a company that designs physical products. Each project is likely to live inside a directory structure segregating and organizing areas or work such as: mechanical design, schematic, pcb layout, bill of materials, design calculations, documentation, embedded firmware, FPGA code, cost calculations, marketing materials, packaging design, manufacturing, specifications, etc. In turn, each of these categories will rightly have its own subdirectory structures when and where it makes sense. The above per-product directory structure is also likely to be completely replicated as product releases and revisions require. Not everything can be handled by Git-type version control systems. In fact, in product design there are very good arguments for complete design duplication during iterations or to mark release (as shipped) configurations. Different subject. This second use case cannot be served well with the iOS app-centric sand-boxed model. A product directory structure with thousands of files can have a number of applications access these files. There will not be a one-to-one correlation between applications and a lot of the files in the design. Similar use cases can be found in other businesses where the end-product might not be a physical product design. Research projects, financial reports, publications and other work product is likely to require a number of different file types that may or may not come together to form a single deliverable. Again, the iOS sand-boxed model fails to support this use case because it forces a per-file-type or per-application separation of files and does not permit or provide the ability to organize disparate file types into projects according to context. Put another way: If you are Lockheed you don't want the F-16 and F-117 mechanical design files mashed together into one folder simply because the same CAD system is used to open then. You want them to live within their corresponding project stores and within a sensible directory structure that organizes work according to relevant criteria. For example, the wing mechanical design directory might also contain a set of directories with aerodynamics data whereas the mechanical design directory for the seat has not need for such data. I see that the Windows approach seems to work well for the first type of user. If applications use it correctly (some don't) everything gets dumped into "My Documents" and other predefined folders. Users would occasionally add sub-folders of their own. The second set of users generally has the presence of mind and knowledge to "roll their own". Using my own patterns as an example, I don't think I own a single computer (Mac or PC) that does not have a separate "Data" drive where projects are stored within their own directory structures and according to their own needs. There's another twist to this, which is a far less common use case: I happen to run more than one business. There's zero justification for my Photoshop files from business #1 to be stored in the same location as those of business #2 on the same computer. Each business has its own root directory from which to organize the corresponding files.