我有兴趣听取开发人员关于设计用户界面，可用性和可维护性的意见和经验。可用性：使用“应用”按钮或每次更改后保存更改？
通常的做法是让用户调整选项，当表格变得“脏”后，启用“应用”按钮，用户可以通过按下取消退出。这是Windows平台上最常见的方法（我相信MS可用性准则也会这样做）。
另一种方法是在对选项进行每个更改后应用更改。例如，用户选中某个复选框，并应用更改。用户更改某些文本框的值，并在框失去焦点后应用更改等。您可以获得该点。这种方法在Mac OSX上最常见。不管我个人的意见如何（苹果的可用性更好，但我通常写的软件都是针对Windows用户），你们怎么看？
编辑：我完全意识到，这不是一个真正的问题，而是要求讨论，而且它的位置可能不在SO上，其政策是只有答案和问题。但我相信这可能是有用的讨论，主要是因为在提问之前我找不到任何类似的内容。
两者都有自己的位置，并且它们都用于多种平台（它们并不是PC和Mac之间的区别）。
“应用”按钮方法允许您进行一些更改，应用它们，而不必重新打开对话框进行一些更改。这对于尝试解决问题很有用，但是当您希望用户对他们的选择进行有条不紊的思考时（或者感到安全） - 用户可以准确地掌控他们应用更改的时间。在某些情况下，您可能不希望在进行更改之前进行修改，或者在用户需要知道他们想要的设置的情况下，而不需要“实验”的情况下，这一点很重要。这些对话框通常也有一个取消按钮（希望）可以撤消自打开对话框后所做的任何更改。这些对话框通常是模态的，所以用户被锁定在对话框中，直到他们做出选择。
即时效果对话框允许用户根据自己的选择尝试并查看“实时”更新。当用户想要测试选项以了解它们会产生什么效果时，这非常棒。您必须小心使用视觉样式以向用户明确他们正在“正在运行”，并且他们必须小心，因为他们无法退出其变更。这种类型的对话框的Microsoft方法是有一个“关闭”按钮，这使得即时效果方法变得明显。这些对话通常不是模态的，即它们被视为“实时编辑面板”而不是对话框。
通常，UI倾向于围栏的实时编辑面，因为它允许用户通过诸如按下特殊按钮来提交更改等技术来实验性和不受阻碍（例如，请参阅Win7中的控制面板 - 很难与XP相比任何模态对话框）
然而，最终这两个选项之间的选择真的取决于您希望控制的设置类型。即，如果您在某些文本上设置字体样式，那么您确实想要处于实时实验端，但如果您正在配置重要的相关信息组（例如，您的DNS服务器地址和子网掩码）你可能想要使用一些需要你思考/了解并有意应用你的改变的东西（因此用户可以输入并仔细检查这些信息，因此他们可以同时改变几个相关的信息片段。另外，如果你提交了一个DNS服务器地址以用户输入的方式生效，他们将失去网络连接，直到他们获得所有数字为止 - 生活对此没有意义）。
当用户必须配置网络设置时，Apple本身正在使用“更安全”的方法。 http://www.riscos.org/networking/osx.html在许多其他地方，选项立即生效。 – 2010-06-17 22:55:32
符合平台预期。
我也同意Apple在可用性方面的优越性，但您的决定应该基于您的目标平台所展现的最常见行为。您应该始终以最小的用户体验出乎意料的用户，而对于大多数Windows用户，我猜这就是坚持OK/Apply/Cancel的行为。
如果您有跨平台的应用程序，请分别使用GUI，以尊重匹配平台期望口头禅。是的，这是额外的工作，但它表明你在乎。
我同意一般情况下您需要匹配平台预期。
个人，但是，一般我喜欢使用适用的/保存的原因有两个： 1）一种部分地施加变化可能是破坏性的（以延迟或在实际屏幕工件） 2）某些状态或它们的组合可以不有效（或者它们可能对用户的看法无效）。 3）如果您提供某种展开更改或用有意义的名称保存更改的方式，则可以根据用户选择何时应用或保存的方式对其进行逻辑分组。作为一名开发人员，我喜欢事物的提交/回滚方法，而且我也喜欢在我的UI中使用这种方法。
我只能想到两个很好的原因有应用按钮：
这些都不是很常见。几乎任何选项都可以在Histalally 1中使用。但是现在电脑速度更快，而且很少有相关性。如果变化的影响可以立即看到，为什么有人不想要那样？所以gui（但通常不是代码）可以通过跳过apply步骤来简化。我不认为用户真的需要取消按钮是很常见的，部分原因是它有点模糊。如果我进行一项更改，应用，进行其他更改并按取消，我应该期待什么？第一次更改是否会恢复（在大多数应用程序中，答案是否定的，因为更容易实现）？
如果是的话，那就是有了应用按钮，那么一切都被清除了，然后按OK /取消呢？或者我们需要考虑另一种选择，即窗口关闭，在这种情况下，第一次更改会保留，但第二次更改会恢复？
如果不是，则基本套用将被还原的书签设为取消按。但是这种复杂的行为真的需要在任何现实生活中使用吗？
保持这种复杂的历史原因是否理智，因为用户（据信）期望它？我看到用户总是按下应用，然后确定。为什么？也许只是因为GUI太复杂。或者，因为不确定“应用”是否意味着“应用和解除对话”（在某些应用中它会这样做），并且确定可能不会应用更改（我已经看到了错误的应用程序，如果没有应用就可以关闭窗口，也许他们也有）。至少我不认为用户总体上对这些复杂选择的准确逻辑有影响，因此他们不需要它，也不需要在那里。人们倾向于主要区分“积极”（是，好，向前，应用）和“否定”（否，取消，放弃，返回）行动是对话，有多个要么需要用户提供更多的支持。有趣的是，交换一个positiva行动与另一个似乎并没有太多影响用户的看法。如果一个带有按钮yes/no的对话框改变为ok/cancel，许多用户甚至不会注意到。
关于可用性（这是更重要的恕我直言）。如果做错了，可维护性即时应用可能非常混乱，但也非常干净和可维护，然后做对。如果应用程序采用一次性应用程序写入，则通常只有一个功能。对每一个小变化调用这样的函数当然不是非常有效。我所看到的这一点常常通过将功能分解为几个不同的功能来解决，以便应用不同的内容，理想情况下是针对可以进行的每种改变的一种专用功能。这会使应用程序响应更快，但维护起来很可怕。所以不要去那里。一个简洁的解决方案是使用MVC（模型 - 视图 - 控制器）并为每个配置项目创建一个模型，并将它们绑定到配置表单中的字段以及应用程序的相关部分（以及配置存储备份 - 结束，所有的变化都会自动保存）。如果在所讨论的环境中没有可用的MVC，绝对值得一写。
+1用于在整个表格填充后保存更改，而不是每个字段。
但是，只要字段失去焦点，应该进行验证，以便在出现任何错误时立即提供反馈。
我几乎可以肯定这是重复的，但是，这个话题是争论性的，并且最终没用，因为正确的答案总是“在给定的平台上做标准的事情”。 – 2010-06-17 22:24:48
我很乐意阅读有关该主题的整个讨论，但是，我一直无法找到一个。我提出这个问题要求人们的意见，因为这不是一个真正的问题，我不期望得到确切的答案。另外，这不是第一个“无用”的问题。 – 2010-06-17 22:29:19
“它已经发生了”的态度并不好，或者在我看来，是任何事情的借口。我很欣赏你可能对这个领域感兴趣，我希望你能找到你想要的信息。 – 2010-06-17 22:32:06