24 Aug 2012

The Implicit TagSystem — A Proposal For Moving the Filesystem Forward

The filesystem serves two roles — it's an interface to both users and applications (API) to store data in. There's been discussion about the filesystem's drawbacks as a user interface, and how we can move it forward. Unfortunately, most of these posts point out the problems rather than offering a solution. Which is reasonable, since this is a hard problem. I have a proposal, but I don't know if it is good enough. In addition to, and perhaps more important than, discussing any particular solution, I want to take a look at the general considerations that apply to this problem, and how they broadly determine the kinds of solutions that are possible. Let's dive right in.

There are many problems with the filesystem. Non-technical users don't understand the concept of nesting objects in other objects of the same kind They undersand files, and files belonging to folders, but not folders belonging to other folders, arbitrarily deep. As I think back to my earliest days of computer usage, of using WordPerfect on MS-DOS, the filesystem was a major challenge after I'd otherwise understood using the computer. You can slowly learn one thing after another at your own pace, but then you run into this wall called the filesystem — the learning curve suddenly becomes very steep. Hierarchy is natural for geeks, but actually complex for normal human beings.

Nesting is not the only problem with the filesystem. It often doesn't quite fit what you want to do. For example, files can belong to only one folder, but in real life, things belong to multiple categories. Stock options.pdf logically belongs to both the "work-related" and "financial" folders, for example [1].

Nor is there only one axis along which you can define categories. For example, you can categorize your photos by location or by year. Folders force you to anoint one true organisation. Then folders and files don't have an order, whereas you often want things to be ordered in some way.

The filesystem also ignores the organization already present in the files, like file types, modification times or embedded tags like ID3 or EXIF tags. Imagine the file browser automatically categorizing a directory containing tens of thousands of files into documents, music, video, etc. And if you have too many "documents", they could be categorized as text, spreadsheets, etc, with "text" being further categorized if needed into plain text, Microsoft Word, etc.

Why should I have to create a directory for my music when the system can tell from the file type that it's music? Further, why should I have to manually organize my music into subdirectories by genre, band or album when that information is already encoded into the files in a form that the computer can recognize? And no, iTunes doesn't count. It's fine as far as it goes, but the question is: why isn't the filesystem itself smart enough to logically organize data based on its characteristics? Why should there be another layer to work around the brokenness of the filesystem? Making me sort the music into various folders is making me do dog work, essentially creating and maintaining a parallel organization to the one already in the files.

Similarly, why do I have to organize my photos by location or by year when the system could read the EXIF tags? As another example, imagine a mass of documents automatically grouped by when they were created, modified or last opened, like "Today", "In the Last Week", "In the Last Month", "This Year", etc.

Another failure is Microsoft Word's File Open dialog box listing all the files in the filesystem that it can open. It should just list the files it can open. Why even show the others? If there are only a few Word documents (or other files that Word can open) on the filesystem, wouldn't it be better for it to bypass the hierarchy and just show those few files? Only if there are lots of compatible documents is a hierarchy needed to sort them out. Even then, show only as little hierarchy as needed to sort out the relevant documents. For example, why show directories that don't contain any documents the app can open? File open dialog boxes tend to confound users by showing irrelevant stuff.

In fact, this is part of the reason web apps like Google Docs (disclosure: my employer) are popular. Or apps that hide the filesystem, like Simplenote or iTunes [2]. You can lose your Word document in the filesystem, because you forgot where you've saved it, or if you don't know that there's even such a concept as saving a file in a specific folder. But you can't lose your notes in Simplenote or Google Docs [3].

So these are the problems with the filesystem: nesting is extremely hard for non-technical people to understand, files get lost in the hierarchy, the filesystem assumes that there's only one way of organizing your stuff and that single way consists of diving it into non-overlapping categories, the filesystem ignores organization already present as file types, creation/modification/access times, tags such as ID3 or EXIF, and the filesystem doesn't show the relevant files in context when you're in an app trying to open a document.

Before we look at solutions, let's see what we'd consider an acceptable solution. We can look at this in two ways:
1. Something that satisfies the vast majority of users' needs, while being much simpler.
2. Something that is as powerful as the filesystem, even if it's not significantly simpler.

Apple has a propoal on the lines of (1): iCloud supports one level of folders. Actually two, with the app effectively being the outer level of organization. Data is partitioned by app, and within each app, you have documents and folders of documents, only one level deep [4].

Is the iOS solution good enough for a majority of users? A lot of people would immediately answer no, but keep in mind that the people writing these blogs in the first place are power users. My mom wouldn't write a blog post on the state of the filesystem, but she does use an iPad. It's hard for us power users and geeks to reason in the abstract when our instincts tell us otherwise, so maybe we should keep opinions and instincts aside on this particular issue and take a data-driven approach: tablets are in their infancy, on a historical scale. What if there are hundreds of millions of tablet users five years from now, of which the majority find that iOS's apps + one level of folders is good enough for their needs? Then we could declare the filesystem problem as a power-user issue and move on.

If the answer is no, that apps with one level of folders are not powerful enough to organize and access documents for the majority of users, then the question arises, can we add a little to the iPad to cover the majority of use cases with only a small increase in complexity, rather than the cliff of the filesystem — extremely complex and extremely powerful?

I can imagine iOS 7 having a Documents app that liberates documents from their apps, as containers, and shows you a view of all your documents independent of the app that created them. Once you select a document, it might open it in the default app for that document type, or in the app that created that document, or let you choose from a list of apps that can open that document. In other words, yes, apps are fine as one way to organize files into groups, but not as a jail that confines the documents by application.

A way to pass documents between apps is also sorely needed. Imagine writing an email on your iPad, realizing you have to attach a document, clicking the Attach button and choosing an app and then a document within the app, all without leaving Mail. If iOS liberates documents from their apps as container, might that be enough, again in the 80/20 sense?

If even that is not enough, we can use the ideas above about implicitly organizing files into groups based on type, creation/modification/access times, which apps can open them, tags in MP3 or JPEG files, etc. Think of it as a file manager that, when you browse to a folder, automatically groups the files in that folder into virtual sub-folders for you, on the fly, based on many criteria. I can imagine going to my Music folder and choosing to view by genre, say Electronic Music, then choosing to view Electronic music tracks downloaded in the last month... Think of it as iteratively refining a multi-dimensional search, but with a UI closer to browsing (by selecting pre-populated categories like genres, creation times, etc) than searching [6]. And the browsing UI needn't look like a file listing. I can imagine seeing my photo collection as a world map, as Picasa Web Albums shows you.

The question is whether this kind of implicit organization, along with one level of folders, and apps as another level of organization, provides most of the power that users need to organize their data, with less complexity than the filesystem [7].

I'd go one step further and use tags instead of folders, to fix the problem of real-world data belonging to multiple categories at once. Besides, if we have only one level of organization, it's important for that single level to be powerful, in the sense of a document having multiple tags.

Putting all this together, I strongly suspect that a single level of directories is enough if we make use of all the other kinds of organization that already exists:
1. Document type, which could be as granular or fine-grained as the user wants. Coarse-grained would be organizing into documents, music and pictures. One level finer would be plain text vs rich text. The finest level would be "Microsoft Word documents".
2. Apps that can open the document.
3. App that created the file
4. Creation, access and modification times.
5. Implicit tags like ID3 or EXIF tags.
6. One level of folders.

The argument is that a single level of tags together with all this implicit information information that already exists presented as virtual folders will probably do away with the need for a filesystem with nested folders, again except as a power user feature.

But what form will this power user feature take?

For example, might we use tags instead of hierarchical folders? No, you still need hierarchy — otherwise you are likely to still have an unmanageable number of tags. My Dropbox contains 743 folders, for example. And that's just my Dropbox. I'll go crazy trying to manage 743 tags without a further level of organization. There's no way around it — the filesystem is extremely scalable, since you can nest folders as deep as you need, dealing with thousands of entities as one entity and thereby being able to manage complexity. This is a basic human tool. Take away hierarchy, means taking away this tool to manage complexity, and you cannot manage an extensive collection of documents any more.

So we need hierarchy or nesting. But instead of folders, which require a file to belong to exactly one folder, we can have tags that may exist in two forms: as subtags within another tag, or as standalone tags. For example, I currently have have a folder structure like: financial documents > tax > 2011-12 fiscal. I might map that to tags, creating a nested tag for "tax" in "financial documents" and another for "2011-12 fiscal" in "tax". Nested tags behave like nested folders — just as adding something to a sub-folder also adds to to the parent folder, applying a sub-tag to a document also implicitly applies the parent tags. This preserves the organization you've set up, rather than letting it decay as time goes and more files are created that happen to belong to the sub-tag but not to the super-tag.

But, of course, tags are multi-dimensional. I might also categorize stock options.pdf as being both "work-related" and "financial", for example. This is a different axis from the year. So I can look at my tax documents by year, or by the  source of income (salary, stock options, etc). That is, I can organize my data in multiple methods at once, and each of those methods can further have overlapping categories.

So, instead of folders and subfolders, let's have tags and sub-tags, where a file can be tagged with any number of tags, and tagging a file with a subtag automatically tags it with its parent tags.

Since this is more flexible than the filesystem, it will need a shallower hierarchy for the same organization. But is this multi-dimensional nested organization even harder for users to understand than the single-dimensional nested organization of the filesystem? Are we making the problem worse?

A system that's more complex to learn and understand may actually be simpler to use once you've mastered it, if it can manage complexity better for you. This is a tradeoff between the complexity of learning the system and the complexity of day to day use. I don't know if the nested tagsystem meets this bar.

But the single-level tagsystem may be better than the filesystem of today, being easier to understand, while giving most users the power they need, and not forcing them to spend a lot of time manually organizing their files.


[1] No, symlinks don't count. How many people use them to categorize their data? It's an ultra-geek feature.

[2] Apple calls these shoebox apps. Some of them use a database to store their data. Some may use plain files, but they are saved in directories hidden from the user, like ~/Library. They don't have the notion of opening or closing documents (even with autosave), or of each open document opening another window. They are single-window apps that hide the filesystem.

[3] No, search is not a solution to this problem. Search is fine as far as it goes, but one shouldn't be forced to use search because the organization is broken. Instead, let's fix the organization. Search and browse are two different uses.

[4] iOS already supports one level of folders for apps. This can't be a coincidence. Maybe they deliberately chose a consistent scheme for organizing documents as for organizing apps — one level only.

[5] In other words, on desktop operating systems, you can use your folders as the first level of organization, or the app. This is two ways to do the same thing, and it's not surprising that Apple got rid of one of them. Each way definitely has its own advantages, but at the end of the day, they are two different ways to open a document.

[6] This organization may not be the one that you'd have created if you were to do it manually, but that is secondary — most users care about an organization that works for them, rather than a specific organization. Power users might create their own organization when they find that the auto-generated one isn't good enough, which is fine, and not an argument that there being an auto-generated organization in the first place, rather than disarray.

[7] A filesystem also facilitates interchanging documents from one app to another. Can we instead define a protocol that lets an app pass a document on to another one without the user having to explicitly export it from the first app into the filesystem and then import it in to the second? Surely that's a kludge.

Android content providers are one way we might do this. They let one app browse data held by another app by going through a standard interface implemented by the app with the data. This works for information  not exposed as documents, too — you could write an email backup app that shows the user a list of emails in Gmail and lets him select some to be backed up.

Another way of interchanging data between apps is for the apps to work together, by having one app use the second one's API. An example is Simplenote's option to sync with Dropbox. You don't explicitly save a text file locally from Simplenote to Dropbox.

No comments:

Post a Comment