为什么需要保存按钮？答案

【问题标题】：Why is the save button needed?为什么需要保存按钮？
【发布时间】：2010-11-20 16:16:56
【问题描述】：

像 OneNote 这样的软件已经表明可以实现自动保存，并且它的效果与手动保存按钮 / CTRL+S 一样好（或更好）。

无论如何，您想要保存的所有内容。只是如果您正在尝试破坏性的东西，您会关闭而不保存。

那么从程序员/可用性的角度来看，为什么现在几乎所有软件中仍然可以看到手动“保存”功能？是不是大家都懒得在数据被修改的时候实现“自动保存”？

我们实施自动保存是否是个好主意，至少可以在我们的特定行业和我们的竞争对手中开始一些牵引力？

【问题讨论】：

当我想到有多少次我不小心在错误的窗口中输入了字符，因为我错误地认为我正在查看的窗口有焦点，我意识到没有某种恢复方式的自动保存是不好的。甚至不是这样，有时我打开文件并知道我没有进行任何更改（例如参考文档）但程序声称我做了。一想到我可能正在保存我不想要的东西，我就害怕，所以当提示时我不保存。使用自动保存，我如何确保不会自动保存这些类型的“更改”？
您必须能够告诉用户何时保存了某些内容。一个好的应用程序将实现自动保存功能和手动保存功能。查看 MS Word，它实现了自动保存功能和手动保存功能。但是，有时自动保存很糟糕，因为它不允许用户控制何时保存某些内容。例如，在订购软件中，您可能会犯错误，并且您不希望它一直被提交或处理。
One Note 在这一点上让我很生气。我希望能够显式保存东西，自动保存应该是紧急恢复选项。
自动保存应该是第三方保存文件。如果用户想要保存多个文档，这自动意味着您将需要手动保存，如果您需要，自动保存无论如何都会成为附加功能。

标签： filesystems save autosave ui-design onenote

【解决方案1】：

对于大学的一个项目，我和我的团队构建了一个应用程序，但没有明确保存为实验。

我们实现了无限撤消堆栈并使用实际数据对撤消堆栈进行序列化，这样即使您关闭应用并重新打开它，您也始终可以撤消上一次操作。每个操作都会在磁盘上的操作列表中写入一个新条目，以便文件始终保持一致（嗯，大多数情况下......），即使电源出现故障。它有点像版本控制系统和日志文件系统之间的交叉。

有两个问题：一，我们没有时间把它完全正确（啊，年轻的狂妄自大）；第二，每个人（同学们，最重要的是助教）都讨厌它，因为已经提到的所有原因。

有时，尽管你的意图是最好的，但你不能忽视根深蒂固的行为。

【讨论】：

【解决方案2】：

归根结底：保存按钮的实现和维护成本低于撤消按钮。

【讨论】：

+1 我认为这与简单有关。如果您需要手动保存选项（您可能需要），那么添加自动保存将成为一项额外功能，并且可能没有足够的附加值来保证手动保存和自动保存以及他们之间的必要沟通。

【解决方案3】：

当您处理文档时，自动保存功能非常有用。业务应用程序呢？如果我编辑客户的帐户，它是否应该在我从编辑的字段中跳出时更新帐户？如果是这样，当账户处于无效状态时该怎么办？您何时执行业务规则以及如何执行它们？当您必须在每次编辑时考虑业务规则时，它将如何执行？

您当然可以构建一个考虑到这些因素的应用程序，但是值得付出额外的努力吗？

那么我们应该去掉保存按钮吗？视情况而定。

【讨论】：

【解决方案4】：

我在医疗领域工作，在某些情况下您希望用户负责保存某些东西。如果您有 EHR 并且您正在为患者输入处方，那么您不一定希望它自动保存 - 您希望用户了解并为他们的行为负责。此外，出于显而易见的原因，在这样的关键系统中自动保存值可能是灾难性的......

【讨论】：

【解决方案5】：

简答：“自动保存”=“自动销毁”/“自动 ”。

【讨论】：

不，自动保存没问题，只要它对显式保存没有任何影响。如果自动保存始终是单独的保存文件，那么它只能增加价值。
有趣。这有点微妙，但很好。在其他地方放置一个恢复缓冲区，但让我控制我的涂鸦的当前状态是否应该保存。

【解决方案6】：

从程序员的角度来看，实现自动保存并不是什么大不了的事。您只需设置一个计时器，然后回调即可进行保存。

但是，从可用性的角度来看，自动保存是非常有问题的。首先，用户习惯于手动保存并且不向他们提供它会使大多数用户感到困惑并失去控制感。

更大的问题是自动保存会覆盖底层文件的内容无论你是否想要。当然你可以将自动保存功能保存到临时文件中，但决定覆盖原始文件必须始终来自用户，而不是来自软件。而且因为您无论如何都需要用户启动至少一次手动保存，为什么不让手动保存始终可用？

【讨论】：

【解决方案7】：

实现自动保存并不难 - 只需实现正常保存并在需要时调用它或仅在计时器中调用它（如果你很懒）。

保存按钮之所以常见，是因为用户几十年来学习的共同模式。

将数据或文件从持久存储加载到主内存中。
修改主内存中的数据。
将修改后的数据保存回永久存储。

这种模式来自硬盘驱动器和主内存之间的旧区别。如果您以另一种方式考虑它（如某些实验性操作系统所做的那样），则无需加载和保存文件-只需将硬盘驱动器视为您的主内存，而将主内存视为硬盘驱动器的另一个缓存级别.因此，所有文件（不在可移动媒体上）始终在内存中，您再也不需要加载或保存文件。

但是进行这种更改并不容易，因为用户已经习惯了旧模式多年。此外，旧的加载和保存模式是获得一种原始撤消系统的一种非常简单的方法。

自动保存也需要一个撤消系统，而且构建一个也不是那么简单。特别是如果您执行图像、音频或视频编辑并且您正在生成大量数据，则很难找到一个好的时间内存权衡。并且存在用户会尝试通过关闭应用程序来撤消操作然后意识到这不起作用的风险。因此，保留撤消信息以保护用户免受此错误或在崩溃时保存不需要的更改甚至可能是一个好主意。

所以，是的，我真的很想看到保存（和加载）按钮消失。我也想要持久的撤销信息，甚至完整的编辑历史。但我认为这种变化不会在几年内发生——如果有的话。

【讨论】：

【解决方案8】：

我认为这个问题的答案是“视情况而定”！

您不仅应该考虑用户在与其他应用程序的一致性方面的期望，还应该考虑用户将使用您的应用程序的方式。

OneNote 的一个非常常见的用例是有人打开它以转储一些信息，几乎作为他们正在处理的内容的旁白。他们需要快速进出。任何有关保存的提示都会令人讨厌。

另一方面，Word 等应用程序希望用户花费大量时间来处理文档。在这种情况下，手动保存和响应确认框等工作将被视为一项相对较小的任务。

【讨论】：

正如人们在这里所指出的那样，他们的用例并没有太大的不同。人们 - 有时也希望能够在 OneNote 中明确保存某个状态，但该选项恰好不可用。

【解决方案9】：

保存按钮是众所周知的、舒适的 UI 功能，从 Jon Skeet 到奶奶，每个人都熟悉。如果你摆脱了它，对于某些人来说，这就像删除窗口上的关闭按钮一样。诚然，他们最终会习惯的，但有些人不明白他们的数据是自动保存的。

此外，如果您在网络上进行自动保存，那么您不仅会为所有这些实例占用服务器上的大量空间，而且还会通过定期保存占用大量带宽。至少手动保存，你只是在用户想要的时候使用空间和带宽，这可以更不频繁，从而节省带宽。当然，自动保存的优点是在出现问题时可以保留工作。

检查“skeuomorph”的定义:)

【讨论】：

我相信 Jon Skeet 的程序只会在 Jon 需要时自动保存。
“更不频繁”...也称为“不太频繁”？
尽管含义几乎完全相同，但它们的内涵略有不同。 “更不频繁”意味着某些事情不会发生很多，现在发生得更少，而“不太频繁”意味着它确实发生了很多，但现在发生得更少了。在大局中，这意味着它发生的更少。

【解决方案10】：

除了“保存”之外，通常还有“另存为..”。两者都给用户一种控制和安全的感觉。知道他们点击了“保存”后，他们就可以知道在重新加载数据时可以预期他们的数据处于什么状态。

【讨论】：

【解决方案11】：

也许应该被标记为主观的？

作为一名开发人员，我总是对这样的应用感到有些不安。我喜欢可以控制何时保存我的数据，尽管这可能只是多年的工作条件。每当我在没有明确按下关闭按钮（或快捷方式）的情况下关闭已输入数据的窗口时，我都会有一种“哦哦”的感觉。

也就是说，我已经“训练”过在某些情况下接受它。例如，OneNote 或 Tomboy。很多 OS X 应用程序都遵循这种模式，尤其是数据库服务器 GUI 工具等实用程序应用程序。

因此，简而言之，针对不同情况的不同工具。 IMO，如今大多数软件都不会从手动保存到自动保存中受益。

【讨论】：

【解决方案12】：

自动保存通常在定义的时间间隔内保存。如果您想在间隔之间保存会发生什么？

您应该实施手动保存以与环境中的其他应用程序保持一致。

人们期望文件 -> 保存或 CTRL + S 存在。

【讨论】：

在添加/编辑超出特定限制的数据时无法触发自动保存？这样，您将始终恢复任何重大更改。
@Jeremy Rudd：“重大”变化不一定是大变化。
+1 表示“人们期望文件 -> 保存存在”。 IME 这是包含任何看似多余的操作（包括保存）的最重要的原因。