在开发基于Windows窗体的应用程序时，在设计窗体的主菜单系统时，有什么标准应该遵循吗？
大多数带有菜单系统的windows应用程序都有标准的"文件"|"编辑"|"视图"|"工具"|"帮助"菜单。如何确定任何其他顶级菜单项的位置？
此外，如何确定子菜单项的位置？例如，您将遵循哪些规则或原则来确定项目是否应放置在"编辑"、"工具"或您自己的非标准顶级菜单中？
我在这里找两样东西：
- 详细说明这一点的已发布资源（网络或印刷品）（尤其是来自微软的），或来自用户体验或用户界面专业人士的其他材料
- 你自己的意见
根据Gamecat提到Ribbon的回应，我也将把它扩展到Ribbon。如何确定哪些选项卡按钮显示在？正在查找与上面相同的内容。
相关问题：https://stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere
Microsoft的Vista用户体验指南位于：http://msdn.microsoft.com/en-us/library/aa511258.aspx
菜单（包括标准菜单）的特定内容位于：http://msdn.microsoft.com/en-us/library/aa511502.aspx
这包括菜单和菜单项的标准顺序、它们的名称以及它们的快捷键。
一些通用指南：
文件用于影响用户正在处理的整个内容（通常是一个文件）或整个应用程序（例如，退出）的命令。对于用户来说，这也是一个选择他们想要处理的表单的好地方
编辑用于选择内容片段（例如，查找、全选），并对这些片段执行操作（复制、删除）。不要将其用作一般的"更改某些内容"菜单（例如，用于"编辑"首选项或宏）。
View更改内容的外观或呈现方式，而不更改基础内容本身（例如，用户在表单中输入的内容）。考虑而不是包含在"视图"菜单项中以控制工具栏的存在（工具栏不是内容）。这确实应该与选项/首选项有关。
虽然它被列为标准，但我会避免使用"工具"菜单。这个名字没有任何意义，内容往往是随意的垃圾。考虑Office功能区使用的名称和组织（例如，"选项"位于"文件"的等效项下）。看见http://blogs.msdn.com/jensenh/archive/2006/01/31/520061.aspx.
通常将特定于应用程序的菜单项放置在标准菜单中的标准菜单项之下，这样用户的肌肉记忆就不会因标准菜单项而中断。但是，如果应用程序特定的菜单项是标准菜单项的变体，则将其直接放置在标准菜单项下方（例如，在"查找"下方的"查找下一个"或在"粘贴"下方的特殊粘贴）
不要害怕为不符合上述条件的项目创建自己的菜单。菜单栏通常没有足够的广度，产生了微弱的信息气味，尤其是对于非标准菜单项。八到十个菜单是完全可以接受的。只有三个菜单项的菜单是完全可以接受的；有两个菜单项的一个也不是不可能的。
级联菜单或子菜单很难使用。改为使用分隔符对菜单项进行分组。在考虑级联菜单之前，菜单可能有大约15个项目。如果你有这么多菜单项，首先考虑将一些菜单项分解为一个单独的菜单，而不是菜单中的级联菜单。
将应用程序特定的菜单放在菜单栏上的"视图"之后，但放在"窗口"或"帮助"之前。我强烈建议用户研究（例如卡片排序）来组织和命名非标准菜单。
仔细观察Ribbon，你会发现它的组织结构与菜单栏几乎相同，具有"文件"（徽标菜单）、"编辑"（"主页"选项卡，包括格式设置）和"视图"等功能，因此从组织角度来看，无论使用Ribbon还是菜单栏，都没有什么区别。
菜单栏仍然是大多数应用程序的最佳选择。功能区并不意味着比传统的菜单栏/工具栏组合少点击。不要因为MS在推动功能区就跳到功能区。我在http://www.zuschlogin.com/?p=36。
Microsoft菜单文档：
- Windows用户体验指南：菜单
- Windows用户体验指南：菜单设计概念
这不是一个标准，但您可以使用办公产品作为指导原则。
顺便说一句，菜单是过去的，现在都是Ribbon。起初我对缎带持怀疑态度，但现在我认为这是一个非常好的主意。（尽量减少鼠标点击总是一个好主意）。
不错的链接：http://blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx
有几种可用的标准：
- 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
苹果在其平台上有一个很长的指南：
- 接口指南
Microsoft功能区文档：
- Windows用户体验指南：Ribbons
此外，关于不同类型的应用程序应使用何种类型的界面（菜单栏、功能区、工具栏、直接命令等）的文档：
- Windows用户体验指南：程序命令模式
需要记住的一些事情。
这两种标准化方法都是在网络出现之前在桌面软件中开发和实现的。这意味着这两个模型在设计时都没有考虑到网络环境。传统的桌面环境和基于网络的环境有一个很大的区别——浏览器的"后退"按钮。
o"取消"也是一种"返回"的方式，"确定"是一种"前进"的方式。这种"向前/向后"的比喻是大多数形式的"取消"one_answers"确定"函数的基础。
以下是这个比喻的一些其他扩展：
- 我们使用可视化来传达复杂的想法。图形用户界面是可视化的一种形式。我们在西方（尤其是美国文化）有着丰富的可视化标准历史
o时间：在我们的标准可视化中，"旧"通常描绘在左边，"新"描绘在右边（大多数时间的图形描绘都使用这种从左到右的比喻）
o过程：我们在可视化渐进步骤时使用从左到右的比喻："第一"在左边，"第二"通常显示在右边。
o写作和阅读：在写作和阅读中，我们从左到右"继续"或"前进"（当然，除非我们在亚洲）
o在电影中：电影是另一种视觉形式。在电影中，动作的标准是：如果一个人"要去某个地方"，她会从屏幕的左侧向右移动。如果她要"回去"，她会从右向左移动
o取消/确定模式可能有助于改善有意识的决策：该模式假设你想在决定要采取的行动之前阅读选项（对于需要用户充分关注并有多个行动的重要互动，建议使用）。)"取消/确定"模型首先显示了"替代"操作（在左侧）…因此，在决定"确定"是您真正想要采取的操作之前，您可以先阅读这些操作。确定/取消模式可能会让用户养成点击他们遇到的第一个选项的习惯。同时，接受过使用"取消/确定"模式培训的用户可以直接点击"确定"按钮，只要他们相当确定这是他们想要做出的选择。
o操作系统调整：Mozilla的Firefox在显示"确定"one_answers"取消"按钮的顺序时与所使用的操作系统相匹配。换句话说，按钮的显示会根据操作系统训练您使用的内容进行调整。
这是一项有趣的调查，它解决了这个非常具体的问题，即这些按钮应该按哪个顺序排列：http://measuringuserexperience.com/SubmitCancel/index.htm
- DM
是。。。菜单的逻辑分组有助于用户轻松记忆。我也不喜欢有"工具"菜单，把不属于其他地方的东西都倒在这里。。。应该有一个像Mac或Office按钮（2010年的Outspace UI）一样的"应用程序菜单"，你可以在那里使用这些"工具"或首选项。
关于按钮排序，请尝试遵循平台惯例。。。http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/