Is the Save Button Obsolete?

Luther Blissett asks: "I've wondered this for awhile now: why do we still have a Save button? Why isn't it always automatic? Why isn't 'Save As' called 'Name and File'? I understand that in ancient history, when Save was a hit on system resources (e.g. when saving to your 5.25 inch floppy disk), we might give control to the user. Also, the average user then was probably more technically adept (out of necessity) and knew the difference between RAM and storage. But now? Why?"

since day one

[yagu]

Since day one, "SAVE" has been obsolete along with a myriad of abstractions offered end users (what the heck is the notion of a "FILE" menu anyway? -- What the heck is the notion of "FILE"? I know I've read every beginner's book about getting familiar with computers, and they always go into excruciatingly dull detail about the file abstraction (it's a collection of bytes the comprise a document, blah, blah, blah.)). Users don't care what a file is, they don't want to know what a file is, they just want to do work.

(I will admit caution when absolving users of any responsibility to learn, but generally speaking, end users have enough on their plate without having to incorporate geek-speak to do their work.)

I was in a design meeting one day discussing the appropriateness of the "FILE" menu for the application we were delivering. One of the anointed Golden Boys of the team had sketched the layout and included the "FILE" menu. I asked why we needed it, there was NO notion of "FILE" in our application, there was no notion of "SAVE FILE", etc. in our application.

He said, "cuz they expect it, it's a standard menu." I said, "standard cuz they expect it, or standard cuz it's always been there?" I finally gave up on the chicken and egg discussion, let it be resolved the end users "expect" "FILE" (NOT!).

That said, I could (and may) go through the menu selections in virtually any application and find half of the "options" are abstractions that have bubbled up either historically, or were just never "translated" for end userdom. It's a mess, and it's a presentation piece of software I am constantly explaining, and apologizing for.

It's toothpaste out of the tube, I wish it could go back in. But, it's a great lesson in humility when you actually take a lay-step back and actually try to interpret what we see as normal-speak on a daily basis. It isn't normal, and it isn't transparent.

Short answer to the poster's question: yes

Most of the crap we throw the users' way is artifact crap that never went away. (Does anyone know or remember the story about cutting away 1/3 or the Thanksgiving Ham when preparing it for Thanksgiving Dinner?)

The save button is about as obsolete as Undo

[chewedtoothpick]

Mainly it is not obsolete because you don't want to make a major mistake, save it and be unable to undo that mistake.

I need a save button...

[WTBF]

Quite a lot of time I make a first draft of a document, save it and print it out. Then I go and edit it and then save this as another copy, the finial version. If it automatically saved then it would end up with the draft not being a draft but half way between draft and finial (I only save every five minutes or so).

Because some user like it that way

[cuyler]

I open up files all the time tofiddle with some numbers without affecting the actual file. My bosses come up to me with little questions all the time - I just open the file with the data, do some minor manipulations, give them their answer and then close it. I care to retain that information.

Then again, I could have wildly misunderstood the question - wouldn't be the first time.

save still a hit on system resources

[DaveJay]

Original poster suggests that saving files isn't a hit on system resources, but of course it is under many circumstances. For my day-to-day activities, here are file types that, when saved, slow my machine down and/or make me wait:

Photoshop files -- they get quite large, after all;
Flash source files -- they get quite large, after all;
Premiere and other video/DVD editing software -- the biggest files of all;
Reason/Sonar (music) files -- they get large, and they also negatively impact system performance when you're playing back complex compositions in real time.

It's even worse if I'm saving to a network share.

So, that may be the case for large files, but what about text files?

Well, I'm a web developer by trade, and when I'm troubleshooting broken code, I often use this convenient and pain-free system to narrow down the bug location:

Step one: cut a chunk of code out of my source document;
Step two: save the file (without the chunk of code);
Step three: paste the chunk of code back into the source document;
Step four: refresh the browser to see if the bug is still present;
Step five: save the file (with the chunk of code restored).

Automatic saves would interfere with what I find to be a very convenient workflow.

Ever used MS Office?

[toleraen]

Every day I work with word docs that are 30+ megs in size. All of our saving is done on network shares across a WAN link. Depending on network traffic, a normal save can stall the system for a quite a bit. Something tells me that if a few hundred engineers were constantly sending save data across that link, things wouldn't be looking so good. So, it is still very much a hit to system resources.

Also, as far as the auto save feature goes, I don't want it to. Ever opened a MS Office file (doc, ppt, xls, etc), go to close it without touching a single thing, and it asks you to save? Not to mention that when you work with baselined documents, if they ever change it has to be sent off for approval, resubmitted to higher ups, etc. If the modified date shows anything other than the baselined date, ruh roh. No thanks on the auto save.

Re:Marginal Cases

[ednopantz]

Aside from the user model issues...

The version tree just isn't very useful if it includes 900 slightly different versions of the same document. Which one do I want? Let's see, it was about 10:00 when I started doing dumb stuff so I guess I want version 845 then, it was from about that time...

I could label my versions explicitly, but then how would this be better than a save button?

Are you always perfect?

[pclminion]

I know I'm not. Suppose I delete a paragraph with the intent to rewrite it, muck around for a while and then decide I preferred it the way it was? If everything is saved automatically, that original paragraph is lost.

Sure, I could Undo back to the previous state, but I've seen so many programs with broken or unreliable Undo that I simply could never trust that. Or what if the editor crashed before I could Undo?

The only way you can do away with user-directed saving is with some sort of automatic versioning system. But then, how often do you version? Whenever a single byte of information changes? Less often? How do you determine it?

What a pain in the ass. I'll keep my Save function, thanks.

Re:since day one

[Eric Giguere]

Not to accuse programmers of being lazy, but it's easier to implement "save" functionality than it is to implement "complete undo/redo" functionality. You need the latter if you don't have the former.

Note that saving a change history along with the document itself can be problematic for various reasons, from the simple fact that you're bloating the file to the fact that you may expose information inadvertently if anyone care to look at the change history. As many Microsoft Word users have discovered to their chagrin.

Eric
My Squidoo page [squidoo.com]

Re:The save button is about as obsolete as Undo

[kisielk]

As someone who worked in IT support in the past, I can tell you that there are many times where people "Save" their document in a state they don't want it in, only to be unable to recover the old one. Furthermore, there's those people who don't want to screw up their existing version so they *don't* save, only to have 3 hours of work go down the drain when their application crashes or something else... I think developers need to look in to better ways of supporting working on large documents (I like the transactional saves recommended by some posters)

Continuous save vs. templates and temporary change

[Kelson]

Consider one-off templating.

You want to make a new document based on your old one (maybe it'll use a similar structure or something). You open it up, make some changes, then save it as a new file, leaving the old one unchanged.

With continuous save (by which I don't mean the auto-save that current apps like MS Office do, where it saves to a temp file), you have to hit "Save as..." or the new-paradigm equivalent immediately, or else your old document is going to end up looking just like the new one. This is only really a problem during the transition phase, while people get used to the new procedure, and it's arguable that it's better in the long run, since as things stand right now you can easily forget that you haven't already branched a new file and save over the old one.

Then there's the issue where you load something and want to make a temporary change, say, for printing or in prep for a screencap or copying and pasting into another app. Or you start typing in the wrong window. If the document is saved continuously, not only do you have to undo the changes before you close the application, but you end up changing the file modification date. Maybe it's not critical for the data, but if you're sorting by when you changed something...

You're using a computer

[jgoemat]

What would you say instead? If I want to load a [document | picture | mp3 song | spreadsheet | database | movie] what would you call it? Where would you put it? Having 'files' and 'directories' (folders) is nearly a necessity for having an operating computer. You could theoritically design an operating system that stored and classified all files based on their type and kept them segregated like that, but you still would have just the notion of file type replacing directory. Then you have all the textures for Doom located in with your family pictures because they're the same type. Have fun browsing through tens of thousands of pictures (including system icons and cached pics from the web) to find your 20 pictures from your camera you wanted to store on your computer. Unless you can come up with a better way, 'file' is here to stay.

If you do away with the concept of 'files', the operating system then has to handle every possible type of document. You wouldn't have had the MP3 revolution because there would be no such thing as an 'MP3' since the OS didn't support it. You also wouldn't be able to organize data in directories, like having all of a game's data in one directory. Grand Theft Auto would have it's application wherever applications are, sounds wherever sounds are kept, textures wherever pictures are kept, movies wherever they are kept, settings files wherever they are kept, and their proprietary data files wherever they are kept, if the OS even allows it because it knows the type of file and where it should go. Then you could be scanning your pictures one day and see a texture not knowing what it is and delete it, then you can't play the game anymore.

And how exactly is 'save' obsolete? How often are you going to write the file to the disk? Every 10 minutes? Every 1 minute? Every keystroke? I would argue that having a 'save' button or menu item is the best way to handle this. If they close down the application with a modified document, the application can warn them as most applications do. Good luck saving a big spreadsheet every keystroke with OO when a save can take minutes. I don't think you'd get much work done. What if you want to just play around? Do you want to have to create a copy of the 'document' before opening it if you want to make changes you may not want to keep? It's also inefficient to save every keystroke when you may be making a lot of changes before saving.

The notion of a 'FILE' menu is there because applications work with FILES. If you have an application that doesn't work with FILES then don't use a file menu.

Atomicity

[Evro]

There's a save button for the same reason we wrap SQL statements in BEGIN TRANSACTION ... COMMIT TRANSACTION. Sometimes you want changes to be all-or-none, and not in some unknown state where some of your intended edits are in place but not others. Maybe the answer to that argument is to save the entire edit history in some kind of infinite undo buffer, but personally I like Ctrl-S. There's autosave, but I still like to save things manually to reflect the states in which I'd actually want the document to exist.

No, it's not.

[Just Some Guy]

Congratulations: you just invented Coyotos [coyotos.org] (was: Eros). Anyway, your idea doesn't account for:

• Limited-write-cycle devices, like thumbdrives. If "save after each byte" trashed the FAT table sectors of my shiny new 1GB USB drive, I'd have to beat someone.
• As someone else mentioned, network access. Few of the projects I work on are local to my own drive. I access most of them via SFTP or WebDAV, plus some NFS and Samba thrown in for good measure. I don't want my working file, regardless of how small, written out continually.

I don't think that "saving" is quite the high-level abstraction you're making it out to be, and it's shorter than saying "write contents to permanent storage". I don't see the concept of files going away any time soon, and as long as we have them, users will need to write to them.

In your defense, I don't think that using unsaved files as a convenient "undo buffer", as mentioned here by others, adds functionality that a good bookmarking system couldn't achieve (albeit with much greater overhead and fragility).

Re:since day one

[Jordy]

Macs have an "Application" menu named after the application. In Firefox it is called "Firefox." That is where application-wide functions are (about/preferences/quit). The "File" menu still exists. That is where major operations relating to files exist (new/save/print/close).

The reason things like "Print" aren't under the application menu is because you can have multiple files open at once. It relates to the current file only. The same goes for "Save." I don't want to save every file I have open.

The apple icon menu is for OS-specific items (about mac/system preferences/shutdown/logout).

version tree == undo tree

[Julian Morrison]

Here's a thought: the versions of a file match the undo states. So, as you edit the file, the program journals it to disk. Crash and resume, and you get your undo history back. Save, and your undo history is collapsed and the file stored in its native (un-journalled) form. So "save" transforms from a storage operation, to a render operation.

This has the advantage that a quit or crash and restart from a temporary change will allow you to back out the change. It also works for large datasets, because you aren't continually saving the whole thing, only journalling the changes.

Constant saving would kill versioning

[alta]

When I work on a new version of a file, I open the most recent, then save as a new name (if I want to save the old)

Also, sometimes I want to make a test change, but not keep it.
Sometimes I want to revert back to the original, but some programs have very limited undo (excel, older photoshops)

Sometimes when I'm just writing something very temporary, like a fax cover page, I NEVER want to save it.

Is posting this to /. just so they can get their name in lights? ;)

Re:I need a save button...

[ednopantz]

And this is better than the save button with backround autosave how?

Users grok save at a basic level. Throw what, 2000 branches at them and they are likely to flip. How would automagic know that changing my font was a BS change and not worth branching and changing my character's name was a big deal?

Isn't this a solution in search of a problem?

Re:since day one

[tehcrazybob]

One of the many reasons I save documents as PDF before I send them on an adventure. I like having my undo history and the like, but I don't really want other people to have it as well. When I save as a PDF, nobody can change my document, most everyone can open it, and I know they are only getting what I want to give them. However, saving as a PDF is a separate step, and one most users won't take.

I don't want my save button taken away, because that's something I'd like to have control over. It's easier for me to save when I want than to write a program to read the user's mind and save appropriately. I'd also like to keep my undo history past a save. So, let's think of it this way. Saving saves a file as well as its undo history. This gives the user complete control. However, if the user tries to exit without saving, the program will sneak a save in without the user knowing, and offer to bring that file up the next time the program is run. Finally, saving as PDF should be offered by more programs. It's a very nice tool to have.