为什么需要保存按钮？
像 OneNote 这样的软件已经表明可以实现自动保存，并且它的效果与手动保存按钮/CTRL+S 一样好（甚至更好）。
不管怎样，你所做的一切你都想保存。只是如果您正在尝试一些破坏性的东西，您会关闭而不保存。
那么，从程序员/可用性的角度来看，为什么今天几乎所有软件中仍然可以看到手动“保存”功能？是因为大家都懒得在数据修改时实现“自动保存”吗？
对我们来说实施自动保存是一个好主意吗？至少可以在我们的特定行业和竞争对手中引起一些关注？
Software like OneNote has shown that auto-save can be implemented, and it works just as well (or better) as the manual save button / CTRL+S.
Anyways everything that you work on you want saved. Its just if you're trying out something destructive that you would close without saving.
So from a programmers/usability perspective, why is the manual "save" feature still seen in virtually all software today? Is it because everyone is too lazy to implement "auto-save" whenever data gets modified?
And is it a good idea for us implement auto-save, at least to start some traction in our specific industry and amongst our competitors?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
也许应该被标记为主观？
作为一名开发人员，我总是对这样的应用程序感到有点不安。我喜欢控制何时保存我的数据，尽管这可能只是多年的工作调节。每当我关闭一个在其中输入数据而没有明确按下关闭按钮（或快捷方式）的窗口时，我都会有一种“呃哦”的感觉。
也就是说，我已经接受过“训练”，可以在某些情况下接受它。例如 OneNote，或者 Tomboy。许多 OS X 应用程序都遵循这种模式，尤其是诸如数据库服务器 GUI 工具之类的实用程序应用程序。
简而言之，不同的工具适用于不同的情况。 IMO，现在大多数软件都不会从手动保存到自动保存的转变中受益。
Should be tagged subjective maybe?
As a developer, I am always a little uneasy around apps like that. I like having control over when my data is saved, though perhaps this is just years of conditioning at work. I get that little "uh oh" feeling whenever I close a window into which I've entered data without explicitly pressing a close button (or shortcut).
That said, I have been "trained" to accept it in certain situations. OneNote, for example, or Tomboy. A great many OS X apps follow this pattern, especially utility apps like DB server GUI tools.
So, in short, different tools for different situations. IMO, most software these days would not benefit from a move from a manual save to an auto-save.
我认为这个问题的答案是“视情况而定”！
您不仅应该考虑用户对与其他应用程序的一致性的期望，还应该考虑用户使用您的应用程序的方式。
OneNote 的一个非常常见的用例是，有人打开它来转储一些信息，几乎作为他们正在处理的内容的旁白。他们需要快速进出。任何关于保存的提示都会很麻烦。
另一方面，Word 等应用程序希望用户花大量时间处理文档。在这种情况下，手动保存和响应确认框等的繁琐工作将被视为相对较小的任务。
I think the answer to this is that 'it depends'!
You should consider not only your user's expectations in terms of consistency with other applications, but also the way in which the user is going to use your application.
A very common use-case for OneNote is that someone opens it up to dump in some information almost as an aside to what they're working on. They need to get in and out quickly. Any prompts about saving would be a nuisance.
Applications like Word, on the other hand, expect users to be spending a concerted amount of time working on a document. In this case, the chore of manually saving and responding to confirmation boxes etc will be seen as a relatively small task.
从程序员的角度来看，实现自动保存并不是什么大问题。您只需设置一个计时器，回调就会完成保存。
然而，从可用性的角度来看，自动保存是很有问题的。首先，用户习惯于手动保存，不向他们提供手动保存会让大多数用户感到困惑并失去控制感。
更大的问题是自动保存会覆盖底层文件的内容无论您是否想要。当然，您可以将自动保存功能保存到临时文件中，但必须始终做出覆盖原始文档的决定来自用户，而不是来自软件。而且因为无论如何您都需要用户启动至少一项手动保存，为什么不始终启用手动保存呢？
From programmers perspective implementing autosave would not be a huge deal. You just set up a timer and callback would do the saving.
However, from usability point of view autosave is very problematic. First of all users are used to having a manual saving and not offering it to them would confuse a majority of users and take feel of control away.
Even bigger issue would be that autosave overwrites contents of underlaying file whether you wanted it or not. Of course you could have autosave feature saving onto temporary file but the decision to overwrite original document must always come from the user, not from the software. And because you would anyways need the user to initiate at least one manual saving, why not enable manual saving to be available always?
当您处理文档时，自动保存功能非常有用。商业应用程序怎么样？如果我编辑客户的帐户，当我从编辑的字段中跳出时，它是否应该更新该帐户？如果是的话，当账户处于无效状态时该怎么办？您何时执行业务规则以及如何执行它们？当您必须在每次编辑时考虑业务规则时，它将如何表现？
您当然可以构建一个将这些考虑因素考虑在内的应用程序，但是值得付出额外的努力吗？
那么我们应该去掉“保存”按钮吗？这取决于。
An autosave feature is great when you are dealing with a document. What about a business application? If I edit a customer's account, should it update the account as I tab out of the edited fields? If so, what should it do when the account is in an invalid state? When do you enforce business rules and how do you enforce them? How will it perform when you have to take business rules into account on every edit?
You can certainly build an application that will take any of these considerations into account, but will it have been worth the extra effort?
So should we get rid of the Save button? It depends.
简短回答：“自动保存”=“自动销毁”/“自动<脏话>”。
Short answer: "auto save" = "auto destroy" / "auto <expletive>".
对于大学的一个项目，我和我的团队构建了一个应用程序，但没有明确保存为实验。
我们实现了无限撤消堆栈，并使用实际数据序列化了撤消堆栈，这样即使您关闭应用程序并重新打开它，您也始终可以撤消上次操作。每个操作都会向磁盘上的操作列表写入一个新条目，以便文件始终保持一致（嗯，大部分......），即使断电也是如此。它有点像版本控制系统和日志文件系统之间的交叉。
有两个问题：一，我们没有时间把它完全正确（啊，年轻人的狂妄自大）；第二，每个人（同学们，最重要的是助教）都讨厌它，因为前面提到的所有原因。
有时，尽管你的意图是好的，但你还是不能忽视根深蒂固的行为。
For one project in university, my group and I built an application without explicit saving as an experiment.
We implemented an infinite undo stack and serialized the undo stack with the actual data so that even if you closed the app and re-opened it, you could always undo your last operation. Every operation wrote a new entry to the action list on disk so that the file was always consistent (well, mostly...), even if the power failed. It was a bit of a cross between a version control system and a journaling file system.
There were two problems: one, we didn't have time to get it completely right (ah, youthful hubris); two, everyone (fellow students and, most importantly, the TAs) hated it, because of all of the reasons mentioned already.
Sometimes, for all your best intentions, you just can't ignore ingrained behaviours.
自动保存通常按定义的时间间隔进行保存。如果您想在时间间隔之间进行保存，会发生什么情况？
您应该实施手动保存，以与环境中的其他应用程序保持一致。
人们期望文件 ->保存，或 CTRL + S 存在。
autosave normally saves on a defined interval. What happens if you want to save in between intervals?
You should implement a manual save to stay consisent with other applications in the environment as well.
People expect file -> save, or CTRL + S to exist.
保存按钮是一个众所周知的、舒适的 UI 功能，从 Jon Skeet 到奶奶，每个人都熟悉它。如果你去掉它，对某些人来说就像去掉窗口上的关闭按钮一样。当然，他们最终会习惯它，但有些人不明白他们的数据已被自动保存。
此外，如果您在网络上进行自动保存，那么所有这些实例不仅会占用服务器上的大量空间，而且定期保存也会占用大量带宽。至少通过手动保存，您只在用户想要的时候使用空间和带宽，这可能会比较不频繁，从而节省带宽。当然，自动保存的优点是在出现问题时保留工作。
检查“skeuomorph”的定义:)
The save button is a well-known, comfortable UI feature that everyone from Jon Skeet to grandma is familiar with. If you got rid of it, it would be like removing the close button on a window for some people. Granted, they would eventually get used to it, but some people would not understand that their data has been saved automatically.
Also, if you're autosaving on the web, not only are you taking up a lot of space on your server with all those instances, you're also using up a lot of bandwidth with periodical saves. At least with manual save, you are only using the space and bandwidth when the user intends, which can be more infrequent, thus saving bandwidth. The advantage, of course, to autosaving is the retention of work should something go awry.
Check the definition of "skeuomorph" :)
除了“保存”之外，通常还有“另存为..”。两者都给用户带来控制感和安全感。了解他们单击了“保存”后，他们就知道重新加载数据时预计数据将处于什么状态。
Additionally with a "save" there is commonly "save as.." as well. Both give the user the feeling of control and security. Knowing that they clicked save lets them know at what state they can expect their data to be in when reloading it.
实际上可以归结为：“保存”按钮的实施和维护成本比“撤消”更便宜。
It really comes down to this: a Save button is cheaper to implement and maintain than Undo.
实现自动保存并不难 - 只需实现一个正常的保存并在需要时调用它或仅在计时器中调用它（如果你很懒）。
保存按钮很常见，因为用户几十年来已经学会了常见的模式。
这种模式来自硬盘驱动器和主内存之间的旧区别。如果您以另一种方式思考（就像某些实验性操作系统所做的那样），则无需加载和保存文件 - 只需将硬盘驱动器视为您的主存储器，并将主存储器视为硬盘驱动器的另一个缓存级别。因此，所有文件（不在可移动媒体上）始终位于内存中，您将不再需要加载或保存文件。
但做这个改变并不容易，因为用户多年来已经习惯了旧的模式。此外，旧的加载和保存模式是获得一种原始撤消系统的非常简单的方法。
自动保存也需要一个撤消系统，而且构建一个系统并不是那么简单。特别是如果您执行图像、音频或视频编辑并且生成大量数据，则很难找到良好的时间-内存权衡。并且存在这样的风险：用户会尝试通过关闭应用程序来撤消操作，然后意识到这不起作用。因此，保留撤消信息以保护用户免受此错误的影响或在崩溃时保存不需要的更改可能是一个好主意。
所以，是的，我真的很希望看到保存（和加载）按钮消失。我也想要持久的撤消信息甚至完整的编辑历史记录。但我认为这种变化在几年内不会发生——如果有的话。
It is not hard to implement auto-save - just implement a normal save and call it when ever needed or just in a timer (if you are lazy).
Save buttons are common because of the common pattern learned by the users for decades.
This pattern comes from the old distinction between harde drive and main memory. If you think about it in another way (as some experimental operating systems do), there is no need for loading and saving files - just think about a hard drive as your main memory and and the main memory as another cache level for the hard drive. In consequence all files (not on removeable medias) are always in memory and you will never again need to load or save files.
But doing this change is not easy because users are used to the old pattern for years. Further the old load and save pattern is an very easy way to get a kind of primitve undo system.
Auto-saving requires an undo system, too, and it is not that trivial to build one. Esspecialy if you perform image, audio or video editing and you are producing a lot of data it is hard to find a good time-memory-trade-off. And there is the risk that user will try to undo things by closing the application and then recognize that this did not work. So it might even be a good idea to persist undo information to protect users from this error or saving unwanted changes in the case of a crash.
So, yes, I would realy like to see the save (and load) buttons to disappear. I would like persisted undo-information or even complete edit histories, too. But I don't think this change can happen in a few years - if ever.
我在医疗领域工作，有时您希望用户负责保存某些东西。如果您有 EHR 并且正在为患者输入处方，那么您不一定希望它自动保存 - 您希望用户了解并对其行为负责。此外，由于显而易见的原因，在这样的关键系统中自动保存值可能会造成灾难性的后果......
I work in the medical field and there are situations where you want the user to take responsibility for saving something. If you have an EHR and you are entering a prescription for a patient then you dont necessarily want it autosaving - you want the user to be aware of and take responsibility for their actions. Also, autosaving a value in a critical system like this could be disastrous for obvious reasons...