Derivadow

As Alan Cooper points out: Disks are a hack, not a design feature (About Face: The Essentials of User Interface Design); they are a hack because we can’t afford the desired solution: computers with 80 GB of non-volatile main memory. So instead of our desired solution we are stuck with hard drives and filesystems. However, he argues this shouldn’t mean that users are forced to deal with the counter intuitive two-copy filesystem.

 “The implementation model of the file system runs contrary to the mental model almost all users bring to it. Most users picture electronic files like printed documents in the real world, and they imbue them with the behavioural characteristics of these real objects. Users visualise two salient facts about all documents: First, there is only one document; and second, it belongs to them. The file system’s implementation model violates both of these rules. There are always two copies of the document, and they both belong to the program.

Every data file, every document, and every program, while in use by the computer, exists in two places at once: on disk and in main memory. The user, however, imagines his document as a book on a shelf. Let’s say it is a journal. Occasionally, it comes down off the shelf to have something added to it. There is only one journal, and it either resides on the shelf or it resides in the user’s hands. On the computer, the disk drive is the shelf, and main memory is the place where editing takes place, equivalent to the user’s hands. But in the computer world, the journal doesn’t come off the shelf. Instead a copy is made, and that copy is what resides in computer memory. As the user makes changes, he is actually making changes to the copy in memory, while the original remains untouched on disk. When the user is done and closes the document, the program is faced with a decision: whether to replace the original on disk with the changed copy from memory, or to discard the altered copy. From the programmer’s point of view, equally concerned with all possibilities, this choice could go either way. From the software’s implementation model point of view, the choice is the same either way. However, from the user’s point of view, there is no decision to be made at all. He just made his changes and now he is just putting the document away. If this were happening with a paper journal in the physical world, the user would have pulled it off the shelf, pencilled in some additions, and then replaced it on the shelf. It’s as if the shelf were to speak up, asking him if he really wants to keep those changes!”

Cooper’s solution is to hide the hack: hide the filesystem from the user by automatically (without a prompt) saving the changes, while at the same time automatically versioning the file.

Jef Raskin in The Human Interface has also expressed concerns with the filesystem, his solution is more radical to Cooper’s: to get rid of it entirely! Raskin argues that since file names are of little help when locating a file, and are always a hindrance when saving a file (breaking your flow to decide what to name your file); he suggests replacing filesystems with an effective full-text search.

Over recent years there appears to be a move towards these ideas both with desktop applications and operating systems.

Applications such as iPhoto, Apples Address Book and iTunes in effect isolate the user from the filesystem – there are no explicit saves: the user launches the application, edits the data and closes the application (data is automatically saved – and with iPhoto a new version created so you can ‘undo’ the change if required). Users are never asked to name a file, and they find what they want either by searching or by creating ‘smart’ groups which are simply predefined queries.

The efficiency afforded by this design pattern is most noticeable not while using the application since the design has the effect of making the interface ‘step back’, allowing the user to focus on the task at hand. Rather you become aware of the benefits when you stop using these applications and switch back to using applications employing the traditional filesystem model. The switch is jarring – the breaks in flow and the drop in concentration is noticeable.

So while some application have started to hide the filesystem from the user for most applications we still rely on the filesystem, as provided by the OS, to help us navigate and manage our digital files; but even here there are signs that things are changing.

All the major operating systems still employ the standard hierarchical filesystem, however, there are signs that we might be moving away from this paradigm.

Apple introduced Spotlight to OS X as part of the Leopard release. Spotlight provides fast, as-you-type, system wide desktop searching of both free text and metadata thus allowing you to quickly find not only text based documents but also pictures, movies and music. Indeed since this feature was introduced I for one rarely use The Finder (the OS X filesystem UI) to find files.

Furthermore it is worth speculating how the introduction of Time Machine to the next version of OS X (Leopard) will effect the filesystem UI. Automatic versioning and easy access to previous versions could allow Apple to remove the Save dialogue box from more of the UI, should they wish. Files could safely be automatically saved in the background with old versions retrieved via Time Machine as needed thereby removing the need for explicit saves and hiding more of the filesystem from the user.

With Windows, third party applications such as Google Desktop have provided similar functionality to Spotlight (prior to Vista the built-in Windows search was too slow to be useful in this regard). However, with the arrival of Vista, Windows Search will provide a similar user experience to Spotlight with rapid, thorough search features, accessible directly from the desktop.

The most interesting developments may not however with the major players, but rather be with the ‘One Laptop per Child’ project with the design and development of Sugar UI. The designers have decided to abandon the traditional GUI and design new and radical design patterns, creating new paradigms of user interaction in the process.

Sugar UI breaks with tradition on a number of levels including the filesystem where they have adopted the concept of a journal:

“The concept of the Journal, a written documentation of everyday events, is generally understood, albeit in various forms across cultures. A journal typically chronicles the activities one has done throughout the day. We have chosen to adopt a journal metaphor for the filesystem as our basic approach to file organization. While the underlying implementation of such a filesystem does not differ significantly from some of those in contemporary operating systems, it also holds less importance than the journal abstraction itself.

At its core, our journal concept embodies the idea that the filesystem records a history of the things a child has done, or, more specifically, the activities she’s participated in. Its function as the store of the objects created while performing those activities is secondary, although also important. The Journal naturally lends itself to a chronological organization (although it can be tagged, searched, and sorted by a variety of means). As a record of things she’s done—not just the things she’s saved—the Journal will read much like a portfolio or scrapbook history of the child’s interactions with her machine and also with her peers. The Journal combines entries explicitly created by the children with those which are implicitly created through participation in activities; developers must think carefully about how an activity integrates with the Journal more so than with a traditional filesystem that functions independently of an application. The activities, the objects, and the means of recording all tightly integrate to create a different kind of computer experience.”
http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/Core_Ideas