在开发基于 Windows 窗体的应用程序时，在设计窗体的主菜单系统时应遵循哪些标准？
大多数带有菜单系统的 Windows 应用程序都有标准的 File |编辑 |查看 |工具 |帮助菜单。您如何确定任何其他顶级菜单项的位置？
此外，您如何确定子菜单项的位置？例如，您将遵循哪些规则或原则来确定是否应将某个项目放置在“编辑”、“工具”或您自己的非标准顶级菜单中？
我在这里寻找两件事：
根据 Gamecat 提到功能区的回复，我也将其扩展到功能区。您如何确定出现在哪些选项卡按钮上？寻找和上面一样的。
相关问题： https://stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere
【问题讨论】：
标签： .net windows winforms user-interface
是的...菜单的逻辑分组有助于您的用户轻松记住事物。 我也不喜欢有一个“工具”菜单并将不属于其他地方的所有东西都倾倒在这里...... 应该有一个“应用程序菜单”，如 Mac 或 Office 按钮（2010 年的 Outspace UI），您可以在其中拥有这些“工具”或首选项。
关于按钮排序，请尝试遵循平台约定... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/
【讨论】：
需要记住的一些事项。
这两种标准化方法都是在网络出现之前在桌面软件中开发和实施的。这意味着这两个模型的设计都没有考虑到 Web 上下文。传统桌面环境和基于 Web 的环境之间有一个很大的区别——浏览器的“返回”按钮。
o “取消”也是“返回”的一种方式，“确定”是一种“前进”的方式。这种“前进/后退”隐喻是大多数形式的“取消”和“确定”功能的基础。
下面是这个比喻的一些其他扩展：
o 时间：在我们的标准可视化中，“旧”通常描绘在左侧，“新”描绘在右侧（大多数时间的图形描绘都使用这种从左到右的比喻）
o 过程：我们在可视化渐进步骤时使用从左到右的比喻：“第一”在左侧，“第二”通常显示在右侧。
o 写作和阅读：在写作和阅读中，我们从左到右“继续”或“前进”（当然，除非我们在亚洲）
o 在电影中：电影是另一种可视化形式。在电影中，运动的标准是：如果一个人“要去某个地方”，她就会从屏幕的左侧移动到右侧。如果她要“返回”，她会从右向左移动
o 取消/确定模型可能有助于改进有意识的决策：此模型假设您想在决定要采取的行动之前阅读选项（建议在需要用户全神贯注的重要交互上并且有多个可用的操作。）取消/确定模型首先呈现“替代”操作（在左侧）......因此您可以在确定“确定”是您真正想要采取的操作之前阅读它们. OK/Cancel 模型可能会让用户养成点击他们遇到的第一个选项的习惯。同时，接受过使用取消/确定模型培训的用户只要确定这是他们想要做出的选择，就可以直接点击“确定”按钮。
o 操作系统适配：Mozilla 的 Firefox 与显示“确定”和“取消”按钮的顺序时使用的操作系统匹配。换句话说，按钮的显示会适应您的操作系统训练您使用的内容。
这是一个有趣的调查，它解决了这个按钮应该按什么顺序的非常具体的问题： http://measuringuserexperience.com/SubmitCancel/index.htm
【讨论】：
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 个项目。如果您有这么多菜单项，请首先考虑将一些菜单项拆分为单独的菜单，而不是菜单中的级联菜单。
将您的应用程序特定菜单放置在菜单栏上的 View 之后但 Window 或 Help 之前。 我强烈建议进行用户研究（例如卡片分类）来组织和命名非标准菜单。
仔细观察功能区，您会发现它的组织方式与菜单栏几乎相同，具有文件（徽标菜单）、编辑（“主页”选项卡，包括格式设置）和视图的等价物，因此，从组织的角度来看，您使用的是功能区还是菜单栏几乎没有什么区别。
菜单栏仍然是大多数应用程序的最佳选择。功能区并不意味着比传统的菜单栏/工具栏组合更少的点击次数。不要仅仅因为 MS 正在推动它而跳到功能区。我在http://www.zuschlogin.com/?p=36 有详细信息。
【讨论】：
Microsoft 功能区文档：
此外，关于应为不同类型的应用程序使用哪种类型的界面（菜单栏、功能区、工具栏、直接命令等）的文档：
【讨论】：
【讨论】：
不是标准，但您可以使用办公产品作为指导。
顺便说一句，菜单是过去的，现在都是 Ribbon。起初我对丝带持怀疑态度，但现在我认为这是一个非常好的主意。 （尽量减少鼠标点击总是一个好主意）。
不错的链接：http://blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx
【讨论】：