Android SDK 2.1 - Dev Guide - Best Practives - UI Guidelines - Menu Design - 中文/Chinese

转自：http://blog.csdn.net/sirdonker/article/details/5684702

菜单设计指南

菜单设计quickview

• OptionsMenu是为了放对当前Activity的整体起作用的命令的。
• ContextMenu是为了放对当前选择项起作用的命令的。
• 把最常用的操作排到菜单前面。
• 只把最最重要的命令放到屏幕上（而不是菜单里）。
• 长按某界面元素弹出来的ContextMenu中的命令，应该能从短按它进入到的新Activity中找到普通的按钮或者OptionsMenu。

In this document

1. 菜单概览
   1. OptionsMenu
   2. ContextMenu
   3. OptionsMenu和ContextMenu的比较
   4. Activity界面中的固有命令
2. 指南
   1. 区分特定和全局命令。
   2. 把最常用的放前面。
   3. 不要把某个命令只放到ContextMenu中。ContextMenu中的第一个命令应该符合人的第一直觉。点击某元素引起的操作应该符合人的直觉。
   4. ContextMenu应该只影响选中的项。只把最重要的命令放到屏幕上。
   5. 在带图标的OptionsMenu中，菜单项名字不要太长。
   6. Dialog不应该有OptionsMenu。
   7. 如果没有OptionsMenu，也不要处理Menu键事件。
   8. 让不可用的菜单项变灰或者隐藏起来。

See also

1. Touch mode
2. Activity and Task Design

一个菜单包含着一系列命令（用户行为），这些命令，同时，通常也可以通过按钮、按键或者触屏滑动手指来执行。 菜单命令，可以执行某项操作，或者导航到你应用的其它部分，甚至其它的应用去。 菜单，可以把本来放在界面上的按钮之类的命令或者导航隐藏起来，从而可以为你应用节省屏幕上的空间。

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可以有大量的菜单项。它有以下两个阶段：

• 带图标的OptionsMenu - 用户按了MENU键之后，系统会在屏幕下方弹出一个不能卷动的带图标的格子。 （在G1上，会显示6个格子。）
• 扩展的OptionsMenu - 要是Activity有更多的菜单项，不能全放到格子里去，格子的最后一个图标会变成“更多”。 选“更多”之后，会弹出一个可卷动的菜单项列表。这个列表包含了剩下的菜单项。

在某些Android手机中，用户可以通过长按MENU键来看OptionsMenu的快捷键（如果有的话）。 在带图标的OptionMenu格子中，菜单项文字和快捷键文字会交替显示。

ContextMenu

ContextMenu有点像桌面系统的右键弹出菜单。 通常，ContextMenu是作为快捷方式存在的。也就是说，ContextMenu提供的命令，在其它地方也能找到。

用户在界面某个位置长按，就能调出ContextMenu（如果有的话）。如下图所示。 ContextMenu是一个菜单项（命令）的列表，这些命令都是用来操作被长按的内容的。 这个菜单项，也可以是为当前Activity服务的，或者是要把长按的内容通过intent 传给下一个Activity。

例如，在Email列表中，用户长按一封邮件，于是可以通过弹出的ContextMenu来读、存档或者删除邮件。

用户也可能通过长按屏幕上的位置（而不是某个确定的内容）来调出ContextMenu。 一个例子是，当用户在主屏上的空白位置长按时，会弹出一个ContextMenu：用户可以在主屏上新建应用的快捷方式。

ContextMenu是一种快捷方式。

在上面的例子中，用户长按联系人“欧比旺·肯诺比”，就会弹出一个ContextMenu。 这个菜单提供了所有的能对这个联系人进行操作的命令。

如果短按这个联系人的话，就是进入“联系人资料”界面 — 这个是最符合第一直觉的短按结果。 我们建议，这个第一直觉操作，同样应该被排在长按出来的ContextMenu的第一位。 在这个例子中，点击“欧比旺·肯诺比”的操作，和长按ContextMenu中“看资料”菜单项，产生的效果是一样的。

再次提醒注意，像以下截屏所展示的一样，ContextMenu以及单击进入的下一屏，拥有同样的对这个联系人操作的命令。 ContextMenu所提供的命令，在“联系人资料”界面的OptionsMenu中都可以找到。

正式由于这种重复，ContextMenu才被认为是一种快捷方式，从而即使不进入下一个界面也能进行操作。 ContextMenu比屏幕上的按钮或者OptionsMenu更不容易被发现。 大部分用户都发现不了，或者根本不用ContextMenu。 由于这个原因，大部分情况下，任何在ContextMenu中的命令都应该能在单击之后的符合人直觉的下一个屏幕中被找到。 在下一节我们会提到，文字操作，例如“选中文字”，可能仅仅出现在ContextMenu中。 另外，富应用，像能够运行web应用的浏览器，可能有一些命令仅仅存在于ContextMenu中而不会在其它地方。

ContextMenu中的文字操作

链接、文字区域都有系统提供的一些所有应用通用的文字操作。包括“全选”、“选中文字”、“全部复制”、“添加到字典”等。 如果文字区域是可编辑的，还会有其它的菜单项，如“全剪切”、“输入法”；如果有剪切板中有文字的话，还会有“粘贴”。 系统会自动调整文本ContextMenu中的菜单项。文本ContextMenu如下图所示。

OptionsMenu和ContextMenu的比较

OptionsMenu持有的命令是涉及全局的，而ContextMenu持有的命令只针对当前选定的内容。 如下图所示，用户调出菜单，然后点击菜单项来执行动作或者打开对话框。

关于菜单的更多详细资料，参见 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 - 隐藏不可用菜单项。 这可以使菜单更短，只展示给用户可用的选择。（同时也避免了菜单卷动。）