Forgot your password?
typodupeerror
Data Storage Software

Is the Save Button Obsolete? 188

Posted by Cliff
from the do-you-do-regular-system-backups-too dept.
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?"
This discussion has been archived. No new comments can be posted.

Is the Save Button Obsolete?

Comments Filter:
  • Marginal Cases (Score:3, Interesting)

    by (1+-sqrt(5))*(2**-1) (868173) <1.61803phi@gmail.com> on Thursday December 08, 2005 @02:46PM (#14212373) Homepage
    [W]hy do we still have a Save button?
    Two marginal cases come to mind:
    1. Transitory unsalvageable states (e.g., you just selected all and cut)
    2. Prohibitively large data sets (e.g., bioinformatics, movies)
    For modest domains, however, a form of automatic versioning control ("save tree") would solve the first case.
    • For modest domains, however, a form of automatic versioning control ("save tree") would solve the first case.

      Shades of VAX/VMS with foo.txt;1 foo.txt;2 foo.txt;3 ... foo.txt;954

      Make it stop!

      :-)

      • I was just thinking this myself. The versioned file system is the ONLY thing I like about the VAX I'm forced to get along with. But the versioning? pretty cool!
        • You realize that we've dated ourselves with our understanding of now-obscure operating systems, don't you?

          I remember when it took three of us to lift a 10 Mb hard disk drive. (But, man! the geek factor of a CDC hawk in one's bedroom in one's parent's house was enormous).

    • Re:Marginal Cases (Score:3, Insightful)

      by ednopantz (467288)
      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?
      • Let's see, it was about 10:00 when I started doing dumb stuff

        Since other comments in this thread have made me reminicent of my own VMS days, I'll use that command set. In that OS, you can always issue:

        $ DIR /DATE

        Pick one from before 10:00. Run with it. Lord knows the versioning on VMS has saved my ass more than a few times...

    • by Julian Morrison (5575) on Thursday December 08, 2005 @05:08PM (#14213773)
      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.
  • since day one (Score:5, Insightful)

    by yagu (721525) * <yayagu@gmai l . com> on Thursday December 08, 2005 @02:47PM (#14212383) Journal

    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?)

    • Re:since day one (Score:5, Insightful)

      by Eric Giguere (42863) on Thursday December 08, 2005 @03:15PM (#14212685) Homepage Journal
      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]
      • On that note do why many applications include change histories in the main file. Autosaves to a symolic file location as well as histories in another file (you should be able to pre as to how far back you want to go in time) would be perfect. Then you can send the file to anyone and no have to worry about such issues. Obviously in a collaprative environment you might want to share histories but thats not so hard.
        • It's just easier to keep the document and the history together if they're in the same file. Otherwise the linkage is easily lost if (say) you rename the main document file and forget to rename the history file.

          Eric
          The Invisible Fence Guide [ericgiguere.com] (features my dogs!)
          • In a system without a save functions files would be deeply hidden and retrieved by the application based on search criteria. For many people a recent documents list is enough for their daily work. Even if you wanted file access you could store the main file in the documents folder and the changes history in a hidden folder. Tarring them as other poster said is silly as it would make sending to others more difficult unless there was a special interface for it.
      • Not everything is a document, so not everything needs to be "saved" to a filesystem; a lot of applications have a File menu only because users have been conditioned to look there for "exit"
      • Re:since day one (Score:2, Insightful)

        by tehcrazybob (850194)
        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 f
    • The "File" menu has traditionally been the place for "standard" system stuff that has nothing to do with "files". E.g. "Exit". What does "exiting" have to do with files? And what "menu" would you put the "exit" menu item (if you even had one), the "Exit Menu" menu? (yes you could dispense with the notion entirely, but closing a single window is often NOT equivalent to "exiting")
      • Re:since day one (Score:3, Informative)

        by Vaevictis666 (680137)
        I think Macs get away with just using the (apple icon) menu. Anyone else could really substitude the File menu with an Application menu that had slightly wordier items in it. File->Save would be Application->Save Document, File->Exit would be Application->Exit, etc.

        As an added benefit of making that change, one could move the "standard" Tools->Options into Application->Options (or Preferences) and stick it next to the typical Print, Printer Setup, Page Setup menu items.

        • Re:since day one (Score:5, Insightful)

          by Jordy (440) * <jordan@NOSpAM.snocap.com> on Thursday December 08, 2005 @04:08PM (#14213270) Homepage
          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).
    • by jgoemat (565882) on Thursday December 08, 2005 @03:40PM (#14212992)
      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.

      • The concept of "document" would still be valid.
        You would have a "spreadsheet", a "letter", etc.
        The "all files should be known to the OS" thing is BS, that's what plugins, kparts/automation-servers are for. MP3 never meant jacksh*t to linux; but inside KDE, you click on one of those, and voila, noatun is loaded with 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 [...]

        ...unless you add a label like "Grand Theft Auto" to all of the objects comprising it, then search for "Grand Theft Auto" to see all of them. Of course, I just re-invented directories, so that seems kind of pointless. Possible, still, nonetheless.

        How often are you going to write the file to the disk? Every 10 minutes?

      • If you do away with the concept of 'files', the operating system then has to handle every possible type of document.
        The concept of 'files' is just an abstraction of the reality of your hard-disk which is a couple chains of linked lists of sectors, we can access it at an extremely low levels that disregards any data on it such as dd -if/dev/hda -of/dev/hdb or we can pile tons of metadata in it so we can see things like thumbnails in our filemanagers. Take a look at libFerris [sourceforge.net], they working on some very intere
    • by schon (31600) on Thursday December 08, 2005 @05:37PM (#14214023)
      what the heck is the notion of a "FILE" menu anyway? -- What the heck is the notion of "FILE"? [...] excruciatingly dull detail about the file abstraction [...] 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. [...] end users have enough on their plate without having to incorporate geek-speak to do their work.

      What the heck is the notion of a "Steering wheel" anyway? what the heck is the notion of "STEERING"? I've read the owner's manual for my car, but it's just excruciatingly dull detail about why I need to learn how to use the "pedals" and "brakes", blah, blah, blah. Drivers don't care what a steering wheel is, or how the brakes work, they have enough on their plate without having to incorporate gearhead-speak to get where they want to go.

      Why do people have to learn how to use a tool? Why can't the tool just be designed so that it can guess exactly what the user wants, and just do it? It all seems so needlessly complicated.
      • Re:since day one (Score:4, Interesting)

        by tengwar (600847) <slashdot@veti[ ]i.org ['nar' in gap]> on Thursday December 08, 2005 @08:11PM (#14215168)
        Humm. Bad example! I take it you've never got used to riding a motorcycle. A steering wheels is a bodge to give you enough leverage to turn the front wheels on a vehicle that doesn't want to turn, or enough purchase to hold it in a straight line when it's trying to follow an imperfection in the road. On a bike, you move the bars a little (or shift your weight) and the power steering comes from the road.

        On a car, you need a clunky H-gate gear lever a foot long, with a complicated and expensive synchomesh mechanism, or an even more complex and expensive automatic gearbox - all to work around the bad gear shift induced by spinning the input shaft at engine speed. On a bike, there's a slow-spinning gearbox that consequently needs no synchromesh and can be fed by a wet multiplate clutch light enough to be lifted with the fingers of the left hand. Only in the past few years have car manufactures finally invented expensive mechanisms to reproduce the "sequential shift" that bikes have had since the 20's

        So yes, a steering wheel on a bike is exactly what the original author raised as the issue with the Save command - it's an ugly and inefficient way of doing things, dictated by the design constraints of the a bad design back in the last century.

    • 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 d
    • if you automatically save for the customer, you run the risk of becomming responsible for the data in their eyes. Meaning very p.o.'d customer's when the system crashes and they lose everything. I've seen this happen with email programs and office messeging software where people call tech support asking for the 'backup' of their data. I guess there are ways around this, but most of them involve having a 'file' menu with prominent export or backup buttons so the user understands that it's their responsibilit
  • There is nothing in the technology that requires a save button for typical programs and uses. KJots is my preferred "scribble a note" repository for that reason: I can't forget to save the note. However, with larger files the delay of doing a "full save" may be an issue. It only takes a second to save most reasonable sized files, but if poorly implemented that second could make the software appear unresponsive. Still, it doesn't require rocket science to save during pauses (if the user stops for more than f
  • Mainly it is not obsolete because you don't want to make a major mistake, save it and be unable to undo that mistake.
    • Ideally, files would automatically be saved and versioned continuously. Like the save button, fact that a "file" currently means "a snapshot of a file at one instant" is obsolete.
    • I see lots of people(.. two, but I dont know many people) use "not saving" instead of undo. Always makes me want to hit them. But then sometimes I'm on somebody else's system and all that's available is some version of vi with one level of undo and terminal settings which convert "@" to a destructive backspace (seriously, wtf?)

      Sometimes closing and re-opening is the best shot until you can figure out where you are.
    • 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 tra
      • Actually, I think this brings up a good point. I do a lot of image editing, and I'm often saving different revisions of the file, if something doesn't work out quite the way I wanted, I can go back to an earlier revision and start there. If a client doesn't care for the end image I've created, it's easy to go back to an earlier revision and make some changes than to have to start over from scratch, or try to add the changes later.
        What I end up with are directories for an image where I have "filename-1","
    • Mainly it is not obsolete because you don't want to make a major mistake, save it and be unable to undo that mistake.

      When talking with my users, I have even referred to closing a document without saving it as a "high level undo". If you completely trash something, just don't save it and start over from the good saved copy. Autosave might deprive you of a good saved copy.
      • I have even referred to closing a document without saving it as a "high level undo".

        Heh. I did this yesterday, when I realised I was editing the wrong template and had deleted swathes of information that needed to be in the template I was actually in rather than the one I had thought I was in. quit without saving, no harm, no foul.

  • by WTBF (893340) on Thursday December 08, 2005 @02:49PM (#14212408)
    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).
    • by hey! (33014) on Thursday December 08, 2005 @03:42PM (#14213015) Homepage Journal
      The answer to that concern is that change logging versioning and branching have to become an integral system service. In such a case there'd be a subtle differnce between naming a version and saving, but it'd be there.

      1. You create your document "Great Novel".
      2. You edit your novel.
      3. You shut off your computer.
      4. You turn on your computer.
      5. You open up "Great Novel" and it takes you where you left off.
      6. After editing for three hours, you decide that you really don't want to kill of your hero, so you ask for the document to be rolled back by 50 minutes.
      7. You start editing from that point, which automagically creates a document branch.
      8. After twenty minutes, you like what you have, and decide to label the version on this branch "best version".
      9. You later decide to go back to your abandoned branch, and label it "hero dies".
      10. Over the course of months, your version tree becomes extremely bushy. However at any time you can ask for the most recent "best version" or see a history of all versions in which "hero dies".

      If I had to say there was a suite of capabilties missing from most applications, it is a comprehensive but easy to use set of logging, versioning and branching capabilities.
      • 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?
      • I've been in a situation that I only needed to revert a certain part of the document. I would hate to reverse all the changes only to redo most of them.
      • LaTeX plus CVS; there are frontends to make cvs easier
        OpenOffice's new fileformat opendoc is xml based so integrating with cvs should be fairly easy (hint, hint any openoffice folks)
      • Just to build on your excellent post which bridges the user-land concepts to developer land concepts (branching) - most Mac software doesn't have such a concept of a file. iTunes, iPhoto - they don't force you think about files, and iPhoto has very basic versioning (revert to original) built right in.

        THen I go back to work, use windows and cuss.

    • You could do that without a save button just as well.
      Instead of saving to a new location AFTER you made your changes, you could also enter a new filename BEFORE you make your changes if your 'Save As' were called 'Name and File'.

      It is just a matter of what we are used to, I guess.

      And a good undo/versioning function is about the only thing that would allow you to catch mistakes that can happen in either system (e.g. hitting "save" instead of "save as" with the current scheme or forgetting to rename the file
  • by cuyler (444961) <slashdot@theERDO ... m minus math_god> on Thursday December 08, 2005 @02:51PM (#14212433)
    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.
    • I'll second this one. I'm forever opening things up and making tweaky changes. Nope, don't like that. Hmm. How about this? Nope, don't like that. This? Hmm... maybe ... but nah.

      Often as not, I decide to stick with the original (at least for now). This is so much easier when the software doesn't "helpfully" autosave and force me to wade through levels of undo: Lessee ... how many things did I change now? --oh dadblast it, the app only allows X levels of undo, and here I must have made x+1 change
  • by DaveJay (133437) on Thursday December 08, 2005 @02:55PM (#14212481)
    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.
  • by nekoniku (183821) <justicek AT comcast DOT net> on Thursday December 08, 2005 @02:55PM (#14212488) Homepage
    Since the US is a Christian nation, having a "Save" button helps keep Jesus constantly on our minds. Now if we could only get the "Delete" button changed to "Damn to the Flames of Hell for All Eternity".

    And don't even get me started on the obviously Freudian "Cut" and "Paste".
    • by SoCalChris (573049) on Thursday December 08, 2005 @03:30PM (#14212829) Journal
      Jesus & Satan were constantly getting into arguments about who is better on the computer. Finally, God gets tired of the bickering, and offers to have a contest to see who can use the computer better.

      The day of the contest comes, and both Jesus and Satan begin working as quickly as they can. Hours pass, with both of them creating many spreadsheets, documents and databases. About 5 minutes before the contest ends, all of the power goes off, then comes back on after a few seconds.

      Satan starts cursing at the computer, and how he just lost everything he had been working on. Jesus calmly just restarts the computer, and finishes what he was working on. Satan sees this, and starts complaining to God about how Jesus must be cheating.

      God replies to Satan, "Jesus saves".
    • I see a lot of truth in this, the guy in the next cube frequently and fervently calls on His Name in situations sometimes related to file saving. And says a lot of the stuff you said about the Delete button too.
  • by toleraen (831634) on Thursday December 08, 2005 @02:58PM (#14212514)
    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.
  • All information is automatically stored as soon as you are done entering it. Still, we have a save button. Because otherwise people would ask where the save button is.

    I dont really like this feature, I'd prefer the save button do /something/. But I'm also the kind of person who compulsively clicks "save" (or :w) every now and then, so maybe I'm the target.
    Actually, our save button does do one thing: it disabled itself after being clicked until something else changes. I argue against that because I feel I sh
    • Well, making the save button disabled also shows the user that their file has been saved (and while it's disabled, it hasn't been modified), giving a visual component to an otherwise invisible process.
      • I've alway's preferred gvim or visual studio's method of putting an * or + in the title bar when a file you're viewing has been modified since being opened. The reasoning is: this isnt so simple as a "this file is different from what is on disk", it is the more nuanced "I havent seen you make any changes since last time I did something involving the filesystem". Not having seen changes does not mean there is no difference, and so should not take away functionality. Within the last hour I have opened a log,
  • As opposed to what? (Score:3, Interesting)

    by Eil (82413) on Thursday December 08, 2005 @03:09PM (#14212625) Homepage Journal
    How is it obsolete?

    There still is a difference between RAM and storage and there's no indication that that will change any time soon. A Save button gives us the control that we still need. In a word processor, for example, a quick typer could generate as many as 15 or more individual changes to the document per second. Yes, you could save at predefined intervals, but that number would need to be tweaked depending on the software and hardware situation. There's no one save interval that would fit all needs.

    There is another possible reason for the save button to exist... occasionally there are situations where I want to open a document and even possibly modify it but not save it. Rare, I know, but automatic saving would be a drawback in this case.

    In the end, removing the Save button from applications would only introduce more problems than it would cure. In an ideal world, I can see where it would work (Apple would be the first to do it), but with today's hardware, software, and users as error-prone as they are, it's much better to just leave it there.
    • Apple has done it. Aperture has no save button. But Aperture is a photography management and processing application that restricts itself to only making changes to images that can be done with CoreImage -- ie recreated on the fly. So the original file is never changed, only a list of instructions for how to turn that original image into the one you want. If you want to do something that can't be done in realtime like that, you have to use something like Photoshop... which has, and needs, a save button b
  • 1. Lots of people work with larger data sets than you do.
    2. Lots of people (photographers, lawyers, accountants, etc.) might want to share their work without sharing all the steps that went into creating that work.
    3. Lots of people might see a need to share data using something with limited bandwidth/storage.
  • by pclminion (145572) on Thursday December 08, 2005 @03:14PM (#14212679)
    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.

    • One problem I've noticed with every implementation of "Undo" that I've ever seen is that there is never any indication of what it is that you are about to "Undo". You hit Ctrl-Z and the cursor jumps to some unexpected part of the page -- what did it undo? No way to know, 'cuz it's not there, so now you have to "Redo" to compare, then "Undo" again.

      I'm not sure what the best way of implementing an improved "Undo" function would be. Perhaps "Undo" would just use strikeout and redlining to show what it is about
      • Animation. The app jumps to the edit you've asked to undo, then fades it out smoothly, perhaps with a dust cloud to signify "poof, it's gone." I'm not kidding--this would really help, if done tastefully, in a nonobtrusive manner.
    • There are lots of cases of changes that are not practically undoable. Not for text editing, but for other document types where keeping an infinite undo list would use up huge amounts of space or take massive amounts of time to step back and forth through.
  • I suppose the "save as" button is analogous to "dialing" a telephone. You would be hard pressed to find an actualy pulse type dial phone in the USA, but you don't "press" a phone number, you "dial" it. Things things make sense because of something in the past.
  • We have the save button for the same reason that we drive on the right (in the US) and stop at red lights -- its just the way it is, it works and everyone is used to it.

  • by Kelson (129150) * on Thursday December 08, 2005 @03:27PM (#14212796) Homepage Journal
    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...
  • Microsoft's oneNote (the new notetaking app bundled with office) has no 'save' function to speak of. It looks like the industry is taking the hint, and it's already being phased out where it can.

    many RAW image editing apps also do not have a save function for the simple reason that all RAW manipulations are nondestructive, and thus, nothing is potentially lost by saving every step along the way.
  • I use some things to create momentary onscreen storage -- sort of a clipboard proxy, if you will. For instance, if I want to copy & paste from one app to another, but decide that it's easier to fix the formatting in a plain text editor first. So I copy from app A, paste into the editor, fix it up, copy from the editor, paste into app B. Then I close the editor without saving. There is no reason to keep that plain text file -- none whatsoever. A setup that automatically saves every doc would, on my
  • Windows CE had this as a part of the recommended practices for programmers. For the most part, you never do bring stuff into RAM if you can help it- you leave it and edit it in storage memory instead of in program memory. Thus, no "Save" function is ever neccessary- because the data is already in storage memory. Save As is neccessary for setting file format and file name- but that's it.
  • by hey! (33014)
    So you can send your users humorous little messages like "Slow Down, Cowboy!"
  • Atomicity (Score:2, Insightful)

    by Evro (18923)
    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
  • No, it's not. (Score:3, Insightful)

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday December 08, 2005 @03:51PM (#14213112) Homepage Journal
    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).

    • Since you seem to know something about coyotos, why is it taking so long to bring this out? I sort of followed the discussions on Eros with interest for years and have been waiting to see capability computing brought back. In the meanwhile Unix is adding it (and interesting enough NT is sort of taking it out). Oracle has continued to use this model but there has been little discussion of the pros and cons based on Oracle's experiences.

      Do you have idea what the big holdup is?
      • Since you seem to know something about coyotos

        Actually, you probably know as much about it as I do. I randomly checked up on it ever few months or so, and only recently noticed the name and/or control change. I hope it turns into something, because I'd like to see a genuinely new approach to computing take off.

        • Oh ok. BTW its an old approach. This is sort of multics like, what the Unix guys were rebelling against. Also you see most of this stuff in VMS including the save model you mentioned.
  • Storage efficiency.

    Mostly, 'save' just pushes things from fast but volatile memory onto safer but slower disk storage. IMO, the bigger and more interesting question is why we haven't yet got a single storage solution that can be used both as efficient temporary non-volatile swap space, making RAM obsolete, and still be used for permanent storage, replacing hard drives.

    Stability.

    Going off on a tangent a little, I've often wondered why executable code and data are still put in the same memory address space. W
    • the bigger and more interesting question is why we haven't yet got a single storage solution that can be used both as efficient temporary non-volatile swap space, making RAM obsolete, and still be used for permanent storage, replacing hard drives.

      Well the reason is because we don't have the technology to produce infinitely fast high capacity storage. Right now (while holding cost constant) for linear increases in storage speed we can experience exponential drop offs in capacity. So to resolve that we
      • The problem is that we're using operating systems that are very old. Think about it. Linux, a "newish" OS is based on 30 year old concepts.

        I've long thought that we should do away with the conceptual separation between RAM and disk or other mass storage. We've already come a long way.. the average person has no need to think about cpu registers, or the cache, or even RAM to some extent with the use of swap files. We need to go all the way and just make it all one huge seamless memory space, where each l
  • Why isn't 'Save As' called 'Name and File'?

    'Name and File' seems pretty ambiguous to me. I prefer something like 'Save copy as...' or the title of the post, 'Save a copy with name...'

    We have the screen real estate to be a little more generous with our names :)

  • The problem is that many applications don't properly implement undo. As a result you could end up saving over data that you really wanted to retain.

  • I'm not sure if the quibble is about the word "Save" itself or the feeling that details of the system are being exposed in the application unneccessarily.

    Operation systems commonly use the "file cabinet" metaphor for persistent data storage and I personally think that if "File" were used as both a verb and a noun, that would be more confusing than staying with the "Save" verb.

    The user of a software application is typically doing work with some sort of data model. They usually expect the data in the model t
  • I've searched and searched and I can't find it anywhere on my Palm.
  • I guess I could just drag and drop all my files, who needs pesky pull down menus. (sarcasm)

    The OS is file based, even if the file system (note name) is database driven or a plain journaled file system, its files. Even unix is entirely made up of files pointing at files!

    Soon as the user knows what a file is, its easier for them to know about backups, copying files or working on files. Even in school the first thing they teach you is how to save your work, and revisions of your work per FILE.

    A question li
  • I often open files just to look at them, and inadvertently hit a key that modifies the file. I don't WANT such changes to be saved automatically, especially if I am not aware that I made them. If this mode were to be adopted, I would at least want two kinds of Open commands - Open to view, and Open to edit. Unfortunately given the feature-poor point-and-click interface most people use these days, this becomes more cumbersome, for example double-click = view, shift+double-click = edit. (You can specify an o
  • I as well as people I know use notepad and wordpad and other programs as temporary buffers to view data.

    I copy part of a file to a notepad window. I have no intention of saving this data, but want to view it in notepad and not vi. Maybe I'm going to use notepads find / replace, because I find it easier than vi ( personal opinion ), or for some other reason. Why they hell would I want notepad to just save this data without me telling it to?

    PDA's do what you ask already and so do phones. It is a case by

  • by alta (1263) on Thursday December 08, 2005 @05:46PM (#14214092) Homepage Journal
    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? ;)
  • by redelm (54142) on Thursday December 08, 2005 @05:48PM (#14214114) Homepage
    I don't know how you work with files, but I frequently poke around and do not want changes saved. This applies especially for spreadsheets. I always turn autosave off, and I'm quite conscious of the need to save and time myself accordingly.

  • 130 pages. About 30 pages filled with equations. Lots of photos, figures, tables, listings, indexes etc.
    Pentium 4 3GHZ, 1GB RAM.
    Over a minute to load/save. During saves system slows down to a crawl, what you type appears some 10 seconds later. You just have to wait through.
    Thank you, I'd better decide when to save by myself. Give the systems another 10 years of Moore's law and we can talk about removing 'save' again.
  • I know that at one point, it was considered necessary and useful to understand things, and people generally were expected to really think things through before posing stupid ideas and thinking we need to change the whole world without any reason every so often.

I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.

Working...