在您的应用程序中显示菜单的最佳方法是什么?

时间:2008-11-27 10:27:20

标签: winforms user-interface

您认为在传统WinForms应用程序中向用户提供分层功能列表的最佳方法是什么? (菜单系统 - 假设功能可以分成少量的模块和子模块,但这些子模块没有固定的深度。)

您喜欢传统的下拉菜单系统,色带,停靠工具栏,树视图方法还是其他任何创新想法?

6 个答案:

答案 0 :(得分:2)

您的设计中需要考虑的一件重要事情是Usability vs Discoverability

最佳解决方案在很大程度上取决于您的用户。市中心游客的自助服务终端应用程序的UI要求与发电站控制屏幕的要求非常不同......

答案 1 :(得分:1)

我经常将一个工具条停靠在最常用的功能上。所有其他的东西都是设置热键的下拉菜单。

如果我有一个可以包含不同类型项目的列表,我会使用底部停靠的工具条,根据列表中的选定项目更改其内容。这样我只有与任务相关的按钮/图标,而不是一堆禁用按钮,这会刺激视图。

我还为自动填充项目的上下文菜单添加了与底部工具条相同的选项。这样我就可以更快地找到“动作”,而无需将鼠标移动到屏幕底部。

我真的很讨厌功能区(作为用户)因此我不会在项目中使用它作为程序员。

答案 2 :(得分:1)

在我看来,最好的方法是确保一切都可以通过多种方式完成。

  • 菜单
  • 键盘快捷键
  • 工具箱......

因此用户可以选择它。

我真正希望在更多应用程序中看到的是菜单或选项直接附加到用户正在查看的所选项目(控件)。当然,菜单与给定内容相关。

我已经在我的开源项目Monex中实现了这一点,我真的很喜欢自己使用它。请看这个screenshot

答案 3 :(得分:0)

您可以随时选择逐渐控制色带。 Microsoft / Office界面习惯于成为用户对标准的期望(最终)。

答案 4 :(得分:0)

在我看来,你的问题没有明确的答案。它总是取决于您向用户呈现的菜单以及预期使用该应用程序的用户

具有标准/通用功能的菜单最好呈现为Office样式,意味着下拉菜单或新的功能区样式。   具有自定义功能的菜单,当您声明具有不同深度的多个模块和子模块时,通常最好将其显示为类似TreeView的菜单。

从用户的角度来看,一个典型的用户可以使用标准菜单做得很好,而更高级的用户不会介意更高级的功能,如键盘导航或隐藏/显示菜单或将其停靠在窗户的另一面。

答案 5 :(得分:0)

菜单栏,工具栏和色带用于命令,其中用户对项目的选择作用于窗口中显示的数据对象或整个应用程序。您使用哪一个主要取决于您应用中的命令数量。

  • 仅工具栏:大约20个或更少的命令。为每个命令按钮提供图标和文本标签。用分隔符表示层次结构。不超过两个级别 - 相应地平衡您的层次结构。

  • 带有工具栏的菜单栏:超过20个但少于约1000个命令。单个菜单上最多20个菜单项(使用分隔符)通常比级联菜单更好 - 相应地平整您的层次结构。常用命令应该有加速器。通常将工具栏限制为不超过30个最常用的命令,主要是命令,否则只能从对话框中访问。考虑对具有加速器的菜单项具有工具栏控件 - 一个好的专家访问方式通常就足够了。

  • 功能区:超过1000个命令。功能区仅仅是将不同的菜单栏和工具栏放在不同的选项卡上。为了更好地工作,与每个选项卡相关联的任务(功能层次结构的顶部)应该是非集成的 - 用户很少从一个用户切换到另一个用户。功能区也可以更有效地促进高级功能的发现,代价是可发现性和基本功能的效率。

检查函数层次结构中的项目是否可以更好地表示为属性而不是命令。命令执行一个过程,如打开,查找和复制,而属性更改某些内容的特定特征,如字体,大小和视角。属性由窗口中的字段控件(例如,文本框,复选框和下拉列表)设置,而不是菜单项,工具栏控件或功能区控件。

充满这种字段控件(或数据对象的其他表示)的窗口是内容块。树控件可用于控制显示的内容块。与选项卡控件一样,当用户经常在内容块之间切换并且不比较内容块时,它们优先于多个窗口。当内容量不适合单行选项卡时,树优先于选项卡控件。

树中没有任何空节点。用户点击的任何内容都应该显示完整的内容窗格 - 相应地标注您的层次结构,甚至是使用列表框而不是树的极端。

如果用户倾向于选择一个内容块,在那里完成任务,然后离开您的应用程序,然后考虑显示所有内容块的整页菜单的“主页”页面,可能根据您的层次结构进行空间排列,每个只需点击一下即可访问。