OneNote 之类的软件已经表明可以实现自动保存,并且它与手动保存按钮 / CTRL+S 一样好(或更好)。
无论如何,您想要保存的所有工作。只是如果你正在尝试一些破坏性的东西,你会在不保存的情况下关闭。
那么从程序员/可用性的角度来看,为什么今天几乎所有软件中仍然可以看到手动“保存”功能?是不是因为每个人都懒得在数据被修改时实现“自动保存”?
我们实施自动保存是否是个好主意,至少可以在我们的特定行业和我们的竞争对手中开始一些牵引力?
OneNote 之类的软件已经表明可以实现自动保存,并且它与手动保存按钮 / CTRL+S 一样好(或更好)。
无论如何,您想要保存的所有工作。只是如果你正在尝试一些破坏性的东西,你会在不保存的情况下关闭。
那么从程序员/可用性的角度来看,为什么今天几乎所有软件中仍然可以看到手动“保存”功能?是不是因为每个人都懒得在数据被修改时实现“自动保存”?
我们实施自动保存是否是个好主意,至少可以在我们的特定行业和我们的竞争对手中开始一些牵引力?
自动保存通常在定义的时间间隔内保存。如果你想在间隔之间保存会发生什么?
您应该实施手动保存以与环境中的其他应用程序保持一致。
人们期望文件->保存或 CTRL + S 存在。
保存按钮是一个众所周知的、舒适的 UI 功能,从 Jon Skeet 到奶奶,每个人都熟悉。如果您摆脱它,对于某些人来说,这就像删除窗口上的关闭按钮一样。当然,他们最终会习惯它,但有些人不明白他们的数据是自动保存的。
此外,如果您在网络上进行自动保存,那么您不仅会在所有这些实例上占用服务器上的大量空间,而且还会通过定期保存占用大量带宽。至少手动保存,你只是在用户想要的时候使用空间和带宽,这可能会更不频繁,从而节省带宽。当然,自动保存的优点是在出现问题时可以保留工作。
检查“ skeuomorph ”的定义:)
此外,“保存”通常还有“另存为..”。两者都给用户一种控制和安全的感觉。知道他们点击了保存,让他们知道在重新加载数据时他们可以预期他们的数据处于什么状态。
归根结底:Save 按钮的实现和维护成本比 Undo 低。
我在医疗领域工作,在某些情况下,您希望用户负责保存某些东西。如果您有 EHR 并且您正在为患者输入处方,那么您不一定希望它自动保存 - 您希望用户了解并为他们的行为负责。此外,由于显而易见的原因,在这样的关键系统中自动保存值可能是灾难性的......
实现自动保存并不难——只需实现一个正常的保存并在需要时调用它或者只是在计时器中调用它(如果你很懒的话)。
保存按钮很常见,因为用户几十年来学习的常见模式。
这种模式来自硬盘驱动器和主存储器之间的旧区别。如果您以另一种方式考虑它(就像某些实验性操作系统那样),则无需加载和保存文件-只需将硬盘驱动器视为您的主内存,而将主内存视为硬盘驱动器的另一个缓存级别. 因此,所有文件(不在可移动媒体上)始终在内存中,您将不再需要加载或保存文件。
但做这种改变并不容易,因为用户已经习惯了多年的旧模式。此外,旧的加载和保存模式是获得一种原始撤消系统的一种非常简单的方法。
自动保存也需要一个撤消系统,而且构建一个也不是那么简单。特别是如果您执行图像、音频或视频编辑并且您正在生成大量数据,则很难找到一个好的时间-内存权衡。并且存在用户会尝试通过关闭应用程序来撤消操作然后意识到这不起作用的风险。因此,保留撤消信息以保护用户免受此错误或在崩溃的情况下保存不需要的更改甚至可能是一个好主意。
所以,是的,我真的很想看到保存(和加载)按钮消失。我也想要持久的撤销信息,甚至完整的编辑历史。但我认为这种变化不会在几年内发生——如果有的话。
也许应该标记为主观的?
作为一名开发人员,我对这样的应用程序总是有点不安。我喜欢控制何时保存我的数据,尽管这可能只是多年的工作条件。每当我在没有明确按下关闭按钮(或快捷方式)的情况下关闭已输入数据的窗口时,我都会有一种“哦哦”的感觉。
也就是说,我已经“训练”在某些情况下接受它。例如,OneNote 或 Tomboy。很多 OS X 应用程序都遵循这种模式,尤其是数据库服务器 GUI 工具等实用程序应用程序。
所以,简而言之,不同的工具适用于不同的情况。IMO,如今大多数软件都不会从手动保存到自动保存中受益。
我认为这个问题的答案是“视情况而定”!
您不仅应该考虑用户在与其他应用程序的一致性方面的期望,还应该考虑用户将使用您的应用程序的方式。
OneNote 的一个非常常见的用例是有人打开它以转储一些信息,几乎作为他们正在处理的内容的旁白。他们需要快速进出。任何有关储蓄的提示都会令人讨厌。
另一方面,像 Word 这样的应用程序希望用户花费大量时间在文档上工作。在这种情况下,手动保存和响应确认框等工作将被视为一项相对较小的任务。
从程序员的角度来看,实现自动保存并不是什么大不了的事。您只需设置一个计时器,然后回调即可进行保存。
但是,从可用性的角度来看,自动保存是非常有问题的。首先,用户习惯于手动保存并且不提供给他们会使大多数用户感到困惑并失去控制感。
更大的问题是,无论您是否愿意,自动保存都会覆盖底层文件的内容。当然,您可以将自动保存功能保存到临时文件中,但覆盖原始文档的决定必须始终来自用户,而不是来自软件。而且因为您无论如何都需要用户启动至少一次手动保存,为什么不让手动保存始终可用呢?
处理文档时,自动保存功能非常有用。业务应用程序呢?如果我编辑客户的帐户,它是否应该在我从编辑的字段中跳出时更新帐户?如果是这样,当帐户处于无效状态时该怎么办?您何时执行业务规则以及如何执行它们?当您必须在每次编辑时考虑业务规则时,它将如何执行?
您当然可以构建一个考虑到这些因素的应用程序,但值得付出额外的努力吗?
那么我们应该摆脱“保存”按钮吗?这取决于。
简短的回答:“自动保存”=“自动销毁”/“自动 <expletive>”。
对于大学的一个项目,我和我的团队构建了一个应用程序,但没有明确保存为实验。
我们实现了无限撤消堆栈并使用实际数据序列化撤消堆栈,这样即使您关闭应用程序并重新打开它,您也可以随时撤消上一次操作。每个操作都会在磁盘上的操作列表中写入一个新条目,以便文件始终保持一致(嗯,大多数情况下......),即使电源出现故障。它有点像版本控制系统和日志文件系统之间的交叉。
有两个问题:一,我们没有时间把它完全正确(啊,年轻的狂妄自大);第二,每个人(同学们,最重要的是助教)都讨厌它,因为已经提到的所有原因。
有时,尽管你的意图是最好的,但你不能忽视根深蒂固的行为。