【写在前面】
此文纯属个人兴趣翻译搬运，原文地址：https://www.smashingmagazine.com/2017/05/basic-patterns-mobile-navigation/。如专业术语翻译有偏差，欢迎指出。
【本文适合人群】
1.设计师，特别是移动app设计师
2.产品经理(创业公司产品的任何level）
3.移动应用的开发者（记住你永远不仅仅是一个方案的执行者! ）
【正文】
当用户使用你的app时，他们需要随时知道该去哪儿，怎么去。好的导航就像一辆车，能把用户带到他们想去的地方。受屏幕空间和基于web端内容选择优先级的限制，如何在移动端建立一套好的导航系统变的非常有挑战性。
针对这个难题，不同的导航模式有不同的解决方法，但是这些导航模式依然面临各种可用性问题。这篇文章将阐述5个移动端的基本导航模式，分析其优势和劣势。如果你想增加其他的模式，你可以免费下载Adobe XD（广告链接我就不加了，大家按需搜索吧）。
一、汉堡包式菜单
移动端的屏幕空间非常珍贵，汉堡包菜单（或者叫“边橱”）是最流行的节省空间的导航模式之一。它允许你将导航隐藏到屏幕左侧，只有用户点击时才展示。
When to Use
汉堡包式菜单的主要缺点是他被发现的概率较低，并不建议作为主要的导航菜单。但它可以成为一个不错的次级导航。次级导航的选项通常都是在特定情境下对用户来说比较重要的目的地或功能特性。作为次级导航，他们可以被放在一个视觉上不那么重要的位置，只要用户需要时可以快速找到它们。利用汉堡包导航隐藏这些选项，设计师可以避免因为给用户展示过多的选项而导致用户无从选择。
Uber使用的就是汉堡包图标。因为Uber主屏幕的内容聚焦于预约车辆，没有必要将类似“支付”，“历史记录”或者“设置”这些次级选项展示出来。一般使用流程也不涉及这些选项，所以他们选择了汉堡包式图标。
PROS
1.可以提供较多的导航选项。汉堡包式导航菜单的主要优势就是可以涵盖相对较多的导航选项于一个非常小的空间。
2.整洁的设计。设计师可以通过将选项藏在侧面菜单中，省出许多屏幕空间。这种模式可以很好的让用户聚焦屏幕上的主要内容。
CONS
1.不易被发现。所谓“眼不见，心不烦”。当导航内容被隐藏时，用户使用它的机会就会少。尽管这种导航已经开始成为一种标准化设计，用户越来越熟悉这种设计，但还是有很多人不会想到去点击它。
2.与平台的导航规则不一致。汉堡包菜单几乎已经成为Android的一种标准（在素材设计中叫“navigation drawer”），但在iOS中，只有舍弃基础的导航元素才能实现，并很可能导致过载问题。
3.汉堡图标会隐藏内容。汉堡菜单不能以预览选项内容：展现当前位置的信息更难，因为只有当用户点击图标，内容才会展示。
4.达成目标需要额外操作。找到一个具体的页面通常至少要2个页面（1个在菜单图标上，1个在目标选项上）。
TIPS
1.排列选项的优先级。如果导航过于复杂，隐藏并不能改善用户体验。很多实例表明，将菜单以更可见的方式展示会增强用户的互动性和满意度。不妨问自己，对移动端展示来说，什么是足够重要的？回答这个问题，可以帮你很好的理解用户真正关心的是什么。
2.如果高优先级的导航选项较少，可以考虑使用 tabs 或者 tab bar。
3.评审你的信息架构。好的apps 应该是非常聚焦的。如果你有一个非常复杂的应用，可以将其分成两个或者多个简单的应用中。 Facebook 发布 Messenger 来解决复杂性的问题。降低功能点可以减少菜单的选项，或者降低对汉堡包菜单的需求。
二、Tab Bar 标签栏
Tab bar 是从桌面设计中沿袭下来的，它通常有相对较少的目的地，这些目的地都有着同等的重要性，并且可以从应用的任何地方都可以直接到达。
When To Use
标签式导航对有相对较少的高级导航选项（最多5个）的 apps 来说是不错的选择。它让核心功能都展示在一个 tap 中，并可以快速在功能之间切换。
PROS
1.Tab bar 能很好的显示当前位置。适当的使用了视觉引导（icons, labels, and colors）让用户一眼就能识别出其当前位置。
2.一致性。导航不会因为切换页面而不见。用户可以清楚的知道 app 的主要页面，并轻松点击就可以到他们想去的地方。
3.在拇指区域内，底部导航更容易点击，特别是当单手持设备时。
CONS
1.导航的选项是有限的。如果你的 app 有超过5个选项，想把它们都挤进一个导航栏，同时还保证最佳触屏大小将是个挑战。
2. Android 和 iOS 设备上标签栏的位置和逻辑是不同的。不同平台的 UI 和可用性有不同的规则，设计标签栏时需要将这些都考虑进去。标签栏在 Android 设备屏幕上方，而在 iOS 屏幕下方。其中原因是 Android 的底部控制栏是硬件。但是，这个规则不适用于移动端网页，因为浏览网页的用户体验应该保持一致，不应因设备不同而不同。
TIPS
1.让触屏目标大到可以很容易的点击或触碰。计算每次底部导航行为的宽度，用宽度除以次数。或者，让所有导航宽度等于最大宽度（10*10 mm）。
2.给导航选项排序。用户期待看到排好序的标签栏。第一个标签最好是主页，标签的序列最好能反映它们的优先级或者用户流程的逻辑。其中的一个标签应该保持活跃并在视觉上容易识别。
3.测试图标的可用性。下面的例子中，设计师将功能隐藏在图标中，使用户很难识别。为了防止这种悲剧发生，请用5秒定律测试你的图标：如果一个东西要花5秒以上的时间去想一个合适的图标，那么这个图标很有可能不太能直抒其意。
4.如果一个图标没通过定律（既它不是不言而喻的），那么给它一个文本标签。在线下世界中，我们很少会单纯根据图形来表达想法，特别是好的想法。因为缺乏图标的标准用途，文本标签对于表明意义和减少歧义非常有必要。用户应该在点击一个元素前明确了解接下来将会发生什么。
三、Prioirty+ 模式
迈克尔·施纳加尔（Michael Scharnagl）的“优先+”模式是 — 显示认为是最重要的元素，隐藏不太重要的元素在“更多”按钮 — 的导航。
When to Use
这种导航很适合内容很多的 apps 和网页，这些内容有很多部分和页面，例如，一个新闻网页或者一个电商页面。The Guardian 就使用了priority+的模式。不太重要的内容会在用户点击 “All” 按钮时展示。
PROS
1.这种模式优先考虑导航选项。它会展示最常被访问的选项。
2.充分利用屏幕空间。当屏幕增大时，被展示的选项也随之增加，可以提高可见性和参与度。
3.适应性非常高。可以在不同屏幕之间进行很好的扩展而不用担心转换模式。
CONS
它可能会隐藏一些重要的选项。这种模式要求设计师来假设导航选项的相对重要性。需要注意的是，你优先考虑的内容不一定是用户最想看的内容。
四、悬浮按钮
形状类似浮在UI上面的圆形图标，悬浮按钮根据选中的状态改变颜色。对Android用户来说它是一个常见又特别的设计元素。据Google的说法，悬浮按钮的可以促进用户使用。
When to Use
悬浮按钮的设计建立在用户会在绝大多数时候进行某项操作的假设之上。可以通过在app中强调这个观点来使这项“hero”操作更明显。例如，一款音乐app可以用一个悬浮按钮表示“播放”。
这个按钮对用户来说是一个非常自然的线索，告诉用户下一步做什么。Google在用户调研中发现，用户把它视为一个探路的工具。当浏览不熟悉的屏幕（就像大多数人第一次运行一个app）时，他们会通过悬浮按钮来导航。因此，这也是一个优先展示你希望用户进的行操的途径。
PROS
1.它是重要性的标志。
2.它占用极少的屏幕空间。与标签栏相比，它不会占用一整行。
3.一个视觉体验讨喜的UI元素也许不会提高可用性，但是，情感也是用户体验的一个因素。如果一个用户喜欢一个app是因为它的视觉设计很吸引人，这也是一种正面的用户影响。
4.它可以提高效率。Steve Jones 的一个研究 表明，用户在第一次使用悬浮按钮时，对可用性会有轻微的影响，一旦用户通过这个元素完成了一个任务，他们就能比使用普通按钮更有效地使用悬浮按钮。
CONS
1.悬浮按钮会分散用户对内容的注意力。它鲜艳、浮起和破格的设计使其天生突出，这种设计本意就是为了吸引用户的注意力，但有时会分散用户对原本内容的注意力。
2.它会遮挡内容。以Google Gmail 应用为例，下图中的悬浮按钮就遮挡了“收藏”键和最后一行的时间。如果用户想看这些信息，只能通过多余的滑动操作。
3.它是单一图标式导航。从设计上悬浮按钮就是一个圆圈里面有个图标，没有文字标签。因为图标的解释可以有千万种，这就导致有些图标非常难懂。即便是下图中像铅笔一样的图标在不同的apps中可以代表不同的意义。
TIPS
1.因为悬浮按钮如此突出，一屏上请只使用一个。
2.不是每个屏都需要一个悬浮按钮，就像不是每屏都有同等重要的操作。
3.悬浮按钮与正面操作有很强的相关性，因为这些特点，它通常都被用作正面操作（如创建、收藏、导航、搜索等）。不要把它用于毁灭性操作，如删除。
4.悬浮按钮可以用一系列具体操作取代。这样可以用来展示一些优先级没那么高但也很重要的操作。Evernote 就是通过悬浮按钮来简化控制键的。
5.悬浮按钮还可以改善不同屏之间的转换。它不只是一个圆形的按钮，它还有一些转换属性，例如扩展、变换等，简化用户在不同屏之间的操作。
五、全屏导航
本文提到的其他导航模式都在想法设法减少导航占用的屏幕资源，而全屏导航采用的是相反策略。这种导航通常提倡将整个首页作为导航。用户通过一步步点击或翻页来发现菜单中的其他选项。
When to Use
这种模式在基于任务和基于地点的网页和app中较实用，特别是当用户想将内容限制在导航结构的某个分支内时。从概述页面过滤到详情页面可以帮助用户了解他们真正寻找的内容，并专注于某部分的内容。
PROS
全屏导航是实现简约化和一致性的最佳方式。你可以通过将信息块以一致性的方式组织起来进行展示，避免因信息过多而吓跑用户；当用户决定了他们的路径，便可以用整屏来展示内容。
CONS
浏览器（Chrome）页面上的优质资源将会被浪费。除了导航选项，你不能展示任何内容。（想想：360）
TIPS
通过汉堡包菜单隐藏次要功能，将重点放在主要体验上。
六、 基于手势的导航
2007年6月29日，从Apple发布第一款全触屏智能手机那一刻起，游戏规则变了，移动设备开始被触屏交互主导。
(Image:Aaron Wade)
手势迅速在设计师中流行起来，甚至不少 apps 的设计就是对手势控制的实验。
如今，一款移动应有的成功很大程度上取决于它手势操作的用户体验的好坏。
When to Use
当用户想简单自发地体验某个具体内容时，手势模式很适用。与普通导航菜单相比，用户会花更多时间在内容上。所以，选择基于情境的手势而非标准菜单的一个原因是，手势的互动性更强。例如，当用户浏览一个页面内容时，他们可以点击某个图片了解更多。
PROS
1. 手势省去了UI 组件。将手势融入设计之中可以最小化操作界面，把屏幕空间留给更有价值的内容。
2.手势的UI更自然。Luck Wroblewsk 提到一项研究，让40个来自于9个不同国家的人给28个不同任务设计手势，如删除、滑动、缩放，结果表明，手势有着跨文化和体验的相似性。例如，当表示“删除”时，大家会尝试将物体拖出屏幕。
3.手势可以成为一个产品的特性。Tinder 大量使用了基于手势的概念，并使这些手势成为了一个产品的特征。
CONS
1.手势的导航是不可见的。UI设计的一个重要法则是可见性：通过菜单，所有操作都应该可见并容易被发现。可见的UI可以美丽诱人，但因为手势是不可见的，就很可能会有很多可用性的问题。
2.用户使用成本增加。大多数手势既不人性也不易学。当设计基于手势的导航时，每次删掉UI组件都会增加app的学习成本；如果没有合理的视觉引导和线索，用户会不知道如何进行操作。
TIPS
1.确保用户不需要学习一个全新的交互方式。设计用户熟悉的体验。为了设计好基于手势的导航，从观察现有的手势开始。如果你在设计一款邮箱应用，可以使用左右滑动手势，因为这个操作对很多用户来说可能已经很熟悉：
2.结合上下文教育用户如何进行交互。避免冗长的、静态的前期教程，尽量给用户展示与当前活动相关的信息。
七、3D Touch
3D Touch 是随着iPhone 6s和 6s Plus面世的一种微妙的触屏机制。Apple将其可以进行的操作分为两大类：
（一）快速操作
iOS 主屏不再只是应用的罗列，因为3D Touch可以让用户在主屏上未打开应用时就对其进行一些操作。长按应用图标会出现一个快速操作的小列表：直接进入自拍模式、或者通过短信直接找到常用联系人。
（二）Peek and pop
3D Touch允许用户在决定看完整内容前预览部分内容并进行相关操作。当用户长按某个内容时，如邮件列表里的一条内容，3D Touch 会展示一个预览页面。
When to Use
使用3D Touch可以非常方便的进行常用操作。把3D Touch看成是键盘快捷键：让人快速完成重复操作。还可以通过3D Touch帮用户跳过一些不必要的步骤。
但就像键盘快捷键，核心功能不应该只属于3D Touch，用户通过正常运行 app 也应该可以进行这些操作。
PROS
1.通过快捷键操作，3D Touch可以跳过一些不必要的点击节省时间。
2.通过简化界面，3D Touch可以实现快捷、轻量级交互。它给了设计师和开发者简化界面的新契机。
CONS
用户需要记住哪些应用有快捷操作。3D Touch还没有普及，一些应用有这个功能，一些没有。
八、创新式导航模式
虽然手机屏幕越来越大，但大部分屏幕的触达性却越来越低（less easily acessible），设计能（特别是导航）适应不同屏幕就越有必要。
为解决这个问题，设计师不得不寻求新的解决方案。一些有意思的解决方案可以在最近发表的 底部导航界面（Bottom Navigation Interface）中找到。一个解决方案在一个款医疗app （Ada）中应用。这款应用的界面是一个有汉堡包菜单的镜面：通常在app顶部的东西都被放到了app底部的易触达区域。
另一个解决方案是针对打电话应用的，应用了单手导航原则。这个方案可以解决人们打电话或发信息时倾向于用单手进行操作的问题。
结 论
设计用户导航应该是每个app设计者高优先级考虑的事情。新用户和老用户都需要知道如何进行操作。产品的易用性越高，用户就会越喜欢你的产品。
原文里的绝大部分外链我都添加了（有些可能需要科学上网）。
最后感谢周陟老师最初分享这篇原文。
