For a long time Alan Cooper (in the 3 versions of his book "About Face") has been promoting a "unified file model" to, among other things, dispense with what he calls the most idiotic message box ever invented - the one the pops up when hit the close button on an app or form saying "Do you want to discard your changes?" I like the idea and his arguments, but also have the knee-jerk reaction against it that most seasoned programmers and users have.

While Cooper's book seems quite popular and respected, there is remarkably little discussion of this particular issue on the Web that I can find. Petter Hesselberg, the author of "Programming Industrial Strength Windows" mentions it but that seems about it.

I have an opportunity to implement this in the (desktop) project I am working on, but face resistance by customers and co-workers, who are of course familiar with the MS Word and Excel way of doing things. I'm in a position to override their objections, but am not sure if I should.

My questions are:

Are there any good discussions of this that I have failed to find? Is anyone doing this in their apps? Is it a good idea that it is unfortunately not practical to implement until, say, Microsoft does it?

  • 2
    Google Docs uses the "unified file model". There's still a save button, but in reality it's a placebo: every time you make a change, the file is "saved". Of course, Google Docs also has a very robust "history" model where you can revert to any previous revision you like. Dec 28, 2010 at 19:15
  • Thanks all for the responses. Particularly ElGringoGrande and Berin Loritsch. I picked Berin's only because it seemed a bit more complete. I'm still pondering the direction to take. Dec 29, 2010 at 15:06

5 Answers 5


The apropriateness of the Unified File System really depends on the application at hand. Things like web applications, Microsoft OneNote, and iOS applications lend themselves to that model. When an application is database driven, it also lends itself to that model. However, I can also think of areas where it is not the best option. In particular, when an application can consume data that didn't come from that application, you need the concept of a file system to locate the information.

As far as keeping the memory and disk in sync, I want it but I don't for my word processor. If I've taken the time to save my file, I might want to make sure I'm not losing any information. That need has been taken care of by the auto-save feature we've had for several years now. If someone trips over the power cord I can at least get some of it back. However, I create a number of throw away documents I don't want littering my file system. A sign that will only be used for one day, playing around with font samples, etc.

The answer is "it depends". Cooper's UFS is useful in some cases, and less so in others. The technical savvy of your users also might play into your decision on it. Most of us have grown up with the status quo, and sometimes the benefits of change don't outweigh the cost of change. I'd evaluate the appropriateness of that approach in your app.


Microsoft does do it in OneNote.

I wouldn't override the user desires. We thought about implementing this but come to find out many users do things without thinking and use the close form button (or ctrl-alt-del if there isn't one) to prevent their mistakes from getting saved.

If you could implement it in a way that allows them to go back to a previous session (a big undo of sorts) then it might be acceptable. But people are designed to take advantage of the environment around them. Change the environment and you risk destroying the advantage they have discovered.

  • 1
    And supplying undos that crossed session lines would cause its own problems. How many people start letters saying what they think and then finish by making it diplomatic? You'd need a separate export function. Dec 28, 2010 at 19:03
  • +1, especially for the last paragraph. Don't overwrite previous content when saving, but add a new "version", keeping older versions intact. To save space, you can have multiple versions share (immutable) data.
    – Joey Adams
    Dec 28, 2010 at 19:09
  • 1
    @David: that's a good example of really wanting a "publish" command rather than a "save a new version in this version stream" command. Dec 28, 2010 at 20:24
  • 1
    @Alex: Precisely - except that most people won't go looking for a "publish" or "export" command. There's no immediately visible difference, after all, and they're used to just sending the final version of the file. Dec 28, 2010 at 20:34
  • I agree you have to have a "revert to previous version" option if one is going to use the unified model-- it's fundamental to it. In fact, in my case, all of the data (these are app specific items, not really files, but it's all the same) is in a DBMS that does not allow destructive updates, so I have every version ever saved. This is one of the reasons I'm even considering the unified model, as it's a freebee to recall old versions of an item. Dec 28, 2010 at 20:43

The unified file system has already won!

All iOS* applications work this way. There are no 'files', there is no file system, there is no saving, only applications that contain data that you can always return to unless you delete it. Given that MacOS may fall to iOS some day, I'd say that the model has definitely caught on.

Websites work this way too--rarely do you 'save' a document, rarely do you navigate a set of documents, and very rarely do you share documents between websites. The documents are embedded within the site, the way these questions and answers are embedded within StackExchange.

Historically, there were a few awkward attempts to hodge-podge this into Windows and Macs, and it turned people off to the idea. But the change to a new platform where no one expects there to be a file browser has freed companies to transition fully.

(* I don't know from Android or other phone OSes; maybe there, too.)

  • 2
    Filesystems however exist (in a good part) to separate data and interfaces from programs and applications. There are arguments on both sides.
    – Jé Queue
    Dec 28, 2010 at 19:00
  • 2
    @Alex, except that you cannot share information between applications. A save game file can't be opened by a text editor on the iOS, because that other app doesn't have access to the sandbox. Dec 28, 2010 at 19:02
  • @Stephen, that's true, and an essential aspect of eliminating a file-based mental model. If you want to move data between applications, you must resort to either direct sharing between apps ("share this on Facebook!"), or an intermediary both can speak (like the clipboard). I'm confused by your "except". Dec 28, 2010 at 20:23
  • You can share information between applications - iOS supports file handlers, and also passing information via URL handlers. It's just done at a level where users are connecting data between applications, not being the middleman in the transfer process. Dec 29, 2010 at 1:24
  • 1
    @Alex, wait, so using the clipboard (temporary) intermediary is acceptable but using a common file system (permanent) is not? Jan 3, 2011 at 18:20

Are you going to keep their data in files or in some kind of database?

If you expect them to have physical access to the files then you will have to teach them that your files are 'special'. In their current mental model they can copy, paste, rename and delete. I'm sure some of them already use rename as a way to 'version' their data (e.g. resume2010.doc, SalesDataFromBob2.xls).

If it is a database, I'm sure they will want to export/import files at some point.


Is having a prominently displayed "save always" option for the user that hard to implement?

  • 1
    No, it's not hard to implement at all. But is it really a good idea to create an option and support two models here? I don't think so. I think I am better of picking one and sticking with it. Dec 28, 2010 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.