在确定菜单项目的位置时是否有任何标准可供遵循？

Question

在开发基于Windows窗体的应用程序时，在设计表单的主菜单系统时是否应遵循任何标准？

大多数带菜单系统的Windows应用程序都有您的标准文件| 编辑| 查看| 工具| 帮助菜单。 如何确定任何其他顶级菜单项的位置？

另外，如何确定子菜单项的位置？ 例如，您将遵循哪些规则或原则来确定是否应将项目放在“编辑”，“工具”或您自己的非标准顶级菜单中？

我在这里寻找两件事：

1. 发布的资源（网络或打印）详细说明了这一点（特别是如果它来自Microsoft），或来自UX或UI专业人员的其他资料。
2. 你自己的意见。

基于Gamecat提到功能区的响应，我将把它扩展到功能区。 如何确定显示哪些标签按钮？ 寻找与上述相同的内容。

相关问题： https ： //stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere

Answer 1

微软的Vista用户体验指南位于： http ： //msdn.microsoft.com/en-us/library/aa511258.aspx

菜单特有的内容（包括标准菜单）位于： http ： //msdn.microsoft.com/en-us/library/aa511502.aspx

这包括菜单和菜单项的标准顺序，名称和加速器。

一些一般准则：

文件用于影响用户正在处理的整个内容（通常是文件）或整个应用程序（例如，退出）的命令。 它也是用户选择他们想要处理的表单的好地方。

编辑用于选择内容片段（例如，查找，全选）并对此片段进行操作（复制，删除）。 不要将它用作一般的“更改内容”菜单（例如，“编辑”首选项或宏）。

查看更改内容的外观或表示，同时不更改基础内容本身（例如，用户在表单中输入的内容）。 考虑不在视图菜单项中包含用于控制工具栏的存在（工具栏不是内容）。 这应该是选项/偏好。

虽然它被列为标准，但我会避免使用“工具”菜单。 该名称没有任何意义，内容往往是随机垃圾。 考虑Office功能区使用的名称和组织（例如，选项位于File的等效位置）。 请参见http://blogs.msdn.com/jensenh/archive/2006/01/31/520061.aspx 。

通常将标准菜单项下的特定于应用程序的菜单项放在标准菜单中，以便用户的肌肉记忆不会因标准菜单项而中断。 但是，如果应用程序特定的菜单项是标准菜单项的变体，则将其置于标准菜单项的下方（例如，查找下面的查找或粘贴下面的特殊粘贴）

不要害怕为不适合上述项目的项目创建自己的菜单。 菜单栏通常没有足够的宽度，特别是对于非标准菜单项，会产生微弱的信息气味。 八到十个菜单是完全可以接受的。 只有三个菜单项的菜单是完全可以接受的; 一个有两个菜单项是不可能的。

级联或子菜单很难使用。 改为使用分隔符对菜单项进行分组。 在需要考虑级联菜单之前，菜单可能有~15个项目。 如果你有这么多的菜单项，首先考虑将一些菜单作为一个单独的菜单，而不是菜单中的级联菜单。

在View之后但在菜单栏上的Window或Help之前放置您的应用程序特定菜单。 我强烈建议用户研究（例如，卡片分类）来组织和命名非标准菜单。

仔细查看功能区，您会看到它的组织与菜单栏几乎相同，文件（徽标菜单），编辑（“主页”选项卡，包括格式）和视图等效，因此从从组织的角度来看，无论您使用的是Ribbon还是菜单栏都没什么区别。

菜单栏仍然是大多数应用程序的最佳选择。 功能区并不意味着比传统的菜单栏/工具栏组合更少的点击次数。 不要因为MS正在推动它而跳到功能区。 我在http://www.zuschlogin.com/?p=36上有详细信息。

Answer 2

Microsoft菜单文档：

• Windows用户体验指南：菜单
• Windows用户体验指南：菜单设计概念

Answer 3

是的...菜单的逻辑分组可以帮助您的用户轻松记住事物。 我也不喜欢有一个“工具”菜单并转储不属于其他地方的所有内容......应该有一个像Mac一样的“应用程序菜单”，或者像Office按钮（2010年的Outspace UI），你可以拥有那些“工具”或偏好。

关于按钮订购，请尝试遵循平台约定... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-味道/

Answer 4

不是标准，但您可以使用办公产品作为指导。

顺便说一下，菜单是过去的，现在都是Ribbon。 起初我对这个色带持怀疑态度，但现在我认为这是一个非常好的主意。 （最小化鼠标点击总是一个好主意）。

不错的链接： http ： //blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx

Answer 5

有几种标准可供选择：

• Microsoft的标准指南： http ： //www.amazon.com/review/product/1556156790？pageNumber = 2
• http://msdn.microsoft.com/en-us/library/ms997532.aspx
• http://www.otal.umd.edu/guse/standards.html

Apple在他们的平台上有一个很长的指南：

• 接口指南

Answer 6

Microsoft Ribbon文档：

• Windows用户体验指南：色带

此外，有关不同类型的应用程序应使用哪种类型的界面（菜单栏，色带，工具栏，直接命令等）的文档：

• Windows用户体验指南：程序命令模式

Answer 7

要记住一些事情。

两种标准化方法都是在Web之前的桌面软件中开发和实现的。 这意味着这两个模型都没有考虑到Web上下文。 传统的桌面环境和基于Web的环境之间存在一个很大的区别 - 浏览器的“后退”按钮。

o“取消”也是“返回”的一种方式，“确定”是一种“前进”的方式。 这种“前进/后退”比喻是大多数形式的“取消”和“确定”功能的基础。

以下是这个比喻的一些其他扩展：

• 我们使用可视化来传达复杂的想法。 图形用户界面是一种可视化形式。 我们在西方（更具体地说是美国美国文化）的可视化标准有着悠久的历史

o时间：在我们的标准可视化中，“旧”通常在左侧描绘，“新”在右侧描绘（大多数时间的图形描绘使用这种从左到右的比喻）

o过程：我们在逐步显示渐进式步骤时使用从左到右的比喻：“第一个”在左侧，“第二个”通常显示在右侧。

o写作和阅读：在写作和阅读中，我们“继续”或从左向右“向前”移动（除非我们当然在亚洲）

o电影：电影是另一种可视化形式。 在电影中，一个标准的运动是：如果一个人“走到某个地方”，她会从屏幕的左侧移动到右边。 如果她“回来”，她会从右向左行进

o取消/确定模型可能有助于改善有意识的决策：此模型假定您在决定要采取哪种行动之前想要阅读选项（建议需要用户充分关注并拥有更多内容的重要互动他们可以使用的几个动作。）取消/确定模型首先（左侧）显示“替代”动作...所以你可以在决定“确定”是你真正想要采取的动作之前阅读它们。 确定/取消模型可能使用户习惯于单击他们遇到的第一个选项。 同时，经过训练使用取消/确定模型的用户可以直接选择“确定”按钮，只要他们确信这是他们想要做出的选择。

o操作系统适配：Mozilla的Firefox与显示“确定”和“取消”按钮顺序时使用的操作系统相匹配。 换句话说，按钮的显示适应您的操作系统训练您使用的内容。

这是一个有趣的调查，解决了这个按钮应该在哪个顺序的非常具体的问题： http ： //measuringuserexperience.com/SubmitCancel/index.htm

• DM