Design Issues – Working With Files

As veteran users of software, we are accustomed to managing our own files. More than likely, you’ve used Explorer to navigate around your hard drive, and grown accustomed to the file open and save dialogs.

However, this reliance on files is actually not a service to the customer, but to the developer. Ideally, software should protect us from file details, by remembering the last file and loading automatically, saving automatically, and keeping track. After all, why should a customer need to know where a file is; rather a listing of files to load should be enough, except for those occasions where a file needs to be placed on a specific drive (like a floppy), or across a network.

The goal? Eventually, file systems should be hidden from everyday use. We don’t care where a file is on a drive, just so we can find it when necessary. Extensions and filenames and file paths are handy for programmers, but all a customer wants to know is what a file contains. For this reason, file names should eventually be hidden – far better if each load dialog had a description (or an image) of what the file is. By ignoring file names, we also avoid the problem of coming up with memorable file names. After all, the reason you need to choose a unique and descriptive file name is so you can find the file later – display the files in a more descriptive manner, and the file name is immaterial (except to avoid duplicates)

To provide this utopian vision, file systems will probably need a major overhaul at the operating system level. However, with ‘roll your’ systems like Linux and FreeBSD, the possibility is there to integrate these features into the system, perhaps someday making the detailed knowledge of files, extensions and paths a thing of the past.

Comments are closed.