android4.0界面设计：式样 的第二部分翻译，因为这部分实在是太长了，我把它划分成了好几部分。。。。。

Back（返回）和Up（上一级）按钮的导航

一致的导航是用户体验不可或缺的组成部分。一些与用户行为不一致或者出乎用户意料的操作，会让用户感到沮丧。Android3.0一个重要的改变就是引入了总体导航。遵循“返回”和“上一级”的设计原则，将使你的应用导航更加符合用户的预期。

Android2.3以及更早的系统依赖于系统的back按钮。Android3.0引入了一个新的导航机制：up按钮，up按钮由一个应用程序图标和一个向左的符号组成。

Up vs. Back

Up按钮用来在不同层次的视图间导航。举例来说，如果视图A显示一个数据列表，用户选择其中一个数据进入详细视图B，那么视图B应当支持up按钮，通过up按钮可以返回到视图A。

如果当前视图是最顶层视图，那么不应该出现up按钮（因为没有上一级）。

系统的back按钮则是以时间倒序的形式来导航的。所以它通常基于视图之间的时间关系，而不是应用程序的层次结构。

当你上一个浏览的视图是当前视图的上层视图时，按下back按钮跟按下up按钮的结果是一样的---你都会返回到上层视图。Up按钮可以保证用户停留在你的应用程序中，而back按钮则可以让用户返回到主视图，甚至返回到其它的应用程序。

Back按钮还支持一些其它的非绑定视图的导航：

1. 关闭浮动窗口（对话框，弹出菜单等）

2. 关闭上下文动作栏，取消已选择项的高亮效果。

3. 隐藏屏幕软键盘。

 

     Navigation Within Your App 应用内导航

Navigating to screens with multiple entry points 视图导航的多个入口

有时候一个视图在应用的层次结构中并没有一个严格的位置，它可以从多个导航的入口到达。比如设置页面，用户可以从应用的其它任何页面跳转到设置页面。在这种情况下，up按钮应该跟back按钮的操作一样，都是回到上一个页面。

Changing view within a screen 在一个屏幕内改变视图内容

不通过up或back按钮来改变视图内容：屏幕还是在应用层次的相同位置，并且没有产生新的导航操作。（译者注：这里的意思是在同一个视图内，不通过导航来改变视图的内容，一个明显的例子就是刷新，通过刷新操作，视图内的内容更新了，但是视图并没有改变，也没有产生导航行为）

这样的例子有如下几个：

通过标签或者左右滑动来切换视图内容；

下拉切换视图内容；

过滤列表；

排序列表；

改变显示特征（比如放大）

 

Navigating between sibling screens 同级视图之间的导航

当你的应用支持从列表页到详细页面的导航时，用户常常希望能够通过导航在详细页面的同级视图之间切换。例如在Gmail里，用户很容易在相同的收件箱中，通过左右滑动来查看更新的或者旧的邮件。当这样来在同一视图内改变视图内容时，back和up导航并不发生改变

然而有一个特例，就是浏览的详细视图之间不存在对应列表中的关联。比如，当你浏览应用商店时，同一个开发者开发的应用，或者同一个艺术家的专辑。在这些情况下，back按钮遵循时间倒序来操作，up按钮则应该避开这些相关的视图并导航到上一级视图。

你完全可以基于你对详情视图的了解， 使up导航的操作行为更聪明便捷。扩展上面提到的应用商店的例子，假设用户可以通过左右滑动从浏览的图书细节视图直接导航到电影细节视图，在这种情况下，up按钮应当可以返回到电影分类视图，即便用户却从来没打开过这个视图。

   Navigation into Your App via Home Screen Widgets and Notifications

通过手机主界面的控件和通知来导航到你的应用

你可以使用手机主界面的控件或者通知来使用户直接导航到你的应用的特定界面，而无需通过层层导航。比如Gmail的收件箱小部件和新消息通知，既绕过了收件箱主页面，又可以让用户直接看到想要的信息。

对于上面的两种情况，up按钮的处理如下：

如果目的视图是从一个特定视图导航过来的，up按钮应该导航到该视图。

否则，应该导航到应用的最顶层视图。

对于back按钮，可以通过往任务返回栈中插入最顶层视图来使导航更加可预见。这样即便用户已经忘记了如何进入的应用，也可以在退出前导航到最顶层视图。

举例来说，Gmail的主界面控件有一个按钮，点击后用户会进入gmail的邮件细节界面。邮件细节界面的Up或者back按钮应该导航用户到收件箱，而收件箱页面的back按钮应该导航用户到主界面。

Indirect notifications 间接通知

当你的应用需要同时展示多个事件的信息时，你可以使用通知，导航用户到一个中间界面。这个中间界面会陈列这些事件，并提供一个深入到每个事件的导航。这样的通知形式，我们叫做间接通知。

 

不同于标准（直接）通知，当用户在间接通知的中间界面点击back按钮后，将会返回引发消息的页面。一旦用户通过中间界面进入了应用后，up和back按钮则执行标准操作：在应用内导航，而不会跳转到中间界面。

例如，假设用户在Gmail中收到一个日历的间接通知。点击这个通知打开中间界面，它将会有几种不同的情况：点击back按钮返回到Gmail，点击特定的按钮退出中间界面或者进入到日历应用的细节页面。

 

 

Pop-up notifications 弹出式通知

 

弹出式通知绕过通知栏，直接出现在用户面前。它很少被使用，除非有必要中断用户的体验。例如，使用弹出式通知来提醒用户好友的视频邀请，因为这个邀请在几秒钟后会自动失效。

就导航行为而言，弹出通知后紧跟着一个间接通知的中间界面。Back按钮可以忽略弹出通知。如果用户从弹出式通知导航到应用内部，那up和back按钮应该遵循标准通知的规则，在应用内导航。

 

Navigation Between Apps 应用间导航

 

Android系统的一个优点是能够在应用程序之间导航。例如，一个应用程序需要捕捉一张照片，则可以激活摄像机应用程序，然后把拍摄的照片返回给这个应用程序。这是一个巨大的双赢行为，既可以让开发者使用其他应用的功能，又可以让用户对公共的行为有一致的体验。

了解应用间的导航，重要的是要了解下面所说的android框架行为。

 

Activities, tasks, and intents 活动、任务和意图

在android系统中,活动是一个应用程序组件,该组件定义了一个屏幕上的信息和所有相关的用户可以执行的行动。应用程序是一个活动的集合,包括所有你创建的活动和那些你从其他应用程序重用的活动。

任务是用户遵循一个目标活动的序列。一个任务可以利用来自一个应用程序的活动,或者利用来自多个不同的应用程序的活动。

 

意图是一种机制,用于从一个应用到另一个应用。一个应用程序的活动可以指示哪些意图他们可以回应。对于常见的意图如“共享”,用户可以有许多应用程序满足该请求。

 

示例:应用程序间导航支持共享

理解活动、任务和意图如何一起工作,考虑一个应用程序如何允许用户分享另一个应用的内容。

例如,从主界面启动Google应用商店开始新任务A(见下图)。在浏览应用商店并进入到图书细节界面后,用户仍然在相同的任务中,只是通过添加活动来扩展了它。触发共享动作后,弹出一个对话框提示用户的每个活动(从不同的应用程序)。

当用户选择通过Gmail来共享时，Gmail的活动作为任务A的一部分被添加进来----没有新的任务被创建。如果Gmail有自己的任务在后台运行，它也不会受到影响。

从分享界面点击发送或者返回按钮，将会回到图书细节界面。然后再点击返回按钮则会继续在Google应用商店内导航，直至导航到应用商店主页面。

然而有时候，用户希望在分享界面点击up按钮后能够继续停留在Gmail里。这是Gmail应该为这个需求新建一个任务B。从任务B的界面点击back按钮后会返回到Gmail的主界面。

任务A会继续在后台运行，用户稍后可能会返回到任务A（比如通过最近浏览界面）。如果Gmail已经有一个运行在后台的任务，那么这个任务将取代任务B----而之前B任务所在的上下文将会被抛弃。

 

 

Action Bar  动作栏

 

动作栏可以说是android应用程序最重要的组成元素。它显示在每个界面的上方，一般存在于整个应用程序的始终。

动作栏的主要目的在于：

用突出的，易用的，可预测的方式作出重要的操作（比如添加新条目或者搜索等等）

保证应用内一致的导航和视图切换

通过提供操作的overflow来减少很少用到的操作，以避免混乱无章。

提供一个专门的空间，来给用户一个身份验证。（译者注：登录系统）

 

如果你刚开始编写Android应用程序,请注意,action bar是其中最重要的设计元素。下面描述的这些指导将有助于使你的应用的界面符合Android应用程序的核心设计。

 

General Organization （动作栏的）一般结构

动作栏分为四个不同的功能区域,适用于大多数应用程序：

1. 应用程序图标

应用程序图标是你的应用的标示。如果你愿意的话，它可以被替换成不同的商标或者LOGO。值得注意的是，如果应用程序当前没有显示顶部界面，那一定要在应用程序图标的左边显示up按钮，这样用户才可以导航到顶层界面。对于up导航的详细说明，请看Navigation pattern（导航模式）部分。

2. 视图控制

如果你的应用程序在不同的视图中显示数据，“视图控制”部分的动作栏允许用户切换视图。比如下拉菜单或者选项卡控件。

如果你的应用程序只在一个视图中显示数据，那么你还可以使用试图控制部分来显示交互式的内容，比如应用程序标题或者详细的品牌信息。

3. 动作按钮

把最重要的操作显示在你的应用程序的这部分中。没有显示在这部分中的操作将会自动移到overflow部分。

4. 动作overflow

把不太常用的操作移动到动作overflow部分。

 

 

适应旋转和不同的屏幕大小

UI最重要的问题之一是考虑如何适应屏幕旋转以及不同的屏幕大小。

你可以通过使用分割动作栏来适应这种变化，它允许你通过多个在主动作栏下面或者屏幕底部的动作栏来分发动作栏内容。

分裂的动作栏按钮显示在垂直方向上的屏幕底部。

 

分裂的动作栏布局注意事项

当分裂成多个动作栏时，你通常有三个可能的位置来放置它们：

1.主动作栏

2.顶部栏

3.底部栏

如果用户可以从给定的界面导航，那么主动作栏至少要包括up按钮。

为了让用户可以快速地在视图间切换，可以在顶部栏使用选项卡或者下拉菜单

为了显示动作栏，如果有必要的话，在底部栏使用动作overflow

 

上下文动作栏

一个上下文动作栏(CAB)是一个临时的动作栏，它涵盖了这个应用程序的动作栏存在期间的特定的子任务。CABs最具代表性的是被用在选择数据或者文本的动作中。

通过在选择的数据项上长按来触发上下文动作栏。

在上下文动作栏中，用户可以：

通过触摸来选择额外的元素。

触摸CAB上的一个操作后，CAB会自动隐藏。

通过导航栏的返回按钮或者CAB的复选按钮可以隐藏CAB，这同时会取消选中项的高亮。

当你允许用户通过长按来选择数据时，使用CAB。你可以控制CAB的内容，插入你希望用户执行的操作。

要了解更多信息，请参加the Selection pattern.

 

 

Action Bar Elements   动作栏原理

tabs 选项卡

 

选项卡（Tabs）用于即刻展示出APP界面，并使其更容易检索以及在选项之间相互切换。如果你预期你的用户会频繁切换界面，那么请使用选项卡（Tabs）。

 

选项卡（Tabs）有两种类型：固定式和滚动式。

 

Scrollable tabs  滚动式选项卡

 

滚动式选项卡通常会占据栏目的整个宽度，且当前活动界面居于中间位置，因此，滚动式选项卡需要在专有栏目之下。滚动式选项卡能够通过其自身水平方向的滚动带来更多的选项卡选项（Tabs）用于浏览。

 

如果你的APP有大量界面，或者由于你的APP是动态嵌入界面所以你不能确定将会有多少界面（例如，在即时信息APP中用户能够在打开的聊天窗口中穿梭），那么请你使用滚动式选项卡。滚动式选项卡应当总是允许用户同滑动选项卡（Tabs）本身一样能够通过左右滑动内容区域来穿梭界面。

 

Fixed tabs  固定式选项卡

 

固定选项卡长年显示在屏幕上，并且它不能像移动滚动式选项卡一样被移动。在主动作栏上的固定选项卡能够在屏幕翻转时移动到顶部栏。

 

Spinners  下拉菜单

 

下拉菜单是一个允许用户切换你的软件界面的下拉菜单。

 

以下情形在主动作栏中较选项卡（Tabs）来说更适合使用下拉菜单：

1. 你不想因为专属选项卡（Tabs）栏而浪费纵向屏幕实际可用面积（screen real estate）。

2. 你预期你的APP用户会频繁切换界面。

 

Action buttons  动作按钮

 

在动作栏上的动作按钮会覆盖你的APP中最重要的活动。思考一下哪个按钮是最经常使用的，并且依次排列。根据可用的屏幕实际可用面积（screen real estate），系统会将你最重要的动作显示为动作按钮并且将多余部分移至“更多动作”（动作溢出action overflow）。动作栏和“更多动作”（动作溢出action overflow）必须仅为用户可用的当前动作。如果一个动作在当前内容下是不可用的，隐藏它。不要让它作为缺陷显示。

 

动作优先级引导，使用FIT方案。

 

F —Frequent  频率

    人们在浏览屏幕时会十次有七次使用到这个动作吗？

    他们通常使用它时会连续用几次吗？

    每次使用一个额外的步骤真的很累赘吗？

 

I —Important  重要性

    你想所有人都了解这个动作，因为它非常与众不同的酷或者是一个卖点？

    这种毫不费力的动作是在罕见的情况下它所需求的吗？

 

T —Typical  特有的

    它呈现出的是在同类APP中特有的的一流动作吗？

    特定环境中，如果它被埋在了“更多动作”（动作溢出action overflow）里，人们会为此感到吃惊吗？

    如果符合F/I或者T任一，那么它适合动作栏。否则，它属于“更多动作”（动作溢出action overflow）。

 

 

预定义符号（Pre-defined glyphs）应当应用于一些常见的动作中，如刷新、分享。下方的下载衔接提供一个图标程序包，它已经根据各种各样的屏幕密度做了尺度调整并且与所使用的明亮或者黑暗的主题相适应。这个程序包还包括未定风格的图标，这样除了在Adobe® Illustrator®源文件中进一步个性化以外，你可以结合你的主题修改它。

Download the Action Bar Icon Pack

 

 

Action overflow  更多动作（动作溢出action overflow）

动作栏中的“更多动作”（动作溢出action overflow）为你的APP中不经常使用的动作提供了通道。更多动作图标只会在没有物理菜单键的手机上显示。有菜单键的手机按键即可显示更多动作。

主动作栏放多少个动作合适？动作栏容量是根据以下规则控制的：

主动作栏上的动作按钮最好不要占掉超过栏目宽度50%的空间。底部动作栏上的动作按钮则可以占掉动作栏的整个宽度。

独立密度像素的屏幕宽度决定着适合主动作栏的按钮数量：

 

 <360dp   =  2图标

 360-499dp   =  3图标

 500-599dp   =  4图标

 600< =  5图标

 

 

Sharing data  分享数据

无论何时你的APP允许分享数据，如照片、视频片段，请使用在你动作栏上的分享动作供应商。这个功能被设计为通过在下拉菜单中陈列最近使用过的共享服务以及包含其他分享选择来提升分享效率。

Action Bar Checklist  动作栏菜单

当你计划划分动作栏的时候，请问自己如下问题：

对于任务来说视图导航有多重要？

如果视图导航对于你的APP来说十分重要，那么为了达到最快速切换请用选项卡（Tabs）或者下拉菜单（spinners）。

APP的哪个动作必须在动作栏上保持长久有效，哪个动作可以移至更多动作（action overflow）？

如果有几个动作都是一级动作或者都可以移入更多动作（action overflow），那么请使用FIT规则筛选决定。如果一级动作的数量超出了主动作栏的容量，那就将他们单独放在底部动作栏上。

能够保证持续显示的其他重要因素是什么？

有时候展示并保持可见的语境信息对你的APP是十分重要的。例如在信息收件箱视图上显示未读信息数字，或者在音乐游戏中显示当前游戏的信息。认真规划哪些是你需要展示出的重要信息，然后对你的动作栏进行相应架构。