Hacker News Reader

Comment by w0utert | Hacker News Reader

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.

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.

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.

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.

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.

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.

View on HN

Your thought process is precisely how vendors like Apple are arriving at this conclusion. The problem with it is that you are assuming that your users are blithering idiots without any actual work to do.

The oh-so-quaint folder metaphor directly correlates to how humans do things in the physical world. I put my winter coat in a closet. My winter scarf, boots, hat and gloves are also in the closet, but in a box on a shelf.

My system may not be the same as yours, but it works for me. Dumping my winter stuff with all of my clothing on a pile, and affixing a blue tag on it to represent "winter stuff" isn't improving things. Installing a database-backed clothing management system like you would find at a dry cleaner in my house solves my organizational problem, but introduces alot of complexity and overhead.

Let's be real here. The reason that Apple is doing this is that have had success in delivering a dumbed-down API that makes their life much easier on phones, and prevents pesky third party software developers from doing dangerous things like allowing applications to talk to each other. They've decided to bring this innovation to the general purpose computer.

Dumping my winter stuff with all of my clothing on a pile, and affixing a blue tag on it to represent "winter stuff" isn't improving things.

It's a strict improvement (in the mathematical sense) if the tagging system allows you to view items with no tags.

Am curious, what is the mathematical sense here mean? Not snarky, really curious.

What I mean is that a sufficiently powerful tag system can be used to emulate a directory-based system. For example, with simply a means to view files without tags, you can recover a single-level directory system (à la CP/M) by merely tagging files with at most one tag.

If you also incorporate a notion of hierarchical tags (where for every tag X, there exists a set of tags Y which act as the conjunction of X and Y) and extend the above ability to allowing viewing files tagged with X but not tagged with any child tags of X, you can recover the familiar multi-level file system again by tagging files with at most one tag.

GMail almost gets this right, as it has a hierarchical tag system, but (AFAIK) it has no means for viewing e-mails tagged with a given tag but not any child tags.

Hmm.. True.. My first thought was well, i could say the reverse, but realized, our current implementation of directories and hierarchies are restrictive. in the sense of having multiple tags/directory names to a set of files(it can be argued, symlinks do the job well enough). The analogy, also brought to mind the choice to allow multiple inheritance or not. I guess the trade-offs are the same. Power to the user vs easier(but restricted ) for the user -- I don't mean the tag system per se, but the idea of having only one level of filesystem.

P.S: As far as my personal stance, it comes down to the type of use/nature of application/(perhaps more appropriately) amount of attention being spent. I don't want to have to descend hierarchies of filesystem(Even ones, i created/customized myself) to find my music. OTOH, I'll be pissed, if i have to search for my code files by tags/file contents.

I was about to point this out elsewhere in the thread where someone was saying that you can do anything you want with a hierarchical directory structure and hard links ...

This is equivalent to hierarchical tags (if you allow that an "untagged" file is equiv. to the root directory) but maybe less confusing.

Shoes are simple. But where did you put the backup debit bank card? To the "finance" stuff? Or to the "plastic card" pile? Where to put spare photos for documents - near the foreign passport cause you'll surely need both of them next time? Or to the unsorted photos pile? Where should we put spare screws from a new shelf - on that shelf or in the toolbox with other screws? Etc. etc.

This is why directories are getting old - they allow only one tag for a file - the folder name. New systems, like iTunes and others are introducing concept of advanced tags - you can find the same file in the Author "dir" in the Genre "dir" in the Type "dir" etc. They aren't perfect yet but they are being refined all will be dominant in the future.

Shoes aren't simple for everyone. My wife's friend has a pretty robust system for managing dozens of pairs of shoes.

The point is, unlike iTunes where you have a consistent and generally understood metadata system, people have their own systems to deal with arbitrary needs, whether that be shoes or code.

Being prescriptive and pushing a single "one true path" for everyone isn't solving problems. And computers are supposed to be here to solve problems.

Which is why it'd be nice if filesystems supported labels. I'd keep the directory structure, but I want to be able to apply the "2004 vacations" label on a all files in a given directory. Then you can add other particular labels to some files.

I don't want to have to manage labels separately for iPhoto, for Picasa and for all the possible image viewers that I'll use in the future.

Yes, yes, yes. I've been fighting photo management software for years when all I want is the ability to tag files.

Windows have had that for years now.

But I guess since Apple haven't done it yet, it doesn't exist to hipsters.

Even when I disable in every machine I use, that's the idea behind KDE's Nepomuk.

http://nepomuk.kde.org/discover/user

The argument really isn't labels vs. directories but files vs. siloed databases. The fact that iTunes knows one tag doesn't do me any good for finding the file for use in another application. Labels are great things, but they're much less usable than directories because they're totally siloed to individual applications. iOS definitely does not have a filesystem that replaces folders with tags.

"This is why directories are getting old - they allow only one tag for a file"

Erm, no. A file can be tagged (linked) into as many directory locations as you like. This is what hardlinks do and it is not a new concept.

hardlinks? Jeez... most programmers and sysadmins I've mentioned them to don't even understand hardlinks.

Are you suggesting that hardlinks are good enough for my mom, too?

Shortcuts do basically the same thing, and my grandmother understands shortcuts.

This reminds me of an old story: a user backup all his documents by burning them into a CD, only to get his IT department discovered he only backup desktop shortcuts instead of the real file.

This is the main difference between hard links and shortcuts. The above scenario won't likely to happen with hard links (because they're actual files). As with jcromartie, I have a really hard time explaining that hardlinks are not shortcuts even to programmers.

I can't imagine my dad (hell, even my brother) will ever going to understand hardlinks. He don't even understand how shortcuts works (only how to use it).

>I have a really hard time explaining that hardlinks are not shortcuts even to programmers.

While the distinction is important to programmers and sysadmins, the average end-user treats shortcuts as if they were hard links, it would not make the UI more complicated to change the 'make link' behavior to hard-link instead of sym-link.

Yes it won't, but when you have to introduce the concept of multiple files could point to the exactly same data on the hard drive and no, it's not a "copy" of that file, it's rather mind-blowing.

Actually I believe you're suggesting that the paradigm of tagging files may be inappropriately complex for most users. And I would agree.

The point is that we've had the ability to apply tags since the dawn of unix. It remains an obscure feature because as you say most users are uninterested.

You need better programmers and sysadmins.

>Installing a database-backed clothing management system like you would find at a dry cleaner in my house solves my organizational problem, but introduces alot of complexity and overhead.

This would be complex to implement, but would greatly simplify things for the user.

Imagine I had a big box I could throw all my stuff into, and when I wanted, say, my shoes, I could just say "Computer, retrieve winter boots" and my personal robot would pulled it out of the box for me. This would be awesome. Sure it would be complicated to implement a physical system like this, but storing an retrieving files in this way is easy. OS X's Spotlight gets us most of the way there. Now we just need tags.

The problem with complexity is that it ends up being rigid. What happens when you get boots that the robot can't pick up?

I scan alot of stuff at home and tag it with PDF tags. It's totally awesome, because Spotlight can index them, and the metadata is associated with the file vs. the file system. So I can use it in Linux or Windows as well.

The problem? I can't do that for all filetypes. My TaxCut files for my personal and business taxes have no meaningful metadata that Spotlight can use. I could use Spotlight Comments, but that metadata isn't portable. The portable facility for this sort of file that I have is directory structure.

On iOS, I'm just fucked. Unless the file in question is a picture, I'm stuck emailing things around, storing them within apps and whatever nonsensical filing system they have, or storing them in iCloud and only using Apple apps.

Apple wants my Mac experience to be like my iOS experience. Which is why I need a portable way to organize my junk.

The pile analogy implies that all interaction with the computer takes place using a visual metaphor, rummaging through the pile.

I like folders just fine (exactly because they let me pile arbitrary things together however I feel like), but not having some facility to search for things is just as bad as not having folders.

One nice thing about database style systems is that they don't actually have to own the canonical version of some information in order to be able to index that information. So let's keep our folders, but let's also have nice search facilities that let the user drill through the filesystem analogy and find their data using some other criteria.

The problem with it is that you are assuming that your users are blithering idiots without any actual work to do.

One of the most widely replicated UX results is that over half of people don't "get" the concept of a nested directory structure. Not even when you try to explain it to them.

Not dumb people either. College graduates. It seems to be a mental block. It is not one you will find among programmers (anyone who can't understand this is unable to become a programmer), but if you're designing for the general population you need to be aware of it.

The result is that any user interface which forces people to be aware of a directory structure is going to confuse the heck out of real people. You may have a directory structure. But to get happy users you need to keep them blissfully unaware of it.

Could you point to a study or something that describes this phenomenon?

I only ask because I work with a huge (50k+) population of people who, based on the evidence I have from systems we manage, do seem to "get it" to varying degrees.

There's definitely a spectrum, from people who are digital slobs to neatniks who have more folders than files.

One of the most widely replicated UX results is that over half of people don't "get" the concept of a nested directory structure. Not even when you try to explain it to them. Not dumb people either. College graduates. It seems to be a mental block.

I have never heard of this ("most widely replicated UX result"), nor have I ever seen it to be the case on any kind of consistent basis.

In an effort to perform a minimum of due diligence, I ran a couple web searches and no relevant articles were returned.

What I do believe, is that users have difficulty understanding directories / folders as they can be represented on newer OS's as another commenter very eloquently pointed out.

However, I am highly skeptical of the claim that the population at large is simply unable to grasp the basic concept of hierarchical directories.

I find this too, but I also think that it has something to do with the word "directory." People don't really think of collections of directories (like phonebooks for example), they think of a single directory in which you look up things. When you use "folder", this seems to go away and people get the metaphor. When a tech savvy person is explaining it, they frequently interchange the two terms and confuse the listener. A "directory" is list that you look up things in, like a dictionary, and a "folder" is a object that contains related items.

A list of Artists, Rap, Prince, or Slow songs in some mp3 management software resembles people's ideas of a "directory" better.

One thing I've noticed about these silo/tagging systems and non-savvy users is that, though the users are generally comfortable in them, they also tend to lose data completely a lot and have no idea how to find it again. They also find it very hard to understand the concept of backups because they have no sense of location for any of their data.

"File," "Folder," "Copy," "Move," "Mail," and "Trash" are a really excellent set of terms to explain this stuff easily. Did AAPL or MS come up with this? I find the only problem with them is that people don't understand why you don't end up with two files of the same name in the same folder when you make a copy (because "Copy" is more like "Copy and Move".)

edit: or copy is more like "nothing just happened," really. I think the metaphor becomes broken when you go to clipboards and pasting. Maybe the right metaphor is to make the desktop the clipboard. When people "Copy" a file, folder, or anything else, it should appear on their "Desktop" rather than a "Clipboard," where they can see it at all times, and use it as a shortcut. The desktop doesn't have to be thought of as a proper directory.

I've always thought that Copy / Cut was a poor metaphor. The metaphors are so awful that I almost never used GUI filesystem manipulation until the mid-2000's, doing everything through the command line. I still usually use the command line.

Okay, I want to move files from point A to point B. What you're supposed to use is "cut" and "paste". If I use "cut" in a text editor, the text is gone until pasted. What if I do a "cut" on files? Are they deleted? Are they put in some super-invisible temporary trash bin? Or does the OS actually do nothing until you "paste" them? Do they have the same clipboard as copied text, or a different one? If you do a "cut" on files in folder A, followed by a "paste" in folder B, followed by another "paste" in folder C, what's the result? How do cut/copy interact with shortcuts, junction points, hardlinks, or symlinks? What are the subtle semantic incompatibilities in these metaphors across different versions of Windows, PC, Mac, Gnome, KDE, etc.?

Using the GUI is a crapshoot in terms of whether what actually happens will match my intent, and I'm an expert; I can scarcely imagine what a n00b's experience must feel like. You can do things much more precisely with command-line mv, cp or xcopy, find | xargs, or writing a simple Python script with os.walk(). About the only thing I use the GUI to do is select a large number of randomly distributed files from a directory.

"Trash" is also confusing, because things don't end up there consistently. If you cut things, they don't; if you delete them from the GUI they do. If you delete things from the command line, they don't. If the things are on a removable device, the Trash doesn't get them. If you delete things within an application, who knows what happens? It depends on whether the app is coded to use whatever API routes stuff to the Trash.

>"Trash" is also confusing, because things don't end up there consistently. If you cut things, they don't; if you delete them from the GUI they do. If you delete things from the command line, they don't.

I think they broke the metaphor there by even using the word "delete" at all. Make them choose between "Trash" or "Shred" and that might work.

I once found myself explaining the details of "Copy" as something like "like making a ghost clone of the original that you are holding and can put it down to make it a real clone if you want to, or just let go of and it disappears"... so yeah, that function didn't get properly made graphical at all. Way too much hidden behavior. The command line, because it makes you specify where the copy goes, is far more clear. If there were a little icon of the file that attached itself to the mouse pointer in between the "copy" and "paste" steps, that might clear things up nicely.

The problem with it is that you are assuming that your users are blithering idiots without any actual work to do.

I think we are assuming there will be more sophisticated organizational systems built on top of this abstracted file system eventually. We are still in the very early days of this transition. The need to logically organize files can be accomplished in many different ways. An OS could have logical organization features based on concepts like projects, collections, etc. At that point you can start doing some fancy stuff. What if two projects overlap in some way? No problem. They can both reference the same files. Maybe my project is going to include 100 image files that someone else on my team is producing. No problem. I will just add their shared collection of images into the project and they will auto-update themselves anytime my team member makes changes. In the long run this is all about consolidating sharing, organization and collaboration.

> I think we are assuming there will be more sophisticated organizational systems built on top of this abstracted file system eventually.

Yeah, the only problem is it's been 9 years since WinFS was demonstrated as a concept and we're still not significantly closer to mainstream database-like filesystems.

I do everything you describe over the concept of a filesystem. A project/collection... has its own folder. If you have a shared resource you can have it appear in both folders (either through symlinks which are transparent at most UI levels, or by the system automatically configure a mount --bind when you want to share a resource between projects, or you can say, I want to make use of a resource that is part of another project, so I explicitly link to that other project)

I love dumping my stuff and know my mother will take care of it for me^^

At home, I have a rack of shelves with box and manilla folders. Each one contains different things like house bills, banking statements, insurance docs etc. I find it completely natural and a very easy way to file stuff. When I go to the bank, I take my banking folder with me. When I go to the insurance company, I take my insurance folder with me. My Mum and Dad (and likely most other people in the world) also have a similar system in their house.

I store my digital files in a similarly compartamentalized, hierarchical manner. It may come as a surprise to you but my Mum and Dad (who are approaching 60 and are not exactly clued up computer users) also do the same thing on their PCs (dad with his various excel sheets and word docs, mum with her photos). Of all the brain dead questions they ask me to do with their computers and the various tech problems they have, understanding folders and using them is literally something that has never come up. The paradigm is immediately obvious to them and they find it a natural way to catalogue and store their files. This notion that a user is too lazy to organise their files is simply something I have NEVER seen (and I've seen quite a lot when it comes to bad computer users).

If my parents were to be given a computer that had no concept of directories it would be a disaster. They would be just as lost as when I try to explain to them that the email they see in Thunderbird is the same as the one they see via webmail because Thunderbird is accessing their mail account through IMAP. To them that just sounds like magic. They much preferred it when they used to get their email via POP. Oh, and guess how they organise their email? Yep, lots of folders. I don't think they've ever used the tagging and advanced search features offered by Thunderbird.

I'm the same and it would fill me with rage having to exclusively interact with all my files through a GUI front end to an sqlite database. Which effectively is what we're talking about here. I can't think of anything more non-intuitive or pointless.

I think it's highly dependent on the type of person, or family. For example I have had to help many people track down their documents which are somewhere in a download or documents folder. I, personally, am not the kind of person who sorts my paperwork into folders. Neither, like some people, do I organise every single e-mail into a folder. Gmail has understood this well, and makes it easier to find what I want. I find it much easier to make sure I know _when_ something happened, I make sure I e-mail myself notes, and copies of documents, but most of the time it happens by itself anyway, so I can search for them in Gmail. For example if I want to find some paperwork done when we moved into a new house, I can track down the date in Gmail, and know in which box to go dig it up. Most of the time what I need has an e-mail record somewhere.

That said, I strongly support allowing people to approach the problem from both sides, chronological with good tagging/searching or being able to organise things into folders in a way they like. People work in different ways. However, I think the default is to be disorganised, and the best way to deal with being disorganised is to keep it as simple as possible.

But physical paper has basic restrictions that digital media doesn't - like lack of easily searchable metadata, and being able to be in multiple groups at one time.

My photos (many thousands of them) are stored in folders by date, but I pretty much never search them that way. I use Lightroom, which automaticaly puts basic stuff like date in there, and allows me to tag every photo with things location, themes, people, ratings etc. It also allows me to put them into (multiple, if I want) groups. And it's combinations of these things that I use to locate my photos - e.g. all the photos of my daughter in Berlin in 2008.

My music is little different - I might fancy listening to a specific album, or a random bunch of jazz tracks or whatever. I get to them through my music app, not through the filesystem.

Some other stuff still relies more on basic directory structures, but that's only because I've not found a suitable set of tools that provide me with a full metadata approach just yet.

And yes, a lot of people would probably initially struggle with moving away from directories and over to a metadata-based world, but that's more to do with the fact that it's what they are currently used to than it being a fundamentally better approach.

And just because two files are in different folders you can't still tag them and make them part of the bigger concept?

In fact with folders and tagging you are getting the best of both worlds.

I didn't say that you couldn't tag them if they are in folders. My point is that a fixed directory structure is pretty much irrelevant to how I usually want to manage/search my photos etc - it adds pretty much nothing to what I can manage far more flexibly through the metadata.

Except when searching by metadata doesn't find what you want. Or when it finds too much. This is now 99% case for me when I use spotlight.

I have a huge library of PDF books (tens of gigabytes). If I search for a bunch of keywords or even if I know entire title, the damn spotlight returns way too many irrelevant results. Now I could perhaps spend 10 - 20 seconds thinking about how to write a more specific query, but it's faster to actually go to ~/Reference/Computer Science/CS Theory/ and get right to my damn book, which I know will be there based on how I structured my filesystem and the topic the book covers.

This has in fact gotten worse since snow leopard, before the default was to show file name matches first then content matches. So if you want a book on algorithms, almost all CS theory books will match. You have to type filename:"book title" to be more specific.

Now one could argue that Spotlight should get better. But I'm arguing that you will always encounter cases where it will be really difficult to find what you want, even if you know a lot about what you are searching, let alone if you vaguely remember a detail about what you want to find. But by being able to restrict what you are looking for you will have better luck.

Searching for photos is much easier, because photos are binary content, so apart from EXIF there is not much to look for in there. But if you have documents with plain text or searchable content like PDFs, things get a lot worse.

I agree that Spotlight is dreadful. But that's not really an issue with metadata per se. After all, OSX is still primarily a traditional directory-based OS.

> it's faster to actually go to ~/Reference/Computer Science/CS Theory/

That's fine if this is the only way you ever want to structure your documents, and if you've not got too many of a particular subject. Say you've got hundreds of CS books, some of them have stuff about graphics in them, some of them have stuff about OSX programming in them, and some have both. Now you want to find a book about OSX graphics. Did you store them by subject (maybe not, because the books have loads of topics), or by OS (most of them are OS-agnostic, and some cover multiple OSs, so again maybe not). Do you remember where you stored it?

This is a pretty simple example, but it's exactly the challenge I face on a regular basis when using the fixed hierarchy of the filesystem. Do I store info about my motorbike crash along with other letters I wrote in 2008, or with other info about my bike, or other info about insurance, or medical issues etc? What I want to do is tag it with all of those things, because I might be looking for it for any one of those reasons.

If you want a hierarchical approach, then Lightroom as an example shows how you can still do this - it just allows you almost total freedom with how you do it - files can be in as many collections (and as nested) as you want.

Your two examples are both forms of media that require content management to be manageable at scale. In many ways, for photos, audio and video, rich metadata is more important than the actual data. People use iTunes, iPhoto, Picasa, etc. Enterprises use SharePoint and Filenet.

My guess is that at least 80% of that kind of media is managed via applications using specialized apps using metadata.

The "other stuff" that you speak of isn't equipped with rich and consistent metadata.

Think of it this way. Your iTunes folders are exactly the same as mine, there is just a variance in the music that you have. Your photo application is very similar to mine -- the variance will be the degree to which you organize events and add metadata.

Other stuff is different. Look at a folder that you use for a specific project. The chances are, you have documents in there created by multiple people. You probably have scanned documents with no metadata. Maybe even spreadsheets with financial data or some code examples. Whatever you have, there is a high chance that it looks completely different from my directory in key ways. Even the metadata may be inconsistent -- I tag some files for searching and add spotlight comments on the Mac. Most of my colleagues do not. The ones that do don't use the same conventions as I do.

In the real world, I need to look through the documents about Project X, which was implemented in 2009 to plan for a refresh of the project. The people who were here then are mostly gone. If I'm relying on metadata, how in the hell am I going to find Project X documents? How do I find things when I don't know what I'm looking for.

In the physical world, we have drawers, boxes and folders. In the digital world, we have filesystems. That isn't going anywhere, even if Apple decides to drag many people backwards.

I agree that a lot of other documents don't have the metadata that they need to allow them to be managed in this flexible manner. But that doesn't mean that a fixed directory structure is a fundamentally better approach - it simply means that these file types (or the users that create them) haven't caught up with the benefits that proper metadata tagging would give.

In answer to your question about Project X - if the documents were able to be (and actually were) tagged with "Project X", and "2009", it would be extremely straightforward.

Using a fixed directory structure, you're relying on the fact that you know where it was stored. Did you choose to store your projects by date? If so, can you remember when it was done? Was it stored by client? Can you remember which client it was for? Was it stored by development team? Which team created it? In a metadata world, all of those things could be tagged independently against any relevant document and you simply do a search for the attributes that you're interested in.

From what I've seen on the computers I've used, non-technical people seem to have far better filing systems in general. My mum and dad both organise their files and emails impeccably, whereas my file structure is so badly organised I can literally lose files for years before rediscovering them like an archeologist on a dig.

They also likely have a much lower volume of files to manage, being non-technical and all. I could probably get by with the single folder level at home, where I mostly just browse the internet and watch video on my PC, but having to manage all my various projects at work would be a nightmare.

How are you supposed to check out a source code repository? Many frameworks require things to be in a specific folder structure in order to work.

> At home, I have a rack of shelves with box and manilla folders. Each one contains different things like house bills, banking statements, insurance docs etc.

Inside one of the manila folders, do you keep an apartment building, with 12 floors, each floor with 20 apartments, each apartment with 3 rooms, each with 4 racks, 3 shelves on each, each shelf with 50 manila folders? Inside one folder, do you keep a wormhole to the 2nd bedroom in apartment 1409 in the building 2 doors down from the apartment building I first mentioned?

I think having levels of folders is a good idea, each level with different names, e.g. 4 levels: house, room, shelf, and folder.

"...I'd estimate [that] 9/10 people have all their documents in a single flat folder."

You pulled that out of your backside; I decided to use real data. My employer has extraordinarily loose security: our main file server has no access restrictions on any user's working directory. So, I am able to get a quick look at the filing practices of just under 200 people. Of these, 15 didn't use their personal folders at all, presumably preferring to store everything on their desktops. Everyone else had at least one level of folders in their directories. Roughly half of the company are developers, the other half are non-technologists, like sales, administrators, and trainers.

I asked my wife (MD of a mid-sized media company with over 500 staff) what her lot did. Every one of the middle managers she directly looks after have complex filing schemes of their own. She recently went through a big process with IT to create a centralised repository for project work so she is intimately familiar with how her team run their workflow. This is not a technology company; these are sales managers, marketers, operations people, creatives and so on.

9/10? No, not at all. 1/10 perhaps.

"...users can't be bothered to come up with hierarchies...folders are an anachronism..."

This is simply untrue. Neither the data nor my personal experience bear that out: My mother, a retired luddite who never used a computer in her working life and someone who has sent precisely six emails in her entire life, has a hierarchy of folders on the first gen Mac Mini I bought her a decade ago.

"...they just want..."

Assumption is incredibly dangerous. Be careful, especially if you are designing things for people to use. Moving away from hard numbers and into psychology, your thinking is simplistic in the extreme. Human beings absolutely love to organise things. Scrapbooking, Pinterest, stamp collecting. Hobbies that are basically just organising stuff. We love categorising the world: genre-ordered record collections, the Dewey decimal system, Kingdom-Phylum-Class-Order-Family-Genus-Species, Felony Murder 2, Captain-Commander-Lieutenant, Category Theory in mathematics, the Standard Model... People are a lot smarter and a lot more organised than you understand. Have you ever seen a toddler carefully sorting their toys? It's deep inside us.

Very true, I've been in IT for over 20 years and have worked at sites ranging from 10 users to over 13000 users. I can attest to the flat filing system as the exception not the rule. At my current employer, looking at public folders on network shares the average folder depth is 5 deep. Many have a main repository and then secondary and Tertiary hierarchies using symbolic links to the same contents to help people find what they are looking for.

I'm not necessarily disagreeing with you, but I do want to point out that you're talking about employees of a company that has a shared file server... That people use! I have several family members, that I consider highly intelligent, who work blue colar, manual labor jobs, for which they don't have email addresses, even as they were promoted to more senior and leadership roles. My uncle hates his computer. He loves his iPad. Furthermore, I know several more folks who have business email addresses, some kind of web mail, are not issued company machines, and maybe only check that email once a month. Consider service industries, like restaurants. The number of people that work these sorts of jobs likely outnumber tech savvy office dwellers 10-to-1. You live in a bubble. Most of us here on HN do.

Not unreasonable. The bubble in this case is pretty big though: it's anyone who works out of an office. Not necessarily 'tech savvy' by any means: I'm talking about Excel/Word/Powerpoint jockeys, HR managers, sales reps, designers, producers etc. These people's primary tool is the computer they sit in front of all day so there's at least a little familiarity there. The computer turns their thoughts into bits: letters, spreadsheets, presentations, emails. They work mainly in the ephemeral, acting as links in a chain of information, passing it from one person to the next and maybe massaging it a bit in between. They are used to flipping concepts around their heads and are fluent in the 'language' of information. This means they don't suffer much cognitive dissonance when dealing with multi-layered folder hierarchies.

Your blue collar kinsfolk have different tools: hands, for the most part, boosted by some array of domain-specific instruments. Those tools turn their thoughts into furniture, or repaired cars, or pipework, or cabling; I'd widen the group from traditional blue collar to include people like surgeons, too. They work in the arena of the tangible, so - and here I speculate - obviously tortured metaphors like nested folders grate on them and are much harder to adopt.

As to your numbers of waiters vs. office rats: there is probably some data from the Bureau of Labor/ONS. Work calls though :)

> 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

I could not agree less: Most people I know follow about the regular OS distribution, ie., most on Windows, some on Linux, and a few on OSX, plus the odd geek using what-not... The only cases that matches your "9/10 observations" are the few guys using OSX, and even then many converted from Windows and keep using their OS just as they did before. And everybody else is using a system where he cannot easily organize stuff through apps (ie., we probably all agree that OSX has the best inter-app interoperability) or otherwise is experienced enough to want full control of their own data and therefore keeps his data organized, eg., in a Dropbox folder hierarchy. And given the majority of people I know are Windows users with very little "IT knowledge", their behaviour is what I would put into the majority bin. According to my own obeservations at least, nearly all of these user-types rely on some increadibly convoluted folder hierarchy to store their music, photos, documents and the odd video.

Note that I am not arguing about the best way to organize folders and files, all I am saying is that AFAIK the very large majority of users does organize their files in deep folder structures (and, is using Windows Explorer to do that, too...).

"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."

9 out of 10 home / casual users: perhaps true. Among teachers using the 70 staff computers in this large open plan office, there is an amazing variety of carefully organised folder structures and layouts that typically, for each teacher, organise 8 to 10 courses each consisting of two sessions a week for 36 weeks. With overlap. And shared folders with colleagues.

If we used Mac OS X instead of Windows, it it really is the case that you can only have one level of folder, then my colleagues would have to recreate their heirarchies using file naming conventions. Messy, and hard to manipulate.

A database approach might yield an actual benefit: I'm assuming that would look a bit like Outlook's message view where clicking on the from, received, subject fields allows an instant reordering of the material. But tree like re-orderings would be needed to allow my colleagues to continue to organise their content as they do now.

Part of me likes the Jef Raskin approach, the content is the file name and you use incremental search to find a particular part of your work. It is hard to see how that works for media files.

I have no issues with changing how we organise material, but there does seem to be a shift in assumptions on how people will use their computers towards the superficial media stoage and comsumption sort of model. That won't fit everyone at all.

No, in Mac OS X you can have as many levels of folders as you want. I'm not sure what the article is trying to say… In fact, Mac OS X still relies in directory structure to… well, give structure to its filesystem. We still have /usr, /Volumes, /Users, /etc, et al.

I thought that must be the case, thanks for clarification.

I think the article may be referring to the directory structure in iCloud, which allows only one level of nesting similar to the folders feature on iOS and in Launchpad. John Siracusa's review describes it[1]:

"Only one level of nesting is allowed, and the "folders" are of the iOS variety, complete with tiny icon previews and inline expansion of their contents."

[1] http://arstechnica.com/apple/2012/07/os-x-10-8/12/

That's similar to the AWS S3 namespace, though deeper directory structures can be somewhat faked through use of additional '/' seperators, though if I understand correctly, they're not semantically significant.

> 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.

This is demonstrably false. Like probably many HNers I'm the "computer guy" for my family and friends; I have seen dozens of machines used by non-technical people, some as old as 80 years old, some as young as 10. Not one of them does what you say.

Everyone I know organizes their files in a directory structure (for pictures, usually by year/event, for example).

I think this is because 9/10 people really only have a handful of files (lets say < 50, ignoring photos because they are usually managed by a separate app) that they ever deal with, so one "My Documents" folder with a sort by date option is easy enough to deal with. I don't think it's because people cannot grasp the concept of folders. Alternatively, look at email, where the volume to deal with is far greater. I would say that most Outlook users put their email into folder structures, and I have seen quite elaborate set-ups created by people that are not technical whatsoever.

  They have all their pictures and video in a tool that 
  organizes them into albums and such without them having to 
  deal with folders.

Yeah, and they organize their albums by category, containing albums by year. Or they organize theyr albums by genre, containing albums by artist, containing albums in chronological order.

And how exactly does that differ from folders and does that support the point of the OP, that folders aren't difficult?

Referring specifically to something like iPhoto or iTunes, the general purpose or intended paradigm is that users don't have to manage file folders or folder structures themselves.

The whole idea is that users can't do it, especially when complexity increases (it's not a given that power users are great at this either) and that everything you have should just work (when you upload photos, it's organized by location date, etc., on import, automatically or music is automatically there).

As I understood it, the author didn't claim folders were the epitome of file management, but rather lamenting that newer systems don't even give us folders.

Then again, for many tasks, a tree truly is the best way to structure files (start broad and then home in on a file even if you have no clue about the filename or what the file contains or even the type of the file) and any file management system that doesn't recognize this is seriously flawed.

I got hooked by WinFS (then again it was many many years since I last heard anything about it), a traditional filesystem with a database layer on top seems like a good start.

Agreed. For example trees of source code seem to fit the hierarchical structure very well, because it can (almost) map directly to projects, modules, submodules and classes, and conveniently separate them from e.g. build products or configuration files. Trees are not evil, but they are not the holy grail of file management either.

From a historical point of view, a traditional filesystem with a database layer on top seems to be the most logical way to go. Personally, I think it would be interesting to see what would happen if someone did it the other way around: create a whole new way of organizing files that doesn't use trees, and allow layering some kind of 'tree view' on top of that.

If not for a specific few lines of code explicitly forbidding hard linked directories, all of the modern file systems would actually be directional graphs.

Truly? So, what is the best way to make a hierarchy of, say MP3s:

- year-performer-composer-star rating

- genre-year-song title

- album title-song title

- ...

You get the same problem almost everywhere. Is it year-project or project-year or maybe customer-year-quarter-project?

Yes, for many tasks, a tree is a good way to structure information. The problem is that the choice of tree can be widely different for different tasks (for example, 'that song you played last week', 'that minute-long guitar riff by X')

I think a hierarchy should be like an index in a database: set by an expert to match the most common access pattern, but not enforcing other access patterns. Hierarchical file systems are good at the former, but atrocious at the latter.

And we sort-of already have WinFS, in the form of full-text indexes on file systems.

Well without a tree structure you're still going to have an issue with the names.

Personally I use Album Artist/Album/DiscTrack. Artist - Title.ext

But say we did away with folders - you'd have to put all that data in the filenames to sort properly anyway!

Naaaaaah, you'd just have metadata!

I think the last time I used the filesystem to browse my music was in 2003. And it was dreadful. I use a music library app in which I can decide which way my music is ordered. Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem.

The music library app is especially tuned for ways to view my music that make sense for music. It makes those easily accessible. The file system is wholly inadequate for that task.

The library app takes care of the underlying folder structure – but that’s an implementation detail I absolutely do not care about. I don’t even know how it looks. (I just looked it up, it’s “Artist” – “Album”, the same structure I used before I started using a library app.)

I’m not sure that the file system is really so bad (at least I’m relatively comfortable with it) but I do think that for certain specialized tasks it’s massively preferable to have dedicated apps. Music and photos are my two prime examples.

"Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem."

from the "to each his own" file: i have never understood why anyone would care about sorting their music in any of these ways. To me, none of these are ways to "view my music that make sense for music." On the other hand, I find a directory structure for albums and everything else chucked into a giant directory to work just fine, as it supports the sort order I do sometimes care about, mtime. Normal search tools like locate work pretty well too.

In previous comments on related articles on HN, I have pointed out that files, and to a lesser extent directories, are good because they serve as a universal protocol-of-sorts for dealing w/ blobs of data. That allows you to use the system that works for you, and me to use the system that works for me, and yet we can still share files and move between systems etc. with little headache.

I am actually sympathetic to moving to a tag-like system that supports hierarchical tags (gmail style), so that multiple organizational structures can be imposed onto a mess of files. I also find it funny that that's more or less how unix file systems work under the hood.

All of these music filing schemes fail miserably when confronted by Classical music. There you often have four 'obvious' candidates for leading tag---composer, performer, conductor, title etc. There is even an entertaining amount of discussion on the net about the best way to solve the problem. The only point of commonality accepted is that the iTunes approach simply does not work. Then every one starts to bang their personal agenda drums; all sadly out of sync. And this for a subject that every one 'knows' Move into other areas and you will find similar problems. This does not even begin to touch the problem of tagging as a speed bump---takes time, ask a librarian :)

How much music do you have? 100 songs?

I have 5,380 titles, I cannot for the life of me imagine how to deal with that inside the confines of the file system. I want to browse my music. (It probably doesn’t help that I despise search. Search is no alternative to browsing for me.)

(Besides: This is not some evil scheme. Metadata for music is completely standard. My music library app – and every popular music library app – puts music in straightforward human-readable folders. That’s a nice fallback if all else fails – but to me it is just that. A fallback.)

I have 3575 music files on my current main hard drive, organized by hand into an /Artist/Year - Album Title/File.ext structure just fine. I don't listen to classical music or by genres, though.

I have around 69,000 and I find that due to the fact that most music players choke on that amount, that often sorting by filename is one of the fastest ways to get my music into a decent order.

Also in response to other post - you can quickly rename your music with something like Musicbrainz Picard (cross platform) or foobar2000 (Windows).

for the record, I too have about 5000 tracks these days.

I use both. I've got about 10,000 tracks sorted as Artist - Album/Song.ext in the filesystem. Since I'm a bit of a geek about my music anyway I remember which song is where anyway and if not, there's still find.

In the music player (mpd + ncmpcpp as a client) everything's sorted using tags so I can do all the searches I ever want quickly.

The filesystem way of storing things is merely about redundancy and whenever I want to copy stuff onto an external device. I do not want to use an app to sync stuff onto my smartphone. That's just an extra app for a trivial task. Additionally it provides me with a tad more control. And seriously? I couldn't care less about copying over all MP3s recorded by a band Z in year X belonging to genre Y (or some other sort of query). When I copy music to the phone I'll copy albums and that's what this file structure is absolutely perfect for.

Don’t you browse your music? I’m very particular about my music collection and I definitely need to browse it. Sometimes I just do not know what I want to listen to, so search is useless. And looking at something like all albums from 2009 (because I know some good music came out then) can be very useful for me.

I do not care about the structure on the disc. I use my music library app to browse.

I said that many things are well represented by trees, not all things...

And we sort-of already have WinFS, in the form of full-text indexes on file systems.

We have nothing like WinFS in practice, we don't think or use our filesystem as if it was a database. That is the key difference, not the implementation.

> start broad and then home in on a file even if you have no clue about the filename or what the file contains or even the type of the file

But this file system does not construct itself and if you made a mistake while sorting a file you hit the search field after a while anyway, because you can't find the file in any subfolder. You're right, a mixture of both will probably the next step. But it seemed to me that MS isn't trying something new with windows 8 and the metro interface, did they?

I completely agree but I would add that a lot of people start out by using folders but it needs a little care and attention to keep it all organized so they end up with a few folders that contain everything.

The beauty of a filesystem is that it is somewhat independent of the applications that use it. So if your photo app index gets borked then you haven't really lost anything too valuable - apart from any meta data that is not stored in the image itself. Put everything in a database and you risk bricking the entire computer as far as the user is concerned. Of course this applies to files and folders as well but these are a little more battle tested.

Way back in the early 1990s Microsoft's Cairo was supposed to be based on an object database which got rid of files and folders. Sine this is a relatively old idea I'd be interested to know why folders have not been replaced yet.

You're assuming the database is tied to each application; that's only one possible approach.

NEPOMUK (currently a KDE project) is an example of a database which is independent of any particular application. It stores RDF metadata about each file (and about other things too, like contacts, events, etc) and provides a common ground for any application that connects to it.

In the end, the filesystem is just a key-value database too...

Google had a Desktop search tool to do a slightly similar job.

Yes and no. Google Desktop was a fully contained application; indexing was just an internal mechanism for its own functionality.

NEPOMUK is closer to an actual filesystem, in that it's not user facing; it's a service for other applications, like email clients, media players, etc. This allows them to almost effortlessly¹ share information like user contacts or music metadata.

¹ Apparently, a basic but functional email client can be built on top of the platform in 10 minutes.

I like that your main argument against trees for organizing files is that people use specific applications per file type to organize them... _in trees._ Photos are sorted by year first and album then. Songs are sorted by artist first and album then. People understand trees just fine.

Also, the problem of being unable to put the same thing in more than a place is a) not one fixed by app silos b) part of our daily life while sorting physical objects c) fixed with filesystem links (soft/hard).

Your argument only proves today's mainstream file management programs/save as dialogues/etc. are inadequate. Trees remain the best simplest model to organize files in a filesystem

Absolutely. The knee-jerk reaction of the author is painful. Mindless copying of what went before is how we end up with bad ideas being repeated over and over. When we try new things the good will survive, and the bad will be improved or removed. When we merely copy, we maintain the status quo. I'm glad to see Apple innovating, and I'd love a system which mostly gets rid of folders to be a success. Let's watch this space.

It took about 10 years for my mother, a daily Windows user, to understand folders. I lost count of how many times I explained it. The previous generation seem to particularly struggle with digitally-native concepts.

Folders are of course a broken metaphor. In the real world folders are not placed inside other folders - it makes no sense! The entire file concept is anachronistic, why do I care how the document is stored? Why do I even have to save? Why can't I undo after closing and re-opening a program? Why a I forced to give a document a name on disk when it already has a title? Etc...

Over the years I've moved from a fairly hierarchical arrangement of my files to one closer to maybe two levels (source code excluded), the congnitive burden is so much less - it's the advent of indexed search which has made this possible.

Files are sorted into filing cabinets or boxes, which are stored on shelves, in different rooms etc.

> I'm glad to see Apple innovating, and I'd love a system which mostly gets rid of folders to be a success.

Okay, let's not get carried away here. They aren't doing anything new. This is old hat, and they are just now working it into OSX. This isn't some Apple invented paradigm, this has been played with many times over.

> It took about 10 years for my mother, a daily Windows user, to understand folders.

Are you really sure about that? I have a hunch the difficulty wasn't with the folders themselves, but rather the badly-designed navigation interface of the Open dialog, and where it's starting from.

I've found that understanding the folder concept is one of the easiest things for new computer users to grasp.

The Open dialog certainly caused a lot of trouble. Perhaps I should have said learned to use effectively rather than understand. The concept of hierarchical folders is not particularly challenging, but the practice of using them is usually a real pain for little upside. One of the main use of folders I see is people grouping their work by year, month, etc - what's the point when the file has that metadata anyway?

I can totally agree. The "folder" file structure is a tree structure. This is easily understood if you have a CS background, but for new computer users it could be a huge mental step if try to explain that you can stack folders endlessly into another.

Additionally you have to think in terms of hierarchies instead of groups to make a folder structure work you. Something like: Media > Pictures > 2012 > .....

It seems to me that Apple was never a Fan of folder structures. Just look at the way iPhoto or iTunes work. They basically are a clients to your media library.

I assume the main reason this works is because pictures and audio files already have a fairly big amount of meta data like music genre or location data.

A scenario where I can find all I worked on in the office yesterday wouldn't be that bad.

Jesus Christ, iPhoto lock-in is one of the most scummy things Apple has ever done. You don't have to be a CS student to feel the need to easily move a bunch of photos easily from your local computer to an external storage device or even upload in batch to something like picasa. By completely blocking the user from the directory structure, Apple made sure people would share the iPhoto albums only with a select few that Apple had chosen for us.

That's just pure BS. If you want to get your photo's out of iPhoto, all you have to do is select them, and drag them to wherever you want to have them.

If anything, iPhoto is the poster child for applications that do not need hierarchical file systems. Sometimes I want to have all photo's for a certain event, sometimes I want all photo's that are less than a year old, sometimes I want all photo's that have my cat on them, and so on. How does a tree-like organization of pictures facilitate making subselections like that?

You are just taking your allergy to applications that manage your files in ways that are incompatible with you messing around on the file system, and making an argument in favor of hierarchical file systems out of it.

Wanting to access my photos doesn't mean I want to copy them elsewhere. Most of the time I want them to stay where they are, just use them with a different app.

I'm not saying nested folders fit everyone (although my anecdotal experience differs greatly from yours), but you don't have to be a geek or an old-timer to appreciate that your data is not tightly coupled to an app.

I don't know enough about new approach Apple has taken to comment directly upon it (yet). I do think original article was crap (and this one isn't great either).

But having to use the app to manage files, is a whole new paradigm that someone has to learn which is exactly what people are trying to avoid in the first place. So either teach one paradigm to a new user and stick to it (aka using the file system) or application specific paradigm (aka use iphoto to manage photos, itunes for music files, etc). So depending on how good you are at controlling the application usage from one app to another you end up having to learn each applications way of doing things instead of learning one way of doing things and using that throughout.

As a developer and previous life as IT support I fully support the teaching the file system paradigm because it works better overall.

All of the tag resorting you are doing within iphoto can and is done rather easily within the file system as well so what has that added other then more complexity?

Both task can easily be achieved. Just select and drag them out of the app into any folder.

I don't like everything about iPhoto (it's database design is rather monolithic and not build for user that have many storage devices that are not always plugged in like external hard drives)

But I wanted to say: "hey, look here! We are already managing many files without folders."

1. Depending on search for file access for most of the time means either the user has to remember the file name to a certain extent (thereby making it a lookup system) or the file search system has to be smart enough - the former is too burdensome for the user and the latter isn't there yet.

2. Your argument is biased by the idea of using multiple machines - most people don't deal with the _same_ data on different machines. If all those machines have the same fundamental way of organizing files (i.e. through directories) then I don't see how that is unfriendly to the user.

3. File management is mostly needed in scenarios where you create/consumer a lot of files - e.g. lots of PDFs or lots of photos or lots of music. The tree-based directory structure is the most intuitive way to organize files in those scenarios. You cannot possibly claim that most people would be happy with a single flat folder system for these scenarios.

File management is of course unnecessary in cases like notes or reminders where you don't need to be bothered by organizing files for each entry in different layers of directories. But this can't be the determining factor for completely abolishing the directory structure concept.

Reply on news.ycombinator.com