Bad User Interface of the Week: File It Under “Bad”

he UNIX philosophy says "everything is a file," which sounds sensible on the surface. It is somewhat useful to have a unified interface, but what exactly is a file?

In the UNIX world, a file is an untyped, unstructured stream of bytes. This is a fairly useful from a programmer’s perspective; it’s a lowest-common-denominator that can be used to implement more useful abstractions, but what does it mean from a user perspective?

I tried an experiment. Over the last few months, I have asked a small number of people to tell me what a file is. Some have been computer scientists, some in business, and some fairly naive computer users. Not a single one could tell me what a file was.

As with many user interface concepts, a file is based on a physical metaphor: a thin folder for storing documents. Interestingly, if I asked people to tell me what a document was, I got sensible answers. Terminology can be very important when describing parts of the user interface.

Once a user understands what a file is, there are still some hurdles to overcome. One of the biggest is the concept of "saving." In general, saving means "write the current document state to disk." Somewhat counter-intuitively, saving is typically a destructive operation; when you save, you are usually overwriting the previous version.

How should saving work? Most programs maintain an undo history, but very few save this with the document. Those that do often present a security problem; if you then share the file with someone else, then that person can see the revision history of the document. It turns out that "saving" is actually used for two purposes:

• Checkpointing
• Publishing

These are conceptually quite different. Checkpointing is a way of telling the computer that you might want to go back to that particular state. Some filesystems, such as that of VMS, incorporate this automatically. Every time you "save" a file, you are performing a non-destructive operation, creating a new version of it on disk. ZFS can do this very well, allowing each version of a file to be checkpointed and only using disk storage for the changes. LFS also permits this kind of interaction. Most conventional UNIX and Windows filesystems, however, do not.

Publishing is quite different. Publishing is the act of sending a document to a remote person. This is often the virtual equivalent of selecting Print, and some systems integrate the UIs. On recent versions of OS X, for example, the Print dialog has a button for sending the PDF through an Automator workflow, which can be used for emailing the PDF version to the recipient.

Combining two very separate user operations into the same user interface because the implementations are similar is a very common mistake. This is something that files themselves often exhibit. When I write a long document, I have a text file containing the typesetting commands, and text and a PDF file containing the typeset output. The same is true when writing software; I have source files and an executable file.

This almost certainly sounds normal to most readers, because this is the way most systems work. But why is it this way? A source code listing and an executable are, in an abstract sense, simply different views on the same data. One can easily be produced from the other (and in some cases this process is even reversible). Many languages do not make this distinction at all; the compiler generates the executable code when the program runs, and if it caches the result, it does so in a manner not visible to the user.

One of the first systems to work this way was SmallTalk, which dispensed with files altogether. The environment contained a class browser, and this allowed classes and methods to be edited without any thought as to how they were stored on disk, nor of whether they needed to be recompiled.

When designing a user interface, always try to remember how your users will be interacting with it. What is actually important from their perspective? No one ever needs to edit files; they need to edit data. Files are one abstraction of data, but they may not be the best one for the task at hand. Music jukebox and photo album software have shown how much better a specialized viewer can be for certain tasks. A user of something like iTunes is aware of tracks, with track and album names, artists, and other metadata, not of a hierarchy of files in folders on a disk. Picking the correct abstractions for user interfaces is as important as picking them for systems.