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