The problem with one-level folders

Bmyq5_medium

This is a response/critique on Olver Reichenstein "Mountain Lion's New File System" published july 25th.

The ping-pong

Apple's intentions on hiding the file system have proven to pass the test of usability and time, but only because they were so easily understood. iPhone OS 3.0 (or later known as iOS 3) introduced the paradigm of opening a file with a multitude of installed apps. It worked in a familiar way: one file, many apps. The current iCloud implementation of app vs file is extremely dissonant: only one file can be used by one app. Of course if iOS' philosophy is to be continued, then to open a file which is contained in app A, then first the app A should be open in order to transfer it to app B. This is a fundamental mistake on both implementations of the iCloud platform that will get fixed by Apple, but for now, the Mac App Store can be severely hit by this, there must be App variety to modify the same information and thus by extension, keep the Mac ecosystem alive.

App versatility

Being able to modify the same file with different applications is crucial for the App market, if people get the choice of selecting between two apps, one of which the user finds more appealing or feature-rich, the variety of apps will increase, and developers will be able to reach different kinds of consumers.

Developers love to build apps, usable apps, maybe ones that accomplish the same purpose as ten thousand more in the app store, but with their own twist. Take Clear for example, Apple's App Store certainly doesn't lack task tracking apps, but they differentiated themselves by creating a gesture-based workflow. Maybe people just bought them for the gesture gimmick, but it certainly seemed to appeal to a big portion of Apple's user base, and yet, they received a never ending stream of critiques from so-called UI experts. There's clearly no single solution for a problem involving multiple people using different work flows with multiple inputs, and iCloud's single-level folder solution is no different.

Why folders-in-folders

The classic folder inside a folder paradigm may seem like quite an extraordinary task to maintain, particularly for power-users who need to keep a fine description of the each file, that description being the folder hierarchy. But as Oliver has pointed, the brain can hold just so much information, and keeping track of every file takes more brain power than most of us are comfortable to admit. But our brain classifies information based on a context: every document that has a relation with a project. Each piece of information that we unload to the computer is classifiable, but we won't do the classification. That's why we hate folders, because they demand for the contents to be classified, but we won't do it, that's the computer's job, and that's why we use computers, to think and organise all the inputs in our lives. Can that information live in just a folder-inside-a-folder paradigm? it certainly has proven to be effective to a certain extent, but we can do better.

The fundamental flaw

Using this paradigm, we assume that the topmost folder describes everything inside it, and each folder inside it is an specialisation of the superior one. This is where the fallacy of information organisation with folders-in-folders arise, there are two misconceptions that are true with folders but false with any kind of information:

  • Granularity cannot be achieved other than a complex hierarchy
  • A file cannot be described with two classifications

Since we've taken this paradigm for granted, we could save all of a project's files inside a folder and be done. The next day, to resume work we could find every piece of information about that project inside a folder, and we don't need to remember that if I want to open a mockup, I have to

A single-folder hierarchy does not address this issues, it aggravates them. Of course we could dump every document inside a folder named "Documents" and use spotlight the rest of our lives, but it still assumes that we need to know the right keywords, and thus the information still hasn't been completely unloaded.

Of course, some can object that to efficiently work on a project, they need to have a general grasp of it, and yes, that does work for short term data management, but if we're to use this paradigm for years to come, remembering a brief description of that "something" project you were working on 3 years ago will prove quite a difficult task, not to mention having to sort the "Documents" folder by date and guess where it could be.

A partial solution

How could we classify a single file with more than two descriptions? a partial answer: tags. Back in '05, when Microsoft was still in the early alpha builds, they hinted at a "database driven file system" or WinFS. It was a developer's dream, every file would be swimming in a sea of information, classified by a database. Long would be the days in which the file could only have a name and extension, if it was a music file, it was described by its name and artist, it it was a photo, by where and when was it taken, it was going to be a centralised information bank. This way if a project involved multiple forms of files, they would be easily manipulated by purpose-specific applications. This is where iCloud could converge. If every application could read every tagged file that seems compatible with is (that is photos with photo editors, music with players) then the cross-application file management problem would be solved.

But isn't tagging the same problem?

In some sense, yes, we could have an application that automatically tags the file depending on the project you're currently working on, using different factors like date, your own tags, people involved, etc, and since granularity is the biggest reason why people still use folder-in-folder systems, it could be easily solved by either creating much more specific metadata, which is not limited to the hierarchical folder classification limitations. You still have to remember a keyword to look it up, but it wouldn't need to be any kind of specific in order to be found. In a single-level folder system, if you want to look for a project involving "noodles" created 3 years ago, you'd have to open the enormous "Projects" folder and order it by date hoping you can make it up just by the name. With file tagging, we could search for the tag "projects" and "noodle", since we wouldn't be able to remember every aspect of it (the data has been unloaded to the computer) we could look at the relationships that they have with other files by tagging, so in this case, we learned that weren't looking for the keyword "noodle" but rather "soup", something that couldn't be deduced by mere Spotlight results.

What's next?

Sadly, we have to wait to know. As of right now, if you want to use just use Apple services with Apple products, you must oblige to the Apple way, but as it always has been, Apple has a greater plan in mind, probably involving much more flexible solutions like file tagging or some Cupertino magic, only time will tell.

So, what do you think?