ryan.freebern.org

If people in general were truly good at remembering tiny details, we’d never lose track of our car keys or the TV remote, and we’d always remember what time we scheduled that doctor’s appointment for and the date of our sister-in-law’s birthday. Thing is, we’re not. Human brains always have trouble with small details, and we constantly have to use memory tricks and the like to get something to stick. Computers, on the other hand, are great with details. Their whole point is for them to be able to keep track of billions and billions of bits of information and manipulate them for us. Why, then, do current filesystems require us to keep track of lots of fiddly information?

The Filesystem is a Robot Butler

Picture this: you wrote a paper by hand recently about chimpanzee mating habits and you put it somewhere in your house. A while later, you want to fetch that paper again, and thankfully, you have a robot butler to do the fetching for you, but first you need to tell the robot butler how to find the document. If the robot butler is like the current computer filesystem, you’d have to say “Robot Butler, bring me the document entitled “Hey Good Ooking” that’s in the yellow folder in the center pile on the top shelf of the second shelving unit on the western wall of the small room downstairs.” However, if your Robot Butler was designed for maximum usability, you’d just have to say “Robot Butler, bring me that thing I wrote about chimps,” and the Robot Butler would know just what you were talking about.

I dunno about you, but I’d rather have that second type of Robot Butler. Current computer filesystems are designed to be efficient for the system, and for programmers, to use. Their tree structure is logical and easy for simple algorithms to parse and build. However, to a human, trees like that can become unwieldy quickly. When I want to access something and I can’t remember if it’s in /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, or /usr/X11R6/bin, that’s a problem. People don’t remember which branches of trees to follow to get to the fruit they’re looking for, they just look up and grab the first fruit they see. A filesystem should allow us to specify what we’re looking for based on metadata–that is, easily-remembered contextual information about the thing we’re looking for. When I want to open that paper I talked about above, I don’t care where in my filesystem tree it’s located. I just want to say “open the document I wrote a few days ago about chimps” and have it appear before me. “Tagging,” which is all the rage on the web these days, is a useful and simple type of metadata that makes categorizing and finding information quicker.

A Humanized Filesystem

To solve this problem, we need a database filesystem designed primarily for human use. It needs to keep track of all the metadata it can, things like when the file was created, who created it, what type of file it is, and keywords it can extract from the file, as well as allowing us to specify our own metadata for it. Files should be associated into projects or packages for easy access. When we feel the need to view our creations, they should be grouped by default into projects and ordered by when we last worked on them, so that our current projects are the first things we see, and finding something we worked on last week is just a matter of scrolling back along the timeline a little ways.

A filesystem like this would require us to ditch the familiar but frustrating “open file” dialog that we’ve all become so used to. Opening a file will no longer be an exercise in digging through tree branches. Instead, the system will just need to prompt us for metadata. The new “open file” dialog will present us with a sensible selection of contextually relevant projects (recent ones at the top of the list, of course), and ask us to type some keywords. If we need to narrow things down further, we can select a timeframe or a filetype for the file we’re looking for.

Efficiency through Organization

Furthermore, we don’t expect one program to handle all our different filetypes for us, so why do we expect one filesystem to be the right choice for every type of file? I visualize four distinct filesystems on a computer: two for the system to use, two for the user.

For the system:

• Application filesystem: small blocks, organized to keep each application’s files clustered. All application settings, etc. stored in the AppFS. Programs bundled into packages so that uninstalling is as simple as deleting the package, and all settings go with it. Shared libraries are also stored in the AppFS.
• Cache filesystem: small blocks, used for high-traffic things like cached web files and temporary files. Transient user-specific application data, basically. When the CacheFS is close to full, the oldest stuff begins getting auto-expired, but until then it’s easily and quickly recalled.

For the user:

• Document filesystem: small blocks, designed to store user’s documents: letters, stories, papers, memos, etc.
• Media filesystem: large blocks, designed to store audio, video, and imagery. A notable difference in this filesystem could be the generation of psychoacoustic and psychovisual metadata for each file, to help keep track of media based on what it looks or sounds like instead of its exact data.

Of course, these different filesystems would be largely transparent to the end user. They wouldn’t need to know or care which filesystem is used to store a specific piece of data, and the operating system and applications should be designed to make it a non-issue. The organization of data among the filesystems is only there to make the system more efficient in regards to drive space and more sensible for programmers and software designers. Additionally, fully encapsulating applications into packages in the AppFS will keep cruft from building up in the system, and restricting most user activity to the DocFS and the MediaFS will help maintain software stability.

In the next and final installment of this series, I will explore how the system can proactively become more than just a glorified calculator by sensing and incorporating context in its algorithms.

(This post is the fourth part of my five-part post series “Reimagining the PC.” You might like to start back at the beginning.)

This entry was posted on Thursday, Apr 19, 2007 at 7:31 am and is tagged design, technology, usability. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.