What's with this anti-directory structure movement?

From the article: <i>I have honestly never seen a single person have any issues with directories, nested or no, and as old as the concept might be, the people I interact with seem to be able to handle it just fine.</i><p>Twitch.<p>The author's clearly been interacting with different people from the ones <i>I</i> know. 80-somethings who didn't grow up with computers frequently get hopelessly confused by directories. The philosophy professor who's been using a Mac since the mid-80s is a bit harder to explain. And then there was the time I got called in in the early 90s to fix the office PC used by a succession of secretaries -- running MS-DOS -- and discovered they'd saved something over 2000 Word Perfect files in the root directory because <i>none</i> of the temps the company had employed over a 12 month period had ever heard of directories.<p>In my experience many casual users (for values of something like 10%-50% of computer users these days) simply do not "get" hierarchical storage at all; they find it as baffling as predicate calculus. Hence the desire of some software vendors -- who are trying to provide machines that <i>anyone</i> can use without training -- to move away from it, at least on the user's side.

When I see people struggle with folders, it's these two things:<p>- System, Application and Settings storage folders that the typical user really shouldn't have to see in the first place<p>- Predefined directory structures like "My Documents" that the user didn't create themselves. Especially when apps crud things up even more with subdirectories with files the user didn't create themselves and can't edit themselves (on my Mac I have "EyeTV Archive", "Final Cut Pro Documents", "iChats", etc... these should be hidden in Library folders until the user exports them). The Desktop is among these. Storing files on the Desktop shouldn't be possible.<p>If when new users got a computer, the only storage visible was a completely blank home folder, I think a lot of this confusion would disappear. It's not nesting of folders per-se that's the problem, it's that there's a ton of shit there from the beginning that the user has no idea what it is, where they are right now, and where their document will go. When the user created everything themselves and applications don't save documents go into special folders by default, I think a lot of that confusion is gone.<p>In this world, users who don't understand folders won't create them, and so they won't be confronted with the complexity. The "app silo" model could be emulated by app open dialogs only showing files created by the app itself by default.<p>Personally, I hate the app silo model. I like having a folder per project with all the related files in it. If I'm working on a report, I want to be able to quickly get to the text chapters, the graphs, my data sources, etc without jumping between apps so much.

This all boils down to several salient points:<p>1) Nobody, not even 90-year-old computer newbies, has trouble understanding hierarchical folders. There could not be a more natural concept of organization. It corresponds to a box inside a storage box inside a closet inside a room inside a house inside a neighborhood, etc. It's just every level is called a folder. Saying that "x" group of people "can't understand" that is just insulting to them, frankly.<p>2) People who use a flat directory to save 1000's of invoices on a computer which is only used for that, who do not understand folders -- that's fine. This doesn't prove folders are non-intuitive. They just don't <i>need</i> to understand folders, because the job doesn't require folders. The moment their job does, someone can explain it to them, and they will get it, the same way they get that paperclips go in the box on the shelf in the closet.<p>3) The original Mac OS (say, up to System 6) did a great job of making folders understandable. They were physical icons, physical window locations, they were easy to use. The Open/Save dialogs could be a bit confusing, and still are -- there's definitely room for improvement there.<p>4) Modern OS's do a <i>terrible</i> job at making folders understandable, because there are drive directories, often hidden, and then multiple user folders, and their Documents directories, and then things <i>outside</i> their Documents directories (like Desktop, Downloads, etc.), and fake folders that show the content of multiple other folders, etc.<p>5) So people are rightly claiming that folders are a mess and confusing. Yes they are, on modern OS's. But the problem is not with the concept of folders, it's with their back-assward modern implementations. So don't throw the baby out with the bathwater and claim that folders are bad. Instead, the solution is:<p>6) Modern OS's and apps: stop trying to organize our damned files for us! Stop auto-creating "Downloads" and "My Pictures" and "My Skype Photos" and "My Virtual Machines" directories. Just stop it! Instead, give each user their own home directory, have it be <i>empty</i> on a new computer, have every application open/save things in it by default (including downloads), and let the user organize things gradually as they see fit. And don't let anyone but a power user ever get outside of this directory.<p>(And ideally, stop allowing users to put documents on their desktop -- it just confuses things and nobody has ever come up with an intuitive way to integrate that with the concept of user folders (my desktop is <i>inside</i> my user folder, what?). Documents on a desktop is an outgrown metaphor that just nobody seems to have the courage to jettison.)

A directory structure is too restrictive, much like Java and C++ inheritance. Cluster and search based file access is way more flexible and fluid, but we haven't had a good UI or overlay onto traditional filesystems yet. Think of Go's interface model, but for files.<p>Imagine you have a file that is a vendor-provided html template. Does it go in vendor/ or templates/? vendor/templates? What if you want to find out all the templates in use by the system? Document that somewhere and expect a newhire to 'just know' where you store the fragments of your templates?<p>Sometimes there really <i>isn't</i> a parent-child relationship between data, modeling it like that is always true seems very 1980s.<p>Perhaps Rob Pike can sum it up better than I can:<p>"My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type's parent, whether A inherits from B or B from A. Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision.<p>I believe that's a preposterous way to think about programming. What matters isn't the ancestor relations between things but what they can do for you."

I think the other point of view, the anti-directory one, is well reflected in this review of OSX: <a href="http://informationarchitects.net/blog/mountain-lions-new-file-system/" rel="nofollow">http://informationarchitects.net/blog/mountain-lions-new-fil...</a><p>The most notable saying is that "As soon as we have more than a handful of notions, or (beware!) more than one hierarchical level of notions, it gets hard for most brains to build a mental model of that information architecture."<p>Here is my ranty answer:<p>~~~~<p>My god. Who the HELL are those guys to be so dismissive of human brain?<p>I have a kid, he is learning ten words a day, and this little boy is not a genius: It is a normal human being in formation. He is also playing a lot with my old legos, and he is communicating better and better in two very different languages. I can tell you, dear "Information architects" that he can already handle more than one hierarchical level!<p>I have worked in normal companies before. By that I mean companies were people have meetings, get bored by many slideshows every week, and use excel spreadsheets daily. In this kind of companies, geniuses are not the norm. And all of these people, all of these common "brains" could handle easily "more than one hierarchical level".<p>So, dear "Information architects", please keep your stinky morgue to yourself.<p>Human brain is the most wonderful thing that can be observed in the world. Its capacities surpass anything we (human brains) can modelize with our other tools. A kid of 3 years is much better in all what matters than a computer. We, normal human beings, won't let you grow a new generation of lobotomized humans for whom it is "hard" to build a "mental model" with "more than one hierarchical level".<p>Post-scriptum: After a mandatory proof-reading, I sit there and I wonder: maybe my legitimate anger against your aristocratic hauteur did blind me of a better explanation. The "brain limitation" you are attributing so kindly to "most brains" is just your own problem, maybe. Then your are not as cynical as it seems. But then I repeat: of any of my colleagues, old and young, clever and stupid, ubergeek or almost illiterate, all could handle a f<i></i>king tree structure for their file. Thanks for considering them (a bit).

There is a flaw with directories and hierarchical storage and it's not their conceptual complexity.<p>Gmail made a move away from folders and it's one that I've embraced.<p>1. It's easy to spend too long manually organizing things into folders. It's the kind of relaxing, busy-work we can fall into to avoid the hard stuff we're supposed to be doing.<p>2. There are many arbitrary ways to rearrange hierarchies and no clear limit for how deep they should be. Many of us with slight OCD-ish tendencies can fall down the rabbit-hole here.<p>3. It's manual work that the computer should partially be doing for us.<p>There are ways to mitigate these problems. Multiple views of the same structure, tags instead of folders and easily accessibly, instantaneous search can teach us to be less dogmatic about our directories.<p>I very rarely need to use tags/folders with my email now. Search works for me 90% of the time. It's only special tasks such as doing my tax returns or tracking a particularly complex bunch of emails where I might use tags. I think my file system is probably an order of magnitude more complicated and there is less automatic metadata with files (my file system doesn't know what project a file is related unless I tell it whereas you can tell a lot about an email just using from/to/cc fields.)<p>At this point I was hoping to end on some kind of conclusion but I can't think of one.

I think at some point Apple will sell us "folders within folders" as a gorgeous update that took so long to really get it right.

That's a refreshing view. I fully agree. I hate it when a music player do not allow me to browse my clean and deep directory. I detest the fact that apparently no Picture manager is letting me to see my 10 years of photos in the hierarchy of my choice, that I implemented patiently in a directory structure.<p>And to the many comments right here that argue that people have hard time dealing with directories, I have one question: Did you ever work within a normal company (I mean, the kind of company where you have people in suit or tailleur doing ppt and excels)?<p>I have, and I can tell you that the most stubborn HR assistant will have his or her files almost neatly catalogued in a hierarchy, and most of the time they will be able to find the "2001 report on office expenses" directly from the hierarchy.<p>Granted, most will not use a clever and consistent naming convention for files, allowing to sort them properly (eg. all files prefixed by year). And that is a problem. A problem that the hierarchy solves properly, by the way.<p>So, I would bet the Apple/Google "no file" movement is a dead end. Worse, it is a trap. Check who will benefit from this move: Users? No. Advertisers? Maybe. DRM corporations? Certainly...

I had to stop reading at "I've never met a user who has trouble navigating nested directories."<p>My experience tells me he is in the 'tech guy' bubble. As someone who volunteered helping city kids use computers, had a 'business' fixing people's computers, and has a dad who teaches a free computer class at a library, and has worked tech support, I say with some confidence that the silent majority of people don't understand folders at all.<p>You have to be a tech savvy, middle to upper middle class person with relatively high motivation before you stand a chance of understanding folder structure. Exceptions abound, of course, but then again most 9-5 working, intelligent people struggle to organize their data in folders even though they fit my demographic of people with a chance to understand.

Maybe it started with music playlists. My digital music collection is largely in the same folder structure as it was 15 years ago, but every music player wants to make a library based on metatags, which in theory makes sense, but then just adds the problem of giving everything suitable metatags. Building your own file structure based on your own needs just seems easier and simpler.

The original article wasn't very good, but this response is even worse. It appears the author is lacking any form of creativity to think beyond the idea that folders are the only paradigm for ordering files that could possibly work.<p>In practice, if you forget about system files and such, I'd estimate 9 out of 10 people have all their documents in a single flat folder, which they only access through their word processor or whatever they use to open them. They have all their pictures and video in a tool that organizes them into albums and such without them having to deal with folders. They have all their music in a program that keeps them in a library somewhere, which they never manipulate on the file system level. And so on. Or (also very common) they just dump everything they touch on their computer on the desktop. This is not because making folders is 'too complex', but because users can't be bothered to come up with hierarchies to order where there files are 'stored on the file system' or whatever, they just want to make their changes persistent and be able to quickly find their files later.<p>For the vast majority of people, folders are an anochronism. It's not that they are 'hard' or 'complex', but they are simply not essential, and actually quite limiting for file management. The whole idea that the artefacts you create or consume are best structured as a tree really doesn't make a whole lot of sense. Especially not if you want to have all your data available on multiple machines which may have wildly different file systems such as desktops and mobile devices.<p>This doesn't mean we should all have big piles of files with no ways of structuring them, but it doesn't mean folders are the epitome of file management either. A database-like file system with powerful search options could definitely be much better. From an end-user perspective, organizing files by the applications they can open them also seems to be a pretty good idea to me. Attaching metadata and tags to files so you don't have to superimpose them using a tree-like structure would be a huge improvement.<p>I'm not saying that what Apple is trying with iOS and now OS X is so great we should all hail it as the future of file management, but personally I think they are moving in the right direction. Ideally, end-users should be able to operate their devices and get to their files without even knowing it has something as abstract as a 'file system'. Just sit down, get the file you want using whatever criterium makes the most sense for finding it, manipulate it, and have the same file available on every other machine. I think this is the vision Apple has, but it will take lots of time to get there.<p>Also, people mailing files to themselves to get them on their iOS devices literally has nothing to do with how the iOS file system works. Folders or no folders would not make any difference.

Some people can handle directories just fine. But, a lot of people simply do not grasp the concept. For many, many years I have been trying to explain hard disks, folders and files to family members. They simply don't understand the concept. Opening a folder and double clicking on a file to open it and a program to read the file starts: they do not understand it.<p>For these ordinary users of computer appliances the iOS way of handling files is simply a blessing. You use an application to do something, to write a text, to listen to music, to communicate. Applications that can interact with each other, will interact with each other. Simple.<p>For an ordinary computer appliance user it is not necessary to be confronted with a file system. Just as a lot of other technical details are hidden from ordinary users.

&#62; The article I'm about to link to, by Oliver Reichenstein, is pretty terrible<p>Funnily, I liked linked article more (better written, also easier to read). Although I partially agree, partially would argue with both.<p>I think hierarchy-less approach, properly designed and implemented, would work OK for most users. Folders just look like the most basic and generic way for organizing stuff, which isn't necessarily the best, and probably deserves optimization for particular use cases.<p>However, take for example cases when computer is used for production—say, DTP or video/photo editing. If you take away the freedom to organize files hierarchically, it would impose certain restrictions on the workflow. The “genericness” could be an advantage for more complex use cases.

I wonder if others have scaled back on the "meaningfulness" of file names. I name a lot of my files (and directories) 01, 02, 03, etc (with suffixes according to meaning) and then I have a local README file that lists the contents of each of these.<p>I find it this scheme handy for scientific work in which the files are often multiple attempts to solve a problem. It saves me from writing file names like "solution" and "solution_method2" and "solution_method2_with_bug_fix" etc. The README format gives me tons of space to write comments (and cross-reference other work), while the filename, incrementing from version to version, is a sort of diary stamp.<p>This works for directories too. I tend to go only 2 directories deep on a given project. The top level is for the task, e.g. a calculation or a figure for a paper I'm writing, and the second is for a sequence of approaches to that task.<p>With this scheme, I focus on README files and not names in a directory tree. Colleagues who have tried this have found it weird at first, but then tend to prefer it to the "informative name" scheme they grew up with.<p>If databases were more convenient, I could imagine doing all my work with "flattened" filenames in a single directory. I think that's what apple are moving toward, but they are thinking of application-specific work, so the application deals with the databases. I prefer the README/filesystem structure because it lets me use tools like grep, etc.

Intuition is learned.<p><i>Something is intuitive not because it’s universally understood but because we have learned the meaning of it from a holistic point of view. This requires lots and lots of experience and, for that matter, trial and error.</i><p>Metaphors are only meaningful in retrospect.<p><i>Don’t count on the physical-looking button to be intuitive just because it’s a metaphor from real life. Once you tell someone what a specific element means, they will most probably understand it, but not because of the metaphor itself.</i><p>There are no Bablefish in UX<p><i>Designing products and services is like speaking French. Not everyone understands it. Comprenez-vous? The noob might pick up a word here and there, but they aren’t, by any metrics, comfortable with participating in the conversation.</i><p>This all leads to the following conclusion:<p><i>Intuitive interaction is for experts, not for noobs Understanding something intuitively really means that you understand it holistically. If you understand it holistically, you can fill in the gaps. This doesn’t mean you shouldn’t make your design intuitive or improve on it—not at all. Just understand that you are doing it for the natives.</i> not for the noobs.<p><a href="http://000fff.org/anatomy-of-a-noob-why-your-mom-suck-at-computers/" rel="nofollow">http://000fff.org/anatomy-of-a-noob-why-your-mom-suck-at-com...</a>

The article linked to is a witless rant. The article he is reacting to is actually pretty good.<p>As is commonly the case with people who don't understand what they are talking about, the author is confusing policy (I want to organise my stuff) and mechanism (use folders and sub-folders). What is undeniable is that we need a coherent way to organise our stuff. What is wrong-headed is assuming that hierarchical directories are the best, or the only, way to do so.

Apple's attempts at making "seamless" user experiences can be frustrating, especially on edge cases. For example, in Garageband instruments are stored in special files down a ways in a directory tree in Application Support. It happens that files get corrupted, but access to the file is so abstracted that the source of the trouble is not apparent, as it is a directory not intended to be accessed by the user. It's an attempt to hide complexity from the user but it makes it hard to trouble-shoot, or to perform actions outside of the expected.<p>The area that does boggle my mind in terms of a flat structure are complex multi-media authoring environments. Where different files and types are used to assemble a larger work.<p>My main principle as an audio engineer is that I have to know exactly where each file in the project lives in the FS. If I'm not sure, the scenarios in which projects, or parts of projects get lost happen more frequently.<p>Not to mention that a given project uses many files of different types, and can have 10s or 100s of thousands of files. Automatic file management seems like a recipe for disaster, especially as it won't work perfectly.<p>I don't get it.

One opinion, repeated a zillion times, does not make an argument; it makes a rant.<p>I see only a few arguments in this text:<p>- the author does not think nested hierarchies are difficult. If he added "for nerds", I would agree with him.<p>- the author equates having limited nesting with the 'data silos' situation on iOS and (from what I read in reviews), in slightly lesser sense on Mac OS X Mountain Lion.<p>- claiming that the mouse is hard to use because it provides "indirect manipulation". That may seem so, but the human brain is exceptionally good at transferring motor skills between modalities. For example, anybody who can write can write with his feet, nose, car, or whatever, and the handwriting will (except for the quality of fine motor skills) be recognizable as yours (<a href="http://www.ebaumsworld.com/jokes/read/211551/" rel="nofollow">http://www.ebaumsworld.com/jokes/read/211551/</a>)<p>- equating having limited nesting with vendor lock-in. Proprietary file formats are fine for doing that. I do not see why you would need to do anything more.

The article is a bit of a rant, but it resonates deeply with me. The single-level of nesting is obnoxious. The spotify app allows a flat list of playlists--just the one level of nesting. Now that I've got a couple hundred albums in there, it has basically become useless, and I just have to search to find everything, which is _not_ what I want to do.<p>Hierarchical structures are how we see the world. Tagging and search is not sufficient. File systems give us the illusion of a "place" that a file lives. A single place. Like my socks are in a drawer in my closet, they are always there. A given music file is always in /home/steve/Music/&#60;artist&#62;/&#60;album&#62;/track.foo. That's where it lives. I can find it, even if I have 10,000 albums. My tax documents are in /home/steve/Documents/personal/taxes/2011/ . They exist there. I can auto-backup /home/steve/Documents and I know that those documents are safely backed up. I won't lose those things.

I'm all for any easier file organization system as long as it's portable between systems, allows a large number of files to be locatable and usable immediately after being plugged into a system (i.e. without a lengthy indexing process), and doesn't make it difficult to share files between users in a network (e.g. a Samba set-up in an office). I don't know if there can be any such system that doesn't become as "complex" as the current folders-in-folders way of doing things. Most of the systems I've seen assume that I only access the files from this device and I'd never need to copy them to external storage or share them with another user not necessarily using the same kind of system as I do.<p>Maybe a hybrid system, like the one being done in GNOME, where you have the traditional underlying file system present, and a separate indexing program (GNOME documents) that enables searching by content, context, date modified, etc would be best.

&#62; Vendor lock-in<p>Well, duh! Obviously that's what it is about when "apps" don't want to tell you how they store their data. MS Office has been doing that very successfully for more than 20 years now. And removing the abillity to actually locate the data would make it even easier to tie the user to the app and plattform.

I don't think changing the way we structure our files is that bad an idea, although the iOS version of it isn't really great. Folders are basically a way of grouping files of a similar topic/concern together. Files can belong to many topics/concerns, but they can only belong to one folder. I'd really love it if we evolved the folder concept to a concept of tags, where the organization is very fluid and dynamic.<p>Example(example folder structures):<p>* I could put an anime movie file under /Media/Video/Movies/Anime or /Media/Video/Anime/Movies<p>* Same for an anime tv show: /Media/Video/shows/Anime or /Media/Video/Anime/shows<p>If i could tag the anime movie as "Movie" and as "Anime", i could just pick and choose which way i want to view it:<p>* All movies?<p>* All anime movies?<p>* All anime?

The giveaway phrase here is:<p>"... instead of having your own structure, tailor-made for you because you created it in the first place ..."<p>Non-geeks don't have the time, interest or inclination to catalogue and curate these sorts of structures.<p>The list that the author gives of everyday items that are easy to use ("cupboards, Tupperware, boxes, closets, pockets, wallets") all have the common property that they are not recursive, and that you can easily figure out their contents at a glance, something that is impossible to garner by looking at an opaque list of directories.<p>While there are some good points here about the problems of files being siloed in apps on iOs, the directory structure is a ux disaster.

I think android has the approach to filesystems write. Each app has there own dedicated folder for internal usage and is hidden from the user (actually, the user cannot access it at all unless the specific app provides a method because of sandboxing, but that is a different issue). There is also a file structure where apps can read and write any data that the user might want to share between apps, devices. By convention, the files are organized either by type (image) or by app, however when the user wants to move them, or open them with a different program, this option is left available.

It's not so much that folders are counter-intuitive. The problem with them is that they impose a single, arbitrary structure on files that could be organized in many different ways. For example, you could have folders like AllMyImages/ or AllMyCatImages/ or CatImagesJuly2012/ but there's no way to anticipate what will be the most useful directory structure for all future situations. It would be more flexible and useful to have indexes over the files that let you dynamically organize your content according to attributes such as contains-cats, date, is-image, author, etc.

One of the many reasons to hate Apple. I don't understand why supposed geeks can get behind a company that willfully puts draconian protections to keep you from using a computer like a computer. No USB port? No useable FILE SYSTEM? Emailing files is a pathetic hack for a poorly designed device. And "simplicity" is not a saving grace, there is NO REASON to not allow this sort of functionality except to force everyone to use horrible iTunes. People can defend Apple all they want, but no one can give me a valid user-centric reason for those decisions.

To me, this is about choice.<p>If a computer has a file system that is accessible to the user and supports files and hierarchical directories, then users can choose to use it or not. If they want to use directory hierarchies then they can. Or if they want to store all their files in one place and rely on applications to present filtered views or search (not necessarily even in terms of files) then they can.<p>If the file system is not accessible or doesn't support hierarchical directories then you have no choice. This is not an option that interests me.

If OS vendor would like to switch to using metadata or tags to organize documents, allowing just two level directory structure could be the first step.<p>Documents in root would end up having no tags at all and the folder name would be used as the tag for those stored in folders. Obviously you could also do this with complex directory structures, but then the tags would become quite long.<p>Metadata/tag based systems don't necessary exclude the complex folder structures as we have seen but having both can make things complicated.

I think that isolating data and applications into their own directory on a PC makes total sense.<p>But there was something that I read to do with organizing your email inbox into folders which is sort of related. A study found that people who organise their inbox into multiple sub-folders don't get any benefit at all compared to those that have just one big inbox; when they want to find something, they just sort by 'from', 'date', 'subject' or do a find text.

I dont want applications to be file-managers and hiding where my files really are. Files+directories is a very intuitive, powerful, and low-abstraction concept --- directories and files correspond directly to inodes. Thus the file-system and users' view of files is the same. Tagging etc can easily be accomplished by using extended attributes (like in the BeOS Filesystem), but apparently no one wants to use extended attributes.

i would like to see the anti-directory people put forth a basic cms that works this way. everything is tagged, no folders. or however they're saying they want it to work.<p>then give this to an enterprise. hell PAY them to use it. see what the results are.<p>since you're all ui/ux experts 'they're using it wrong' will be an unacceptable response to anything that happens.

So... Apple doesn't want people to write code on their OS anymore? I can't think of many languages that would not suffer from a lack of folders. I don't care about all the other crap being discussed. There will always be people that have a hard time with XYZ.

There seems to be alot of the comments here pointing out that the users are dumb, or they "just have to learn" – really? Aren't we the ones that should design solutions that are easy to understand, and easy to use?

I come across a great counter-example to directory structures every day. I make 32-bit, 64-bit, debug, and release builds of my product. How do I organize them in a tree? Which distinction is "higher-level"?

I read somewhere that Apple uses hard links to directories for time machine.

There's a huge difference here between Mom, Dad and Uncle Fester using a computer and professional or business users.<p>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.<p>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.<p>The second set of users, the pro's and business users --to generalize-- are a different story.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.

Great topic and one that has been bothering me. Can somebody answer the following question - when I have a PDF opened in app-1 in my iOS device and there is an export/share button in that app which allows me to open that PDF in app-2, does that sharing end up creating two copies of my PDF on my device? If yes, then isn't this app-as-a-silo model a little inefficient?

I think computer scientists need data points before making proclamations like "most people don't like folders".

&#62; I have honestly never seen a single person have any issues with directories, nested or no...<p>This is completely off. I've seen people not being able to "get" the concept of folders and files even after months of demonstrations... They simply forget, don't understand, can't use. Especially in the context of drives, devices, memory cards, etc.<p>And those people are large in numbers, the non-computer crowd. Probably at least 30% of the general population.