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