OK、APPLY、CANCEL 按钮的顺序
这个问题的延伸: https://stackoverflow.com/questions/50335/ok-cancel-or-cancel-ok< /a>
APPLY 按钮应该放在哪里(单击 APPLY 按钮与单击 OK 具有相同的效果,只是对话框保持打开状态)?
Windows 通常使用 OK-CANCEL-APPLY,但我倾向于使用 OK-APPLY-CANCEL。
另外,如果单击“应用”按钮,是否应将“取消”按钮文本更改为“关闭”,直到对话框中进行另一次更改?我假设如果没有要应用的更改,“应用”按钮将被禁用。
An extenstion of this question:
https://stackoverflow.com/questions/50335/ok-cancel-or-cancel-ok
Where should the APPLY button go (clicking the APPLY button has the same effect as clicking OK, except the dialog remains open)?
Windows typically uses OK-CANCEL-APPLY, but my inclination is to use OK-APPLY-CANCEL.
Also, if the APPLY button is clicked, should the CANCEL button text be changed to CLOSE until another change is made in the dialog? I'm assuming the APPLY button will be disabled if there are no changes to apply.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
为了回答您的第一个问题,Windows 7 和 Windows Vista 的 Windows 用户体验交互指南指定了以下命令按钮顺序 (p506):
确定
取消
申请
帮助
现在,你比微软聪明吗?好吧,你很难成为第一个,但你应该在发布你的设计之前证明这一点。对一组专门创建场景的用户运行可用性测试,以检查是否:
您的替代按钮顺序会产生卓越的用户性能。
当用户切换到使用标准顺序的另一个应用程序时,它不会导致性能缺陷。
。仅当上述两项均被证明为真时,才可违反 Windows UX 指南。
关于你的第二个问题,我建议你不要在用户选择“应用”后将“取消”更改为“关闭”。关闭按钮通常意味着任何后续更改都无法恢复。用户可能没有注意到按钮的初始标题,因此可能认为该对话框从不支持取消,从而使用户不愿意进一步探索该对话框。将标题保留为“取消”可以确保用户可以放弃接下来所做的任何更改。如果一些用户担心“取消”会撤消他们应用的任何内容,那么我希望他们只会选择“确定”。理论上来说。测试将再次告诉您用户的真实想法和行为,以及哪种设计可以做出最佳权衡。
我同意你的看法,这些“确定/应用”混合单次/多次使用对话框既混乱又令人困惑。解决整个问题的一种替代方法是使用“立即提交”,用户所做的任何更改都会立即显示在应用程序中(这可能是 Windows UX 指南中所说的“属性检查器”)。立即提交消除了“确定”、“应用”和“取消”的需要。相反,您有“关闭”,我还建议您还有一个“撤消”按钮,其工作方式类似于“撤消”菜单项,可以按顺序恢复用户对每个选择所做的每个更改。除了避免确定/应用/取消/关闭混乱之外,这种设计速度更快(尝试更改的点击次数更少),清楚用户输入的效果,并且支持增量撤消(取消是全部或全无)。
To answer your first question, the Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista specify the following order for your command buttons (p506):
OK
Cancel
Apply
Help
Now, are you smarter than Microsoft? Well, you’d hardly be the first, but you should prove it before releasing your design. Run a usability test on a bunch of users specifically creating scenarios to check if:
Your alternative button order produces superior user performance.
It does not cause a performance deficit when the user switches to another application that uses the standard order.
Go against the Windows UX Guide only if both of the above are demonstrated to be true.
Regarding your second question, I would recommend that you do not change Cancel to Close after the user selects Apply. A Close button usually implies that any subsequent changes cannot be reverted. Users may not have noticed the button’s initial caption thus may believe the dialog never supports canceling, making the user reluctant to explore the dialog further. Leaving the caption as Cancel assures users they can discard whatever changes they make next. If some users worry that Cancel will undo whatever they Applied, then I expect they’ll just select OK. In theory. Testing would once again tell you what users really think and do, and which design makes the best trade-off.
I’m with you that these OK/Apply hybrid single-use/multi-use dialogs are klugey and confusing. One alternative that gets around the whole problem is to use “immediate commit,” where whatever changes the user makes are instantly shown in the application (this may be a “property inspector” as the Windows UX Guide calls it). Immediate commit eliminates the need for OK, Apply and Cancel. Instead you have Close, and I would also suggest you also have an Undo button that works like an Undo menu item, sequentially reverting each change the user made with each selection. In addition to avoiding the OK/Apply/Cancel/Close confusion, this design is faster (fewer clicks to try a change), makes it clear what user input has what effect, and supports incremental undo (Cancel is all or nothing).
我坚持克里斯·罗伯茨的回答:与操作系统。
编辑:即使您认为定位错误,也请记住,就 Windows 而言,Microsoft 进行了大量的用户测试和焦点小组工作。即使 Ok-Cancel-Apply 不是您应用程序的最佳答案,如果用户习惯了该布局,那么它可能是最不坏的解决方案。
我想到了最近对 Ubuntu UI 的更改,Canonical 团队决定将最小化/最大化/关闭按钮移至窗口镶边顶部。功能没有改变,但它确实惹恼了一些用户(包括我自己)。在您的应用程序可能遇到的所有问题中,您真的需要添加这样令人头疼的 UI 问题吗?
I'd stick with Chris Roberts' answer: be consistent with the operating system.
Edit: even if you consider the positioning wrong, keep in mind that in the case of Windows, Microsoft does a ton of user testing and focus-group goodness. Even if Ok-Cancel-Apply isn't the best answer for your application, if the users are accustomed to that layout then it's likely the least bad solution.
I think about the recent change to the Ubuntu UI where the Canonical team decided to move the minimize/maximize/close buttons at the top of the window chrome. The functionality wasn't changed, but boy did it irk some users (myself included). Of all the problems your application may encounter, do you really need to add a UI headache like that?
在 Windows 中:
确定
取消
上一个
下一个
同意
不同意
在 Mac 操作系统中:
取消
确定
上一页
下一页
不同意
同意
PS
我更喜欢始终将下一个操作设置在更靠近右侧的位置。这就像阅读文本(从左到右)。所以下一步总是更靠近右边,上一步总是更靠近左边。
对我来说,以前或过去的事情应该放在左边,下一个或未来应该在右边。
但民意调查显示这是 50%/50%...所以最终的决定取决于你。
离线:
我从 Windows 3.11 开始使用 Microsoft,并且很确定 Microsoft 中没有人如此深入地考虑过这个问题......以及 UI 中的许多其他事情......
In Windows:
OK
Cancel
Prev
Next
Agree
Disagree
In Mac OS:
Cancel
OK
Prev
Next
Disagree
Agree
P.S.
I prefer always set the next action closer to the right. It's like reading text (from left to right). So the next step is always closer to right, the previous step is always closer to left.
For me, it's make more sense that something previous or past should be on the left and the next or future should be on the right.
But polls show it's 50%/50%... So the final decision is up to you.
Offtop:
I'm using Microsoft from Windows 3.11 and pretty sure nobody in Microsoft ever thought about this so deeply... and about a lot other things in UI also...
我不会偏离世界上使用最广泛的操作系统系列......
I wouldn't diverge from the most widely used operating system family in the world...
它应该保持“确定-取消-应用”状态。用户通常会在完成所有操作后单击“确定”,但单击“应用”将允许用户测试他们所做的更改,而无需关闭对话框。 “确定”和“取消”按钮在警报框中保持在一起,但在某些对话框中将“应用”添加到末尾以添加额外的功能。保持与操作系统和 Windows 用户习惯的相同。
It should stay as OK-CANCEL-APPLY. Users would usually click OK once they have completed everything, but clicking Apply will allow the user to test the changes they have made without having to close the dialog box. The OK and Cancel buttons stay together in alert boxes, but Apply was added to the end in some dialog boxes to add the extra functionality. Keep it the same as the operating system and what Windows users are used to.
抱歉各位,但是任何认为微软是可用性典范的人都没有注意到。他们的大多数设计都是在进行任何用户测试之前就产生的,因此微软不愿意改变这种巨大的惯性。为此,我并不责怪他们,但任何/所有微软产品中愚蠢的用户界面都受到了很多指责。看看这个:要退出软件,请单击“开始”按钮。如果他们的数百万美元都花在了这个无意义的事情上,那么这些钱也被浪费了。
让我们设计和测试,遵循我们的测试结果,然后重新设计,直到我们得到正确的结果;忘记惯性!
我自己的测试不断证实,即使对于在整个计算机体验过程中一直使用 Windows 的用户来说,相反的 Windows 也能更好地工作。对于从右向左阅读的读者来说,按从功率较小到功率较大的顺序排列按钮效果更好,也更有意义。先取消,再保存,更像苹果风格。
Sorry guys, but anyone who considers Microsoft to be an appropriate paradigm of usability just isn't paying attention. Most of their designs originated before doing any user testing at all, and so Microsoft is reluctant to change from that massive inertia. For that, I don't blame them, but there is blame aplenty for boneheaded UI in any/all Microsoft products. Just look at this: To quit the software, you click the START button. If their $millions were spent on this boondoggle, then those dollars were also wasted.
Let's design and test, follow our test results, and redesign until we get it right; forget inertia!
My own testing keeps confirming that the Windows opposite works better, even with users who have been with Windows throughout their entire computer experience. For right-to-left readers, ordering buttons from less power to more power just works better and makes more sense. Cancel first, then Save, more like the Apple style.