The evil File/Save

Recently I discussed with my friend about desktop application design. In my opinion, most of the File/Save are bad design for a GUI-based system.

1. A good application should try to hide the technical detail such as the file system in the operating system. File concept should be avoided whenever possible. The famous example is the Quicken financial software. When you open Quicken, you see your balance book. There is no need to open Quicken, and then open again for a file. 

2. If the application designer intends to use the File Folder metaphor in real life, he should avoid  File/Save because there is no such metaphor in real life as Save a file. When you file something, it is there. 

3. A document-based design should treat document as a physical document: They exists and persists as soon as they are created.  A user should not lost the whole document because he forgot to save it.  Someone may argue that a user might regret his changes and want to revert back to original file. There are plenty of technique to overcome this issue: Use of command pattern, journaling, or simply store multiple copies. They are all better than save-it-or-lose-it solution.

4. User does not care if something is in the memory or in the storage. Developers does. To explain File/Save activity often involved in explanation of memory and storage, RAM and HDD.  These is too much information for the users.

As a matter of fact, even for developer tools, there is rarely need for File/Save. Eclipse IDE (or Visual Age) is a good example.  In object-oriented language, you always work with class, not files. When coding is done, you compile it into class, not just save it. 

So next time when we design an application menu, think first if we really need that File/Save menu. Will that cause user to lose their work? Will we involved in the embarrassing moment to explain what is RAM and what is HDD to the user?