iOS 10设计规范（四）：交互 Part 2

手势

用户是通过触摸屏上的手势来跟iOS设备交互，在用户的预期中，下面这些标准手势在跨系统和所有APP中都有同样的效果。
点击。触发一个控制或者选择一个物体。

• 拖拽。移动屏幕上的元素。
• 轻滑。快速的滚屏或移动。
• 横扫。当用一根手指操作时，可以返回上一屏（返回）、展示分屏功能（split view）中被遮挡的部分、展示列表中某一行的删除按钮、展示Peek中的操作项。当在iPad中用四根手指操作，可以在APP之间切换。
• 双击。放大并且居中内容/图片，在已经放大的状态下缩小。
• 捏。往外捏会放大，往里捏合会缩小。
• 长按。若针对可编辑或可选中的文本操作，会展示被放大的光标位置界面；若针对固定内容界面操作，比如集合视图，会进入编辑模式。
• 摇动。撤销或重做。

总的原则是：要使用标准手势。人们都熟悉标准手势，也不希望被迫学习新的手势来做同样的事情。不过在游戏或者其他沉浸式的APP中，自定义手势反而会增加乐趣。除此之外，最好还是使用标准手势，这样就不需要付出额外的发现和记忆成本了

不要禁止系统级手势。除了标准手势，还有一些其他手势会引发系统级的响应。比如控制中心（从屏幕底部往上拉）和通知中心（从屏幕顶部往下拉）。用户在所有APP中还是需要使用这些手势的。

不要用标准手势完成不标准的操作。除非你的APP是有特殊玩法的游戏，否则重新定义标准手势的意义会导致用户疑惑，增加理解的复杂度。

提供一些缩短操作路径的手势作为导航或其他操作的补充（而非替代）。很多系统应用都有个清晰、可点的导航栏按钮，可以让用户回到之前的页面，同时，用户也可以用从屏幕边缘横扫的手势来返回。在iPad上，人们可以按压Home键返回桌面，同时，也可以使用4根手指捏合的手势。

使用多手指手势可以提高某些APP的体验。尽管并非所有APP都适合多手指操作的手势，比在某些APP中可以让体验变得更丰富，比如游戏和绘画APP中。举个栗子，一些游戏需要多点控制（如方向杆和开火按钮），这时候多手指手势允许这些控制同步进行。

加载过程

当内容在加载中的时候，一个空白或者静止的页面会让APP看起来像卡住了，导致用户疑惑甚至失望，有可能让用户离开你的APP。

加载过程中，尽可能让加载过程明确、透明。至少，展示一个活动的「转菊」表示一直有进度。更好一点的话，告诉用户明确的进程/进度，让他们知道还需要等多久。

加载过程中，可以教育或者娱乐用户。试试展示一些游戏提示、一系列好玩的视频、有趣的占位图形。

设计个性化的加载界面。虽然标准的进度条通常是够用了，但有时还是会让用户感觉出戏。考虑使用些跟APP或者游戏契合的自创动画和元素，打造一种沉浸式的体验。

尽快给出内容。不要在给出用户预期的界面前，就让用户一直等着，而是要尽快把界面展示出来。可以在未加载的地方使用占位的文字、图形或者动画，当内容加载完毕后再替换掉这些占位符。可以的话，在后台就加载好下一页的内容，比如在动画播放的时候，或者在用户通过导航菜单跳转的时候。

关于加载过程提示的更多信息，详见后文的「加载过程提示」。

模态（Modality）

模态是指，用户必须停下其他事情，先完成一项任务、关闭一条消息或界面才能继续的状态。浮层表单（Action Sheet）、弹框（Alert）、活动视图（Activity Views）都可以实现模态的体验。一些APP有模态界面，比如当用户在编辑日历中的事件，或者当用户在Safari中选择书签的时候。模态界面有几种形态：可以是全屏的，可以是父界面，可以是悬浮窗，也可以只是屏幕的一部分。一个典型的模态界面包括「确认」、「取消」两种退出模态的选项。

尽量少使用模态。一般来说，用户希望非线性地使用APP，只有必须要吸引用户全部注意的时候再使用。比如说用户必须在「完成」和「放弃」中二选一才能继续使用APP的时候，又比如要用户保存重要信息的时候。

为用户提供一种明显且安全的方式离开模态。要确保用户在离开模态时，对他们的行为会导致什么结果有明确的认知。

保持模态任务的的简单、精炼、聚焦。不要将模态设计成好像嵌在APP中的迷你应用。如果模态设计得太复杂，用户很容易忘记进入模态之前的主要任务是什么。在创建那些包含树形视图结构的模态任务时要特别小心，因为这种形式很容易使人们产生迷失感，忘记回退的步骤。如果你的模态任务当中必须包含那些需要通过不同的视图来呈现的子任务，那么一定要给用户提供单一且清晰的信息结构路径。在用户完成模态任务前，避免使用「完成」按钮。

为模态界面拟一个能够概括任务的标题。你也需要在界面的其他部分提供能完整描述任务或者能引导用户的文字。

把提醒弹框（Alert）留给需要传递必要——理想情况下还应有可操作项——的信息的时候。提醒框会打断用户的操作，并且需要用户点击一下才能退出。所以让用户感觉这个弹框的出现是合理的，非常重要。更多信息，后文继续展开。

对通知的体验怀抱敬畏之心。在设置中，用户会定义他们接收你APP通知的方式。记住这一点，可以避免导致用户完全关掉你APP的通知。

不要在悬浮窗之上再展开一个模态界面。除了提醒弹框，其他东西都不应该在悬浮窗之上出现。在极少数情况下，当用户在悬浮窗上做出操作后需要展现一个模态界面，那就先关闭悬浮窗，再展现模态界面。

根据你APP的布局，调整模态界面的位置。举个栗子，模态界面有时会包含导航栏，让它的位置跟你APP的导航栏位置重合。

选择恰当的模态界面样式。你可以使用的样式包括：

选择一个适合的模态过场。要跟你的APP搭配，不突兀。默认的过场方式是从屏幕下方垂直地向上进入，完成后再落下去。三维翻转的过场方式，在视觉上看好像是当前界面的背面内容，完成模态任务后再翻转回来。需要注意的是，APP中的模态过场方式要保持统一。

导航

用户在APP中发生了预期外情况时，就需要导航了。你的任务就是让导航能自然而不突兀地支撑整个APP的结构和想要实现的目标。导航应该是自然的、易理解的，而不是喧宾夺主地令用户的注意力从内容上吸引过来。iOS中，有三种主要的导航结构。

树形结构

在每屏都要选择一条路径，直到到达目标页面为止。这时候如果你要去另一个地方，你必须一步步回退，或者从头开始再选择不同路径。设置、邮箱就是这种导航结构。

扁平结构

可以在很多类别的内容间切换，音乐和AppStore就是这种导航结构。

内容或体验驱动的结构

可以在内容中随意切换，或者内容本身就是导航。游戏、书籍以及其他沉浸式APP大多都使用这种导航结构。

一些APP也会融合多种导航结构，比如，一个APP可以在使用扁平结构的同时，在每个类别中又使用树形结构。

永远都要为用户提供清晰的路径。用户应该随时都能够知道他们在APP中的什么位置，而且了解如何去前往一个目的地。除了导航结构，内容之间的路径也应该是有逻辑、可预期的。一般来说，每个页面都要有到达路径。如果用户需要在一个页面上看多种信息，试试使用操作项列表（Action sheet）、提醒框、悬浮窗或者模态界面。这些组件的详细信息，后文展开。

设计一种能够快而简单地获取内容的信息架构。以尽可能少的点击、滑动和页面来组织所有信息。

用各种手势营造流畅而优雅的体验。让用户毫无阻拦地在各页面之间移动。比如，你可以允许用户通过从屏幕侧边滑动，以返回上一页。

使用标准的导航组件。尽量使用页面控制组件（Page Control）、Tab栏、Segmented Control组件、列表组件、集合视图（Collection Views）组件和分割屏组件。用户对这些组件都已经熟悉了，凭直觉就知道怎么使用你的APP。

在移动过程中使用导航栏（Navigation Bar）。导航栏的标题会告诉用户目前在什么位置，「返回」按钮可以简单返回上一页。更详细信息，在后文「导航栏」展开。

利用Tab栏代表不同类别的内容或功能。无论用户现在在哪里，tab栏都能让用户快速简单地在不同模块间切换。更多信息，在后文「Tab栏」展开。

当你要展示多个包含同一类内容的页面时，试试页面控制组件（Page Contro，比如很多APP更新后的功能介绍页底部的导航小圆点）。这个组件会告诉用户一共有几页，以及目前所处位置。「天气」APP就使用了一个页面控制组件来展示不同位置的天气页。更多信息，在后文「页面控制组件」展开。

Segmented Controls组件（见下图）和工具栏没有导航作用。前者用于将信息组织成不同类别，后者用于与当前内容进行交互。更多信息，在后文「Segmented Controls」和「工具栏」展开。

来源：

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

由WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。

本文首发于Why·Liam·Blog (https://blog.naaln.com)，版权所有，侵权必究。

本文永久链接：https://blog.naaln.com/2016/07/ios-10-design-4/