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.
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.
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.
But I guess since Apple haven't done it yet, it doesn't exist to hipsters.
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.
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.
Are you suggesting that hardlinks are good enough for my mom, too?
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 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).
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
It's a strict improvement (in the mathematical sense) if the tagging system allows you to view items with no tags.
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.
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.
This is equivalent to hierarchical tags (if you allow that an "untagged" file is equiv. to the root directory) but maybe less confusing.
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.
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.
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.
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.
In fact with folders and tagging you are getting the best of both worlds.
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.
> 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.
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.
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.
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.
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.
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 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...).
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.
"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."
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).
They have all their pictures and video in a tool that
organizes them into albums and such without them having to
deal with folders.
And how exactly does that differ from folders and does that support the point of the OP, that folders aren't difficult?
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).
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.
- 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.
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!
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.
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.
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.)
Also in response to other post - you can quickly rename your music with something like Musicbrainz Picard (cross platform) or foobar2000 (Windows).
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.
I do not care about the structure on the disc. I use my music library app to browse.
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.
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.
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?
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.
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...
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.
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
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.
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.
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.
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.
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.
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).
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?
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."
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.
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.