I’m in the middle of writing another blog entry about saving (note to self: add a link later) which made me want to write briefly about something related that bothers me quite regularly. Professionally, that is, not personally 😉
A lot of applications (like Microsoft Office Word, for example, which I’m using right now) have two basic options when it comes to saving files:
File -> Save
File -> Save As…
It’s pretty obvious what Save does — it saves the current state of the current document (whatever the application’s idea of a “document” is) with its current name in its current location. If the document does not yet have a name and location, the user is prompted for this information.
But what was the user’s intention when they hit the Save button? There are a bunch of possibilities:
· They are about to exit the application and want to save the state of the document for the next editing session
· They are concerned about program crashes, hardware problems, or power outages, and want to save their work-in-progress “just in case” something goes wrong
· They are going to copy the document from the current machine and work on it on another machine (eg, taking it home)
· They are going to copy the document from the current machine and give it to another person for collaborative purposes
· They are going to copy the document from the current machine and give it to another person as a finished document
· They are storing a final “authoritative” version of the document for historic / legal reasons
· Possibly some more…
These are semantically different actions, and ideally we might like our software to perform different tasks depending on what our intention was. For example, when I’m saving a work-in-progress as a mitigation against crashes or power loss, I might not want to think about a file name or location. It might be a “throw-away” file I’m never going to keep once I’ve finished with it, or maybe I won’t be sure what it should be called until it’s completed. In these cases, forcing me to think about where to save the file or what it should be called is a waste of my time. Obviously this is what things like AutoSave are designed to accomplish, although not all software supports AutoSave and even when it is available the user may want to explicitly save their current progress before a “risky” operation or after writing something particularly insightful.
As another example, when I’m working on a document with somebody else I probably want my application to store collaboration-related metadata such as revision marks, comments, and tracking IDs, but when I am ready to “publish” my file to the general public, I want all that information removed. Today programs like Microsoft Word are “optimised” for the former case (metadata is stored with the file) and you have to hunt around the Tools -> Options -> Security tab to turn it off. And then it’s a global switch that applies to all future Save operations on all future documents; there’s no one-time-only “Save and clean” operation that I can see in the product.
Save As… presents its own set of problems… again, it’s pretty obvious what it does — save the current state of the document with a new name and location — but here there are at least three possible motivations:
· The user wants to make a new “version” of the current file
· The user wants to create a “checkpoint” of the current file
· The user wants to create an entirely new file, using the existing file as a “template” or base
The difference between the first two is basically whether you want to save the current state of the file and start working on the next “version” (eg, go from AnnualReport_Monday.doc to AnnualReport_Tuesday.doc and keep working on Tuesday’s version) or whether you want to continue working on the main document but save a temporary copy with a different name (eg, working on SalesReport.xls you create a temporary SalesReport_BeforeReformat.xls but keep working on the main file). Applications like the Microsoft Office Suite tend to favour the first approach: Save As… creates a copy with the new name and makes that new copy the current version. If you want the second way of doing it, you have to first Save, then Save As… with the new name, then Open the original version again. Messy, huh?
The third motivation is when you really want to create a brand new file but rather than start from scratch you want to copy some of the formatting or the data from the current document. For example, using the data and formatting in BudgetForecast2002.xls to create BudgetForecast2003.xls — it’s not a new “version” of the 2002 spreadsheet; it really is a new spreadsheet.
Again, there are things that we might want the software to do differently depending on our intention. As mentioned above, getting the “checkpoint” semantics in Office requires some manual steps. In the “I’m really creating a new document” case, we might want to do a “deep” clone of content in the document (including OLE objects, linked images, etc.) so that they can be modified along with the new document and not affect the old document.
Unfortunately, having a cascading File -> Save sub-menu with (at least) nine different options under it would be horribly confusing for most users. They just want to “save” a file, for whatever their definition of “save” is, without wanting to worry about what all the other possible meanings of “save” might be. In actual fact, Save As… is conspicuous by its absence in our very own Visual Studio product — you can’t clone or checkpoint your solutions in VS. I guess they expect you to be a “real” developer and use source control instead…
So, sometimes things don’t work out the way you want them… it’s not easy designing software!