我很想听听其他开发人员在设计用户界面、可用性和可维护性方面的意见和经验。
常见的方法是允许用户调整选项，在表单变得“脏”后，启用“应用”按钮，用户可以通过按取消来退出。这是 Windows 平台上最常见的方法（我相信 MS 可用性指南也这么说）。
另一种方法是在对选项进行每次更改后应用更改。例如，用户选中某个复选框，并应用更改。用户更改某些文本框的值，并在框失去焦点后应用更改等。你明白了。这种方法在 Mac OSX 上最为常见。
不管我个人的看法是什么（苹果在可用性方面做得更好，但我写的软件通常是针对 Windows 用户的），你们怎么看？
编辑：我完全意识到这不是一个真正的问题，而是要求进行讨论，而且它的位置可能不在 SO 上，其政策是只提供答案和问题。但我相信这可能是有用的讨论，主要是因为在询问之前我找不到类似的东西。
两者都有自己的位置，并且它们都在许多平台上使用（它们并不是 PC 和 Mac 之间的真正区别）。
“应用”按钮方法允许您进行一些更改、应用它们，而不必重新打开对话框来进行更多更改。这对于尝试事情很有用，但是当您希望用户有条不紊地思考（或感到安全）他们的选择时 - 用户可以精确地控制何时应用他们的更改。这在某些情况下很重要，因为您可能希望在完成其中几个更改之前不提交更改，或者在用户应该知道他们想要什么设置而不是需要“实验”的情况下。这些对话框通常还有一个取消按钮，（希望）可以撤消对话框打开后所做的任何更改。这些对话框通常是模态的，因此用户被锁定在对话框中，直到他们做出选择。
即时效果对话框允许用户根据他们的选择进行试验并查看“实时”更新。当用户想要试验选项以查看它们将产生什么效果时，这非常有用。您必须小心视觉样式，以使用户清楚他们正在“实时”操作，并且他们必须小心，因为他们无法撤销他们的更改。对于这种类型的对话框，Microsoft 的方法是使用单个“关闭”按钮，这使得即时效果的方法显而易见。这些对话框通常不是模态的，即它们被视为“实时编辑面板”而不是对话框。
通常，UI 倾向于围栏的实时编辑侧，因为它允许用户进行实验并且不受技术细节的阻碍，例如必须按下特殊按钮来提交更改（例如，参见 Win7 中的控制面板 - 几乎没有任何模态对话框可比较到 XP）
但是，最终这两个选项之间的选择实际上取决于您希望控制的设置类型。即，如果您要在某些文本上设置字体样式，那么您真的希望处于现场实验的末端，但是如果您正在配置重要且相关的信息组（例如，您的 DNS 服务器的地址和您的子网掩码）您可能想要使用需要您思考/知道并有意识地应用您的更改的东西（因此用户可以输入并仔细检查信息，因此他们可以“同时”更改多个相关信息。此外，如果您提交DNS 服务器地址在用户键入时实时，他们将失去他们的网络连接，直到他们得到所有数字正确 - 活着对此没有意义）。
匹配平台期望。
我也同意 Apple 在可用性方面更胜一筹，但您的决定应该基于您的目标平台表现出的最常见行为。你应该总是做最不让用户感到惊讶的事情，对于大多数 Windows 用户来说，我猜这就是要坚持这种OK/Apply/Cancel行为。
如果您有跨平台的应用程序，请使用独立的 GUI 来尊重匹配平台期望的口头禅。是的，这是额外的工作，但它表明你在乎。
我同意一般来说你需要匹配平台的期望。
然而，就个人而言，我通常更喜欢使用应用/保存，原因有两个：1）部分应用的更改可能会造成破坏（延迟或实际屏幕伪影）2）某些状态或组合可能无效（或者它们可能无效在用户的感知中是有效的）。3) 如果您提供某种方式来展开更改或使用有意义的名称保存更改，那么根据用户选择点击应用或保存的时间对它们进行逻辑分组是有意义的。作为一名开发人员，我喜欢提交/回滚的方法，我也喜欢在我的 UI 中使用这种方法。
我只能想到有一个应用按钮的两个很好的理由：
这些都不是很常见。Historacally 1 过去几乎适用于任何选项。但是现在计算机速度更快，并且 1 很少相关。如果改变的效果可以立即看到，为什么会有人不想要呢？因此，可以通过跳过应用步骤来简化 gui（但通常不是代码）。我认为用户真正需要取消按钮的情况也不常见，部分原因是它有点模棱两可。如果我进行一项更改、应用、进行其他更改并按取消，我应该期待什么？是否会恢复第一个更改（在大多数应用程序中，答案是否定的，因为这更容易实现）？
如果是，那就是拥有应用按钮的关键，然后一切都结束了，然后仍然按确定/取消？或者我们是否需要考虑另一种选择，即关闭窗口，在这种情况下保留第一个更改但恢复第二个更改？
如果否，则应用基本上设置一个书签，如果按下取消，它将恢复为。但是在任何现实生活用例中真的需要这种复杂的行为吗？
因为用户（被认为）期望它而保持这种历史原因的复杂性是否合理？我看到用户总是按应用，然后确定。为什么？也许只是因为 GUI 太复杂了。或者因为不确定“应用”是否意味着“应用和关闭对话框”（它在某些应用程序中这样做）并且 OK 可能不会应用更改（我已经看到错误的应用程序，其中 OK 只是关闭窗口而不应用，也许他们也有）。至少我不认为用户一般都知道这些复杂选择的确切逻辑，因此他们不需要它，也不需要它。人们倾向于主要区分“积极”（是，好的，前进，应用）和“消极”（否，取消，中止，返回）动作是对话，拥有一个以上的任何一个都需要用户更多的关注。有趣的是，与另一个交换一个积极的行动似乎并没有太大影响用户的感知。如果带有按钮是/否的对话框更改为确定/取消，许多用户甚至不会注意到。
关于可用性（恕我直言，这更为重要）。如果做错了，可维护性的即时应用可能会非常混乱，但如果做得好，也会非常干净和可维护。如果应用程序是使用一次性应用的方法编写的，则通常只有一个功能。为每一个微小的变化调用这样的函数当然不是很有效。我所看到的通常是通过将函数拆分为几个不同的函数来应用不同的东西来解决这个问题，理想情况下，一个专用函数用于可以进行的每种更改。这将使应用程序更具响应性，但维护起来很糟糕。所以不要去那里。一个巧妙的解决方案是使用 MVC (Model-View-Controller) 并为每个配置项创建一个模型，并将它们绑定到配置表单中的字段以及应用程序的相关部分（以及配置存储 back-结束，因此每个更改都会自动保存）。如果相关环境中没有可用的 MVC，那么绝对值得编写一个。
+1 用于在填写整个表单而不是每个字段后保存更改。
但是，只要字段失去焦点，就应该进行验证，以便在出现任何问题时立即提供反馈。