转自:http://blog.csdn.net/sirdonker/article/details/5684702
菜单设计指南
一个菜单包含着一系列命令(用户行为),这些命令,同时,通常也可以通过按钮、按键或者触屏滑动手指来执行。 菜单命令,可以执行某项操作,或者导航到你应用的其它部分,甚至其它的应用去。 菜单,可以把本来放在界面上的按钮之类的命令或者导航隐藏起来,从而可以为你应用节省屏幕上的空间。
Android系统提供了两种菜单形式。你可以用它们来提供功能或者导航。 简单来说:
- OptionsMenu包含影响当前Activity的、全局的功能,或者会启动另一个相关的Activity。 用户一般可以通过MENU键来调出这类菜单。
- ContextMenu包含了另一些只对当前选择的界面元素的功能。一般来说,这类菜单是通过长按某界面元素触发的。 与OptionsMenu一样,菜单中的命令可以运行在当前Activity,也可以是运行在其它Activity。
只有最最简单应用才不需要菜单。 系统会自动展示和收起菜单,而且提供了用户访问菜单的标准方法。(MENU键和长按)。 这套访问菜单的方式,在所有的应用中都是一致的。从而使用户可以用这种通用的方式使用各个应用。 所有的菜单都是“浮”在当前Activity上面的,而且比全屏尺寸要小。这样,即使弹出了菜单,应用仍然是可见的。 菜单项一旦被点击,菜单就会消失。
下面,让我们开始对菜单系统的概览。
菜单概览
提示 - 你的设备上的菜单和屏幕可能和下面的图不一样:这可能是因为Android版本不同的原因,或者设备原因。
OptionsMenu
OptionsMenu中包含的命令,应该是影响整个当前Activity的,或者能启动其它Activity的。 它们不应影响当前选中的项。(ContextMenu才是干这个的。)
在大多数机器上,用户按了MENU键之后,OptionsMenu就会出现在屏幕下方。 用户可以通过再按MENU,或者按BACK来关掉菜单。 (实际上,任何菜单,都可以通过再按MENU键、按BACK键或者单击屏幕上菜单外面的区域来来关掉。) 再次提醒,调出这个菜单的方式,可能会因为设备不同而变化。
每个Activity 都会有一系列操作,从而有一个OptionsMenu。一个多Activity的应用,每个Activity都可能会有不同的OptionsMenu。
例如,一个Email应用中,消息列表Activity,OptionsMenu可能会提供搜索、写信、刷新或者改变Email设置等操作。 写信Activity可能会有不同的OptionsMenu,包括抄送、增加附件或者取消邮件等。
- 带图标的OptionsMenu - 用户按了MENU键之后,系统会在屏幕下方弹出一个不能卷动的带图标的格子。 (在G1上,会显示6个格子。)
- 扩展的OptionsMenu - 要是Activity有更多的菜单项,不能全放到格子里去,格子的最后一个图标会变成“更多”。 选“更多”之后,会弹出一个可卷动的菜单项列表。这个列表包含了剩下的菜单项。
![](http://hi.csdn.net/attachment/201006/21/0_1277121413ZzOS.gif)
在某些Android手机中,用户可以通过长按MENU键来看OptionsMenu的快捷键(如果有的话)。 在带图标的OptionMenu格子中,菜单项文字和快捷键文字会交替显示。
ContextMenu
ContextMenu有点像桌面系统的右键弹出菜单。 通常,ContextMenu是作为快捷方式存在的。也就是说,ContextMenu提供的命令,在其它地方也能找到。
用户在界面某个位置长按,就能调出ContextMenu(如果有的话)。如下图所示。 ContextMenu是一个菜单项(命令)的列表,这些命令都是用来操作被长按的内容的。 这个菜单项,也可以是为当前Activity服务的,或者是要把长按的内容通过 intent 传给下一个Activity。
例如,在Email列表中,用户长按一封邮件,于是可以通过弹出的ContextMenu来读、存档或者删除邮件。
用户也可能通过长按屏幕上的位置(而不是某个确定的内容)来调出ContextMenu。 一个例子是,当用户在主屏上的空白位置长按时,会弹出一个ContextMenu:用户可以在主屏上新建应用的快捷方式。
![](http://hi.csdn.net/attachment/201006/21/0_1277121449SDed.gif)
ContextMenu是一种快捷方式。
在上面的例子中,用户长按联系人“欧比旺·肯诺比”,就会弹出一个ContextMenu。 这个菜单提供了所有的能对这个联系人进行操作的命令。
如果短按这个联系人的话,就是进入“联系人资料”界面 — 这个是最符合第一直觉的短按结果。 我们建议,这个第一直觉操作,同样应该被排在长按出来的ContextMenu的第一位。 在这个例子中,点击“欧比旺·肯诺比”的操作,和长按ContextMenu中“看资料”菜单项,产生的效果是一样的。
再次提醒注意,像以下截屏所展示的一样,ContextMenu以及单击进入的下一屏,拥有同样的对这个联系人操作的命令。 ContextMenu所提供的命令,在“联系人资料”界面的OptionsMenu中都可以找到。
正式由于这种重复,ContextMenu才被认为是一种快捷方式,从而即使不进入下一个界面也能进行操作。 ContextMenu比屏幕上的按钮或者OptionsMenu更不容易被发现。 大部分用户都发现不了,或者根本不用ContextMenu。 由于这个原因,大部分情况下,任何在ContextMenu中的命令都应该能在单击之后的符合人直觉的下一个屏幕中被找到。 在下一节我们会提到,文字操作,例如“选中文字”,可能仅仅出现在ContextMenu中。 另外,富应用,像能够运行web应用的浏览器,可能有一些命令仅仅存在于ContextMenu中而不会在其它地方。
![](http://hi.csdn.net/attachment/201006/21/0_1277121480IK51.gif)
ContextMenu中的文字操作
链接、文字区域都有系统提供的一些所有应用通用的文字操作。包括“全选”、“选中文字”、“全部复制”、“添加到字典”等。 如果文字区域是可编辑的,还会有其它的菜单项,如“全剪切”、“输入法”;如果有剪切板中有文字的话,还会有“粘贴”。 系统会自动调整文本ContextMenu中的菜单项。文本ContextMenu如下图所示。
![](http://hi.csdn.net/attachment/201006/21/0_1277121503CjkJ.gif)
OptionsMenu和ContextMenu的比较
OptionsMenu持有的命令是涉及全局的,而ContextMenu持有的命令只针对当前选定的内容。 如下图所示,用户调出菜单,然后点击菜单项来执行动作或者打开对话框。
![](http://hi.csdn.net/attachment/201006/21/0_12771215272ZL5.gif)
关于菜单的更多详细资料,参见 Creating Menus.
Activity屏幕上的固有命令
命令也可以直接放到屏幕上,例如文字按钮、图形按钮或者列表项之类。 这种方式,可以让命令更容易被用户发现 — 用户无需进行任何操作就能在屏幕上看到它们。 更容易被看到,意味着会占更多的屏幕空间。这一点需要权衡。
指南
选择正确类型的菜单,并且正确地使用它们,是设计好的应用的关键因素。 接下来的指南,应该能够指导用户体验设计和应用开发人员。
区分只对选中内容起作用的命令和全局命令。
把影响当前Activity的命令,放到OptionsMenu里,或者直接放到屏幕上;把针对当前选定内容的命令,放到ContextMenu里。 (两种菜单上的命令,都可以运行在本Activity执行动作或者启动另一个Activity。)
你可以通过问自己“这个命令操作什么”来判断使用何种菜单: 如果这个命令针对或者设计当前选中项(或者是屏幕上的位置),这个命令就应该放到ContextMenu里。 否则,就放到OptionsMenu里去。 两种命令是被系统强制区别的。 当你按下MENU的时候,选中的内容就会变成没被选中,所以也就没办法对它进行操作。 (触屏没焦点,AndroidSDK在其它文档里也提出无论设备有没有方向键,也不应该考虑焦点问题。) 关于这一点的详细解释,参见博文: Touch mode.
一个针对选中项的ContextMenu的例子。当用户长按一个通讯录中一个人名时,弹出的ContextMenu中有 “查看资料”、“打电话”和“编辑联系人”。
把最常用的操作放到前面。
由于屏幕高度有限,一些菜单必须是可卷动的。 所以,把最重要的命令放到无需卷动就能看到的位置是很重要的。 对于OptionsMenu,把最常用的操作放到带图标的OptionMenu去, 然后用户可以选择“更多”来看到剩下的菜单项。 而且,一般来说,把同样的命令放到同样的位置。例如,在不同的Activity中,搜索几乎总是在OptionsMenu第一个。
在ContextMenu中,最符合直觉的命令应该是第一个,然后越往下越不常用,最少用到的命令放在底下。
不要把命令仅仅放在ContextMenu里。
正确的设计是,用户完全不用ContextMenu就可以使用整个应用。 一般来说,如果你的应用有一部分是只能通过ContextMenu来使用的,那么你就需要把这些命令复制到菜单外面了。
在打开一个ContextMenu之前,没有可视的标识说明这个位置有弹出菜单。(OptionsMenu有MENU键,而ContextMenu没有。)ContextMenu不容易被发现。 因此,一般来说,ContextMenu中包含的命令,应该是其它位置放置的命令的拷贝。 例如,虽然可以通过长按联系人名字的弹出菜单中选择打电话,用户同样可以在联系人详情中通过单击电话号码来打电话。 参考shortcut。
ContextMenu中的第一个命令应该是单击后最符合直觉的那一个操作。
如同本文shortcut中所说, 单击一个元素,应该跟长按此元素出现的ContextMenu中第一位菜单项的操作一致。 两者都应该是最符合第一直觉的操作。
点击一个列表项之类执行的操作应该是符合直觉的。
在你的应用中,当用户点击了任何可以互动的文本(链接或者列表项)或者图片(图标之类),执行的操作应该是用户所想象中的操作。
一些首选操作的例子:
- 点击一个图片,执行“看图”。
- 点击一个媒体图标或者媒体文件名,执行“播放”。
- 点击一个URL链接,执行“打开链接”。
- 单击一个地址,执行“到此处”(运行一个地图应用)。
注意,在不同的上下文中,选择同样的元素,首选操作可以是不一样的:
- 在联系人应用中,点击一个联系人,执行“查看资料”。
- 在即时通信应用中,点击一个联系人,执行“开始聊天”。
- 在Email应用中,从通讯录中选择联系人为收信人时,在通讯录中点击联系人,执行“添加到收信人”操作。
ContextMenu应该标识出被选中的内容。
当用户长按一个元素之后,弹出的ContextMenu应该包括被选中项的名字。 因此,当创建一个ContextMenu的时候,要确保这个菜单包含一个标题以及被选项的名字。这样用户才能明确地知道自己选中了哪个。 例如,如果用户选中了一个联系人“圣女贞德”,那么就要 (通过setHeaderTitle
) 把名字放到菜单的标题中。并且,编辑命令也应该是“编辑联系人”而不是“编辑”。
只把最重要的命令直接放到屏幕上。
通过把命令放到菜单里,你的屏幕上就能有更多的空间来放置其它内容。 另一方面,把命令直接放到屏幕上,会让这些命令更明显,更容易被用到。
下面一些,是把命令直接放到界面上的最主要的一些原因:
- 为了让一个命令足够明显,保证这个命令不会被忽略。
例如:在线商店的“付款”按钮。 - 当对这个命令的快捷访问很重要,并且如果通过菜单访问会显得很慢的时候。
例如:看图应用的上一张/下一张,或者放大/缩小按钮。 - 当操作进行中,并且需要确切的“完成”时。
例如:切图Activity的保存/放弃按钮。 - 对话或者向导。
例如:确认/取消按钮。 - 为了直接的控制。 例如:在主屏上拖动图标到垃圾箱。(拖动本身是命令的一种。)
格子里带图标的OptionsMenu中,菜单项名字要短。
如果在带图标的OptionsMenu中,文字过长的话,系统会把文字截短。 因此,“Create Notification”会被截短成“Create…ication”一类的东西。 你无法控制这种截短,所以最好还是让文字短一些。 在某些版本的Android中,当图标由于方向键或者轨迹球获得焦点而高亮的时候,图标的描述文字可能会被展开并卷动。
对话框不应该有OptionsMenu
当一个对话框显示的时候,MENU键应该是不起作用的。 对于看起来像对话框的Activity也是这样。 这里对话框的定义是,尺寸比全屏要小,有零到三个按钮,不可卷动,可能有一个可选择的列表或者包括单选或者多选框。 (凡是看起来是对话框的,都是对话框,并不局限于Dialog类。)
不为对话框提供菜单的原因是,此时,用户是处于一个过程的中间,不应该提供一个可以开始新的全局任务位置。 (OptionsMenu就是干这个的。)
如果Activity没有OptionsMenu,也不要用一个消息提示。
当用户按MENU键,如果没有OptionsMenu的话,系统默认动作是什么事都不做。强烈建议你也不要在这种情况下为MENU提供其它的动作(例如显示一条消息)。 这对维持用户在不同应用之间的一贯体验有好处。
把不可用的菜单项置灰或者隐藏。
一些菜单项的动作在某些时候可能会不起作用 — 例如,浏览器的“前进”按钮,在使用“后退”键之前,都是没用的。 建议:
- 在OptionsMenu - 置灰不可用的菜单项。 在格子菜单和“更多”菜单中都是如此。 It would be disorienting for the icon menu to change from 6 items to 5 items, and we treat the "More" menu the same way.
- 在ContextMenu - 隐藏不可用菜单项。 这可以使菜单更短,只展示给用户可用的选择。(同时也避免了菜单卷动。)